Databases I (H.15) Normaliseren Wiebren de Jonge Vrije Universiteit, Amsterdam voorlopige versie...
-
Upload
filip-groen -
Category
Documents
-
view
214 -
download
0
Transcript of Databases I (H.15) Normaliseren Wiebren de Jonge Vrije Universiteit, Amsterdam voorlopige versie...
Databases I (H.15)Normaliseren
Wiebren de JongeVrije Universiteit, Amsterdam
voorlopige versie 2003sheets 1-54 stabiel !?
Overzicht
Reeds behandeld:– hoe herken je normaalvormen
resp. bepaalde vormen van redundantie?
Te behandelen:– hoe moet je zulke redundantie vermijden
resp. een hogere normaalvorm bereiken?– wat zijn de valkuilen?
Voorbeeld Normaliseren (1/2)
F = { sofinr naam,sofinr adres,sofinr gdatum }
Key: {sofinr, vmiddel}
Alle FD’s in F = FRR = m.c. van F zijn r_partiëel naar niet-primaire attributen
Dus: wel in 1NF, maar niet in 2NF
Introductie Normaliseren (5/5)
F = { sofinr naam, sofinr adres, sofinr gdatum }
Key R1: {sofinr} Key R2: {sofinr, vmiddel}F1 = F F2 = R1 is in BCNF R2 is in BCNF (dus het hele schema is in BCNF)
Spurious tupels & dangling tupels
Spurious tupels leveren een ècht probleem:
Het is niet meer mogelijk om vanuit de decompositie de oorspronkelijke relatie te reconstrueren
Dangling tupels leveren geen ècht probleem:
Het betekent simpelweg dat in de decompositieinformatie kan worden opgeslagen die bij het joinen “verloren” kan gaan. M.a.w.: de decompositie biedt je extra mogelijkheden,n.l. om “losse” informatie op te slaan.
Lossless-join eigenschap
{R1, R2, …, Rn} is een decompositie van een relationeel schema R indien: n
i=1 Ri = R (Dus indien alle Ri’s samen de attributen van R bevatten)
Definitie van “lossless”:
Zij R een relationeel schema, zij C een verzameling constraints en zij {R1, R2, …, Rn} een decompositie van R.
{R1, R2, …, Rn} heeft de lossless-join eigenschap m.b.t. C d.e.s.d.a. ()voor elke mogelijke extensie r van R die aan de constraints van C voldoet geldt:
r = R1(r) join R2(r) join … join Rn(r)
(d.w.z. als er, wanneer voldaan wordt aan de constraints van C, door “joinen v.d. projecties” nooit spurious tupels zullen ontstaan)
Eigenschappen “join van projecties” “join van projecties” kan soms meer tupels teruggeven,
maar nooit minder als je de “join van projecties” opnieuw projecteert,
krijg je hetzelfde resultaat als direct na het projecteren van de oorspronkelijke relatie
meerdere keren uitvoeren van “join van projecties” levert precies hetzelfde resultaat op als één keer “join van projecties”
(S1, P1, J1)(S2, P1, J2)
(S1, P1) (P1, J1)(S2, P1) (P1, J2)
(S1, P1, J1)(S2, P1, J2)(S1, P1, J2)(S2, P1, J1)
Controleren lossless-join (als 2 proj.)
Zij D = {R1, R2} een decompositie van R en zij F een verzameling FD’s. D is een lossless join decompositie m.b.t. F d.e.s.d.a.
1) (R1 R2) (R1 - R2) F+, òf2) (R1 R2) (R2 - R1) F+
Merk op: (R1 R2) (R1 - R2) F+ (R1 R2) R1 F+
“”: augmentatie met R1 R2 (voeg links en rechts R1 R2 toe)
“”: decompositie-regel (R1 - R2 is een deelverz. van R1)
Dus, D is een lossless join decompositie m.b.t. F d.e.s.d.a.1) (R1 R2) R1 F+, òf2) (R1 R2) R2 F+
oftewel: d.e.s.d.a. R1 R2 een supersleutel is van R1 of R2
Voorbeeld DatabaseDPD_EMP
E#1 DPD_N1 REL EMP_N BDATE D#E2 Barbara wife Joe 1968-04-04 D1E3 Mary daughter Jack 1969-09-03 D1E3 Sue wife Jack 1969-09-03 D1E4 Tom son Will 1971-03-21 D2E4 Mary wife Will 1971-03-21 D2
DPD EMP
E#1 DPD_N1 REL E#1 EMP_N BDATE D#E2 Barbara wife E2 Joe 1968-04-04 D1E3 Mary daughter E3 Jack 1969-09-03 D1E3 Sue wife E4 Will 1971-03-21 D2E4 Tom sonE4 Mary wife
Vb. lossless-join (splitsing in 2 projecties)
D is een lossless join decompositie m.b.t. F d.e.s.d.a.1) (R1 R2) R1 F+, òf2) (R1 R2) R2 F+
R = DPD_EMP = {E#, DPD_N, REL, EMP_N, BDATE, D#}
met F = { {E#, DPD_N} REL, E# EMP_N, E# BDATE, E# D# }
R1 = DPD = {E#, DPD_N, REL}R2 = EMP = {E#, EMP_N, BDATE, D#}
R1 R2 = {E#} èn E# {E#, EMP_N, BDATE, D#} (=EMP)
Dus: deze decompositie van DPD_EMP is lossless m.b.t. F
Vb. lossless-join (met n projecties) (1/3)
DPD_EMP_DPM (E#, DPD_N, REL, EMP_N, BDATE, D#, DPM_N, BUDGET)
met F = { {E#, DPD_N} REL, D# DPM_N, E# EMP_N, D# BUDGET, E# BDATE, DPM_N D#, E# D#, DPM_N BUDGET }
DPD (E#, DPD_N, REL)EMP (E#, EMP_N, BDATE, D#)DEPT (D#, DPM_N, BUDGET)
Vb. lossless-join (met n projecties) (2/3)
DPD_EMP_DPM (E#, DPD_N, REL, EMP_N, BDATE, D#, DPM_N, BUDGET)
met F = { {E#, DPD_N} REL, D# DPM_N, E# EMP_N, D# BUDGET, E# BDATE, DPM_N D#, E# D#, DPM_N BUDGET }
E# DPD_N REL EMP_N BDATE D# DPM_N BUDGET
DPD a1 a2 a3 b14 b15 b16 b17 b18
EMP a1 b22 b23 a4 a5 a6 b27 b28
DEPT b31 b32 b33 b34 b35 a6 a7 a8
Vb. lossless-join (met n projecties) (3/3) DPD_EMP_DPM (E#, DPD_N, REL,
EMP_N, BDATE, D#, DPM_N, BUDGET)
met F = { {E#, DPD_N} REL, D# DPM_N, E# EMP_N, D# BUDGET, E# BDATE, DPM_N D#, E# D#, DPM_N BUDGET }
E# DPD_N REL EMP_N BDATE D# DPM_N BUDGET
DPD a1 a2 a3 a4 a5 a6 a7 a8
EMP a1 b22 b23 a4 a5 a6 a7 a8
DEPT b31 b32 b33 b34 b35 a6 a7 a8
N.B. situatie na “toepassing” van E# {EMP_N, BDATE, D#} en van D# {DPM_N, BUDGET}
Algoritme lossless-join Heeft een decompositie R1, …, Rk van R
de lossless-join eigenschap m.b.t. een verzameling FD’s F?
1) maak een tabel met k rijen (voor iedere R1, …, Rk een rij) en n kolommen (voor ieder attribuut A1, …, An een kolom)
2) i j: zet in rij i en kolom j: het symbool aj als Aj Ri het symbool bij als Aj Ri
3) “verwerk” nu telkens opnieuw alle FD’s X Y F totdat– òfwel één van de rijen gelijk is geworden aan a1, …, an
– òfwel de tabel niet meer gewijzigd kan worden
4) deze decompositie is lossless er is een rij gelijk aan a1, …, an
“verwerken” van een FD X Y:telkens als een aantal rijen ‘dezelfde X-waarden’ hebben,geef ze dan ook ‘dezelfde Y-waarden’ (en kies zo mogelijk voor een aj)
Let op: telkens als je een symbool wijzigt, moet je alle instanties van dat symbool wijzigen (dus ook instanties in heel andere rijen)
Voorbeeld lossless-join algoritme (1/7)
R = {A,B,C,D,E} = ABCDE
R1=AD R2=AB R3=BE R4=CDE R5=AE
F = {AC, BC, CD, DEC, CEA}
A B C D E
R1 a1 b12 b13 a4 b15
R2 a1 a2 b23 b24 b25
R3 b31 a2 b33 b34 a5
R4 b41 b42 a3 a4 a5
R5 a1 b52 b53 b54 a5
Voorbeeld lossless-join algoritme (2/7)
F = {AC, BC, CD, DEC, CEA}
A B C D E
R1 a1 b12 b13 a4 b15
R2 a1 a2 b13 b24 b25
R3 b31 a2 b33 b34 a5
R4 b41 b42 a3 a4 a5
R5 a1 b52 b13 b54 a5
Voorbeeld lossless-join algoritme (3/7)
F = {AC, BC, CD, DEC, CEA}
A B C D E
R1 a1 b12 b33 a4 b15
R2 a1 a2 b33 b24 b25
R3 b31 a2 b33 b34 a5
R4 b41 b42 a3 a4 a5
R5 a1 b52 b33 b54 a5
Voorbeeld lossless-join algoritme (4/7)
F = {AC, BC, CD, DEC, CEA}
A B C D E
R1 a1 b12 b33 a4 b15
R2 a1 a2 b33 a4 b25
R3 b31 a2 b33 a4 a5
R4 b41 b42 a3 a4 a5
R5 a1 b52 b33 a4 a5
Voorbeeld lossless-join algoritme (5/7)
F = {AC, BC, CD, DEC, CEA}
A B C D E
R1 a1 b12 a3 a4 b15
R2 a1 a2 a3 a4 b25
R3 b31 a2 a3 a4 a5
R4 b41 b42 a3 a4 a5
R5 a1 b52 a3 a4 a5
Voorbeeld lossless-join algoritme (6/7)
F = {AC, BC, CD, DEC, CEA}
A B C D E
R1 a1 b12 a3 a4 b15
R2 a1 a2 a3 a4 b25
R3 a1 a2 a3 a4 a5
R4 a1 b42 a3 a4 a5
R5 a1 b52 a3 a4 a5
Voorbeeld lossless-join algoritme (7/7)
Opmerking
We hebben de FD’s in dit vb. “toevallig” in een gunstige volgorde verwerkt zodat we na één ronde al klaar zijn.
In het algemeen moet de gehele verzameling van FD’s meerdere malen doorlopen worden
(namelijk, net zolang totdat er: ofwel een rij a’s uitkomt, ofwel er niets meer in de tabel veranderd kan worden)
Vb. 1: Dependency Preserving ? (1/3)R = { Stad, Straat, Huisnr, Postcode, Vraagprijs }
F = { {Stad, Straat, Huisnr} Postcode, {Stad, Straat, Huisnr} Vraagprijs, {Postcode, Huisnr} Vraagprijs,
Postcode Stad, Postcode Straat }
Stad1 Straat1 Huisnr1,2 Postcode2 Vraagprijs
Amsterdam Westerstr 31 1015 MK 500 000
Den Haag Laan 237 2512 DT 400 000
Den Haag Hoefkade 30 2526 CA 150 000
Appingedam Broerstr 8 9901 EK 200 000
Appingedam Broerstr 12 9901 EK 225 000
Keys: { {Stad, Straat, Huisnr}, {Postcode, Huisnr} }
Vb. 1: Dependency Preserving ? (2/3)R = { Stad, Straat, Huisnr, Postcode, Vraagprijs}
F = { {Stad, Straat, Huisnr} Postcode, {Stad, Straat, Huisnr} Vraagprijs, {Postcode, Huisnr} Vraagprijs,
Postcode Stad, Postcode Straat }
R1 R2
Postcode1 Huisnr1 Vraagprijs Postcode1 Stad Straat
1015 MK 31 500 000 1015 MK Amsterdam Westerstr
1212 DT 237 400 000 1212 DT Den Haag Laan
2526 CA 30 150 000 2526 CA Den Haag Hoefkade
9901 EK 8 200 000 9901 EK AppingedamBroerstaat
9901 EK 12 225 000
Vb. 1: Dependency Preserving ? (3/3)R = { Stad, Straat, Huisnr, Postcode, Vraagprijs }
F = { {Stad, Straat, Huisnr} Postcode, {Stad, Straat, Huisnr} Vraagprijs, {Postcode, Huisnr} Vraagprijs,
Postcode Stad, Postcode Straat }
R1 = {Postcode, Huisnr, Vraagprijs}R2 = {Postcode, Stad, Straat}
Er geldt: R1 R2 = Postcode èn Postcode {Stad, Straat} F+
dus de decompositie heeft de lossless-join eigenschap
Echter, de volgende FD’s zijn beide “tussen wal en schip gevallen”: {Stad, Straat, Huisnr} Postcode {Stad, Straat, Huisnr} Vraagprijs
(dus join nodig om ze te checken, want niet afleidbaar uit rest; zie vb.2)
Vb. 2: Dependency Preserving ?R = {A, B, C} = ABC (keys: {A} = A)F = { A B, (r_sleutel)
A C, (r_sleutel) B C } (r_transitief)
R1 = AB (= {A, B}) R2 = BC (= {B, C})
Er geldt: R1R2 = B en BBC F+ (dus lossless-join eigenschap)
De FD AC lijkt “tussen wal en schip te vallen”, doch: AC volgt uit AB en BC AB kan efficiënt in R1 gecontroleerd/afgedwongen worden BC kan efficiënt in R2 gecontroleerd/afgedwongen worden
Dus: als AB en BC beide afgedwongen worden, dan wordt daarmee automatisch ook AC afgedwongen
Dependency Preserving
De projectie van F op een verzameling attributen Z:
Z(F) = { X Y F+ | XY Z }
Let op: Z(F) = Z(F+) !! (dus eig. ongelukkig gekozen definitie)
Een decompositie {R1, R2, … Rk} heet dependency preserving
d.e.s.d.a. (ki=1 Ri(F
(+))) F
M.b.v.: F G F+ = G+ F G+ èn G F+
kan afgeleid worden:
afh. bewarend F+ = (ki=1 Ri(F))+ F (k
i=1 Ri(F))+
Want de tweede eis G F+, oftewel: (ki=1 Ri(F)) F+, volgt in dit geval
uit het feit dat een projie van F per defie alleen afhankelijkheden uit F+ bevat.
Vb. 2: Dependency Preserving m.b.v. F+ (1/3)
F = {AB, AC, BC} R1 = {A,B} = AB R2 = {B,C} = BC
deze decompositie is dependency preserving d.e.s.d.a.:
F ( R1(F) R2(F) )+
oftewel:
F ( R1(F+) R2(F+) )+
eerst maar eens F+ uitrekenen...
Vb. 2: Dependency Preserving m.b.v. F+ (2/3)
F+ = {AA, ABA, ACA, ABCA
AB, BB, ABB, BCB, ACB, ABCB
AC, BC, CC, ABC, BCC, ACC, ABCC
AAB, ABAB, ACAB, ABCAB
ABC, BBC, ABBC, BCBC, ACBC, ABCBC
AAC, ABAC, ACAC, ABCAC
AABC, ABABC, ACABC,ABCABC}
Kortom, i.h.a. ondoenlijk!
Met dit kleine voorbeeld kan het ‘nog net’.
We gaan dan ook ‘braaf’ (resp. ‘domweg’) verder met de uitwerking
van dit vb. om een beter beeld te krijgen van waar het om gaat.
Vb. 2: Dependency Preserving m.b.v. F+ (3/3)F = {AB, AC, BC} R1 = {A,B} = AB R2 = {B,C} = BC
als deze decompositie dependency preserving is,
dan zou moeten gelden: F ( R1(F) R2(F) )+
R1(F) = {AA, AB, AAB, BB, ABA, ABB, ABAB}
R2(F) = {BB, BC, BBC, CC, BCB, BCC, BCBC}
dus er zou moeten gelden– A B ( R1(F) R2(F) )+ (klopt, want A B R1(F) )
– B C ( R1(F) R2(F) )+ (klopt, want B C R2(F) )
– A C ( R1(F) R2(F) )+ (klopt, want uit A B R1(F) en BC R2(F) volgt:
AC ( R1(F) R2(F) )+ )
Dus: deze decompositie is dependency preserving
Vb. 1: Dependency Preserving m.b.v. F+
F = { {Stad, Straat, Huisnr} Postcode,{Stad, Straat, Huisnr} Vraagprijs, {Postcode, Huisnr} Vraagprijs,
Postcode Stad, Postcode Straat }
R1 = {Postcode, Huisnr, Vraagprijs}R2 = {Postcode, Stad, Straat}
als deze decompositie is dependency preserving is,dan zou moeten gelden:
F ( R1(F) R2(F) )+
echter, er geldt o.a. (maar hoe zie je dat?):
{Stad, Straat, Huisnr} Vraagprijs ( R1(F) R2(F) )+
Dus: deze decompositie is niet dependency preserving
Problemen met: Dependency Preserving?
afh. bewarend F+ = (ki=1 Ri(F))+ F (k
i=1 Ri(F))+
Neem: G = ki=1 Ri(F)
Merk op: 1) G bepalen door eerst F+ uit te rekenenis i.h.a. ondoenlijk
2) G+ uitrekenen i.h.a. ook ondoenlijk
Oplossing voor 2): check voor elke FD X Y F of ook geldt: X Y G+ d.w.z. of: Y X+
G
Dit laatste kan zonder G uit te hoeven rekenen!
(M.a.w.: het eerste probleem kan ook omzeild worden.
Er bestaat een algoritme wat, althans dit jaar, niet tot de stof behoort.)
Dependency Preserving met F* i.p.v. F+
Maar ook zonder dat algoritme te gebruiken kan het slimmer!
E.e.a. kan efficiënter met gebruik van F* i.p.v. F+
Kan o.a. m.b.v. een ‘zuiniger’ vorm van projectie van F:
*Z(F) = { X Y F* | XY Z }
afh.bewarend F (ki=1 Ri(F))+ F (k
i=1 *Ri(F))+
dus nu: check voor elke FD X Y F
of ook geldt: X Y (ki=1 *Ri(F))+
Vb. 2: Dependency Preserving met F* F = {AB, AC, BC} R1 = {A,B} = AB R2 = {B,C} = BC
deze decompositie is dependency preserving d.e.s.d.a.:
F ( *R1(F) *R2(F) )+
in dit vb.: F* = F
*R1(F) = {AB}
*R2(F) = {BC}
dus er zou moeten gelden– A B ( *R1(F) *R2(F) )+ ? Ja, want A B *R1(F) )
– B C ( *R1(F) *R2(F) )+ ? Ja, want B C *R2(F) )
– A C ( *R1(F) *R2(F) )+ ? Ja, want uit A B *R1(F) en BC *R2(F) volgt:
AC ( *R1(F) *R2(F) )+ )
Dus: deze decompositie is dependency preserving
Vb. 1: Dependency Preserving m.b.v. F*
F = { {Stad, Straat, Huisnr} Postcode,{Stad, Straat, Huisnr} Vraagprijs, {Postcode, Huisnr} Vraagprijs,
Postcode Stad, Postcode Straat } = F*
R1 = {Postcode, Huisnr, Vraagprijs}R2 = {Postcode, Stad, Straat}
als deze decompositie is dependency preserving is,dan zou moeten gelden:
F ( *R1(F) *R2(F) )+
echter, er geldt o.a.:
{Stad, Straat, Huisnr} Vraagprijs ( *R1(F) *R2(F) )+
Dus: deze decompositie is niet dependency preserving
Normaalvormen
Een database-ontwerp (db-schema) R1, R2, …, Rn
is in ?NF t.o.v. een verzameling FD’s F
d.e.s.d.a. iedere relatie Ri in ?NF is t.o.v. Ri(F)
( N.B. in de praktijk natuurlijk: t.o.v. *Ri(F) )
‘Tussenstand’
We weten nu hoe we in een relatie-schema en/of db-schema potentiële redundantie kunnen herkennen
(normaalvorm bepalen)
Van een decompositie kunnen we nu beoordelen:– hoe goed in de decompositie redundantie
wordt voorkomen (i.e. hoe hoog de normaalvorm is)
– of de decompositie dezelfde informatie kan bevatten alsde oorspronkelijke tabel (via “lossless join” algoritme)
– of de FD’s ( {“gewenste constraints”}) in de decompositieop een efficiënte manier kunnen worden afgedwongen
(via “dependency preserving” algoritme dat niet is behandeld
of door dat ‘handmatige controle’ m.b.v. F* zoals geschetst)
Gewenste eigenschappen database-ontwerp
Beslist de lossless-join eigenschap, want anders verlies van info
B.v.k. een hoge normaalvorm, want anders potentiële redundantie, etc.
B.v.k. dependency preserving, want anders is er veel werk (n.l. ‘dure’ joins) nodig om de opgelegde constraints (zoals FD’s) af te dwingen
Bestaat er een decompositie die aan de wensen voldoet?
Hoe vind je zo’n decompositie?(zonder alle mogelijke decomposities te hoeven uitproberen)
Wat is er mogelijk en wat (soms) niet?
BCNF + dependency preserving + lossless: soms onmogelijk
BCNF + dependency preserving: soms onmogelijk
BCNF + lossless: altijd mogelijk
3NF + dependency preserving + lossless: altijd mogelijk
Twee decompositie-algoritmes
3NF decompositie algoritme (lossless + dependency preserving)
BCNF decompositie algoritme(lossless, doch niet altijd dependency preserving)
In dit college gaan we uitsluitend het 3NF algoritme behandelen!
(Het BCNF decompositie algoritme valt dit jaar nog buiten de
tentamenstof, o.a. i.v.m. complexiteit van projecteren van F+
of van berekenen van F* en i.v.m. overslaan van het algoritme
voor het testen van de “dependency preserving” eigenschap)
3NF decompositie algoritme (lossless + d.p.)Gegeven een relatie-schema R en een verzameling FD’s F:
1) Bepaal een minimal cover van F en noem die m.c. G.
2) Splits R op in alle relatie-schema’s XiAi die corresponderen met een afhankelijkheid Xi Ai in G
3) Telkens als Xi = Xj mogen we de twee bijbehorende schema’s (XiAi en XjAj) samenvoegen tot XiAiAj.
4) Om de lossless-join eigenschap te verzekeren voegen we één relatie-schema X toe, waarbij X een sleutel moet zijn van R.
5) Verwijder eventueel een aantal overbodige schema’s(± schema’s die bevat zijn in een ander schema).
N.B. stappen 2 en 3 kun je ook makkelijk in één klap uitvoeren
Voorbeeld 3NF decompositie algoritme (1/5)
Gegeven:
DPD_EMP_DPM = {E#, DPD_N, REL, EMP_N, BDATE, D#, DPM_N, BUDGET}
met F = { {E#, DPD_N} REL, E# {EMP_N, BDATE, D#},
D# {BUDGET, DPM_N}, DPM_N {D#, BUDGET} }
Stap 1: Bepaal een minimal cover van F (en noem die G)
G = { {E#, DPD_N} REL, D# DPM_N, E# EMP_N, D# BUDGET, E# BDATE, DPM_N D#, E# D# }
Voorbeeld 3NF decompositie algoritme (2/5)
We hebben:
G = { {E#, DPD_N} REL, D# DPM_N, E# EMP_N, D# BUDGET, E# BDATE, DPM_N D#, E# D# }
Stap 2: Splitsen in losse relatieschema’s (maak voor iedere FD in G een ‘bijpassend’ relatieschema)
{E#, DPD_N, REL}, {D#, DPM_N},{E#, EMP_N}, {D#, BUDGET},{E#, BDATE}, {DPM_N, D#},{E#, D#}
Voorbeeld 3NF decompositie algoritme (3/5) We hebben:
G = { {E#, DPD_N} REL, D# DPM_N, E# EMP_N, D# BUDGET, E# BDATE, DPM_N D#, E# D# }
en schema’s: {E#, DPD_N, REL}, {D#, DPM_N}, {E#, EMP_N}, {D#, BUDGET}, {E#, BDATE}, {DPM_N, D#}, {E#, D#}
Stap 3: Samenvoegen van schema’s
{E#, DPD_N, REL},{E#, EMP_N, BDATE, D#},{D#, DPM_N, BUDGET},{DPM_N, D#}
Voorbeeld 3NF decompositie algoritme (4/5) We hebben:
G = { {E#, DPD_N} REL, D# DPM_N, E# EMP_N, D# BUDGET, E# BDATE, DPM_N D#, E# D# }
en schema’s: {E#, DPD_N, REL}, {E#, EMP_N, BDATE, D#}, {D#, DPM_N, BUDGET}, {DPM_N, D#}
Stap 4: Relatie-schema voor een sleutel toevoegen
Op basis van G kunnen we een sleutel vinden: {E#, DPD_N} (In dit vb. is het zelfs de enige sleutel)
Dus voeg nu toe: {E#, DPD_N}
Voorbeeld 3NF decompositie algoritme (5/5) We hebben:
{E#, DPD_N, REL},{E#, EMP_N, BDATE, D#},{D#, DPM_N, BUDGET},{DPM_N, D#}, {E#, DPD_N}
Stap 5: Verwijderen overbodige relatie-schema’s (± schema’s die in een ander relatie-schema bevat zijn)
{E#, DPD_N, REL} (=DPD){E#, EMP_N, BDATE, D#} (=EMP){D#, DPM_N, BUDGET} (=DEPT)
N.B.: Het eindresultaat is dus precies gelijk aan onzevoorbeeld-DB met de 3 tabellen DPD, EMP en DEPT
Hogere normaalvormen: 4NF (1/3)
voorbeeld:
dating-bureau houdt van iedere zoekende de volgende informatie bij: naam, hobby’s, huisdieren– personen kunnen meerdere hobby's en/of huisdieren hebben
– er is geen verband tussen hobby’s en huisdieren
ZOEKENDE_HOBBY ZOEKENDE_HUISDIER
NAAMHOBBY NAAM HUISDIER
Truus bridgen Truus kat
Truus puzzelen Truus goudvis
Teun sjoelen Teun Hond
Teun Kanarie
Hogere normaalvormen: 4NF (2/3)
Stel, je stopt al deze informatie in slechts één tabel.Kun je dan d.m.v. FD’s vooraf detecteren dat je hiermeeredundantie kunt introduceren? (antwoord: nee, want F = )
ZOEKENDE
NAAMHOBBY HUISDIER
Truus bridgen kat
Truus bridgen goudvis
Truus puzzelen kat
Truus puzzelen goudvis
Teun sjoelen hond
Teun sjoelen kanarie
Hogere normaalvormen: 4NF (3/3)
ZOEKENDE
NAAM HOBBY HUISDIER
Truus bridgen kat
Truus bridgen goudvis
Truus puzzelen kat
Truus puzzelen goudvis
Teun sjoelen hond
Teun sjoelen kanarie
Multi-valued dependencies (MVD’s):
1) naam --->> hobby2) naam --->> huisdier
4NF: gebaseerd op MVD’s (betreffen ‘onafh.’ many-many relationships)
N.B. ZOEKENDE is wel in BCNF, maar niet in 4NF
Hoogste normaalvorm: 5NF (=PJNF)
FD’s: beschrijven many-one relationships (tussen attr.waarden)
MVD’s: betreffen “onafhankelijke” many-many relationships (...)
JD’s: beschrijven relationships (tussen attr.waarden) die de lossless-join eigenschap garanderen
Join Dependency (JD):
een constraint die inhoudt dat de betreffende relatie gelijk is aan de join van een aantal projecties (voor iedere toegestane extensie!)
N.B.: {FD’s} {MVD’s} {JD’s}
5NF (=PJNF): – gebaseerd op ‘èchte’ join dependencies
(i.e. ook splitsen als ‘èchte’ JD aanwezig) – de ultieme normaalvorm (althans op basis van projectie en join,
i.e. ‘knippen’ en ‘plakken’)
Voorbeeld van een join-dependency (JD)
In de context van de “SPJ” database”:
“Als een supplier iets levert aan een bepaald project, dan levert hij aan dat project ook alles wat hij kan leveren en wat bij dat project gebruikt wordt.”
Als deze join dependency geldt in het SPJ-voorbeelddan is de tabel SPJ niet in 5NF
De decompositie {SP, PJ, JS} is dan wel in 5NF (èn lossless)
Enkele nuttige stellingen
Als een relatie-schema in 3NF is en als elke sleutel bestaat uit slechts één enkel attribuut (i.e. er is geen enkele
samengestelde sleutel), dan is het relatie-schema ook in 5NF
Als een relatie-schema in BCNF is en als er tenminste één sleutel is bestaande uit een enkel attribuut,dan is het relatie-schema ook in 4NF
Elke relatie met twee attributen is in BCNF
Bewijs laatste stelling
Stelling:Elke relatie R met twee attributen is in BCNF(BCNF: iedere relevante FD is een r_sleutelafh)
Bewijs:
Neem een minimal cover G van REr zijn 4 mogelijkheden voor G:1) G =
dan is inderdaad iedere relevante FD een r_sleutelafh (triviaal)
2) G = {AB}dan is A een key, dus AB een r_sleutelafh
3) G = {BA}dan is B een key, dus BA een r_sleutelafh
4) G = {AB, BA}dan zijn A en B key’s en zijn AB en BA r_sleutelafh
Slotopmerking m.b.t. normaliseren
Met de in dit college behandelde theorie is men in staat om gegeven een schema potentiële redundantie te herkennen en te vermijden (tot op zekere hoogte)
Het is echter aan de Database-ontwerper om te beslissen of normalisering ook echt wenselijk is
(denk hierbij b.v. aan zaken als performance bij retrieval, i.e. leesoperaties)