IT i organisationer och databasteknik Föreläsning 5 Analytisk databasdesign Arkitektur hos ett informationssystem Presentation Användargränssnitt via en browser Applikationslogik Data Java servlets som exekverar på en server Data från en databashanterare 1
Funktionellt beroende: Pnr Namn Funktion (i vanlig mat. betydelse): 610321 11111 22222 33333 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. 610321 11111 33333 22222 Ej funktion: Maria Eva Sture Olle Här är det funktionella beroendet inte uppfyllt. Pnr:et 22222 pekar ut två värden på Namn, nämligen Maria och Eva. 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. 2
Det finns ingen bra notation för att visa funktionella beroenden INOM en klass - alltså funktionella beroenden mellan attribut! Namn: String 1..1 Vikt: Integer 1..1 Adressort: String 1..1 Postnr: Integer 1..1 1..1 ägs_av 0..* HUND Namn: String 1..1 Vikt: Integer 1..1 Favoritmat: String 1..1 Funktionellt beroende, exempel Produkt Prodnr Mtrl Färg Lagerplats 1234 trä gul hylla1 2567 stål grå hylla5 Prodnr Prodnr Prodnr Mtrl Färg 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. 3
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 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)? Pnr Namn Ort Postnr 610321 Ann, Maria Kista 12345 22222 Kalle Södertälje 77999 33333 Maria Södertälje 77888 55555 Lisa Kista 12345 Attributet Namn innehåller en mängd värden, dvs tabellen är inte i 1 NF. 4
Två möjliga lösningar: 1. Pnr Namn Ort Postnr 610321 Ann Kista 12345 610321 Maria Kista 12345 22222 Kalle Södertälje 77999 33333 Maria Södertälje 77888 55555 Lisa Kista 12345 2. Pnr Ort Postnr 610321 Kista 12345 22222 Södertälje 77999 33333 Södertälje 77888 55555 Kista 12345 1NF Pnr Namn 610321 Ann 610321 Maria 22222 Kalle 33333 Maria 55555 Lisa Observera att def. av 1NF inte talar om vare sig nycklar eller funktionella beroenden. Alla attribut ska vara atomära. Punkt slut. Lösning nr 2 bygger dock intuitivt på att vi i den ursprungliga tabellen insåg att Pnr funktionellt bestämde alla de andra attributen (i alla fall så länge Namn utgjorde en mängd värden). I den ursprungliga tabellen kunde alltså Pnr väljas till primärnyckl (PN). I så fall kan man alltid övergå till 1 NF genom att bryta ut PN plus det attribut som inte var atomärt och skapa en en ny tabell av dessa två. I den gamla tabellen blir Pnr, Ort och Postnr kvar. Nycklar... 1. Pnr Namn Ort Postnr 610321 Ann Kista 12345 610321 Maria Kista 12345 22222 Kalle Södertälje 77999 33333 Maria Södertälje 77888 55555 Lisa Kista 12345 Det (de) attribut som ska utgöra primärnyckel måste funktionellt bestämma alla övriga attribut. Vilka funktionella beroenden finns i 1? Jo, Pnr,Namn Ort, Postnr Pnr och Namn får utgöra PN 2. Pnr Ort Postnr Pnr Namn 610321 Kista 12345 610321 Ann 22222 Södertälje 77999 610321 Maria 33333 Södertälje 77888 22222 Kalle 55555 Kista 12345 33333 Maria 55555 Lisa Vilka funktionella beroenden finns i 2? I första tabellen har vi Pnr Ort, Postnr så där får Pnr bli PN. I andra tabellen finns inga funktionella beroenden utan båda attributen behövs för att identifiera en rad. 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. 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 så finns det högst ett värde Pnr Namn Ort Postnr på såväl Ort som Postnr. 610321 Ann Kista 12345 Men både Ort och Pnr 610321 Maria Kista 12345 bestämms också av enbart 22222 Kalle Södertälje 77999 Pnr. Alltså gäller 33333 Maria Södertälje 77888 Pnr Ort, Postnr. 55555 Lisa Kista 12345 Ort och Postnr är alltså inte beroende av hela nyckeln. 2NF 2NF -NAMN Bryt ut Pnr och de attribut Pnr Ort Postnr Pnr Namn som Pnr bestämmer till en 610321 Kista 12345 610321 Ann egen tabell! 22222 Södertälje 77999 610321 Maria Som synes får vi samma lösning som lösning 2. när vi 33333 Södertälje 77888 22222 Kalle 55555 Kista 12345 33333 Maria försökte gå från 0NF till 1NF. Lösning 2. var alltså 55555 Lisa redan i 2NF! 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 PRODUKT 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 7
Mera 2NF KURSTILLFÄLLE Kurs Lärare Telefon Sal IS:4 Paul 11111 Sal4 2i1033 Maria 22222 Sal4 GK:D Mats 33333 SalA ISIntro Paul 11111 SalB GK:D Paul 11111 SalA FK: DB Peter 44444 Sal3 FK:IS Paul 11111 F3 Kurs, Lärare --> Telefon, Sal Lärare --> Telefon 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 LÄRARE Lärare Telefon Paul 11111 Maria 22222 Mats 33333 Peter 4444 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 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. 2NF 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 (och 3NF!) -NAMN Pnr Ort Postnr Pnr Namn 610321 Kista 12345 610321 Ann 22222 Södertälje 77999 610321 Maria 33333 Södertälje 77888 22222 Kalle 55555 Kista 12345 33333 Maria 55555 Lisa 3NF POST Postnr Ort 12345 Kista 77999 Södertälje 77888 Södertälje 3NF Pnr Postnr 610321 12345 222222 77999 33333 77888 55555 12345 Ort är transitivt beroende av nyckeln (Pnr). Lösning: Bryt ut det transitiva beroendet till en egen tabell. 9
Tabell i 2N Mera 3NF Kurs Datum Lärare Sal Antal_sittplatser DB:1 990321 Maria F1 100 DB:3 990417 Kalle F1 100 PP:4 990321 Kalle F2 50 SYS:1 990828 Maria F1 100 SÄK:3 990817 Kurt F1 100 Kurs, Datum --> Lärare, Sal, Antal_sittplatser Sal --> Antal_sittplatser Tabell i 3NF Tabell i 3NF Kurs Datum Lärare Sal Sal Antal_sittplatser DB:1 990321 Maria F1 DB:3 990417 Kalle F1 PP:4 990321 Kalle F2 SYS:1 990828 Maria F1 SÄK:3 990817 Kurt F1 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! 10
Utrymme vs Tid vs Konsistens Titel Författare Librettot Vikt Antal Sidor Förlag Hamlet Shakespeare Once upon.the End. 35 1000 Bonniers Hamlet Shakespeare Once upon.the End. 46 1500 Pierson Hamlet Shakespeare Once upon.the End. 60 2000 Nordstedts etc. Hamlet Shakespeare Once upon.the End. 79 2500 Prentice-Hall 1984 Orwell 20 100 Bonniers etc. Titel Vikt Ant.sid. Förlag Titel Författare Librettot Hamlet Shakespeare Once upon The End. 1984 Orwell Hamlet 35 1000 Bonniers Hamlet 46 1500 Pierson Hamlet 60 2000 Nordstedts etc. 1984 20 100 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. 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) Pseudotranitiva lagen: OM A --> B OCH CB --> D SÅ AC --> D Augmentativa lagen: OM A --> B så gäller XA --> XB 12
Uppgift I (uppgift d) från seminarium 3): 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. Uppgift (b) från seminarium 3: OM vi vet att följande gäller: (a): XY --> Z (b): ZY --> W Gäller då följande: 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 13
Kvar att göra (från seminarium 3) är uppgift a) och c) a) OM XY --> Z och XZ --> W, följer då att XY --> W? C) OM XY --> Z och XZ --> Y och ZW --> X, följer då att YW --> X? 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 14
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 --> 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. 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 PROJEKTANSTÄLLNING Datum Anställd Deltagandegrad Glöm inte att ange nya främmande nycklar! 15