Informationssystem och databasteknik

Transkript

1 Informationssystem och databasteknik Föreläsning 5 Analytisk databasdesign F5! Funktionellt beroende: Pnr Namn Funktion (i vanlig mat. betydelse): Maria Eva Sture Olle För varje värde på Pnr, tex 22222, får det finnas högst ett värde på ett Namn. Däremot får två (eller flera) Pnr ha samma värde på Namn. Dessutom finns det Namn som inte pekas ut av något Pnr. Liksom det finns Pnr:er som inte pekar ut något Namn Ej funktion: Maria Eva Sture Olle Här är det funktionella beroendet inte uppfyllt. Pnr:et pekar ut två värden på Namn, nämligen Maria och Eva. 1

2 Semantiken i funktionella beroenden Primärnyckeln i en tabell bestämmer övriga attribut funktionellt (dvs givet en viss primärnyckel finns det maximalt ett värde på alla övriga attribut/kolumner) Dessutom är vissa normalformer definerade i termer av funktionella beroenden. Kom ihåg att funktionella beroenden är ett uttryck för semantiken, betydelsen, i en applikation. Det svåra i en designprocess är att klarlägga denna semantik. Det finns ingen bra notation för att visa funktionella beroenden INOM en klass - alltså funktionella beroenden mellan attribut! PERSON Namn: String 1..1 Vikt: Integer 1..1 Adressort: String 1..1 Postnr: Integer ägs_av 0..* HUND Namn: String 1..1 Vikt: Integer 1..1 Favoritmat: String

3 Funktionellt beroende, exempel Produkt Prodnr Mtrl Färg Lagerplats 1234 trä gul hylla stål grå hylla5 Prodnr Mtrl Prodnr Färg Prodnr Lagerplats När man ibland talar om Fullständigt funktionellt beroende har det att göra med primärnyckelns "minimalitet", dvs attributen skall vara beroende av hela (sammansatta) nyckeln. I en del litteratur gör man inte denna distinktion. 1NF, 2NF och 3NF 1NF A relation is in 1 NF iff the domains for all attributes are atomic 2NF A relation is in 2NF if it is in first normal form and all the nonkey attributes are fully functionally dependent on the key 3NF A relation is in 3NF if it is in second normal form and no nonkey attribute is transitively dependent on the key 3

4 1 NF En relation (tabell) är i 1NF omm varje attribut i tabellen består av atomära värden. Hur skulle en tabell se ut om den inte var i 1NF (dvs. i 0NF)? PERSON Pnr Namn Ort Postnr Ann, Maria Kista Kalle Södertälje Maria Södertälje Lisa Kista Attributet Namn innehåller en mängd värden, dvs tabellen är inte i 1 NF. 1NF PERSON Pnr Namn Ort Postnr Ann Kista Maria Kista Kalle Södertälje Maria Södertälje Lisa Kista Obs att 1NF inte definieras i termer av funktionella beroenden. Alla attribut (kolumner) skall innehålla atomära värden, punkt slut. 4

5 PRODUKT Pid Färg Pris Penna Blå, Vit, Röd 3 Skruv Metall 5 Mutter Metall 33 Stol Vit, Röd, Grön 6 Bord Vit, Blå, Röd 9 Vas Vit 44 Pall Gul 10 Mera 1NF Finns det något funktionellt beroende i den nya tabellen? Ja förmodligen Pid --> Pris Felöversatt från det konceptuella schemat? PRODUKT Pid Färg Pris Penna Blå 3 Penna Vit 3 Penna Röd 3 Skruv Metall 5 Mutter Metall 33 Stol Vit 6 Stol Röd 6 Stol Blå 6 Bord Vit 9 Bord Blå 9 Bord Röd 9 Vas Vit 44 Pall Gul 10 Partiellt funktionellt beroende A --> B kallas ett partiellt funktionellt beroende omm det existerar ett C som är en äkta delmängd av A OCH C --> B En relation, R, är i 2NF omm den är i 1NF och om det för varje attribut i R gäller ETT av följande villkor: 1. Attributet ingår i en kandidatnyckel (ev. den som väljs som PN) 2. Attributet är INTE partiellt beroende av en kandidatnyckel (ev. PN). Mao, alla attribut ska vara fullständigt funktionellt beroende av hela primärnyckeln, inte bara en del av denna. 5

6 2NF En tabell är i 2NF omm den är i 1NF och alla attribut är funktionellt beroende av hela primärnyckeln. Dvs Pnr, Namn Ort, Postnr Vi fortsätter exemplet från 1NF: gäller. Dvs. för varje par av värden på Pnr och Namn PERSON så finns det högst ett värde Pnr Namn Ort Postnr på såväl Ort som Postnr Ann Kista Men både Ort och Pnr Maria Kista bestämms också av enbart Kalle Södertälje Pnr. Alltså gäller Maria Södertälje Pnr Ort, Postnr Lisa Kista Ort och Postnr är alltså inte beroende av hela 2NF 2NF nyckeln. PERSON UPPGIFTER PERSON Bryt ut Pnr och de attribut Pnr Ort Postnr Pnr Namn som Pnr bestämmer till en Kista egen tabell! Ann Södertälje Maria Södertälje Kalle Kista Maria Lisa Ny främmande nyckel: PERSON.Pnr = PERSONUPPGIFTER.Pnr PRODUKT Pid Färg Pris Penna Blå 3 Penna Vit 3 Penna Röd 3 Skruv Metall 5 Mutter Metall 33 Stol Vit 6 Stol Röd 6 Stol Blå 6 Bord Vit 9 Bord Blå 9 Bord Röd 9 Vas Vit 44 Pall Gul 10 Mera 2NF Pid --> Pris PRODUKTUPPG. Pid Pris Penna 3 Skruv 5 Mutter 33 Stol 6 Bord 9 Vas 44 Pall 10 PRODUKT Pid Färg Penna Blå Penna Vit Penna Röd Skruv Metall Mutter Metall Stol Vit Stol Röd Stol Blå Bord Vit Bord Blå Bord Röd Vas Vit Pall Gul 6

7 Mera 2NF KURSTILLFÄLLE Kurs Lärare Telefon Sal IS:4 Paul Sal4 2i1033 Maria Sal4 GK:D Mats SalA ISIntro Paul SalB GK:D Paul SalA FK:DB Peter Sal3 FK:IS Paul F3 FK:IS Maria F5 KURSTILLFÄLLE Kurs Lärare Sal IS:4 Paul Sal4 2i1033 Maria Sal4 GK:D Mats SalA ISIntro Paul SalB GK:D Paul SalA FK: DB Peter Sal3 FK:IS Paul F3 FK:IS Maria F5 LÄRARE Lärare Telefon Paul Maria Mats Peter 4444 Kurs, Lärare --> Telefon, Sal Lärare --> Telefon Identifierare - Primärnyckel? ENTITET/ KLASS a: Datatype 1..1 UNIK b: Datatype 1..1 c: Datatype 1..1 c: Datatype 1..1 TABELL blev ju en tabell: a b c d Observera att om a har avbildningsregeln 1..1 UNIK och övriga attribut (dvs. b, c, d) 1..1 så finns det ett funktionellt beroende: a b, c, d dvs a kan väljas till PN. TABELL a b c d 7

8 Transitivt beroende Ett funktionellt beroende X --> Y för en relation R utgör ett transitivt beroende om följande båda saker gäller: 1. Det existerar en mängd attribut Z, sådan att Z varken utgör en kandidatnyckel för R eller ingår i en kandidatnyckel för R 2. X --> Z OCH Z --> Y Något svagare definition (baserad på primärnyckel istället för kandidatnyckel): Z får varken utgöra primärnyckel eller ingå i primärnyckeln. 3NF En tabell är i 3NF omm den är i 2NF och det inte existerar några transitiva beroenden mellan något icke-nyckel attribut och nyckeln. 2NF 2NF (och 3NF!) PERSON PERSON-NAMN Pnr Ort Postnr Pnr Namn Kista Ann Södertälje Maria Södertälje Kalle Kista Maria Lisa 3NF POST Postnr Ort Kista Södertälje Södertälje 3NF PERSON Pnr Postnr Ort är transitivt beroende av nyckeln (Pnr). Lösning: Bryt ut det transitiva beroendet till en egen tabell. 8

9 Tabell i 2N Kurs Datum Lärare Sal Antal_sittplatser DB: Maria F1 100 DB: Kalle F1 100 PP: Kalle F2 50 SYS: Maria F1 100 SÄK:3 SÄK: Kurt Olle F1 F Tabell i 3NF Mera 3NF Kurs, Datum --> Lärare, Sal, Antal_sittplatser Sal --> Antal_sittplatser Tabell i 3NF Kurs Datum Lärare Sal Sal Antal_sittplatser DB: Maria F1 DB: Kalle F1 PP: Kalle F2 SYS: Maria F1 SÄK: Kurt F1 SÄK: Olle F2 F1 100 F2 50 Problem vid ofullständig normalisering Ofullständig normalisering leder till sk uppdateringsanomalier: INSÄTTNING: Man kan inte lägga in uppgifter om en sals antal sittplatser om salen ifråga inte används av en kurs BORTTAG: När den enda kursen som en sal används i tas bort så försvinner även alla uppgifter om salen UPPDATERING: Om man bygger om en sal och följdaktligen kanske vill ändra angivelsen av antal platser (om nu salen blivit mindre/större) så måste man ändra på ALLA rader där just denna sal förekommer - risk för inkonsistens! 9

10 Utrymme vs Tid vs Konsistens Titel Författare Librettot Vikt Antal Sidor Förlag Hamlet Shakespeare Once upon.the End Bonniers Hamlet Shakespeare Once upon.the End Pierson Hamlet Shakespeare Once upon.the End Nordstedts etc. Hamlet Shakespeare Once upon.the End Prentice-Hall 1984 Orwell Bonniers etc. Titel Vikt Ant.sid. Förlag Titel Författare Librettot Hamlet Shakespeare Once upon The End Orwell Hamlet Bonniers Hamlet Pierson Hamlet Nordstedts etc Bonniers etc. Semantiken i funktionella beroenden Primärnyckeln i en tabell bestämmer övriga attribut funktionellt (dvs givet en viss primärnyckel finns det maximalt ett värde på alla övriga attribut/kolumner) Dessutom är vissa normalformer definerade i termer av funktionella beroenden. Kom ihåg att funktionella beroenden är ett uttryck för semantiken, betydelsen, i en applikation. Det svåra i en designprocess är att klarlägga denna semantik. 10

11 Vilka funktionella beroenden kan man identifiera genom att inspektera instanserna? Anställd Projekt Titel Olle Proj1 Fil. lic Olle Proj2 Civ. ing Olle Proj1 Civ. ing Lisa Proj2 Civ. ing etc. etc. etc. Inga alls. Inget av det tre attributen, Antälld, Projekt och Titel räcker ensamt till för att bestämma övriga attribut funktionellt. Inte heller några två-kombinationer av attribut räcker till: Anställd+Projekt har flera värden på Titel (tex har Olle+Proj1 två olika titlar: Fil. lic eller Civ.ing). Anställd+Titel har två olika värden på Projekt (dvs Olle är betitlad Civ.ing i såväl Proj1 som Proj2), slutligen har Projekt och Titel minst två värden på Anställd (Civ. ing i Proj1 innehas av både Olle och Lisa). Alltså måste vi använda ALLA attributen för att identifiera en rad. Tabellen bli sk. all-key. Armstrongs axiom Låt A, B, C, X och D utgöra mängder av attribut (ibland med bara ett element) i en relation R Reflexiva lagen: OM B är en delmängd av A SÅ gäller A --> B Transitiva lagen: OM A --> B och B --> C SÅ A --> C Additiva lagen: OM A -->B och A --> C SÅ A --> BC Dekomponeringslagen: OM A --> BC SÅ (A -->B OCH A --> C) Augmentativa lagen: OM A --> B så gäller XA --> XB 11

12 Uppgift I Om vi vet att (a) X--> Y (b) Z --> WY (c) YW --> ZX gäller Gäller det då även att (d) Z --> X? SANT. Bevis: Vi använder först dekomponeringslagen på (b): (e) Z --> W OCH (f) Z --> Y Sen använder vi (f) och (e) och additiva lagen och får: (g) Z --> YW Sen tar vi transitiva lagen på (g) och (c) och får: (h) Z --> ZX Slutligen används dekomponeringslagen en gång till på (h) och vi får Z --> X, vilket skulle bevisas. OM vi vet att följande gäller: (a): XY --> Z (b): ZY --> W Gäller då följande: (c) XW --> Z? FALSKT. Visas med ett motbevis: X Y Z W Både (a) och ( b) är uppfyllda men INTE (c) a b c b a m q b 12

13 PROJEKTANSTÄLLNING Projekt Datum Anställd Deltagandegrad Budget Projekt, Datum --> Anställd, Deltagandegrad, Budget Datum, Anställd --> Deltagandegrad Projekt --> Budget Vilken normalform? Ja, vi ser ju att attributet Budget är beroende av bara en del av primärnyckeln så vi är INTE i 2NF. Projekt Datum Anställd Deltagandegrad Projekt Budget PROJEKTANSTÄLLNING Projekt Datum Anställd Deltagandegrad Projekt, Datum --> Anställd, Deltagandegrad, Budget Datum, Anställd --> Deltagandegrad Projekt --> Budget Vilken normalform? Tillämpa dekomponeringslagen: Vi får Projekt, Datum --> Anställd Reflexiva lagen ger sen att Projekt, Datum --> Projekt, Datum Dekomponeringslagen ger Projekt, Datum Datum Additiva lagen ger sen att Projekt, Datum --> Datum, Anställd. Vi har redan att Datum, Anställd --> Deltagandegrad. Dvs, vi har ett transitivt beroende mellan primärnyckeln och Deltagandegrad. Således är PROJEKTANSTÄLLNING INTE i 3NF. 13

14 Vi överför den till 3NF genom att bryta ut determinanten, (Datum, Anställd) och det den bestämmer till en ny relation. Kvar i den gamla relationen blir determinanten plus övriga attribut: PROJEKTANSTÄLLNING Projekt Datum Anställd Projekt Budget ANSTÄLLNINGSDELTAGANDE Datum Anställd Deltagandegrad Glöm inte att ange nya främmande nycklar! 14