Professional Documents
Culture Documents
Database System Concepts - 5th Edition, July 28, 2005. 7.2 ©Silberschatz, Korth and Sudarshan
The Banking Schema
branch = (branch_name, branch_city, assets)
customer = (customer_id, customer_name, customer_street, customer_city)
loan = (loan_number, amount)
account = (account_number, balance)
employee = (employee_id. employee_name, telephone_number, start_date)
dependent_name = (employee_id, dname)
account_branch = (account_number, branch_name)
loan_branch = (loan_number, branch_name)
borrower = (customer_id, loan_number)
depositor = (customer_id, account_number)
cust_banker = (customer_id, employee_id, type)
works_for = (worker_employee_id, manager_employee_id)
payment = (loan_number, payment_number, payment_date, payment_amount)
savings_account = (account_number, interest_rate)
checking_account = (account_number, overdraft_amount)
Database System Concepts - 5th Edition, July 28, 2005. 7.3 ©Silberschatz, Korth and Sudarshan
Combine Schemas?
Database System Concepts - 5th Edition, July 28, 2005. 7.4 ©Silberschatz, Korth and Sudarshan
A Combined Schema Without Repetition
Database System Concepts - 5th Edition, July 28, 2005. 7.5 ©Silberschatz, Korth and Sudarshan
What About Smaller Schemas?
Suppose we had started with bor_loan. How would we know to split up
(decompose) it into borrower and loan?
Write a rule “if there were a schema (loan_number, amount), then
loan_number would be a candidate key”
Denote as a functional dependency:
loan_number → amount
In bor_loan, because loan_number is not a candidate key, the amount of a loan
may have to be repeated. This indicates the need to decompose bor_loan.
Not all decompositions are good. Suppose we decompose employee into
employee1 = (employee_id, employee_name)
employee2 = (employee_name, telephone_number, start_date)
The next slide shows how we lose information -- we cannot reconstruct the
original employee relation -- and so, this is a lossy decomposition.
Database System Concepts - 5th Edition, July 28, 2005. 7.6 ©Silberschatz, Korth and Sudarshan
A Lossy Decomposition
Database System Concepts - 5th Edition, July 28, 2005. 7.7 ©Silberschatz, Korth and Sudarshan
First Normal Form
Database System Concepts - 5th Edition, July 28, 2005. 7.8 ©Silberschatz, Korth and Sudarshan
First Normal Form (Cont’d)
Atomicity is actually a property of how the elements of the domain are
used.
z Example: Strings would normally be considered indivisible
z Suppose that students are given roll numbers which are strings of
the form CS0012 or EE1127
z If the first two characters are extracted to find the department, the
domain of roll numbers is not atomic.
z Doing so is a bad idea: leads to encoding of information in
application program rather than in the database.
Database System Concepts - 5th Edition, July 28, 2005. 7.9 ©Silberschatz, Korth and Sudarshan
Goal — Devise a Theory for the Following
Database System Concepts - 5th Edition, July 28, 2005. 7.10 ©Silberschatz, Korth and Sudarshan
Functional Dependencies
Database System Concepts - 5th Edition, July 28, 2005. 7.11 ©Silberschatz, Korth and Sudarshan
Functional Dependencies (Cont.)
Let R be a relation schema
α ⊆ R and β ⊆ R
The functional dependency
α→β
holds on R if and only if for any legal relations r(R), whenever any
two tuples t1 and t2 of r agree on the attributes α, they also agree
on the attributes β. That is,
t1[α] = t2 [α] ⇒ t1[β ] = t2 [β ]
Example: Consider r(A,B ) with the following instance of r.
1 4
1 5
3 7
Database System Concepts - 5th Edition, July 28, 2005. 7.12 ©Silberschatz, Korth and Sudarshan
Functional Dependencies (Cont.)
Database System Concepts - 5th Edition, July 28, 2005. 7.13 ©Silberschatz, Korth and Sudarshan
Use of Functional Dependencies
Database System Concepts - 5th Edition, July 28, 2005. 7.14 ©Silberschatz, Korth and Sudarshan
Functional Dependencies (Cont.)
Database System Concepts - 5th Edition, July 28, 2005. 7.15 ©Silberschatz, Korth and Sudarshan
Closure of a Set of Functional
Dependencies
Given a set F set of functional dependencies, there are certain other
functional dependencies that are logically implied by F.
z For example: If A → B and B → C, then we can infer that A → C
The set of all functional dependencies logically implied by F is the closure
of F.
We denote the closure of F by F+.
F+ is a superset of F.
Database System Concepts - 5th Edition, July 28, 2005. 7.16 ©Silberschatz, Korth and Sudarshan
Boyce-Codd Normal Form
A relation schema R is in BCNF with respect to a set F of
functional dependencies if for all functional dependencies in F+ of
the form
α→β
α → β is trivial (i.e., β ⊆ α)
α is a superkey for R
Database System Concepts - 5th Edition, July 28, 2005. 7.17 ©Silberschatz, Korth and Sudarshan
Decomposing a Schema into BCNF
Database System Concepts - 5th Edition, July 28, 2005. 7.18 ©Silberschatz, Korth and Sudarshan
BCNF and Dependency Preservation
Database System Concepts - 5th Edition, July 28, 2005. 7.19 ©Silberschatz, Korth and Sudarshan
Third Normal Form
Database System Concepts - 5th Edition, July 28, 2005. 7.20 ©Silberschatz, Korth and Sudarshan
Goals of Normalization
Database System Concepts - 5th Edition, July 28, 2005. 7.21 ©Silberschatz, Korth and Sudarshan
How good is BCNF?
There are database schemas in BCNF that do not seem to be
sufficiently normalized
Consider a database
classes (course, teacher, book )
Database System Concepts - 5th Edition, July 28, 2005. 7.22 ©Silberschatz, Korth and Sudarshan
How good is BCNF? (Cont.)
course teacher book
database Avi DB Concepts
database Avi Ullman
database Hank DB Concepts
database Hank Ullman
database Sudarshan DB Concepts
database Sudarshan Ullman
operating systems Avi OS Concepts
operating systems Avi Stallings
operating systems Pete OS Concepts
operating systems Pete Stallings
classes
course teacher
database Avi
database Hank
database Sudarshan
operating systems Avi
operating systems Jim
teaches
course book
database DB Concepts
database Ullman
operating systems OS Concepts
operating systems Shaw
text
This suggests the need for higher normal forms, such as Fourth
Normal Form (4NF), which we shall see later.
Database System Concepts - 5th Edition, July 28, 2005. 7.24 ©Silberschatz, Korth and Sudarshan
Functional-Dependency Theory
Database System Concepts - 5th Edition, July 28, 2005. 7.25 ©Silberschatz, Korth and Sudarshan
Closure of a Set of Functional
Dependencies
Given a set F set of functional dependencies, there are certain other
functional dependencies that are logically implied by F.
z For example: If A → B and B → C, then we can infer that A → C
The set of all functional dependencies logically implied by F is the closure
of F.
We denote the closure of F by F+.
We can find all of F+ by applying Armstrong’s Axioms:
z if β ⊆ α, then α → β (reflexivity)
z if α → β, then γ α → γ β (augmentation)
z if α → β, and β → γ, then α → γ (transitivity)
These rules are
z sound (generate only functional dependencies that actually hold) and
z complete (generate all functional dependencies that hold).
Database System Concepts - 5th Edition, July 28, 2005. 7.26 ©Silberschatz, Korth and Sudarshan
Example
R = (A, B, C, G, H, I)
F={ A→B
A→C
CG → H
CG → I
B → H}
some members of F+
z A→H
by transitivity from A → B and B → H
z AG → I
by augmenting A → C with G, to get AG → CG
and then transitivity with CG → I
z CG → HI
by augmenting CG → I to infer CG → CGI,
and augmenting of CG → H to infer CGI → HI,
and then transitivity
Database System Concepts - 5th Edition, July 28, 2005. 7.27 ©Silberschatz, Korth and Sudarshan
Procedure for Computing F+
F+=F
repeat
for each functional dependency f in F+
apply reflexivity and augmentation rules on f
add the resulting functional dependencies to F +
for each pair of functional dependencies f1and f2 in F +
if f1 and f2 can be combined using transitivity
then add the resulting functional dependency to F +
until F + does not change any further
Database System Concepts - 5th Edition, July 28, 2005. 7.28 ©Silberschatz, Korth and Sudarshan
Closure of Functional Dependencies
(Cont.)
We can further simplify manual computation of F+ by using the
following additional rules.
z If α → β holds and α → γ holds, then α → β γ holds (union)
z If α → β γ holds, then α → β holds and α → γ holds
(decomposition)
z If α → β holds and γ β → δ holds, then α γ → δ holds
(pseudotransitivity)
The above rules can be inferred from Armstrong’s axioms.
Database System Concepts - 5th Edition, July 28, 2005. 7.29 ©Silberschatz, Korth and Sudarshan
Closure of Attribute Sets
result := α;
while (changes to result) do
for each β → γ in F do
begin
if β ⊆ result then result := result ∪ γ
end
Database System Concepts - 5th Edition, July 28, 2005. 7.30 ©Silberschatz, Korth and Sudarshan
Example of Attribute Set Closure
R = (A, B, C, G, H, I)
F = {A → B
A→C
CG → H
CG → I
B → H}
(AG)+
1. result = AG
2. result = ABCG (A → C and A → B)
3. result = ABCGH (CG → H and CG ⊆ AGBC)
4. result = ABCGHI (CG → I and CG ⊆ AGBCH)
Is AG a candidate key?
1. Is AG a super key?
1.Does AG → R? == Is (AG)+ ⊇ R
2. Is any subset of AG a superkey?
1. Does A → R? == Is (A)+ ⊇ R
2. Does G → R? == Is (G)+ ⊇ R
Database System Concepts - 5th Edition, July 28, 2005. 7.31 ©Silberschatz, Korth and Sudarshan
Uses of Attribute Closure
There are several uses of the attribute closure algorithm:
Testing for superkey:
z To test if α is a superkey, we compute α+, and check if α+ contains
all attributes of R.
Testing functional dependencies
z To check if a functional dependency α → β holds (or, in other
words, is in F+), just check if β ⊆ α+.
z That is, we compute α+ by using attribute closure, and then check
if it contains β.
z Is a simple and cheap test, and very useful
Computing closure of F
z For each γ ⊆ R, we find the closure γ+, and for each S ⊆ γ+, we
output a functional dependency γ → S.
Database System Concepts - 5th Edition, July 28, 2005. 7.32 ©Silberschatz, Korth and Sudarshan
Canonical Cover
Database System Concepts - 5th Edition, July 28, 2005. 7.33 ©Silberschatz, Korth and Sudarshan
Extraneous Attributes
Database System Concepts - 5th Edition, July 28, 2005. 7.34 ©Silberschatz, Korth and Sudarshan
Testing if an Attribute is Extraneous
Database System Concepts - 5th Edition, July 28, 2005. 7.35 ©Silberschatz, Korth and Sudarshan
Canonical Cover
Database System Concepts - 5th Edition, July 28, 2005. 7.36 ©Silberschatz, Korth and Sudarshan
Computing a Canonical Cover
R = (A, B, C)
F = {A → BC
B→C
A→B
AB → C}
Combine A → BC and A → B into A → BC
z Set is now {A → BC, B → C, AB → C}
A is extraneous in AB → C
z Check if the result of deleting A from AB → C is implied by the other
dependencies
Yes: in fact, B → C is already present!
z Set is now {A → BC, B → C}
C is extraneous in A → BC
z Check if A → C is logically implied by A → B and the other dependencies
Yes: using transitivity on A → B and B → C.
– Can use attribute closure of A in more complex cases
The canonical cover is: A→B
B→C
Database System Concepts - 5th Edition, July 28, 2005. 7.37 ©Silberschatz, Korth and Sudarshan
Lossless-join Decomposition
For the case of R = (R1, R2), we require that for all possible
relations r on schema R
r = ∏R1 (r ) ∏R2 (r )
A decomposition of R into R1 and R2 is lossless join if and
only if at least one of the following dependencies is in F+:
z R1 ∩ R 2 → R1
z R1 ∩ R 2 → R2
Database System Concepts - 5th Edition, July 28, 2005. 7.38 ©Silberschatz, Korth and Sudarshan
Example
R = (A, B, C)
F = {A → B, B → C)
z Can be decomposed in two different ways
R1 = (A, B), R2 = (B, C)
z Lossless-join decomposition:
R1 ∩ R2 = {B} and B → BC
z Dependency preserving
R1 = (A, B), R2 = (A, C)
z Lossless-join decomposition:
R1 ∩ R2 = {A} and A → AB
z Not dependency preserving
(cannot check B → C without computing R1 R2)
Database System Concepts - 5th Edition, July 28, 2005. 7.39 ©Silberschatz, Korth and Sudarshan
Dependency Preservation
Database System Concepts - 5th Edition, July 28, 2005. 7.40 ©Silberschatz, Korth and Sudarshan
Testing for Dependency Preservation
Database System Concepts - 5th Edition, July 28, 2005. 7.41 ©Silberschatz, Korth and Sudarshan
Example
R = (A, B, C )
F = {A → B
B → C}
Key = {A}
R is not in BCNF
Decomposition R1 = (A, B), R2 = (B, C)
z R1 and R2 in BCNF
z Lossless-join decomposition
z Dependency preserving
Database System Concepts - 5th Edition, July 28, 2005. 7.42 ©Silberschatz, Korth and Sudarshan
Testing for BCNF
Database System Concepts - 5th Edition, July 28, 2005. 7.43 ©Silberschatz, Korth and Sudarshan
Testing Decomposition for BCNF
Database System Concepts - 5th Edition, July 28, 2005. 7.44 ©Silberschatz, Korth and Sudarshan
BCNF Decomposition Algorithm
result := {R };
done := false;
compute F +;
while (not done) do
if (there is a schema Ri in result that is not in BCNF)
then begin
let α → β be a nontrivial functional dependency that holds on Ri
such that α → Ri is not in F +,
and α ∩ β = ∅;
result := (result – Ri ) ∪ (Ri – β) ∪ (α, β );
end
else done := true;
Database System Concepts - 5th Edition, July 28, 2005. 7.45 ©Silberschatz, Korth and Sudarshan
Example of BCNF Decomposition
R = (A, B, C )
F = {A → B
B → C}
Key = {A}
R is not in BCNF (B → C but B is not superkey)
Decomposition
z R1 = (B, C)
z R2 = (A,B)
Database System Concepts - 5th Edition, July 28, 2005. 7.46 ©Silberschatz, Korth and Sudarshan
Example of BCNF Decomposition
Database System Concepts - 5th Edition, July 28, 2005. 7.47 ©Silberschatz, Korth and Sudarshan
BCNF and Dependency Preservation
R = (J, K, L )
F = {JK → L
L→K}
Two candidate keys = JK and JL
R is not in BCNF
Any decomposition of R will fail to preserve
JK → L
This implies that testing for JK → L requires a join
Database System Concepts - 5th Edition, July 28, 2005. 7.48 ©Silberschatz, Korth and Sudarshan
Third Normal Form: Motivation
Database System Concepts - 5th Edition, July 28, 2005. 7.49 ©Silberschatz, Korth and Sudarshan
3NF Example
Relation R:
z R = (J, K, L )
F = {JK → L, L → K }
z Two candidate keys: JK and JL
z R is in 3NF
JK → L JK is a superkey
L→K K is contained in a candidate key
Database System Concepts - 5th Edition, July 28, 2005. 7.50 ©Silberschatz, Korth and Sudarshan
Redundancy in 3NF
null l2 k2
Database System Concepts - 5th Edition, July 28, 2005. 7.51 ©Silberschatz, Korth and Sudarshan
Testing for 3NF
Optimization: Need to check only FDs in F, need not check all FDs in
F+.
Use attribute closure to check for each dependency α → β, if α is a
superkey.
If α is not a superkey, we have to verify if each attribute in β is
contained in a candidate key of R
z this test is rather more expensive, since it involve finding
candidate keys
z testing for 3NF has been shown to be NP-hard
z Interestingly, decomposition into third normal form (described
shortly) can be done in polynomial time
Database System Concepts - 5th Edition, July 28, 2005. 7.52 ©Silberschatz, Korth and Sudarshan
3NF Decomposition Algorithm
Database System Concepts - 5th Edition, July 28, 2005. 7.53 ©Silberschatz, Korth and Sudarshan
3NF Decomposition Algorithm (Cont.)
Database System Concepts - 5th Edition, July 28, 2005. 7.54 ©Silberschatz, Korth and Sudarshan
Example
Relation schema:
cust_banker_branch = (customer_id, employee_id, branch_name, type )
The functional dependencies for this relation schema are:
customer_id, employee_id → branch_name, type
employee_id → branch_name
The for loop generates:
(customer_id, employee_id, branch_name, type )
It then generates
(employee_id, branch_name)
but does not include it in the decomposition because it is a subset of the
first schema.
Database System Concepts - 5th Edition, July 28, 2005. 7.55 ©Silberschatz, Korth and Sudarshan
Comparison of BCNF and 3NF
Database System Concepts - 5th Edition, July 28, 2005. 7.56 ©Silberschatz, Korth and Sudarshan
Design Goals
Database System Concepts - 5th Edition, July 28, 2005. 7.57 ©Silberschatz, Korth and Sudarshan
Multivalued Dependencies (MVDs)
Database System Concepts - 5th Edition, July 28, 2005. 7.58 ©Silberschatz, Korth and Sudarshan
MVD (Cont.)
Tabular representation of α →→ β
Database System Concepts - 5th Edition, July 28, 2005. 7.59 ©Silberschatz, Korth and Sudarshan
Example
Database System Concepts - 5th Edition, July 28, 2005. 7.60 ©Silberschatz, Korth and Sudarshan
Example (Cont.)
In our example:
course →→ teacher
course →→ book
The above formal definition is supposed to formalize the
notion that given a particular value of Y (course) it has
associated with it a set of values of Z (teacher) and a set of
values of W (book), and these two sets are in some sense
independent of each other.
Note:
z If Y → Z then Y →→ Z
z Indeed we have (in above notation) Z1 = Z2
The claim follows.
Database System Concepts - 5th Edition, July 28, 2005. 7.61 ©Silberschatz, Korth and Sudarshan
Use of Multivalued Dependencies
Database System Concepts - 5th Edition, July 28, 2005. 7.62 ©Silberschatz, Korth and Sudarshan
Theory of MVDs
Database System Concepts - 5th Edition, July 28, 2005. 7.63 ©Silberschatz, Korth and Sudarshan
Fourth Normal Form
Database System Concepts - 5th Edition, July 28, 2005. 7.64 ©Silberschatz, Korth and Sudarshan
Restriction of Multivalued Dependencies
Database System Concepts - 5th Edition, July 28, 2005. 7.65 ©Silberschatz, Korth and Sudarshan
4NF Decomposition Algorithm
result: = {R};
done := false;
compute D+;
Let Di denote the restriction of D+ to Ri
while (not done)
if (there is a schema Ri in result that is not in 4NF) then
begin
let α →→ β be a nontrivial multivalued dependency that holds
on Ri such that α → Ri is not in Di, and α∩β=φ;
result := (result - Ri) ∪ (Ri - β) ∪ (α, β);
end
else done:= true;
Note: each Ri is in 4NF, and decomposition is lossless-join
Database System Concepts - 5th Edition, July 28, 2005. 7.66 ©Silberschatz, Korth and Sudarshan
Example
R =(A, B, C, G, H, I)
F ={ A →→ B
B →→ HI
CG →→ H }
R is not in 4NF since A →→ B and A is not a superkey for R
Decomposition
a) R1 = (A, B) (R1 is in 4NF)
b) R2 = (A, C, G, H, I) (R2 is not in 4NF)
c) R3 = (C, G, H) (R3 is in 4NF)
d) R4 = (A, C, G, I) (R4 is not in 4NF)
Since A →→ B and B →→ HI, A →→ HI, A →→ I
e) R5 = (A, I) (R5 is in 4NF)
f)R6 = (A, C, G) (R6 is in 4NF)
Database System Concepts - 5th Edition, July 28, 2005. 7.67 ©Silberschatz, Korth and Sudarshan
Further Normal Forms
Join dependencies generalize multivalued dependencies
z lead to project-join normal form (PJNF) (also called fifth normal
form)
A class of even more general constraints, leads to a normal form
called domain-key normal form.
Problem with these generalized constraints: are hard to reason with,
and no set of sound and complete set of inference rules exists.
Hence rarely used
Database System Concepts - 5th Edition, July 28, 2005. 7.68 ©Silberschatz, Korth and Sudarshan
Overall Database Design Process
Database System Concepts - 5th Edition, July 28, 2005. 7.69 ©Silberschatz, Korth and Sudarshan
ER Model and Normalization
Database System Concepts - 5th Edition, July 28, 2005. 7.70 ©Silberschatz, Korth and Sudarshan
Denormalization for Performance
Database System Concepts - 5th Edition, July 28, 2005. 7.71 ©Silberschatz, Korth and Sudarshan
Other Design Issues
Some aspects of database design are not caught by normalization
Examples of bad database design, to be avoided:
Instead of earnings (company_id, year, amount ), use
z earnings_2000, earnings_2001, earnings_2002, etc., all on the
schema (company_id, earnings).
Above are in BCNF, but make querying across years difficult
and needs new table each year
z company_year(company_id, earnings_2000, earnings_2001,
earnings_2002)
Also in BCNF, but also makes querying across years difficult
and requires new attribute each year.
Is an example of a crosstab, where values for one attribute
become column names
Used in spreadsheets, and in data analysis tools
Database System Concepts - 5th Edition, July 28, 2005. 7.72 ©Silberschatz, Korth and Sudarshan
Modeling Temporal Data
Temporal data have an association time interval during which the data
are valid.
A snapshot is the value of the data at a particular point in time.
Adding a temporal component results in functional dependencies like
customer_id → customer_street, customer_city
not to hold, because the address varies over time
A temporal functional dependency holds on schema R if the
corresponding functional dependency holds on all snapshots for all
legal instances r (R )
Database System Concepts - 5th Edition, July 28, 2005. 7.73 ©Silberschatz, Korth and Sudarshan
End of Chapter
Database System Concepts - 5th Edition, July 28, 2005. 7.76 ©Silberschatz, Korth and Sudarshan
Correctness of 3NF Decomposition
Algorithm (Cont’d.)
Claim: if a relation Ri is in the decomposition generated by the
above algorithm, then Ri satisfies 3NF.
Let Ri be generated from the dependency α → β
Let γ → B be any non-trivial functional dependency on Ri. (We need only
consider FDs whose right-hand side is a single attribute.)
Now, B can be in either β or α but not in both. Consider each case
separately.
Database System Concepts - 5th Edition, July 28, 2005. 7.77 ©Silberschatz, Korth and Sudarshan
Correctness of 3NF Decomposition
(Cont’d.)
Case 1: If B in β:
z If γ is a superkey, the 2nd condition of 3NF is satisfied
z Otherwise α must contain some attribute not in γ
z Since γ → B is in F+ it must be derivable from Fc, by using attribute
closure on γ.
z Attribute closure not have used α →β. If it had been used, α must
be contained in the attribute closure of γ, which is not possible, since
we assumed γ is not a superkey.
z Now, using α→ (β- {B}) and γ → B, we can derive α →B
(since γ ⊆ α β, and B ∉ γ since γ → B is non-trivial)
z Then, B is extraneous in the right-hand side of α →β; which is not
possible since α →β is in Fc.
z Thus, if B is in β then γ must be a superkey, and the second
condition of 3NF must be satisfied.
Database System Concepts - 5th Edition, July 28, 2005. 7.78 ©Silberschatz, Korth and Sudarshan
Correctness of 3NF Decomposition
(Cont’d.)
Case 2: B is in α.
z Since α is a candidate key, the third alternative in the definition of
3NF is trivially satisfied.
z In fact, we cannot show that γ is a superkey.
z This shows exactly why the third alternative is present in the
definition of 3NF.
Q.E.D.
Database System Concepts - 5th Edition, July 28, 2005. 7.79 ©Silberschatz, Korth and Sudarshan
Figure 7.5: Sample Relation r
Database System Concepts - 5th Edition, July 28, 2005. 7.80 ©Silberschatz, Korth and Sudarshan
Figure 7.6
Database System Concepts - 5th Edition, July 28, 2005. 7.81 ©Silberschatz, Korth and Sudarshan
Figure 7.7
Database System Concepts - 5th Edition, July 28, 2005. 7.82 ©Silberschatz, Korth and Sudarshan
Figure 7.15: An Example of
Redundancy in a BCNF Relation
Database System Concepts - 5th Edition, July 28, 2005. 7.83 ©Silberschatz, Korth and Sudarshan
Figure 7.16: An Illegal R2 Relation
Database System Concepts - 5th Edition, July 28, 2005. 7.84 ©Silberschatz, Korth and Sudarshan
Figure 7.18: Relation of Practice
Exercise 7.2
Database System Concepts - 5th Edition, July 28, 2005. 7.85 ©Silberschatz, Korth and Sudarshan