Hva kjennetegner god relasjonsdatabasedesign? Eksempel: Grossistdatabase versjon 1

Transkript

1 Hva kjennetegner god relasjonsdatabasedesign? Skjemaene samler beslektet informasjon: Tekstlig nærhet (samlokalisering i skjema) gjenspeiler logisk nærhet Brudd på dette har en tendens til å påtvinge dobbeltlagring av data og dermed forårsake oppdateringsanomalier Så lite dobbeltlagring som mulig: Plassbehovet minimaliseres Oppdatering forenkles Så få glisne relasjoner som mulig: Plassbehovet minimaliseres Unngår problemer med håndtering av nil-verdier Korrekt totalinformasjon kan gjenskapes nøyaktig Ingen falske data genereres INF v003 Eksempel: Grossistdatabase versjon Produkt(Kode, Produktnavn, Produsent, #Enheter) Kunde(Kode, Kundenr, Navn, Adresse, #Bestilt) Skranker:. Alle verdier i Kode i Produkt-skjemaet skal være unike. For hvert par av Kundenr, Kode i Kunde-skjemaet skal det være bare en mulig verdi av #Bestilt 3. Verdien i Kundenr bestemmer verdiene i Navn og Adresse 4. Kode i Kunde-skjemaet henspeiler på verdier i Kode i Produkt-skjemaet INF v003

2 Grossistdatabase versjon med integritetsregler Produkt(Kode, Produktnavn, Produsent, #Enheter) Kunde(Kode, Kundenr, Navn, Adresse, #Bestilt) Integritetsregler:. Kode Produktnavn Produsent #Enheter. Kundenr Kode #Bestilt 3. Kundenr Navn Adresse 4. Kode i Kunde-skjemaet er fremmednøkkel til Produkt Merk at {Kode} er en kandidatnøkkel i Produkt. Den er den eneste slike i Produkt og blir derfor primærnøkkel Merk at og 3 gir at {Kode, Kundenr} er en supernøkkel i Kundeskjemaet. Dette er dessuten en kandidatnøkkel og den eneste slike i Kunde, og blir derfor primærnøkkel INF v003 3 Eksempelekstensjon Kunde Kunde Kode Kundenr Navn Adresse #Bestilt A A B a a b 3 8 INF v003 4

3 Oppdateringsanomalier Innsettingsanomalier Opprettholde konsistente verdier Hvordan håndtere sekundær informasjon? Tillate nil i primærnøkkel? Slettingsanomalier Risikerer å miste sekundær informasjon Modifiseringsanomalier Opprettholde konsistente verdier Oppdatering av sekundær informasjon INF v003 5 Hvordan unngå oppdateringsanomalier Unngå/fjern oppdateringsanomalier og dobbeltlagring ved å splitte (dekomponere) relasjonene slik at dobbeltlagring blir borte! INF v

4 Dekomposisjon av et relasjonsskjema Gitt et relasjonsskjema R(A,A,,An). En dekomposisjon D = {R,R,,Rm} av R er en samling med skjemaer R,R,,Rm som er slik at samtlige attributter A,A,,An kan gjenfinnes i minst ett av skjemaene R,R,,Rm. INF v003 7 Eksempel: Grossistdatabase versjon Produkt(Kode, Produktnavn, Produsent) Kundereg(Kundenr, Navn, Adresse) Bestilling(Kode, Kundenr, #Bestilt) Integritetsregler: Kode i Bestilling er fremmednøkkel til Produkt Kundenr i Bestilling er fremmednøkkel til Kundereg INF v

5 Eksempelekstensjoner Kundereg, Bestilling Kundereg Bestilling Kundenr Navn Adresse Kode Kundenr #Bestilt A B a b 3 8 INF v003 9 Naturlig join Vi ønsker å kunne rekonstruere opprinnelig ekstensjon. Naturlig join er en operasjon der to relasjoner slås sammen til ett ved at to og to tupler parres hvis og bare hvis de har like verdier i attributter med likt navn INF v

6 Kundereg Kundereg Kundenr Navn Adresse Bestilling Bestilling Kode Kundenr #Bestilt A B a b 3 8 Kundereg Bestilling Kundenr Navn Adresse Kode #Bestilt A A B a a b 3 8 INF v003 Eksempel: Grossistdatabase, versjon 3 Produkt(Kode, Produktnavn, Produsent) Kundereg(Kundenr, Navn, Adresse) Kodereg(Kode, Kundenr) Antall(Kundenr, #Bestilt) Integritetsregler: Kode i Kodereg er fremmednøkkel til Produkt Kundenr i Kodereg er fremmednøkkel til Kundereg Kundenr i Antall er fremmednøkkel til Kodereg INF v003 6

7 Eksempelekstensjoner Kundereg, Bestilling Kodereg Antall Kodereg Antall Kode Kundenr Kundenr #Bestilt Kode Kundenr #Bestilt Naturlig join på de to tabellene gir flere tupler enn i den opprinnelige tabellen! = Falske tupler INF v003 3 Retningslinjer for dekomposisjon av relasjoner? Motivasjon: Fjerne oppdateringsanomalier Teknikk: Dekomponere problemrelasjoner Betingelse: Opprinnelig ekstensjon skal alltid kunne rekonstrueres nøyaktig ved naturlig join Problem: Hvordan vurdere objektivt om en samling relasjoner er god/dårlig? Hvordan sikre at en dekomposisjon aldri gir falske tupler? INF v

8 Normalformer Normalformer er et uttrykk for hvor godt vi har lykkes i en dekomposisjon Jo høyere normalform, jo færre oppdateringsanomalier Det fins algoritmer for å omforme fra lavere til høyere normalformer Det fins algoritmer for å sjekke om en dekomposisjon er tapsfri, dvs. at naturlig join aldri vil gi falske tupler INF v003 5 Utgangspunkt for normalformene NF-BCNF Alle integritetsregler er i form av FDer (og fremmednøkler) INF v

9 Normalformer, oversikt NF NF 3NF EKNF BCNF INF v003 7 Første normalform Definisjon NF (Codd 97): Alle domener omfatter atomære verdier. Funksjonsverdien til et tuppel for et gitt attributt skal være en slik atomær verdi (eller nil). Alle relasjoner er automatisk på NF. INF v

10 Andre normalform Definisjon ikketriviell FD X Y: Y inneholder minst ett attributt forskjellig fra X. Dvs.Y-X Definisjon NF (Codd 97): En relasjon R er på andre normalform hvis alle ikketrivielle FDer i R på formen X A der X er en mengde attributter og A er ett attributt i R, tilfredsstiller minst ett av følgende: i. X er en supernøkkel i R ii. A er et nøkkelattributt i R iii. X K for noen kandidatnøkkel K i R INF v003 9 Egenskaper NF NF NF siden alle relasjoner er NF Når er en relasjon NF, men ikke NF? Svar: Når det fins en ikketriviell FD X A og en kandidatnøkkel K hvor X K, X K og A ikke er et nøkkelattributt Eks: R(A,B,C,D), F={BC D, C A} Dekomposisjon: R (A,C), R (B,C,D) NF er mest av historisk interesse; vi gjør sjelden feil som bryter NF. INF v

11 Tredje normalform Definisjon 3NF (Codd 97): En relasjon R er på tredje normalform hvis alle ikketrivielle FDer i R på formen X A tilfredsstiller minst ett av følgende: i. X er en supernøkkel i R ii. A er et nøkkelattributt i R INF v003 Egenskaper 3NF 3NF NF fordi kravene til 3NF er en skjerping av kravene til NF Når er en relasjon NF, men ikke 3NF? Svar: Når det fins en ikketriviell FD X A hvor X ikke er en supernøkkel og A ikke er et nøkkelattributt og X K for noen kandidatnøkkel K Eks: R(A,B,C), F={A BC, B C} Dekomposisjon: R (A,B), R (B,C) Også 3NF er lett å oppnå. INF v003

12 Elementary Key Normal Form EKNF (Zaniolo 98) er ikke pensum, men er tatt med for oversiktens skyld. Vi gjengir ikke definisjonen her (den består i en skjerpelse av krav (ii) i 3NF. INF v003 3 Boyce-Codd Normal Form Definisjon BCNF (Boyce & Codd 974): En relasjon R er på Boyce-Codd normalform hvis alle ikketrivielle FDer i R på formen X A tilfredsstiller følgende: i. X er en supernøkkel i R INF v003 4

13 Egenskaper BCNF BCNF 3NF fordi kravene til BCNF er en skjerping av kravene til 3NF Når er en relasjon 3NF, men ikke BCNF? Svar: Når det fins en ikketriviell FD X A hvor X ikke er en supernøkkel og A er et nøkkelattributt Eks: R(A,B,C), F={AB C, C A} Dekomposisjon: R (B,C), R (A,C) Merk at FDen AB C går på tvers av R og R INF v003 5 Oppsummering normalisering Brudd på normalformer gir opphav til dobbeltlagring Jo høyere normalform, desto mindre dobbeltlagring BCNF: Alle FDer er i form av kandidatnøkler. Dvs. ingen dobbeltlagring innen skjemaet. Men: Noen FDer kan gå på tvers av skjemaer EKNF: Ingen FDer går på tvers av skjemaer, men det kan være noen FDer innen skjemaer som gir opphav til dobbeltlagring Krav til dekomposisjon: Den må være tapsfri, dvs. aldri kunne gi opphav til falske tupler Det er en fordel om dekomposisjonen også er FDbevarende, dvs. at ingen FDer går på tvers av skjemaer INF v

14 Hvorfor BCNF ikke alltid er gunstig Dersom vi har en dekomposisjon som ikke er FD-bevarende, må vi foreta join mellom skjemaene i forbindelse med oppdateringer for å sjekke at integritetsreglene overholdes. Vi har valget mellom Enten: Gå tilbake til 3NF (EKNF) og bryte BCNF, da får vi dobbeltlagring og må ta hensyn til dette under oppdatering Eller: Beholde BCNF og foreta join mellom relasjoner for å sjekke at FDer overholdes ved oppdateringer INF v003 7 Det fins algoritmer som Tester om en dekomposisjon er tapsfri Tester om en dekomposisjon er FDbevarende Dekomponerer skjemaer tapsfritt og FDbevarende Garantert EKNF, men gir ikke alltid BCNF Dekomponerer skjemaer tapsfritt til BCNF Ikke alltid FD-bevarende INF v

15 Flerverdiavhengigheter Generalisering av FDer; gir opphav til en større klasse integritetsregler enn de som kan uttrykkes ved FDer INF v003 9 Eksempel: Emnedatabase Emne(Kode, Lærebok, Foreleser) Skranker: En lærebok benyttes aldri i mer enn ett emne, men et emne kan ha flere lærebøker Hver lærer foreleser bare i ett emne, men et emne kan ha flere forelesere INF v

16 Eksempelekstensjon Emne Kode Lærebok Foreleser Emne Kode Lærebok Foreleser Inf0 Inf0 Inf0 Inf0 Inf0 Liang OOhefte Kjernen PHP Web Margunn Ingvild Erik Tone Gerhard Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Inf0 Liang Liang OOhefte OOhefte Kjernen Kjernen Kjernen PHP PHP PHP Web Web Web Margunn Ingvild Margunn Ingvild Erik Tone Gerhard Erik Tone Gerhard Erik Tone Gerhard INF v003 3 Definisjon flerverdiavhengighet Gitt et relasjonsskjema R(A,A,,A n ). La X, Y være delmengder av {A,A,,A n }. La Z være de attributtene som ikke er med i X eller Y. Y er flerverdiavhengig 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å fins det også to tupler u og u hvor. u [X]=u [X]=t [X]=t [X]. u [Y]=t [Y], u [Y]=t [Y] 3. u [Z]=t [Z], u [Z]=t [Z] INF v

17 MVD Vi skriver X Y hvis Y er flerverdiavhengig av X. Ofte snakker vi for korthets skyld om MVDen X Y der MVD står for Multi-Valued Dependency. Hvis Y X, så X Y. Hvis XY er samtlige attributter i R, så X Y. Hvis X Y, så X Y. Definisjon triviell MVD: X Y hvor Y X eller XY er samtlige attributter i R. Definisjon ekte MVD: En ikketriviell X Y hvor X Y ikke holder. MVDer benyttes til å uttrykke integritetsregler: Kode Lærebok, Kode Foreleser MVDer opptrer gjerne hvis man plasserer to :n-forhold i en relasjon og de to forholdene ikke har avhengigheter seg imellom INF v Armstrongs slutningsregler utvidet til MVDer (for spesielt interesserte). Refleksivitet FD: Hvis Y X, så X Y. Utvidelse FD: Hvis X Y, så XZ YZ 3. Transitivitet FD: Hvis X Y og Y Z, så X Z. 4. Komplement: Hvis Z er de attributtene som XY ikke omfatter, og X Y, så X Z. 5. Utvidelse MVD: Hvis X Y og Z W, så XW YZ 6. Transitivitet MVD: Hvis X Y og Y Z, så X Z-Y 7. FDer er MVDer: Hvis X Y så X Y 8. Sammensmeltning: Hvis X Y, W Z, W Y= og Z Y, så X Z Regelsettet er sunt og komplett for MVDer og FDer. INF v

18 Utgangspunkt for normalformene 4NF-5NF Alle integritetsregler er i form av FDer og MVDer (og fremmednøkler) INF v MVD-normalformer, oversikt NF BCNF 4NF PJNF DKNF 5NF INF v

19 Fjerde normalform Definisjon 4NF (Fagin 977): En relasjon R er på fjerde normalform hvis alle ikketrivielle MVDer X Y tilfredsstiller følgende: i. X er en supernøkkel i R INF v Egenskaper 4NF 4NF BCNF: Anta at R er 4NF. Vis at for enhver ikketriviell FD X Y i R er X en supernøkkel Når er en relasjon BCNF, men ikke 4NF? Svar: Når alle ikketrivielle FDer X Y er slik at X er en supernøkkel og det fins en ekte MVD Z W der Z ikke er en supernøkkel. INF v

20 Normalformene utover 4NF De øvrige normalformene er ikke pensum, men er tatt med for oversiktens skyld. PJNF: Project-Join Normal Form (Fagin 979) DKNF: Domain Key Normal Form (ref?) 5NF (Maier 983). Egenskap: Hvis vi fortsetter å dekomponere minimalt og tapsfritt, så vil ikke dekomposisjonen bety noen reduksjon i antall tupler eller verdier som må lagres, tvert imot vil lagerbehovet øke. INF v