Polygraph to check View Serializability in DBMS
In a Database Management System (DBMS), ensuring that transactions execute correctly without conflicts is important. One way to check this is through view serializability, which ensures that a schedule produces the same final result as some serial execution of transactions.
To check view serializability, we use a polygraph, a special type of graph that helps to visualize dependencies between transactions. By analyzing this graph, we can determine whether a given schedule maintains the correct order of operations.
Note: The main objective of serializability is to identify non-serial schedules that allow transactions to execute concurrently without interference while ensuring that the final database state is equivalent to a serial execution (where transactions run one after another).
There are different types of schedules based on serializability:
- Serial Schedule – Transactions execute one after another without overlapping.
- Non-Serial Schedule – Transactions overlap in execution.
- Conflict Serializable Schedule – A non-serial schedule that can be converted into a serial schedule by swapping non-conflicting operations.
- View Serializable Schedule – A non-serial schedule that produces the same final database state as some serial schedule, but may not be conflict serializable.
View Serializability
A schedule is called View Serializable if it’s view equivalent to a serial schedule (no overlapping transaction allowed). For a schedule to be View Serializable, it must meet these three conditions:
- Same Initial Reads – Each transaction in the schedule must read the same initial values as in a serial schedule.
- Same Read-Write Mapping – If a transaction reads a value written by another transaction, it must be the same as in a serial schedule.
- Same Final Writes – The final write operations in both schedules must be the same.
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)
To check whether the given Schedule 1 and Schedule 2 are View Serializable, we need to verify the three conditions of View Serializability:
- Same Initial Reads: Both schedules ensure that transactions read the initial values of A and B in the same way.
- Same Read-Write Mapping: In both schedules, transactions read values written by previous transactions consistently.
- Same Final Writes: The final values of A and B in both schedules match what would happen in some serial execution of T1 and T2.
Since both schedules follow the three conditions of View Serializability, they are View Serializable.
Polygraph Method to check View Serializability
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:
- Identify all the transactions in the schedule.
- 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.
- 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.
- 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.
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. If a transaction (Tn) reads a value that was written by another transaction (Tm) in a schedule, then in any equivalent serial schedule, Tn should read the same value after Tm writes it.
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
Remaining Schedule: T1 → T2 → T3
Polygraph Construction
If the polygraph is acyclic, then the schedule T1 → T2 → T3 is View Serializable.
Polygraph
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.
FAQs on Polygraph to Check View Serializability in DBMS
What is a Polygraph in DBMS?
A Polygraph is a directed graph used to check View Serializability in DBMS by representing dependencies between transactions based on read-write and write-write relationships.
How does a Polygraph help in checking View Serializability?
A Polygraph helps by visually representing transaction dependencies. If the graph contains a cycle, the schedule is not view serializable. If no cycle exists, the schedule is view serializable and can be executed in some serial order.
What is the difference between a Polygraph and a Precedence Graph?
A Precedence Graph is used to check Conflict Serializability, ensuring a strict transaction order based on conflicts. A Polygraph is more flexible and is used to check View Serializability, allowing more schedules to be considered valid.
What are the steps to construct a Polygraph for a given schedule?
Identify transactions and dependencies, draw directed edges for read-after-write and write-after-write relationships, and check for cycles. If there are no cycles, the schedule is view serializable.
What happens if a cycle is found in the Polygraph?
A cycle means that no equivalent serial schedule exists for the given schedule, so it is not view serializable. Transactions may need to be reordered or rescheduled to achieve serializability.
