Databases I (H.14) Functionele Afhankelijkheden en Normaalvormen

Slides:



Advertisements
Verwante presentaties
H3 Tweedegraads Verbanden
Advertisements

Les 2 klassediagrammen II
Sudoku puzzels: hoe los je ze op en hoe maak je ze?
SQL deel 2: datamodel ontwerp
Eerst wat terminologie vooraf….
Normaliseren Uitgangspunt
H1 Basis Rekenvaardigheden
Uitleg lijdend voorwerp (lv)
Hogeschool HZ Zeeland 19 augustus 2003augustus 2003 Data Structuren & Algoritmen Week 1.
Entiteit-Relatie Model
Databank van een restaurant Download op Twee tabellen: Klanten: Alle klanten die minstens.
Databases I (H.15) Normaliseren Wiebren de Jonge Vrije Universiteit, Amsterdam voorlopige versie 2003 sheets 1-54 stabiel !?
Van Nul naar Drie Normaliseren.
Normaliseren Datamodellering 2006.
<Mdl01 hoorcollege 1>
Databases I Van EER naar relationeel
Opleiding AI cursus Databases
Base: bewerkingen 2 soorten - Oplopend- Aflopend.
DEEL 1 LES 5 De basis Les 5 Spelen met troef versie
Entity Relation Model (ER-model).
1 Datastructuren Sorteren: alleen of niet alleen vergelijkingen College 5.
1 Datastructuren Sorteren: alleen of niet alleen vergelijkingen (II) College 6.
Visibility-based Probabilistic Roadmaps for Motion Planning Tim Schlechter 13 februari 2003.
Omtrekshoeken Stelling van de constante hoek:
Parallelle Algoritmen String matching. 1 Beter algoritme patroonanalyse Bottleneck in eenvoudig algoritme: WITNESS(j) (j = kandidaat in eerste i-blok)
Hoofdstuk 12: Oefeningen
Normalisatie Relationeel databaseontwerp:
Inleidend probleem Data structuur (hiërarchie van classes)
Databases I Functionele Afhankelijkheden en Normaalvormen
Databases I Relationeel Model Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I (H. 9.3) Tupelcalculus Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I (H.3) Het Entity-Relationship Model Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I (H. 1) Wiebren de Jonge Vrije Universiteit, Amsterdam Voorlopige versie 2003.
Databases I Normaliseren Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
ribwis1 Toegepaste wiskunde, ribPWI Lesweek 01
Hoofdstuk 3 Databaseontwikkeling 4 Access.  Uitgangspunt is altijd de informatiebehoefte van de klant  Deze wordt vaak bepaald door rapporten, formulieren.
Inleiding CIW 2008 Analysecollege 1. Analysevraag 1 Bekijk de reclame van Bol.com waarbij mensen vragen naar een bepaalde film, maar vervolgens een product.
Klik ergens op het witte deel van deze pagina om verder te gaan
Datastructuren Sorteren, zoeken en tijdsanalyse
H4 Differentiëren.
Uitleg bijvoeglijke bepaling (bvb)
Hoofdstuk 9 havo KWADRATEN EN LETTERS
MET DANK AAN COLLEGA’S IN DEN LANDE ! vee 2012
Vergelijkingen oplossen
SQL ( SERVER ) Les #02: T-SQL. A GENDA Herhaling les 4 Views SELECT…INTO Beheren van tabellen: CREATE ALTER DROP Opdracht voor de volgende les.
Samenvatten Klas 4A de Foorakker.
T U Delft Parallel and Distributed Systems group PGS Fundamentele Informatica in345 Deel 2 College 6 Cees Witteveen.
MBR AtT1 College 9 Diagnose met correctmodellen. Verdieping in de formalisatie. In reader: Characterizing diagnoses and Systems J. de Kleer, A.
Databases I (H. 7: 1-3) Het Relationele Model Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Praktische aspecten Database Design en Database System Architectuur Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve.
Databases I (Info) Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Het Entity-Relationship Model
Databases I (H. 2) Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003 (blijft dit jaar ‘incompleet’)
Les 0 Structured Query Language SQL. Programma Les 0 – Introductieopdracht Les 1 Les 2 Les 3 Schriftelijke toets.
ANALYSE 3 INFANL01-3 WEEK CMI Informatica.
Analyse 3 INFANL01-3 week 2 CMI Informatica.
ANALYSE 3 INFANL01-3 WEEK 8 CMI Informatica. ANALYSE 3- INFANL01-3 ▸ Vorige les ▸ Herhaling ▸ Normaliseerregels ▸ Omzetten ERD ▸ Group by en SET ▸ Proeftentamen.
ANALYSE 3 INFANL01-3 WEEK CMI Informatica.
V2.5 NdF-h6 1 NdF-h1 1 1e9 1 Hoofdstuk 6 Verliezers tellen bij troefcontract Hoofdstuk 6 Verliezers tellen bij troefcontract.
Kansverdelingen Kansverdelingen Inleiding In deze presentatie gaan we kijken naar hoe kansen zijn verdeeld. We gaan in op verschillende.
EERDER….. Tabellen rij (record, tuple, occurence) kolom (attribuut, veld) tabel (relatie) tabelstructuur : patient(PAT#,PNAAM,LEEFTIJD,GESLACHT,ARTS)
Wat is SQL (1)? SQL (Structured Query Language):  is een zeer krachtige taal met een beperkt vocabulaire (aantal ‘woorden’)  is declaratief (‘WAT’ niet.
Grammatica zinsdelen H1 t/m H6
Minimum Opspannende Bomen Algoritmiek. 2 Inhoud Het minimum opspannende bomen probleem Een principe om een minimum opspannende boom te laten groeien Twee.
Centraal Examen Nederlands
– Software development fundamentals
Minimum Opspannende Bomen
De grafiek van een lineair verband is ALTIJD een rechte lijn.
Modderdorp UNPLUGGED Bron: csunplugged.org.
– Software development fundamentals
Transcript van de presentatie:

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: YX  YX  (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+ = {AA, BB, CC, ABA, ABB, ABAB, BCB, BCC, BCBC, ACA, ACC, ACAC, ABCA, ABCB, ABCC, ABCAB, ABCBC, ABCAC, ABCABC} 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+ = {AA, BA, CA, ABA, BCA, ACA, ABCA AB, BB, CB, ABB, BCB, ACB, ABCB AC, BC, CC, ABC, BCC, ACC, ABCC AAB, BAB, CAB, ABAB, BCAB, ACAB, ABCAB ABC, BBC, CBC, ABBC, BCBC, ACBC, ABCBC AAC, BAC, CAC, ABAC, BCAC, ACAC, ABCAC AABC,BABC, CABC, ABABC, BCABC, ACABC, ABCABC} 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 XY  G te testen of Y  X+F . Immers, omdat Y  X+F  F |= X  Y  XY  F+ testen we dan voor iedere XY  G of geldt XY  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 - {XA})  {(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 - {XA})  G then remove X  A from G; (i.e. update G)

Opmerking 1: Algoritme 14.2 boek Vraag: wanneer geldt: G-{XA}{X-B A}  G ? 1e antwoord:  1. G-{XA}{X-B A}  G+ èn 2. G  (G-{XA}{X-B A})+ 1. G-{XA}{X-B A}  G+  X-BA  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-{XA})  {X-B A} |= X  A Maar: XA  (G-{XA}{X-BA})+  G  (G-{XA}{X-B A})+ Kortom: voorwaarde 2 geldt altijd !! Eindantwoord: G-{XA}{X-BA}  G  X-BA  G+  G |= X-B  A

Opmerking 2: Algoritme 14.2 boek Vraag: wanneer geldt: G-{XA}  G ? 1e antwoord:  1. G-{XA}  G+ èn 2. G  (G-{XA})+ 1. G-{XA}  G+ dit is hoe dan ook waar, want: G-{XA}  G  G-{XA}  G+ 2. G  (G-{XA})+  X A  (G-{XA})+  G-{X  A} |= X  A Eindantwoord: G-{XA}  G  X A  (G-{XA})+  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 - {XA} |= 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 ABD en ABE) ABC  BC (opsplitsen in ABCB en ABCC 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 BD (volgt uit 5) (N.B. ook kon: AD) dus: G:=G-{ABD}{BD} (dus: gooi 5 weg!) 2) AB  E uit (5) en (6) volgt BE (transitiviteit) dus: G:=G-{AB E}{BE} 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 - {XA} 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 ABD en ABE) ABC  BC (opsplitsen in ABCB en ABCC 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  DB+G  G:=G-{ABD}{BD} 2) AB  E B+G = BDEC  EB+G  G:=G-{AB E}{BE} 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-{BD} = BEC  D B+G-{BD}  blijft 2) B  E B+G-{BE} = BDEC  E B+G-{BE}  G:=G-{BE} 3) A  C A+G-{AC} = ADEC  C A+G-{AC}  G:=G-{AC} 4) A  D A+G-{AD} = A (!!)  D A+G-{AD}  blijft 6) D  E D+G-{DE} = D  E D+G-{DE}  blijft 7) E  C E+G-{EC} = E  C E+G-{EC}  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  AX: (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