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.

Need of View-Serializability

• Some schedules are not Conflict-Serializable but still give consistent results. Conflict-Serializability is limited when the Precedence Graph of a schedule contains a cycle. If a cycle exists, we cannot predict whether the schedule will be consistent or not. According to Conflict-Serializability, a schedule is consistent only if its precedence graph has no cycles.
• But what happens if a schedule's precedence graph has a cycle and still produces consistent results, just like a conflict-serializable schedule?
• To handle such cases, we use the concept of View-Serializability. It expands the idea of serializability to include schedules that are consistent but may not meet the strict conditions of Conflict-Serializability.

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 - 

Now, we see that the precedence graph of the second table does not contain any cycle/loop, which means it is conflict serializable (equivalent to serial schedule, consistent) and the final result (i.e. a=0) is coming the same as the first table. 

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.

But what if it is non-conflict serializable. In this situation, we cannot predict whether it is consistent and serializable or not. As we look in the above example, where the precedence graph of Schedule S₁ was giving consistent results, equivalent to the serializable result of Schedule S'₁, despite containing cycles/loops.

So, to address the limitation of the Conflict-Serializability concept View-Serializability method came into the picture. 

Methods to Check View Serializability

Method 1: View Equivalent

If a given schedule is found to be view equivalent to some serial schedule, then it is called as a view serializable schedule. View equivalence is a way of comparing two different schedules to check if they produce the same final result in a database, even though the order of actions might be different.

There are three main conditions for view equivalence between two schedules:

• Initial Read
• Updated Read
• Final Update/Write

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

Method 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.

1. Test for Conflict Serializability: 

• Check whether the given schedule is conflict serializable or not.
• If the given schedule is conflict serializable, then it is surely view serializable.
• If the given schedule is not conflict serializable, then it may or may not be view serializable.

2. Check for Blind Writes:

• Blind write occurs when a transaction writes to a data item without reading its value first (i.e., there’s no prior read operation for that item in the schedule).
• To ensure view serializability, the key thing to check is whether blind writes create a conflict in terms of the final outcome. If a schedule has blind writes, it may not produce the same result as a serial schedule. This is because a blind write could change a value that another transaction relies on without that transaction ever seeing the change.
• So, if there exists any blind write, then the schedule may or may not be view serializable. 

3. Check for Cycles in the Dependency Graph:

• After testing for conflict serializability and checking for blind writes, the next step is to examine the dependency graph.
• The dependency graph is a directed graph where:
  • Each node represents a transaction.
  • There is a directed edge from transaction T1 to transaction T2 if T1 must come before T2 for the schedule to maintain consistency.
• If there is a cycle in the dependency graph, the schedule is not serializable (and thus not view serializable) and if no cycle/loop exists in the graph, then the schedule would be a View-Serializable.

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.

Its Dependency graph will be followed as:

• 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.