The Database Life Cycle (DBLC) d.

Create the physical design

3. Implementation and Loading
Within larger information systems, the database is
subject to a life cycle. It goes hand in hand with the a. Install the DBMS
System/Software Development life Cycle (SDLC). b. Create the database(s)
c. Load or convert the data
4. Testing and Evaluation
Database Initial Study Analysis
a. Test the database
b. Fine-tune the database
Database Design Detailed Design c. Evaluate the database and its application
programs
Implementation and 5. Operation
Coding
Loading Testing and
a. Produce the required information flow
Testing and Evaluation 6. Maintenance and evolution
Evaluation
a. Introduce changes
b. Make enhancements
Operation
Database Database Design Strategies
Application program
Maintenance and
maintenance Classic Approaches:
Evolution
1. Top-down design starts by identifying the data
sets, then defines the data elements for each of
1. Database Initial Study those sets. The entities are defined before the
attributes per entity.
a. Analyse the company situation
b. Define problems and constraints 2. Bottom-up design first identifies the data
c. Define objectives elements (items), then groups them together in
d. Define scope and boundaries data sets. The attributes are defined first then
2. Database Design are grouped to form the entities..
a. Create the conceptual design The design approach used often depends on the scope
b. DBMS software selection of the problem and on personal preferences. The
c. Create the logical design
approaches are complementary rather than mutually A transaction is a logical unit of work that must
exclusive. be entirely completed or entirely aborted.

A successful transaction changes the database from

one consistent state to another. A consistent
Database Design Philosophies database state is one in which all data integrity
constraints are satisfied.
The choice of design philosophy is essentially based on
the company’s structure as well as the scope and size Thus, to ensure consistency of the database, every
of the system. transaction must begin with the database in a known
consistent state, and the transaction itself should be
1. Centralized design is more productive when
successful (thereby changing to another consistent
the data component is composed of a relatively
state) or aborted (so it is reverted to the consistent
small number of objects and procedures. The
state it started with). Because of this, all transactions
database design can be represented in a fairly
are controlled and executed by the DBMS to guarantee
simple database. A single conceptual design is
database integrity.
completed and then validated.
Most transactions are composed of two or more
2. Decentralized design is more appropriate for
database requests. A database request is the
systems with data components that have a
equivalent of a single SQL statement in an application
considerable number of entities and complex
program or transaction.
relations on which complex operations are
performed. It is also applied when the problem
itself is spread across several operational sites
and each element is a subset of the entire data
set.
Transaction Properties

All transactions must display:

Transaction Management and Concurrency
Controls • Atomicity – this requires that all operations of a
transaction be completed; if not, the transaction
Basically, a transaction is any action that reads from is aborted.
and/or writes to a database. It may be as simple as a
SELECT statement; it may consist of any combination • Consistency – indicates the permanence of the
of SELECTs, INSERTs, UPDATEs and/or DELETEs. database’s consistent state.
 • Isolation – means that the data used during the
execution of a transaction cannot be used by a
second transaction until the first one is
completed. This is particularly useful in a multi-
user database environment.
• Durability – ensures that once transaction
changes are done (committed), they cannot be
undone or lost, even in the vent of system
failure.
• Serializability – ensures that the concurrent
execution of several transactions yield
consistent results. That is, the concurrent
execution of transactions T1, T2, and T3 yields
results that appear to have been executed in
serial order.
Transaction Management with SQL
ANSI has defined standards to govern over SQL
database transactions. Transaction support is provided
by: COMMIT and ROLLBACK. ANSI requires that when
a transaction sequence is initiated by the user or an
application program, the sequence must continue
through all succeeding statements until one of the
following occurs:
1. A COMMIT statement is reached. Changes are
permanently recorded within the database.
2. A ROLLBACK statement is reached. All changes
are aborted and the database is returned to the
previous consistent state.
3. The end of the program is successfully reached.
This should be equivalent to a COMMIT.
4. The program is abnormally terminated. This
should be equivalent to a ROLLBACK.
Transaction Log
A DBMS uses a transaction log to keep track of all
transactions that update the database. The
information may be used by the DBMS for a recovery
requirement by rollback statements, an abnormal
termination, or system failure.
Concurrency Control
The coordination of the simultaneous execution of
transactions in a multiuser database system is known
as concurrency control. Its main objective is to
ensure the Serializability of transactions in a multiuser
database environment.
Concurrency control aims to resolve:
1. Lost Updates
Without concurrency control, updates may be
lost.
Consider the following transactions:
T1 : purchase 100 units
T2 : sell 30 units
Both transactions refer to the same
product. The product currently has 35
units.
T1 and T2 read that value they each get
35.
Then T1 adds 100 units to that quantity
making it 135 (35 + 100) but T2 subtracts
30 units making it 5 (35-30).
 T1 then writes the updated value to the
database (quantity is 135).
T2 also writes the updated value to the
database (quantity is 5).
Because T2 writes after T1, T1’s update is lost,
the only transaction actually saved will be T2.
2. Uncommitted data
Using the same transactions and values,
consider this scenario:
T1 reads the quantity as 35.
T1 adds 100 units so quantity = 135.
T1 writes the new quantity (135).
T2 then reads the quantity as 135.
T2 computes for new value (135-
30=105).
T1 issues a ROLLBACK.
T2 writes the new quantity 105.
Because T2 read the uncommitted update of T1,
it violated the isolation property of transactions.
Once T1 is rolled back, then the quantity should
be 35 and T2’s update would make the final
quantity equal to 5.
3. Inconsistent retrievals
Inconsistent retrievals occur when a transaction
calculates some summary value (aggregate)
functions over a set of data while other
transactions are updating the data.
T1: SUM of quantity
T2: UPDATEs 2 products to correct a typing
error; that 10 units were added to product A but
it was actually meant for product AA. The
correction should be A-10 and AA+10
While T1 is summing up the quantities, it
may catch the values of A and AA when it
has deducted the value of 10 from A but
not yet added 10 to AA. The counts would
be off by 10.
Scheduler
The scheduler is a special DBMS program that
establishes the order in which the operations within
concurrent transactions are executed. The scheduler
interleaves the execution of database operations to
ensure Serializability and isolation of transactions.
Concurrency Control with Locking Methods
A lock guarantees exclusive use of a data item to a
current transaction. A transaction acquires a lock prior
to data access; the lock is released (unlocked) when
the transaction is completed so that another
transaction can lock and use the data item.
Lock granularity indicates the level of lock use,
Locking can take place at the following levels:
• Database
In a database-level lock, the entire database
is locked. This prevents the use of any tables in
the database by transaction T2 while
transaction T1 is being executed. This level is
good for batch processing but unsuitable for
online multiuser databases.
• Table
In a table-level lock, the entire table is locked.
This prevents the use of any rows from the
 locked table by T2. However, T2 can access the
same database as long as it accesses a different
table.
• Page
In a page-level lock, the DBMS locks the entire
diskpage. A diskpage, or page, is the
equivalent of a diskblock. A diskblock is the
directly accessible section of a disk. A page has
a fixed size, e.g. 4KB, 8KB, 16KB. If you have to
write 73bytes to a 4KB page, then the entire
4KB page must be read from disk, update din
memory, and written back to disk. A table can
span several pages, a page can contain several
rows of one or more tables.
• Row
A row-level lock is much less restrictive as it
allows concurrent transactions to access
different rows of the same table even when the
rows are located on the same page. This greatly
improves the availability of data but requires a
high overhead.
• Field
A field-level lock allows concurrent
transactions to access the same row as long as
they require different fields or attributes. This is
the most flexible but is rarely done due to the
extremely high level of overhead required.
Lock Types
1. Binary Locks
A binary lock has 2 states: locked (1) or
unlocked (0). If an object (database, table, page,
or row) is locked by a transaction, no other
transaction can use the object. It is unlocked
then any object can lock it for its use. As a rule,
a transaction must unlock the object after its
termination. Such operations are automatically
managed and scheduled by the DBMS, and
every DBMS has a default locking mechanism. If
the end user wants to override the default,
there are also SQL commands available for it.
2. Shared/Exclusive Locks
The labels “shared” and “exclusive” indicate the
nature of the lock. An exclusive lock exists
when access is reserved specifically for the
transaction that locked the object. It should be
used when the potential for conflict exists. A
shared lock exists when concurrent
transactions are granted access on the basis of
a common lock. It produces no conflict as long
as all concurrent transactions are read-only.
A shared lock is issued when a transaction
wants to read data and no exclusive lock is held
on that data item. An exclusive lock is issued
when a transaction wants to update (write) a
data item and no locks are currently held on
that data item.
A lock can then have three states: unlocked,
shared (read), and exclusive (write).
Still, the mutual exclusive rule is applied; only
one transaction at a time can own an exclusive
lock on the same object.
 data. Once all locks have been acquired, the
transaction is in its locked point.
Read/Write Conflict Scenarios:
2. A shrinking phase, in which a transaction
Transaction Transaction
T1 T2
RESULT releases all locks and cannot obtain any new
lock.
Read Read No conflict

Read Write Conflict

Write Read Conflict

Write Write Conflict Deadlocks

A deadlock occurs when two transactions wait for

each other to unlock data. To illustrate:

T1 = access data items X and Y

Issues with Locks
T2 = access data items Y and X
Although locks prevent serious data inconsistencies,
they can lead to two major problems: T1 locks data item X

• The resulting transaction may not be T2 locks data item Y

serializable
• The schedule may create deadlocks. A database
deadlock is caused when two transactions wait
for each other to unlock data.
Two-Phase Locking to Ensure Serializability
Two-phase locking (2PL) defines how transactions
acquires and relinquish locks. I can ensure
serializability but cannot prevent deadlocks. It is called
Two-phase locking because it consists of:
1. A growing phase, in which a transaction
acquires all required locks without unlocking
T1 waits for T2 to unlock data item Y
T2 waits for T1 to unlock T1
The above scenario is also known as a deadly
embrace.
In a real-world DBMS, many more transactions can be
executed simultaneously, thereby increasing the
probability of generating deadlocks.
It is important to note that deadlocks re only possible
when one of the transactions wants to obtain an
exclusive lock on a data item; no deadlock condition
can exists among shared locks.
The three basic techniques to control deadlocks are:
• 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 by the
transaction are rolled back and all locks are
released. The transaction is rescheduled for
execution.
• Deadlock detection. The DBMS periodically
tests the database for deadlocks. If a deadlock
is found, one of the transaction (the “victim”) is
aborted and the other transaction continues.
• Deadlock avoidance. The transaction must
obtain all of the locks it needs before it can be
executed. This technique avoids the rollback of
conflicting transactions by requiring that locks
be obtained in succession.
Concurrency Control with Time Stamping
Methods
The time stamping approach to scheduling
concurrent transactions assigns a global, unique
timestamp to each transaction. The time stamp value
produces an explicit order in which transactions are
submitted to the DBMS.
Time stamps must have two properties:
1. Uniqueness. This ensures that no equal time
stamp value can exist.
2. Monotonicity. This ensures that the time
stamp value always increases.
NB: the term monotonicity is part of the
standard control concurrency vocabulary.
All database operations (read and write) within the
same transaction must have the same timestamp. The
DBMS executes conflicting operations in time stamp
order, thereby ensuring serializability of the
transactions.
The disadvantage of the time stamping approach is
that each value stored in the database requires two
additional time stamp fields: one for the last time he
field was read and one for the last update, thus
increasing memory requirements and overhead cost.
Time stamping also tends to demand a lot of system
resources because many transactions may have to be
stopped, rescheduled, and restamped.
Wait/Die and Wound Wait Schemes
When using time stamps to manage concurrent
transactions, there are two schemes that can be
applied to decide which transaction is rolled back and
which continues executing:
Assume: T1 has time stamp of 11548789 and T2 has
time stamp of 19562545
Transacti Transacti
Wait/Die Wound/Wait
on on
Scheme Scheme
Requesti Owning
ng Lock Lock
T1 T2 • T1 waits until • T1 preempts
 T2 is
(rolls back) T2 • A differential backup of the database, in
• T2 is which only the last modifications to the
completed and
rescheduled database (compared to a previous backup copy)
T2 releases its
using the same are copied
locks
time stamp
• T2 dies (rolls • A transaction log backup, which backs up
back) • T2 waits until only the transaction log operations that are not
• T2 is T1 is reflected in a previous backup copy of the
T2 T1
rescheduled completed and
database.
using the T1 releases its
same time locks
The database backup is stored in a secure place,
stamp
usually in a different building, and is protected against
dangers such as fire, theft, flood, and other potential
In both schemes, transactions may wait for lock calamities. The backup’s existence guarantees
requests and that may cause deadlocks, to prevent database recovery following system
this, each lock request has an associated time-out (hardware/software) failures.
value. If the lock is not granted before the time-out
Causes / Factors of system failures:
expires, the transaction is rolled back.
• Software

o Software-induced failures are often traced

Database Recovery Management
back to the OS, the DBMS software,
Database recovery restores a database from a given application programs, or viruses.
state, usually inconsistent, to a previously consistent
state. Recovery techniques are based on the atomic • Hardware
transaction property: all portions of the transaction
o May include: memoty chip errors, disk
must be treated as a single, logical unit of work in
crashes, bad disk sectors, and disk full
which all operations are applied and completed to
errors.
produce a consistent database.

Levels of backup: • Programming exceptions

o Application programs or end users may

• A full backup of the database, or dump of the
database roll back transactions when certain
conditions are defined.

• Transactions
 o The system detects deadlocks and aborts
one of the transactions.
• External Factors
o Fire, earthquake, flood, or other natural
disasters
Concepts that affect the recovery process:
• The write-ahead-log-protocol. This ensures
that transaction logs are always written before
any database data are actually updated so that,
in case of 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 copy is
available even when there is physical disk
failure.
• Database buffers. A buffer is a temporary
storage area in primary memory used to speed
up disk operations. To improve processing time,
DBMS software reads the data from the physical
disk and stores a copy of it in the buffer. When a
transaction updates data , it updates the copy of
the data in the buffer. Later all buffers that
contain updated data are written to a physical
disk during a single operation.
• Database checkpoints. A database checkpoint
is an operation in which the DBMS writes all of
its updated buffers to disk. The DBMS does not
execute any other requests and checkpoint
operations are registered in the transaction log.
Transaction Recovery
The database recovery process involves bringing the
database to a consistent state after a failure.
Transaction recovery procedures generally make use
of deferred-write and write-through techniques.
When the recovery procedure uses deferred-write or
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 after transaction reaches its
commit point, using the transaction log information. If
the transaction aborts before it reaches to its commit
point, no changes (no ROLLBACK or undo) need to be
made to the database because the database was
never updated. The recovery process for all started
and committed transaction (before the failure) will
follow the steps:
1. Identify the last checkpoint in he transaction
log. This is the last time transaction data was
physically save to disk.
2. For the transaction started and committed
before the last checkpoint, nothing needs to be
done because the data are already saved.
3. For a transaction that performed a omit
operation after the last checkpoint, the DBMS
uses the transaction log records to redo the
transaction and to update the database, using
the ”after” values in the transaction log. The
changes are made in ascending order, from
oldest to newest.
 4. For any transaction of any ROLLBACK operation
after the last checkpoint or that was left active
(with neither a COMMIT nor a ROLLBACK) before
the failure occurred, nothing needs to be done
because the database was never updated.
ROLLBACK) before the failure occurred, the
DBMS uses the transaction log records to
ROLLBACK or undo the operations, using the
“before” values in the transaction log. Changes
are applied in reverse order, from newest to
oldest.

When the recovery procedures uses write-through or

immediate update, the database is immediately
updated by transaction operations during the
transaction’s execution, even before the transaction
reaches to its commit point. If the transaction aborts
before it reaches its commit point, a ROLLBACK or
undo operation needs to be done to restore te
database to a consistent state. In that case, the
ROLLBACK operation will use the transaction log
“before” values. The recovery process will follow the
steps:

1. Identify the last checkpoint in the transaction

log. This is the last time transaction data were
physically saved to disk.

2. For a transaction that started and committed

before the last checkpoint, nothing needs to be
done because the data are already saved.

3. For a transaction that committed after the last

checkpoint, the DBMS redoes the transaction,
using the “after” values of the transaction log.
Changes are applied in ascending order, from
oldest to newest.

4. For any transaction that had a ROLLBACK

operation after the last checkpoint or that was
left active (with neither a COMMIT nor a