Open In App

Polygraph to check View Serializability in DBMS

Improve
Improve
Improve
Like Article
Like
Save Article
Save
Share
Report issue
Report

Prerequisite – Concurrency Control -Introduction, Conflict Serializability, Transaction Isolation Levels in DBMS 

Serializability: If any transaction (non-serial) produces an outcome that is equal to the outcome of that schedule’s transaction executed serially then we can call that transaction schedule a Serializable schedule. 

Note: The main objective of serializability is to find non-serial schedules that allow transactions to execute concurrently without interference and produce a database state that could be produced by a serial execution. These are following types of schedules:  

  1. Serial schedule
  2. Conflict Serializability
  3. View Serializability
  4. Non-serial schedule

View Serializability: A schedule is called View Serializable if it’s view equivalent to a serial schedule (no overlapping transaction allowed). These are the following conditions to be a View Serializability: 

  1. In both the schedules read of initial value of data item and write of final value of data item by transaction must be same.
  2. W->R conflict must be same in both schedules.

Now, let us consider the following examples. 

Example: Suppose there is two schedules one is non-serial and another one is serial schedule.  

    Schedule 1              Schedule 2      
  --------------          ---------------
   T1      T2               T1      T2
  --------------          ---------------
  r1(A)                    r1(A)
  A=A+10                   A=A+10
  w1(A)                    w1(A)
  r1(B)                            r2(A)
  B=B*10                           A=A+10
  w1(B)                            w2(a)
          r2(A)            r1(B)                            
          A=A+10           B=B*10      
          w2(A)            w2(B)      
          r2(B)                    r2(B)
          B=B*10                   B=B*10
          w2(B)                    w2(B)  

Checking view serializable or not: 

    Comparison Table
---------------------------
Schedule 1    Schedule 2
---------------------------
A   T1 T2         T1 T2
B   T1 T2         T1 T2 

So Schedule 2 is view equivalent to Schedule 1. 

Using polygraph when the number of transactions is more than 2: Suppose we have 3 transactions T1, T2, and T3. Possible combinations of those transactions are:  

--------------
 T1   T2   T3
 T1   T3   T2
 T2   T1   T3
 T2   T3   T1
 T3   T1   T2
 T3   T2   T1
-------------- 

1. A Tn reads an initial data in a schedule the same Tn also should read the initial data in one of the transaction combinations. That means T1 should occur before T2, so we have to remove these combinations: 

--------------
 T2   T1   T3
 T2   T3   T1
 T3   T2   T1
-------------- 

2. A Tn reads a data after another Tn has written in a schedule, the same Tn also should read after another Tn has written it in one of transaction combination. 

3. A Tn writes the final value for a data in a schedule, the same Tn should also write the final data in one of the transaction combinations. That means T2 occur before T3, so we have to remove these combinations: 

--------------
 T1   T3   T2
 T3   T1   T2
 T3   T2   T1
-------------- 

Example:  

Schedule = w3(x),r2(x),w2(y),r1(z),w3(y),w1(y)  
  T1   T2    T3
----------------
            w(x)
     r2(x)
     w2(y)
r1(z)
           w3(y)
w1(y)
---------------- 

Here T3 must occur first, though it actually does not matter because of no one else writes X, we will keep all the possible transaction combination in the first step. 

T1 must occur after T3 because T1 reads Z after T3 writes it. So here we remove those three combinations of transaction where T1 is before than T3. 

Available combination:
 T2 T3 T1
 T3 T1 T2
 T3 T2 T1 

T2 must occur last cause if not T3 or T2 will overwrite y that T1 writes in our schedule, so we remove from available combination where T1 is not occurring last.  

Available combination:
 T2 T3 T1
 T3 T2 T1 

Note: We use Polygraph when a blind write is available in any transaction. 

Polygraph is a graphical representation used to check view serializability in database management systems (DBMS). View serializability is a property of a schedule of transactions that ensures the same final result is obtained regardless of the order in which the transactions are executed.

A polygraph consists of a directed graph with each node representing a transaction in the schedule, and each edge representing a conflict between two transactions. A conflict occurs when two transactions try to access the same data item in different ways, such as one reading and the other writing, or both writing.

To construct a polygraph, the following steps are followed:

  1. Identify all the transactions in the schedule.
  2. For each pair of transactions Ti and Tj, determine if there is a conflict between them. If there is a conflict, draw a directed edge from Ti to Tj.
  3. If there is a cycle in the polygraph, the schedule is not viewed as serializable, and the transactions must be rearranged to ensure view serializability.
  4. To check if a schedule is view serializable using a polygraph, we need to ensure that there are no cycles in the polygraph. If there are no cycles, the schedule is view serializable, and we can execute the transactions in any order without changing the final result.

Polygraph is an effective technique for checking view serializability, but it can become complicated for large schedules with many transactions and conflicts. In such cases, other techniques such as the precedence graph algorithm or the serialization graph algorithm may be used to check view serializability.

To check view serializability using Polygraph, follow these steps:

Create a directed graph called the precedence graph, where each transaction is a node and an edge exists from transaction Ti to Tj if and only if Ti precedes Tj in the schedule.

For each pair of transactions Ti and Tj that conflict, draw a “conflict edge” from the node representing Ti to the node representing Tj, indicating that Ti conflicts with Tj.

Use Polygraph to check if the resulting graph is acyclic. If it is acyclic, then the schedule is view serializable.

If the graph is cyclic, then the schedule is not view serializable. In this case, the graph can be analyzed to find a cycle and to determine if any transactions in the cycle can be swapped to make the schedule view serializable.

Advantages:

Accuracy: Polygraph is a powerful tool that can accurately determine whether a schedule is view serializable or not. It can detect conflicts that may not be apparent from a manual analysis of the schedule.

Efficiency: Polygraph can quickly analyze large schedules and determine whether they are view serializable. This saves time and effort that would be required for a manual analysis.

Visualization: Polygraph generates a graph representation of the schedule that shows the dependencies between transactions. This visualization can help users to better understand the schedule and the conflicts that occur.

Flexibility: Polygraph can be used to check the view serializability of different types of schedules, including serial and concurrent schedules.

Disadvantages:

Complexity: Polygraph is a complex tool that requires a high level of technical expertise to use effectively. Users must be familiar with graph theory and database concepts to interpret the results.

Limited scope: Polygraph is designed to check view serializability only. It cannot detect other types of anomalies, such as deadlock or starvation.

False negatives: Polygraph may fail to detect some instances of non-view serializable schedules, resulting in false negatives.

Limited applicability: Polygraph may not be useful for all types of databases or database systems. Some DBMSs may have built-in features that ensure view serializability, making polygraph redundant.


Last Updated : 21 Mar, 2023
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads