Informationssystem och databasteknik

Relevanta dokument
IT i organisationer och databasteknik

Analytisk relationsdatabasdesign

Föreläsning 3 Transformation från konceptuell datamodell till relationsschema ( Syntetisk databasdesign ) Vad är ett databashanteringssystem?

Informationssystem och Databasteknik

Föreläsning 4 Transformation från konceptuell datamodell till relationsschema ( Syntetisk databasdesign ) Normalisering (Analytisk databasdesign)

Pga att (Nummer och Typ) tillsammans bestämmer övriga attribut funktionellt väljer vi (Nummer, Typ) till primärnyckel:

Karlstads Universitet, Datavetenskap 1

Logisk databasdesign

2NF Hästnamn, KursId, StartDatum, SlutDatum KursId NY!, där RIDKURS.KursId = KURS.KursId 3NF Hästnamn, Art, NY! NY! NY! NY!

Idag. Databaskvalitet(??) Databaskvalitet... Databaskvalitet...

Databaser och databasdesign. Den relationella modellen, normalisering och modellering (2)

Tentamen plus lösningsförslag

ÖVNING 10 2NF Hästnamn, KursId, StartDatum, SlutDatum KursId NY! 3NF Hästnamn, Art, NY! NY! NY! NY! KursId, StartDatum, SlutDatum KursId NY!

Databaser Design och programmering

Normalisering. Christer Stuxberg Institutionen för Informatik och Media

Funktionella beroenden - teori

Universitetet: ER-diagram

Exempel-Tentamen III

Normalisering. Varför? För att åstadkomma en så bra struktur i databasen som möjligt med minimalt med dubbellagrad info.

ÖVNING 10 2NF Hästnamn, KursId, StartDatum, SlutDatum KursId NY! 3NF Hästnamn, Art, NY! NY! NY! NY! KursId, StartDatum, SlutDatum KursId NY!

Föreläsning 6: Normalisering & funktionella beroenden

Konceptuella datamodeller

Programdesign, databasdesign. Databaser - Design och programmering. Funktioner. Relationsmodellen. Relation = generaliserad funktion.

Tentamen Databasmetodik DB:DSK/FK/DVK/ATD/SP/EIT mfl. äldre kurstillfällen Lördag 8 juni kl

Databaser - Design och programmering. Relationsmodellen. Relationer - som tabeller. Relationer som tabeller. Alternativa notationer: Relationsschema

Relationell databasdesign

Lösningsförslag till Tentamen,

Databasdesign. E-R-modellen

Karlstads Universitet, Datavetenskap 1

NORMALISERING. Mahmud Al Hakim

Tentamen 2I1033, IT i Organisationer och Databasteknik lördag 17/4 2004, kl LÖSNINGSFÖRSLAG

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

Databaser och Datamodellering Foreläsning IV

Kvalitetstänkande. Utgångsläge Samtliga ER-diagram har överförts till scheman

Tentamen för DD1370 Databasteknik och informationssystem

GIS, databasteknik och kartografi. Kursmaterial för databasdelen

Karlstads Universitet, Datavetenskap 1

Tentamen ISGB01 (delkurs i ISGB24) Databasdesign 7,5 Poäng

Relationsmodellen och syntetisk databasdesign

Tentamen för DD1370 Databasteknik och informationssystem

Informationssystem och Databasteknik

Relationsdatabasdesign

Tentamen Databasmetodik DB:DSK/FK/DVK/ATD/SP/EIT mfl. äldre kurstillfällen 8 augusti 2013 kl. 9-13

Tentamen EIT:DB Databastmetodik 11/ kl Lösningsförslag

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

Tentamen ISGB01, ISGB24. Databasdesign 7,5 Poäng

Exempel tentamen. Skriv bara på en sida av pappret Skriv namn på varje papper Skriv läsligt, annars rättas inte tentamen Alla hjälpmedel är tillåtna

Inst. för Data- och Systemvetenskap SU Maria Bergholtz. Tentamen. 21/ kl Inga hjälpmedel är tillåtna (annat än ordbok).

Tentamen. Databasmetodik Lördag 27 september 2014 kl

Skriftlig tentamen i kurserna TDDD12 och TDDB48 Databasteknik kl

Vad är en databas? Databaser. Relationsdatabas. Vad är en databashanterare? Vad du ska lära dig: Ordlista

Frågor att lösa med SQL mot databasen kursdb_sql Sida 1 av 5

Concepts learned this far. ER till relationer. ER till relationer. ER till relationer. TDDD12 Database Technology

Tentamen för DD1370 Databasteknik och informationssystem

Idag. Hur vet vi att vår databas är tillräckligt bra?

Webbprogrammering, grundkurs 725G54

TENTAMEN TDDB77 Databaser och Bioinformatik 17 mars 2005, kl 8-12

Tentamen för DD1370 Databasteknik och informationssystem

Lite om databasdesign och modellering

Lösningsförslag till fiktiv tentamen för DD1370 Databasteknik och informationssystem

Tentamen i Databasteknik

Grunderna för relationsmodellen!

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

Modul DB1-1 Databasmodellering

Webprogrammering och databaser. Konceptuell datamodellering med ER-modellen

Lösningsförslag Tentamen, 25 april 03

Webprogrammering och databaser. Konceptuell datamodellering med ER-modellen

Modul DB1-2 Datamodellering

Föreläsning 3 Dagens föreläsning går igenom

Relationsmodellen. Relations modellen är idag den mest änvända datamodellen för kommersiella

Uppdelning. Relationell databasdesign, FB Teori Låt R vara ett relationsschema. R 1, R 2,..., R n är en uppdelning av

Konceptuell modellering

Databaser design och programmering. Design processen ER- modellering

Tentamen för DD1370 Databasteknik och informationssystem

Tentamen DATABASTEKNIK - 1DL116

Tentamen i. Databasteknik

Tentamen. i Databasteknik. lördagen den 13 mars Tillåtna hjälpmedel: Allt upptänkligt material

IT i organisationer och databasteknik

Databaser design och programmering. Fö 2: Design processen, ER-modellering

Lösningsförslag till Exempel tentamen

TENTAMEN TDDB77 Databaser och Bioinformatik 12 juni 2007, kl 14-18

Vad är en databas? Databaser. Relationsdatabas. Vad är en databashanterare? Vad du ska lära dig: Ordlista

MA2047 Algebra och diskret matematik

LMA033/LMA515. Fredrik Lindgren. 4 september 2013

DD1350 Logik för dataloger. Fö 7 Predikatlogikens semantik

25/11/14. Databasteknik och informationssystem DD1370. Påminnelse inför Lab 1 redovisningen. Repetition: ER modellering (gammalt + nytt)

TENTAMEN. TDDD12 Databasteknik TDDD46 Databasteknik. 16 augusti 2010, kl 14-18

Ett arbetsexempel Faktureringsrutin

Tentamen NDA01G Öppen för alla. Tentamenskod: Inga hjälpmedel är tillåtna

Lösningsförslag till. tentamen för 1E1601

Lösningar till tentamen i EDAF75

02/12/14. Databasteknik och informationssystem DD1370. Behövs Föreläsning 8? Dagens föreläsning. Om Lab 1. De 11 Stegen (Kokbok)

Tentamenskod: Tentamensdatum: Tid: 14:00-19:00. Inga hjälpmedel är tillåtna

! Webprogrammering. ! Databasteori och praktik. ! Fö, le, la + projekt. ! Examination (tenta, dugga + labb, ! Studera användarna och deras problem

Design och underhåll av databaser

TENTAMEN För kursen. Databasteknik. Ansvarig för tentamen: Anna Palmquist. Förfrågningar: Anslås inom 3 veckor

2. Redundans 3. Normalformer

TDDI60 Tekniska databaser

Transkript:

Informationssystem och databasteknik Föreläsning 5 Analytisk databasdesign F5! 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. 1

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 1..1 1..1 ägs_av 0..* HUND Namn: String 1..1 Vikt: Integer 1..1 Favoritmat: String 1..1 2

Funktionellt beroende, exempel Produkt Prodnr Mtrl Färg Lagerplats 1234 trä gul hylla1 2567 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

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 650321 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. 1NF PERSON Pnr Namn Ort Postnr 650321 Ann Kista 12345 650321 Maria Kista 12345 22222 Kalle Södertälje 77999 33333 Maria Södertälje 77888 55555 Lisa Kista 12345 Obs att 1NF inte definieras i termer av funktionella beroenden. Alla attribut (kolumner) skall innehålla atomära värden, punkt slut. 4

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

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. 650321 Ann Kista 12345 Men både Ort och Pnr 650321 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 2NF 2NF nyckeln. PERSON UPPGIFTER PERSON Bryt ut Pnr och de attribut Pnr Ort Postnr Pnr Namn som Pnr bestämmer till en 650321 Kista 12345 egen tabell! 650321 Ann 22222 Södertälje 77999 650321 Maria 33333 Södertälje 77888 22222 Kalle 55555 Kista 12345 33333 Maria 55555 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

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 FK:IS Maria 22222 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 11111 Maria 22222 Mats 33333 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

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 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 PERSON 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. 8

Tabell i 2N 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 SÄK:3 990817 050821 Kurt Olle F1 F2 100 50 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: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 SÄK:3 050821 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

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

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

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

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

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