assignment of rdbms

Q.1 Explain the Database Recovery Techniques.

Database Recovery Techniques
Introduction to Database Recovery
Database recovery is the process of restoring a database to a correct state after it has been subjected
to failures such as system crashes, power outages, hardware failures, or software errors. Recovery
ensures that the database remains consistent and adheres to the ACID properties (Atomicity,
Consistency, Isolation, Durability).

Types of Failures
1. Transaction Failure: Occurs when a transaction cannot be completed due to logical errors,
system issues, or user errors.
2. System Crash: Results from hardware or software failures, causing the system to halt
unexpectedly.
3. Disk Failure: Includes disk corruption or crashes, leading to loss of data stored on the disk.
Recovery Techniques
There are several techniques to recover a database depending on the type of failure. These
techniques include:
1. Log-Based Recovery
 Transaction Logs: Every change made to the database is recorded in a log. The log contains
details such as the transaction ID, operation type, affected data, and the before-and-after
values.
 Undo and Redo Operations:
 Undo: Reverses uncommitted transactions to ensure atomicity.
 Redo: Reapplies committed transactions to ensure durability.
 Write-Ahead Logging (WAL): Ensures that log entries are written to stable storage before
the corresponding data changes are made to the database.
2. Checkpoints
 A checkpoint is a snapshot of the database's state at a particular point in time.
 During recovery, the system starts from the most recent checkpoint, avoiding the need to
process older transactions, thus reducing recovery time.
3. Shadow Paging
 In this technique, changes are made to a shadow copy of the database instead of the actual
database.
 If a transaction commits successfully, the shadow copy replaces the original database.
 Advantages: No need for logs or checkpoints.
 Disadvantages: High overhead due to copying large data blocks.
4. Deferred Update
 In this method, changes are not written to the database until a transaction commits.
 If a failure occurs before the commit, no changes are made, simplifying recovery.
 However, this can lead to slower performance for large transactions.

5. Immediate Update
 Changes are written to the database as soon as they occur, even before the transaction
commits.
 Recovery involves undoing uncommitted changes and redoing committed changes.

6. Backup and Restore

 Regular backups of the database are maintained to ensure data can be restored in case of a
failure.
 Backups can be full, incremental, or differential.
 Restoration involves applying backups and then redoing or undoing transactions as per the
logs.
7. ARIES (Algorithm for Recovery and Isolation Exploiting Semantics)
 ARIES is a widely used recovery algorithm that combines log-based recovery, checkpoints,
and other optimizations.
 Steps in ARIES:
1. Analysis Phase: Identifies dirty pages and active transactions.
2. Redo Phase: Reapplies changes from the log to ensure all committed transactions are
reflected.
3. Undo Phase: Rolls back changes from uncommitted transactions.
Conclusion
Database recovery techniques are essential for ensuring data consistency, reliability, and availability
in the face of failures. The choice of technique depends on the specific requirements of the database
system, such as performance, durability, and complexity. By implementing robust recovery
mechanisms, organizations can safeguard their data and maintain trust in their database systems.

Q.2 Explain the Relational Algebra.

Relational Algebra
Introduction
Relational Algebra is a procedural query language used to query and manipulate data stored in a
relational database. It provides a set of operations to perform queries and retrieve desired results.
These operations are performed on relations (tables) and produce new relations as their output.

Fundamental Operations
The basic operations of relational algebra include selection, projection, union, set difference,
Cartesian product, and renaming. These form the building blocks for more complex queries.
 1. Selection (σ)
 Filters rows in a relation based on a specified condition.
 Syntax: σcondition(R)\sigma_{\text{condition}}(R)
 Example: σage>25(Employee)\sigma_{\text{age} > 25}(Employee) selects
employees older than 25.
2. Projection (π)
 Extracts specific columns (attributes) from a relation.
 Syntax: πattribute1, attribute2, ...(R)\pi_{\text{attribute1, attribute2, ...}}(R)
 Example: πname, age(Employee)\pi_{\text{name, age}}(Employee) retrieves only
the name and age of employees.
3. Union (∪)
 Combines tuples from two relations and removes duplicates.
 Syntax: R∪SR \cup S
 Example: Combining the records of two departments in an organization.
 Note: Relations must be union-compatible (same attributes and domains).
4. Set Difference (−)
 Retrieves tuples present in one relation but not in another.
 Syntax: R−SR - S
 Example: Employees in RR but not in SS.
5. Cartesian Product (×)
 Combines every tuple of one relation with every tuple of another relation.
 Syntax: R×SR \times S
 Example: Joining two relations where no common attribute exists.
6. Rename (ρ)
 Assigns a new name to a relation or its attributes.
 Syntax: ρnewName(R)\rho_{\text{newName}}(R)
 Example: ρDept(Department)\rho_{\text{Dept}}(Department) renames the
"Department" relation to "Dept".

Derived Operations
Derived operations are built using fundamental operations and simplify query expression.

1. Intersection (∩)
 Retrieves common tuples between two relations.
 Syntax: R∩SR \cap S
2. Join (⨝)
  Combines related tuples from two relations based on a condition.
 Types:
 Theta Join (⨝θ): Combines tuples matching a condition.
 Equi-Join: A special case of theta join where the condition is equality.
 Natural Join: Automatically joins relations based on common attributes.
3. Division (÷)
 Retrieves tuples from one relation that are related to all tuples in another relation.
 Example: Find students who have completed all courses in a given list.
4. Outer Join
 Includes tuples that do not have matching pairs in the other relation.
 Types: Left Outer Join, Right Outer Join, Full Outer Join.
Example Query
Suppose we have two relations:
Student: {RollNo, Name, Age}\{ \text{RollNo, Name, Age} \}
Marks: {RollNo, Subject, Marks}\{ \text{RollNo, Subject, Marks} \}
Query: Retrieve names of students with marks in "Math".

 Relational Algebra: πName(σSubject = ’Math’(Student⋈Marks))\pi_{\text{Name}}(\

sigma_{\text{Subject = 'Math'}}(Student \bowtie Marks))

Conclusion
Relational Algebra is a powerful query language that serves as the theoretical foundation for SQL.
By using its operations, users can construct complex queries to manipulate and retrieve data
efficiently from relational databases.

Q.3 Explain Constraints and Triggers.

Constraints and Triggers
Introduction
In relational databases, constraints and triggers are mechanisms to enforce data integrity and
automate certain actions. Constraints ensure that data adheres to specified rules, while triggers
execute predefined actions when specific events occur.

Constraints
Constraints are rules applied to table columns to maintain data validity and integrity. They prevent
invalid data entry and enforce database consistency.
Types of Constraints
1. Primary Key
  Ensures that each row in a table is unique and identifiable.
 Example: A "StudentID" column in a "Student" table.
2. Foreign Key
 Maintains referential integrity between two tables.
 Example: A "CourseID" in an "Enrollment" table references the "Course" table.
3. Unique
 Ensures that all values in a column are distinct.
 Example: A "Username" column in a "Users" table.
4. Not Null
 Ensures that a column cannot have null (empty) values.
 Example: A "Name" column in an "Employee" table.
5. Check
 Ensures that values meet a specific condition.
 Example: Check (Age > 18)\text{Check (Age > 18)}.
6. Default
 Assigns a default value to a column if no value is provided.
 Example: A "Status" column defaults to "Active".

Triggers
Triggers are database objects that execute automatically in response to certain events such as
INSERT, UPDATE, or DELETE operations.
Features of Triggers
 Automated Execution: Triggers run without manual intervention.
 Event-Driven: Activated by specific database events.
 Enforce Rules: Useful for enforcing complex business logic.
Types of Triggers
1. Before Triggers
 Executed before the specified event.
 Example: Validate data before insertion.
2. After Triggers
 Executed after the specified event.
 Example: Log changes to a table.
3. Instead Of Triggers
  Used for views to intercept operations like INSERT, UPDATE, or DELETE.
 Example: Redirect an INSERT to another table.

Example of a Trigger
Scenario: Automatically log updates to an "Employee" table.
CREATE TRIGGER log_update
AFTER UPDATE ON Employee
FOR EACH ROW
INSERT INTO Employee_Log (EmpID, OldSalary, NewSalary, UpdateTime)
VALUES (OLD.EmpID, OLD.Salary, NEW.Salary, CURRENT_TIMESTAMP);

Comparison
 Constraints: Enforce rules passively, ensuring data integrity.
 Triggers: Perform active actions based on events, enabling automation.

Conclusion
Constraints and triggers are essential tools for maintaining data integrity and automating actions in
relational databases. Constraints provide a foundation for data validity, while triggers add flexibility
and automation to database management. Together, they ensure robust and consistent database
operations.

Q.4 Explain the Denormalization.

Denormalization
Introduction
Denormalization is the process of intentionally introducing redundancy into a database by
combining tables to improve query performance. While normalization eliminates redundancy to
ensure consistency, denormalization strikes a balance between efficiency and data integrity. It is
often used in systems where read operations dominate write operations.

Why Denormalization is Used

1. Performance Improvement: Reduces the number of joins required in queries, speeding up
data retrieval.
2. Reduced Complexity: Simplifies query logic, making it easier for developers and
applications to access data.
3. Optimized for Read-Heavy Workloads: Suitable for reporting and analytical systems
where data is read frequently.
When to Use Denormalization
 When joins are causing performance bottlenecks.
 For large-scale databases with high read-to-write ratios.
 In distributed databases to reduce the number of network calls.

Techniques of Denormalization
1. Combining Tables
 Merges two or more normalized tables into a single table.
 Example: Combining "Customer" and "Order" tables into one.
2. Adding Redundant Columns
 Stores additional attributes in a table to avoid joins.
 Example: Adding "CustomerName" to the "Order" table.
3. Precomputing Aggregates
 Stores calculated values, such as totals or averages, in a table.
 Example: Adding "TotalSales" to a "Sales" table.
4. Storing Derived Data
 Saves derived values to avoid recalculations.
 Example: Storing "Age" instead of recalculating it from the "DateOfBirth".

Advantages of Denormalization
1. Faster query performance.
2. Reduced query complexity.
3. Improved reporting and analytics.

Disadvantages of Denormalization
1. Increased Storage: Redundancy leads to higher storage requirements.
2. Data Inconsistency: Changes in one location might not propagate correctly to redundant
data.
3. Maintenance Challenges: Updates and deletions become more complex due to duplication.
Example
Consider a normalized database with:

 Customer Table: {CustomerID, Name}\{ \text{CustomerID, Name} \}

 Order Table: {OrderID, CustomerID, Amount}\{ \text{OrderID, CustomerID, Amount} \}
After denormalization:

 A single table: {OrderID, CustomerID, Name, Amount}\{ \text{OrderID, CustomerID,

Name, Amount} \}.

Conclusion
Denormalization improves query performance in specific scenarios at the cost of redundancy and
potential inconsistencies. It is a strategic decision based on the system's requirements, balancing
performance with data integrity.

Q.5 Explain the all different types of Normalization with

Examples.
Types of Normalization
Introduction -Normalization organizes data in a database to reduce redundancy and improve
integrity. It involves dividing data into multiple tables and defining relationships. Here are the key
normal forms:

1. First Normal Form (1NF)

Rule:

 Each column contains atomic values (no arrays or repeating groups).

 Each row must be unique (identified by a primary key).
Example:

StudentID Name Courses

1 Alice Math, Physics
1NF Table:

StudentID Name Course

1 Alice Math
1 Alice Physics

2. Second Normal Form (2NF)

Rule:

 Must be in 1NF.
 Non-prime attributes must depend on the entire primary key.
Example:
Order Table:

OrderID ProductID ProductName

2NF Tables:
Orders Table:

OrderID OrderDate
OrderDetails Table:

OrderID ProductID Quantity

3. Third Normal Form (3NF)

Rule:

 Must be in 2NF.
 No transitive dependencies (non-prime attributes shouldn't depend on other non-prime
attributes).
Example:

EmpID DeptID DeptName

3NF Tables:
Employee Table:

EmpID DeptID
Department Table:

DeptID DeptName

4. Boyce-Codd Normal Form (BCNF)

Rule:

 Must be in 3NF.
 Every functional dependency's left side must be a superkey.
Example:

CourseID Instructor
BCNF Tables:
Instructor Table:

Instructor Department
Course Table:

CourseID Instructor

5. Fourth Normal Form (4NF)

Rule:
  Must be in BCNF.
 No multi-valued dependencies (where attributes are dependent on unrelated columns).
Example:

StudentID Course Hobby

4NF Tables:
Student-Course Table:

StudentID Course
Student-Hobby Table:

StudentID Hobby

6. Fifth Normal Form (5NF)

Rule:

 Must be in 4NF.
 No join dependency that is not implied by candidate keys.
Example:
| ProjectID | EmployeeID | Role |
5NF Tables:
Project-Employee Table:

ProjectID EmployeeID
Project-Role Table:

ProjectID Role

Conclusion
Normalization reduces redundancy and ensures data integrity. Higher normal forms, like 4NF and
5NF, handle complex dependencies but may increase query complexity.