In a real‑world database system, multiple transactions often execute at the same time (concurrently). The order in which their operations are actually executed is called a schedule.

Understanding types of schedules is the first step toward learning concurrency control, which ensures that concurrent transactions do not interfere with each other in a way that corrupts data or produces incorrect results.

What Is a Schedule?

A schedule in DBMS is a sequence of operations (reads and writes) from two or more transactions, arranged in the order they are executed by the system.

For example, if two transactions $T_1$ and $T_2$ run concurrently, a schedule might look like:

• $T_1$.read(A)

• $T_2$.read(B)

• $T_1$.write(A)

• $T_2$.write(B)

This sequence is one possible schedule of $T_1$ and $T_2$.

The same transactions can have many different schedules, depending on how the DBMS interleaves their operations.

Why Schedules Matter

• They determine how concurrent transactions interact.

• A bad schedule can cause inconsistencies, lost updates, dirty reads, or phantom reads.

• A good schedule must be equivalent to a serial schedule in effect, so the database remains correct.

This is why we classify schedules into different types based on their structure and behavior.

Types of Schedules

We can broadly classify schedules into the following types:

1. Serial Schedule

A serial schedule is one in which one transaction completes entirely before the next one starts.

In other words, operations of different transactions are not interleaved.

Example

Suppose we have two transactions $T_1$ and $T_2$. A serial schedule could be:

• All operations of $T_1$

• Then all operations of $T_2$

Or:

• All operations of $T_2$

• Then all operations of $T_1$

Serial schedules are safe and correct because there is no interference between transactions. However, they do not exploit concurrency and are usually slower in real systems.

2. Non‑Serial Schedule

A non‑serial schedule is one in which operations of different transactions are interleaved (mixed together).

In real‑world DBMS, most schedules are non‑serial because the system interleaves operations to improve performance and allow transactions to run concurrently.

Example

A non‑serial schedule of $T_1$ and $T_2$:

• $T_1$.read(A)

• $T_2$.read(B)

• $T_1$.write(A)

• $T_2$.write(B)

Here, operations of both transactions are mixed, not grouped in one block.

Non‑serial schedules can be correct or incorrect, depending on whether they are serializable (explained in later articles).

3. Serializable Schedule

A serializable schedule is a schedule (usually non‑serial) whose effect on the database is equivalent to some serial schedule.

In simple terms:

“Even though operations are interleaved, the final result is the same as if the transactions ran one after another in some order.”

Serializable schedules are considered correct because they preserve consistency, even though they allow concurrency.

4. Non‑Serializable Schedule

A non‑serializable schedule is a schedule whose effect is not equivalent to any serial schedule.

Such schedules can cause inconsistencies, like lost updates, dirty reads, or incorrect results, and must be avoided in well‑designed systems.

Why Classifying Schedules Is Important

• Serial schedules are correct but not efficient.

• Non‑serial schedules are efficient but must be constrained to be at least serializable.

• DBMS uses concurrency control protocols (locking, timestamping, etc.) to allow only serializable or equivalent schedules.

For beginners, the key idea is:

• A schedule is the actual order of operations from multiple transactions.

• The goal of concurrency control is to allow non‑serial schedules that are serializable, so the system stays correct and efficient at the same time.

Summary

Types of schedules in DBMS classify how operations from multiple transactions are ordered:

• Serial schedule: one transaction finishes before the next starts; no interleaving.

• Non‑serial schedule: operations of different transactions are interleaved; common in real systems.

• Serializable schedule: non‑serial but effect‑equivalent to some serial schedule; considered correct.

• Non‑serializable schedule: effect not equivalent to any serial schedule; can cause inconsistencies.

Understanding these types is essential before moving to serializability, lock‑based protocols, and isolation problems like dirty read and phantom read in later articles.