View Serializability in DBMS

In database systems, concurrent execution of transactions is used to improve resource utilization and system throughput. However, concurrency can lead to inconsistencies in the database if not handled properly.

• View Serializability ensures that even though transactions run concurrently, their outcome will be identical to the result achieved if the transactions were executed one by one in a specific order.
• It is a concept in concurrency control that checks whether a non-serial schedule produces the same final output as a serial schedule.
• It ensures data consistency by verifying that the initial reads, updated reads, and final writes of transactions are the same as in a serial schedule.

Example: Understanding View-Serializability first with a Schedule:

Schedule S₁:

So, its Conflict Precedence Graph is as follows - 

The above graph contains cycle/loop which means it is not conflict-serializable but it does not mean that it cannot be consistent and equivalent to the serial schedule it may or may not be. 

Schedule S'₁:

In the above example if we do swapping among some transaction's operation so our table will look like this:

Its Precedence Graph is as follows:

The graph of S'1 has no cycles, meaning it’s conflict serializable and view serializable.

Note: In the above example we understood that if a schedule is Conflict-serializable so we can easily predict that It would be

1. Equivalent to a serial schedule,
2. Consistent,
3. And also a View-Serializable.

Methods to Check View Serializability

1. View Equivalent

If a schedule is view equivalent to a serial schedule, it’s view serializable. This requires three conditions:

• Initial Read: Same initial read values.
• Updated Read: Same updated read values.
• Final Update/Write: Same final write values.

Read more about Condition of Schedules to be View Equivalent, Here.

2. Conflict Serializability and Dependency Graph

Another method to check view serializability starts by testing conflict serializability through the precedence graph and then check for Blind Writes following checking the cycle in dependency graph.

• Test Conflict Serializability: If a schedule is conflict-serializable, it’s view serializable.
• Check for Blind Writes: A blind write happens when a transaction writes to an item without reading it first. It may cause inconsistency in view serializability.
• Check for Cycles: If the dependency graph has no cycles, the schedule is view serializable.

Example Problem: Prove whether the given schedule is View-Serializable or not. 

S' : read1(A), write2(A), read3(A), write1(A), write3(A)

Solution: First of all we'll make a table for a better understanding of given transactions of schedule S'

First, we check whether it is Conflict-Serializable or not, because if it is Conflict-Serializable so it will also be View-Serializable, so we will make a precedence graph for the schedule S'. From precedence graph, we can conclude that the schedule is not conflict serializable (as there is a loop or cycle in precedence graph).

Now, we will check whether the Schedule S` contains any blind write. We found that the schedule S' contains a blind-write write2(a) in transaction T2. Hence schedule S' may or may not be View-Serializable.

Now, we will draw a dependency graph.

• Transaction T₁ first reads data_item "a" and transaction T₂ first updates(write) "a".
• So, the transaction T₁ must execute before T₂ .
• In that way, we get the dependency (T₁ → T₂ ) in the graph.
• And, the final update(write) on "a" is made by transaction T₃ .
• So, transaction T₃ must execute after all the other transactions(T₁ , T₂ ).
• Thus, we get the dependency (T₁ , T₂ ) → T₃ in the graph shown below:

As there is no cycle/loop in the dependency graph, the schedule S' is View-Serializable.