LC238D http://www.aitel.hist.no/fag/_dmdb/ Normalisering Hva er normalisering? side 2 Normaliseringens plass i utviklingsprosessen side 3 Eksempel side 4 Funksjonell avhengighet side 5-6 Første normalform (1NF) side 7 Andre normalform (2NF) side 8-9 Tredje normalform (3NF) side 10 Generelle definisjoner av 2NF og 3NF side 11-13 Boyce-Codd normalform (BCNF) side 13-15 Framstillingen avviker noe fra læreboka, der normalisering gjennomgås i kapittel 3. Forelesning 10 Hva er normalisering? Normalisering er en formell metode for å designe relasjonsdatabaser Mål: Å unngå unødvendig dobbeltlagring av data (redundans) pga dobbeltlagring lett fører til inkonsistente data. Dobbeltlagring er kun nødvendig for å kople tabeller sammen (referanseintegritet, primærnøkkel fremmednøkkel) Middel: Dele opp eksisterende tabeller Normaliseringen legger stor vekt på å finne kandidatnøkler. Det stilles formelle krav til sammenhengen mellom attributtene i en tabell. Jo strengere krav, desto høyere normalform. 1NF, 2NF, 3NF, BCNF, 4NF, 5NF,? 4NF og 5NF kun av teoretisk betydning. Gjennomgås ikke. side 2 1
Normaliseringens plass i utviklingsprosessen Som kvalitetssikring: Relasjonsmodell basert på EER-diagram Normalisering Enda bedre relasjonsmodell For å forstå en eksisterende database: Et sett med tabeller Klargjør funksjonelle avhengigheter Grunnlag for å lage EER-modell side 3 Har fått følgende dataeksempel til vurdering, 1 Svendsen 20 Lillehammer (1, 300), (2, 200), (3, 400), (4, 200), (5, 100), (6, 100) 2 Jensen 30 Porsgrunn (1, 300), (2, 400) 3 Bø 30 Porsgrunn (2, 400) 4 Christiansen 20 Lillehammer (2, 200) Det er fullt mulig å ta tak i dette via EER-modellering, men vi velger normalisering ettersom dataene allerede er gitt på tabellform. Kan vi bruke denne tabellen i databasen? NEI Skal gjennomgå Codds tre-trinns-prosess (1972) 1NF 2NF 3NF Forutsetter kun én kandidatnøkkel. side 4 2
Funksjonell avhengighet Gitt en relasjon R med (bl.a.) attributtene X og Y. X og Y kan være sammensatte. Y er funksjonelt avhengig (f.a.) av X hvis og bare hvis det til hver X-verdi er assosiert eksakt en Y-verdi. R.X ---> R.Y Eller: X bestemmer ( determinerer ) Y. X er en determinant. Eks.: leveranse1. ---> leveranse1. leveranse1. ---> leveranse1. (, ) leveranse1.(, ) ---> leveranse1. Dersom X er en supernøkkel må alle de øvrige attributtene være funksjonelt avhengig av X. Y er fullt funksjonelt avhengig (f.f.a.) av X, hvis den er funksjonelt avhengig av X, og det ikke fins en delmengde Z av X som Y er funksjonelt avhengig av. Eks.: leveranse1.(, ) ---> leveranse1. f.a., men ikke f.f.a. leveranse1.() ---> leveranse1. f.f.a. (og dermed f.a.) Heretter betyr f.a. det samme som f.f.a. side 5 Viser funksjonelle avhengigheter i et diagram Dette er en modell av virkeligheten. Merk at bestemmer! side 6 3
Tabellen foran ser slik ut på 1NF: Første normalform (1NF) Første normalform (1NF): Det eksisterer en primærnøkkel, og ingen del av denne er NULL. Tabellen inneholder ikke repeterende grupper. - Kun én verdi i hver rute i tabellen. 1 Svendsen 20 Lillehammer 1 300 1 Svendsen 20 Lillehammer 2 200 1 Svendsen 20 Lillehammer 3 400 1 Svendsen 20 Lillehammer 4 200 1 Svendsen 20 Lillehammer 5 100 1 Svendsen 20 Lillehammer 6 100 2 Jensen 30 Porsgrunn 1 300 2 Jensen 30 Porsgrunn 2 400 3 Bø 30 Porsgrunn 2 200 4 Christiansen 20 Lillehammer 2 200 side 7 Hva er primærnøkkelen? (, ) Tabellen foran ser slik ut på 1NF: Første normalform (1NF) Første normalform (1NF): Det eksisterer en primærnøkkel, og ingen del av denne er NULL. Tabellen inneholder ikke repeterende grupper. - Kun én verdi i hver rute i tabellen. 1 Svendsen 20 Lillehammer 1 300 1 Svendsen 20 Lillehammer 2 200 1 Svendsen 20 Lillehammer 3 400 1 Svendsen 20 Lillehammer 4 200 Problemer med oppdatering? Update Eksempler: pass på å få med både og i where-delen av update-setn for endring av, men hvis skal endres skal kun med i where-delen av update-setn. Masse unødvendige oppdateringer på grunn av dobbeltlagringen. insert kan ikke registrere en leverandør uten samtidig å registrere en leveranse delete sammen med siste leveranse forsvinner leverandøren 1 Svendsen 20 Lillehammer 5 100 1 Svendsen 20 Lillehammer 6 100 2 Jensen 30 Porsgrunn 1 300 2 Jensen 30 Porsgrunn 2 400 3 Bø 30 Porsgrunn 2 200 4 Christiansen 20 Lillehammer 2 200 side 8 4
Andre normalform (2NF) Andre normalform (2NF): En relasjon er på 2NF hvis og bare hvis den er på 1NF, og den ikke inneholder partielle avhengigheter (en ikkenøkkel-attributt er f.a. av en del av primærnøkkelen). Fra 1NF til 2NF: Splitt opp relasjonen i flere nye relasjoner slik at partielle avhengigheter unngås. ( Ingen piler krysser bokser ) side 9 Splitter 1NF-tabellen i to 1 Svendsen 20 Lillehammer 2 Jensen 30 Porsgrunn 3 Bø 30 Porsgrunn 4 Christiansen 20 Lillehammer 1 1 300 1 2 200 1 3 400 1 4 200 1 5 100 1 6 100 2 1 300 2 2 400 3 2 200 4 2 200 Splitter ved å foreta en projeksjon. En naturlig forening bringer relasjonene tilbake til utgangspunktet. De nye tabellene kan inneholde mer informasjon enn de opprinnelige, men ikke mindre. side 10 5
1 Svendsen 20 Lillehammer 2 Jensen 30 Porsgrunn 3 Bø 30 Porsgrunn 4 Christiansen 20 Lillehammer Splitter 1NF-tabellen i to 1 1 300 1 2 200 1 3 400 1 4 200 1 5 100 1 6 100 2 1 300 Hva er primærnøklene i 2 2 400 disse to tabellene? 3 2 200 Tabellen over: 4 2 200 Tabellen til høyre: (, ) Splitter ved å foreta en projeksjon. En naturlig forening bringer Problemer relasjonene med oppdatering? tilbake til utgangspunktet. update byens er lagret unødvendig mange ganger, eksempel: De nye tabellene kan inneholde mer informasjon enn de opprinnelige, update tabell set = 60 where = Porsgrunn kan bli mange oppdateringer men ikke mindre. insert kan ikke registrere ny by med før vi har en leverandør der delete byens forsvinner med den siste leverandøren side 11 Tredje normalform (3NF) Fra 2NF til 3NF: Transitive avhengigheter fjernes. Transitiv avhengighet:, det vil si Tredje normalform (3NF): En relasjon er på 3NF, hvis og bare hvis den er på 2NF, og den ikke inneholder transitive avhengigheter. ( Alle piler utgår fra primærnøkkelen. ) 1 Svendsen Lillehammer 2 Jensen Porsgrunn 3 Bø Porsgrunn 4 Christiansen Lillehammer Lillehammer 20 Porsgrunn 30 side 12 6
Tredje normalform (3NF) Fra 2NF til 3NF: Transitive avhengigheter fjernes. Transitiv avhengighet:, det vil si Tredje normalform (3NF): En relasjon er på 3NF, hvis og bare hvis den er på 2NF, og den ikke inneholder transitive avhengigheter. ( Alle piler utgår fra primærnøkkelen. ) 1 Svendsen Lillehammer 2 Jensen Porsgrunn 3 Bø Porsgrunn 4 Christiansen Lillehammer Problemer med oppdatering? Nei. Lillehammer 20 Porsgrunn 30 Hva er primærnøklene i disse to tabellene? Tabellen til venstre: Tabellen til høyre: (Det blir en bedre løsning dersom vi innfører et by_nr) side 13 Generelle definisjoner av 2NF og 3NF Hva hvis flere kandidatnøkler? 2NF En relasjon er på 2NF hvis og bare hvis den er på 1NF, og den ikke inneholder partielle avhengigheter (en ikke-nøkkel-attributt er f.a. av en del av en kandidatnøkkel). 3NF En relasjon er på 3NF, hvis og bare hvis den er på 2NF, og den ikke inneholder transitive avhengigheter, dvs at det ikke fins ikkenøkkelattributter som er funksjonelt avhengig av andre ikkenøkkelattributter. side 14 7
Eksempel med flere kandidatnøkler Anta at også entydig identifiserer en leverandør. Ellers noe forenklet: To kandidatnøkler: (, ) (, ) Sjekk mot de generelle definisjonene av 2NF og 3NF side 15 Eksempel med flere kandidatnøkler, forts 1 Svendsen 1 300 1 Svendsen 2 200 1 Svendsen 3 400 1 Svendsen 4 200 1 Svendsen 5 100 1 Svendsen 6 100 2 Jensen 1 300 2 Jensen 2 400 3 Bø 2 200 4 Christiansen 2 200 Problemer med oppdatering? Tilsvarende problemer som tidligere, Kan f.eks. ikke registrere leverandørinfo uten leveranse. Tabellen har to eller flere kandidatnøkler Minst to av kandidatnøklene er overlappende Minst to av kandidatnøklene er sammensatte side 16 8
Boyce-Codd normalform (BCNF) Boyce-Codd normalform (BCNF): En relasjon tilfredsstiller BCNF hvis enhver determinant er en kandidatnøkkel. Hvis en tabell har bare én kandidatnøkkel, er 3NF og BCNF ekvivalente. 1 Svendsen 1 300 1 Svendsen 2 200 1 Svendsen 3 400 1 Svendsen 4 200 1 Svendsen 5 100 1 Svendsen 6 100 2 Jensen 1 300 2 Jensen 2 400 3 Bø 2 200 4 Christiansen 2 200 Er BCNF oppfylt? Nei, og er begge determinanter som ikke er kandidatnøkler To kandidatnøkler: (, ) (, ) side 17 Kandidatnøkler i disse tabellene? Tabellen til venstre: og Tabellen til høyre: (, ) er kandidatnøkkel Splitter slik at BCNF er tilfredsstillt 1 Svendsen 2 Jensen 3 Bø 4 Christiansen 1 1 300 1 2 200 1 3 400 1 4 200 1 5 100 Konklusjon: Unødvendig å gå gjennom 1NF 2NF 3NF prosessen. I praktisk arbeid er det nok å sjekke at BCNF er oppfylt. BCNF kan også brukes dersom de tre kravene midt på side 93 i læreboka ikke er oppfylt. 1 6 100 2 1 300 2 2 400 3 2 200 4 2 200 side 18 9