Home » DBMS

Schedule and Its Types in DBMS

In this tutorial, we will learn about the schedule, and its various types with the help of examples in database management system. By IncludeHelp Last updated : May 31, 2023

Overview

Transaction: A transaction is a logical work unit made up of one or more database activities. It may consist of a series of read-and-write operations.

Schedule: A schedule is an arrangement of transactions executed by a DBMS. It represents the order of execution of the operations within the transactions.

Conflict: a conflict ensues when two transactions access the same data item and at least one of them conducts a write operation.

Now, let’s understand Schedule and its different types,

What is Schedule in DBMS?

A schedule is a series of operations from one transaction to another transaction. In database management systems (DBMS), different types of schedules define the order in which transactions are executed.

Types of Schedules

Here are the commonly known types of schedules:

1. Serial Schedule

A serial schedule in DBMS refers to an execution sequence in which transactions are executed one after another in a sequential manner. This ensures that the operations of one transaction do not overlap or interfere with the operations of other transactions.

Example

Below mentioned example demonstrates serial schedule:

In the above figure, T1 and T2 are the two transactions executing serially one after another. Therefore, transaction T1 will execute first; once it will get done then transaction T2 will execute. This type of schedule is known as a serial schedule. Execution order, concurrency, isolation, data consistency, and no deadlocks are major points that play a vital role in the functioning of serial schedules; the descriptions of these are as follows -

• Execution Order: In a serial schedule, the order of executing transactions is fixed and predetermined. Each transaction starts only after the completion of the preceding transaction.
• Concurrency: Since transactions are executed serially, there is no concurrency or parallelism in a serial schedule. Only one transaction is active at a time.
• Isolation: Serial schedules provide a high level of isolation between transactions. Each transaction has exclusive access to the database, and its operations do not interfere with the operations of other transactions. This ensures consistency and integrity of the data.
• Data Consistency: Serial schedules guarantee that the database remains in a consistent state throughout the execution of transactions. There are no conflicts or concurrency-related issues that can result in inconsistent or incorrect data.
• No Deadlocks: Serial schedules are free from deadlocks since there is no possibility of transaction dependencies or circular wait conditions.

Serial schedules are commonly used in situations where data consistency is critical and the workload or the number of concurrent transactions is relatively low; however, in scenarios with high transaction volumes and the need for improved performance, concurrent schedules are preferred over serial schedules.

2. Non-Serial Schedule

A non-serial schedule allows simultaneous/concurrent execution of transactions. All transactions' operations are combined or interleaved with one another. Non-serial schedules provide more flexibility and concurrency than serial schedules. This concurrency may result in parallel execution of transactions and enhanced performance, but it also introduces the possibility of data inconsistencies or anomalies. Non-serial schedules are not always -

• Consistent
• Recoverable
• Cascadeless
• Strict

This schedule requires additional mechanisms, such as concurrency control techniques (e.g., locking, timestamp ordering, etc.), to ensure data integrity and consistency. These mechanisms help manage access to shared resources and ensure that conflicting operations do not lead to inconsistencies in the database.

Example

Below mentioned example demonstrates non-serial schedule:

In the above example T1 and T2 are the two banking transactions; the description of the schedule is as -

• T1: Read Account A balance.
• T2: Read Account B balance.
• T1: Add Rs 5000 into Account A.
• T2: Deduct Rs 2000 from Account B.
• T2: Write the updated balance of Account B.
• T1: Write the updated balance of Account A.

In this non-serial schedule, T1 and T2 are interleaved, and their operations are executed concurrently.

Types of non-serial schedules

There are two types of non-serial schedules Serializable and Non-Serializable.

2.1. Serializable

A schedule is considered serializable if it is equivalent to some serial execution of the same transactions. A serializable schedule provides the illusion of running transactions in isolation, even though they may be executed concurrently.

Example

In this case, T1 reads and writes to data item A, and T2 reads and writes to data item B. The plan can be made to work like a series processing because the processes of T1 and T2 can be moved around.

2.1.1. Conflict Serializability

A non-serial schedule is a conflict serializable if the order of conflicting operations (read-write or write-write) can be rearranged to create an equivalent serial schedule. These operations pair become conflicting if the following conditions satisfy:

• Each relates to a distinct transaction.
• They have the same data item.
• At least one write operation is present.

Example

The final result of the non-serial schedule is the same as a serial schedule, but the order of execution may be different.

2.1.2. View Serializability

A non-serial schedule is a view serializable if it is view equivalent to a serial schedule. It means that it produces the same result as some serial schedules that can be obtained by permuting the non-conflicting (read-only) operations. This means that the order of non-conflicting operations can be changed without affecting the final result.

Example

2.2. Non-Serializable

A Non-serializable schedule is a non-serial schedule that cannot be serialized. It is not guaranteed that a non-serializable schedule would have the same impact on any consistent database as a serial schedule. It refers to a schedule of transactions that do not maintain the serializability property; it violates the serializability property and may lead to several anomalies, such as lost updates, dirty reads, non-repeatable reads, and inconsistent analysis. These anomalies can result in incorrect and inconsistent data states, compromising the integrity and reliability of the database.

There are two types of Non-Serializable schedule:

2.2.1. Recoverable schedule

A recoverable schedule ensures that if a transaction T1 reads a data item previously written by another transaction T2, then T2 must commit before T1 commits. This ensures that the system can recover from failures without violating the integrity of the data.

Example

From above example, we can see that T2 performs a dirty read operation. The commit operation of T2 is delayed till T1 commits or roll backs. T1 commits later. T2 may now make a commitment. If T1 had failed, T2 would have the opportunity to succeed by going back in time.

2.2.2. Non-recoverable Schedule

If a transaction conducts a dirty read operation from an uncommitted transaction and subsequently commits before the transaction from which the value was read, the schedule is known as a non-recoverable Schedule.

Example

T2 carries out a dirty read operation. T2 makes a commitment before T1. T1 later fails and rolls back. T2's reading now appears to be erroneous. T2 is unable to recover because it has already committed.