02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 1 Tabeldesign Design af relationsdatabaser Normalisering.

Præsentationer af emnet: "02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 1 Tabeldesign Design af relationsdatabaser Normalisering."— Præsentationens transcript:

1 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 1 Tabeldesign Design af relationsdatabaser Normalisering

2 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 2 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 –opdaterings anomalier, dvs. problemer ved indsætning, modificering og sletning af data Antallet af null- værdier minimeres: –pladsforbrug –flere fortolkninger Undgå uægte tupler ved JOIN

3 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 3 Tabel-mening Alternativt design for Nørhalne Bibliotek: Udlånstabel: [bogtitel, matNr, lånernr, lånernavn, låneradresse, dato, rykkerstatus] Oplysninger om forskellige ting blandet i den samme tabel

4 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 4 Minimér NULL-værdier Hver 10. ansat har en firmabil, hver 10. bil er (ikke) en firmabil? Hvor skal fremmednøglen placeres? Hvis NULL bliver den normale værdi, så hører attributten nok ikke til i denne tabel. Bil Ansat 1 1

5 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 5 Uægte tupler Betragt følgende udsnit af et ”alternativt” tabeldesign for Nørhalne Bibliotek: 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).

6 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 6 Normalisering Normalformerne er en formel formulering af designmål for tabeller. Normalisering er processen. Der findes 6 normalformer: –1., 2., 3., og BCNF. –4. og 5. NF BCNF er mest interessant i praksis

7 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 7 Første Normal Form (1NF) En tabel er på 1NF hvis: –der kun er simple attributter. - dvs. ingen sammensatte eller flerværdi attributter 1NF er efterhånden blevet en del af den formelle definition af en tabel i den relationelle model.

8 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 8 Funktionelle afhængigheder, fundamentet for 2., 3. og BCNF. 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). Funktionel afhængighed (FA eller FD) skrives: X -> Y Y er funktionelt afhængig af X, værdien af Y er altid entydigt bestemt af X, X bestemmer (determinerer) Y. Hvis X er en kandidat nøgle, så gælder X -> Y for alle sæt af attributter 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). Lyder flot, men: FA er forretningsregler

9 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 9 BCNF Hvis en tabel er på BCNF, er den også på 1., 2. og 3. NF. En tabel er på BCNF, hvis alle determinanter er kandidatnøgler. Det må kun være kandidatnøgler som bestemmer indholdet af andre attributter.

10 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 10 Tredje Normal Form (3NF) Forholder sig til transitive afhængigheder 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. En tabel er på 3NF hvis: –den er på 2NF –ingen ikke-nøgle attribut er transitivt afhængig af en kandidat nøgle. ”Postnummer-by”-problemet!

11 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 11 Anden Normal Form (2NF) Forholder sig til partielle afhængigheder En funktionel afhængighed X->Y er fuldt funktionel afhængig (FFA), hvis man ikke kan fjerne nogle attributter fra X uden at X->Y ophæves. Hvis en funktionel afhængighed ikke er fuld er den partiel. En tabel er på 2NF hvis: –den er på 1NF –alle ikke-nøgle attributter er fuldt funktionelt afhængige af kandidat-nøglerne. Udlånstabel: [bogtitel, matNr, lånernr, lånernavn, låneradresse, dato, rykkerstatus]

12 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 12 3NF og BCNF Der er kun forskel på 3NF og BCNF, hvis den betragtede relation –har flere kandidatnøgler, som er sammensatte, og er overlappende (dvs. har fælles attributter) dvs.: A: [a, b, c, d] Kandidatnøgler, fx: (a, b) og (a, d)

13 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 13 BCNF vs. 3NF - Ex SSP [S#, Sname, P#, Qty] Kandidatnøgler (S#, P#) og (Sname, P#) FA:S# -> Sname Sname -> S# På 3NF, idet Sname er en nøgleattribut, men tabellen indeholder uhensigtsmæssig redundans.

14 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 14 Normalisering Alle attributter skal afhænge af nøglen, af hele nøglen og af intet andet end nøglen. - So help me Codd.

15 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 15 Opgave Revider tabeldesignet for Nørhalne Bibliotek, så det er i overensstemmelse med både de uformelle og formelle designregler. Brug dette design.design Lav tabeldesign for Nørhalne Ferieby. Brug evt. denne ER-model.ER-model

16 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 16 Eksempel Tabeller ej normaliseret: Projekt:[prjId, navn, afdId, afdNavn, afdChefCpr] Ansat:[cpr, navn,….., afdId, afdNavn, afdChefCpr] Leverandør:[levId, navn, tel,…, vareId, navn,…] Leverance:[vId, lId, prjId, kvantum] ArbejderPå:[cpr, prjId, timer]

17 02-09-2007NOEA/IT - FEN - Databaser/TabelDesign 17 Opgaver Revider tabeldesign for Nørhalne Bibliotek og Nørhalne Ferieby