Lec 1-2 Relational Database Management Issues.pptx

Advanced DBMS
1st
Semester
Paper: COMP 105
Farhana Sultana
Assistant Professor
Department of Computer Science
University of Gour Banga

TRANSACTION PROCESSING
Lecture -1

Transaction
• A collection of operations that forms a single logical unit of
work.
• A transaction is an executing program that forms a logical unit
of database processing.
• A transaction is a unit of program execution that accesses and
possibly updates various data items.
Contd..

Transaction
• A transaction is initiated by a user program written in a high-
level data-manipulation language (typically SQL), or
programming language (for example, C++, or Java), with
embedded database accesses in JDBC or ODBC.
• A transaction is delimited by statements (or function calls) of
the form begin transaction and end transaction.
• The transaction consists of all operations executed between
the begin transaction and end transaction.
Contd..

An Example of Transaction
Account A Account B Sum of A and B
Balance: Rs.1000
Balance :
Rs. 500 Rs.1500
Transfer Rs. 200 from Account A to Account B
Balance after transfer :
Rs. 800
Balance after
transfer :
Rs. 700
Rs.1500
Contd..
• Transfer of money from account A to account B is a
transaction consisting of two updates, one to each account.

The transfer of money from Account A
to Account B is a transaction (Ti) which
includes below operations:
Ti : read(A);
A:=A-200;
write (A);
read (B);
B:=B+200;
write (B)
Contd..

Ti : read(A);
A:=A-200;
write (A);
read (B);
B:=B+200;
write (B)
What will happen when many
transactions executes
Simultaneously or Concurrently?
Contd..

Ti : read(A);
A:=A-200;
write (A);
read (B);
B:=B+200;
write (B)
T1 CPU I/O CPU I/O
T2 I/O CPU I/O CPU
Time Contd..
What will happen when many
transactions executes
Simultaneously or Concurrently?

A Case Study
Transaction 1
R(A)
A=A-200
W(A)
R(B)
B=B+200
W(B)
Balance of A: 1000
Balance of B: 500
After Transaction1:
Balance of A:(1000-200 )=800
Balance of B: (500+200)=700
Time

A Case Study
Transaction 1 Transaction 2
R(A)
A=A-200
W(A)
R(B)
B=B+200
W(B)
R(A)
A=A-100
W(A)
Balance of A: 1000
Balance of B: 500
After Transaction1:
Balance of A:(1000-200 )=800
Balance of B: (500+200)=700
After Transaction2:
Balance of A: (800-100)=700
Time

A Case Study
R(A)
A=A-200
W(A)
R(B)
B=B+200
W(B)
R(A)
A=A-100
W(A)
Balance of A: 1000
Balance of B: 500
After Transaction1:
Balance of A:?
Balance of B: ?
After Transaction2:
Balance A: ?

A Case Study
R(A)
A=A-200
W(A)
R(B)
B=B+200
W(B)
R(A)
A=A-100
W(A)
Balance of A: 1000
Balance of B: 500
After Transaction1:
Balance of A:?
Balance of B: ?
After Transaction2:
Balance A: ?
Whenever we
execute some
transactions in
interleaved
fashion there may
be some
inconsistency in
data

Transaction Management System
• Transaction Management System is a software which
manages the transaction in either interleaved way or in
sequential way.
• Whenever we are executing the transactions in interleaved
manner it should provide the same effect if it would have
done in sequential manner.
• The System must follow some properties to manage
transaction.

ACID Properties
• Atomicity
• Consistency
• Isolation
• Durability
Contd..

ACID Properties
• Atomicity: ‘All or None’ i.e. either all operations of
the transaction are reflected properly in the
database, or none are.
– Responsibility of transaction management system.
Contd..

ACID Properties
The transfer of money from A to B is a transaction(Ti) which
includes below operations
Ti : read(A);
A:=A-200;
write (A);
read (B);
B:=B+200;
write (B)
Contd..
• Atomicity:

ACID Properties
• Consistency : A transaction should be consistency
preserving, meaning that if it is completely executed
from beginning to end without interference from
other transactions, it should take the database from
one consistent state to another.
– Ensuring consistency for an individual transaction is the
responsibility of the application programmer who codes the
transaction.
Contd..

ACID Properties
Account A Account B Sum of A and B
Balance: Rs.1000
Balance :
Rs. 500 Rs.1500
Transfer Rs. 200 from Account A to Account B
Balance after transfer :
Rs. 800
Balance after
transfer :
Rs. 700
Rs.1500
Contd..
• Consistency :

ACID Properties
• Isolation: Even though multiple transactions may execute
concurrently, the system guarantees that, for every pair
of transactions Ti and Tj, it appears to Ti that either Tj
finished execution before Ti started or Tj started execution
after Ti finished. Thus, each transaction is unaware of
other transactions executing concurrently in the system.
– Responsibility of concurrency control manager
Contd..

ACID Properties
• Isolation:
Contd..

ACID Properties
• Durability: After a transaction completes
successfully, the changes it has made to the database
persist, even if there are system failures.
– Responsibility of recovery management system.
Contd..

ACID Properties
• Atomicity: all or none
• Consistency: no violation of integrity constraint
• Isolation: concurrent changes invisible
• Durability : committed updates persists

Transaction Processing Systems
• Transaction processing systems are systems with
large databases and hundreds of concurrent users
executing database transactions.
• Examples: airline reservations, banking, credit card
processing, online retail purchasing, stock markets,
supermarket checkouts, and many other
applications.

Data Item
• A database is basically represented as a collection of named
data items.
• A data item can be
– an individual field (attribute)
– a database record
– a whole relation or table
– a larger unit such as a whole disk block
• The size of a data item is called its granularity.

Database Access Operations
• The basic database access operations that a transaction can
include are as follows:
– read_item(X)/read(X)/r(X): Reads a database item named X
into a program variable.
– write_item(X)/write(X)/w(X): Writes the value of program
variable X into the database item named X.
• X can be any of the data items mentioned in the previous slide.
Contd..

Execution of read_item(X)
Executing a read_item(X) command
includes the following steps:
1. Find the address of the disk block that
contains item X.
2. Copy that disk block into a buffer in main
memory (if that disk block is not already
in some main memory buffer).
3. Copy item X from the buffer to the
program variable named X.
Contd..

Execution of write_item(X)
Executing a write_item(X) command includes
the following steps:
1. Find the address of the disk block that contains
item X.
2. Copy that disk block into a buffer in main memory
(if that disk block is not already in some main
memory buffer).
3. Copy item X from the program variable named X
into its correct location in the buffer.
4. Store the updated block from the buffer back to
disk (either immediately or at some later point in
time).

Transaction Operations and Transaction States
• A transaction is an atomic unit of work that
should either be completed in its entirety or not
done at all.
• For recovery purposes, the system needs to
keep track of when each transaction starts,
terminates, and commits or aborts.
Contd..

• Therefore, the recovery manager of the DBMS needs to keep track of the
following operations:
 BEGIN_TRANSACTION: This marks the beginning of transaction execution.
 READ or WRITE: These specify read or write operations on the database items that are
executed as part of a transaction.
 END_TRANSACTION: This specifies that READ and WRITE transaction operations have
ended and marks the end of transaction execution.
– At this point it may be necessary to check whether the changes introduced by the transaction can
be permanently applied to the database (committed) or whether the transaction has to be
aborted because it violates serializability.
Contd..

 COMMIT_TRANSACTION: signals a successful end of the transaction so that any
changes (updates) executed by the transaction can be safely committed to the
database and will not be undone.
 ROLLBACK (or ABORT): This signals that the transaction has ended unsuccessfully,
so that any changes or effects that the transaction may have applied to the
database must be undone.
Contd..

Figure: State transition diagram illustrating the states for transaction execution.

Some Related Concepts
• Single User System vs. Multiuser System
• Multiprogramming vs. Multiprocessing
• Concurrent transaction
– Interleaved Processing
– Parallel Processing
Contd..

Some Related Concepts
• Concurrent transaction:
Figure: Interleaved processing versus parallel processing of concurrent transactions.
Interleaved processing Parallel Processing

Questions?
• List the ACID properties. Explain the usefulness of each.
• Discuss the atomicity, durability, isolation, and consistency preservation
properties of a database transaction.
• Draw a state diagram and discuss the typical states that a transaction goes
through during execution.
• Discuss the actions taken by the read_item and write_item operations on
a database.

Concurrent Transaction
Figure: Interleaved processing versus parallel processing of concurrent transactions.
Interleaved processing Parallel Processing

Concurrency Control
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
read(A)
A:=A+500
write(A)
Transfer Rs. 200 from A to B Deposit Rs. 500 to A
Contd..
For concurrency control purposes, a transaction is a particular execution of a program
on a specific date, account holder, account number in a bank.

Concurrency Control
• Types of Problems
– The Lost Update Problem.
– The Temporary Update (or Dirty Read) Problem.
– The Incorrect Summary Problem.
– The Unrepeatable Read Problem.

Concurrency Control
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
read(A)
A:=A+500
write(A)
Time
A = 1000 B = 500
T1: A = 800 B = 700
T2: A = 1300
T1 and T2 are executed serially

Concurrency Control
• Lost Update Problem: (w – w conflict)
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
read(A)
A:=A+500
write(A)
Item A has an incorrect value because
its update by T1 is lost
Time
A=1000 B=500
T1: A=800 B= 700
T2: A = 1300 ?

Concurrency Control
• Lost Update Problem: (w – w conflict)
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
read(A)
A:=A+500
write(A)
Item A has an incorrect
value because its update
by T1 is lost
Time
A=1000 B=500
T1:
A=800 B= 700
T2: A= 1300
But in T2 , A= 1500
A = 1000
A = 800
A = 1000
A = 1500
A = 800
B = 500
A = 1500
B = 700
B = 700

Concurrency Control
• Lost Update Problem:
This problem occurs when two transactions that access the
same database items have their operations interleaved in a
way that makes the value of some database items incorrect.

Concurrency Control
• Temporary Update Problem:
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
read(A)
A:=A+500
write(A)
Time
A = 1000 B = 500
T1: A = 800 B = 700
T2: A = 1300

Concurrency Control
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
read(A)
A:=A+500
write(A)
Time
A = 1000
A = 800
A = 800
A = 800
A = 1300
A = 1300
B = 500
B = 700
B = 700

Concurrency Control
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
read(A)
A:=A+500
write(A)
Transaction T1 fails and must change the
value of A back to its old value;
meanwhile T2 has read the temporary
incorrect value of A
The value of item A that is read by T2 is
called dirty data because it has been
created by a transaction that has not
completed yet.
Time

Concurrency Control
This problem occurs when one transaction updates a
database item and then the transaction fails for some reason.
Meanwhile, the updated item is accessed (read) by another
transaction before it is changed back to its original value.

Concurrency Control
• Incorrect Summary Problem:
T1 T3
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
sum:=0
Read(K)
Sum:=Sum+K
Read(A)
Sum:=Sum+A
Read(B)
Sum:=Sum+B T3 reads A after Rs. 200 is subtracted and
reads B before Rs. 200 is added; a wrong
summary is the result (off by Rs 200)
Time
T3: Sum the salary of all employees
Employees: A, B, K
Salary of A= 500
B=600
K=1000

Concurrency Control
• Incorrect Summary Problem:
If one transaction is calculating an aggregate summary
function on a number of database items while other
transactions are updating some of these items, the aggregate
function may calculate some values before they are updated
and others after they are updated

Concurrency Control
• Unrepeatable Read Problem:
T1 T2
read(A)
read(A)
A:=A-200
write(A)
read(A)
A:=A+500
write(A)
T1 receives different values for its two
reads of the same item.
Time

Concurrency Control
• Unrepeatable Read Problem:
If a transaction Ti reads the same item twice and the item is
changed by another transaction Tj between the two reads,
then Ti will receive two different value for same read
operation.

Schedule
• When transactions are executing concurrently in an
interleaved fashion, then the order of execution of operations
from all the various transactions is known as a schedule (or
history).
• A schedule (or history) S of n transactions T1, T2, ..., Tn is an
ordering of the operations of the transactions.

Schedule (Example)
• Transaction T1 has two operations: a1, a2
• Transaction T2 has two operations: b1, b2
T1 T2
a1
a2
b1
b2
T1 T2
a1
a2
b1
b2
T1 T2
a1
a2
b1
b2
T1 T2
a1
a2
b1
b2
T1 T2
a1
a2
b1
b2
T1 T2
a1
a2
b1
b2

Schedule (Example)
Different Symbol used:
• b: begin_transaction,
• r: read_item,
• w: write_item,
• e: end_transaction,
• c: commit
• subscript: the transaction id
(transaction number) to each
operation in the schedule.
Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);

Number of Schedule Possible
• T1: n operations
• T2: m operations
• Number of Schedule Possible:
• Total number of Serial Schedule: 2! (Total umber of
transactions)
• Total number of non serial or concurrent schedule
possible: - 2!

Number of Schedule Possible
• Find the number of non-serial schedule
possible over 3 transactions with 2, 3, 4
operations respectively.

Types of Schedule
• Serial Schedule
• Complete Schedule
• Recoverable Schedule
• Cascading aborts and Cascadless Schedule
• Strict Schedule

Serial Schedule
• 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.

Complete Schedule
• A Schedule is said to be
complete if the last
operation of each
transaction is either
commit or abort.

Recoverable Schedule
• Once a transaction T is committed, it should never be necessary to roll
back T. This ensures that the durability property of transactions is not
violated.
• The schedules that theoretically meet this criterion are called
recoverable schedules.
• Those that do not are called nonrecoverable and hence should not be
permitted by the DBMS.
• A schedule S is recoverable if no transaction T in S commits until all
transactions T that have written some item X that T reads have
committed.

Recoverable Schedule
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
Commit
read(A)
A:=A+500
write(A)
Commit
Failed
and
Roll
Back
Non recoverable Schedule
T1 T2
read(A)
A:=A-200
write(A)
read(B)
B:=B+200
write(B)
Commit
read(A)
A:=A+500
write(A)
Commit
T2 must
commit
after T1
commits as
it read a
data A
which is
written by
T1.

Cascading aborts and Cascadless schedule
• If one transaction failure causes multiple transaction to
rollback, it is called cascading rollback or cascading aborts.
• A schedule is said to be Cascadless, or to avoid cascading
rollback, if every transaction in the schedule reads only items
that were written by committed transactions.

Cascading aborts and Cascadless schedule
T1 T2 T3
R(A)
W(A)
Commit
R(A)
W(A)
Commit
R(A)
W(A)
Commit
Failed
and
Roll
Back
Roll
Back
Roll
Back
Cascading Abort
T1 T2 T3
R(A)
W(A)
Commit
R(A)
W(A)
Commit
R(A)
W(A)
Commit
Cascadless Schedule

Strict Schedule
• A restrictive type of schedule, called a strict schedule, in
which transactions can neither read nor write an item X until
the last transaction that wrote X has committed (or aborted).
Strict schedules simplify the recovery process.
T1 T2
C
C
T1 T2
C
R
C
T1 T2
C
R
W
C

Serializable Schedule
• A transaction schedule is Serializable if its outcome is equal to
the outcome of transactions executed serially i.e. sequentially
without overlapping in time.
• The types of schedules that are always considered to
be correct when concurrent transactions are
executing are known as serializable schedules.

Serializability
• The concept of serializability of schedules is used to
identify which schedules are correct when transaction
executions have interleaving of their operations in
the schedules

Types of Serializability
• Result Equivalent Schedule
• Conflict Equivalent Schedule (Conflict Serializability)
• View Equivalent Schedule (View Serializability)
Contd…

• Result Equivalent Schedule:
Two schedules Si and Sj are said to be result
equivalent schedules if they produce the same final
database state.
Contd…

• Result Equivalent Schedule:
T1 T2
R(x)
X=x+5
W(x)
R(Y)
Y=Y+5
W(Y)
R(X)
X=X * 3
W(X)
T1 T2
R(x)
X=x+5
W(x)
R(Y)
Y=Y+5
W(Y)
R(X)
X=X * 3
W(X)
T1 T2
R(x)
X=x+5
W(x)
R(Y)
Y=Y+5
W(Y)
R(X)
X=X * 3
W(X)
S1 S2 S3
X = 2
Y = 5

• Conflict Equivalent Schedule:
Two schedules Si and Sj are said to be conflict
equivalent schedules if the conflict operations in
both the schedules execute in the same order
Ti Tj
R(A)
W(A)
W(A)
R(A)
W(A)
R(A)
W(A)
R(A)
Contd…

• Conflict Equivalent Schedule:
T1 T2
R1(A)
W1(A)
R1(B)
W1(B)
R2(A)
W2(A)
T1 T2
R1(A)
W1(A)
R1(B)
W1(B)
R2(A)
W2(A)
S1
S2
3 Conflicting
Operations
Order in which they
are appearing in S1:
R1 (A) W2(A)
W1(A) W2(A)
W1(A) R2(A)
Order in which they
are appearing in S2:
R1 (A) W2(A)
W1(A) W2(A)
W1(A) R2(A)
Conflict equivalent schedule

• View Equivalent Schedule:
A serial schedule and a non-serial schedule are said to be view equivalent if they
satisfy all of the following conditions:
a) If Ti reads initial value of ‘A’ in S, then Tj should also read initial value of data
item A in S’
b) If Ti produces final write operation of A in S then Tj should also perform the final
write operation of A in S’
c) If Tj reads a value produced by Ti in S . Then Tj also must read the value produce
by Ti in S’
 Here S is the serial schedule and S’ is the non serial schedule

• View Equivalent Schedule:
T1 T2
R(A)
A=A+10
W(A)
R(B)
B=B+20
W(B)
R(A)
A=A-10
W(A)
R(B)
B=B*1.1
W(B)
S1
T1 T2
R(A)
A=A+10
W(A)
R(B)
B=B+20
W(B)
R(A)
A=A-10
W(A)
R(B)
B=B*1.1
W(B)
S2
Data
Item
Read
First
Write
Last
A T1 T2
B T1 T2
For S1
Data
Item
Read
First
Write
Last
A T1 T2
B T1 T2
For S2
Write Read
Dependency Order
in S1:
T1(W(A)) T2(R(A))
T1(W(B)) T2(R(B))
Write Read
Dependency Order
in S2:
T1(W(A)) T2(R(A))
T1(W(B)) T2(R(B))

Questions?
1. What is a schedule (history)? Define the concepts of recoverable,
cascadeless, and strict schedules, and compare them in terms of their
recoverability.
2. Discuss the different measures of transaction equivalence. What is the
difference between conflict equivalence and view equivalence?
3. What is a serial schedule? What is a serializable schedule? Why is a
serial schedule considered correct? Why is a serializable schedule
considered correct?
4. Discuss how serializability is used to enforce concurrency control in a
database system. Why is serializability sometimes considered too
restrictive as a measure of correctness for schedules?
5. Define the violations caused by each of the following: dirty read,
nonrepeatable read, and phantoms.
6. Application oriented questions.

Lec 1-2 Relational Database Management Issues.pptx

More Related Content

Similar to Lec 1-2 Relational Database Management Issues.pptx (20)

Recently uploaded (20)

Lec 1-2 Relational Database Management Issues.pptx