A Complete Guide to Serializability in DBMS

Imagine you and a friend share a bank account with ₹10,000. At the same time, you withdraw ₹2,000 from an ATM while your friend withdraws ₹3,000 using the mobile app. If both actions read the same balance, the system may incorrectly approve both, leaving the wrong final amount. This is a data consistency issue. 

In this blog, you will learn about serializability in DBMS, the rule that keeps transactions reliable and prevents such errors. You’ll see how it works, the types (conflict serializability in DBMS and view serializability in DBMS), why it matters, and examples to make the idea clear. 

Master database management and more with our Online Data Science Course—your gateway to a data-driven career! 

What is Serializability in DBMS? 

To understand serializability in DBMS, you first need to know about transactions and schedules. A transaction is a single logical unit of work, which may include one or more operations like reading, writing, or updating data. For example, transferring money involves debiting one account (a write operation) and crediting another (another write operation). Transactions follow ACID properties (Atomicity, Consistency, Isolation, Durability) to ensure they are reliable. 

Take your data expertise to the next level with these top AI and Data Science programs: 

• Master of Science in AI & Data Science – O.P. Jindal Global University 
• Master’s in Data Science – LJMU 
• PG Diploma in Machine Learning & AI – IIIT Bangalore 

A schedule is the order in which the operations of multiple transactions are executed. There are two main types of schedules: 

1. Serial Schedule: Transactions are executed one after another, in a sequence. There is no overlap. If you have Transaction 1 (T1) and Transaction 2 (T2), a serial schedule will execute all of T1 first, and then all of T2, or vice versa. 

Advantage: This method is simple and guarantees data consistency. There is no chance of interference. 

Disadvantage: It is very slow. The system's resources are not used efficiently, as only one transaction runs at a time. 

Also Read: 15 Disadvantages of DBMS (Database Management System) 

Example of a Serial Schedule: 

2. Non-Serial (or Concurrent) Schedule: Operations from multiple transactions are interleaved. This means the system can switch between transactions to improve performance and resource utilization. 

Advantage: This method is much faster and more efficient. 

Disadvantage: It can lead to data inconsistency if not managed correctly. 

Example of a Non-Serial Schedule: 

Now, we can define serializability. A non-serial schedule is considered serializable if its outcome is equivalent to the outcome of some serial schedule. In simple terms, serializability in DBMS is a property that allows you to get the high performance of a concurrent schedule while ensuring the result is just as correct as if the transactions had run one by one. It is the best of both worlds. 

Also Read: What is Normalization in DBMS? 1NF, 2NF, 3NF 

Why is Serializability Important for Data Consistency? 

Running transactions concurrently without proper control can create serious problems. Serializability is important because it is the highest level of isolation and directly prevents these issues, ensuring the database remains in a consistent state. Let's look at the problems that occur when a schedule is not serializable. 

1. Lost Update Problem 

This happens when two transactions read the same data item and then both update it. The second update overwrites the first one, causing the first update to be "lost." 

Example: 

Imagine a product inventory count is 50. 

• T1 (Sale): Reads inventory (50). 
• T2 (Restock): Reads inventory (50). 
• T1: Calculates new inventory (50 - 5 = 45) and writes 45 to the database. 
• T2: Calculates new inventory (50 + 20 = 70) and writes 70 to the database. 

The final inventory should be 65 (50 - 5 + 20). But because T2's writing happened last, the final value is 70. T1's update was lost. A serializable schedule would prevent this. 

2. Dirty Read (Uncommitted Read) Problem 

This occurs when one transaction reads data that has been written by another transaction but has not yet been committed. If the first transaction fails and rolls back, the second transaction is left with "dirty" data that technically never existed. 

Example: 

• T1: Updates an employee's salary from ₹50,000 to ₹60,000. 
• T2: Reads the employee's new salary (₹60,000) to calculate annual bonuses. 
• T1: Fails due to an error and rolls back. The salary reverts to ₹50,000. 

Now, T2 has already used the ₹60,000 figure to perform its calculations, leading to incorrect bonuses. The data T2 read was "dirty." 

Also Read: What is Data Model in DBMS? What is RDBMS? 

3. Incorrect Summary Problem 

This problem arises when one transaction is calculating an aggregate function (like SUM or AVG) on a set of data while another transaction is updating that same data. The summary calculation ends up using a mix of old and new values, producing an incorrect result. 

Example: 

• T1: Starts calculating the total balance of three accounts: A (₹1000), B (₹2000), and C (₹3000). It reads A and B, getting a running total of ₹3000. 
• T2: Transfers ₹500 from C to A. It debits C (now ₹2500) and credits A (now ₹1500). 
• T1: Reads account C (now ₹2500) and adds it to its running total. 

T1's final total is ₹1000 (old A) + ₹2000 (old B) + ₹2500 (new C) = ₹5500. The actual total should always be ₹6000. The summary is incorrect. Ensuring serializability in DBMS prevents these concurrency-related anomalies. 

You may also read this: Relational DBMS 

Types of Serializability: Conflict vs. View 

There are two main types of serializability that a DBMS can use to check if a concurrent schedule is correct. Both aim for the same goal, equivalent to a serial schedule, but they use different rules. 

Understanding Conflict Serializability in DBMS 

This is the more common and stricter type of serializability. A schedule is considered conflict serializable if it can be turned into a serial schedule by swapping its non-conflicting operations. 

Two operations are said to be conflicting if they meet all three of these conditions: 

1. They belong to different transactions. 
2. They access the same data item. 
3. At least one of them is a WRITE operation. 

Here is a simple breakdown of conflicts: 

To test for conflict serializability in DBMS, you can use a Precedence Graph. Here is how it works: 

• Create a node for each transaction in the schedule. 
• Draw a directed edge from T1 to T2 if an operation in T1 conflicts with and executes before an operation in T2. 
• After drawing all such edges, check the graph. If the graph contains a cycle, the schedule is not conflict serializable. If the graph is acyclic (has no cycles), it is conflict serializable. 

Example: 

Consider this schedule S: 

1. T2:R(A) and T1:W(A): Conflict. T2 reads before T1 writes. Draw an edge T2 -> T1. 
2. T1:R(A) and T2:W(A): Conflict. T1 reads before T2 writes. Draw an edge T1 -> T2. 

The precedence graph has a cycle (T1 -> T2 and T2 -> T1). Therefore, this schedule is not conflict serializable. 

Also Read: Structure of Database Management System 

Exploring View Serializability in DBMS 

This type is less strict and more general than conflict serializability. It has a broader definition of equivalence, allowing for more schedules to be considered serializable. A schedule S is view serializable if it is view equivalent to some serial schedule S'. 

Two schedules, S1 and S2, are view equivalent if they satisfy these three conditions: 

1. Initial Read: If a transaction reads the initial value of a data item in S1, it must also read the initial value of that same data item in S2. 
2. Updated Read: If a transaction T1 reads a value that was written by another transaction T2 in S1, it must read the value written by T2 in S2 as well. 
3. Final Write: The transaction that performs the final write on a data item in S1 must also be the transaction that performs the final write on that item in S2. 

Every conflict serializable schedule is also view serializable. However, a schedule can be view serializable but not conflict serializable. This usually happens in cases involving "blind writes," where a transaction writes a value without reading it first. Checking for view serializability in DBMS is computationally harder, which is why most systems use protocols that ensure conflict serializability instead. 

Also Read: Relational Database vs Non-Relational Databases 

How Do Databases Achieve Serializability? 

Databases do not check every schedule on the fly. Instead, they use concurrency control protocols to ensure that any schedule they produce is guaranteed to be serializable. These protocols are the rules that transactions must follow. 

1. Lock-Based Protocols 

This is the most common approach. Transactions must acquire a "lock" on a data item before they can access it. 

• Shared Lock (S-lock): Allows a transaction to read data. Multiple transactions can hold a shared lock on the same item simultaneously. 
• Exclusive Lock (X-lock): Allows a transaction to read and write data. Only one transaction can hold an exclusive lock on an item at any time. 

The most popular lock-based protocol is Two-Phase Locking (2PL). It divides a transaction's execution into two phases: 

• Growing Phase: The transaction can acquire locks but cannot release any. 
• Shrinking Phase: The transaction can release locks but cannot acquire any new ones. 

This protocol guarantees conflict serializability in DBMS, but it can lead to deadlocks, where two transactions are waiting for each other to release a lock. 

Also Read: Lock Based Protocol in DBMS 

2. Timestamp-Based Protocols 

This protocol uses timestamps to avoid deadlocks. Each transaction is assigned a unique timestamp when it starts. The DBMS compares the timestamp of a transaction with the read/write timestamps of the data item it wants to access. If a transaction tries to perform an operation that violates the timestamp order, it is aborted and restarted with a new timestamp. 

3. Optimistic Protocols (Validation Based) 

This protocol is based on the assumption that conflicts are rare. Transactions are allowed to execute without any checks. When a transaction is ready to commit, it enters a validation phase. The DBMS checks if its operations conflicted with any other committed transactions. If a conflict is found, the transaction is rolled back. Otherwise, it is committed. This works well in systems with low data contention. 

Also Read: Transaction in DBMS 

Conclusion 

The concept of serializability in DBMS is fundamental to creating reliable applications. It provides the theoretical foundation for concurrency control, allowing databases to deliver high performance without sacrificing the integrity of your data. By understanding how serial schedules and their concurrent equivalents work, you can better appreciate the complex but crucial work happening inside a DBMS to keep your data safe and consistent. 

Boost your career with our popular Software Engineering courses, offering hands-on training and expert guidance to turn you into a skilled software developer.

Explore our Popular Software Engineering Courses

Master in-demand Software Development skills like coding, system design, DevOps, and agile methodologies to excel in today’s competitive tech industry.

In-Demand Software Development Skills

Stay informed with our widely-read Software Development articles, covering everything from coding techniques to the latest advancements in software engineering.

Read our Popular Articles related to Software