DFC20203

DATABASE DESIGN
CHAPTER 5
DATABASE TRANSACTION MANAGEMENT
 COURSE LEARNING OUTCOME

Apply fundamental of DBMS, relational data

model and normalization concepts in database
development process. (CLO1)
Show a well-structured database using the
database query to manipulate a database with
an appropriate commercial Database
Management System (DBMS) in solving an
organization’s requirements.(CLO2)
 INTRODUCTION
• Database transactions reflect real-world transaction
that are triggered by events such as buying a product,
registering for a course or making a deposit in bank
account.
• Transactions are likely to contain many parts. For
example, a sales transaction may require updating the
customer’s account, adjusting the product inventory
and so on.
• All parts of a transaction must be successfully
completed to prevent data integrity problems.
• Therefore executing and managing transactions are
important to database system activities.
 WHAT IS A TRANSACTION?
• Any action that reads from and/or writes to a database
may consist of:
Simple SELECT statement to generate a list of table contents
A series of related UPDATE statements to change the values of
attributes in various tables
A series of INSERT statements to add rows to one or more tables
A combination of SELECT, UPDATE, and INSERT statements
 WHAT IS A TRANSACTION?
• A transaction is a logical unit of work that must be either entirely
completed or aborted.
• Successful transaction changes the database from one consistent state to
another.
– One in which all data integrity constraints are satisfied
• Most real-world database transactions are formed by two or more
database requests
– The equivalent of a single SQL statement in an application program or
transaction
 EVALUATING TRANSACTION RESULTS
• Not all transactions update the database.
• SQL code represents a transaction because database was
accessed.
• Improper or incomplete transactions can have a
devastating effect on database integrity
– Some DBMSs provide means by which user can define enforceable
constraints based on business rules
– Other integrity rules are enforced automatically by the DBMS
when table structures are properly defined, thereby letting the
DBMS validate some transactions
The Relational Schema for SaleCo Database
 TRANSACTION PROCESSING
• For example, a transaction may involve:
– The creation of a new invoice
– Insertion of an row in the LINE table
– Decreasing the quantity on hand by 1
– Updating the customer balance
– Creating a new account transaction row
• If the system fails between the first and last step, the
database will no longer be in a consistent state.
 TRANSACTION PROPERTIES

• DBMSs ensure that transactions obey certain

properties. The most important and widely
known properties are the ACID properties
(atomic, consistent, isolated, and durable) as
discussed next.
 TRANSACTION PROPERTIES
• ATOMIC means that a transaction cannot be subdivided.
Either all the work in the transaction is completed or
nothing is done.
• For example, the transfer of funds between two accounts
is a transaction. If we transfer $20 from account A to
account B, then at the end of the transaction A’s balance
will be $20 lower and B’s balance will be $20 higher (if
the transaction is completed) or neither balance will have
changed (if the transaction is aborted).
 TRANSACTION PROPERTIES
• CONSISTENT - when the transaction starts the entities are in a
consistent state, and when the transaction ends the entities are
once again in a consistent, albeit different, state.
• The implication is that the referential integrity rules and
applicable business rules still apply after the transaction is
completed.
• For example, if a user's account is balanced before a
transaction, then the account is balanced after the transaction.
Otherwise, the transaction is rejected and no changes take
effect.
 TRANSACTION PROPERTIES
• ISOLATED means that transactions do not interfere with each
other except in allowable ways. A transaction should never
overwrite changes made by another transaction. In addition, a
transaction may be restricted from interfering in other ways
such as not viewing the temporary changes made by other
transactions.
• For example, if a transaction T1 is being executed and is using
data item X, that data item cannot be accessed by any other
transaction (T2…Tn) until T1 ends.
 TRANSACTION PROPERTIES

• DURABLE means that any changes resulting

from a transaction are permanent. No failure will
erase any changes after a transaction terminates.
• For example, if a bank's computer experiences a
failure five minutes after a transaction completes,
the results of the transaction are still recorded on
the bank's database.
 EXAMPLE OF FUND TRANSFER
• Transaction to transfer RM50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
• Consistency requirement – the sum of A and B is unchanged by the
execution of the transaction.
• Atomicity requirement — if the transaction fails after step 3 and
before step 6, the system should ensure that its updates are not
reflected in the database, else an inconsistency will result.
 EXAMPLE OF FUND TRANSFER
(CONT)
• Durability requirement — once the user has been notified that the
transaction has completed (i.e., the transfer of the RM50 has taken
place), the updates to the database by the transaction must persist
despite failures.
• Isolation requirement — if between steps 3 and 6, another
transaction is allowed to access the partially updated database, it will
see an inconsistent database (the sum A + B will be less than it
should be).
TRANSACTION MANAGEMENT WITH
SQL
• ANSI has defined standards that govern SQL database transactions.
• Transaction support is provided by two SQL statements: COMMIT
(saves changes to disk) and ROLLBACK (restores the previous
database state).
• ANSI standards require that, when a transaction sequence is initiated
by a user or an application program, it must continue through all
succeeding SQL statements until one of four events occurs:
– COMMIT statement is reached
– ROLLBACK statement is reached
– End of program is reached
– Program is abnormally terminated
 You can do this with your
R friends. You can do this with
I your nose. But don't do it with
your friend's nose!
D
Mr. Brown was killed on Sunday
D afternoon. The wife said she
was reading a book. The butler
L said He was taking a shower.
E The chef said he was making
breakfast. The maid said she
was folding clothes, and the
gardener said he was planting
tomatoes. Who did it?
 TRANSACTION SYSTEM
• A transaction process system (TPS) is an information system that
collects, stores, modifies and retrieves the data transaction of an
enterprise.
• E.g: airline ticket reservation system, electronic banking.
• Category of TPS:
– Batch transaction processing system
– Online transaction processing system (OLTP)/ Real time
transaction processing system

https://www.techopedia.com/definition/707/transaction-process-system-tps
TRANSACTION SYSTEM CATEGORY
BATCH
• Batch processing is where the information is collected
TRANSACTIO and stored as a batch but not processed immediately.
N • Useful for enterprises that need to process large
amounts of data using limited resources.
PROCESSING • Example: credit card transactions.

SYSTEM
ONLINE
TRANSACTIO • A system whereby each transaction is processed
N immediately without the delay of accumulating
transactions into a batch.
PROCESSING • Also known as real time transaction processing system.
• Example: online shopping transaction, ATM, PayPal.
SYSTEM
(OLTP)
 CONCURRENCY CONTROL
• The coordination of the simultaneous execution
of transactions in a multiprocessing database is
known as concurrency control.

• The objective of concurrency control is to

ensure the serializability of transactions in a
multiuser database environment.
 CONCURRENCY CONTROL
– Importance of concurrency control  simultaneous execution of
transactions over a shared database can create several data integrity
and consistency problems.

Interference Problems
• Three problems that can result because of simultaneous access to a
database:
(1) lost update,
(2) uncommitted dependency / uncommitted data
(3) inconsistent retrieval.
NORMAL EXECUTION OF TWO
TRANSACTIONS
 INTERFERENCE PROBLEMS :
LOST UPDATE
• Lost update is the most serious interference problem
because changes to a database are inadvertently lost.
• In a lost update, one user's update overwrites another
user's update.
 INTERFERENCE PROBLEMS:
UNCOMMITTED DEPENDENCY
• An uncommitted dependency occurs when one
transaction reads data written by another transaction
before the other transaction commits.
• An uncommitted dependency is also known as a dirty
read because it is caused by one transaction reading dirty
(uncommitted) data.
• Violates the isolation property of transaction.
CORRECT EXECUTION OF TWO TRANSACTIONS
AN UNCOMMITTED DEPENDENCY
PROBLEM
 INCONSISTENT RETRIEVAL PROBLEM

• Occur when a transaction calculates some

aggregate functions over a set of data while
transactions are updating the data
–Some data may be read after they are changed and some
before they are changed yielding inconsistent results
RETRIEVAL DURING UPDATE
TRANSACTION RESULTS: DATA ENTRY
CORRECTION
INCONSISTENT RETRIEVALS

‘1558-QW1’
 THE SCHEDULER
• The scheduler is a special DBMS process that establishes the order
in which the operations are executed within concurrent
transactions.
• The scheduler interleaves the execution of database operations to
ensure serializability and isolation of transactions.
• To determine the appropriate order, the scheduler bases its actions
on concurrency control algorithms, such as locking or time stamping
methods.
• The scheduler’s main job is to create a serializable schedule of a
transaction’s operations, in which the interleaved execution of
the transactions (T1, T2, T3, etc.) yields the same results as if the
transactions were executed in serial order (one after another).

Database Systems: Design, Implementation and Management.12th Edition

(Carlos Coronel and Steven Morris)
 CONCURRENCY CONTROL TOOLS
In order to prevent the three interference
problems, most DBMS use these two tools:
(1) Lock
(2) Two-phase locking protocol
 LOCK
• A lock guarantees exclusive use of data item to a current
transaction.
• The lock prevents one transaction from using the data item
while another transaction is using it.
• Locking is necessary in a concurrent environment to assure
that one process does not retrieve or update a record that is
being updated by another process.
• Failure to use some controls (locking), would result in
inconsistent and corrupt data.
 EXAMPLE OF LOCK USED DURING MULTIPLE
TRANSACTIONS

Time Anna’s transaction Dean’s transaction

1 Lock account balance

2 Read account balance (balance = RM1000)

3 Request account balance (access is denied)
4 Withdraw RM600 (Balance = RM400)

5 Write account balance (balance = RM400)

6 Unlock account balance

7 Lock account balance

8 Read account balance (Balance = RM400)

9 Withdraw RM100 (Balance = RM300)

10 Write account balance (Balance = RM300)

11 Unlock account balance
 LOCK
GRANULARITY
(level of lock use)

DATABASE TABLE PAGE ROW FIELD

 DATABASE-LEVEL LOCK

 Good for batch processing but unsuitable for online multi-user

DBMSs.
 T1 and T2 can not access the same database concurrently even if they use
different tables.
 TABLE-LEVEL LOCK

 T1 and T2 can access the same database concurrently as long as they use
different tables.
 Can cause bottlenecks when many transactions are trying to access the same
table (even if the transactions want to access different parts of the table and would
not interfere with each other).
 Not suitable for multi-user DBMSs.
 PAGE-LEVEL LOCK

 An entire disk page is locked (a table can span several pages and each
page can contain several rows of one or more tables).
 Most frequently used multi-user DBMS locking method.
 ROW-LEVEL LOCK

 Concurrent transactions can access different rows of the same table

even if the rows are located on the same page.
 Improves data availability but with high overhead (each row has a
lock that must be read and written to).
 FIELD-LEVEL LOCK
 Allows concurrent transactions to access the
same row as long as they require the use of
different fields with that row.
 Most flexible lock buy requires an extremely
high level of overhead.
 LOCK TYPE

• Regardless of the level of locking, the DBMS

may use different lock types: binary, shared
or exclusive locks.
 BINARY LOCKS
 Has only two states: locked (1) or unlocked (0).
 Eliminates “Lost Update” problem – the lock is not released until the
write statement is completed.
 Can not use PROD_QOH until it has been properly updated.
 Considered too restrictive to yield optimal concurrency conditions as it locks
even for two READs when no update is being done.
 SHARED/EXCLUSIVE LOCKS
• EXCLUSIVE LOCK
– Access is specifically reserved for the transaction that locked the object.
– Must be used when the potential for conflict exists – when a transaction wants
to update a data item and no locks are currently held on that data item by
another transaction.
– Granted if and only if no other locks are held on the data item.
• SHARED LOCK
– Concurrent transactions are granted READ access on the basis of a common
lock.
– Issued when a transaction wants to read data and no exclusive lock is held on
that data item.
• Multiple transactions can each have a shared lock on the same data item if
they are all just reading it.
• MUTUAL EXCLUSIVE RULE
– Only one transaction at a time can own an exclusive lock in the same object.
 SHARED/EXCLUSIVE LOCKS
• Increased overhead
– The type of lock held must be known before a lock can be granted
– Three lock operations exist:
• READ_LOCK to check the type of lock
• WRITE_LOCK to issue the lock
• UNLOCK to release the lock
– A lock can be upgraded from share to exclusive and downgraded
from exclusive to share
• Two possible major problems may occur
– The resulting transaction schedule may not be serializable
– The schedule may create deadlocks
 TWO-PHASE LOCKING TO ENSURE
SERIALIZABILITY
• Defines how transactions acquire and relinquish
locks.
• Guarantees serializability, but it does not prevent
deadlocks.
– Growing phase, in which a transaction acquires all the
required locks without unlocking any data.
– Shrinking phase, in which a transaction releases all
locks and cannot obtain any new lock.
 TWO-PHASE LOCKING TO ENSURE
SERIALIZABILITY
• Governed by the following rules:
– Two transactions cannot have conflicting locks.
– No unlock operation can precede a lock operation in
the same transaction.
– No data are affected until all locks are obtained—that
is, until the transaction is in its locked point.
TWO-PHASE LOCKING PROTOCOL

• In this example, the transaction

acquires all the locks it needs
until it reaches its locked point.
(in this example, the transaction
requires two locks.)
• When the locked point is
reached, the data are modified to
conform to the transaction
requirements.
• Finally, the transaction is
completed as it releases all of the
locks it acquired in the first
phase.
 You are awoken at 3 A.M. by a knock
R on your door. Your parents call you
to let you know that they are there
I for breakfast. You are confused but
quickly think of what food you have.
D You have bread, jam, butter, and
eggs. What do you open first?
D
A thief enters a shop and threatens
L the clerk, forcing him to open the
safe. The clerk says, "The code for
E the safe is different every day, and
if you hurt me you'll never get the
code". But the thief manages to
guess the code on his own.
How did he do it?
 DEADLOCK
• Using locks to prevent interference problems can lead to deadlock problem.

• A deadlock is a problem of mutual waiting. One transaction has a resource that a second

transaction needs, and the second transaction holds a resource that the first transaction needs.

• For example, a deadlock occurs when two transactions, T1 and T2, exist in the following

mode:

– T1 = access data items X and Y

– T2 = access data items Y and X

• If T1 has not unlocked data item Y, T2 cannot begin; if T2 has not unlocked data item X, T1

cannot continue. Consequently, T1 and T2 each wait for the other to unlock the required data

item. Such a deadlock is also known as a deadly embrace.

EXAMPLE OF DEADLOCK
 TECHNIQUES TO CONTROL
DEADLOCK

DEADLOCK
CONTROL

DEADLOCK DEADLOCK DEADLOCK

PREVENTION DETECTION AVOIDANCE
 (1)DEADLOCK PREVENTION
• A transaction requesting a new lock is aborted when
there is the possibility that a deadlock can occur.
• If the transaction is aborted, all changes made by
this transaction are rolled back and all locks
obtained by the transaction are released.
• The transaction is then rescheduled for execution.
Deadlock prevention works because it avoids the
conditions that lead to deadlocking.
 (2)DEADLOCK DETECTION
• The DBMS periodically tests the database for
deadlocks.
• If a deadlock is found, the “victim” transaction is
aborted (rolled back and restarted) and the other
transaction continues.
 (3)DEADLOCK AVOIDANCE
• The transaction must obtain all of the locks it needs
before it can be executed.
• This technique avoids the rolling back of conflicting
transactions by requiring that locks be obtained in
succession.
• However, the serial lock assignment required in
deadlock avoidance increases action response times.
 DATABASE RECOVERY
MANAGEMENT
(1)Database recovery
(2)Transaction recovery
(3)Database backup
 DATABASE RECOVERY
• Database recovery restores a database from a given state
(usually inconsistent) to a previously consistent state.
• Recovery techniques are based on the atomic transaction
property: all portions of the transaction must be treated
as a single, logical unit of work in which all operations are
applied and completed to produce a consistent database.
• If a transaction operation cannot be completed for some
reason, the transaction must be aborted and any changes
to the database must be rolled back (undone).
• In short, transaction recovery reverses all of the changes
that the transaction made to the database before the
transaction was aborted.
 DATABASE RECOVERY

• Critical events can cause a database to stop

working and compromise the integrity of the
data.
• Critical events: hardware/software failures,
human-caused incidents and natural
disasters.
 EXAMPLE OF CRITICAL EVENTS
1 Hardware/software failures
• A failure of this type could be a hard disk media failure, a bad capacitor on a motherboard, or a failing memory
bank.
• Other causes of errors under this category include application program or operating system errors that cause data
to be overwritten, deleted, or lost.

2 Human-caused incidents
• This type of event can be categorized as unintentional or intentional.
• An unintentional failure is caused by a careless end user. Such errors include deleting the wrong rows from a table,
pressing the wrong key on the keyboard, or shutting down the main database server by accident.
• Intentional events are of a more severe nature and normally indicate that the company data is at serious risk.
Under this category are security threats caused by hackers trying to gain unauthorized access to data resources
and virus attacks caused by individuals trying to compromise the database operation and damage the company.

3 Natural disasters
• fires, earthquakes, floods, and power failures.
 TRANSACTION Log

• A DBMS uses a transaction log to keep track of all

transactions that update the database.

• The DBMS uses the information stored in this log for a

recovery requirement triggered by a ROLLBACK statement,
a program’s abnormal termination, or a system failure such
as a network discrepancy or a disk crash.
 TRANSACTION LOG
• The transaction log stores the following:
• A record for the beginning of the transaction.
• For each transaction component (SQL statement):
–– The type of operation being performed
(INSERT, UPDATE,DELETE).
–– The names of the objects affected by the transaction (the
name of the table).
–– The “before” and “after” values for the fields being updated.
–– Pointers to the previous and next transaction log entries for
the same transaction.
• The ending (COMMIT) of the transaction.
• Although using a transaction log increases the processing overhead of a
DBMS, the ability to restore a corrupted database is worth the price.
 TRANSACTION LOG

– If a system failure occurs, the DBMS will examine the log for all
uncommitted or incomplete transactions and it will restore (ROLLBACK)
the database to a previous state
– When the recovery process is completed, the DBMS will write in the
log all committed transactions that were not physically written to the
database before the failure occurred.
 TRANSACTION RECOVERY
• Database transaction recovery uses data in the
transaction log to recover a database from an
inconsistent state to a consistent state.
• Four important concepts that affect the recovery process:
1. Write-ahead-log protocol
2. Redundant transaction logs
3. Database buffers
4. Database checkpoints
 TRANSACTION RECOVERY
• The write-ahead-log protocol ensures that transaction
logs are always written before any database data is
actually updated. This protocol ensures that, in case of a
failure, the database can later be recovered to a
consistent state using the data in the transaction log.
• Redundant transaction logs (several copies of the
transaction log) ensure that a physical disk failure will not
impair the DBMS’s ability to recover data.
 TRANSACTION RECOVERY
• Database buffers are temporary storage areas in primary memory
used to speed up disk operations.
• To improve processing time, the DBMS software reads the data from
the physical disk and stores a copy of it on a “buffer” in primary
memory.
• When a transaction updates data, it actually updates the copy of the
data in the buffer because that process is much faster than
accessing the physical disk every time.
• Later, all buffers that contain updated data are written to a physical
disk during a single operation, thereby saving significant processing
time.
 TRANSACTION RECOVERY
• Database checkpoints are operations in which the DBMS writes all
of its updated buffers in memory (also known as dirty buffers) to
disk. While this is happening, the DBMS does not execute any other
requests.
• A checkpoint operation is also registered in the transaction log.
• As a result of this operation, the physical database and the
transaction log will be in sync.
• This synchronization is required because update operations update
the copy of the data in the buffers and not in the physical database.
 TRANSACTION RECOVERY
• Transaction recovery procedures generally make use of deferred-
write and write-through techniques.
• When the recovery procedure uses a deferred-write technique
(also called a deferred update), the transaction operations do not
immediately update the physical database. Instead, only the
transaction log is updated.
• The database is physically updated only with data from committed
transactions, using information from the transaction log.
• If the transaction aborts before it reaches its commit point, no
changes (no ROLLBACK or undo) need to be made to the database
because it was never updated.
 TRANSACTION RECOVERY
• When the recovery procedure uses a write-through technique (also
called an immediate update), the database is immediately updated
by transaction operations during the transaction’s execution, even
before the transaction reaches its commit point.
• If the transaction aborts before it reaches its commit point, a
ROLLBACK or undo operation needs to be done to restore the
database to a consistent state.
• In that case, the ROLLBACK operation will use the transaction log
“before” values.
 DATABASE BACKUP
• A backup is a copy of all or part of a disk. The backup is used when
the disk containing the database or log is damaged.
• A backup is usually made on magnetic tape because it is less
expensive and more reliable than disk.
• Periodically, a backup should be made for both the database and the
log. To save time, most backup schedules include less frequent
massive backups to copy the entire contents of a disk and more
frequent incremental backups to copy only the changed part.
 DATABASE BACKUP

• Types of backup:
–Periodic backup (e.g. nightly, weekly)
–Cold backup – database is shut down during
backup.
–Hot backup – selected portion is shut down
and backed up at a given time.
 DATABASE BACKUP
– Full backup: Full backup is a method of backup where all the
files and folders selected for the backup will be backed up.
When subsequent backups are run, the entire list of files and will
be backed up again.
– Incremental backup: Incremental backup is a backup of all
changes made since the last backup. With incremental backups,
one full backup is done first and subsequent backup runs are
just the changes made since the last backup.
– Example of incremental backup: For example, suppose that
you created a full backup on Monday, and used incremental
backups for the rest of the week. Tuesday's backup would only
contain the data that has changed since Monday. Wednesday's
backup would only contain the data that has changed since
Tuesday.
 DATABASE BACKUP
– Differential backup: Differential backup is a backup of all
changes made since the last full backup. With differential
backups, one full backup is done first and subsequent backup
runs are the changes made since the last full backup.
– Example of differential backup: Suppose for example that you
wanted to create a full backup on Monday and differential
backups for the rest of the week. Tuesday's backup would
contain all of the data that has changed since Monday. It would
therefore be identical to an incremental backup at this point. On
Wednesday, however, the differential backup would backup any
data that had changed since Monday.
 SUMMARY
• TRANSACTION SYSTEM.
• CATEGORY OF TRANSACTION SYSTEM.
• PROPERTIES OF TRANSACTION: ACID.
• SQL TCL STATEMENTS: START TRANSACTION, COMMIT, ROLLBACK.
• CONCURRENCY CONTROL.
• SIMULTANEOUS EXECUTION OF TRANSACTION PROBLEMS: LOST
UPDATE, UNCOMMITTED DATA & INCONSISTENT RETRIEVAL.
• LOCK METHOD.
• DEADLOCK PROBLEM.
• DATABASE RECOVERY MANAGEMENT.