Databases I (H.15) Normaliseren Wiebren de Jonge Vrije Universiteit, Amsterdam voorlopige versie 2003 sheets 1-54 stabiel !?

Slides:



Advertisements
Verwante presentaties
H3 Tweedegraads Verbanden
Advertisements

BRIDGE Vervolgcursus Vervolg op starterscursus Bridgeclub Schiedam ‘59 info: Maandagavond: 19: – of
Sudoku puzzels: hoe los je ze op en hoe maak je ze?
SQL deel 2: datamodel ontwerp
De elektronische verzamelaanvraag Ruben Fontaine Markt- en Inkomensbeheer – dienst Aangiftes.
‘SMS’ Studeren met Succes deel 1
Les 2 : MODULE 1 STARRE LICHAMEN
Eerst wat terminologie vooraf….
BRIDGE Vervolgcursus Vervolg op starterscursus Bridgeclub Schiedam ‘59 info: Maandagavond: 19: – of
H1 Basis Rekenvaardigheden
Module 7 – Hoofdstuk 5 (1) SQL – een begin.
dia's bij lessenserie Pythagoras ± v Chr.
vwo A/C Samenvatting Hoofdstuk 6
Ronde (Sport & Spel) Quiz Night !
Van Nul naar Drie Normaliseren.
Normaliseren Datamodellering 2006.
Databases I Van EER naar relationeel
Opleiding AI cursus Databases
Hogere Wiskunde Complexe getallen college week 6
Leiden University. The university to discover. ICLON, Interfacultair Centrum voor Lerarenopleiding, Onderwijsontwikkeling en Nascholing Denkgereedschap.
9 januari 2013 Bodegraven 1. 1Korinthe 11 1 Wordt mijn navolgers, gelijk ook ik Christus navolg. 2.
Persoonlijk worden.
1 Datastructuren Sorteren: alleen of niet alleen vergelijkingen College 5.
Visibility-based Probabilistic Roadmaps for Motion Planning Tim Schlechter 13 februari 2003.
vwo C Samenvatting Hoofdstuk 12
Extra vragen voor Havo 3 WB
Omtrekshoeken Stelling van de constante hoek:
Regelmaat in getallen … … …
De grafiek van een lineair verband is ALTIJD een rechte lijn.
Regelmaat in getallen (1).
1 het type x² = getal 2 ontbinden in factoren 3 de abc-formule
Hoofdstuk 12: Oefeningen
Deze les wordt verzorgd door de Kansrekening en statistiekgroep Faculteit W&I TU/e.
Marketing Werkgroep 6.
Normalisatie Relationeel databaseontwerp:
Divide and Conquer in Multi-agent Planning Multi-Agent Planning as the Process of Merging Distributed Sub-plans Eithan Ephrati and Jeffrey S. Rosenschein.
Databases I Functionele Afhankelijkheden en Normaalvormen
Databases I Relationeel Model Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I (H.14) Functionele Afhankelijkheden en Normaalvormen
Databases I (H. 9.3) Tupelcalculus Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Normaliseren Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
13 maart 2014 Bodegraven 1. 1Korinthe Want gelijk het lichaam één is en vele leden heeft, en al de leden van het lichaam, hoe vele ook, een lichaam.
1 Datastructuren Heapsort (2e deel) College 5. 2 Vandaag  Heaps en Heapsort  (eind)  Nog sneller sorteren:  Ondergrenzen  Linair sorteren.
Projectie en stelling van thales
ribwis1 Toegepaste wiskunde Lesweek 2
ribwis1 Toegepaste wiskunde Lesweek 01 – Deel B
ribwis1 Toegepaste wiskunde, ribPWI Lesweek 01
ribwis1 Toegepaste wiskunde – Differentieren Lesweek 7
Tweedegraadsfuncties
1 Datastructuren Een informele inleiding tot Skiplists Onderwerp 13.
Vergelijkingen oplossen.
ECHT ONGELOOFLIJK. Lees alle getallen. langzaam en rij voor rij
Letterrekenen K. van Dorssen.
Hoofdstuk 5 Vijfkaart hoog, eerste verkenning 1e9 NdF-h1 NdF-h5 1 1.
17/08/2014 | pag. 1 Fractale en Wavelet Beeldcompressie Les 5.
Toets 1 Examen Reinder Reen.
12 sept 2013 Bodegraven 1. 2  vooraf lezen: 1Kor.7:12 t/m 24  indeling 1Korinthe 7  1 t/m 9: over het huwelijk  10 t/m 16: over echtscheiding  16.
Databases I (H. 7: 1-3) Het Relationele Model Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I (Info) Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Het Entity-Relationship Model
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.
Codetuts Academy Les 6 Module 2a Php Fundamentals 1.
EERDER….. Tabellen rij (record, tuple, occurence) kolom (attribuut, veld) tabel (relatie) tabelstructuur : patient(PAT#,PNAAM,LEEFTIJD,GESLACHT,ARTS)
– Software development fundamentals
Meest voorkomende vragen bij examenteksten.
Meest voorkomende vragen bij examenteksten.
– Software development fundamentals
Transcript van de presentatie:

Databases I (H.15) Normaliseren Wiebren de Jonge Vrije Universiteit, Amsterdam voorlopige versie 2003 sheets 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 = F RR = 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 R 1 : {sofinr}Key R 2 : {sofinr, vmiddel} F 1 = FF 2 =  R 1 is in BCNFR 2 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 decompositie informatie 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  {R 1, R 2, …, R n } is een decompositie van een relationeel schema R indien:  n i=1 R i = R (Dus indien alle R i ’s samen de attributen van R bevatten)  Definitie van “lossless”: Zij R een relationeel schema, zij C een verzameling constraints en zij {R 1, R 2, …, R n } een decompositie van R. {R 1, R 2, …, R n } 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” (S 1, P 1, J 1 ) (S 2, P 1, J 2 ) (S 1, P 1 )(P 1, J 1 ) (S 2, P 1 )(P 1, J 2 ) (S 1, P 1, J 1 ) (S 2, P 1, J 2 ) (S 1, P 1, J 2 ) (S 2, P 1, J 1 )

Controleren lossless-join (als 2 proj.)  Zij D = {R 1, R 2 } 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) (R 1  R 2 )  (R 1 - R 2 )  F +, òf 2) (R 1  R 2 )  (R 2 - R 1 )  F +  Merk op: (R 1  R 2 )  (R 1 - R 2 )  F +  (R 1  R 2 )  R 1  F + “  ”: augmentatie met R 1  R 2 (voeg links en rechts R 1  R 2 toe) “  ”: decompositie-regel (R 1 - R 2 is een deelverz. van R 1 )  Dus, D is een lossless join decompositie m.b.t. F d.e.s.d.a. 1) (R 1  R 2 )  R 1  F +, òf 2) (R 1  R 2 )  R 2  F + oftewel: d.e.s.d.a. R 1  R 2 een supersleutel is van R 1 of R 2

Voorbeeld Database DPD_EMP E# 1 DPD_N 1 REL EMP_NBDATED# E2Barbarawife Joe D1 E3Marydaughter Jack D1 E3Suewife Jack D1 E4Tomson Will D2 E4Marywife Will D2 DPD EMP E# 1 DPD_N 1 REL E# 1 EMP_N BDATE D# E2Barbara wife E2Joe D1 E3Mary daughter E3Jack D1 E3Sue wife E4Will D2 E4Tom son E4Mary wife

Vb. lossless-join (splitsing in 2 projecties)  D is een lossless join decompositie m.b.t. F d.e.s.d.a. 1) (R 1  R 2 )  R 1  F +, òf 2) (R 1  R 2 )  R 2  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#} R 1 = DPD = {E#, DPD_N, REL} R 2 = EMP = {E#, EMP_N, BDATE, D#} R 1  R 2 = {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_NRELEMP_NBDATED# DPM_N BUDGET DPD a 1 a 2 a 3 b 14 b 15 b 16 b 17 b 18 EMP a 1 b 22 b 23 a 4 a 5 a 6 b 27 b 28 DEPT b 31 b 32 b 33 b 34 b 35 a 6 a 7 a 8

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_NRELEMP_NBDATED#DPM_NBUDGET DPD a 1 a 2 a 3 a 4 a 5 a 6 a 7 a 8 EMP a 1 b 22 b 23 a 4 a 5 a 6 a 7 a 8 DEPT b 31 b 32 b 33 b 34 b 35 a 6 a 7 a 8 N.B. situatie na “toepassing” van E#  {EMP_N, BDATE, D#} en van D#  {DPM_N, BUDGET}

Algoritme lossless-join  Heeft een decompositie R 1, …, R k van R de lossless-join eigenschap m.b.t. een verzameling FD’s F? 1) maak een tabel met k rijen (voor iedere R 1, …, R k een rij) en n kolommen (voor ieder attribuut A 1, …, A n een kolom) 2)  i  j: zet in rij i en kolom j: het symbool a j als A j  R i het symbool b ij als A j  R i 3) “verwerk” nu telkens opnieuw alle FD’s X  Y  F totdat – òfwel één van de rijen gelijk is geworden aan a 1, …, a n – òfwel de tabel niet meer gewijzigd kan worden 4) deze decompositie is lossless  er is een rij gelijk aan a 1, …, a n  “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 a j )  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 R 1 =AD R 2 =AB R 3 =BE R 4 =CDE R 5 =AE F = {A  C, B  C, C  D, DE  C, CE  A} ABCDE R 1 a 1 b 12 b 13 a 4 b 15 R 2 a 1 a 2 b 23 b 24 b 25 R 3 b 31 a 2 b 33 b 34 a 5 R 4 b 41 b 42 a 3 a 4 a 5 R 5 a 1 b 52 b 53 b 54 a 5

Voorbeeld lossless-join algoritme (2/7) F = {A  C, B  C, C  D, DE  C, CE  A} ABCDE R 1 a 1 b 12 b 13 a 4 b 15 R 2 a 1 a 2 b 13 b 24 b 25 R 3 b 31 a 2 b 33 b 34 a 5 R 4 b 41 b 42 a 3 a 4 a 5 R 5 a 1 b 52 b 13 b 54 a 5

Voorbeeld lossless-join algoritme (3/7) F = {A  C, B  C, C  D, DE  C, CE  A} ABCDE R 1 a 1 b 12 b 33 a 4 b 15 R 2 a 1 a 2 b 33 b 24 b 25 R 3 b 31 a 2 b 33 b 34 a 5 R 4 b 41 b 42 a 3 a 4 a 5 R 5 a 1 b 52 b 33 b 54 a 5

Voorbeeld lossless-join algoritme (4/7) F = {A  C, B  C, C  D, DE  C, CE  A} ABCDE R 1 a 1 b 12 b 33 a 4 b 15 R 2 a 1 a 2 b 33 a 4 b 25 R 3 b 31 a 2 b 33 a 4 a 5 R 4 b 41 b 42 a 3 a 4 a 5 R 5 a 1 b 52 b 33 a 4 a 5

Voorbeeld lossless-join algoritme (5/7) F = {A  C, B  C, C  D, DE  C, CE  A} ABCDE R 1 a 1 b 12 a 3 a 4 b 15 R 2 a 1 a 2 a 3 a 4 b 25 R 3 b 31 a 2 a 3 a 4 a 5 R 4 b 41 b 42 a 3 a 4 a 5 R 5 a 1 b 52 a 3 a 4 a 5

Voorbeeld lossless-join algoritme (6/7) F = {A  C, B  C, C  D, DE  C, CE  A} ABCDE R 1 a 1 b 12 a 3 a 4 b 15 R 2 a 1 a 2 a 3 a 4 b 25 R 3 a 1 a 2 a 3 a 4 a 5 R 4 a 1 b 42 a 3 a 4 a 5 R 5 a 1 b 52 a 3 a 4 a 5

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 } Stad 1 Straat 1 Huisnr 1,2 Postcode 2 Vraagprijs AmsterdamWesterstr MK Den HaagLaan DT Den HaagHoefkade CA AppingedamBroerstr EK AppingedamBroerstr EK 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 } R 1 R 2 Postcode 1 Huisnr 1 VraagprijsPostcode 1 StadStraat 1015 MK MKAmsterdamWesterstr 1212 DT DTDen HaagLaan 2526 CA CADen HaagHoefkade 9901 EK EKAppingedamBroerstaat 9901 EK

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 } R 1 = {Postcode, Huisnr, Vraagprijs} R 2 = {Postcode, Stad, Straat} Er geldt: R 1  R 2 = 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) R 1 = AB (= {A, B}) R 2 = BC (= {B, C}) Er geldt: R 1  R 2 = B en B  BC  F + (dus lossless-join eigenschap) De FD A  C lijkt “tussen wal en schip te vallen”, doch:  A  C volgt uit A  B en B  C  A  B kan efficiënt in R 1 gecontroleerd/afgedwongen worden  B  C kan efficiënt in R 2 gecontroleerd/afgedwongen worden Dus: als A  B en B  C beide afgedwongen worden, dan wordt daarmee automatisch ook A  C 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 {R 1, R 2, … R k } heet dependency preserving d.e.s.d.a. (  k i=1  Ri (F (+) ))  F  M.b.v.: F  G  F + = G +  F  G + èn G  F + kan afgeleid worden: afh. bewarend  F + = (  k i=1  Ri (F)) +  F  (  k i=1  Ri (F)) + Want de tweede eis G  F +, oftewel: (  k i=1  Ri (F))  F +, volgt in dit geval uit het feit dat een proj ie van F per def ie alleen afhankelijkheden uit F + bevat.

Vb. 2: Dependency Preserving m.b.v. F + (1/3) F = {A  B, A  C, B  C} R 1 = {A,B} = AB R 2 = {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 + = {A  A, AB  A,AC  A,ABC  A A  B,B  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, AB  AB,AC  AB,ABC  AB A  BC,B  BC, AB  BC,BC  BC,AC  BC,ABC  BC A  AC, AB  AC,AC  AC,ABC  AC A  ABC, AB  ABC, AC  ABC,ABC  ABC} 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 = {A  B, A  C, B  C} R 1 = {A,B} = AB R 2 = {B,C} = BC  als deze decompositie dependency preserving is, dan zou moeten gelden: F  (  R1 (F)   R2 (F) ) +   R1 (F) = {A  A, A  B, A  AB, B  B, AB  A, AB  B, AB  AB}  R2 (F) = {B  B, B  C, B  BC, C  C, BC  B, BC  C, BC  BC}  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 B  C   R2 (F) volgt: A  C  (  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 } R 1 = {Postcode, Huisnr, Vraagprijs} R 2 = {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 + = (  k i=1  Ri (F)) +  F  (  k i=1  Ri (F)) +  Neem: G =  k i=1  Ri (F) Merk op:1) G bepalen door eerst F + uit te rekenen is 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  (  k i=1  Ri (F)) +  F  (  k i=1  * Ri (F)) +  dus nu:check voor elke FD X  Y  F of ook geldt:X  Y  (  k i=1  * Ri (F)) +

Vb. 2: Dependency Preserving met F* F = {A  B, A  C, B  C} R 1 = {A,B} = AB R 2 = {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) = {A  B}  * R2 (F) = {B  C}  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 B  C   * R2 (F) volgt: A  C  (  * 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* R 1 = {Postcode, Huisnr, Vraagprijs} R 2 = {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) R 1, R 2, …, R n is in ?NF t.o.v. een verzameling FD’s F d.e.s.d.a. iedere relatie R i 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 als de oorspronkelijke tabel(via “lossless join” algoritme) –of de FD’s (  {“gewenste constraints”}) in de decompositie op 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 X i A i die corresponderen met een afhankelijkheid X i  A i in G 3)Telkens als X i = X j mogen we de twee bijbehorende schema’s (X i A i en X j A j ) samenvoegen tot X i A i A j. 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 onze voorbeeld-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 NAAMHUISDIER Truusbridgen Truuskat Truuspuzzelen Truusgoudvis Teunsjoelen TeunHond TeunKanarie

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 hiermee redundantie kunt introduceren? (antwoord: nee, want F =  ) ZOEKENDE NAAMHOBBYHUISDIER Truusbridgenkat Truusbridgengoudvis Truuspuzzelenkat Truuspuzzelengoudvis Teunsjoelenhond Teunsjoelenkanarie

Hogere normaalvormen: 4NF (3/3) ZOEKENDE NAAMHOBBYHUISDIER Truusbridgenkat Truusbridgengoudvis Truuspuzzelenkat Truuspuzzelengoudvis Teunsjoelenhond Teunsjoelenkanarie Multi-valued dependencies (MVD’s): 1)naam --->> hobby 2)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-voorbeeld dan 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 R Er zijn 4 mogelijkheden voor G: 1)G =  dan is inderdaad iedere relevante FD een r_sleutelafh (triviaal) 2)G = {A  B} dan is A een key, dus A  B een r_sleutelafh 3)G = {B  A} dan is B een key, dus B  A een r_sleutelafh 4)G = {A  B, B  A} dan zijn A en B key’s en zijn A  B en B  A 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)