What Are Schedules and Serializability?

In a database system, multiple users or programs (called transactions) often try to read or write
data at the same time. A schedule is the order in which the operations (like reading or writing
data) from these transactions are executed. To ensure the database stays correct and
consistent, we need to make sure these schedules produce the same results as if the
transactions ran one after another, without overlapping. This is where serializability comes in.
Serializable schedules are those that, even if operations from different transactions are mixed
(interleaved), give the same final result as a serial schedule—where transactions run one at a
time, in sequence, with no overlap.
Key Terms Made Simple
1. Transaction: A set of operations (e.g., reading or writing data) that must be completed
as a single unit. For example, booking an airline ticket involves checking seat availability,
reserving a seat, and updating the database.
2. Serial Schedule: Transactions run one after another, with no mixing of their operations.
Example:
o Transaction T1 (book a seat) finishes completely, then Transaction T2 (book
another seat) starts.
o This is like two people waiting in line at a ticket counter, one finishing before the
next starts.
3. Non-serial Schedule: Operations from different transactions are interleaved (mixed).
Example:
o T1 starts booking a seat, then T2 starts, then T1 continues, and so on.
o This is like two people shouting their requests at the ticket counter at the same
time, with the clerk handling them in a mixed order.
4. Serializable Schedule: A non-serial schedule that gives the same result as a serial
schedule. It’s “correct” because the database ends up in the same state as if the
transactions ran one at a time.
5. Conflict: Two operations conflict if:
o They are from different transactions.
o They access the same data item.
o At least one is a write operation.
o Example: T1 wants to write to X, and T2 wants to read X. The order matters
because T2 might read the wrong value if T1 writes after T2 reads.
Why Serial Schedules Aren’t Practical
Running transactions one at a time (serial schedules) is safe but slow. Imagine a bank where
only one customer can do anything at a time—everyone else waits! This wastes time, especially
if a transaction is waiting for something (like loading data from a disk). Interleaving lets multiple
transactions run together, making things faster, but we need to ensure the results are still
correct.
Example to Understand Serializability
Let’s use a simple example with two transactions, T1 and T2, working on two data items, X and Y
(think of X as a bank account balance and Y as another account). Initially, X = 90 and Y = 90.
 T1: Subtract 1 from X (X = X - 1) and add 3 to Y (Y = Y + 3).
 T2: Subtract 2 from X (X = X - 2) and add 2 to Y (Y = Y + 2).
After both transactions, we expect X = 89 and Y = 93 (because 90 - 1 - 2 = 89 and 90 + 3 + 2 =
93).
Serial Schedules
There are two possible serial schedules:
1. T1 then T2:
o T1: Read X (90), write X (90 - 1 = 89), read Y (90), write Y (90 + 3 = 93).
o T2: Read X (89), write X (89 - 2 = 87), read Y (93), write Y (93 + 2 = 95).
o Result: X = 87, Y = 95.
2. T2 then T1:
o T2: Read X (90), write X (90 - 2 = 88), read Y (90), write Y (90 + 2 = 92).
o T1: Read X (88), write X (88 - 1 = 87), read Y (92), write Y (92 + 3 = 95).
o Result: X = 87, Y = 95.
Both serial schedules give the same final result, so either is correct.
Non-serial Schedule
Now, let’s mix the operations (interleave them). Consider two schedules, C and D:
 Schedule C (problematic):
o T2 reads X (90).
o T1 reads X (90).
o T1 writes X (90 - 1 = 89).
o T2 writes X (90 - 2 = 88).
o T1 reads Y (90), writes Y (90 + 3 = 93).
o T2 reads Y (93), writes Y (93 + 2 = 95).
o Result: X = 88, Y = 95 (wrong for X!).
This is wrong because T2 reads X before T1 changes it, so T2’s write to X overwrites T1’s change
(a lost update). The final X value should be 87, not 88.
 Schedule D (correct):
o T1 reads X (90).
o T1 writes X (90 - 1 = 89).
o T2 reads X (89).
o T2 writes X (89 - 2 = 87).
o T1 reads Y (90), writes Y (90 + 3 = 93).
 o T2 reads Y (93), writes Y (93 + 2 = 95).
o Result: X = 87, Y = 95 (correct!).
Schedule D is serializable because it gives the same result as the serial schedule T1 then T2.
Schedule C is not serializable because it doesn’t match either serial schedule.
How Do We Check Serializability?
To determine if a non-serial schedule is serializable, we use conflict equivalence. Two schedules
are conflict equivalent if they order all conflicting operations (read-write or write-write on the
same data item) in the same way.
 Steps to Check:
1. Identify conflicting operations (e.g., T1 writes X, T2 reads X).
2. Check if the order of these conflicts matches the order in a serial schedule (T1
then T2, or T2 then T1).
3. If you can reorder the nonconflicting operations to match a serial schedule, the
schedule is serializable.
For Schedule D:
 Conflicts: T1’s write X and T2’s read X, T1’s write X and T2’s write X.
 Order in D: T1 writes X, then T2 reads X, then T2 writes X. This matches T1 then T2.
 Nonconflicting operations (like T1’s read Y and T2’s write Y) can be moved without
affecting the result.
 Conclusion: D is serializable (equivalent to T1 then T2).
For Schedule C:
 Conflicts: T2 reads X, T1 writes X, T2 writes X.
 This order doesn’t match T1 then T2 (because T2 reads X before T1 writes X) or T2 then
T1 (because T1 writes X before T2 writes X).
 Conclusion: C is not serializable.
Why Does This Matter?
Serializable schedules allow multiple transactions to run at the same time (improving speed)
while ensuring the database stays correct, as if the transactions ran one at a time. Database
systems use techniques like locking or timestamps to enforce serializability, preventing issues
like lost updates.