Serializability in DBMS

In DBMS, serializability ensures the database remains correct even when multiple transactions run at the same time. It makes transactions behave as if they were executed one after another in some order. This prevents conflicts, maintains data consistency, and ensures reliable results, just like in a single, orderly sequence of transactions.

Non-serial Schedule

A non-serial schedule allows transactions to run concurrently and may access the same data. To ensure database consistency, it must be serializable, meaning it should produce the same result as some serial (one-by-one) execution.

Example:

We can observe that Transaction-2 begins its execution before Transaction-1 is finished, and they are both working on the same data, i.e., "a" and "b", interchangeably. Where "R"-Read, "W"-Write

Serializability testing

We can utilize the Serialization Graph or Precedence Graph to examine a schedule's serializability. A schedule's full transactions are organized into a Directed Graph, what a serialization graph is.

It can be described as a Graph G(V, E) with vertices V = "V1, V2, V3,..., Vn" and directed edges E = "E1, E2, E3,..., En". One of the two operations—READ or WRITE—performed by a certain transaction is contained in the collection of edges. Where Ti -> Tj, means Transaction-Ti is either performing read or write before the transaction-Tj.

Types of Serializability

There are two ways to check whether any non-serial schedule is serializable.

1. Conflict serializability

Conflict serializability ensures database consistency by checking if a non-serial schedule can be rearranged into a serial order by swapping non-conflicting operations. It prevents conflicting operations (like read/write on the same data) from executing at the same time.

Conflict Equivalency

For two schedules (S1 and S2) to be conflict equivalent, they must satisfy the following:

• Same Conflicting Operations: The same conflicting operations (e.g., reads and writes on the same data item) must occur in both schedules in the same order. Example: If t1 writes A before t2 in S1, then t1 must also write A before t2 in S2.
• Non-Conflicting Operations: Operations that do not conflict (e.g., reading different data items) should not affect the order of the schedules. Example: If t1 reads B and t2 reads C in S1, then t1 should still read B and t2 should still read C in S2.
• Preserving Transaction Order: The order of conflicting operations should be the same in both schedules to maintain consistency. Example: If t1 writes A and t2 reads A in S1, t2 must read A after t1 in S2.

In simple terms, conflict equivalency ensures that conflicting operations happen in the same order in both schedules, while non-conflicting ones can appear in any order.

2. View Serializability

View serializability ensures that a non-serial schedule results in the same final outcome as a serial schedule, maintaining database consistency.

To further understand view serializability in DBMS, we need to understand the schedules S1 and S2. The two transactions T1 and T2 should be used to establish these two schedules. Each schedule must follow the three transactions in order to retain the equivalent of the transaction. These three circumstances are listed below.

1. Same Transactions: Both schedules must include the same set of transactions.
2. Same Writes: Each data item must be written by the same transaction in both schedules.
3. Same Reads: Each read must read the same value (from the same write) in both schedules.

View Equivalency

Schedules (S1 and S2) must satisfy these two requirements in order to be view equivalent:

1. The same data must be read first in both schedules. Example: If t1 reads A in S1, it must do the same in S2.
2. The same data must be used for the final write. Example: If t1 updates A last in S1, it should do the same in S2.
3. The middle sequence should also match. Example: If t1 reads A and t2 updates A in S1, the same order should occur in S2.

Example: We have a schedule "S" with two concurrently running transactions, "t1" and "t2."

Schedule S:

By switching between both transactions' mid-read-write operations, let's create its view equivalent schedule (S').

Schedule S':

It is a view serializable schedule since a view similar schedule is conceivable.

Note: A conflict serializable schedule is always viewed as serializable, but vice versa is not always true.

Benefits of Serializability

• Predictable Execution: Transactions behave consistently without surprises—no data loss or corruption.
• Easier Debugging: Each transaction runs independently, making errors easier to trace and fix.
• Lower Costs: Reduces need for complex hardware and can cut down development costs.
• Better Performance: Optimized, consistent execution can sometimes outperform non-serial schedules.