UNIVERSITY INSTITUTE OF

ENGINEERING

Department of Computer Science & Engineering

Databases Management System

(23CSH-205/23ITH-205)
DR. GITANJALI
E16525
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE
 ABOUT COURSE

• The main DBMS course, we learn about the structural formation of data, maintain data
integrity, multitasking with concurrent access and recovery without occurring crashes,
data structures, data models etc. and their working in which every organization is based.
• At the end of the course, the students may understand the concepts of data structures,
data models and design, construction of queries by using SQL, uses and applications of
database design etc
 COURSE OUTCOMES

CO No. Title BT Level

Will be covered in this
lecture
Students will be able to understand the database system
CO1
concepts and design databases for different applications.
Memorize

Students will be able to identify different types of DDL, DML,

CO2 DCL and TCL commands and their usage. Understanding

Students will be able to classifying Normalization,

CO3 Dependencies and Denormalization along with their Apply
requirements.
Students will be able to analyse and Compare Transaction
CO4
Processing techniques and Recovery techniques.
Analyze
Students will be able to evaluate database performance after
CO5 implementing Triggers, procedures, packages, cursors and Evaluate
views.
 COURSE OBJECTIVES
This course will enable students to,

1. To have good understanding of database system concepts and design databases for
different applications.
2. To learn how to use a DBMS and RDBMS.
3. To implement and understand different types of DDL, DML and DCL statements.
4. To understand transaction concepts related to databases and recovery/backup
techniques required for the proper storage of data.
 Topics covered

Transaction Management and Concurrency Control:

Introduction to Transaction Processing, Properties of Transactions, Serializability
and Recoverability, Need for Concurrency Control, Locking Techniques, Time
Stamping Methods, Optimistic Techniques and Granularity of Data items.
 Transaction Management
Transactions are a set of operations used to perform a
logical set of work. A transaction usually means that
the data in the database has changed. One of the
major uses of DBMS is to protect the user data from
system failures. It is done by ensuring that all the data
is restored to a consistent state when the computer is
restarted after a crash. The transaction is any one
execution of the user program in a DBMS. One of the
important properties of the transaction is that it
contains a finite number of steps. Executing the same
program multiple times will generate multiple
transactions.
 Transaction Management
Example: Consider the following example of transaction operations to be performed to
withdraw cash from an ATM vestibule.
Steps for ATM Transaction
1. Transaction Start.
2. Insert your ATM card.
3. Select a language for your transaction.
4. Select the Savings Account option.
5. Enter the amount you want to withdraw.
6. Enter your secret pin.
7. Wait for some time for processing.
8. Collect your Cash.
9. Transaction Completed.
 Transaction Management
A transaction can include the following basic
database access operation.
• Read/Access data (R): Accessing the
database item from disk (where the
database stored data) to memory variable.
• Write/Change data (W): Write the data
item from the memory variable to the
disk.
• Commit: Commit is a transaction control
language that is used to permanently save
the changes done in a transaction
 Transaction Management
Example: Transfer of 50₹ from Account A to Account B. Initially A= 500₹, B= 800₹.
This data is brought to RAM from Hard Disk.
 Transaction Management
Stages of Transaction

Note: The updated value of Account A = 450 ₹ and Account B = 850 ₹.

All instructions before committing come under a partially committed state and are stored in
RAM. When the commit is read the data is fully accepted and is stored on a Hard Disk.
 Transaction Management
Transaction States
Transactions can be implemented using SQL queries and Servers. In the diagram, you can
see how transaction states work.
 Transaction Management
Desirable Properties of Transaction (ACID Properties)
Transaction management in a Database Management System (DBMS) ensures that
database transactions are executed reliably and follow ACID properties: Atomicity,
Consistency, Isolation, and Durability. These principles help maintain data integrity, even
during failures or concurrent user interactions, ensuring that all transactions are either fully
completed or rolled back if errors occur.
 Atomicity
• States that all operations of the transaction take place at once if not, the transactions are
aborted.
• There is no midway, i.e., the transaction cannot occur partially. Each transaction is
treated as one unit and either run to completion or is not executed at all.
• Atomicity involves the following two operations:
• Abort: If a transaction stops or fails, none of the changes it made will be saved or
visible.
• Commit: If a transaction completes successfully, all the changes it made will be saved
and visible.

Atomicity
 Consistency
• The rules (integrity constraint) that keep the database accurate and consistent are
followed before and after a transaction.
• When a transaction is completed, it leaves the database either as it was before or in
a new stable state.
• This property means every transaction works with a reliable and consistent version
of the database.
• The transaction is used to transform the database from one consistent state to
another consistent state. A transaction changes the database from one consistent
state to another consistent state.

Consistency
 Isolation
• It shows that the data which is used at the time of execution of a transaction cannot be
used by the second transaction until the first one is completed.
• In isolation, if the transaction T1 is being executed and using the data item X, then that
data item can’t be accessed by any other transaction T2 until the transaction T1ends.
• The concurrency control subsystem of the DBMS enforced the isolation property

Isolation
 Durability
• The durability property is used to indicate the performance of the database’s consistent
state. It states that the transaction made the permanent changes.
• They cannot be lost by the erroneous operation of a faulty transaction or by the system
failure. When a transaction is completed, then the database reaches a state known as the
consistent state. That consistent state cannot be lost, even in the event of a system’s
failure.
• The recovery subsystem of the DBMS has the responsibility of Durability property.

Durability
 Failure Classification
To find that where the problem has occurred, we generalize a failure into the
following categories:
• Transaction failure
• System crash
• Disk failure
 1.Transaction Failure
The transaction failure occurs when it fails to execute or
when it reaches a point from where it can’t go any further.
If a few transactions or process is hurt, then this is called
as transaction failure.
Reasons for a transaction failure could be –
1. Logical errors: If a transaction cannot complete due
to some code error or an internal error condition, then
the logical error occurs.
2. Syntax error: It occurs where the DBMS itself
terminates an active transaction because the database
system is not able to execute it. For example, The
system aborts an active transaction, in case of
deadlock or resource unavailability.
 2. System Crash
System failure can occur due to power failure or other
hardware or software failure. Example: Operating
system error.
• Fail-stop assumption: In the system crash, non-
volatile storage is assumed not to be corrupted.
 3. Disk Failure
• It occurs where hard-disk drives or storage drives used to fail frequently. It was a
common problem in the early days of technology evolution.
• Disk failure occurs due to the formation of bad sectors, disk head crash, and
unreachability to the disk or any other failure, which destroy all or part of disk
storage.
 Serializability
Serializability
It is an important aspect of Transactions. In simple meaning, you can say that
serializability is a way to check whether two transactions working on a database are
maintaining database consistency or not.
It is of two types:

1. Conflict Serializability
2. View Serializability
 Conflict Serializable
Concurrency serializability, also known as conflict serializability, is a type of
concurrency control that guarantees that the outcome of concurrent transactions is
the same as if the transactions were executed consecutively.
• Conflict serializable schedules: A schedule is called conflict serializable if it
can be transformed into a serial schedule by swapping non-conflicting
operations.
• Non-conflicting operations: When two operations operate on separate data
items or the same data item but at least one of them is a read operation, they are
said to be non-conflicting.
 Conflicting Operations
Two operations are said to be conflicting if all conditions are satisfied:
• They belong to different transactions
• They operate on the same data item
• At Least one of them is a write operation
Example:
• Conflicting operations pair (R1(A), W2(A)) because they belong to two different
transactions on the same data item A and one of them is a write operation.
• Similarly, (W1(A), W2(A)) and (W1(A), R2(A)) pairs are also conflicting.
• On the other hand, the (R1(A), W2(B)) pair is non-conflicting because they
operate on different data items.
• Similarly, ((W1(A), W2(B)) pair is non-conflicting.
Consider the following schedule:

If Oi and Oj are two operations in a transaction and Oi< Oj (Oi is executed before Oj),
same order will follow in the schedule as well. Using this property, we can get two
transactions of schedule S1:
T1: R1(A), W1(A), R1(B), W1(B)
T2: R2(A), W2(A), R2(B), W2(B)
Possible Serial Schedules are: T1->T2 or T2->T1
Possible Serial Schedules are: T1->T2 or T2->T1

Swapping non-conflicting operations R2(A) and R1(B) in S1, the schedule becomes,

S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)

-> Similarly, swapping non-conflicting operations W2(A) and W1(B) in S11, the schedule
becomes,

S12: R1(A), W1(A), R1(B), W1(B), R2(A), W2(A), R2(B), W2(B)

S12 is a serial schedule in which all operations of T1 are performed before starting any operation
of T2. Since S has been transformed into a serial schedule S12 by swapping non-conflicting
operations of S1, S1 is conflict serializable.
 Conflict Equivalent
Two schedules are said to be conflict equivalent when one can be transformed to
another by swapping non-conflicting operations. In the example discussed above,
S11 is conflict equivalent to S1 (S1 can be converted to S11 by swapping non-
conflicting operations). Similarly, S11 is conflict equivalent to S12, and so on.
Note 1: Although S2 is not conflict serializable, still it is conflict equivalent to S21
and S22 because S2 can be converted to S21 and S22 by swapping non-conflicting
operations.
Note 2: The schedule which is conflict serializable is always conflict equivalent to
one of the serial schedule. S1 schedule discussed above (which is conflict
serializable) is equivalent to the serial schedule (T1->T2).
Advantages of Conflict Serializability
• Consistency: Conflict serializability guarantees that the transactions’ outcomes
correspond to the sequence in which they were carried out.
• Correctness: Regardless of the order in which transactions were submitted,
conflict serializability guarantees that transactions are executed correctly.
• Decreased Overhead: By doing away with pointless locking and other conflict
resolution techniques, conflict serializability lowers overhead.

Disadvantages of Conflict Serializability

• Complexity: Conflict serializability can be complex to implement, especially in
large and complex databases.
• Reduced Performance: Conflict serializability can reduce performance by
introducing delays and overhead due to locking and other conflict resolution
mechanisms.
• Limited Concurrency: Conflict serializability can limit the degree of
concurrency in the system because it may delay some transactions to avoid
conflicts.
 View Serializability
The View serializability is a concept that is used to compute whether schedules are
View-Serializable or not. A schedule is said to be View-Serializable if it is viewing
equivalent to a Serial Schedule (where no interleaving of transactions is possible).

Example: Understanding View-

Serializability first with a Schedule
S1 :
So, its Conflict Precedence Graph is as follows –

The above graph contains cycle/loop which

means it is not conflict-serializable but it does
not mean that it cannot be consistent and
equivalent to the serial schedule it may or may
not be.
LookSchedule S’1 :
In the above example if we do swapping among some transaction’s operation so our
table will look like this –
Its Precedence Graph is as follows –

Now, we see that the precedence graph of the second table does not contain any cycle/loop,
which means it is conflict serializable (equivalent to serial schedule, consistent) and the final
result is coming the same as the first table.
Note: In the above example we understood that if a schedule is Conflict-serializable so we can
easily predict that It would be –
Equivalent to a serial schedule,
Consistent,
And also, a View-Serializable.
 Schedule
Schedule, as the name suggests is a process of lining the transactions and executing
them one by one. When there are multiple transactions that are running in a
concurrent manner and the order of operation is needed to be set so that the
operations do not overlap each other, Scheduling is brought into play and the
transactions are timed accordingly.
It is of two types:
1. Serial Schedule
2. Non-Serial Schedule
 Types of Schedules in DBMS
Schedules in DBMS ensure that transactions are executed in a serializable order.
Understanding the types of schedules is crucial for ensuring database consistency.
 Serial Schedules:
Schedules in which the transactions are executed non-interleaved, i.e., a serial
schedule is one in which no transaction starts until a running transaction has ended
are called serial schedules. Example: Consider the following schedule involving two
transactions T 1 and T 2 .
where R(A) denotes that a read operation is performed on some data
item ‘A’ This is a serial schedule since the transactions perform
serially in the order T 1 —> T 2
 Non-Serial Schedule
This is a type of Scheduling where the operations of multiple transactions are
interleaved. This might lead to a rise in the concurrency problem. The transactions are
executed in a non-serial manner, keeping the end result correct and same as the serial
schedule. Unlike the serial schedule where one transaction must wait for another to
complete all its operation, in the non-serial schedule, the other transaction proceeds
without waiting for the previous transaction to complete. This sort of schedule does
not provide any benefit of the concurrent transaction. It can be of two types namely,
Serializable and Non-Serializable Schedule. The Non-Serial Schedule can be divided
further into Serializable and Non-Serializable.
 Serializable
This is used to maintain the consistency of the database. It is mainly used in the Non-
Serial scheduling to verify whether the scheduling will lead to any inconsistency or
not. On the other hand, a serial schedule does not need the serializability because it
follows a transaction only when the previous transaction is complete. The non-serial
schedule is said to be in a serializable schedule only when it is equivalent to the serial
schedules, for an n number of transactions. Since concurrency is allowed in this case
thus, multiple transactions can execute concurrently. A serializable schedule helps in
improving both resource utilization and CPU throughput. These are of two types:
• Conflict Serializable
• View Serializable
 Conflict Serializable
Concurrency serializability, also known as conflict serializability, is a type of
concurrency control that guarantees that the outcome of concurrent transactions
is the same as if the transactions were executed consecutively.
• Conflict serializable schedules: A schedule is called conflict serializable if
it can be transformed into a serial schedule by swapping non-conflicting
operations.
• Non-conflicting operations: When two operations operate on separate data
items or the same data item but at least one of them is a read operation, they
are said to be non-conflicting.
 Conflicting Operations
Two operations are said to be conflicting if all conditions are satisfied:
• They belong to different transactions
• They operate on the same data item
• At Least one of them is a write operation
Example:
• Conflicting operations pair (R1(A), W2(A)) because they belong to two different
transactions on the same data item A and one of them is a write operation.
• Similarly, (W1(A), W2(A)) and (W1(A), R2(A)) pairs are also conflicting.
• On the other hand, the (R1(A), W2(B)) pair is non-conflicting because they operate
on different data items.
• Similarly, ((W1(A), W2(B)) pair is non-conflicting.
 View Serializable Schedule
A View Serializable Schedule is a type of schedule in DBMS that ensures the final
outcome of the schedule is the same as that of a serial schedule, even if the operations
are interleaved.
It is broader than Conflict Serializable Schedules, meaning all conflict-serializable
schedules are view-serializable, but not all view-serializable schedules are conflict-
serializable.
Example of a View Serializable Schedule
• The initial read condition is satisfied as T2T2T2 reads AAA after
T1T1T1 writes it.
• The final write condition is satisfied as T3T3T3 performs the final write
on AAA.
• The read-write dependency condition is satisfied as T2T2T2 reads the
value of AAA written by T1T1T1.
Conditions for View Serializability A schedule is view-serializable if it
satisfies the following three conditions:
Initial Read Condition:
• If a transaction TiT_iTi​ reads a data item initially (i.e., no other transaction
writes it before TiT_iTi​), then in the equivalent serial schedule, TiT_iTi​
must also be the first to read that data item.
Final Write Condition:
• If a transaction TjT_jTj​ performs the final write on a data item in the
schedule, it must also perform the final write in the equivalent serial
schedule.
Read-Write Dependency Condition:
• If a transaction TkT_kTk​ reads a data item XXX written by TmT_mTm​ in
the schedule, then TkT_kTk​ must read XXX after TmT_mTm​ writes it in
the equivalent serial schedule.
Difference Between View Serializability and Conflict
Serializability
 1. Recoverable Schedules
A recoverable schedule ensures that if a transaction TiT_iTi​ reads data modified by
another transaction TjT_jTj​, TjT_jTj​ must commit before TiT_iTi​ commits. This
ensures that the database can be recovered to a consistent state if a failure occurs.
Key Features:
• Ensures no cascading aborts.
• Maintains consistency during failures.
Example of a Recoverable Schedule:
T2 reads the value of AAA written by T1T1T1.
T1T1T1 commits before T2T2T2, making the schedule recoverable.
Importance:
Recoverable schedules prevent data inconsistency during rollbacks.
 2. Non-Recoverable Schedules
A non-recoverable schedule occurs when a transaction TiT_iTi​ reads data written by
TjT_jTj​, but TjT_jTj​is not committed before TiT_iTi​commits. If TjT_jTj​later aborts,
it becomes impossible to maintain consistency because TiT_iTi​ has already committed
invalid data.

Example of a Non-Recoverable Schedule:

T2T2T2 reads the value of AAA written by T1T1T1.
T2T2T2 commits before T1T1T1, but T1T1T1 aborts, making
the data read by T2T2T2 invalid.
This leads to inconsistency and makes recovery impossible.
 Cascading Abort Schedules
A cascading abort schedule occurs when the failure of one transaction causes multiple
other transactions to roll back because they read uncommitted data.
Example:

T2 and T3T3T3 read uncommitted data written by

T1T1T1.
When T1T1T1 aborts, both T2T2T2 and T3T3T3 must
also abort, leading to a cascading rollback.
 Cascadeless Schedules
A cascadeless schedule avoids cascading aborts by ensuring that a transaction TiT_iTi​
can only read data written by another transaction TjT_jTj​ if TjT_jTj​ has already
committed.
Example:
• T2 reads the value of AAA only after T1T1T1 has committed, ensuring no
cascading aborts.

Benefits:
• Simplifies recovery.
• Reduces the number of transactions affected by rollbacks.
 Strict Schedules
A strict schedule ensures that a transaction TiT_iTi​ can neither read nor write a data
item modified by another transaction TjT_jTj​until TjT_jTj​has committed or aborted.
Example:
• T2 cannot access AAA until T1T1T1 has completed, making recovery
straightforward.

Benefits:
• Guarantees recoverability.
• Avoids cascading aborts.
Difference between Serial Schedule and
Serializable Schedule
Serial Schedule Serializable
Schedule
 Concurrency Control
Concurrency control is a very important concept of DBMS which ensures the
simultaneous execution or manipulation of data by several processes or user without
resulting in data inconsistency. Concurrency Control deals with interleaved execution
of more than one transaction.

Goals of Concurrency Control

1. Maintain Database Consistency: Ensure that the database remains in a consistent
state even when multiple transactions execute concurrently.
2. Isolation: Provide each transaction the illusion of being executed alone.
3. Maximize Throughput: Allow maximum concurrency without compromising data
integrity.
4. Avoid Anomalies: Prevent problems such as lost updates, dirty reads, uncommitted
data, and non-repeatable reads.
 Concurrency Control
• Executing a single transaction at a time will increase the waiting time of the other transactions
which may result in delay in the overall execution. Hence for increasing the overall
throughput and efficiency of the system, several transactions are executed.
• Concurrency control is a very important concept of DBMS which ensures the simultaneous
execution or manipulation of data by several processes or user without resulting in data
inconsistency.
• Concurrency control provides a procedure that is able to control concurrent execution of the
operations in the database.
• The fundamental goal of database concurrency control is to ensure that concurrent execution
of transactions does not result in a loss of database consistency. The concept of serializability
can be used to achieve this goal, since all serializable schedules preserve consistency of the
database. However, not all schedules that preserve consistency of the database are
serializable.
 Dirty Read Problem(Write-Read conflict)
Dirty read problem occurs when one transaction updates an item but due to some
unconditional events that transaction fails but before the transaction performs rollback,
some other transaction reads the updated value. Thus creates an inconsistency in the
database. Dirty read problem comes under the scenario of Write-Read conflict between
the transactions in the database
1. The lost update problem can be illustrated with the below scenario between two
transactions T1 and T2.
2. Transaction T1 modifies a database record without committing the changes.
3. T2 reads the uncommitted data changed by T1
4. T1 performs rollback
5. T2 has already read the uncommitted data of T1 which is no longer valid, thus
creating inconsistency in the database.
 Lost Update Problem
Lost update problem occurs when two or more transactions modify the same data,
resulting in the update being overwritten or lost by another transaction. The lost update
problem can be illustrated with the below scenario between two transactions T1 and
T2.
1. T1 reads the value of an item from the database.
2. T2 starts and reads the same database item.
3. T1 updates the value of that data and performs a commit.
4. T2 updates the same data item based on its initial read and performs commit.
5. This results in the modification of T1 gets lost by the T2’s write which causes a
lost update problem in the database.
 Concurrency Control Protocols
Concurrency control protocols are the set of rules
which are maintained in order to solve the concurrency
control problems in the database. It ensures that the
concurrent transactions can execute properly while
maintaining the database consistency. The concurrent
execution of a transaction is provided with atomicity,
consistency, isolation, durability, and serializability via
the concurrency control protocols.
• Locked based concurrency control protocol
• Timestamp based concurrency control protocol
 Locked based Protocol
In locked based protocol, each transaction needs to acquire locks before they start
accessing or modifying the data items. There are two types of locks used in databases.
• Shared Lock : Shared lock is also known as read lock which allows multiple
transactions to read the data simultaneously. The transaction which is holding a
shared lock can only read the data item but it can not modify the data item.
• Exclusive Lock : Exclusive lock is also known as the write lock. Exclusive lock
allows a transaction to update a data item. Only one transaction can hold the
exclusive lock on a data item at a time. While a transaction is holding an exclusive
lock on a data item, no other transaction is allowed to acquire a shared/exclusive
lock on the same data item.
 Phase Locking Protocol
There are two kind of Two-Phase protocol mostly used in database:
• Two Phase Locking Protocol : It is a widely used technique which ensures strict ordering of lock
acquisition and release. Two phase locking protocol works in two phases.
⚬ Growing Phase : In this phase, the transaction starts acquiring locks before performing any
modification on the data items. Once a transaction acquires a lock, that lock can not be
released until the transaction reaches the end of the execution.
⚬ Shrinking Phase : In this phase, the transaction releases all the acquired locks once it
performs all the modifications on the data item. Once the transaction starts releasing the
locks, it can not acquire any locks further.
• Strict Two-Phase Locking Protocol : It is almost similar to the two phase locking protocol the
only difference is that in two phase locking the transaction can release its locks before it
commits, but in case of strict two phase locking the transactions are only allowed to release the
locks only when they performs commits.
 Timestamp Based Concurrency Control
The main idea for this protocol is to order the transactions based on their Timestamps. A
schedule in which the transactions participate is then serializable and the only
equivalent serial schedule permitted has the transactions in the order of their Timestamp
Values. Stating simply, the schedule is equivalent to the particular Serial Order
corresponding to the order of the Transaction timestamps. An algorithm must ensure
that, for each item accessed by Conflicting Operations in the schedule, the order in
which the item is accessed does not violate the ordering. To ensure this, use two
Timestamp Values relating to each database item X.
• W­_TS(X) is the largest timestamp of any transaction that executed write(X)
successfully.
• R_TS(X) is the largest timestamp of any transaction that executed read(X)
successfully.
 Advantages of Concurrency Control
In general, concurrency means, that more than one transaction can work on a system.
The advantages of a concurrent system are:
• Waiting Time: It means if a process is in a ready state but still the process does not
get the system to get execute is called waiting time. So, concurrency leads to less
waiting time.
• Response Time: The time wasted in getting the response from the cpu for the first
time, is called response time. So, concurrency leads to less Response Time.
• Resource Utilization: The amount of Resource utilization in a particular system is
called Resource Utilization. Multiple transactions can run parallel in a system. So,
concurrency leads to more Resource Utilization.
• Efficiency: The amount of output produced in comparison to given input is called
efficiency. So, Concurrency leads to more Efficiency.
Disadvantages of Concurrency Control
• Overhead: Implementing concurrency control requires additional overhead, such as
acquiring and releasing locks on database objects. This overhead can lead to slower
performance and increased resource consumption, particularly in systems with high levels
of concurrency.
• Deadlocks: Deadlocks can occur when two or more transactions are waiting for each
other to release resources, causing a circular dependency that can prevent any of the
transactions from completing. Deadlocks can be difficult to detect and resolve, and can
result in reduced throughput and increased latency.
• Reduced concurrency: Concurrency control can limit the number of users or
applications that can access the database simultaneously. This can lead to reduced
concurrency and slower performance in systems with high levels of concurrency.
• Complexity: Implementing concurrency control can be complex, particularly in
distributed systems or in systems with complex transactional logic. This complexity can
lead to increased development and maintenance costs.
THANK YOU