Functional Dependencies and Normal Forms (Part 2) · 2020. 11. 30. · Database System Concepts -...

Database System Concepts, 7th Ed.

©Silberschatz, Korth and Sudarshan

See www.db-book.com for conditions on re-use

Functional Dependencies and Normal Forms

(Part 2)

http://www.db-book.com/

©Silberschatz, Korth and Sudarshan7.2Database System Concepts - 7th Edition

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”


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)

C B

𝑐1 𝑏1

𝑐2 𝑏1

A C

𝑎1 𝑐1

𝑎1 𝑐2

A B C

𝑎1 𝑏1 𝑐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.

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)

Dept Floor Building City

Physics 1 Watson New York


Comp. Sci. 3 Taylor Chicago


Floor, Building -> Dept

Dept -> Building

Building -> City



Example.

Dept Floor Building

Physics 1 Watson

Physics 2 Watson

Comp. Sci. 3 Taylor

Comp. Sci. 2 Taylor

Building City

Watson New York

Taylor Chicago


Dept -> Building

Building -> City

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

Dept Floor Building City






Dept -> Building

Building -> City



Dept Floor

Physics 1

Physics 2

Comp. Sci. 3

Comp. Sci. 2

Dept Building

Physics Watson

Comp. Sci. Taylor

Building City

Watson New York

Taylor Chicago

Dept -> Building Building -> City

Dept Floor Building

Physics 1 Watson

Physics 2 Watson

Comp. Sci. 3 Taylor

Comp. Sci. 2 Taylor

Building City

Watson New York

Taylor Chicago


Dept -> Building

Building -> City

The schema is in 3NF, and in fact there are some redundancies.

But, the transitive dependencies are gone.

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


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

• 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 𝐴, 𝐷 , 𝐴 → 𝐷 >

𝑅1 contains a candidate key (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) · 2020. 11. 30. · Database System Concepts -...

Documents

Transcript of Functional Dependencies and Normal Forms (Part 2) · 2020. 11. 30. · Database System Concepts -...