INF1300 Introduksjon til databaser

Like dokumenter
Oppdateringsanomalier Normalformer

Dagens tema: Oppdateringsanomalier Normalformer

INF1300 Introduksjon til databaser

Oppdateringsanomalier. Normalformer. Institutt for informatikk INF

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Relasjonsdatabasedesign

God Databasedesign: På vei mot Normalformer

Relasjonsdatabasedesign

Relasjonsdatabaseteori

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Hva kjennetegner god relasjonsdatabasedesign? Eksempel: Grossistdatabase versjon 1

Relasjonsdatabasedesign

Normalformer or Normalisering 1NF, 2NF, 3NF, BCNF

Relasjonsdatabasedesign

Relasjonsdatabasedesign

UNIVERSITETET. Relasjonsdatabasedesign

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Relasjonsdatabasedesign

INF3100 Databasesystemer

UNIVERSITETET I OSLO. Relasjonsmodellen. Relasjoner og funksjonelle avhengigheter. Institutt for Informatikk. INF Ellen Munthe-Kaas 1

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Plenum: Nøkler, normalformer og funksjonelle avhengigheter

IN2090 Introduksjon til databaser

INF1300 Introduksjon til databaser

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Normalisering. Hva er normalisering?

Relasjonsdatabasedesign (forts.)

INF212 - Databaseteori. Kursinnhold

Relasjonsdatabasedesign. Ekstramateriale: Normalformer utover 4NF (ikke pensum)

IN2090 Databaser og datamodellering. Databasedesign og normalformer

Normalisering. Hva er normalisering?

Oppskriftsbok. FDer og MVDer - oversikt: se s. 3 Relasjonsalgebra - oversikt: se s. 45

Normalformer utover 4NF (ikke pensum)

UNIVERSITETET I OSLO. Oppskriftsbok. FDer og MVDer Relasjonsalgebra. Institutt for Informatikk. INF3100 Ellen Munthe-Kaas 1

Relasjonsdatabasedesign (forts.)

Normalisering. Hva er normalisering?

INF3100 Databasesystemer

Databaser. - Normalisering -

Dagens tema: Relasjonsmodellen (funksjonelle avhengigheter og nøkler, integritetsregler) Realisering: Fra ORM til relasjoner

INF1300 Introduksjon til databaser

Oppgaver INF3100. Oversikt over innholdet

Normalisering. Partielle avhengigheter Transitive avhengigheter Normalformer: 1NF, 2NF, 3NF, BCNF Normaliseringsstegene Denormalisering

Kunnskapsorganisasjon og gjenfinning 1

Oppgaver INF3100. Oversikt over innholdet

1. Normalisering Kommentarer til læreboka

INF1300 Introduksjon til databaser

Databaser: Relasjonsmodellen, del I

Relasjonsdatabasedesign, ekstramateriale (ikke pensum)

UNIVERSITETET I OSLO

Løsningsforslag maskindatabasen på Ifi SQL og normalisering

UNIVERSITETET I OSLO

Repetisjon: Normalformer og SQL

UNIVERSITETET I OSLO RELASJONSALGEBRA. Regning med relasjoner. Institutt for Informatikk. INF Ellen Munthe-Kaas 1

Integritetsregler i SQL

UNIVERSITETET I OSLO

Integritetsregler i SQL

Integritetsregler i SQL. Primærnøkler

For alle ikke-trivielle FDer X A i R: eller A er et nøkkelattributt i R eller X K for noen kandidatnøkkel K i R

UNIVERSITETET RELASJONSALGEBRA. Regning g med relasjoner. Institutt for Informatikk. INF Ellen Munthe-Kaas 1

Det matematisk-naturvitenskapelige fakultet. Kontroller at oppgavesettet er komplett før du begynner å besvare det.

Universitetet i Oslo Institutt for informatikk. Relasjonsmodellen og normaliseringsteori. Til bruk i IN 212. Ragnar Normann.

INF1300 Introduksjon til databaser

Løsningsforslag til eksamen i IN2090 Databaser og datamodellering og INF1300 Introduksjon til databaser 6. desember :30 18:30 (4 timer)

Relasjonsalgebraen. Algebra

Løsningsforslag for Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

UNIVERSITETET I OSLO RELASJONSALGEBRA. Regning med relasjoner. Institutt for Informatikk. INF Ragnar Normann

UNIVERSITETET I OSLO RELASJONSALGEBRA. Regning med relasjoner. Institutt for Informatikk INF Ellen Munthe-Kaas

UNIVERSITETET I OSLO RELASJONSALGEBRA. Regning med relasjoner. Institutt for Informatikk INF Ellen Munthe-Kaas

UNIVERSITETET. Relasjonsalgebra. INF Ragnhild Kobro Runde

UNIVERSITETET I OSLO INF1300 Introduksjon til databaser

Oppgave 1 ER- og relasjonsmodell 10 %

UNIVERSITETET I OSLO RELASJONSALGEBRA. Regning med relasjoner. Institutt for Informatikk. INF Ellen Munthe-Kaas

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

INF3100 V2018 Obligatorisk oppgave nr. 1

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Del 1: ER-modellering og databaseteori

EKSAMEN DATABASER

UNIVERSITETET I OSLO

1. Relasjonsmodellen Kommentarer til læreboka

SQL Structured Query Language

INF1300 Introduksjon til databaser

D: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.

Oppgave 3 - normalisering

UNIVERSITETET I OSLO INF1300 Introduksjon til databaser

SQL og Mengdelære. Oracle, MySQL, Access, bruker forskjellige syntaks.

Kunnskapsorganisasjon og gjenfinning 1. Relasjonsmodellen og -databaser

INF3100 Databasesystemer

Relasjonsmodellen og normaliseringsteori

INF3100. Databasesystemer

Transkript:

UNIVERSITETET I OSLO INF300 Introduksjon til databaser Dagens tema: Oppdateringsanomalier Normalformer INF300 7.0.008 Ellen Munthe-Kaas

Hva kjennetegner god relasjonsdatabasedesign? Relasjonene samler beslektet informasjon Så lite dobbeltlagring som mulig Så få glisne relasjoner som mulig Korrekt totalinformasjon kan gjenskapes nøyaktig ved join INF300 7.0.008 Ellen Munthe-Kaas

Eksempel: Grossistdatabase versjon I (GDB) Produkt(Kode, Produktnavn, Produsent, #Enheter) Bestilling(Kode, Kundenr, Navn, Adresse, #Bestilt) Integritetsregler i tillegg til primærnøklene: A. Verdiene i Navn og Adresse er funksjonelt avhengige av verdien i Kundenr B. Kode i Bestilling er fremmednøkkel til Kode i Produkt INF300 7.0.008 Ellen Munthe-Kaas 3

Relasjonene samler beslektet informasjon: Tekstlig nærhet gjenspeiler logisk nærhet (Med tekstlig nærhet menes her samlokalisering i en relasjon) Brudd på dette prinsippet har en tendens til å påtvinge duplisering av data og dermed forårsake oppdateringsanomalier INF300 7.0.008 Ellen Munthe-Kaas 4

Oppdateringsanomalier Innsettingsanomalier Opprettholde konsistente verdier Håndtere sekundær informasjon Håndtere nil i kandidat- og fremmednøkler Slettingsanomalier Unngå tap av sekundær informasjon Modifiseringsanomalier Opprettholde konsistente verdier Oppdatere sekundær informasjon INF300 7.0.008 Ellen Munthe-Kaas 5

Eksempelinstans Bestilling Bestilling Kode Kundenr Navn Adresse #Bestilt A A B a a b 3 8 Sekundær informasjon «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 INF300 7.0.008 Ellen Munthe-Kaas 6

Så lite dobbeltlagring som mulig: Plassbehovet minimaliseres Oppdatering forenkles INF300 7.0.008 Ellen Munthe-Kaas 7

Så få glisne relasjoner som mulig: Plassbehovet minimaliseres Unngår problemer med hvordan join på nil-verdier skal håndteres Unngår problemer med hvordan aggregeringsfunksjoner skal håndtere nilverdier INF300 7.0.008 Ellen Munthe-Kaas 8

Hvordan unngå dobbeltlagring Splitt (dekomponer) relasjonene slik at dobbeltlagring blir borte! Instanser for de dekomponerte relasjonene fremkommer fra opprinnelig instans ved projeksjon INF300 7.0.008 Ellen Munthe-Kaas 9

Eksempel: Grossistdatabase versjon (GDB) Produkt(Kode, Produktnavn, Produsent, #Enheter) Kunde(Kundenr, Navn, Adresse) Ordre(Kode, Kundenr, #Bestilt) Integritetsregler i tillegg til primærnøklene: Kode i Ordre er fremmednøkkel til Produkt Kundenr i Ordre er fremmednøkkel til Kunde INF300 7.0.008 Ellen Munthe-Kaas 0

Eksempelinstanser Kunde, Ordre Ny modell Kunde Kundenr Navn Adresse A B a b Ordre Kode Kundenr #Bestilt 3 8 Bestilling Gammel modell Kode Kundenr Navn Adresse #Bestilt A A B a a b 3 8 INF300 7.0.008 Ellen Munthe-Kaas

Krav til dekomposisjoner Vi ønsker å kunne rekonstruere den opprinnelige instansen Dekomposisjon av relasjoner må derfor gjøres på en måte som sikrer at vi alltid kan gjenskape den opprinnelige instansen ved naturlig join INF300 7.0.008 Ellen Munthe-Kaas

Kunde Ordre 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 INF300 7.0.008 Ellen Munthe-Kaas 3

Eksempel: Grossistdatabase, versjon 3 (GDB3) Produkt(Kode, Produktnavn, Produsent, #Enheter) Kunde(Kundenr, Navn, Adresse) Koderegister(Kode, Kundenr) Antall(Kundenr, #Bestilt) Integritetsregler: Kode i Koderegister er fremmednøkkel til Produkt Kundenr i Koderegister er fremmednøkkel til Kunde Kundenr i Antall er fremmednøkkel til Kunde INF300 7.0.008 Ellen Munthe-Kaas 4

Eksempelinstanser Koderegister, Antall Koderegister Antall Koderegister Antall Ordre! Kode Kundenr Kundenr #Bestilt Kode Kundenr #Bestilt 3 8 3 8 8 3 Naturlig join på de to tabellene gir flere tupler enn i den opprinnelige tabellen! = Falske tupler INF300 7.0.008 Ellen Munthe-Kaas 5

Korrekt totalinformasjon kan gjenskapes nøyaktig ved join: Ingen falske tupler genereres INF300 7.0.008 Ellen Munthe-Kaas 6

Normalformer Problem: Hvordan vurdere objektivt om en samling relasjoner er god/dårlig? Normalformer er et uttrykk 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 INF300 7.0.008 Ellen Munthe-Kaas 7

Litt 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 t s X-attributter. INF300 7.0.008 Ellen Munthe-Kaas 8

Integritetsregler Integritetsregler begrenser mengden av lovlige instanser for et databaseskjema. Primærnøkler uttrykker én type integritetsregler. Primærnøkler er spesialtilfeller av kandidatnøkler. Kandidatnøkler er spesialtilfeller av funksjonelle avhengigheter. (I tillegg fins andre typer integritetsregler.) INF300 7.0.008 Ellen Munthe-Kaas 9

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. INF300 7.0.008 Ellen Munthe-Kaas 0

Nøkkelattributt Et nøkkelattributt er et attributt som er med i en kandidatnøkkel. Et ikke-nøkkelattributt er et attributt som ikke er med i noen kandidatnøkkel. INF300 7.0.008 Ellen Munthe-Kaas

Funksjonell avhengighet (repetisjon) Gitt en relasjon R og skranker for R, og gitt 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. Ofte snakker vi for korthets skyld om «FDen X Y» (der FD står for Functional Dependency) Vi sier at «Y følger av X», eller at «X bestemmer Y» Integritetsregelen X AA...Ak kan alternativt representeres ved k FDer X A, X A,..., X Ak (hvor høyresidene består av bare ett attributt). INF300 7.0.008 Ellen Munthe-Kaas

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 kandidatnøkkel, holder X Y for enhver Y. Omvendt: Hvis X Y for enhver Y, så er X en supernøkkel. Spesielt betyr dette 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. INF300 7.0.008 Ellen Munthe-Kaas 3

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) INF300 7.0.008 Ellen Munthe-Kaas 4

Normalformer, oversikt NF NF 3NF BCNF INF300 7.0.008 Ellen Munthe-Kaas 5

Utgangspunkt for normalformene NF-BCNF Alle integritetsregler er i form av FDer (i tillegg til domeneskranker og fremmednøkler) INF300 7.0.008 Ellen Munthe-Kaas 6

Første normalform En relasjon er NF hvis det bare er tillatt med atomære verdier i attributtene INF300 7.0.008 Ellen Munthe-Kaas 7

Andre normalform En relasjon R er NF hvis enhver ikketriviell FD X A (hvor X R og A R) tilfredsstiller minst ett av følgende tre krav: X er en supernøkkel A er et nøkkelattributt X W for noen kandidatnøkkel W i R R bryter NF hvis det fins en ikketriviell FD X A hvor A er et ikke-nøkkelattributt og det fins en kandidatnøkkel W slik at X W (ekte delmengde). INF300 7.0.008 Ellen Munthe-Kaas 8

Brudd på andre normalform FD X A hvor X utgjør noen av, men ikke alle, attributtene i en av kandidatnøklene og A er et ikke-nøkkelattributt. X A X er skravert. Kandidatnøkler er markert med lyseblått. INF300 7.0.008 Ellen Munthe-Kaas 9

Tredje normalform En relasjon R er 3NF hvis enhver ikketriviell FD X A tilfredsstiller minst ett av følgende to krav: X er en supernøkkel A er et nøkkelattributt R bryter 3NF hvis det fins en ikketriviell FD X A hvor A er et ikke-nøkkelattributt og X ikke er en supernøkkel. INF300 7.0.008 Ellen Munthe-Kaas 30

Brudd på tredje, men ikke andre, normalform FD X A hvor (noen av) attributtene i X er ikkenøkkelattributter, eventuelle nøkkelattributter i X ikke omfatter noen kandidatnøkkel, og A er et ikkenøkkelattributt. X A X A INF300 7.0.008 Ellen Munthe-Kaas 3

Boyce-Codd normalform En relasjon R er BCNF hvis enhver ikketriviell FD X A tilfredsstiller følgende krav: X er en supernøkkel R bryter BCNF hvis det fins en ikketriviell FD X A hvor X ikke er en supernøkkel. INF300 7.0.008 Ellen Munthe-Kaas 3

Normalisering begrensninger Det lar seg alltid gjøre å normalisere til 3NF uten at noen funksjonelle avhengigheter går på tvers av relasjonene Det lar seg ikke alltid gjøre å normalisere til BCNF uten at noen funksjonelle avhengigheter går på tvers av relasjonene INF300 7.0.008 Ellen Munthe-Kaas 33

Brudd på Boyce-Codd, men ikke tredje, normalform FD X A hvor A er et nøkkelattributt og X ikke er en supernøkkel. X A X A X A INF300 7.0.008 Ellen Munthe-Kaas 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. INF300 7.0.008 Ellen Munthe-Kaas 35

Normalisering Normalisering går ut på å dekomponere relasjoner med lav normalform til relasjoner med høyere normalform. Regel: Gitt en relasjon R(XYZ) med en FD X Y. Hvis R dekomponeres til S(XY), S(XZ), vil vi aldri kunne få falske tupler ved naturlig join av S og S. Hvis vi dekomponerer R(XYZ) til 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. INF300 7.0.008 Ellen Munthe-Kaas 36

Normalisering Bruk regelen på forrige lysark til å dekomponere relasjonen Bestilling(Kode, Kundenr, Navn, Adresse, #Bestilt) fra GDB (lysark 3) i henhold til FDen Kundenr Navn, Adresse, dvs. med X = {Kundenr} Y = {Navn, Adresse} Z = {Kode, #Bestilt} Da blir resultatet de to relasjonene Kunde og Ordre fra GDB (lysark 0) : Kunde(Kundenr, Navn, Adresse) Ordre(Kode, Kundenr, #Bestilt) I GDB er det ingen brudd på normalformene; alle relasjonene er på BCNF. I dekomponeringen av GDB til 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. INF300 7.0.008 Ellen Munthe-Kaas 37