Databases I (H.14) Functionele Afhankelijkheden en Normaalvormen versie 2003 Databases I (H.14) Functionele Afhankelijkheden en Normaalvormen Wiebren de Jonge Vrije Universiteit, Amsterdam
De rest van de colleges DB I (komende 3 college-weken) Meer over relationeel database design: functionele afhankelijkheden normaalvormen dependency preserving opsplitsing lossless join eigenschap diverse praktische aspecten Database design is meer dan alleen ‘naïeve’ (E)ER-mapping (daarna 2 college-weken) Enkele technische aspecten van belang voor een DMBS, i.e. een (zeer beperkt) kijkje ‘onder de motorkap’ van een DBMS opslagstructuren, query optimizing, transactions, recovery, ...
Introductie Normaliseren (1/5)
Introductie Normaliseren (2/5)
Introductie Normaliseren (3/5)
Introductie Normaliseren (4/5)
Introductie Normaliseren (5/5)
Data dependencies (gegevensafhankelijkheden) data dependencies zijn (specifieke soorten van) constraints; omvat o.a.: functional dependencies (FD, functionele afh.) multi-valued dependencies (MVD, meerwaardige afh.) join dependencies (JD, join-afh.) redundantie ‘update anomalies’ o.a. vanwege potentiële inconsistentie update: modification, insertion, deletion
FD’s (functionele afhankelijkheden) gegeven: een database-schema D met attributen A1, A2, …, An X {A1, A2, …, An} en Y {A1, A2, …, An} Y is functioneel afhankelijk van X (notatie: X Y) d.e.s.d. als bij een bepaalde waarde voor (de combinatie) X steeds precies één waarde hoort voor (de combinatie) Y Als de attributen van X en Y in één relatie R voorkomen: Y is functioneel afhankelijk van X (notatie: X Y) d.e.s.d. als voor elke mogelijke, toegestane inhoud van R geldt: t1,t2 R: (t1[X] = t2[X]) (t1[Y] = t2[Y]) (Evt. is R de ‘universele relatie’)
Voorbeeld FD’s (1/4) Gegeven de volgende extensie van relatie R: R A B C a e i a f i b g k c g k Gelden in R de volgende functionele afhankelijkheden: A B ? Antwoord: Nee B C ? Antwoord: Misschien !!
Voorbeeld FD’s (2/4) Gegeven de volgende extensie van een relatie: EMP ENR NAME BDATE DNR E1 John 1964-08-28 D1 E2 Joe 1968-04-04 D1 E3 Jack 1969-09-03 D1 E4 Will 1971-03-21 D2 E5 Bridget 1972-01-22 D2 Beantwoord op basis van de gegeven extensie of in EMP de volgende functionele afhankelijkheden gelden: ENR NAME ? Antwoord: Misschien DNR NAME ? Antwoord: Nee BDATE NAME ? Antwoord: Misschien
Functionele afhankelijkheden Een functionele afhankelijkheid is een constraint Of voldaan wordt aan een constraint is (mede) afhankelijk van de betekenis van de gegevens Het is niet genoeg als een constraint in één extensie opgaat, vereist is dat hij in elke extensie opgaat! Een functionele afhankelijkheid is daarmee een eigenschap van de intensie (van de DB of relatie)
Voorbeeld FD’s (3/4) Gegeven de relatie EMPLOYEE (ENR, NAME, BDATE, DNR), waarbij de 4 attributen resp. het personeelsnummer, de naam en de geboortedatum van een werknemer betreffen, en de afdeling waarvoor hij/zij werkt en waarbij geldt dat het personeelsnummer uniek is voor een werknemer. Gelden de volgende functionele afhankelijkheden? ENR NAME Antwoord: Ja DNR NAME Antwoord: Vrijwel zeker niet BDATE NAME Antwoord: Vrijwel zeker niet N.B.: bij deze beantwoording kennis gebruikt over bedrijven i.h.a.
Voorbeeld FD’s (4/4) Gegeven de volgende extensie van een relatie die van werknemers hun personeelsnummer, naam en geboortedatum weergeeft en de afdeling waarvoor hij/zij werkt: EMP ENR NAME BDATE DNR E1 John 1964-08-28 D1 E2 Joe 1968-04-04 D1 E3 Jack 1969-09-03 D1 E4 Will 1971-03-21 D2 E5 Bridget 1972-01-22 D2 Gelden de volgende functionele afhankelijkheden? ENR NAME Antwoord: Ja DNR NAME Antwoord: Nee BDATE NAME Antwoord: Nee / Misschien (met / zonder gebruik extra kennis)
Notatie Zij F een verzameling FD’s, dan notatie: F |= X Y def “X Y is logisch afleidbaar uit F”, i.e. “als alle FD’s uit F gelden, dan geldt ook X Y” F+ def { X Y | F |= X Y}
Keys / sleutels Als gegeven: een relatieschema R met attributen A1, A2, …, An een verzameling functionele afhankelijkheden F een verzameling X {A1, A2, …, An} dan geldt: X is een sleutel van R d.e.s.d. als: 1) X A1A2…...An F+ èn (identificatie) 2) Y: YX YX (Y A1A2…...An F+) (minimaliteit) Notaties: a) hier nu gebruikt: ABC def { A, B, C } = { B, A, C } b) straks ook nog: XY def X Y
‘Sleutelbegrippen’ :-) key superkey (wel identificatie, geen minimaliteit vereist) candidate key (elke echte sleutel) primary key (één uitverkozen sleutel) alternate/alternative key (alle overige sleutels) N.B.: gebruik niet, zoals in boek, de verwarrende benaming ‘secondary key’; met deze laatste term wordt i.h.a. een ‘secondary search key’ bedoeld.
Armstrong’s Afleidingsregels (=AA) Gegeven: de verzameling U van alle attributen in DB-schema D als Y X U, dan X Y (reflexiviteit) als X Y èn Z U, dan XZ YZ (augmentatie) als X Y èn Y Z, dan X Z (transitiviteit) Armstrong’s afleidingsregels zijn gezond (later: ook volledig) Idee achter bewijs ‘gezondheid’ van transitiviteit: Stel, t1[X] = t2[X] voor twee willekeurige tupels t1 en t2. Uit X Y volgt dan dat t1[Y] = t2[Y]. Uit Y Z volgt dan dat t1[Z] = t2[Z]. Dus, als t1[X] = t2[X] dan ook t1[Z] = t2[Z] (d.w.z. X Z) Hierbij: tupels uit relatie of uit ‘universele relatie’ (def cart. produkt van alle rel.’s)
Andere veel gebruikte afleidingsregels als X Y èn Z Y, dan X Z (decompositie) als X Y èn X Z, dan X YZ (vereniging) als X Y èn WY Z, dan WX Z (pseudo-transiviteit) Bewijs verenigingsregel m.b.v. AA (= Armstrong’s Afleidingsregels): 1) X Y (gegeven) 2) X Z (gegeven) 3) X YX (augmentatie van 1 met X; augmentatie met Z geeft XZ YZ, dus met X geeft X YX) 4) XY ZY (augmentatie van 2 met Y) 5) X YZ (transitiviteit op 3 en 4; YX = XY en ZY=YZ)
Logisch afl.baar vs. AA-afl.baar (“|– vs. |=”) notatie: a) F |– X Y def X Y is AA-afleidbaar uit F (i.e. afleidbaar uit F m.b.v. Armstrong’s Afl.regels) b) X+F def { A | F |– X A} m.b.v. decompositie-regel, verenigingsregel en de definitie van X+F is afleidbaar: hulpstelling: F |– X Y Y X+F (*) m.b.v. (*): Armstrong’s Afl.regels zijn volledig, d.w.z. “|– |=” al gezien: Armstrong’s Afl.regels zijn gezond, d.w.z. “|– |=”
Gezond en volledig, i.e. “|– |=” Omdat Armstrong’s afleidingsregels gezond en volledig zijn, m.a.w. omdat “|– |=”, geldt nu dus ook: X+F def { A | F |– X A } = { A | F |= X A } F+ def { X Y | F |= X Y} = { X Y | F |– X Y} F |= X Y Y X+F (**) (vgl. met hulpstelling)
Vier keer hetzelfde X Y F+ (m.b.v. definitie van F+) F |= X Y (m.b.v. “|- |=”) F |– X Y (volgens hulpstelling afgeleid uit def. X+F) Y X+F N.B.: F+ def { X Y | F |= X Y} X+F def { A | F |– X A}
Berekening van F+ is i.h.a. ondoenlijk Gegeven: DB met slechts 3 attributen: A, B en C F = Gevraagd: bereken F+ F+ = {AA, BB, CC, ABA, ABB, ABAB, BCB, BCC, BCBC, ACA, ACC, ACAC, ABCA, ABCB, ABCC, ABCAB, ABCBC, ABCAC, ABCABC} Hier zit dus heel erg veel werk aan vast... (al gauw ondoenlijk)
F G (1/2) Definitie: F G (i.e. F en G equivalent) d.e.s.d. als F+ = G+ Gegeven: • R met attributen A, B en C • F = {A B, B C, C A} • G = {A C, C B, B A} Geldt hier dan F G ? Eerste aanpak: bereken F+ en G+. F+ = {AA, BA, CA, ABA, BCA, ACA, ABCA AB, BB, CB, ABB, BCB, ACB, ABCB AC, BC, CC, ABC, BCC, ACC, ABCC AAB, BAB, CAB, ABAB, BCAB, ACAB, ABCAB ABC, BBC, CBC, ABBC, BCBC, ACBC, ABCBC AAC, BAC, CAC, ABAC, BCAC, ACAC, ABCAC AABC,BABC, CABC, ABABC, BCABC, ACABC, ABCABC} Hier zit dus heel erg veel werk aan vast... (i.h.a. ondoenlijk)
F G (2/2) Het kan ook slimmer / eenvoudiger: merk op: F+ = G+ F+ G+ G+ F+ hulpstelling: G+ F+ G F+ bewijs: “”: triviaal (m.b.v. def. van afsluiting) “”: voor elke G en H geldt: G H G+ H+; neem nu H = F+, dan krijg je dus: G F+ G+ (F+)+, maar (F+)+ = F+ (m.b.v. def. van afsluiting) G F+ kan getest worden zonder F+ uit te rekenen, n.l. door voor iedere XY G te testen of Y X+F . Immers, omdat Y X+F F |= X Y XY F+ testen we dan voor iedere XY G of geldt XY F+ . idem dito*: F G+ testen zonder G+ uit te rekenen.
Voorbeeld B+ gegeven: F = {A B, B C, C A} wat is nu B+F? B+F = {B, C, A} = BCA = ABC Algoritme 14.1 boek: X+ := X; repeat oldX+ := X+; for each FD Y Z F do if Y X+ then X+ := X+ Z; until (X+ = oldX+) (na afloop bevat X+ precies X+F ) Eigenlijk hoef je dus nogeneens geheel AG+ te berekenen, je moet alleen nagaan of de rechterkant in AG+ zit.
Terug naar ons voorbeeld: F G ? gegeven: R met attributen A, B en C F = {A B, B C, C A} G = {A C, B A, C B} geldt hier F G ? geldt F G+ ? - A B G+ ? A+G = ABC, dus B A+G, dus OK - B C G+ ? B+G = ABC, dus C B+G, dus OK - C A G+ ? C+G = ABC, dus A C+G, dus OK geldt G F+ ? - A C F+ ? A+F = ABC, dus C A+F, dus OK - B A F+ ? B+F = ABC, dus A B+F, dus OK - C B F+ ? C+F = ABC, dus B C+F, dus OK Dus: F G+ G F+ F G Eigenlijk hoef je dus nogeneens geheel AG+ te berekenen, je moet alleen nagaan of de rechterkant in AG+ zit.
Minimal set of FD’s Een verzameling FD’s F heet minimaal als: de rechterkant van iedere FD uit slechts één attribuut bestaat er geen enkele FD is met een overbodig attribuut aan de linkerkant er geen enkele overbodige FD is een FD X A heeft een “overbodig” attribuut B (B X) aan de linkerkant indien je A ook vanuit de overige attributen kan afleiden (dus als A Z+F met Z = X-B) een FD X A is “overbodig” in F wanneer je vanuit X nog steeds A kunt afleiden, zonder gebruik te maken van X A (dus als A X+H met H = F - {X A}) Voorbeeld geven: BCD --> A heeft overbodig attribuut B indien je met CD nog steeds A kunt “afleiden” (informeel), dus A (CD)+ B --> A is overbodig als je zonder deze regel vanuit B nog steeds A kan afleiden (informeel), dus bijvoorbeeld als je ook nog B --> C en C --> A hebt.
Minimal Covers G is een minimal cover van F G F èn G is minimaal Finding a minimal cover G for F (Algoritme 14.2 boek) 1. set G := F; replace each FD X A1 A2…An G by the n FD’s X A1, X A2, …, X An; (i.e. update G) 2. for each FD X A G for each attribute B X if ( (G - {XA}) {(X-B)A} ) G then replace X A by (X - B) A; (i.e. update G) 3. for each remaining FD X A G if (G - {XA}) G then remove X A from G; (i.e. update G)
Opmerking 1: Algoritme 14.2 boek Vraag: wanneer geldt: G-{XA}{X-B A} G ? 1e antwoord: 1. G-{XA}{X-B A} G+ èn 2. G (G-{XA}{X-B A})+ 1. G-{XA}{X-B A} G+ X-BA G+ G |= X-B A 2. Merk op: {X-B A} |= X AB (via augmentatie met B) en dus ook: {X-B A} |= X A Dus altijd geldt: (G-{XA}) {X-B A} |= X A Maar: XA (G-{XA}{X-BA})+ G (G-{XA}{X-B A})+ Kortom: voorwaarde 2 geldt altijd !! Eindantwoord: G-{XA}{X-BA} G X-BA G+ G |= X-B A
Opmerking 2: Algoritme 14.2 boek Vraag: wanneer geldt: G-{XA} G ? 1e antwoord: 1. G-{XA} G+ èn 2. G (G-{XA})+ 1. G-{XA} G+ dit is hoe dan ook waar, want: G-{XA} G G-{XA} G+ 2. G (G-{XA})+ X A (G-{XA})+ G-{X A} |= X A Eindantwoord: G-{XA} G X A (G-{XA})+ G-{X A} |= X A
“Slimmere” versie Algoritme 14.2 (impl. I) Finding a minimal cover G for F (vgl. Algoritme 14.2 boek) 1. set G := F; replace each FD X A1 A2…An G by the n FD’s X A1, X A2, …, X An; (i.e. update G) remove all trivial FD’s from G; 2. for each FD X A G for each attribute B X if G |= (X-B) A then replace X A by (X - B) A; (i.e. update G) 3. for each remaining FD X A G if G - {XA} |= X A then remove X A from G; (i.e. update G) “Voordeel”: afleidbaarheid is vaak snel “met het blote oog” in te zien
Voorbeeld Minimal Cover (impl. I) (1/5) Gegeven een relatie schema R = ABCDE met F = { AB DE, ABC BC, A C, A D, B D, D E, E C } Bepaal een minimal cover van F
Voorbeeld Minimal Cover (impl. I) (2/5) Stap 1: G := F met alleen enkelvoudige attributen aan de rechterkanten AB DE (opsplitsen in ABD en ABE) ABC BC (opsplitsen in ABCB en ABCC en beide weggooien) A C A D B D D E E C
Voorbeeld Minimal Cover (impl. I) (3/5) Stap 2: verwijder overbodige attributen uit de linkerkanten 1) AB D BD (volgt uit 5) (N.B. ook kon: AD) dus: G:=G-{ABD}{BD} (dus: gooi 5 weg!) 2) AB E uit (5) en (6) volgt BE (transitiviteit) dus: G:=G-{AB E}{BE} 3) A C 4) A D 5) B D 6) D E 7) E C
Voorbeeld Minimal Cover (impl. I) (4/5) Stap 3: verwijder overbodige afhankelijkheden 1) B D 2) B E volgt uit (1) en (6), dus verwijderen uit G 3) A C volgt uit (4), (6) en (7), dus verwijderen uit G 4) A D 6) D E 7) E C
Voorbeeld Minimal Cover (impl. I) (5/5) Resulterende minimal cover (eindantwoord): B D A D D E E C
“Slimmere” versie Algoritme 14.2 (impl. II) Finding a minimal cover G for F (vgl. Algoritme 14.2 boek) 1. set G := F; replace each FD X A1 A2…An G by the n FD’s X A1, X A2, …, X An; (i.e. update G) remove all trivial FD’s from G; 2. for each FD X A G for each attribute B X if A (X-B)+G then replace X A by (X - B) A; (i.e. update G) 3. for each remaining FD X A G if A X+G - {XA} then remove X A from G; (i.e. update G) “Voordeel”: d.i. de programma-versie (voor als het ingewikkelder wordt)
Voorbeeld Minimal Cover (impl. II) (1/5) Gegeven een relatie schema R = ABCDE met F = { AB DE, ABC BC, A C, A D, B D, D E, E C } Bepaal een minimal cover van F
Voorbeeld Minimal Cover (impl. II) (2/5) Stap 1: G := F met alleen enkelvoudige attributen aan de rechterkanten AB DE (opsplitsen in ABD en ABE) ABC BC (opsplitsen in ABCB en ABCC en beide weggooien) A C A D B D D E E C
Voorbeeld Minimal Cover (impl. II) (3/5) Stap 2: verwijder overbodige attributen uit de linkerkanten 1) AB D B+G = BDEC DB+G G:=G-{ABD}{BD} 2) AB E B+G = BDEC EB+G G:=G-{AB E}{BE} 3) A C 4) A D 5) B D 6) D E 7) E C
Voorbeeld Minimal Cover (impl. II) (4/5) Stap 3: verwijder overbodige afhankelijkheden 1) B D B+G-{BD} = BEC D B+G-{BD} blijft 2) B E B+G-{BE} = BDEC E B+G-{BE} G:=G-{BE} 3) A C A+G-{AC} = ADEC C A+G-{AC} G:=G-{AC} 4) A D A+G-{AD} = A (!!) D A+G-{AD} blijft 6) D E D+G-{DE} = D E D+G-{DE} blijft 7) E C E+G-{EC} = E C E+G-{EC} blijft
Voorbeeld Minimal Cover (impl. II) (5/5) Resulterende minimal cover (eindantwoord): B D A D D E E C
Soms meerdere minimal covers F = { A B, F = { A C, B C, B A, C A, C B, A C, A B, B A, B C C B } C A } De resulterende m.c. kan afhangen van de volgorde waarin je de regels behandelt. Bij één en dezelfde F kan dus meer dan één m.c. horen.
Nog enkele belangrijke definities (1) een FD X Y F+ is triviaal Y X een FD X Y F+ is volledig AX: (X-A) Y F+ (m.a.w. géén overbodig attribuut in de linkerkant) relevante FD: een niet-triviale, volledige FD X A (dus met aan de rechterkant slechts één attribuut)
Nog enkele belangrijke definities (2) sleutel FD: een FD X A waarbij X een sleutel is r_sleutel FD: een relevante FD X A waarbij X een sleutel is (m.a.w.: een relevante sleutelafh.) r_partiële FD: een relevante FD X A waarbij X een echte deelverzameling is van een of andere sleutel r_transitieve FD: een relevante FD X A waarbij X geen deelverzameling is van enige sleutel (dus X geen sleutel, noch echte deelverz. v.e. sleutel)
Precies drie soorten relevante FD’s Zij X A een relevante FD (d.w.z. een niet-triviale, volledige FD met enkelvoudige rechterkant) als er een of andere key S is met X = S, dan is X A een r_sleutel afh. als er een of andere key S is met X S èn X S, dan is X A een r_partiële afh. als er geen enkele key S is met X = S of (X S èn X S), dan is X A een r_transitieve afh. Dus: een relevante FD is: ofwel een r_sleutel afh., ofwel een r_partiële afh., ofwel een r_transitieve afh.
Redundantie & Normaliseren Problemen voortkomend uit redundantie: potentiële inconsistentie (oplossing: FD’s afdwingen) onnodig beslag op disk-ruimte update anomalieën Schema’s met (potentiële) redundantie: hoe herken je ze? normaalvormen hoe los je het op? splitsen wat zijn de valkuilen? lossless join dependency preserving
Normaalvormen: 1NF R = { Sofi, Naam, Adres, Gdatum, {Vervoermiddelen} } Sofi Naam Adres Gdatum Vervoersmiddelen 351.72.069 Kok Markt 23 1-2-1934 {fiets,auto,motorfiets} 816.45.926 Smit Spui 13 5-6-1978 {fiets} 465.99.810 Kok Kerkstr 7 2-3-1943 {auto} Attribuut “Vervoersmiddelen” is multi-valued en daarom is R niet in 1NF (en per definitie ook geen relatie) Er geldt: iedere relatie is in 1NF Preciezer geformuleerd: Ieder relationeel schema van een tabel die aan de eisen van het relationele model voldoet (en dus géén multi-valued attributen bevat), is automatisch in 1NF. …dus ook de “slechte” relationele schema’s in de voorgaande slides zijn in 1NF. Idee: “Ga eerst maar eens een correct schema maken, voordat we over redundantie gaan spreken”
Normaalvormen: 2NF (1/2) R = { Stad, Straat, Huisnr, Vraagprijs, Stadspop } F = { Stad Straat Huisnr Vraagprijs, Stad Stadspop } N.B. uit F volgt: {Stad, Straat, Huisnr} is de enige sleutel Stad1 Straat1 Huisnr1 Vraagprijs Stadspop Amsterdam Westerstr 31 500 000 734 000 Den Haag Laan 237 400 000 442 000 Den Haag Hoefkade 30 150 000 442 000 Appingedam Brink 8 200 000 12 000 Appingedam Brink 12 225 000 12 000 de “schuldige” FD: Stad Stadspop
Normaalvormen: 2NF (2/2) R = { Stad, Straat, Huisnr, Vraagprijs, Stadspop } F = { Stad Straat Huisnr Vraagprijs, Stad Stadspop } {Stad, Straat, Huisnr} is de enige sleutel De “schuldige” FD was: Stad Stadspop (zie vorige sheet) r_partiële FD: een relevante FD X A waarbij X een echte deelverzameling is van een of andere sleutel 2NF: géén r_partiële FD’s naar niet-primaire attributen toegestaan N.B. primaire attribuut = attribuut dat tot een of andere key behoort
Normaalvormen: 3NF (1/2) R = { ISBN, Titel, Auteur, Tel_Auteur } F = { ISBN Titel, ISBN Auteur, Auteur Tel_Auteur } {ISBN} is de enige sleutel ISBN1 Titel Auteur Tel_Auteur 1234 Het Stenen Bruidsbed Mulisch 06 23456789 2345 De Ontdekking v/d Hemel Mulisch 06 23456789 3456 Als je begrijpt wat ik bedoel Toonder +353 1 2345678 4567 Zoals mijn goede vader zei Toonder +353 1 2345678 de “schuldige” FD: Auteur Tel_Auteur
Normaalvormen: 3NF (2/2) R = { ISBN, Titel, Auteur, Tel_Auteur } F = { ISBN Titel, ISBN Auteur, Auteur Tel_Auteur } Key: {ISBN} De “schuldige” FD was: Auteur Tel_Auteur (zie vorige sheet) r_transitieve FD: een relevante FD X A waarbij X geen deelverzameling is van een of andere sleutel (dus geen sleutel en ook geen echte deelverz.) 3NF: géén r_partiële en géén r_transitieve FD’s naar niet-primaire attributen toegestaan
Normaalvormen: BCNF (1/3) R = { Stad, Straat, Huisnr, Postcode, Vraagprijs } F = { Stad, Straat, Huisnr Postcode, Stad, Straat, Huisnr Vraagprijs Postcode, Huisnr Vraagprijs Postcode Stad Postcode Straat } {Stad, Straat, Huisnr} en {Postcode, Huisnr} zijn de sleutels 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 de “schuldige” FD’s: Postcode Stad en Postcode Straat
Normaalvormen: BCNF (2/3) R = {Stad, Straat, Huisnr, Postcode, Vraagprijs} F = {Stad, Straat, Huisnr Postcode, Stad, Straat, Huisnr Vraagprijs Postcode, Huisnr Vraagprijs Postcode Stad Postcode Straat} Keys: { {Stad, Straat, Huisnr}, {Postcode, Huisnr} } De “schuldige” FD’s waren: (zie vorige sheet) Postcode Stad Postcode Straat BCNF: helemaal géén r_partiële of r_transitieve FD’s toegestaan (dus ook niet naar primaire attributen)
Normaalvormen: BCNF (3/3) 4 equivalente beschrijvingen van BCNF: geen r_partiële of r_transitieve FD’s (ook niet naar primaire attributen) voor iedere relevante FD X A F+ geldt: X A is een r_sleutel FD voor iedere relevante FD X A F+ geldt: X is een sleutel voor iedere niet-triviale FD X A F+ geldt: X is een supersleutel
Relevant set & relevant restriction Zij F een verzameling FD’s Als je op F (alleen) de eerste 2 stappen uitvoert van het “slimmere” algoritme 14.2 dan krijg je: FRR Wij zullen FRR de relevant restriction van F noemen N.B. ook kan: de 1e twee stappen van Algoritme 14.2 zoals in het boek, maar dan moet je daarna als derde stap alle triviale FD’s verwijderen Merk op dat FRR alleen relevante FD’s bevat en dat geldt: FRR F* = { X A | X A F+ èn X A is relevant } We zullen F* de relevant set van F noemen Zij R een relatie en F een verzameling FD’s (met alleen attrib. uit R) Leid nu eerst uit F een F’ af waarvoor geldt: F’ ΠR(F) (of F, als alleen attr. uit R) en in F’ zitten alleen relevante afhn. N.B. eerder op aparte sheet uitleggen i) primair vs. niet-primair, ii) projectie voorlopig niet, door opleggen beperking: alleen afh. met attributen uit R, en iii) reduceren tot relevante afh., d.w.z. niet-trivale afh. met enkelvoudige rechterkanten en minimale linkerkanten: 1. vervang elke X {A1, A2, …, An} door X A1, X A2, … , X An 2. minimaliseer dan de linkerkanten van alle afhn 3. verwijder triviale afhn) Elders: Een attribuut heet primair als het tot een of andere key behoort. (Dat hoeft niet noodzakelijk de primary key te zijn!) Niet-primair als het tot geen enkele (candidate) key behoort.
Overzicht normaalvormen Zij R een relatie en F een verzameling FD’s (m.b.t. attr. van R) R is in 2NF m.b.t. F F+ bevat geen r_partiële FD naar een niet-primair attribuut R is in 3NF m.b.t. F F+ bevat geen r_partiële FD naar een niet-primair attribuut en ook geen r_transitieve FD naar een niet-primair attribuut R is in BCNF m.b.t. F F+ bevat helemaal geen r_partiële of r_transitieve FD (zelfs niet naar primaire attributen) Vanzelfsprekend kun je beter alleen in F* kijken i.p.v. in heel F+. Sterker nog, slechts in FRR of in een m.c. van F kijken is al OK !! (N.B. dit laatste wordt niet bewezen) Zij R een relatie en F een verzameling FD’s (met alleen attrib. uit R) Leid nu eerst uit F een F’ af waarvoor geldt: F’ ΠR(F) (of F, als alleen attr. uit R) en in F’ zitten alleen relevante afhn. N.B. eerder op aparte sheet uitleggen i) primair vs. niet-primair, ii) projectie voorlopig niet, door opleggen beperking: alleen afh. met attributen uit R, en iii) reduceren tot relevante afh., d.w.z. niet-trivale afh. met enkelvoudige rechterkanten en minimale linkerkanten: 1. vervang elke X {A1, A2, …, An} door X A1, X A2, … , X An 2. minimaliseer dan de linkerkanten van alle afhn 3. verwijder triviale afhn) Elders: Een attribuut heet primair als het tot een of andere key behoort. (Dat hoeft niet noodzakelijk de primary key te zijn!) Niet-primair als het tot geen enkele (candidate) key behoort.
Bepaling normaalvorm: procedure + voorbeeld R = ABCD en F = {AD C, B D, CD B} Bereken eerst FRR of een m.c. (in dit vb. geldt: F = FRR = m.c. van F) Vindt alle sleutels: AB, AD Dus de primaire attributen zijn: A, B, D Classificeer de FD’s uit FRR: AD C: r_sleutelafh. (naar niet-primair attribuut) B D: r_partiële afh. (naar primair attribuut) CD B: r_transitieve afh. (naar primair attribuut) Bepaal de (hoogste, geldende) normaalvorm: 3NF N.B. FD’s die BCNF schenden zijn: B D en CD B