IT i organisationer och databasteknik

Transkript

1 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

2 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. 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

3 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 ä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 hylla 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

4 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 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. 4

5 Två möjliga lösningar: 1. Pnr Namn Ort Postnr Ann Kista Maria Kista Kalle Södertälje Maria Södertälje Lisa Kista Pnr Ort Postnr Kista Södertälje Södertälje Kista NF Pnr Namn Ann Maria Kalle Maria 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 Pnr Namn Ort Postnr Ann Kista Maria Kista Kalle Södertälje Maria Södertälje Lisa Kista 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 Kista Ann Södertälje Maria Södertälje Kalle Kista Maria 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

6 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

7 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 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 nyckeln. 2NF 2NF -NAMN Bryt ut Pnr och de attribut Pnr Ort Postnr Pnr Namn som Pnr bestämmer till en Kista Ann egen tabell! Södertälje Maria Som synes får vi samma lösning som lösning 2. när vi Södertälje Kalle Kista Maria försökte gå från 0NF till 1NF. Lösning 2. var alltså 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

8 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 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 Maria Mats 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

9 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 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 Pnr Postnr Ort är transitivt beroende av nyckeln (Pnr). Lösning: Bryt ut det transitiva beroendet till en egen tabell. 9

10 Tabell i 2N Mera 3NF 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: 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: Maria F1 DB: Kalle F1 PP: Kalle F2 SYS: Maria F1 SÄK: 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

11 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. 11

12 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

13 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

14 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

15 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