Chapter 8: Relational Database

Design- Functional Dependencies

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Chapter 8: Relational Database Design

● Features of Good Relational Design

● Atomic Domains and First Normal Form
● Decomposition Using Functional Dependencies
● Functional Dependency Theory
● Algorithms for Functional Dependencies
● Decomposition Using Multivalued Dependencies
● More Normal Form
● Database-Design Process
● Modeling Temporal Data

Database System Concepts - 6th 8.2 ©Silberschatz, Korth and Sudarshan

 Combine Schemas?
● Suppose we combine instructor and department into inst_dept
● (No connection to relationship set inst_dept)
● Result is possible repetition of information

Database System Concepts - 6th 8.3 ©Silberschatz, Korth and Sudarshan

 A Combined Schema Without Repetition
● Consider combining relations
● sec_class(sec_id, building, room_number) and
● section(course_id, sec_id, semester, year)
into one relation
● section(course_id, sec_id, semester, year,
building, room_number)
● No repetition in this case

Database System Concepts - 6th 8.4 ©Silberschatz, Korth and Sudarshan

 What About Smaller Schemas?
● Suppose we had started with inst_dept. How would we know to split
up (decompose) it into instructor and department?
● Write a rule “if there were a schema (dept_name, building, budget), then
dept_name would be a candidate key”
● Denote as a functional dependency:
dept_name → building, budget
● In inst_dept, because dept_name is not a candidate key, the building
and budget of a department may have to be repeated.
● This indicates the need to decompose inst_dept
● Not all decompositions are good. Suppose we decompose
employee(ID, name, street, city, salary) into
employee1 (ID, name)
employee2 (name, street, city, salary)
● 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 - 6th 8.5 ©Silberschatz, Korth and Sudarshan

 A Lossy Decomposition

Database System Concepts - 6th 8.6 ©Silberschatz, Korth and Sudarshan

 Example of Lossless-Join Decomposition

● Lossless join decomposition

● Decomposition of R = (A, B, C)
R1 = (A, B) R2 = (B, C)

A B C A B B C
α 1 A α 1 1 A
β 2 B β 2 2 B
r ∏A,B(r) ∏B,C(r)

A B C
∏A (r) ∏B (r)
α 1 A
β 2 B

Database System Concepts - 6th 8.7 ©Silberschatz, Korth and Sudarshan

 Goal — Devise a Theory for the Following

● Decide whether a particular relation R is in “good” form.

● In the case that a relation R is not in “good” form, decompose it into a
set of relations {R1, R2, ..., Rn} such that
● each relation is in good form
● the decomposition is a lossless-join decomposition
● Our theory is based on:
● functional dependencies
● multivalued dependencies

Database System Concepts - 6th 8.8 ©Silberschatz, Korth and Sudarshan

 Functional Dependencies
● Constraints on the set of legal relations.
● Require that the value for a certain set of attributes determines
uniquely the value for another set of attributes.
● A functional dependency is a generalization of the notion of a key.

Database System Concepts - 6th 8.9 ©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

● On this instance, A → B does NOT hold, but B → A does hold.

Database System Concepts - 6th 8.10 ©Silberschatz, Korth and Sudarshan

 Functional Dependencies (Cont.)
● K is a superkey for relation schema R if and only if K → R
● K is a candidate key for R if and only if
● K → R, and
● for no α ⊂ K, α → R
● Functional dependencies allow us to express constraints that cannot be
expressed using superkeys. Consider the schema:
inst_dept (ID, name, salary, dept_name, building, budget ).
We expect these functional dependencies to hold:
dept_name→ building
and ID 🡪 building
but would not expect the following to hold:
dept_name → salary

Database System Concepts - 6th 8.11 ©Silberschatz, Korth and Sudarshan

 Use of Functional Dependencies

● We use functional dependencies to:

● test relations to see if they are legal under a given set of functional
dependencies.
4 If a relation r is legal under a set F of functional dependencies, we
say that r satisfies F.
● specify constraints on the set of legal relations
4 We say that F holds on R if all legal relations on R satisfy the set
of functional dependencies F.
● Note: A specific instance of a relation schema may satisfy a functional
dependency even if the functional dependency does not hold on all legal
instances.
● For example, a specific instance of instructor may, by chance, satisfy
name → ID.

Database System Concepts - 6th 8.12 ©Silberschatz, Korth and Sudarshan

 Functional Dependencies (Cont.)
● A functional dependency is trivial if it is satisfied by all instances of a
relation
● Example:
4 ID, name → ID
4 name → name
● In general, α → β is trivial if β ⊆ α

Database System Concepts - 6th 8.13 ©Silberschatz, Korth and Sudarshan

 Closure of a Set of Functional
Dependencies
● Given a set F of functional dependencies, there are certain other
functional dependencies that are logically implied by F.
● 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 - 6th 8.14 ©Silberschatz, Korth and Sudarshan

 Functional-Dependency Theory
● We now consider the formal theory that tells us which functional
dependencies are implied logically by a given set of functional
dependencies.
● We then develop algorithms to generate lossless decompositions into
BCNF and 3NF
● We then develop algorithms to test if a decomposition is
dependency-preserving

Database System Concepts - 6th 8.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.
● For e.g.: 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+.

Database System Concepts - 6th 8.16 ©Silberschatz, Korth and Sudarshan

 Closure of a Set of Functional
Dependencies

● We can find F+, the closure of F, by repeatedly applying

Armstrong’s Axioms:
● if β ⊆ α, then α → β (reflexivity)
● if α → β, then γ α → γ β (augmentation)
● if α → β, and β → γ, then α → γ (transitivity)
● These rules are
● sound (generate only functional dependencies that actually hold),
and
● complete (generate all functional dependencies that hold).

Database System Concepts - 6th 8.17 ©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+
● A→H
4 by transitivity from A → B and B → H
● AG → I
4 by augmenting A → C with G, to get AG → CG
and then transitivity with CG → I
● CG → HI
4 by augmenting CG → I to infer CG → CGI,
and augmenting of CG → H to infer CGI → HI,
and then transitivity

Database System Concepts - 6th 8.18 ©Silberschatz, Korth and Sudarshan

 Procedure for Computing F+
● To compute the closure of a set of functional dependencies 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

NOTE: We shall see an alternative procedure for this task later

Database System Concepts - 6th 8.19 ©Silberschatz, Korth and Sudarshan

 Closure of Functional Dependencies
(Cont.)
● Additional rules:
● If α → β holds and α → γ holds, then α → β γ holds (union)
● If α → β γ holds, then α → β holds and α → γ holds
(decomposition)
● If α → β holds and γ β → δ holds, then α γ → δ holds
(pseudotransitivity)
The above rules can be inferred from Armstrong’s axioms.

Database System Concepts - 6th 8.20 ©Silberschatz, Korth and Sudarshan

 Closure of Attribute Sets
● Given a set of attributes α, define the closure of α under F (denoted
by α+) as the set of attributes that are functionally determined by α
under F

● Algorithm to compute α+, the closure of α under F

result := α;
while (changes to result) do
for each β → γ in F do
begin
if β ⊆ result then result := result ∪ γ
end

Database System Concepts - 6th 8.21 ©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 - 6th 8.22 ©Silberschatz, Korth and Sudarshan

 Uses of Attribute Closure
There are several uses of the attribute closure algorithm:
● Testing for superkey:
● To test if α is a superkey, we compute α+, and check if α+ contains
all attributes of R.
● Testing functional dependencies
● To check if a functional dependency α → β holds (or, in other
words, is in F+), just check if β ⊆ α+.
● That is, we compute α+ by using attribute closure, and then check
if it contains β.
● Is a simple and cheap test, and very useful
● Computing closure of F
● For each γ ⊆ R, we find the closure γ+, and for each S ⊆ γ+, we
output a functional dependency γ → S.

Database System Concepts - 6th 8.23 ©Silberschatz, Korth and Sudarshan

 Canonical Cover
● Sets of functional dependencies may have redundant dependencies
that can be inferred from the others
● For example: A → C is redundant in: {A → B, B → C, A🡪 C}
● Parts of a functional dependency may be redundant
4 E.g.: on RHS: {A → B, B → C, A → CD} can be simplified
to
{A → B, B → C, A → D}
4 E.g.: on LHS: {A → B, B → C, AC → D} can be simplified
to
{A → B, B → C, A → D}
● Intuitively, a canonical cover of F is a “minimal” set of functional
dependencies equivalent to F, having no redundant dependencies or
redundant parts of dependencies

Database System Concepts - 6th 8.24 ©Silberschatz, Korth and Sudarshan

 Extraneous Attributes

● Consider a set F of functional dependencies and the functional

dependency α → β in F.
● Attribute A is extraneous in α if A ∈ α
and F logically implies (F – {α → β}) ∪ {(α – A) → β}.
● Attribute A is extraneous in β if A ∈ β
and the set of functional dependencies
(F – {α → β}) ∪ {α →(β – A)} logically implies F.
● Note: implication in the opposite direction is trivial in each of the
cases above, since a “stronger” functional dependency always
implies a weaker one
● Example: Given F = {A → C, AB → C }
● B is extraneous in AB → C because {A → C, AB → C} logically
implies A → C (I.e. the result of dropping B from AB → C).
● Example: Given F = {A → C, AB → CD}
● C is extraneous in AB → CD since AB → C can be inferred even
after deleting C

Database System Concepts - 6th 8.25 ©Silberschatz, Korth and Sudarshan

 Testing if an Attribute is Extraneous
● Consider a set F of functional dependencies and the functional
dependency α → β in F.
● To test if attribute A ∈ α is extraneous in α
1. compute ({α} – A)+ using the dependencies in F
2. check that ({α} – A)+ contains β; if it does, A is extraneous in α
● To test if attribute A ∈ β is extraneous in β
1. compute α+ using only the dependencies in
F’ = (F – {α → β}) ∪ {α →(β – A)},
2. check that α+ contains A; if it does, A is extraneous in β

Database System Concepts - 6th 8.26 ©Silberschatz, Korth and Sudarshan

 Canonical Cover
● A canonical cover for F is a set of dependencies Fc such that
● F logically implies all dependencies in Fc, and
● Fc logically implies all dependencies in F, and
● No functional dependency in Fc contains an extraneous attribute, and
● Each left side of functional dependency in Fc is unique.
● To compute a canonical cover for F:
repeat
Use the union rule to replace any dependencies in F
α1 → β1 and α1 → β2 with α1 → β1 β2
Find a functional dependency α → β with an
extraneous attribute either in α or in β
/* Note: test for extraneous attributes done using Fc, not F*/
If an extraneous attribute is found, delete it from α → β
until F does not change
● Note: Union rule may become applicable after some extraneous attributes
have been deleted, so it has to be re-applied

Database System Concepts - 6th 8.27 ©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
● Set is now {A → BC, B → C, AB → C}
● A is extraneous in AB → C
● Check if the result of deleting A from AB → C is implied by the other
dependencies
4 Yes: in fact, B → C is already present!
● Set is now {A → BC, B → C}
● C is extraneous in A → BC
● Check if A → C is logically implied by A → B and the other dependencies
4 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 - 6th 8.28 ©Silberschatz, Korth and Sudarshan

 Computing a Canonical Cover

Database System Concepts - 6th 8.29 ©Silberschatz, Korth and Sudarshan

 Computing a Canonical Cover

Database System Concepts - 6th 8.30 ©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 at least one of
the following dependencies is in F+:
● R1 ∩ R2 → R1
● R1 ∩ R2 → R2
● The above functional dependencies are a sufficient condition for
lossless join decomposition; the dependencies are a necessary
condition only if all constraints are functional dependencies

Database System Concepts - 6th 8.31 ©Silberschatz, Korth and Sudarshan

 Example
● R = (A, B, C)
F = {A → B, B → C)
● Can be decomposed in two different ways
● R1 = (A, B), R2 = (B, C)
● Lossless-join decomposition:
R1 ∩ R2 = {B} and B → BC
● Dependency preserving
● R1 = (A, B), R2 = (A, C)
● Lossless-join decomposition:
R1 ∩ R2 = {A} and A → AB
● Not dependency preserving
(cannot check B → C without computing R1 R2 )

Database System Concepts - 6th 8.32 ©Silberschatz, Korth and Sudarshan

 Dependency Preservation

● Let Fi be the set of dependencies F + that include only attributes in

Ri .
4 A decomposition is dependency preserving, if
(F1 ∪ F2 ∪ … ∪ Fn )+ = F +
4 If it is not, then checking updates for violation of functional
dependencies may require computing joins, which is
expensive.

Database System Concepts - 6th 8.33 ©Silberschatz, Korth and Sudarshan

 Testing for Dependency Preservation

● To check if a dependency α → β is preserved in a decomposition

of R into R1, R2, …, Rn we apply the following test (with attribute
closure done with respect to F)
● result = α
while (changes to result) do
for each Ri in the decomposition
t = (result ∩ Ri)+ ∩ Ri
result = result ∪ t
● If result contains all attributes in β, then the functional
dependency
α → β is preserved.
● We apply the test on all dependencies in F to check if a
decomposition is dependency preserving
● This procedure takes polynomial time, instead of the exponential
time required to compute F+ and (F1 ∪ F2 ∪ … ∪ Fn)+

Database System Concepts - 6th 8.34 ©Silberschatz, Korth and Sudarshan

 Example

Database System Concepts - 6th 8.35 ©Silberschatz, Korth and Sudarshan