Lossless Decomposition& 4NF

Prof. Sin-Min Lee

Department of Computer Science

1. Closure • Given a set of functional dependencies, F, its

closure, F+ , is all FDs that are implied by FDs in F.

• e.g. If A B, and B C,

• then clearly A C

Armstrong’s Axioms• We can find F+ by 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).

Additional rules• If and , then (union)

• If , then and (decomposition)

• If and , then

(pseudotransitivity)

The above rules can be inferred from Armstrong’s

axioms.

Example• R = (A, B, C, G, H, I)

F = { A B A CCG HCG I B H}

• Some members of F+

– A H • by transitivity from A B and B H

– AG I • by augmenting A C with G, to get AG CG

and then transitivity with CG I

– CG HI • by augmenting CG I to infer CG CGI, and augmenting of CG H to infer CGI HI, and then transitivity

2. Closure of an attribute set• Given a set of attributes A and a set of FDs F, closure of A under F is

the set of all attributes implied by A

• In other words, the largest B such that:• A B• Redefining super keys:• The closure of a super key is the entire relation schema• Redefining candidate keys:• 1. It is a super key• 2. No subset of it is a super key

Computing the closure for A

• Simple algorithm

• 1. Start with B = A.

• 2. Go over all functional dependencies, , in F+

• 3. If B, then

• Add to B

• 4. Repeat till B changes

Example• R = (A, B, C, G, H, I)F = { A B

A CCG HCG 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. It is a super key.

2. (A+) = BC, (G+) = G.

YES.

Uses of attribute set closures

• Determining superkeys and candidate keys

• Determining if A B is a valid FD• Check if A+ contains B

• Can be used to compute F+

Database Normalization

Functional dependency (FD) means that if

there is only one possible value of Y for every value of X, then

Y is Functionally dependent on X.

Is the following FDs hold?

YX

X Y Z10 B1 C1

10 B2 C2

11 B4 C1

12 B3 C4

13 B1 C1

14 B3 C4

YX

YZ

ZY

XY

• Functional Dependency is “good”. With functional dependency the primary key (Attribute A) determines the value of all the other non-key attributes (Attributes B,C,D,etc.)

• Transitive dependency is “bad”. Transitive dependency exists if the primary/candidate key (Attribute A) determines non-key Attribute B, and Attribute B determines non-key Attribute C.

• If a relation schema has more than one key, each is called a candidate key

• An attribute in a relation schema R is called prim if it is a member of some candidate key of R

Database Normalization

Third Normal Form (3NF)Remove transitive dependencies.

Transitive dependencyA non-prime attribute is dependent on another, non-prime A non-prime attribute is dependent on another, non-prime attribute or attributesattribute or attributesAttribute is the result of a calculationAttribute is the result of a calculation

Examples:Area code attribute based on City attribute of a customerTotal price attribute of order entry based on quantity attribute and unit price attribute (calculated value)

Solution:• Any transitive dependencies are moved into a smaller table.

Transitive Dependence

Give a relation R,

Assume the following FD hold:

Note : Both Ename and Address attributes are non-key attributes in R, and since

Address depends on a non-Prime attribute Name, which depends on the primary

key(EmpNo), a transitive dependency exists

EmpNo EName Salary Address

AddressEmpNoAddresstEnameEnameEmpNo ,,

AddressEname

EmpNo EName Salary Ename Address

R1 R2

Note : If address is a prime attribute Then R is in 3NF

Modification Anomalies

• What happens when you want to– add a new book?– change the address of a patron?– delete a patron record?

PatronName

PatronAddress

BookID

BookTitle

BookAuthor

BorrowDate

DueDate

ReturnDate

SmithJonesHartHicksRiceJones

12 Elk25 Sun73 Sera22 Main69 Witt25 Sun

AAABBBCCCAAADDDCCC

PeaceWarSystemPeaceSpringSystem

BartHineVangBartLyonVang

2/42/42/52/122/61/26

2/182/182/192/252/202/7

2/152/192/232/282/82/6

Modification Anomalies• Deletion anomaly

– deleting one fact about an entity deletes a fact about another entity

• Insertion anomaly– cannot insert one fact about an entity unless a

fact about another entity is also added

• Update anomaly– changing one fact about an entity requires

multiple changes to a table

Referential Integrity Constraint

• When we split a relation, we must pay attention to the references across the newly formed relations

• E.g., a book must exist before it can be checked out:– CHECKOUT [BookID] BOOK [BookID]

• The DBMS or the applications will have to check/enforce constraints

Boyce-Codd Normal Form

• Every determinant is a candidate key– ADVISER(SID,Major,Fname)

– STU-ADV(SID,Fname)ADV-SUBJ(Fname,Subject)

• Boyce-Codd Normal Form (BCNF)

– A relation is in Boyce-Codd normal form (BCNF) if every determinant in the table is a candidate key.

(A determinant is any attribute whose value determines other values with a row.)

– If a table contains only one candidate key, the 3NF and the BCNF are equivalent.

– BCNF is a special case of 3NF.

Database NormalizationDatabase Normalization

A Table That Is In 3NF But Not In BCNF

Figure 5.7

The Decomposition of a Table Structure to Meet BCNF Requirements

Figure 5.8

Lossless-join Decomposition● For the case of R = (R1, R2), we require that

for all possible relations r on schema R

r = R1 (r ) |X| 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+:

● R1 R2 R1

● R1 R2 R2

● 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 |X| R2)

Dependency Preservation● Let Fi be the set of dependencies F +

that include only attributes in Ri. ● A decomposition is dependency preserving, if

(F1 F2 … Fn )+ = F +

● If it is not, then checking updates for violation of functional dependencies may require computing joins, which is expensive.

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 decompositiont = (result Ri)+ Ri

result = result t● If result contains all attributes in , then the

functional dependency is preserved.

Dependency Preservation

● 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)+

FD Example● R = (A, B, C )

F = {A B, B C}Key = {A}

● R is not in BCNF● Decomposition R1 = (A, B), R2 = (B,

C)● R1 and R2 now in BCNF● Lossless-join decomposition● Dependency preserving

A Lossy Decomposition

Aim of Normalization

• Goal for a relational database design is:– BCNF.

– Lossless join.

– Dependency preservation.

• If we cannot achieve this, we accept one of– Lack of dependency preservation

– Redundancy due to use of 3NF

Sample Data for a BCNF Conversion

Table 5.2

Decomposition into BCNF

Perform lossless-join decompositions of each of the following scheme into BCNF schemes: R(A, B, C, D, E) with dependency set {AB CDE, C D, D E}

A B C D A B C D

C D D EA B C E A B C D

C DD E A B C A B C

Given the FDs {B D, AB C, D B} and the relation {A, B, C, D}, give a two distinct lossless join decomposition to BNCF indicating the keys of each of the resulting relations.

A B C D

B D A B C

A B C D

B D A C D

Normalization

Good Decomposition • dependency preserving decomposition

- it is undesirable to lose functional dependencies during decomposition

• lossless join decomposition

- join of decomposed relations should be able to create the original relation (no spurious tuples)

Decomposition and 4NF

• If X ->->Y is a 4NF violation for relation R, we can decompose R using the same technique as for BCNF.

1. XY is one of the decomposed relations.

2. All but Y – X is the other.

Example

Drinkers(name, addr, phones, beersLiked)

FD: name -> addr

MVD’s: name ->-> phones

name ->-> beersLiked

• Key is {name, phones, beersLiked}.

• All dependencies violate 4NF.

Example, Continued

• Decompose using name -> addr:

1. Drinkers1(name, addr) In 4NF, only dependency is name -> addr.

2. Drinkers2(name, phones, beersLiked) Not in 4NF. MVD’s name ->-> phones and

name ->-> beersLiked apply. No FD’s, so all three attributes form the key.

Example: Decompose Drinkers2

• Either MVD name ->-> phones or name ->-> beersLiked tells us to decompose to:– Drinkers3(name, phones)– Drinkers4(name, beersLiked)

BCNF

• Given a relation schema R, and a set of functional dependencies F, if every FD, A B, is either:

• 1. Trivial

• 2. A is a superkey of R

• Then, R is in BCNF (Boyce-Codd Normal Form)

• Why is BCNF good ?

BCNF

• What if the schema is not in BCNF ?

• Decompose (split) the schema into two pieces.

• Careful: you want the decomposition to be lossless

Achieving BCNF Schemas• For all dependencies A B in F+, check if A is a superkey

• By using attribute closure

• If not, then • Choose a dependency in F+ that breaks the BCNF rules, say A B

• Create R1 = A B

• Create R2 = A (R – B – A)

• Note that: R1 ∩ R2 = A and A AB (= R1), so this is lossless decomposition

• Repeat for R1, and R2• By defining F1+ to be all dependencies in F that contain only attributes in R1

• Similarly F2+

Example 1

B C

• R = (A, B, C)• F = {A B, B C}• Candidate keys = {A}

• BCNF = No. B C violates.

• R1 = (B, C)

• F1 = {B C}

• Candidate keys = {B}

• BCNF = true

• R2 = (A, B)

• F2 = {A B}

• Candidate keys = {A}

• BCNF = true

Example 2-1

A B

• R = (A, B, C, D, E)

• F = {A B, BC D}

• Candidate keys = {ACE}

• BCNF = Violated by {A B, BC D} etc…

• R1 = (A, B)

• F1 = {A B}

• Candidate keys = {A}

• BCNF = true

• R2 = (A, C, D, E)

• F2 = {AC D}

• Candidate keys = {ACE}

• BCNF = false (AC D)

• From A B and BC D by pseudo-transitivity

AC D

• R3 = (A, C, D)

• F3 = {AC D}

• Candidate keys = {AC}

• BCNF = true

• R4 = (A, C, E)• F4 = {} [[ only trivial ]]

• Candidate keys = {ACE}

• BCNF = true

• Dependency preservation ???• We can check: • A B (R1), AC D (R3), • but we lost BC D• So this is not a dependency• -preserving decomposition

Example 2-2

BC D

• R = (A, B, C, D, E)

• F = {A B, BC D}

• Candidate keys = {ACE}

• BCNF = Violated by {A B, BC D} etc…

• R1 = (B, C, D)

• F1 = {BC D}

• Candidate keys = {BC}

• BCNF = true

• R2 = (B, C, A, E)

• F2 = {A B}

• Candidate keys = {ACE}

• BCNF = false (A B)

A B• R3 = (A, B)

• F3 = {A B}

• Candidate keys = {A}

• BCNF = true

• R4 = (A, C, E)• F4 = {} [[ only trivial ]]

• Candidate keys = {ACE}

• BCNF = true

• Dependency preservation ???

• We can check:

• BC D (R1), A B (R3),

• Dependency-preserving

• decomposition

Example 3

A BC

• R = (A, B, C, D, E, H)• F = {A BC, E HA}• Candidate keys = {DE}

• BCNF = Violated by {A BC} etc…

• R1 = (A, B, C)

• F1 = {A BC}

• Candidate keys = {A}

• BCNF = true

• R2 = (A, D, E, H)

• F2 = {E HA}

• Candidate keys = {DE}

• BCNF = false (E HA)

E HA

• R3 = (E, H, A)

• F3 = {E HA}

• Candidate keys = {E}

• BCNF = true

• R4 = (ED)• F4 = {} [[ only trivial ]]• Candidate keys = {DE}

• BCNF = true

• Dependency preservation ???

• We can check:

• A BC (R1), E HA (R3),

• Dependency-preserving

• decomposition

Multi-valued Dependency• Two or more functionally independent multi-

valued attributes are dependent on another attribute– EMPLOYEE(Name,Dependent,Project)

• Data redundancy and modification anomalies

• 4NF: BCNF & no multi-valued dependencies– EMPLOYEE(Name,Dependent)– EMPLOYEE(Name, Project)

Definition of MVD

• A multivalued dependency (MVD) X ->->Y is an assertion that if two tuples of a relation agree on all the attributes of X, then their components in the set of attributes Y may be swapped, and the result will be two tuples that are also in the relation.

Example

• The name-addr-phones-beersLiked example illustrated the MVD

name->->phones

and the MVD

name ->-> beersLiked.

Picture of MVD X ->->Y

X Y others

equal

exchange

MVD Rules

• Every FD is an MVD.– If X ->Y, then swapping Y ’s between two tuples that

agree on X doesn’t change the tuples.– Therefore, the “new” tuples are surely in the

relation, and we know X ->->Y.

• Complementation : If X ->->Y, and Z is all the other attributes, then X ->->Z.

Fourth Normal Form

• The redundancy that comes from MVD’s is not removable by putting the database schema in BCNF.

• There is a stronger normal form, called 4NF, that (intuitively) treats MVD’s as FD’s when it comes to decomposition, but not when determining keys of the relation.

4NF Definition

• A relation R is in 4NF if whenever X ->->Y is a nontrivial MVD, then X is a superkey.

– “Nontrivial means that:1. Y is not a subset of X, and

2. X and Y are not, together, all the attributes.

– Note that the definition of “superkey” still depends on FD’s only.

BCNF Versus 4NF

• Remember that every FD X ->Y is also an MVD, X ->->Y.

• Thus, if R is in 4NF, it is certainly in BCNF.– Because any BCNF violation is a 4NF

violation.

• But R could be in BCNF and not 4NF, because MVD’s are “invisible” to BCNF.

4th Normal Form

4th Normal FormMultuvalued dependencies

Instructor Book Class

Price Inro Comp MIS 2003

Parker Intro Comp MIS 2003

Kemp Data in Action MIS 4533

Kemp ORACLE Tricks MIS 4533

Warner Data in Action MIS 4533

Warner ORACLE Tricks MIS 4533

4th Normal Form

INSTR-BOOK-COURSE(InstrID, Book, CourseID)

COURSE-BOOK(CourseID, Book)

COURSE-INSTR(CourseID, InstrID)

4NF(No multivalued dependencies)

TABLE TABLE

TABLETABLE TABLE

TABLE

Independent repeating groups have been treated as a complex relationship.

Example

• Let R be a relation schema with a set of attributes that are partitioned into 3 nonempty subsets.

Y, Z, W• We say that Y Z (Y multidetermines Z)

if and only if for all possible relations r(R)

< y1, z1, w1 > r and < y2, z2, w2 > rthen

< y1, z1, w2 > r and < y2, z2, w1 > r• Note that since the behavior of Z and W are identical it

follows that Y Z if Y W

Theory of MVDs• From the definition of multivalued dependency, we can derive

the following rule:– If , then

That is, every functional dependency is also a multivalued dependency

• The closure D+ of D is the set of all functional and multivalued dependencies logically implied by D. – We can compute D+ from D, using the formal definitions of

functional dependencies and multivalued dependencies.– We can manage with such reasoning for very simple multivalued

dependencies, which seem to be most common in practice– For complex dependencies, it is better to reason about sets of

dependencies using a system of inference rules

Fourth Normal Form• A relation schema R is in 4NF with respect

to a set D of functional and multivalued dependencies if for all multivalued dependencies in D+ of the form , where R and R, at least one of the following hold: is trivial (i.e., or = R) is a superkey for schema R

• If a relation is in 4NF it is in BCNF

Restriction of Multivalued Dependencies

• The restriction of D to Ri is the set Di

consisting of– All functional dependencies in D+ that include

only attributes of Ri

– All multivalued dependencies of the form

( Ri)

where Ri and is in D+

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

Example• R =(A, B, C, G, H, I)

F ={ A BB HICG 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)