What is view equivalency?
Schedules (S1 and S2) must satisfy these two requirements in order to be viewed as equivalent:
- The same piece of data must be read for the first time. For instance, if transaction t1 is reading “A” from the database in schedule S1, then t1 must also read A in schedule S2.
- The same piece of data must be used for the final write. As an illustration, if transaction t1 updated A last in S1, it should also conduct final write in S2.
- The middle sequence need to follow suit. As an illustration, if in S1 t1 is reading A, and t2 updates A, then in S2 t1 should read A, and t2 should update A.
View Serializability refers to the process of determining whether a schedule’s views are equivalent.
Example
We have a schedule “S” with two concurrently running transactions, “t1” and “t2.”
Schedule – S:
Transaction-1 (t1) |
Transaction-2 (t2) |
---|---|
R(a) |
|
W(a) |
|
R(a) |
|
W(a) |
|
R(b) |
|
W(b) |
|
R(b) |
|
W(b) |
By switching between both transactions’ mid-read-write operations, let’s create its view equivalent schedule (S’).
Schedule – S’:
Transaction-1 (t1) |
Transaction-2 (t2) |
---|---|
R(a) |
|
W(a) |
|
R(b) |
|
W(b) |
|
R(a) |
|
W(a) |
|
R(b) |
|
W(b) |
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.
Serializability in DBMS
In this article, we are going to explain the serializability concept and how this concept affects the DBMS deeply, we also understand the concept of serializability with some examples, and we will finally conclude this topic with an example of the importance of serializability. The DBMS form is the foundation of the most modern applications, and when we design the form properly, it provides high-performance and relative storage solutions to our application.