Functional Dependencies and Normal Forms (Part 2)

Functional Dependencies and Normal Forms
(Part 2)
Database System Concepts, 7 th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
Recap on BCNF
 A relation schema <R(U), F> is in Boyce-Codd Normal Form (BCNF) if for

all functional dependencies X -> Y in F+ that are not trivial
• X is a superkey of R
 A schema in BCNF has no redundancies
 We have an algorithm that given <R(U), F>, constructs a decomposition

in BCNF such that:
• The decomposition is lossless
• Relations in the decomposition have no redundancy
 But… some functional dependencies might not be “preserved”
Database System Concepts - 7th Edition 7.2 ©Silberschatz, Korth and Sudarshan
BCNF and Dependency Preservation
 There are cases where there is no way to construct a BCNF

decomposition that also preserves FDs
 Example. < R(A,B,C), AB -> C, C->B >
 The schema is not in BCNF (C is not a superkey).

• redundancy: we are forced to repeat a value for B, each time a
certain value of C appears
 In any decomposition, no relation will have all three attributes A,B,C.

• AB -> C is lost.
 For example, < 𝑅1 𝐴, 𝐶 , ∅ >, < 𝑅2 𝐶, 𝐵 , 𝐶 → 𝐵 >
Dependency Preservation
 Why preserving FDs is important?

• if a table of some relation R is updated, we simply need to check if
R’s FDs are violated or not by the change
 If FDs are not preserved, we must perform a join to check that the FDs
we lost are satisfied
• Much more expensive check
 Example. < 𝑅1 𝐴, 𝐶 ,∅ >, < 𝑅2 𝐶, 𝐵 , 𝐶 → 𝐵 > (we lost AB -> C)
A C C B A B C
𝑎1 𝑐1 𝑐1 𝑏1 = 𝑎1 𝑏1 𝑐1
𝑎1 𝑐2 𝑐2 𝑏1 𝑎1 𝑏1 𝑐2
Dependency Preservation - Definition
 Consider a relation schema <R(U), F>. A decomposition
𝑅1 𝑿𝟏 , … , 𝑅𝑛 𝑿𝒏
preserves functional dependencies iff
(Π𝑿𝟏 𝐹 + ∪ ⋯ ∪ Π𝑿𝒏 (𝐹 + ))+ = 𝐹 +
 Intuition: by only using the FDs we inherit at each relation 𝑅𝑖, we can
logically derive all FDs that could be derived from the original FDs.
 Example. < R(A,B,C), AB -> C, C->B >

< 𝑅1 𝐴, 𝐶 ,∅ >, < 𝑅2 𝐶, 𝐵 , 𝐶 → 𝐵 >
• with only C -> B, AB cannot derive C, i.e., (AB) + does not contain C
Third Normal Form
 A relation schema <R(U), F> is in Third Normal Form (3NF) if for all
functional dependencies X -> Y in F+ that are not trivial
• X is a superkey of R, or
• Each attribute A in Y – X is contained in some candidate key for R.
 So, we slightly weaken the BCNF definition:

• Now, some redundancies are possible,
• but at least, with the second condition, we avoid some other issues
(next slide)
 Observation: If a schema is in BCNF then it is also in 3NF

• The vice versa is not always true
For checking 3NF, we can equivalently focus just on F, and not on its closure.
Transitive Dependencies
 Example.
Dept Floor Building City
Physics 1 Watson New York Floor, Building -> Dept
Physics 2 Watson New York Dept -> Building
Comp. Sci. 3 Taylor Chicago Building -> City
Comp. Sci. 2 Taylor Chicago
 Candidate keys: {Floor, Building}, and {Dept, Floor).

 The schema is not in 3NF (and thus also not in BCNF)
 To assign an additional floor to Physics, we must know:

• its building (Watson), but also, by transitivity,
• the city (New York)
 Example.
Dept Floor Building City

Physics 1 Watson New York Floor, Building -> Dept
Physics 2 Watson New York Dept -> Building
Comp. Sci. 3 Taylor Chicago Building -> City
Comp. Sci. 2 Taylor Chicago
 If we “break” the transitivity, by decomposing w.r.t. Building ->City:

Dept Floor Building
Physics 1 Watson Building City
Physics 2 Watson Watson New York
Comp. Sci. 3 Taylor Taylor Chicago
Comp. Sci. 2 Taylor Building -> City
Floor, Building -> Dept
Dept -> Building
 The schema is in 3NF, and in fact there are some redundancies.
 But, the transitive dependencies are gone.
Dept Floor Building
Physics 1 Watson Building City
Physics 2 Watson Watson New York
Comp. Sci. 3 Taylor Taylor Chicago
Comp. Sci. 2 Taylor Building -> City
Floor, Building -> Dept
Dept -> Building
 If we try to further decompose, we loose Floor, Building -> Dept
Dept Floor
Physics 1 Dept Building Building City
Physics 2 Physics Watson Watson New York
Comp. Sci. 3 Comp. Sci. Taylor Taylor Chicago
Comp. Sci. 2 Dept -> Building Building -> City
Algorithm for 3NF decomposition
 Algorithm: 3NF decomposition

• Input: <R(U), F> (where F is a minimal cover)
• Output: a decomposition of <R(U), 𝐹> in 3NF that is lossless and
preserves FDs
 For each FD 𝑓𝑖 : X -> A in F, construct < 𝑅𝑖 𝑋𝐴 ,Π𝑋𝐴 𝐹 + 𝑚𝑖𝑛 >
 If all the attributes of some 𝑅𝑖 are contained in the attributes of

some 𝑅𝑗
• remove 𝑅𝑖
 If for all schemas 𝑅𝑖, the attributes of 𝑅𝑖 do not contain a

candidate key of R
• Choose a candidate key K, and add < 𝑅0 𝐾 ,∅ >
Algorithm for 3NF decomposition
 Example. < R(A,B,C,D), F = AB->C, C->B, A->D >
 F is already a minimal cover.

 Candidate keys: AB, and AC.
 The schema is not in 3NF:
• A -> D violates the conditions
 Pick each FD, and construct the corresponding relation:

• < 𝑅1 𝐴, 𝐵, 𝐶 , 𝐴𝐵 → 𝐶, 𝐶 → 𝐵 >
• < 𝑅2 𝐶, 𝐵 ,𝐶 → 𝐵 >
• < 𝑅3 𝐴,𝐷 ,𝐴 → 𝐷 >
 Remove redundant relations:

• < 𝑅1 𝐴, 𝐵, 𝐶 , 𝐴𝐵 → 𝐶, 𝐶 → 𝐵 >
• < 𝑅3 𝐴,𝐷 ,𝐴 → 𝐷 >
 The attributes of 𝑅1 contain a candidate key of R (e.g., AB). Done
BCNF vs 3NF decompositions
 BCNF:
• + lossless
• + no redundancy
• - may not preserve FDs
 3NF:
• + lossless
• - some redundancies may remain
• + preserves FDs
 Which one to choose?

• Try BCNF first
• If loss of FDs is unavoidable, use 3NF.

Functional Dependencies and Normal Forms (Part 2)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Functional Dependencies and Normal Forms (Part 2)

Uploaded by

Copyright:

Available Formats

Functional Dependencies and Normal Forms

Database System Concepts, 7 th Ed.

 A relation schema <R(U), F> is in Boyce-Codd Normal Form (BCNF) if for

 A schema in BCNF has no redundancies

 We have an algorithm that given <R(U), F>, constructs a decomposition

 But… some functional dependencies might not be “preserved”

 There are cases where there is no way to construct a BCNF

 Example. < R(A,B,C), AB -> C, C->B >

 The schema is not in BCNF (C is not a superkey).

 In any decomposition, no relation will have all three attributes A,B,C.

 For example, < 𝑅1 𝐴, 𝐶 , ∅ >, < 𝑅2 𝐶, 𝐵 , 𝐶 → 𝐵 >

 Why preserving FDs is important?

 Example. < 𝑅1 𝐴, 𝐶 ,∅ >, < 𝑅2 𝐶, 𝐵 , 𝐶 → 𝐵 > (we lost AB -> C)

 Consider a relation schema <R(U), F>. A decomposition

preserves functional dependencies iff

(Π𝑿𝟏 𝐹 + ∪ ⋯ ∪ Π𝑿𝒏 (𝐹 + ))+ = 𝐹 +

 Example. < R(A,B,C), AB -> C, C->B >

 So, we slightly weaken the BCNF definition:

 Observation: If a schema is in BCNF then it is also in 3NF

 Candidate keys: {Floor, Building}, and {Dept, Floor).

 To assign an additional floor to Physics, we must know:

Dept Floor Building City

 If we “break” the transitivity, by decomposing w.r.t. Building ->City:

 If we try to further decompose, we loose Floor, Building -> Dept

 Algorithm: 3NF decomposition

 For each FD 𝑓𝑖 : X -> A in F, construct < 𝑅𝑖 𝑋𝐴 ,Π𝑋𝐴 𝐹 + 𝑚𝑖𝑛 >

 If all the attributes of some 𝑅𝑖 are contained in the attributes of

 If for all schemas 𝑅𝑖, the attributes of 𝑅𝑖 do not contain a

 Example. < R(A,B,C,D), F = AB->C, C->B, A->D >

 F is already a minimal cover.

 Pick each FD, and construct the corresponding relation:

 Remove redundant relations:

 Which one to choose?

You might also like