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, uke 42 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 status lev_by, 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.status leveranse1. ---> leveranse1. (, status) leveranse1.(, ) ---> leveranse1.lev_by 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.lev_by f.a., men ikke f.f.a. leveranse1.() ---> leveranse1.lev_by 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 lev_by status Dette er en modell av virkeligheten. Merk at lev_by bestemmer status! side 6 3
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. status lev_by 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 Problemer med oppdatering? te Eksempler: pass på å få med både og i where-delen av update-setn for endring av endres skal kun med i where-delen av update-setn. Masse unødvendige oppdateringer på grun insert kan ikke registrere en leverandør uten samtidig å registrere en leveranse delete sammen med siste leveranse forsvinner leverandøren side 7 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 ) lev_by status side 8 4
status lev_by 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 relasjonene tilbake til utgangspunktet. De nye tabellene kan inneholde mer informasjon enn de opprinnelige, men ikke mindre. Problemer med oppdatering? update byens status er lagret unødvendig mange ganger, eksempel: update tabell set status = 60 where lev_by = Porsgrunn kan bli mange oppdat insert Datamodellering kan ikke og databaser registrere ny by med status før vi har en leverandør side 9 der delete byens status forsvinner med den siste leverandøren Tredje normalform (3NF) Fra 2NF til 3NF: Transitive avhengigheter fjernes. Transitiv avhengighet: lev_by status, det vil si status 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. ) lev_by 1 Svendsen Lillehammer 2 Jensen Porsgrunn 3 Bø Porsgrunn 4 Christiansen Lillehammer Problemer med oppdatering? Nei. lev_by lev_by lev_by status Lillehammer 20 Porsgrunn 30 Hva er primærnøklene i disse to tabellene? Tabellen til venstre: Tabellen til høyre: lev_by status (Det blir en bedre løsning dersom vi innfører et by_nr) side 10 5
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 11 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 12 6
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 13 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 14 7
Splitter slik at BCNF er tilfredsstillt Kandidatnøkler i disse tabellene? Tabellen til venstre: og Tabellen til høyre: ev_nr, ) er kandidatnøkkel 1 Svendsen 2 Jensen 3 Bø 4 Christiansen 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 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 side 15 8