Mid Term 2 Examination

4CS4-05: Database Management System

Important Questions

1. What is meant by relational calculus?

2. Write short notes on the following
a. Triggers
b. Normalization
c. Database failures
3. What is MongoDB?
4. Explain following …
a. Shadow Paging
b. Relational Algebra
5. What is a view in DBMS? How does it differ from a table?
6. Describe following …
a. Concurrency
b. Log-based Recovery
c. Active database
7. Define instance and schema.
8. Distinguish between the following
a. 3NF vs BCNF
b. Immediate update and deferred update.
9. What are some common NoSQL database types?
10. What is MongoDB
 5 years (Previous Years) Important Questions and Answers

Question : Define instance and schema. [2024]

Answer An instance in DBMS refers to a specific occurrence or snapshot
of a database at a particular point in time. It represents the current state of the
database, including the data stored in it.
Schema - A schema in DBMS is the overall structure or organization of a
database, including the relationships between different tables, columns, and data
types. It defines the blueprint or layout of the database, specifying how data is
organized and related.

Q. What are some common NoSQL database types?

Answer: Common NoSQL database types include key-value stores (Redis,
Memcached), document databases (MongoDB), graph databases (Neo4j), and
wide-column stores (Cassandra).

Q. What is MongoDB
Answer: MongoDB is a popular document database that stores data in
JSON-like documents. It offers a flexible schema, horizontal scalability, and
supports various query options.

What is a view in DBMS? How does it differ from a table?

A View is a virtual table created by querying one or more base tables. It
does not store data physically but dynamically retrieves it when queried. Unlike
a table, a view does not store its own data but presents data from other tables.

Q. When would you use a NoSQL database instead of a SQL database?

Answer: NoSQL databases are often used for applications that require high
scalability, handle large volumes of unstructured data, or need flexible schema
designs. Examples include social media, content management systems, and web
analytics.

Q. What are the key differences between SQL and NoSQL databases?
Answer: SQL databases are relational, have strict schemas, use SQL for
querying, and scale vertically. NoSQL databases are non-relational, have flexible
schemas, use APIs for querying, and scale horizontally.

What is a deadlock in DBMS? How can it be prevented?

A deadlock occurs when two or more transactions are blocked because
each transaction is waiting for the other to release resources. This results in
a situation where none of the transactions can proceed.
Prevention techniques:
 Lock ordering: Ensuring that all transactions acquire locks in the
same predefined order.
Timeouts: Automatically rolling back transactions that have been
waiting too long for resources.
Deadlock detection: Periodically checking for deadlocks and aborting
one of the transactions to break the cycle

Explain the concept of a schema in DBMS.

A schema in DBMS is the structure that defines the organization of data in
a database. It includes tables, views, relationships, and other elements. A schema
defines the tables and their columns, along with the constraints, keys, and
relationships.

What are constraints in DBMS?

Constraints in DBMS are rules that limit the type of data that can be
inserted into a table to ensure data integrity and consistency. Common types of
constraints include: NOT NULL, PRIMARY KEY, FOREIGN KEY, UNIQUE,
CHECK, DEFAULT.

Que. What are Boyce-Codd Normal Form and Third Normal Form
Boyce-Codd Normal Form vs. Third Normal Form
Normalization is a technique used in database design to reduce redundancy and
improve data integrity. 3NF (Third Normal Form) and BCNF (Boyce-Codd
Normal Form) are higher levels of normalization.
Third Normal Form (3NF)
A relation is in 3NF if:
1. It is in Second Normal Form (2NF).
2. No transitive dependency exists, i.e., no non-prime attribute (an
attribute that is not part of any candidate key) is transitively dependent
on the primary key.
Formal Definition:
A relation is in 3NF if for every functional dependency X → A, at least one
of the following holds:
 X → A is a trivial dependency (i.e., A ⊆ X)
 X is a super key
 A is a prime attribute (part of some candidate key)
Boyce-Codd Normal Form (BCNF)
A relation is in BCNF if:
 For every functional dependency X → A, X must be a super key.
So, BCNF is a stricter version of 3NF.
Key Differences Between 3NF and BCNF
 Aspect 3NF BCNF
Allows functional dependencies Does not allow any
Definition where RHS is a prime attribute, functional dependency
even if LHS is not a super key. unless LHS is a super key.
More lenient, allows some Stricter, removes more
Flexibility
redundancy. redundancy.
Dependency X → A is allowed even if X is not X → A is allowed only if
allowed a super key, if A is prime. X is a super key.
Normalization
Weaker than BCNF Stronger than 3NF
Level
Candidate key: (A, B), and
Example of Not allowed in BCNF,
dependency: B → C, where B is
violation allowed in 3NF.
not a super key and C is prime.
Example
Let’s take a relation:
R(A, B, C)
FDs: A → B
B → A
B → C
Candidate Key: {A, B}
Check if it's in 3NF:
 B → C: B is not a super key, but C is prime? No, C is not in candidate
key.
So, not 3NF.
Now take another example:
R(StudentID, CourseCode, Instructor)

FDs:
1. StudentID, CourseCode → Instructor
2. Instructor → CourseCode
Candidate Key = (StudentID, CourseCode)
 Dependency 1 is fine.
 Dependency 2: Instructor → CourseCode
o LHS (Instructor) is not a super key
o RHS (CourseCode) is a prime attribute? No.
o So not in 3NF or BCNF
If RHS were a prime attribute, then:
 The relation might be in 3NF but not in BCNF.
Imp. Points
 BCNF removes more redundancy than 3NF.
  Every BCNF relation is in 3NF, but not every 3NF relation is in
BCNF.
 Use BCNF when perfect data integrity is crucial and some redundancy
is unacceptable.

What are the different types of database locks?

There are several types of locks in DBMS to ensure data consistency when
multiple transactions are involved:

Shared Lock (S Lock): Allows multiple transactions to read a resource but

prevents modification.
Exclusive Lock (X Lock): Prevents any other transaction from reading or
modifying the locked resource.
Intent Lock: Signals that a transaction intends to lock a resource.
Update Lock (U Lock): Used when a transaction intends to update a
resource.

Relational Algebra
Relational Algebra?
Relational Algebra is a formal system (a procedural query language) used to
retrieve data from relational databases. It operates on relations (tables) and
produces relations as results.
It provides a set of operations that take one or more relations as input and give
a new relation as output.
Relational algebra forms the theoretical foundation of SQL, even though SQL
is declarative while relational algebra is procedural.
Types of Operations in Relational Algebra
There are two types of operations:
1. Basic (Prime) Operations
These are fundamental operations from which all other operations can be
derived.
2. Derived Operations
These are built using combinations of basic operations.

PRIME OPERATIONS in Relational Algebra

Here are the five basic (prime) operations:
Operation Symbol Description
1. Selection σ (sigma) Picks specific rows
2. Projection π (pi) Picks specific columns
3. Union ∪ Combines rows from two relations
4. Set Difference − Rows in one relation but not in another
 Operation Symbol Description
5. Cartesian Product × Combines all rows from two relations
Let’s go through each in detail:
1. Selection (σ)
Purpose: Selects rows that satisfy a condition.
Syntax:
σ<condition>(Relation)
Example:
σage > 18(Student)
Returns all students whose age is more than 18.
👉 Output: All columns, only rows that satisfy the condition.
2. Projection (π)
Purpose: Selects specific columns from a relation.
Syntax:
π<column1, column2, ...>(Relation)
Example:
πname, age(Student)
Returns only the name and age columns of all students.
👉 Output: Only selected columns, removes duplicate rows.
3. Union (∪)
Purpose: Combines rows from two relations, removing duplicates.
Syntax:
Relation1 ∪ Relation2
Example:
πname(Student) ∪ πname(Teacher)
Returns names present in either Student or Teacher tables.
Both relations must be:
 Of the same number of attributes
 Corresponding attributes must have the same domain
4. Set Difference (−)
Purpose: Returns rows that are in the first relation but not in the second.
Syntax:
Relation1 − Relation2
Example:
πname(Student) − πname(PlacedStudents)
Returns names of students who are not placed.
📌 Same requirements as Union: compatible relations.

5. Cartesian Product (×)

Purpose: Combines every row of one relation with every row of another
relation.
Syntax:
Relation1 × Relation2
Example:
If Student has 3 rows and Course has 2 rows, then:
Student × Course has 3×2 = 6 rows.
Often used as an intermediate step before applying join operations.

🎯 Imp. Points Table

Operation Symbol Works On Output Main Use
Selection σ Rows Selected rows Filtering
Column
Projection π Columns Selected columns
picking
Two Combined rows (no
Union ∪ Merge
relations duplicates)
Two
Difference − Rows in one but not in other Subtraction
relations
Two
Product × All combinations Join base
relations
 All operations produce a relation (output is a table).
 Relational algebra is closed: the result of an operation can be used in
another.
 These prime operations can be combined to perform complex queries.

What is a subquery in SQL? Provide an example.

A subquery in SQL is a query embedded within another query. It is used to
retrieve data that will be used in the outer query. Subqueries can be used in
SELECT, INSERT, UPDATE, or DELETE statements.

There are two types of subqueries:

Single-row subquery: Returns a single value.

Multiple-row subquery: Returns multiple values.
Example of a subquery: To find the names of students who have a higher
age than the average age:

SELECT Name FROM Student

WHERE Age > (SELECT AVG(Age) FROM Student);

Shadow Paging— a technique used in database recovery.

Shadow Paging is a database recovery technique used to ensure atomicity
and durability of transactions without using logs.
It is a non-logging method that uses a copy-based mechanism to manage
changes to the database. If a failure occurs during transaction execution, the
database can revert to a consistent state using the “shadow” copy.
Key Concepts
 The database is divided into pages (blocks of data).
 There are two page tables:
1. Current Page Table – tracks the pages being used by an ongoing
transaction.
2. Shadow Page Table – tracks the last committed state of the
database.
These tables maintain page mappings from logical pages to physical locations
on disk.

Step-by-Step Process:
1. Start of Transaction:
o A shadow page table is created by copying the current page table.
o This shadow copy is kept unchanged during the transaction.
2. During Transaction:
o Any page updated is written to a new location (new physical
block).
o The current page table is updated to point to the new location.
o The shadow page table still points to the old location.
3. Commit:
o Once the transaction is successful, the current page table is saved
permanently.
o The old shadow page table is discarded.
4. Abort or Crash:
o If the system crashes before the commit, the shadow page table is
used to restore the database to its previous consistent state.
o The pages not committed are discarded because the shadow page
table still points to old (unchanged) versions.
Advantages of Shadow Paging
 No logging required: simpler to implement than log-based recovery.
 Atomic and Durable: either the entire transaction is done or nothing.
 Quick recovery: just discard the current page table and revert to the
shadow page table.

Disadvantages of Shadow Paging

 Copying page tables is expensive, especially for large databases.
 No support for fine-grained concurrency: not suitable for high-
transaction environments.
 Page fragmentation: because updated pages are written to new locations.
 Difficult to implement incremental changes.
Where It Is Used
 Shadow paging is often used in educational systems or simple
databases, but not in modern commercial DBMSs which prefer log-
based recovery (e.g., ARIES) for better concurrency and performance.

Imp. Points
Aspect Shadow Paging Description
Purpose Recovery without logs
Mechanism Uses shadow (backup) page table
Recovery after crash Revert to shadow table
Commit Make current table permanent
Advantages Simple, atomic, fast recovery
Disadvantages Costly page copying, poor concurrency

Log-based Recovery, an essential concept in database management systems

(DBMS) for ensuring data consistency and integrity.
Log-based Recovery is a transaction recovery technique that uses a log file
to record all database operations. It helps restore the database to a consistent
state in the event of a system crash or failure.
The core idea is:
“Write all changes in a log before applying them to the database. If a failure
occurs, use the log to redo or undo transactions.”
Key Terms
Term Description
A sequential record of all transactions and their database
Log File
operations.
UNDO Reversing the effect of an uncommitted transaction.
REDO Reapplying changes of committed transactions.
A point where the system records all committed data to disk,
Checkpoint
simplifying recovery.
Structure of a Log Entry
Each log record typically includes:
<Transaction_ID, Data_Item, Old_Value, New_Value>
Example:
<T1, A, 100, 200> → Transaction T1 changed A from 100
to 200.
Also includes:
 <START T1> → transaction T1 begins.
 <COMMIT T1> or <ABORT T1> → transaction ends with commit or
abort.
How Log-based Recovery Works
1. Before Update (Write-Ahead Logging):
 Log entry is written before the actual database is updated.
 Ensures that recovery can undo or redo changes if needed.
2. On Crash Recovery:
 The system performs:
o UNDO: For all transactions that started but did not commit.
o REDO: For all transactions that committed before the crash.

Recovery Steps
A. Undo Operation
Used for transactions that did not commit.
For each such transaction:
 Retrieve old value from log
 Restore it to the database
B. Redo Operation
Used for transactions that committed.
For each such transaction:
 Retrieve new value from log
 Reapply it to the database

Advantages of Log-based Recovery

 Ensures atomicity and durability of transactions.
 Allows both rollback (undo) and rollforward (redo).
 Suitable for multi-user and multi-transaction environments.
 Works well with concurrent transaction control mechanisms.

Disadvantages
 Log files can grow large in size over time.
 Requires proper log management and storage.
 Slower than shadow paging in very small systems (due to logging
overhead).

Checkpointing in Log-Based Recovery

To make recovery faster, DBMS uses checkpoints.
What is a Checkpoint?
 A point where:
o All committed changes are saved to the database.
 o The log is updated with a <CHECKPOINT> record.
Benefits:
 During recovery, the system can skip log entries before the checkpoint.
Imp. Points Table
Feature Log-Based Recovery
Recovery mechanism Uses log records
Types of actions UNDO and REDO
Logging rule Write-Ahead Logging
Key operations START, COMMIT, ABORT,
Efficiency Good for large and concurrent systems
Checkpointing Used to optimize recovery

Example Log (Crash Happens After T1 Commit, T2 Incomplete)

<START T1>
<T1, X, 100, 200>
<COMMIT T1>
<START T2>
<T2, Y, 50, 80>
... crash ...
On Recovery:
 Redo T1 because it committed.
 Undo T2 because it did not commit.

Triggers
A trigger in a Database Management System (DBMS) is a stored procedure
that automatically executes or fires when a specified event occurs in the
database.
Trigger = Event-driven action in response to INSERT, UPDATE, or
DELETE operations.

Why Are Triggers Created?

Triggers are used for the following reasons:
Purpose Explanation
🔒 Enforce Business Automatically ensure rules like "a salary cannot be
Rules negative."
🔄 Maintain Data Ensure changes in one table reflect in related tables
Integrity (e.g., updating stock when a sale is made).
 Purpose Explanation
🧾 Automatic Log changes in a table to track who modified what and
Auditing when.
📊 Derived Data
Update totals, balances, or summaries automatically.
Maintenance
Trigger alerts when specific events occur (e.g., low
🚨 Event Notification
inventory level).

How Are Triggers Created?

Triggers are created using the SQL CREATE TRIGGER statement.
🔹 Syntax (for most DBMS like MySQL)
CREATE TRIGGER trigger_name
{BEFORE | AFTER} {INSERT | UPDATE | DELETE}
ON table_name
FOR EACH ROW
BEGIN
-- SQL statements (what to do)
END;
Trigger Components
Component Meaning
When to fire the trigger relative to the triggering
BEFORE / AFTER
action.
INSERT / UPDATE /
Type of event that activates the trigger.
DELETE
FOR EACH ROW Trigger executes for each affected row.
BEGIN...END Block to define what the trigger will do.
Example: Logging Employee Updates
Suppose we want to log any salary updates in the employees table.
CREATE TRIGGER log_salary_update
AFTER UPDATE ON employees
FOR EACH ROW
BEGIN
INSERT INTO salary_audit(emp_id, old_salary,
new_salary, change_date)
VALUES (OLD.id, OLD.salary, NEW.salary, NOW());
END;
Explanation:
 AFTER UPDATE → Trigger fires after an update.
 OLD.salary → Original salary before update.
 NEW.salary → New salary after update.
  NOW() → Current timestamp.

Types of Triggers
Type Description
BEFORE INSERT Triggered before data is inserted.
AFTER INSERT Triggered after data is inserted.
BEFORE UPDATE Triggered before data is updated.
AFTER UPDATE Triggered after data is updated.
BEFORE DELETE Triggered before data is deleted.
AFTER DELETE Triggered after data is deleted.

Advantages of Triggers
 Automatic enforcement of rules
 Centralized logic (business rules inside DB)
 Improves consistency
 Reduces application code complexity

Disadvantages
 Hard to debug
 Performance overhead (if too many triggers fire)
 Complex logic may make maintenance difficult
 Implicit behavior may confuse new developers

Imp. Points
Aspect Description
What Stored procedure that runs automatically
When On INSERT, UPDATE, DELETE
Why Enforce rules, track changes, maintain integrity
Syntax CREATE TRIGGER ...
Types BEFORE/AFTER INSERT/UPDATE/DELETE
Example Use Auditing, validation, cascade actions

Active Database
An Active Database is a type of database system that can respond
automatically to specific events and conditions without user intervention.
In traditional databases, actions happen only when explicitly triggered by users
or applications.
In active databases, the database itself can react automatically using rules.
ECA?
ECA stands for:
 E: Event
 C: Condition
 A: Action
Together, they form the rule that defines what to monitor, when to respond, and
how to react.

Structure of an ECA Rule

ON Event
IF Condition
THEN Action
Explanation of Each Component
Component Description Example
A happening that the database A new student is inserted
Event
monitors (e.g., insert, delete, update) into the students table
A Boolean test that must be true for
Condition IF student's age < 18
the action to be executed
What the database should do when
THEN log a message or
Action the event occurs and the condition is
send an alert
true

Example of ECA Rule

Let's say we want to automatically notify if a product’s quantity falls below 10.
Rule:
ON UPDATE of product_quantity
IF NEW.quantity < 10
THEN INSERT INTO restock_alerts(product_id,
alert_date) VALUES (NEW.id, CURRENT_DATE);
This is implemented as a trigger in SQL.

🧾 Use Cases of Active Databases

Application Area Purpose
🔐 Security Alert when unauthorized access is detected
🧾 Auditing Track who changed data and when
🛒 E-commerce Notify low stock or auto-apply discounts
🏥 Healthcare Trigger alerts for critical patient data changes
🔁 Data Automatically propagate changes to other tables or
Synchronization systems
Advantages of Active Databases
 Automates routine tasks
 Enhances security and integrity
 Reduces application-side programming
 Real-time responsiveness
 Supports complex business rules directly in DBMS
Disadvantages
 May increase system complexity
 Difficult to test and debug triggers
 Can impact performance if too many rules fire frequently
 May create unexpected side effects (if rules interact)
Imp. Points
Topic Description
Active Database A database that reacts to events automatically
ECA Rule A rule format: Event → Condition → Action
Event Triggering operation (Insert, Update, Delete)
Condition Boolean logic to test
Action Operation to perform if condition is true
Implementation Usually via Triggers in SQL

Concurrency
Concurrency refers to the ability of a Database Management System
(DBMS) to allow multiple users or transactions to access the same data at
the same time without interfering with each other.
Goal: Ensure correct results even when multiple operations are performed
simultaneously.
Why is Concurrency Important?
In real-world applications like banking, e-commerce, or ticket booking,
multiple users might access or modify the same database records at the same
time.
Concurrency ensures:
 Data consistency
 Integrity
 Correctness of results
 Better system performance and throughput
Concurrency Example
Imagine two users:
 User A is transferring ₹500 from Account 1 to Account 2.
 User B is checking the balance of Account 1 at the same time.
Without concurrency control, User B might see an incorrect balance during the
transfer.
Problems Without Concurrency Control
If proper control mechanisms aren't used, the following problems may arise:
Problem Description
Lost Update Two transactions update the same data; one update is lost.
Dirty Read One transaction reads uncommitted changes of another.
Non-repeatable A row is read twice and gives different results due to another
Read transaction's update.
A query returns different results on re-execution due to
Phantom Read
insertion/deletion by another transaction.
How DBMS Handles Concurrency
✅ Using Concurrency Control Techniques like:
1. Locks (Shared and Exclusive Locks)
2. Timestamp Ordering
3. Optimistic Concurrency Control
4. Validation-Based Protocols
5. Multiversion Concurrency Control (MVCC)
These mechanisms ensure serializability – the idea that the result of concurrent
transactions is the same as if the transactions were executed one after another.

Example: Lock-Based Concurrency Control

Let’s say:
 Transaction A wants to read and update data.
 Transaction B also wants to update the same data.
Using locking, Transaction A locks the data, and Transaction B must wait until
A completes (commit or rollback) before it can proceed. This prevents lost
updates.

Imp. Points
Aspect Description
Simultaneous access to the same data by multiple
Definition
users/transactions
Purpose To maintain consistency, accuracy, and integrity of data
Problems It
Lost updates, dirty reads, phantom reads, etc.
Avoids
Techniques Locking, Timestamp ordering, MVCC, etc.
Importance Ensures database correctness in multi-user environments
Immediate and Deferred Updates
In the context of database recovery, these two techniques define when the
changes made by a transaction are written to the database (i.e., when the
database is updated with new values).

⚡ 1. Immediate Update
🔹 Definition:
In immediate update, changes made by a transaction are applied to the
database as soon as they are made, even before the transaction commits.
✅ Changes are written to the database during the execution of the transaction.
🔒 Requirements:
 To ensure recovery from crashes, a log (write-ahead logging) must be
maintained.
 The log is written before the actual database is updated (Write-Ahead
Logging - WAL).
🔁 Recovery Mechanism:
 Uses UNDO to rollback the changes of uncommitted transactions.
 May also use REDO for committed transactions (if needed).
✅ Example:
1. T1 starts.
2. T1 updates a balance from ₹1000 to ₹900 → DB is updated immediately.
3. T1 crashes before commit.
4. System uses log to UNDO the update.

2. Deferred Update
🔹 Definition:
In deferred update, no changes are made to the database until the
transaction reaches the commit point. All changes are kept in a buffer or log
during the transaction.
✅ Actual database is updated only after the transaction commits.
🔒 Requirements:
 Only REDO operations are needed during recovery (no UNDO).
 Simple recovery, since uncommitted transactions never modify the
database.
🔁 Recovery Mechanism:
 On crash: only redo changes of committed transactions.
 No undo is required because uncommitted changes never reached the
database.
✅ Example:
1. T1 starts.
 2. T1 plans to update balance from ₹1000 to ₹900 → change stored in
buffer.
3. T1 crashes before commit → no need to undo, as DB was never
modified.

Key Differences Between Immediate and Deferred Update

Feature Immediate Update Deferred Update
When DB is After transaction
During transaction execution
updated commits
WAL (write-ahead log) is Log is used but only for
Log Requirement
mandatory redo
Recovery Actions UNDO and REDO required Only REDO required
Complexity of More complex (has to undo Simpler (no undo
Recovery uncommitted data) needed)
Can be slower due to frequent Generally faster due to
Performance
disk writes batch commit
Banking systems with high
Example Use Case Batch processing systems
durability needs
Imp. Points
 Immediate Update: Database is updated as the transaction progresses.
Needs UNDO and REDO for recovery.
 Deferred Update: Database is updated only after commit. Easier
recovery – only REDO is needed.

Normalization
Normalization is the process of organizing data in a relational database to:
 Reduce data redundancy (duplicate data)
 Avoid insertion, update, and deletion anomalies
 Improve data integrity
It involves dividing large tables into smaller, related ones and defining
relationships among them.
Goals of Normalization
 Minimize redundancy
 Ensure data consistency
 Make the database efficient for updates and queries
Types of Normal Forms
Here are the most common normal forms, explained with examples:

🧩 Unnormalized Form (UNF)

Data is stored without structure; may contain repeating groups.
StudentID Name Courses
101 Ramesh Math, Science
102 Suresh English

1️⃣ First Normal Form (1NF)

Rule: Eliminate repeating groups; ensure that each cell contains atomic
(indivisible) values.
Convert UNF to 1NF:
StudentID Name Course
101 Ramesh Math
101 Ramesh Science
102 Suresh English

2️⃣ Second Normal Form (2NF)

Rule: Must be in 1NF and remove partial dependencies
(Non-prime attributes should depend on the whole primary key, not part of it).
Example Table in 1NF:
StudentID Course Instructor
101 Math Prof. A
101 Science Prof. B
102 English Prof. C
Here, (StudentID, Course) is the composite key, but Instructor depends
only on Course → partial dependency.
Split into 2 tables to get 2NF:
Student-Course Table:
StudentID Course
101 Math
101 Science
102 English
Course-Instructor Table:
Course Instructor
Math Prof. A
Science Prof. B
English Prof. C
3️⃣ Third Normal Form (3NF)
Rule: Must be in 2NF and remove transitive dependencies
(A non-key attribute should not depend on another non-key attribute)
Example in 2NF:
StudentID Name Department HOD
101 Ramesh Physics Dr. Roy
102 Suresh Chemistry Dr. Rao
Here, HOD depends on Department, not directly on StudentID →
transitive dependency.
Split into:
Student Table:
StudentID Name Department
101 Ramesh Physics
102 Suresh Chemistry
Department Table:
Department HOD
Physics Dr. Roy
Chemistry Dr. Rao

4️⃣ Boyce-Codd Normal Form (BCNF)

Rule: Every determinant must be a candidate key. It's a stricter version of
3NF.
Example violating BCNF:
Professor Course Department
Prof. A Math Science
Prof. B Physics Science
Assume:
 A professor teaches only one department.
 A course may be taught by more than one professor.
Here, Professor → Department (Professor determines Department), but
Professor is not a candidate key, violating BCNF.
To normalize:
Professor Table:
Professor Department
Prof. A Science
Prof. B Science
Professor-Course Table:
Professor Course
Prof. A Math
Prof. B Physics

✅ Imp. Points Table

Normal
Condition Purpose
Form
Atomic values (no repeating
1NF Basic structure
groups)
Remove redundancy from
2NF 1NF + No partial dependency
composite keys
3NF 2NF + No transitive dependency Remove indirect dependencies
3NF + Every determinant is a
BCNF Handle special cases of 3NF
candidate key

Different types of database failures

A database failure refers to an event that causes a loss of data, corruption, or
interruption in service. It may result from hardware issues, software bugs, or
human errors.
To maintain data consistency and reliability, a recovery system is used to
restore the database to a consistent state after failure.

🔴 Types of Database Failures

Failures in a database system can be broadly categorized into the following:

1️⃣ Transaction Failure

Cause: When a specific transaction fails to execute successfully.
Reasons:
 Logical errors (e.g., division by zero)
 Invalid input data
 Deadlocks
 Explicit user-initiated rollback
Impact: Only the affected transaction is rolled back; other transactions
continue.
Recovery: Use Undo (Rollback) mechanism to restore database to the state
before the transaction started.

2️⃣ System Crash (System Failure)

Cause: The operating system, DBMS, or hardware crashes during transaction
execution.
Reasons:
 Power failure
 OS crash
 Software bugs
Impact:
 Some transactions might not commit.
 Main memory data is lost.
 Disk data is intact.
Recovery:
 Undo uncommitted transactions.
 Redo committed transactions using logs.

3️⃣ Media Failure (Disk Failure)

Cause: Failure of storage media (e.g., hard disk or SSD) leading to loss of
stored data.
Reasons:
 Disk head crash
 Bad sectors
 Drive corruption
Impact: Permanent loss of data on the disk.
Recovery:
 Use backups and logs stored on separate storage media.
 Restore the latest backup and redo committed transactions from the logs.

4️⃣ Application Software Failure

Cause: Errors in application programs that access the database.
Examples:
 Bugs in front-end code
 Wrong queries or logic
 Violations of constraints
Impact: May lead to invalid data being inserted or updated.
Recovery:
 Use application-level logging.
 Validate and rollback if needed.

5️⃣ Concurrency Failure

Cause: Errors due to simultaneous execution of multiple transactions leading
to inconsistency.
Examples:
 Deadlocks
 Lost updates
 Inconsistent reads
Recovery:
 Use concurrency control mechanisms such as:
o Locking
o Timestamp ordering
o Multiversion concurrency control (MVCC)

6️⃣ Human Error

Cause: Mistakes by users or administrators.
Examples:
 Deleting important data
 Dropping tables accidentally
 Incorrect SQL commands
Impact: May lead to partial or total data loss.
Recovery:
 Use backups and audit trails
 Implement proper user permissions and confirmation prompts

7️⃣ Natural Disasters and Catastrophic Failures

Cause: Earthquakes, fires, floods, etc., destroying data centers.
Impact: Entire system including hardware, software, and data can be lost.
Recovery:
 Maintain off-site backups
 Use disaster recovery plans
 Cloud-based backups and failover systems

🧾 Imp. Points Table

Failure Type Cause Recovery Strategy
Transaction Failure Logical errors, deadlocks Undo transaction using logs
Undo & Redo using log
System Crash Power failure, OS crash
records
Disk corruption, head Restore from backup, redo
Media Failure
crash committed logs
Application Application bugs or logic Validate, rollback incorrect
Software Fail errors changes
Concurrency Apply concurrency control
Deadlocks, race conditions
Failure mechanisms
Mistaken
Human Error Use audit logs, backups
deletions/commands
Off-site backups and disaster
Natural Disasters Fire, flood, earthquakes
recovery