Schedule In DBMS
When we hear the word “Schedule,” the first thought comes to mind, or we generally use this word in our daily lives, like work schedules, day schedules, daily cooking time schedules, etc.
Just like that, in DBMS, the “Schedule” technique is used. The basic definition of a schedule is a plan or timetable that outlines when specific tasks or activities are supposed to occur.
So a Schedule in DBMS is like a to-do list that shows the order in which different tasks from various transactions are done. So basically, it helps keep track of the step-by-step order in which different tasks are done one after another.
In this blog we explain types of schedules in DBMS, how they work with examples.
Let’s first understand Types Of Schedule in DBMS.
Want to transform a career in SQL Developer ?
Enroll now and take the first step towards a successful career. Click here to join our courses today!
Types Of Schedules In DBMS
There are two types of Scheduling in DBMS –
1) Serial Schedule
2) Non-Serial Schedule
Also, Non-Serial Schedule can be further divided into subcategories which we explain further.
1) Serial Schedule
Schedule where tasks (transactions) are executed without mixing with each other is called a “Serial Schedule” . In simple terms, transactions in a serial schedule are executed one at a time.
Let’s Take an example –
| Step | Transaction A | Transaction B |
| 1 | R1 | |
| 2 | W1 | |
| 3 | R2 | |
| 4 | W2 |
- In step 1, Transaction A reads data (R1)
- In step 2, Transaction A writes data (W1)
- In step 3, Transaction B reads data (R2)
Note: All this step occurs after the completion of all steps for Transaction A ( R1 & W1) because this is a serial schedule.
- In step 4, Transaction B writes data (W2)
- So basically Serial Schedule is R1, W1, R2 & W2
Also Read: Types Of Attributes In DBMS
2) Non-Serial Schedule
Non-Serial Schedule is the exact opposite of Serial Schedule. In a Non-Serial schedule multiple transactions can execute simultaneously , and their operations may overlap.
Let’s Take an example –
Transaction C: R1, W1
Transaction D: R2, W2
| Step | Transaction C | Transaction D |
| 1 | R1 | |
| 2 | R2 | |
| 3 | W1 | |
| 4 | W2 |
- In step 1: Transaction C reads data (R1)
- In step 2 : Transaction D reads data (R2)
Note: This step can occur concurrently with step 1 because it involves a different piece of data.
- In step 3, Transaction C writes data (W1). This can happen simultaneously with step 2 or after it.
- In step 4, Transaction D writes data (W2)
Non-Serial Schedule can further divided into two parts –
1) Serializable Schedule
2) Non-Serializable Schedule
Let’s first understand what a Serializable Schedule is with an example.
Also Read: Prime Attribute In DBMS
1) Serializable Schedule
Serializability Schedule means, When you try to execute two or more transactions at the same time, the final results should be the same as doing them one after the other ( Serial Order). This helps keep the database correct and more accurate, even when lots of transactions are executed once at a time.
For Example:
There are two transactions (t1 and t2) related to a bank account:
Schedule 1 (t1 followed by t2):
| Step | Transaction | Operation | Amount |
| 1 | t1 | Withdraw $100 | |
| 2 | t1 | Deposit $500 | |
| 3 | t2 | Check balance | |
| 4 | t2 | Withdraw $50 |
Schedule 2 (t2 followed by t1):
| Step | Transaction | Operation | Amount |
| 1 | t2 | Check balance | |
| 2 | t2 | Withdraw $50 | |
| 3 | t1 | Withdraw $100 | |
| 4 | t1 | Deposit $500 |
- In Schedule 1, t1 operations are completed before t2’s operations.
- In Schedule 2, t2’s operations are completed before t1’s operations.
If you calculate the final balance after each step in both schedules, you’ll observe that the final balances differ. This illustrates the importance of the order of transactions and the impact on the final result.
2) Non-Serializable Schedule
If transactions are not happening one after the other like they are supposed to, it’s called a Non-Serializable Schedule. This happens when one transaction reads data changed by another transaction before it’s finished, or when two transactions try to change the same data at the same time.
For Example:
Transaction A: Withdraw $100, Deposit $200
Transaction B: Check balance, Withdraw $50
| Step | Transaction A | Transaction B |
| 1 | Withdraw $100 | |
| 2 | Check balance | |
| 3 | Withdraw $50 | |
| 4 | Deposit $200 |
- In step 1, Transaction A withdraws $100
- In step 2, Transaction B checks the balance (assuming it’s $150 at this point)
- In step 3, Transaction B withdraws $50
- In step 4, Transaction A deposits $200
Again Serializable Schedule divided into two parts –
- Conflict Serializable
- View Serializable
Let’s understand one by one what Conflict Serializable and View Serializable are.
Also Read: Tuple In DBMS
1) Conflict Serializable
Conflict serializability is really important for schedulers because conflict serializability makes sure that concurrent transactions stay separate. Keeping the order in which things are finalized is the best thing schedulers can do.
In fact, conflict serializability is often regarded as the starting point for the development of algorithms implemented by schedulers to check for serializability.
2) View Serializable
View Serializability is a way to see if a schedule works correctly or not. To check if a schedule is viewed as serializable, we just need to compare it with the schedule where things happen one after the other to see if they match.
There are three steps of checking view serializability –
Step 1: First Read Condition:
In the first step you should read each condition the same as reading in a regular order.
For example: Reading from left to right.
Step 2: Constant Reading & Writing Condition Must:
If one transaction reads something that another transaction changes, it should follow the regular order of reading first and then writing, whether it’s done by the same or a different transaction.
Step 3: Last Write Condition:
The final thing a transaction writes in a schedule should match the last writing in the regular order (serial schedule).
Also Read: What is the command used to define view in SQL?
Conclusion
I hope you get a better understanding of “Schedule In DBMS”.
- Schedule in DBMS organize the order of transactions.
- Proper scheduling ensures transactions work smoothly together.
- Serializable schedules follow rules for consistency.
- Non-serializable schedules let transactions occur at the same time, but this might cause problems and things may not make sense.
If you want to start a career in DBMS?
Call us For Free Career Counseling +91 8600998107 / +91 7028710777
FAQ’s
What is the difference between a Serial schedule and a Serializable Schedule?
Serial Schedule is Transactions happen one after the other, no overlap it is in serial manner on the other hand, In Serializable Schedule is transactions execute one after the other, but might overlap if it doesn’t change the result.
Is Every Schedule Serializable?
No, not every schedule is serializable. Some schedules with overlapping transactions may not guarantee the same result as a purely sequential or serial schedule.
What is Dirty Read in DBMS?
Dirty Read in DBMS is like taking a look at someone’s work in progress. In DBMS, it happens when a transaction reads data that has been modified by another transaction but not yet committed. It’s called ‘dirty’ because things might change.
Why Do We Need Serializability?
We need serializability to ensure that even with overlapping transactions, the end result is the same as if they happened one after another. It keeps the database reliable, accurate and more consistent.
