Advanced database

TRANSACTIONS
Single and Multiusers Database
Classifying a database system according to the number of users who can
use the system concurrently:
1. single-user
only a single user can access the database. Hence, the user can use all the resources
at all times.
2. multi-user database systems.
These DBMSs support two or more two users accessing the database
simultaneously. Multiple users can update data while working together
simultaneously.

Example: Databases of Banks, insurance agencies, stock exchanges, supermarkets.

 Single User Database Systems Multi-User Database Systems
A DBMS is a multi-user if many/multi-users can
A DBMS is a single-user if at most one user at a
use the system and hence access the database
time can use the system.
concurrently.
Most DBMSs are multi-user, like databases of
Single-User DBMSs are mostly restricted to
airline reservation systems, banking databases,
personal computer systems.
etc.
Single user databases do not have Multiple users can access databases and use
multiprogramming thus, a single CPU can only computer systems simultaneously because of the
execute at most one process at a time. concept of Multiprogramming.
The data is neither integrated nor shared The data is integrated and shared among other
among any other user. users.
Example: Databases of Banks, insurance
Example: Personal Computers.
agencies, stock exchanges, supermarkets, etc.
• A and B, executing concurrently in an interleaved fashion. Interleaving keeps the
CPU busy when a process requires an input or output (I/O) operation, such as
reading a block from a disk. The CPU is switched to execute another process
rather than remaining idle during I/O time.
 Transactions

• A transaction is a program including a collection of database

operations, executed as a logical unit of data processing.
• The operations performed in a transaction include one or more of
database operations like insert, delete, update or retrieve data.
• It is an atomic process that is either performed into completion
entirely or is not performed at all.
• A transaction involving only data retrieval without any data update is
called read-only transaction.
Transactions
• Each high level operation can be divided into a number of low level
tasks or operations.
• For example, a data update operation can be divided into three
tasks :
read_item() − reads data item from storage to main memory.
modify_item() − change value of item in the main memory.
write_item() − write the modified value from main memory to
storage.
• Database access is restricted to read_item() and write_item()
operations.
Transaction Operations
• The low level operations performed in a transaction are :
• begin_transaction − A marker that specifies start of transaction
execution.
• read_item or write_item − Database operations that may be interleaved
with main memory operations as a part of transaction.
• end_transaction − A marker that specifies end of transaction.
• commit − A signal to specify that the transaction has been successfully
completed in its entirety and will not be undone.
• rollback − A signal to specify that the transaction has been unsuccessful
and so all temporary changes in the database are undone. A committed
transaction cannot be rolled back.
 Transaction States
• A transaction may go through a subset of five states:
• Active − The initial state where the transaction enters is the active state. The transaction
remains in this state while it is executing read, write or other operations.
• Partially Committed − The transaction enters this state after the last statement of the
transaction has been executed.
• Committed − The transaction enters this state after successful completion of the
transaction and system checks have issued commit signal.
• Failed − The transaction goes from partially committed state or active state to failed
state when it is discovered that normal execution can no longer proceed or system checks
fail.
• Aborted − This is the state after the transaction has been rolled back after failure and the
database has been restored to its state that was before the transaction began.
Desirable Properties of Transactions
• Any transaction must maintain the ACID properties.

• Atomicity − This property states that a transaction is an atomic unit of

processing, that is, either it is performed in its entirety or not
performed at all. No partial update should exist.
• Consistency − A transaction should take the database from one consistent state
to another consistent state.
• Isolation − A transaction should be executed as if it is the only one in the system.
There should not be any interference from the other concurrent transactions that
are simultaneously running.
• Durability − If a committed transaction brings about a change, that change
should be durable in the database and not lost in case of any failure.
 Atomicity

• Transactions do not occur partially.

• Each transaction is considered as one unit and either runs to completion or

is not executed at all. It involves the following two operations:

—Abort: If a transaction aborts, changes made to the database are not

visible.

—Commit: If a transaction commits, changes made are visible.

Atomicity is also known as the ‘All or nothing rule’.
Atomicity
• Consider the following transaction T consisting of T1 and T2: Transfer of 100
from account X to account Y.
Consistency
• This means that integrity constraints must be maintained so that
the database is consistent before and after the transaction.
• It refers to the correctness of a database.

• Referring to the example above, The total amount before and

after the transaction must be maintained.

Total before T occurs = 500 + 200 = 700.

Total after T occurs = 400 + 300 = 700.

Therefore, the database is consistent. Inconsistency occurs in case

T1 completes but T2 fails. As a result, T is incomplete.
Isolation
• Transactions occur independently without interference.
• Changes occurring in a particular transaction will not be visible to any other
transaction.
• This property ensures that the execution of transactions concurrently will result in
a state that these were executed serially in some order.

Let X = 500 , Y = 500.

Consider two transactions T and T”.

• Suppose T has been executed till Read (Y) and then T’’ starts.
As a result, interleaving of operations takes place due to
which T’’ reads the correct value of X but the incorrect value of Y
and sum computed by :
T’’: (X+Y = 50, 000+500=50, 500)
is thus not consistent with the sum at end of the transaction:
T: (X+Y = 50, 000 + 450 = 50, 450).
 Durability
• This property ensures that once the transaction has completed
execution, the updates and modifications to the database are stored
in and written to disk and they persist even if a system failure occurs.

• These updates now become permanent and are stored in non-

volatile memory.

• The effects of the transaction, thus, are never lost.

TRANSACTIONS
Lecture 2
Schedules

• a schedule is the total order of execution of operations.

• Given a schedule S comprising of n transactions, say T1, T2, T3………..Tn;

• for any transaction Ti, the operations in Ti must execute as laid down in the
schedule S.
Types of Schedules
• There are two types of schedules −
1- Serial Schedules − In a serial schedule, at any point of time, only
one transaction is active, i.e. there is no overlapping of transactions.
Types of Schedules

• For example: Suppose there are two transactions T1 and T2 which have some
operations. If it has no interleaving of operations, then there are the following two
possible outcomes:
1. Execute all the operations of T1 which was followed by all the operations of T2.

2. Execute all the operations of T2 which was followed by all the operations of T1.
Types of Schedules
• 2- Parallel Schedules − In parallel schedules, more than one transactions are
active simultaneously, i.e. the transactions contain operations that overlap at time.
Serializable schedule
• The serializability of schedules is used to find non-serial schedules
that allow the transaction to execute concurrently without interfering
with one another.
• It identifies which schedules are correct when executions of the
transaction have interleaving of their operations.
• A non-serial schedule will be serializable if its result is equal to the
result of its transactions executed serially.
 Testing of Serializability
• Serialization Graph is used to test the Serializability of a schedule.
• This graph has a pair G = (V, E), where V consists a set of vertices, and E consists
a set of edges.
• The set of vertices is used to contain all the transactions participating in the
schedule.
• The set of edges is used to contain all edges Ti ->Tj for which one of the three
conditions holds:
1 Create a node Ti → Tj if Ti executes write (Q) before Tj executes read (Q).
2 Create a node Ti → Tj if Ti executes read (Q) before Tj executes write (Q).
3 Create a node Ti → Tj if Ti executes write (Q) before Tj executes write (Q).
Testing of Serializability

• If a precedence graph contains a single edge Ti → Tj, then all the instructions
of Ti are executed before the first instruction of Tj is executed.

• If a precedence graph for schedule S contains a cycle, then S is non-

serializable.

• If the precedence graph has no cycle, then S is known as serializable.

Testing of Serializability (example 1)

Contains cycles
Not Serializable
Testing of Serializability (example 2)

Acyclic Graph
Serializable