2009NOEA/IT - Databaser/arkitektur1 Tabeldesign Design af relationsdatabaser Normalisering

2009NOEA/IT - Databaser/arkitektur2 Uformelle designmål for tabeller Meningen med en tabel skal være let at forstå, oplysninger om forskellige ting må ikke anbringes i den samme tabel. Redundant information undgås: –pladsforbrug –opdateringsanomalier, dvs. problemer ved indsætning, modificering og sletning af data Antallet af null- værdier minimeres: –pladsforbrug Undgå uægte tupler ved JOIN

2009NOEA/IT - Databaser/arkitektur3 Tabel-mening Eksempel på dårligt tabeldesign: Udlånstabel: [bogtitel, matNr, lånernr, lånernavn, låneradresse, dato, rykkerstatus] Oplysninger om forskellige ting er blandet i den samme tabel

2009NOEA/IT - Databaser/arkitektur4 Minimér NULL-værdier Hver 10. ansat har en firmabil - hvor skal fremmednøglen placeres? Hvis NULL bliver den normale værdi, så hører attributten nok ikke til i denne tabel. PersonBil 0..1

2009NOEA/IT - Databaser/arkitektur5 Uægte tupler Betragt følgende udsnit af et ”alternativt” tabeldesign for en biblioteksdatabase: Låner:[lNr, fnavn, enavn,…….] Eksemplar:[matNr,…, enavn, …] Relationen Udlån mellem Låner og Eksemplar er designet ved, at låners efternavn er taget med i Eksemplar. Når Låner og Eksemplar efterfølgende joines vil der optræde uægte tupler, idet Låner.enavn næppe er entydig. Dvs. låner ’117 Ib Hansen’ vil optræde som låner af alle eksemplarer, hvor enavn = ’Hansen’ - altså alle eksemplarer lånt af alle mulige andre hansener (som også vil optræde som lånere af Ibs eksemplarer).

2009NOEA/IT - Databaser/arkitektur6 Normalisering Normalformerne (NF) er en formel formulering af designmål for tabeller. Normalisering er processen. Der findes 6 normalformer: –1., 2., 3. NF, og BCNF. –4. og 5. NF BCNF: Boyce-Codd Normal Form

2009NOEA/IT - Databaser/arkitektur7 Funktionelle afhængigheder Y er funktionelt afhængig af X, hvis der for samme værdi af X altid er den samme værdi af Y (X og Y er sæt af attributter) - skrives X -> Y Y er funktionelt afhængig af X (værdien af Y er altid entydigt bestemt af X, X bestemmer (el. determinerer) Y) At X -> Y siger intet om hvorvidt Y -> X er opfyldt. Klassisk eksempel: i adresse er bynavn funktionelt afhængig af postnummer (eller postnummer determinerer by). En funktionel afhængighed (X->Y) er transitiv, hvis der eksisterer et sæt af attributter Z, hvorom det gælder at X -> Z og Z -> Y.

Normaliseringseksempel 2009NOEA/IT - Databaser/arkitektur8 GrundattributterBeskrivelse EfternavnIkke entydig ID for medarbejder TypeMedarbejdertype GrundlønMedarbejderens grundløn PostnrMedarbejderens postnummer BydelDen til postnummere knyttede bydel IndgåetDato for indgåelse af ordre AfsluttetDato for afsluttelse af ordre VarenrEntydig bestemmelse af vare VarenavnIkke entydig navn for vare AntalAntal varer der indgår i en ordre PrisPris på den vare der indgår i ordren

Normaliseringseksempel 2009NOEA/IT - Databaser/arkitektur9 Vha. sund fornuft opsplittes i to entiteter –Tabsgivende (hvilken medarbejder gennemfører hvilken ordrer?) –Primærnøgle mangler Medarbejdere (1) Efternavn Type Grundløn Postnr Bydel Ordrer (1) Indgået Afsluttet Varenr Varenavn Antal Pris

Normalisering – 1NF – Medarb. 2009NOEA/IT - Databaser/arkitektur10 Krav –Primærnøgle eksisterer –Ingen repeterende grupper Medarbejdere (1) Medarbnr Efternavn Type Grundløn Postnr Bydel

Normalisering – 1NF – Ordrer 2009NOEA/IT - Databaser/arkitektur11 For ikke at gøre dekompositionen tabsgivende overføres den valgte primærnøgle til ”ordrer” –Hvad med primærnøgle her –Kombination af eksisterende attributter? –Tilføjelse af ny attribut? Ordrer (3) Ordrenr Medarbnr Indgået.. Ordrer (2) Medarbnr Indgået Afsluttet Varenr Varenavn Antal Pris

Normalisering – 1NF – Ordrer 2009NOEA/IT - Databaser/arkitektur12 Den repeterende gruppe flyttes (ordre-specifikation) til en ny tabel, og primærnøglen fra ”Ordrer” tilføjes –Hvad med primærnøgle her? Ordrer (4) Ordrenr Medarbnr Indgået Afsluttet Ordrespec (4) Ordrenr Varenr Varenavn Antal Pris Ordrespec (5) Ordrenr Varenr Varenavn Antal Pris

Normalisering – 2NF 2009NOEA/IT - Databaser/arkitektur13 Krav –Tabellen er på 1NF –Alle ikke-nøgle attributter skal være fuldt funktionelt afhængige af primærnøglen –Alle ikke-nøgle attributter skal være entydigt identificerbare ud fra hele primærnøglen (og ikke bare en delmængde af den) Tabeller med usammensatte primærnøgler er altså altid på 2NF, og det er kun nødvendigt at betragte ”Ordrespec”

Normalisering – 2NF – Ordrespec 2009NOEA/IT - Databaser/arkitektur14 Funktionelle afhængigheder i ”Ordrespec” –Pris og varenavn kan bestemmes ud fra varenr alene, og må derfor flyttes ud fra tabellen, for at gøre tabellen på 2NF

Normalisering – 2NF – Ordrespec 2009NOEA/IT - Databaser/arkitektur15 Ordrespec (6) Ordrenr Varenr Antal Lager Varenr Varenavn Pris

Normalisering – 3NF 2009NOEA/IT - Databaser/arkitektur16 Krav –Tabellen er på 2NF –ingen ikke-nøgle attribut er transitivt afhængig af primærnøglen –Alle ikke-nøgle attributter skal være gensidigt uafhængige Problem: i ”Medarbejdere” findes følgende indbyrdes afhængigheder (udover de alm. funkt. afhængigheder) –”Grundløn” afhænger af ”Type” –”Bydel” afhænger af ”Postnr”

Normaliseringseksempel – 3NF 2009NOEA/IT - Databaser/arkitektur17 Løsning: –Transitive afhængigheder isoleres og tabellen dekomponeres Medarbejdere (2) Medarbnr Efternavn Type Postnr Typer Type Grundløn Postnr Bydel

Resultat 2009NOEA/IT - Databaser/arkitektur18 Medarbejdere Medarbnr Efternavn Type Postnr Typer Type Grundløn Postnr Bydel Ordrer Ordrenr Medarbnr Indgået Afsluttet Ordrespec Ordrenr Varenr Antal Lager Varenr Varenavn Pris

2009NOEA/IT - Databaser/arkitektur19 Boyce-Codd Normal Form Alle attributter skal afhænge af nøglen, af hele nøglen og af intet andet end nøglen.