Föreläsning 6: Normalisering & funktionella beroenden

Transkript

1 Föreläsning 6: Normalisering & funktionella beroenden DVA234 Databaser IDT Akademin för Innovation, Design och Teknik

2 Innehåll Föreläsningens mål: Att ge en överblick över hur normalisering fungerar Önskvärda egenskaper i relationsdatabaser Designregler Funktionella beroenden Normalisering Normaliseringsprocessen Normalformer Normaliseringsövning 2

3 Vad är problemet? DB P# Enamn Fnamn Akad# ANamn AOrt Kurs# KursNamn Larsson Lars 101 IDT Västerås DVA110 Programvaruteknik Larsson Lars 101 IDT Västerås DVA230 Datornätverk Larsson Lars 101 IDT Västerås DVA251 Operativsystem Frisk Ove 101 IDT Västerås DVA300 Datorgrafik Frisk Ove 101 IDT Västerås ELA280 Analog Elektronik Frisk Ove 101 IDT Västerås ELA290 Digital Elektronik Frisk Ove 102 HVV E-tuna BC4110 Psykologi gk Frisk Ove 102 HVV E-tuna BC4120 Psykologi fk Alm Linda 108 EST Västerås ST2780 Materialteknik Nordin Hans 109 IDT E-tuna MFT711 Produktutveckling En databas med endast en tabell 3

4 Vad är problemet? Redundant information Samma information upprepas i flera rader, flera kolumner Risk för inkonsistent inmatning Ändringar/uppdateringar krävs på flera ställen Tänk databaser med tusentals eller miljontals rader!!! Mix av olika entitetstyper Personal (Lärare), Akademier och Kurser Hur lagra info om en lärare? Hur lagra info om en akademi? Hur lagra info om en kurs? Oberoende entiteter blir beroende av varandras existens 4

5 Uppdateringsanomalier anomali = abnormitet, avvikelse, rubbning, etc Uppdateringsanomalierna innebär problem vid följande operationer: INSERT: tillägg av nya rader UPDATE: uppdatering av attribut i existerande rader DELETE: borttagning av rader INSERT-anomalin För att lägga till en rad krävs uppgifter om samtliga entiteter, annars riskeras NULL-värden i vissa fält. (Vilket inte går för composite PK!!) Exempel: För att lagra uppgifter om en akademi krävs också info om en lärare och en kurs. 5

6 Uppdateringsanomalier : UPDATE UPDATE-anomalin Uppdatering av attribut krävs på flera rader Risk för inkonsistent uppdatering En rad (entitet) kan missas Felaktiga och motsägande uppgifter kan uppstå Exempel: IDT och EST byter namn till EDT! Uppdateringar krävs för varje kurs och för varje lärare (minst 200 rader!!!) 6

7 Uppdateringsanomalier : DELETE DELETE-anomalin Borttagning av rader tar bort mer info än nödvändigt Risk för att man tappar information Entiteter som ska vara kvar försvinner också Exempel: Den sista personen på EST, Linda Alm, ska sluta (tas bort), men EST ska leva vidare liksom hennes kurs ST2780. Info om EST och ST2780 försvinner också = inte bra! 7

8 Så Hur löser vi detta?? DB P# Enamn Fnamn Akad# ANamn AOrt Kurs# KursNamn Larsson Lars 101 IDT Västerås DVA110 Programvaruteknik Larsson Lars 101 IDT Västerås DVA230 Datornätverk Larsson Lars 101 IDT Västerås DVA251 Operativsystem Frisk Ove 101 IDT Västerås DVA300 Datorgrafik Frisk Ove 101 IDT Västerås ELA280 Analog Elektronik Frisk Ove 101 IDT Västerås ELA290 Digital Elektronik Frisk Ove 102 HVV E-tuna BC4110 Psykologi gk Frisk Ove 102 HVV E-tuna BC4120 Psykologi fk Alm Linda 108 EST Västerås ST2780 Materialteknik Nordin Hans 109 IDT E-tuna MFT711 Produktutveckling En databas med endast en tabell 8

9 Vad är bra databasdesign? Hur undviks uppdateringsanomalierna? Vad skiljer en bra design från en dålig? För att lösa frågorna finns praktiska och formella metoder: Praktiska (informella) metoder består av designregler (guidelines) Formella metoder (mer precisa) bygger på analys och egenskaper hos relationer Formella metoderna bygger på följande begrepp: Funktionella beroenden Normalformer 9

10 Informell metod Egentligen tre huvudregler: Varje tabell ska beskriva en typ av sak Varje rad ska innehålla data om en enda sådan sak Varje sak ska finnas på en enda rad Tänk er en tabell för anställda: Anställd(Pnr, Namn, Telefon, Lön, Chef, Avdelning) Undvik t ex: Chefstelefon Detta är information som hör till chefen Avdelningsadress Detta är information som hör till avdelningen 10

11 Formella designmetoder Funktionella beroenden (Functional Dependencies FDn): Definierar beroenden mellan attribut Givet en mängd av FD kan ytterligare FDn härledas m.h.a. regler Normalformer FDn och nycklar används för att definiera en relations normalform. Onormaliserade relationer normaliseras till olika nivåer av normalformer 1:a, 2:a, 3:de normalformena vanligast (Dessa ingår i kursen) Boyce Codds normalform, 4:de & 5:e normalformerna (Ingår inte, kolla i boken eller på nätet) 11

12 Funktionella beroenden För X -> Y, där X och Y är attributmängder i en relation, gäller att två tupler som har samma värde för X, måste också ha samma värde för Y, dvs X bestämmer/determinerar Y T.ex: StudentID -> Namn //Studentid bestämmer namnet Pnr -> {Namn, Adress} //Pnr bestämmer namn och adress {Pnr, Kurskod} -> Tim. //Pnr och kurskod bestämmer timmar X -> Y för relationen R specificerar ett villkor som måste gälla för alla rader i relationen R En alternativ notation är med pilar mellan attribut: Pnr# Namn Adress FDn fås genom att analysera beroenden och villkor mellan attribut. Det är databasdesignerns uppgift att hitta och specificera dem! 12

13 Så, vår tabell igen Några av de märkliga funktionella beroendena i denna tabell är: DB P# Enamn Fnamn Akad# ANamn AOrt Kurs# KursNamn Personnr determinerar namn Akademi determinerar dess namn och ort Kurskod determinerar kursens namn Kurskoden determinerar vilken akademi den ges på och vilken person som ger den. eller nått... 13

14 Att hitta FDn Att hitta funktionella beroenden kräver, likt för ER modellering Kunskap om semantiken för datat Betänk följande tabell Kan vi givet denna tabell anta något FD?? X Y Kalle 42 Pelle 45 Lisa 26 Kalle 42 Lisa 26 Det är lätt att tro att X->Y, eller hur?? 14

15 Att hitta FDn Att hitta funktionella beroenden kräver, likt för ER modellering Kunskap om semantiken för datat Betänk följande tabell Kan vi givet denna tabell anta något FD?? Studie Förnamn Skostorlek Kalle 42 Pelle 45 Lisa 26 Kalle 42 Lisa 26 Pelle 41 Man kan troligen aldrig göra ett verktyg som automagiskt hittar FDn 15

16 Vad anses normalt!? Vad är en normalform? En relations normalform bestäms av egenskaperna hos funktionella beroenden mellan relationens attribut eller Relationens FDn används för att avgöra relationens normalform Normalformer är rangordnade efter deras kvalitet : 1NF (lägst), 2NF, 3NF, BCNF, 4NF, 5NF (högst) osv Ju högre normalformen är desto mindre av problemen med: redundanta tupler/värden uppdateringsanomalier Målet är att designa relationer med höga normalformer. Normalisering är processen för att omarbeta relationer av en viss normalform till en högre normalform. 16

17 Normaliseringsprocessen Normaliseringen består av följande steg: 1. Analysera och identifiera FDn för alla relationsscheman 2. Avgöra normalformen för varje relationsschema = testa vilken normalforms egenskaper som relationsschemat uppfyller 3. Omarbeta eller dela upp relationsscheman med låg normalform (typiskt < 3NF) 4. Avgöra normalformen för ev. nya relationsscheman: om lägre än 3NF, gå tillbaka till pkt 3. om 3NF eller högre = relationsschemat är normaliserat = klart! Normaliseringsprocessen är klar när alla relationsscheman är minst i 3NF, dvs databasen anses vara normaliserad. I sällsynta fall pågår normaliseringen tills BCNF, 4NF eller 5NF uppfylls används sällan praktiskt, men behövs i speciella fall. 17

18 Repetition nyckelbegrepp Kandidatnyckel (eng. candidatekey) En nyckel som kandiderar till att vara primärnyckel för en relation En relation kan ha flera kandidatnycklar (StudentID OCH Pnr t.ex) Primärnyckel En kandidatnyckel som utses till att vara den primära Kandidatnycklar som inte är primärnyckel kallas också för alternativ nycklar (eng. alternate keys) eller sekundärnycklar Främmande Nyckel En nyckel som pekar ut en primärnyckel i en (annan) tabell 18

19 1:a normalformen 1NF Definition: Ett relationsschema är i 1NF om varje attribut endast kan ha ett odelbart (atomärt) värde. Ovanstående innebär: varje attribut kan högst ha ett värde värdena måste vara odelbara värdemängder (sets) och andra sammansatta värden (composite values) tillåts inte attribut kan inte ha relationer som värden relationer i relationer (nästlade relationer) tillåts inte I praktiken är 1NF inbakat i definitionen av relationsmodellen. 1NF innebär då att tabeller/relationer garanteras följa relationsmodellens principer. 19

20 1NF-normalisering 1NF-normalisering innebär att relationer med flervärdesattribut, eller nästlade relationer, görs om så att de strikt följer relationsmodellens principer: ett värde per attribut! Tupler med flervärdesattribut bryts upp i flera tupler, ett för varje värde i flervärdesattributet. Övriga attribut i tuplerna blir redundanta! Exempel på nästa sida 20

21 Exempel: 1NF-normalisering (a) ett relationsschema som inte är i 1NF. (b) Exempelstillstånd för relationen DEPARTMENT. (c) 1NF version av samma relation. Notera nyckeln! 21

22 2:a normalformen 2NF Definition: Ett relationsschema är i 2NF om det dels är i 1NF, dels att varje ickenyckelattribut är beroende på hela primärnyckeln. Beroenden på hela primärnyckeln innebär att alla FDn måste vara vänsterminimala: dvs det får inte finnas FDn med beroenden på delar av nyckeln (nyckelattributen), s.k. partiellt nyckelberoende 2NF är endast relevant att analysera när primärnyckeln består av flera attribut. 22

23 2NF-normalisering 2NF-normalisering innebär att man eliminerar beroenden till delar av primärnyckeln. Exempel: Givet en relation R{A, B, C, D, E}, där A och B är nyckelattribut MEN attributet E enbart beror på B, dvs följande FDn gäller: A, B à C, D, E Bà E Normalisering till 2NF innebär att E måste brytas ut till en ny relation S med B som PK och FK till R. Resultat blir två relationer: R {A, B, C, D} S {B, E} där A och B är PK och B är FK till S där B är PK 23

24 Exempel: 2NF-normalisering Normalisering av EMP_PROJ till 2NF-relationerna EP1, EP2 och EP3. 24

25 3:e normalformen 3NF Definition: Ett relationsschema är i 3NF om det är i 2NF och att varje ickenyckelattribut inte är transitivt beroende på primärnyckeln. Inga transitiva beroenden på PKn innebär: Att ickenyckelattribut inte får vara beroende på andra ickenyckelattribut Exempel: Givet en relation R{A, B, C, D, E}, där A och B är nyckelattribut och attributet E beror på D som i sin tur beror på A och B, dvs följande FDn gäller: A, B à C, D, E Dà E Normalisering till 3NF innebär att E måste brytas ut till en ny relation S med D som PK och FK till R. Resultat blir två relationer: R {A, B, C, D} där A och B är nyckelattribut S {D, E} där D är PK och FK till R 25

26 Exempel: 3NF-normalisering Normalisering av EMP_DEPT till 3NF-relationerna ED1 och ED2. 26

27 3NF och kandidatnycklar Kommer ni ihåg skillnaden på primärnyckel och kandidatnyckel? 3NF gäller bara ICKEnycklar, dvs. inte kandidatnycklar!!!! Exempel: StudentID# Personnummer Namn upn Ulla Persson Borde vara transitivt beroende 3NF Men Personnummer kan ju också determinera Studentid! Personnummer är en kandidatnyckel och då räknas den inte som transitiv = 3NF 27

28 Exempelövning Normalisera följande tabell (till 3NF minst) Rita FD-diagram Avgör vilken normalform den är i nu Normalisera. Reg# Fartyg Rederi Land Flagga Kapacitet Klass Last# Last Volym F001 MS Freja Dahléns Sverige Sverige L001 Timmer 1500 F001 MS Freja Dahléns Sverige Sverige L002 Kol 2000 F001 MS Freja Dahléns Sverige Sverige L003 Stål 3000 F002 Sabina Cargon England England L001 Vete 2000 F002 Sabina Cargon England England L002 Råg 4000 F003 MS Star Starlines Italien Italien L001 Bananer 5000 F003 MS Star Starlines Italien Italien L002 Äpplen 4000 F004 MS Skie Starlines Italien Panama L001 Ananas F005 Wilma Bayline USA Panama L001 Koppar 5000 F005 Wilma Bayline USA Panama L002 Stål

29 Exempelövning forts... Tabellen utgör databasen för ett system som bevakar fartygsfrakter. Varje rad i tabellen anger en unik fraktorder. Fartyg har unika registreringsnummer resp. namn och ägs av endast ett rederi. Rederier kan dock äga flera fartyg. Ett rederi är registrerat i ett land och ett fartyg seglar under viss "flagg". Observera alltså att flaggan inte nödvändigtvis är samma som rederiets land. Fartygets kapacitet anges i kubikmeter och bestämmer även fartygets klass. Klass 1 = 0 till 9999 m3, Klass 2 = m3 och Klass 3 = m3. Lastnumret är unikt i ett fartyg och utgör tillsammans med fartygets registreringsnummer primärnyckeln i tabellen. 29

30 Steg 1: Finn tabellens FD Vilka funktionella beroenden finns i tabellen? Reg# Fartyg Rederi Land Flagga Kapacitet Klass Last# Last Volym F001 MS Freja Dahléns Sverige Sverige L001 Timmer 1500 F001 MS Freja Dahléns Sverige Sverige L002 Kol 2000 F001 MS Freja Dahléns Sverige Sverige L003 Stål 3000 F002 Sabina Cargon England England L001 Vete 2000 F002 Sabina Cargon England England L002 Råg 4000 F003 MS Star Starlines Italien Italien L001 Bananer 5000 F003 MS Star Starlines Italien Italien L002 Äpplen 4000 F004 MS Skie Starlines Italien Panama L001 Ananas F005 Wilma Bayline USA Panama L001 Koppar 5000 F005 Wilma Bayline USA Panama L002 Stål

31 Steg 2: Finn tabellens Normalform Vilken normalform är tabellen i just nu? Reg# Fartyg Rederi Land Flagga Kapacitet Klass Last# Last Volym F001 MS Freja Dahléns Sverige Sverige L001 Timmer 1500 F001 MS Freja Dahléns Sverige Sverige L002 Kol 2000 F001 MS Freja Dahléns Sverige Sverige L003 Stål 3000 F002 Sabina Cargon England England L001 Vete 2000 F002 Sabina Cargon England England L002 Råg 4000 F003 MS Star Starlines Italien Italien L001 Bananer 5000 F003 MS Star Starlines Italien Italien L002 Äpplen 4000 F004 MS Skie Starlines Italien Panama L001 Ananas F005 Wilma Bayline USA Panama L001 Koppar 5000 F005 Wilma Bayline USA Panama L002 Stål 4000 Partiellt Nyckelberoende Transitiva FDn Tabellen är i första normalformen dvs 1 värde per attribut 31

32 Steg 3: Normalisera till 2NF I detta fall har vi ett partiellt nyckelberoende REG# Fartyg Rederi Land Flagga Kapacitet Klass Last# Last Volym REG# Fartyg Rederi Land Flagga Kapacitet Klass 32

33 Steg 3: Normalisera till 2NF Vad har vi kvar i tabellen då? REG# Fartyg Rederi Land Flagga Kapacitet Klass Last# Last Volym REG# Last# Last Volym 33

34 Steg 3: Normalisera till 2NF Nu är vi minst i 2NF, dvs inga partiella nyckelberoenden REG# Last# Last Volym REG# Fartyg Rederi Land Flagga Kapacitet Klass 34

35 Steg 4: Normalisera till 3NF I vilken normalform är vi nu? REG# Last# Last Volym 3NF Denna är klar REG# Fartyg Rederi Land Flagga Kapacitet Klass Transitiva beroenden 2NF Måste gå vidare 35

36 Steg 4: Normalisera till 3NF Normalisera rederi à land. REG# Fartyg Rederi Land Flagga Kapacitet Klass f.k. REG# Fartyg Rederi Flagga Kapacitet Klass Rederi Land 36

37 Steg 4: Normalisera till 3NF Normalisera kapacitetà klass. REG# Fartyg Rederi Flagga Kapacitet Klass Hmm Denna är krångligare.. Är inte klass ett härlett attribut?? REG# Fartyg Rederi Flagga Kapacitet function getclass(capacity Möjligen med en tabell (class, maxcapacity) int) returns int 37

38 Svar: De normaliserade tabellerna REG# Last# Last Volym REG# Fartyg Rederi Flagga Kapacitet Rederi Land function getclass(capacity int) returns int 38

39 Så, de tre normalformerna 1NF: Ett värde per attribut och rad 2NF: Inga partiella nyckelberoenden 3NF: Inga transitiva beroenden Thats it! 39

40 Innehåll Föreläsningens mål: Att ge en överblick över hur normalisering fungerar Önskvärda egenskaper i relationsdatabaser Designregler Funktionella beroenden Normalisering Normaliseringsprocessen Normalformer Normaliseringsövning 40