Oppdateringsanomalier. Normalformer. Institutt for informatikk INF

Transkript

1 Oppdateringsanomalier Normalformer Institutt for informatikk INF

2 Relasjonene samler beslektet informasjon Så lite dobbeltlagring som mulig Så få glisne relasjoner som mulig Korrekt totalinformasjon kan gjenskapes nøyak;g ved join INF

3 Produkt(Kode, Produktnavn, Produsent, #Enheter) Bestilling(Kode, Kundenr, Navn, Adresse, #Bestilt) A. Verdiene i Navn og Adresse er funksjonelt avhengige av verdien i Kundenr B. Kode i Bestilling er fremmednøkkel til Kode i Produkt INF

4 Tekstlig nærhet gjenspeiler logisk nærhet (Med tekstlig nærhet menes her samlokalisering i en relasjon) Brudd på dede prinsippet har en tendens ;l å påtvinge duplisering av data og dermed forårsake oppdateringsanomalier INF

5 OppreDholde konsistente verdier Håndtere sekundær informasjon Håndtere nil i kandidat- og fremmednøkler Unngå tap av sekundær informasjon OppreDholde konsistente verdier Oppdatere sekundær informasjon INF

6 Bestilling Kode Kundenr Navn Adresse #Bestilt A A B a a b 3 8 «Navn» og «Adresse» er eksempler på sekundær informasjon Dette er nyttig informasjon om kundene, men den er unødvendig i en tabell over bestillingene INF

7 Plassbehovet minimaliseres Oppdatering forenkles INF

8 Plassbehovet minimaliseres Unngår problemer med hvordan join på nil- verdier skal håndteres Unngår problemer med hvordan aggregeringsfunksjoner skal håndtere nil- verdier INF

9 SpliD (dekomponer) relasjonene slik at dobbeltlagring blir borte! Instanser for de dekomponerte relasjonene fremkommer fra opprinnelig instans ved projeksjon INF

10 Produkt(Kode, Produktnavn, Produsent, #Enheter) Kunde(Kundenr, Navn, Adresse) Ordre(Kode, Kundenr, #Bestilt) Kode i Ordre er fremmednøkkel til Produkt Kundenr i Ordre er fremmednøkkel til Kunde INF

11 Kunde Kundenr Navn Adresse Ordre Kode Kundenr #Bestilt A B a b 3 8 Bestilling Kode Kundenr Navn Adresse #Bestilt A A B a a b 3 8 INF

12 Vi ønsker å kunne rekonstruere den opprinnelige instansen Dekomposisjon av relasjoner må derfor gjøres på en måte som sikrer at vi all;d kan gjenskape den opprinnelige instansen ved naturlig join INF

13 Kunde Kundenr Navn Adresse Ordre Kode Kundenr #Bestilt A B a b 3 8 Kunde Ordre = Bestilling Kundenr Navn Adresse Kode #Bestilt A A B a a b 3 8 INF

14 Produkt(Kode, Produktnavn, Produsent, #Enheter) Kunde(Kundenr, Navn, Adresse) Koderegister(Kode, Kundenr) Antall(Kundenr, #Bestilt) Kode i Koderegister er fremmednøkkel til Produkt Kundenr i Koderegister er fremmednøkkel til Kunde Kundenr i Antall er fremmednøkkel til Kunde INF

15 Eksempelinstanser Koderegister, Antall Koderegister Antall Koderegister Antall Ordre! Kode Kundenr Kundenr #Bestilt Kode Kundenr #Bestilt Naturlig join på de to tabellene gir flere tupler enn i den opprinnelige tabellen! = Falske tupler INF

16 Korrekt totalinformasjon kan gjenskapes nøyak;g ved join: Ingen falske tupler genereres INF

17 Normalformer Problem: Hvordan vurdere objek;vt om en samling relasjoner er god/dårlig? Normalformer er et udrykk for hvor godt vi har lykkes i en dekomposisjon At et skjema er på en normalform, sikrer at visse typer dobbeltlagring ikke forekommer Jo høyere normalform, jo mindre dobbeltlagring INF

18 LiD definisjoner (gamle og nye) I de videre definisjonene tenker vi oss gitt en relasjon R(A,A,...,An) med tilhørende integritetsregler. La X R bety at X {A,A,...,An}. Hvis t er et tuppel i en instans av R, betegner t[x] verdiene i X- adribudene ;l t. INF

19 Integritetsregler Integritetsregler begrenser mengden av lovlige instanser for et databaseskjema. Primærnøkler udrykker én type integritetsregler. Primærnøkler er spesial;lfeller av kandidatnøkler. Kandidatnøkler er spesial;lfeller av funksjonelle avhengigheter. (I ;llegg finnes andre typer integritetsregler.) INF

20 Nøkler X er en supernøkkel i R: X R, og ingen instans av R får inneholde to forskjellige tupler t og t hvor t[x] = t[x]. X er en kandidatnøkkel i R: X er en supernøkkel i R, og for alle A i X er X- A ikke en supernøkkel i R. (Dvs. X er en minimal supernøkkel.) X er en primærnøkkel i R: X er en spesielt utpekt kandidatnøkkel i R. INF

21 NøkkelaDribuD Et nøkkeladribud er et adribud som er med i en kandidatnøkkel. Et ikke- nøkkeladribud er et adribud som ikke er med i noen kandidatnøkkel. INF

22 Funksjonell avhengighet (repe;sjon) GiD en relasjon R og integritetsregler for R, og gid X,Y R. Y er funksjonelt avhengig av X hvis vi for enhver lovlig instans av R har at hvis instansen inneholder to tupler t og t hvor t[x] = t[x], så må t[y] = t[y]. I så fall skriver vi X Y. Oee snakker vi for korthets skyld om «FDen X Y» (der FD står for Func;onal Dependency) Vi sier at «Y følger av X», eller at «X bestemmer Y» Integritetsregelen X AA...Ak kan alterna;vt representeres ved k FDer X A, X A,..., X Ak (hvor høyresidene består av bare ed adribud). INF

23 Funksjonell avhengighet og kandidatnøkler Merk at hvis X er en supernøkkel, så holder X Y for enhver Y. Så hvis X er en primærnøkkel, eller mer generelt en kandidatnøkkel, holder X Y for enhver Y. Omvendt: Hvis X Y for enhver Y, så er X en supernøkkel. Spesielt betyr dede at hvis vi angir at R(A,A,...,An) har en kandidatnøkkel X, betyr det at R har FDen X AA...An. Hvis R(A,A,...,An) har en primærnøkkel X, betyr det at R har FDen X AA...An. INF

24 GDB med integritetsregler Produkt(Kode, Produktnavn, Produsent, #Enheter) Bestilling(Kode, Kundenr, Navn, Adresse, #Bestilt) Integritetsregler:. Kode Produktnavn, Produsent, #Enheter (i Produkt) fordi Kode er primærnøkkel i Produkt. Kode, Kundenr Navn, Adresse, #Bestilt (i Bestilling) fordi (Kode, Kundenr) er primærnøkkel i Bestilling 3. Kundenr Navn, Adresse (i Bestilling) fordi verdiene i Navn og Adresse er funksjonelt avhengige av verdien i Kundenr (integritetsregel A på lysark 3) 4. Kode i Bestilling er fremmednøkkel til Produkt (integritetsregel B på lysark 3) INF

25 Normalformer, oversikt NF NF 3NF BCNF INF

26 Utgangspunkt for normalformene NF - BCNF Alle integritetsregler er i form av FDer (i ;llegg ;l domeneskranker og fremmednøkler) INF

27 Første normalform En relasjon er NF hvis det bare er ;llad med atomære verdier i adribudene INF

28 Andre normalform En relasjon R er NF hvis enhver ikketriviell FD X A (hvor X R og A R) ;lfredss;ller minst ed av følgende tre krav: X er en supernøkkel A er et nøkkeladribud X W for noen kandidatnøkkel W i R R bryter NF hvis det finnes en ikketriviell FD X A hvor A er et ikke- nøkkeladribud og det finnes en kandidatnøkkel W slik at X W (ekte delmengde). INF

29 Brudd på andre normalform FD X A hvor X utgjør noen av, men ikke alle, adribudene i en av kandidatnøklene og A er et ikke- nøkkeladribud. X A X er skravert. Kandidatnøkler er markert med lyseblått. INF

30 Tredje normalform En relasjon R er 3NF hvis enhver ikketriviell FD X A ;lfredss;ller minst ed av følgende to krav: X er en supernøkkel A er et nøkkeladribud R bryter 3NF hvis det finnes en ikketriviell FD X A hvor A er et ikke- nøkkeladribud og X ikke er en supernøkkel. INF

31 Brudd på tredje, men ikke andre, normalform FD X A hvor (noen av) adribudene i X er ikke- nøkkeladribuder, eventuelle nøkkeladribuder i X ikke omfader noen fullstendig kandidatnøkkel, og A er et ikke- nøkkeladribud. X A X A INF

32 Boyce- Codd normalform En relasjon R er BCNF hvis enhver ikketriviell FD X A ;lfredss;ller følgende krav: X er en supernøkkel R bryter BCNF hvis det finnes en ikketriviell FD X A hvor X ikke er en supernøkkel. INF

33 Brudd på Boyce- Codd, men ikke tredje, normalform FD X A hvor A er et nøkkeladribud og X ikke inneholder en kandidatnøkkel. X A X A X A INF

34 Brudd på normalformer i GDB Produkt(Kode, Produktnavn, Produsent, #Enheter) Bestilling(Kode, Kundenr, Navn, Adresse, #Bestilt) FDer:. Kode Produktnavn, Produsent, #Enheter (i Produkt) fordi Kode er primærnøkkel. Kode, Kundenr Navn, Adresse, #Bestilt (i Bestilling) fordi (Kode, Kundenr) er primærnøkkel 3. Kundenr Navn, Adresse (i Bestilling) fordi verdiene i Navn og Adresse er funksjonelt avhengige av verdien i Kundenr (integritetsregel A på lysark 3) Denne bryter NF (se lysark 9), så Bestilling er på NF, men ikke NF. INF

35 Normalisering Normalisering går ut på å dekomponere relasjoner med lav normalform ;l relasjoner med høyere normalform. Regel: GiD en relasjon R(XYZ) med en FD X Y. Hvis R dekomponeres ;l S(XY), S(XZ), vil vi aldri kunne få falske tupler ved naturlig join av S og S. Hvis vi dekomponerer R(XYZ) ;l S(XY), S(XZ) og det ikke er slik at X Y holder, vil vi generelt få falske tupler ved naturlig join av S og S. INF

36 Dekomponering av GDB Bruk regelen ;l å dekomponere GDB (lysark 3): Relasjon: Bes;lling(Kode, Kundenr, Navn, Adresse, #Bes;lt) FD: Kundenr Navn, Adresse X = {Kundenr} Y = {Navn, Adresse} Z = {Kode, #Bes;lt} Da blir resultatet GDB (lysark 0) : Kunde(Kundenr, Navn, Adresse) Ordre(Kode, Kundenr, #Bes;lt) I GDB er det ingen brudd på normalformene; alle relasjonene er på BCNF. INF

37 Dekomponering av GDB I dekomponeringen av GDB ;l GDB3 (lysark 4), blir ikke regelen fulgt. Da får vi en database som gir falske tupler, så GDB3 har ikke samme egenskaper som GDB og representerer derfor en annen modell av virksomhetsområdet enn den vi ønsket oss. INF

38 Normalisering ;l 3NF Det lar seg all;d gjøre å normalisere (dekomponere) ;l 3NF Men hvis en relasjon er på 3NF og ikke på BCNF, betyr det at det finnes noen funksjonelle avhengigheter som må sjekkes ved alle innseqnger og oppdateringer. (I ;llegg må selvfølgelig primær- og kandidatnøkler all;d sjekkes) INF

39 Normalisering ;l BCNF Det lar seg all;d gjøre å normalisere (dekomponere) ;l BCNF Men hvis vi har dekomponert ;l BCNF, kan det være at vi ederpå har noen funksjonelle avhengigheter som går på tvers av relasjonene. I såfall må vi ved alle innseqnger og oppdateringer joine de involverte relasjonene for å kunne sjekke at de funksjonelle avhengig- hetene fortsad er oppfylt. INF

40 Vi kan all;d normalisere ;l 3NF uten å få funksjonelle avhengigheter på tvers av relasjonene. Derfor vil man som regel nøye seg med å normalisere bare ;l 3NF i de ;lfellene hvor alterna;vet er normalisering ;l BCNF med funksjonelle avhengigheter på tvers. INF