overview of serializablity in data base

Overview of Serializability in Databases

Serializability is a key concept in database management systems (DBMS), particularly in the

context of concurrency control. It ensures that the execution of multiple transactions in a
database does not result in inconsistent or incorrect states. In essence, serializability guarantees
that the final state of the database, after executing all concurrent transactions, will be the same as
if the transactions were executed one after the other in some serial order (i.e., one transaction at a
time), without any overlap.

Key Concepts

1. Transactions: A transaction in a database represents a unit of work that must either be

fully completed or fully rolled back. Transactions consist of operations such as INSERT,
UPDATE, DELETE, etc.
2. Concurrency Control: Databases often handle multiple transactions simultaneously to
improve performance and resource utilization. Concurrency control ensures that these
transactions do not interfere with each other in ways that could lead to data inconsistency.
3. Schedules: A schedule is the sequence of operations (read, write, commit, etc.) from
multiple transactions. It is essentially the interleaved execution of these operations. A
schedule is serial if the transactions are executed one after another without overlapping.
4. Conflict: Two operations conflict if they belong to different transactions, access the same
data item, and at least one of the operations is a write. For example, if one transaction
writes to a data item and another transaction reads or writes to the same item, these
operations conflict.

Types of Serializability

There are two main types of serializability:

1. Conflict Serializability: A schedule is conflict-serializable if it can be transformed into

a serial schedule by swapping non-conflicting operations (operations that do not conflict
with each other). Conflict serializability is the most common and practical form of
serializability.
o Example: If transaction T1 writes to a data item and transaction T2 reads the
same data item, these operations conflict. However, if T1's write and T2's read do
not interfere with other operations, the schedule can be reordered to form a serial
schedule.
2. View Serializability: A schedule is view-serializable if it produces the same result as
some serial execution of transactions, even if the order of operations is different. It is a
more general concept than conflict serializability and is not always easy to check.
o Example: View serializability checks if the "views" (i.e., the data read by each
transaction) remain consistent, even if the schedule is not conflict serializable.
Why is Serializability Important?

 Consistency: Serializability ensures that concurrent transactions do not lead to database

anomalies such as lost updates, temporary inconsistency, or uncommitted data being read
(dirty reads).
 Correctness: It guarantees that, despite the interleaving of operations, the final state of
the database will reflect a valid execution of transactions, as though they were executed
one after the other in some order.

Achieving Serializability

Database management systems (DBMS) use various methods to enforce serializability:

1. Lock-based Protocols:
o Two-Phase Locking (2PL): A transaction must acquire all the locks it needs
before releasing any lock. 2PL ensures conflict serializability by preventing
transactions from interfering with each other.
o Strict Two-Phase Locking (Strict 2PL): A stricter version of 2PL where a
transaction holds all locks until it commits or aborts, ensuring serializability.
2. Timestamp Ordering:
o Each transaction is given a unique timestamp. The DBMS ensures that
transactions with earlier timestamps are prioritized when reading or writing data
items. This prevents conflicts that could lead to non-serializability.
3. Serializable Schedules:
o The DBMS may analyze schedules to ensure they are serializable. If a schedule is
found to be non-serializable, the system may abort or delay some transactions to
resolve the conflicts.
4. Optimistic Concurrency Control:
o This method allows transactions to execute without locks and checks for conflicts
only during the commit phase. If conflicts are detected, the transaction is rolled
back. This can lead to serializable results if conflicts are rare.

Types of Anomalies Avoided by Serializability

Without serializability, certain anomalies may occur:

1. Lost Update: When two transactions read the same data and then write changes to it, one
update might be lost, as only the last write is reflected in the database.
2. Temporary Inconsistency (or Dirty Read): A transaction reads a data item that has
been written by another transaction but not yet committed. If the second transaction is
rolled back, the first transaction may have read inconsistent data.
3. Uncommitted Data: If a transaction reads data that has been written by another
transaction but that transaction later fails, the first transaction will have read uncommitted
data, leading to potential inconsistencies.

Example of Conflict Serializability

 Consider two transactions T1 and T2:

 T1: Read(X), Write(X)

 T2: Read(X), Write(X)

A possible non-serial schedule might look like this:

1. T1: Read(X)
2. T2: Read(X)
3. T1: Write(X)
4. T2: Write(X)

In this schedule, T1 and T2 conflict when they both try to access X. However, this schedule can
be rearranged into a serial schedule, for example:

 T1: Read(X), Write(X)

 T2: Read(X), Write(X)

This serial schedule is conflict-serializable, meaning it guarantees a consistent outcome.

Conclusion

Serializability is a crucial property in database systems to maintain consistency and ensure the
correctness of concurrent transactions. By enforcing serializability, databases can ensure that
multiple transactions, even when executed in parallel, will result in a valid final state, equivalent
to some serial execution of the transactions. Various concurrency control techniques, such as
locking and timestamp ordering, help achieve this goal, protecting against anomalies like lost
updates, dirty reads, and temporary inconsistencies.

Serializability in DBMS
Last Updated : 06 Oct, 2023





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.
What is a serializable schedule, and what is it used for?
If a non-serial schedule can be transformed into its corresponding
serial schedule, it is said to be serializable. Simply said, a non-serial
schedule is referred to as a serializable schedule if it yields the same
results as a serial timetable.
Non-serial Schedule
A schedule where the transactions are overlapping or switching
places. As they are used to carry out actual database operations,
multiple transactions are running at once. It's possible that these
transactions are focusing on the same data set. Therefore, it is
crucial that non-serial schedules can be serialized in order for our
database to be consistent both before and after the transactions are
executed.
Example:

Transaction-1 Transaction-2

R(a)

W(a)

R(b)

W(b)

R(b)

R(a)

W(b)

W(a)
We can observe that Transaction-2 begins its execution before
Transaction-1 is finished, and they are both working on the same
data, i.e., "a" and "b", interchangeably. Where "R"-Read, "W"-Write
Serializability testing
We can utilize the Serialization Graph or Precedence Graph to
examine a schedule's serializability. A schedule's full transactions
are organized into a Directed Graph, what a serialization graph is.

Precedence
Graph
It can be described as a Graph G(V, E) with vertices V = "V1, V2,
V3,..., Vn" and directed edges E = "E1, E2, E3,..., En". One of the two
operations—READ or WRITE—performed by a certain transaction is
contained in the collection of edges. Where Ti -> Tj, means
Transaction-Ti is either performing read or write before the
transaction-Tj.
Types of Serializability
There are two ways to check whether any non-serial schedule is
serializable.
Types of Serializability - Conflict & View
1. Conflict serializability
Conflict serializability refers to a subset of serializability that focuses
on maintaining the consistency of a database while ensuring that
identical data items are executed in an order. In a DBMS each
transaction has a value and all the transactions, in the database rely
on this uniqueness. This uniqueness ensures that no two operations
with the conflict value can occur simultaneously.
For example lets consider an order table and a customer table as
two instances. Each order is associated with one customer even
though a single client may place orders. However there are
restrictions for achieving conflict serializability in the database. Here
are a few of them.
1. Different transactions should be used for the two procedures.
2. The identical data item should be present in both transactions.
3. Between the two operations, there should be at least one write
operation.
Example
Three transactions—t1, t2, and t3—are active on a schedule "S" at
once. Let's create a graph of precedence.
 Transaction - 1
(t1) Transaction - 2 (t2) Transaction - 3 (t3)

R(a)

R(b)

R(b)

W(b)

W(a)

W(a)

R(a)

W(a)

It is a conflict serializable schedule as well as a serial schedule

because the graph (a DAG) has no loops. We can also determine the
order of transactions because it is a serial schedule.
DAG of transactions
As there is no incoming edge on Transaction 1, Transaction 1 will be
executed first. T3 will run second because it only depends on T1.
Due to its dependence on both T1 and T3, t2 will finally be executed.
Therefore, the serial schedule's equivalent order is: t1 --> t3 --> t2
Note: A schedule is unquestionably consistent if it is conflicting
serializable. A non-conflicting serializable schedule, on the other
hand, might or might not be serial. We employ the idea of View
Serializability to further examine its serial behavior.
2. View Serializability
View serializability is a kind of operation in a serializable in which
each transaction should provide some results, and these outcomes
are the output of properly sequentially executing the data item. The
view serializability, in contrast to conflict serialized, is concerned
with avoiding database inconsistency. The view serializability
feature of DBMS enables users to see databases in contradictory
ways.
To further understand view serializability in DBMS, we need to
understand the schedules S1 and S2. The two transactions T1 and
T2 should be used to establish these two schedules. Each schedule
must follow the three transactions in order to retain the equivalent
of the transaction. These three circumstances are listed below.
1. The first prerequisite is that the same kind of transaction appears
on every schedule. This requirement means that the same kind of
group of transactions cannot appear on both schedules S1 and
S2. The schedules are not equal to one another if one schedule
commits a transaction but it does not match the transaction of
the other schedule.
2. The second requirement is that different read or write operations
should not be used in either schedule. On the other hand, we say
that two schedules are not similar if schedule S1 has two write
operations whereas schedule S2 only has one. The number of the
write operation must be the same in both schedules, however
there is no issue if the number of the read operation is different.
3. The second to last requirement is that there should not be a
conflict between either timetable. execution order for a single
data item. Assume, for instance, that schedule S1's transaction is
T1, and schedule S2's transaction is T2. The data item A is written
by both the transaction T1 and the transaction T2. The schedules
are not equal in this instance. However, we referred to the
schedule as equivalent to one another if it had the same number
of all write operations in the data item.
What is view equivalency?
Schedules (S1 and S2) must satisfy these two requirements in order
to be viewed as equivalent:
1. 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.
2. 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.
3. 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)
Transaction-1 (t1) Transaction-2 (t2)

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.
Advantages of Serializability
1. Execution is predictable: In serializable, the DBMS's threads
are all performed simultaneously. The DBMS doesn't include any
such surprises. In DBMS, no data loss or corruption occurs and all
variables are updated as intended.
2. DBMS executes each thread independently, making it much
simpler to understand and troubleshoot each database thread.
This can greatly simplify the debugging process. The concurrent
process is therefore not a concern for us.
3. Lower Costs: The cost of the hardware required for the efficient
operation of the database can be decreased with the aid of the
serializable property. It may also lower the price of developing
the software.
4. Increased Performance: Since serializable executions provide
developers the opportunity to optimize their code for
performance, they occasionally outperform non-serializable
equivalents.
For a DBMS transaction to be regarded as serializable, it must
adhere to the ACID properties. In DBMS, serializability comes in a
variety of forms, each having advantages and disadvantages of its
own. Most of the time, choosing the best sort of serializability
involves making a choice between performance and correctness.
Making the incorrect choice for serializability might result in
database issues that are challenging to track down and resolve. You
should now have a better knowledge of how serializability in DBMS
functions and the different types that are available thanks to this
guide.