Transaction Management in Databases

Introduction to Transactions
A transaction in a database is a sequence of operations that perform a single logical function
in a database application. It consists of one or more SQL statements, such as INSERT,
UPDATE, DELETE, or SELECT, that must be executed in a way that ensures consistency,
correctness, and reliability. Transactions are crucial for maintaining database integrity,
particularly in multi-user environments where multiple transactions may occur
simultaneously. A well-implemented transaction management system ensures that even if a
failure occurs (such as a system crash, power outage, or software error), the database remains
in a consistent state.

For example, consider a banking system where a user transfers ₹10,000 from Account A to
Account B. This transaction involves two operations: first, deducting ₹10,000 from Account
A, and second, adding ₹10,000 to Account B. If both operations are successfully executed,
the transaction is committed, meaning the changes are permanently saved in the database.
However, if any issue arises during the execution (e.g., a system failure after deducting the
amount but before crediting it), the transaction must be rolled back, undoing the deduction to
ensure that no inconsistent state exists.

ACID Properties of Transactions

To guarantee database reliability and prevent inconsistencies, transactions adhere to the
ACID properties—Atomicity, Consistency, Isolation, and Durability.

1.​ Atomicity ensures that a transaction is treated as a single unit of work, which either
completes entirely or does not occur at all. If any part of the transaction fails, all
changes made during the transaction are undone, restoring the database to its original
state. For instance, in the banking example, if the credit operation to Account B fails,
the deduction from Account A must also be reversed.
2.​ Consistency ensures that a database transitions from one valid state to another valid
state after a transaction. It prevents any operation from leaving the database in an
incorrect or corrupt state. For example, if a sales transaction updates both the
inventory and the revenue records, both changes must be executed correctly to
maintain database consistency.
3.​ Isolation ensures that concurrent transactions do not interfere with each other. When
multiple transactions execute simultaneously, they must be isolated to prevent
conflicts. Consider an e-commerce website where two users attempt to purchase the
last item in stock at the same time—without proper isolation, both transactions might
succeed, leading to an incorrect inventory count.
4.​ Durability guarantees that once a transaction is committed, its effects are permanently
stored in the database, even in the event of a system crash. For instance, once an
 airline ticket is booked and payment is processed, the reservation must persist in the
database, even if the system crashes immediately after the confirmation.

Transaction States
A transaction progresses through multiple states during its execution:

1.​ Active State – The transaction starts and performs operations such as data retrieval or
modification.
2.​ Partially Committed State – The transaction has completed all its operations but has
not yet been permanently saved to the database.
3.​ Committed State – The transaction has successfully completed, and all changes are
made permanent.
4.​ Failed State – If an error occurs before a transaction commits, it enters the failed state.
5.​ Aborted State (Rollback) – The system undoes all changes made by the failed
transaction and restores the database to its previous consistent state.

For example, in an online shopping system, when a customer adds items to their cart and
proceeds to checkout, a transaction starts. If the payment succeeds, the transaction commits,
confirming the order. However, if the payment fails, the transaction rolls back, ensuring the
order is not placed incorrectly.

Concurrency Control in Transactions

Concurrency control mechanisms ensure that multiple transactions executing simultaneously
do not compromise data integrity. Without proper concurrency control, issues such as lost
updates, dirty reads, non-repeatable reads, and phantom reads can arise.

●​ Lost Updates occur when two transactions modify the same data simultaneously, and
one update is lost. Suppose two users attempt to update a product’s stock at the same
time—without proper control, one update may overwrite the other.
●​ Dirty Reads happen when a transaction reads uncommitted changes made by another
transaction. For example, if a finance system allows users to view their updated salary
before it is officially processed, incorrect data may be displayed if the salary update is
later rolled back.
●​ Non-Repeatable Reads occur when a transaction reads the same data twice, but
another transaction modifies it between reads, leading to inconsistencies.
●​ Phantom Reads occur when a transaction retrieves a set of records multiple times, but
another transaction inserts or deletes rows before the second read, causing different
results.

Deadlocks in Transactions
A deadlock occurs when two or more transactions wait indefinitely for each other to release
resources.

For example, consider two transactions:

●​ T1 locks Account A and waits for Account B.

●​ T2 locks Account B and waits for Account A.

Since both transactions are waiting for each other to release locks, neither can proceed,
causing a deadlock.

To prevent deadlocks, databases implement deadlock detection algorithms or deadlock

prevention techniques such as timeouts (forcing transactions to abort if they wait too long)
and priority-based execution (allowing older transactions to proceed first).

Transaction Recovery
Transaction recovery ensures that a database remains consistent even in case of failures.
There are several types of failures:

1.​ System Failures – Power outages, software crashes, or memory failures.

2.​ Disk Failures – Hard drive crashes, corrupt files, or disk malfunctions.
3.​ Transaction Failures – User errors, constraint violations, or deadlock resolution.

To recover from failures, databases use techniques like:

●​ Deferred Update (No Undo, Only Redo) – Changes are not applied until the
transaction commits, ensuring that only committed transactions are saved.
●​ Immediate Update (Undo & Redo) – Changes are applied immediately but can be
undone if a transaction fails.
●​ Checkpointing – Periodic backups of the database state to speed up recovery after a
failure.

For example, if a hotel booking system crashes, checkpointing ensures that only transactions
recorded before the last checkpoint are reprocessed, reducing recovery time.

Database Design and ER Model

Overview of Database Design
Database design is the process of structuring data efficiently to store, retrieve, and manage it
in a database system. A well-designed database eliminates redundancy, ensures data
consistency, and improves performance.
Consider a Library Management System in a university. The library database must store
details about books, students, and book borrowing history. Without proper design, a student
could borrow a book without a record of the transaction, or the same book could have
multiple inconsistent entries. Database design ensures proper structuring, avoids
inconsistencies, and allows for smooth management of library operations.
Imagine you are designing a database for a school management system. If the design is poor,
you may end up with duplicated student records, incorrect grades, or difficulty in finding
information. A properly designed database ensures that student records, teacher information,
and course enrollments are correctly managed.
Steps in Database Design
1.​ Requirement Analysis – What data do we need? (e.g., Students, Teachers, Courses).
2.​ Conceptual Design – Create a rough sketch using an Entity-Relationship (ER) Model.
3.​ Logical Design – Convert the ER Model into database tables (relations).
4.​ Physical Design – Implement the database in a DBMS (e.g., MySQL, PostgreSQL).
Why Good Database Design Matters?
●​ Avoids redundancy → Instead of storing the same student’s name in multiple places,
use a single table.
●​ Ensures data consistency → No two records should contradict each other.
●​ Improves efficiency → Quick data retrieval for reports, searches, and queries.

Entity-Relationship (ER) Model

The ER Model is a conceptual framework used to design databases. It visually represents
real-world entities, their attributes, and relationships before creating actual database tables.
The following diagram showcases two entities - Student and Course, and their relationship.
Student entity possesses attributes - Stu_Id, Stu_Name & Stu_Age. The course entity has
attributes such as Cou_ID & Cou_Name.
Example: ER Model in a Hospital System
Consider a hospital where patients visit doctors. We have:
●​ Patient (Entity): Attributes → Patient_ID, Name, Age.
●​ Doctor (Entity): Attributes → Doctor_ID, Name, Specialty.
●​ Appointment (Relationship): A patient books an appointment with a doctor.

ER Model for an Online Shopping System

For an e-commerce website (like Amazon):
●​ Customers → Attributes: Customer_ID, Name, Email.
●​ Products → Attributes: Product_ID, Name, Price.
●​ Orders → Relationship between Customers and Products.

📌 Reference: Elmasri & Navathe, Fundamentals of Database Systems

Entities in the ER Model
An entity is any object in the real world that can be uniquely identified.
Examples of Entities in Different Domains
1.​ University System
o​ Student (Entity) → Attributes: Student_ID, Name, Course.
o​ Professor (Entity) → Attributes: Professor_ID, Name, Department.
o​ Class (Entity) → Attributes: Class_ID, Subject, Time.
2.​ Banking System
o​ Customer (Entity) → Attributes: Customer_ID, Name, Account_Number.
 o​ Account (Entity) → Attributes: Account_Number, Balance.
o​ Transaction (Entity) → Attributes: Transaction_ID, Date, Amount.
3.​ Supermarket Billing System
o​ Product (Entity) → Attributes: Product_ID, Name, Price.
o​ Cashier (Entity) → Attributes: Cashier_ID, Name.
o​ Bill (Entity) → Attributes: Bill_ID, Date, Total_Amount.
Types of Entities
1.​ Strong Entities – Entities with a unique identifier (Primary Key).
o​ Example:

▪​ In a university, a Student has a unique Student_ID.

▪​ A Book has a unique Book_ID.

2.​ Weak Entities – Entities that depend on another entity for identification.
o​ Example:

▪​ A Book Copy does not have a unique ID but is identified using

Book_ID + Copy_Number.

▪​ A Dependent in an employee database does not have a unique ID but is

linked to the Employee_ID of their guardian.
📌 ER Diagram Representation: Weak entities are represented with double rectangles.
Relationships in the ER Model
A relationship represents an association between two or more entities.
Common Types of Relationships
1.​ One-to-One (1:1)
o​ Example: A Country has one President.
o​ ER Diagram Representation: [Country] ---- (leads) ----> [President]
2.​ One-to-Many (1:M)
o​ Example: A Professor teaches multiple Courses.
o​ ER Diagram Representation: [Professor] ---- (teaches) ----> [Course]
3.​ Many-to-Many (M:N)
o​ Example: A Student enrolls in multiple Courses, and each Course has multiple
Students.
o​ ER Diagram Representation: [Student] ---- (enrolls) ----> [Course]
Constraints in the ER Model
Constraints in the ER (Entity-Relationship) model define rules and restrictions that the data
must follow to ensure integrity, consistency, and accuracy in a database. These constraints
help maintain valid relationships between entities and prevent invalid data entries. There are
several types of constraints, including Primary Key, Foreign Key, Referential Integrity, and
Participation Constraints, each serving a specific purpose in database design. Let’s explore
them in detail with examples.
1. Primary Key Constraint
A Primary Key is a unique identifier for each record in a table. No two rows can have the
same primary key value, and it cannot be NULL. This ensures that each record is distinct and
can be uniquely identified.
📌 Example: Consider a Student Database where each student must have a unique
Student_ID.
Student_ID (PK) Name Age Course
101 Alice 20 Computer Science
102 Bob 21 Mechanical Engineering
103 Charlie 22 Civil Engineering
Here, Student_ID is the Primary Key, ensuring that no two students have the same ID. If we
try to insert another record with Student_ID = 101, the database will reject it to maintain
uniqueness.
2. Foreign Key Constraint
A Foreign Key is a field in one table that references the Primary Key in another table. It
establishes a relationship between two tables and ensures referential integrity (i.e., records in
one table must match valid records in another).
📌 Example: Consider a Student Enrollment System, where students enroll in courses.
Enrollment_ID (PK) Student_ID (FK) Course_ID
1 101 CS101
2 102 ME102
3 103 CE103
4 101 ME102
Here, Student_ID in the Enrollment Table is a Foreign Key referencing the Student_ID in the
Students Table. This ensures that every enrolled student exists in the Students Table. If we try
to insert a record with Student_ID = 999, which does not exist in the Students Table, the
database will reject it.
3. Referential Integrity Constraint
Referential Integrity ensures that a foreign key in one table must always reference a valid
primary key in another table. This means we cannot delete a record in the referenced table if
dependent records exist in another table.
📌 Example: Consider an E-Commerce System, where orders reference customers.
Customers Table
Customer_ID (PK) Customer_Name
1 Alice
2 Bob
3 Charlie
Orders Table
Order_ID (PK) Customer_ID (FK) Order_Amount
1001 1 $500
1002 2 $250
If we try to delete Customer_ID = 1 from the Customers Table, it will cause a problem
because Order_ID = 1001 references Customer_ID = 1 in the Orders Table. The database will
prevent the deletion unless we delete or update the dependent records first.
4. Participation Constraints- Not Null Constraint
Participation Constraints define whether an entity’s participation in a relationship is
mandatory (Total Participation) or optional (Partial Participation).
Total Participation
In Total Participation, every instance of an entity must participate in the relationship.
📌 Example: Every Employee must be assigned to a Department in a company.
Employees Table
Employee_ID (PK) Employee_Name Department_ID (FK)
101 Alice D1
102 Bob D2
103 Charlie D1
Here, every employee must belong to a department, meaning Department_ID cannot be
NULL.
Partial Participation
In Partial Participation, an entity may or may not participate in the relationship.
📌 Example: Not all customers may have a credit card.
Customers Table
Customer_ID (PK) Customer_Name
1 Alice
2 Bob
3 Charlie
Credit Cards Table
Card_Number (PK) Customer_ID (FK)
1111-2222-3333-4444 1
5555-6666-7777-8888 3
Here, not all customers have a credit card. For example, Customer_ID = 2 (Bob) does not
have a record in the Credit Cards Table, making it a case of Partial Participation.
📌 Reference: Silberschatz, Korth & Sudarshan, Database System Concepts
UNIQUE
ER Diagrams
An ER Diagram is a graphical representation of entities, attributes, and relationships.
Symbols in ER Diagrams
●​ Rectangle → Represents an Entity (e.g., Student).
●​ Oval → Represents an Attribute (e.g., Name).
●​ Diamond → Represents a Relationship (e.g., Enrolls).
●​ Lines → Connect entities, attributes, and relationships.
📌 Diagram Reference:
●​ Elmasri & Navathe, Fundamentals of Database Systems
●​ Lucidchart ER Diagram Example

Weak Entity Sets

A Weak Entity Set does not have a unique identifier and depends on a Strong Entity.
Examples of Weak Entities
1.​ Hospital System
o​ Strong Entity: Doctor (Doctor_ID).
o​ Weak Entity: Patient Visit Record (depends on Doctor).
2.​ Library System
o​ Strong Entity: Book (Book_ID).
o​ Weak Entity: Book Copy (Copy_Number depends on Book_ID).

📌 Representation in ER Diagrams:
●​ Double Rectangle → Weak Entity.
●​ Double Diamond → Identifying Relationship.
In the example below, school is a strong entity because it has a primary key attribute - school
number. Unlike school, the classroom is a weak entity because it does not have any primary
key and the room number here acts only as a discriminator.

Codd’s 12 Rules for Relational Databases

Edgar F. Codd, the father of relational databases, proposed 12 rules to define what qualifies
as a relational database management system (RDBMS). These rules ensure that databases are
structured, consistent, and efficient in managing data. Though no database fully complies
with all 12 rules, they serve as a benchmark for designing relational database systems.

●​ Rule 0: Foundation Rule

A system must qualify as a relational database and use relational principles to manage
data. If a system doesn’t follow relational principles, it cannot be considered an
RDBMS.

●​ Rule 1: Information Rule

All information must be stored in tables, including metadata (data about data). This
ensures that everything, including table structures and relationships, is represented in

📌
a structured format.​
Example: A student database stores all student details in a "Students" table instead
of using separate files.

●​ Rule 2: Guaranteed Access Rule

Each data element must be accessible via a unique combination of table name,

📌
primary key, and column name.​
Example: A bank system retrieves a customer’s balance using the Account_ID
and Balance column instead of searching through unstructured records.

●​ Rule 3: Systematic Treatment of NULL Values

NULL values must be systematically treated as missing or unknown data, not as

empty or zero values.​
 📌 Example: A salary column in an employee table can have a NULL value if the
salary is not yet assigned, instead of using "0" (which may indicate a real salary).

●​ Rule 4: Dynamic Online Catalog

A relational database must have an online data dictionary (catalog) that is accessible

📌
using standard query language (SQL).​
Example: In SQL databases, users can query system tables like
INFORMATION_SCHEMA.TABLES to retrieve metadata about tables.

●​ Rule 5: Comprehensive Data Sub-language Rule

The database must support a single, consistent language for data definition,

📌
manipulation, and control, such as SQL.​
Example: SQL allows users to create tables (CREATE TABLE), insert data
(INSERT INTO), retrieve data (SELECT), and enforce security (GRANT/REVOKE).

●​ Rule 6: View Updating Rule

📌
Views (virtual tables) must be updatable like base tables, ensuring data consistency.​
Example: A view showing employee details should allow updates that reflect in
the underlying "Employees" table.

●​ Rule 7: High-Level Insert, Update, and Delete

The system must support set-based operations, allowing modifications on multiple

📌
rows at once instead of handling records individually.​
Example: A university database should allow enrolling multiple students in a
course with a single INSERT query rather than inserting each record separately.

●​ Rule 8: Physical Data Independence

📌
The database’s logical structure must remain unaffected by physical storage changes.​
Example: Moving a database from an HDD to an SSD should not require
rewriting queries or modifying application logic.

●​ Rule 9: Logical Data Independence

Changes in logical schema (table structure) should not require modifications in

📌
applications that access the database.​
Example: Adding a "Middle_Name" column in a "Customers" table should not
break existing queries fetching "First_Name" and "Last_Name."
 ●​ Rule 10: Integrity Independence

Integrity constraints (like primary keys, foreign keys, and data validation rules) must

📌
be stored in the database and not in the application code.​
Example: A banking system should enforce "Balance cannot be negative" at the
database level instead of relying on application logic.

●​ Rule 11: Distribution Independence

The database should work the same way, whether data is stored in a single location

📌
(centralized database) or multiple locations (distributed database).​
Example: An airline reservation system with databases across multiple cities
should function seamlessly, regardless of where a user accesses it.

●​ Rule 12: Non-Subversion Rule

The database must prevent bypassing security rules through low-level access

📌
methods. All operations must go through the defined relational model.​
Example: A user should not be able to bypass access controls by directly
modifying data files instead of using authorized SQL queries.

Codd’s 12 rules provide a foundation for designing relational database systems that are
efficient, scalable, and consistent. While no RDBMS follows all 12 rules perfectly, modern
relational databases like MySQL, PostgreSQL, Oracle, and SQL Server adhere to most of
these principles. Following these rules ensures data integrity, security, and ease of access,
making relational databases the standard for data management across industries.