4NF and 5NF
-
Upload
arjunlnmiit -
Category
Documents
-
view
41 -
download
2
description
Transcript of 4NF and 5NF
![Page 1: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/1.jpg)
4NF and 5NF
Prof. Sin-Min Lee
Department of Computer Science
![Page 2: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/2.jpg)
NormalizationGoal = BCNF = Boyce-Codd Normal Form =all FD’s follow from the fact “key everything.”• Formally, R is in BCNF if for every nontrivial FD
for R, say X A, then X is a superkey.– “Nontrivial” = right-side attribute not in left side.
Why?1. Guarantees no redundancy due to FD’s.
2. Guarantees no update anomalies = one occurrence of a fact is updated, not all.
3. Guarantees no deletion anomalies = valid fact is lost when tuple is deleted.
![Page 3: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/3.jpg)
Example of Problems
Drinkers(name, addr, beersLiked, manf, favoriteBeer)
FD’s:
1. name addr2. name favoriteBeer3. beersLiked manf• ???’s are redundant, since we can figure them out from the FD’s.
• Update anomalies: If Janeway gets transferred to the Intrepid,will we change addr in each of her tuples?
• Deletion anomalies: If nobody likes Bud, we lose track of Bud’s manufacturer.
name addr beersLiked manf favoriteBeer
Janeway Voyager Bud A.B. WickedAleJaneway ??? WickedAle Pete's ???Spock Enterprise Bud ??? Bud
![Page 4: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/4.jpg)
Each of the given FD’s is a BCNF violation:• Key = {name, beersLiked}
– Each of the given FD’s has a left side that is a proper subset of the key.
Another ExampleBeers(name, manf, manfAddr).• FD’s = name manf, manf manfAddr.• Only key is name.
– Manf manfAddr violates BCNF with a left side unrelated to any key.
![Page 5: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/5.jpg)
Decomposition to Reach BCNFSetting: relation R, given FD’s F.
Suppose relation R has BCNF violation X B.
• We need only look among FD’s of F for a BCNF violation, not those that follow from F.
• Proof: If Y A is a BCNF violation and follows from F, then the computation of Y+ used at least one FD X B from F.– X must be a subset of Y.– Thus, if Y is not a superkey, X cannot be a superkey
either, and X B is also a BCNF violation.
![Page 6: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/6.jpg)
1. Compute X+.– Cannot be all attributes – why?
2. Decompose R into X+ and (R–X+) X.
3. Find the FD’s for the decomposed relations.– Project the FD’s from F = calculate all
consequents of F that involve only attributes from X+ or only from (RX+) X.
R X+ X
![Page 7: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/7.jpg)
ExampleR = Drinkers(name, addr, beersLiked, manf, favoriteBeer)
F =1. name addr2. name favoriteBeer3. beersLiked manfPick BCNF violation name addr.• Close the left side: name + = name addr favoriteBeer.• Decomposed relations:
Drinkers1(name, addr, favoriteBeer)Drinkers2(name, beersLiked, manf)
• Projected FD’s (skipping a lot of work that leads nowhere interesting):– For Drinkers1: name addr and name favoriteBeer.– For Drinkers2: beersLiked manf.
![Page 8: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/8.jpg)
(Repeating)• Decomposed relations:
Drinkers1(name, addr, favoriteBeer)Drinkers2(name, beersLiked, manf)
• Projected FD’s:– For Drinkers1: name addr and name favoriteBeer.
– For Drinkers2: beersLiked manf.
• BCNF violations?– For Drinkers1, name is key and all left sides of
FD’s are superkeys.– For Drinkers2, {name, beersLiked} is the key,
and beersLiked manf violates BCNF.
![Page 9: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/9.jpg)
Decompose Drinkers2• First set of decomposed relations:
Drinkers1(name, addr, favoriteBeer)Drinkers2(name, beersLiked, manf)
• Close beersLiked+ = beersLiked, manf.• Decompose Drinkers2 into:
Drinkers3(beersLiked, manf)Drinkers4(name, beersLiked)
• Resulting relations are all in BCNF:Drinkers1(name, addr, favoriteBeer)Drinkers3(beersLiked, manf)Drinkers4(name, beersLiked)
![Page 10: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/10.jpg)
3NFOne FD structure causes problems:• If you decompose, you can’t check all the FD’s only
in the decomposed relations.• If you don’t decompose, you violate BCNF.Abstractly: AB C and C B.• Example 1: title city theatre and theatre city.
• Example 2: street city zip,zip city.
Keys: {A, B} and {A, C}, but C B has a left side that is not a superkey.
• Suggests decomposition into BC and AC.– But you can’t check the FD AB C in only these relations.
![Page 11: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/11.jpg)
ExampleA = street, B = city, C = zip.
Join:
street zip
545 Tech Sq. 02138545 Tech Sq. 02139
city zip
Cambridge 02138Cambridge 02139
city street zip
Cambridge 545 Tech Sq. 02138Cambridge 545 Tech Sq. 02139
zip city
street city zip
![Page 12: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/12.jpg)
“Elegant” Workaround
Define the problem away.• A relation R is in 3NF iff (if and only if)
for every nontrivial FD X A, either:1. X is a superkey, or2. A is prime = member of at least one key.
• Thus, the canonical problem goes away: you don’t have to decompose because all attributes are prime.
![Page 13: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/13.jpg)
What 3NF Gives YouThere are two important properties of a decomposition:1. We should be able to recover from the decomposed
relations the data of the original.– Recovery involves projection and join, which we shall defer until
we’ve discussed relational algebra.
2. We should be able to check that the FD’s for the original relation are satisfied by checking the projections of those FD’s in the decomposed relations.
• Without proof, we assert that it is always possible to decompose into BCNF and satisfy (1).
• Also without proof, we can decompose into 3NF and satisfy both (1) and (2).
• But it is not possible to decompose into BNCF and get both (1) and (2).
– Street-city-zip is an example of this point.
![Page 14: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/14.jpg)
Multivalued Dependencies
The multivalued dependency X Y holds in a relation R if whenever we have two tuples of R that agree in all the attributes of X, then we can swap their Y components and get two new tuples that are also in R.
X Y others
![Page 15: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/15.jpg)
ExampleDrinkers(name, addr, phones, beersLiked)
with MVD Name phones. If Drinkers has the two tuples:
name addr phones beersLiked sue a p1 b1
sue a p2 b2
it must also have the same tuples with phones components swapped:
name addr phones beersLiked sue a p2 b1
sue a p1 b2
Note: we must check this condition for all pairs of tuples that agree on name, not just one pair.
![Page 16: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/16.jpg)
MVD Rules1.Every FD is an MVD.
– Because if X Y, then swapping Y’s between tuples that agree on X doesn’t create new tuples.
– Example, in Drinkers: name addr.
2.Complementation: if X Y, then X Z, where Z is all attributes not in X or Y.– Example: since name phones
holds in Drinkers, so doesname addr beersLiked.
![Page 17: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/17.jpg)
Splitting Doesn’t Hold
Sometimes you need to have several attributes on the right of an MVD. For example:
Drinkers(name, areaCode, phones, beersLiked, beerManf)name areaCode phones beersLiked beerManf
Sue 831 555-1111 Bud A.B.
Sue 831 555-1111 Wicked AlePete’s
Sue 408 555-9999 Bud A.B.
Sue 408 555-9999 Wicked AlePete’s
• name areaCode phones holds, but neither name areaCode nor name phones do.
![Page 18: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/18.jpg)
4NF
Eliminate redundancy due to multiplicative effect of MVD’s.• Roughly: treat MVD’s as FD's for decomposition, but not
for finding keys.• Formally: R is in Fourth Normal Form if whenever MVD
X Y is nontrivial (Y is not a subset of X, and X Y is not all attributes), then X is a superkey.– Remember, X Y implies X Y, so 4NF is more stringent
than BCNF.
• Decompose R, using4NF violation X Y,into XY and X (R—Y).
R Y X
![Page 19: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/19.jpg)
ExampleDrinkers(name, addr, phones, beersLiked)• FD: name addr• Nontrivial MVD’s: name phones andname beersLiked.
• Only key: {name, phones, beersLiked}
• All three dependencies above violate 4NF.
• Successive decomposition yields 4NF relations:D1(name, addr)D2(name, phones)D3(name, beersLiked)
![Page 20: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/20.jpg)
1NF 2NF 3NF BCNF 4NF 5NF
functional dependencies
multivalueddependencies
joindependencies
HIGHER NORMAL FORMS
![Page 21: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/21.jpg)
ASSUMPTIONS
• 24-HOUR FLIGHT-TIMETABLE, ALL FLIGHTS EVERY DAY
• ALL PLANES TAKE-OFF AND LAND (BUT DO NOT CRASH)
• NO AIRPORT IS LANDING-ONLY & NO AIRPORT IS TAKE-OFF-ONLY
TTAB (ORG) = TTAB (DST)
• THERE IS AT LEAST ONE TIME DELAY ENTRY FOR EVERY FLIGHT
• SIMILARLY IN WEATHER REPORT HISTORY
• IF NO TWO FLIGHTS CAN TAKE OFF AT THE SAME TIME IN THE SAME AIRPORT
WES CAN BE POSTED TO FLIGHT AND WEATHER@ORIGIN ELIMINATED
![Page 22: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/22.jpg)
UNIVERSITY DISCIPLINE DEGREE
Old Town Computing BSc
Old Town Mathematics PhD
New City Computing PhD
Old Town Computing PhD
AWARD teaches (UNIVERSITY, DISCIPLINE)is_read_for (DISCIPLINE, DEGREE)awards (UNIVERSITY, DEGREE)
teaches (NewCity, Computing) = true awards (NewCity, PhD) = trueis_read_for (Computing, BSc) = true
FROM(NewCity teaches Computing) and (Computing is_read_for BSc)
IT DOES NOT FOLLOWNewCity awards BSc for_reading Computing
![Page 23: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/23.jpg)
UNIVERSITY DISCIPLINE DISCIPLINE DEGREE UNIVERSITY DEGREE
Old Town Computing Computing BSc Old Town BSc
Old Town Mathematics Mathematics PhD Old Town PhD
New City Computing Computing PhD New City PhD
UNIVERSITY DISCIPLINE DEGREE
Old Town Computing BSc
Old Town Computing PhD
Old Town Mathematics PhD
New City Computing BSc
New City Computing PhD
UNIVERSITY DISCIPLINE DEGREE
Old Town Computing BSc
Old Town Computing PhD
Old Town Mathematics PhD
New City Computing PhD
spurious tuple
AWARD
![Page 24: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/24.jpg)
Join Dependency
R
if R1 R2
R
then
JD*( )
holds for R
for
JD * (R1, R2, R3, ..., Rm) holds in R iff R = join (R1, R2, R3, ..., Rm ), Ri - a projection of R
![Page 25: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/25.jpg)
R
JD* ( , )
then R is in 5NF
if
JD* ( , )
A relation R is in 5NF iff
for all JD * (R1, R2, R3, ..., Rm) in R,
every Ri is a superkey for R.
preventing illogical conjunction of factsFifth Normal Form
JD* ( , ) holds for R
then R is not in 5NF
if
does not contain key
![Page 26: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/26.jpg)
UNIVERSITY DISCIPLINE
Old Town Computing
Old Town Mathematics
New City Computing
DISCIPLINE DEGREE
Computing BSc
Mathematics PhD
Computing PhD
UNIVERSITY DEGREE
Old Town BSc
Old Town PhD
New City PhD
AWARD
![Page 27: 4NF and 5NF](https://reader030.fdocuments.in/reader030/viewer/2022020111/55cf948f550346f57ba2ca83/html5/thumbnails/27.jpg)
NAME CODE TEACHING RESEARCH
Old Town P05 21 4
New City C01 23 3
RANKING
join dependencies
JD1 * ((NAME, CODE, TEACHING), (NAME, RESEARCH))JD2 * ((NAME, CODE, RESEARCH), (NAME, TEACHING))JD3 * ((NAME, CODE, TEACHING), (CODE, RESEARCH))JD4 * ((NAME, CODE, RESEARCH), (CODE, TEACHING))JD5 * ((NAME, CODE), (NAME, TEACHING), (CODE,RESEARCH)).............................................................................................
candidate keys - NAME or CODE
all projections in JD1 - to JD5 are superkeys for RANKING 5NF