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

Transkript

1 Föreläsning 4 Transformation från konceptuell datamodell till relationsschema ( Syntetisk databasdesign ) Normalisering (Analytisk databasdesign) 1 Vad är en databas? Logiskt sammanhängande mängd av data, med en därtill hörande betydelse, strukturerad och försedd med data avsedda för ett visst ändamål, en viss användargrupp i åtanke och återspeglande någon aspekt av världen. En gemensam samling av logiskt relaterade data för att möta ett företags informationsbehov. 2

2 Vad är ett databashanteringssystem? En mängd program som tillåter användaren att skapa och underhålla databaser 3 DATABASSYSTEM Användare/Programmerare Applikationsprogram/Frågor DBMS Program för att hantera frågor/program Program för att hantera lagrade data Lagrad databasdefinition (metadata) Lagrad databas 4

3 Relationsdatabas En relationsdatabas är en databas som uppfattas av användaren som en samling tabeller - oberoende av hur datamängden fysiskt är lagrad. 5 Relationsschema - tabellbeskrivning Projekt PRNR START KLART PLATS BUDGET Relationsnamn Attribut Allmän form: R(A 1, A 2,..., A n ) Domän t.ex. Domänen för attributen BUDGET är Integer större än noll Grad - antal attribut 6

4 Project Relation PRNR START KLART PLATS BUDGET Prnr Goteborg 90 Prnr2 Prnr Falun Stockholm Tuppel ( sveng elska ) (Rad) Prnr Lund 550 Cell Kardinalitet - antalet rader (tuppler) 7 Egenskaper hos relationer Atomära värden i varje cell Värdena i varje kolumn är av samma typ Varje rad (tuple) är unik Ordningen mellan attributen är inte alltid oväsentlig Ordningen mellan raderna är oväsentlig Namnet för varje attribut är unikt för en relation 8

5 Grafisk notation för konceptuella scheman - avbildningsreglerna avgör vad som kan utgöra identifierare! APA Namn : Sträng * äter 1..1 BANAN TOTALITET Textsträng 1..1 Namn 0..1 APA ENVÄRDHET alternativ, starkare, notation: UNICITET (båda max-värdena = 1, alternativt ENVÄRT+INJEKTIVT) TOTALITET 0..* äter 1..1 BANAN 9 Från ett konceptuellt schema till en relationsdatabas Namn: String 1..1 UNIK Ålder: String 1..1 äger 0..* 0..* BIL Regno: String 1..1 UNIK Märke: String 1..1 Ett sätt: ((Namn), Ålder) ÄGER((Namn, Regnr)) BIL((Regnr), Märke) Ett annat sätt: Namn ÄGANDE Namn BIL Regnr Ålder Regnr Märke 10

6 Enkelt objekt - envärda attribut Personnr: String 1..1 UNIK Namn: String 1..1 Person Personnr Namn Blad Per Löw Eva Gren Ove Identifierande attribut är skuggat. 11 Enkelt objekt - flervärda attribut Personnr: String 1..1 UNIK Namn: String 1..1 Titel: String 0..* Person Personnr Namn Blad Per Löw Eva Gren Ove Titel Personnr Titel Civ.ing Fil.dr Civ.ing 12

7 Nycklar? Person Titel Personnr Namn Personnr Titel Blad Per Civ.ing Löw Eva Fil.dr Gren Ove Tekn.dr En (kandidat-) nyckel är ett antal attribut (t ex ett) som unikt identifierar en rad. En nyckel är en minimal supernyckel (se nedan). Den/de attribut som väljs som identifierare kallas primärnyckel. Eventuella övriga nycklar blir alternativnycklar. En främmande nyckel är ett/flera attribut i en tabell som svarar mot primärnyckeln i en annan tabell. Personnr i tabellen TITLE ingår i primärnyckeln för tabellen TITEL men utgör även främmande nyckel mot tabellen. Främmande nyckel-attributet är det som relaterar olika tabeller till varandra. Alla värden som förekommer i främmande-nyckel kolumnerna måste ha sin motsvarighet som primärnyckel i en annan tablell, eller också måste de vara NULL. De två sista villkoren brukar kallas referential integrity. En super-nyckel, slutligen, är en mängd attribut med egenskapen att två tupler inte kan ha samma värde för alla attributen. 13 Entity integrity Ingen del av primärnyckeln får vara NULL (primärnyckeln identifierar ju en rad och måste alltid finnas). Referential integrity Alla värden för kolumner som utgör främmande nyckel kolumner mot en annan tabell måste svara mot existerande primärnyckel-värden för denna andra tabell. Eller också måste värdena i främmande nyckelkolumnerna vara NULL. Detta betyder bland annat att främmande nyckel kolumnerna i en tabell måste ha samma domäner som primärnyckel kolumnerna i den tabell som de refererar till. 14

8 Identifierare Objekt kan identifieras med hjälp av attribut och/eller samband mellan objekt. Avbildningsreglerna för ett attribut som ensamt ska tjäna som identifierare måste alltid vara UNIKT och TOTALT (se nedan). Detta betyder att alla sådana attribut kan väljas ensamma som primärnyckel. Motsatsen till totala attribut kallas f. ö. PARTIELL(a) attribut (eller partiella relationer). En identifierare för ett objekt kan sättas samma av ett eller flera attribut som hör till objektet eller ett attribut plus ett eller flera samband mellan objektet och andra objekt. A attributename: Datatype 1..1 UNIK 15 Sammansatta identifierare KURSDELTAGANDE Personnr: String 1..1 Kurskod: String 1..1 Nivå: String 1..1 Entitetstypen KURSDELTAGANDE modellerar att en student går en viss kurs. Man kan läsa kurser på flera olika nivåer där C-nivån har en svårare tenta än A-nivån. Här finns inget attribut som ensamt är både unikt och totalt (en viss student kan läsa flera kurser än en så kurskod är inte unikt, en kurs har flera deltagare så personnummer är inte unikt. Detsamma gäller nivå där flera studenter kan läsa t ex B-nivån). Kombinerar man ihop attributen personnummer och kurskod får man dock en unik identifierare (detta under förutsättning att man inte kan läsa samma kurs på flera olika nivåer. Om detta gäller måste även nivå inkluderas i identifieraren). KURSDELTAGANDE Personnr Kurskod Nivå 16

9 Sammansatta identifierare KURS Kurskod: String 1..1 UNIK Namn: String 1..1 Vad identifierar KURS? Jo, Kurskod! (Unikt och totalt) hör_till * KURSTILLFÄLLE Kursansvarig: String 1..1 Starttid: String 1..1 Sluttid: String 1..1 Inget av attributen hos klassen KURSTILLFÄLLE är unikt och totalt. Inte ens om man kombinerar ihop alla attributen är det säkert att detta blir unikt (en lärare kan vara ansvarig för olika kurser som går under samma tidsperiod). Om vi däremot väljer att identifiera ett kurstillfälle med attributen starttid, sluttid och kurskod (dvs KURSTILLFÄLLES relation mot KURS) har vi en unik identifierare. 17 KURS Kurskod: String 1..1 UNIK Namn: String 1..1 hör_till * KURSTILLFÄLLE Kursansvarig: String 1..1 Starttid: String 1..1 Sluttid: String 1..1 KURS Kurskod Namn Tabellen KURSTILLFÄLLE har en primärnyckel som består av kolumnerna Kurskod, Starttid och Sluttid. Kolumnen Kurskod ingår i PN men utgör även FN mot tabellen KURS. KURSTILLFÄLLE Kurskod Starttid Sluttid Kursansvarig 18

10 Surrogatnycklar Vanliga användarspecificerade nycklar kan vara bristfällig ett par avseenden: 1. De kan förändras Exempelvis händer det att attribut som t ex avdelningsnummer/namn förändras när ett företag organiseras om. 2. Olika användarnamn kan användas för att identifiera samma entitet. T ex KUNDER KUND CUSTOMER jfr homonymer. Surrogat är systemgenererade entitetsidentifierare vars unikhet är garanterad för alltid och som alltså ej kan förändras. 19 Surrogatnycklar ANVÄNDARE BEHÖVER INTE VARA MEDVETNA OM ATT SURROGAT-NYCKLAR ANVÄNDS, EFTERSOM DESSA BARA ANVÄNDS INTERNT. FORTFARANDE HAR MAN "I LEVANDE LIVET" BEHOV AV ATT KUNNA IDENTIFIERA OBJEKT, OCH BEHOVET AV "ENTITY INTEGRITY" GÖR ATT (ANVÄNDARNAS) PRIMÄR-NYCKEL BEHÖVS. INTERNT KOMMER DOCK SURROGATET ATT ANVÄNDAS SOM ENVÄRDA UNIKA PRIMÄR-NYCKLAR OCH ÄVEN I REFERENSER SOM FRÄMMANDE NYCKLAR. 20

11 Från konceptuellt schema till databas, fortsättning Partiella relationer (och för all del attribut) ger upphov till problem med NULL-värden. Har man inte modellerat bort risken för NULL-värden bör man ta hand om det vid transformationen från konceptuell modell till relationsschema. Partiella relationer och attribut undviks t ex om man använder isahierarkier. 21 NULL Vad betyder egentligen NULL? Värde saknas? Värde finns men är ej känt? (just nu...) Värde är ej tillämpligt? (jfr arvs-hierarkier ) 22

12 ANSTÄLLDA NULL Null-värden kan ge problem vid join. AVDELNING Pnr Anst.nr Adress Avd.nr Avdelning Avd.nr A Byv. 3 3 Forskning B Solsv. 6 5 Försäljn AA Byv. 5 3 Admin B Byv X Solv. 7 NULL Y Byv. 11 NULL En join mellan anställda över Avd.nr kommer att resultera i att de två sista anställda inte kommer med. Beroende på omständigheterna kan detta vara vad som avsågs eller felaktigt. Pnr Anst.nr Adress Avd.nr Avdelning Avd.nr A Byv. 3 3 Forskning B Solsv. 6 5 Försäljn AA Byv. 5 3 Forskning B Byv.7 1 Admin 1 23 Namn: String 1..1 UNIK Ålder: String äger 0..1 BIL Regno: String 1..1 UNIK Märke: String 1..1 Person Personnr Namn Blad Per Löw Eva Gren Ove Bil Regnr Ägs-av Typ AIB Volvo BPL Fiat FJK 359 NULL Saab Det sammanbindande attributet läggs så att det får så få nullvärden som möjligt! Här antas att det finns fler personer utan bilar än tvärtom. 24

13 Partiella relationer alternativ lösning: Namn: String 1..1 UNIK Ålder: String äger 0..1 BIL Regno: String 1..1 UNIK Märke: String BIL- 0 1 ÄGANDE BIL Person Personnr Namn Blad Per Löw Eva Gren Ove Bil / Person Ägs-av Regnr AIB BLP 845 Bil Regnr Typ AIB 436 Volvo BPL 845 Fiat FJK 359 Saab 25 Samband där avbildningarna har M ( många, * ) på en av sidorna Regel: Främmande nyckeln ska placeras i den.tabell som sitter på * ( många ) - sidan! 26

14 Namn: String 1..1 UNIK Ålder: String äger 0..* BIL Regno: String 1..1 UNIK Märke: String 1..1 Person Personnr Namn Blad Per Löw Eva Gren Ove Bil Regnr Ägs-av Typ AIB Volvo BPL Fiat FJK 359 NULL Saab 27 M:M ( många till många, * : * ) måste lösas M:M- relationer måste alltid lösas med ett relationsobjekt (jämför med reifiering). Nullvärden undviks dessutom. Vid den första konceptuella modellen fick ju M:M samband finnas (såvida inte sambandet hade egna attribut). Vid övergång till ett relationsschema bildar man en en ny tabell som innehåller identiferarna från respektive entitet som sammankopplades via M:Msambandet. 28

15 Namn: String 1..1 UNIK Ålder: String * äger 0..* BIL Regno: String 1..1 UNIK Märke: String BIL- ÄGANDE BIL Person Personnr Namn Blad Per Löw Eva Gren Ove Bil / Person Ägs-av Regnr AIB AIB BPL JTL 739 Bil Regnr Typ AIB 436 Volvo BPL 845 Fiat FJK 359 Saab JTL 739 BMW 29 Arvssamband Personnr :String 1..1 UNIK Namn: String 1..1 ANSTÄLLD KONSULT Avdelning: String 1..1 Projekt: String 1..1 Anställd Personnr Avd Dam Herr Person Personnr Namn Blad Per Löw Eva Gren Ove Konsult Personnr Projekt PR 30

16 Översättning av entitet med sammansatta icke-lexikala identifierare Personnr: String 1..1 UNIK Namn: String 1..1 RUM 0..* 1..1 Rumsnr: String 0..* 1..1 bor_på 1..1 ingår_i HOTEL Hnamn: String 1..1 UNIK Typ: String 1..1 Rumsnummer räcker inte till för att identifiera (= vara möjlig att välja som primärnyckel) tabellen RUM! PersonnrNamn Rumsnr HNamn Anna 2A Astoria Lisa 3B Ritz Eva 4S Astoria Pelle 2A Plaza RUM Rumsnr 2A 3B 4S 2A HNamn Astoria Ritz Astoria Plaza HOTEL HNamn Typ Astoria 5* Ritz 3* Plaza 5* 31 Informationsförlust? Övning: Översätt följande två scheman til två olika relationsdatabasstrukturer: Personnr: String 1..1 UNIK Personnr: String 1..1 UNIK 1..1 ISA ANSTÄLLD Anstnr: String 1..1 UNIK gift_med 1..1 ANSTÄLLD Anstnr: String 1..1 UNIK 32

17 Från ett konceptuellt schema till en relationsdatabas Namn: String 1..1 UNIK Ålder: Integer 0..* äger 0..* BIL Regno: String 1..1 UNIK Märke: String 1..1 Ett sätt: ((Namn), Ålder) ÄGER((Namn, Regnr)) BIL((Regnr), Märke) Ett annat sätt: Namn ÄGANDE Namn BIL Regnr Ålder Regnr Märke Vart tog alla regler vägen? 33 Vart tog alla regler vägen fortsättning? - Domänbeskrivningar - Referensregler (Främmande Nyckel-specifikationer) - Integritetsregler (triggers) Kontroll av data skall ske så tidigt (så nära källan) som möjligt! Systemet skall inte kontrollera att data inte är fel, utan undanröja möjligheterna till att det blir fel 34

18 Domändefinition Domänkarakteristika datatyp längd format Exempel numeric, integer, char* 5 siffror, 30 tkn ååmmdd, nnnn-nnnnnnn * siffra, heltal, tecken 35 Domäner för nycklar PK AK FK ej null, unika unika, men får vara null, eller delvis null måste vara samma (domänspecifikt) som PK i föräldratabell 36

19 Inför SQL (DDL-delen): EMPLOYEE Eid: String 1..1 UNIK 1..* 1..1 works_at BUSINESS Bid: String 1..1 UNIK Detta blir två tabeller: EMPLOYEE((EID), BID) och BUSINESS(BID) Hur defineras tabellen EMPLOYEE ovan? SQL har en DDL-del (lite mer okänd än DML-delen). DDL betyder Data Definition Language. DML betyder Data Manipulation Language. Med DDL kan vi definiera tabeller, regler etc. Med DML kan vi sen ställa frågor mot de tabeller vi skapat. 37 SQL: DDL-exempel CREATE TABLE EMPLOYEE (EID VARCHAR(11) NOT NULL UNIQUE, BID CHAR(7) NOT NULL, PRIMARY KEY(EID), FOREIGN KEY(BID) REFERENCES BUSINESS ON DELETE CASCADE ON UPDATE CASCADE) Med hjälp av DDL-satsen ovan har vi realiserat ett antal regler. Entity integrity regler: Ingen del av primärnyckeln får vara NULL och PN måste vara unik för varje förekomst av entiteten. Alltså måste det (de) attribut som väljs till PN deklareras som NOT NULL och UNIQUE *. Vidare bör man ta ställning till vad som ska hända med främmande nyckel-attributet vid DELETE respektive UPDATE av en föräldra -entitet. DELETE och UPDATE-regler talar om just vilka effekter ett borttag eller en uppdatering av en föräldraentitet får på barn -entiteten. Här har vi valt att låta såväl DELETE som UPDATE vara CASCADES. Dvs ett borttag av en föräldraentiet innebär att även barnentiteten tas bort. En uppdatering av en föräldraentitet innebär att även främmande nyckelfältet i barnentiteten uppdateras. Vilka andra typer av effekter på DELETE/ INSERT kunde man valt? *) ibland innebär själva deklarationen av ett attribut som PN just att NOT NULL resp. UNIQUE upprätthålls. Då behöver man inte ange detta specifikt. 38

20 Mera främmande nycklar... CREATE TABLE EMPLOYEE (EID VARCHAR(11) NOT NULL UNIQUE, BID CHAR(7) NOT NULL, PRIMARY KEY(EID), FOREIGN KEY(BID) REFERENCES BUSINESS ON DELETE CASCADE ON UPDATE CASCADE) Här talar man om att BID i tabellen EMPLOYEE refererar till (är främmande nyckel mot) tabellen BUSINESS. Det måste alltså finnas en primärnyckel i BUSINESS vars värden svarar mot värdena för BID i tabellen EMPLOYEE. Om man inte skriver SQL kan man fortfarande visa vilka främmandenyckelrelationer som råder. T ex genom EMPLOYEE. BID = BUSINESS.BID 39 DDL / Arvssamband Personnr :String 1..1 UNIK Namn: String 1..1 ANSTÄLLD KONSULT Avdelning: String 1..1 Projekt: String 1..1 Person(Personnr:char(10), Namn:varchar(20)) PK Personnr Anställd(Personnr:char(10), Avd:varchar(20)) PK Personnr FK Personnr REFERENCES Person UPDATE OF Person.Personnr CASCADES DELETE OF Person CASCADES Konsult(Personnr:char(10), Projekt:varchar(20)) PK Personnr FK Personnr REFERENCES Person UPDATE OF Person.Personnr CASCADES DELETE OF Person CASCADES 40

21 TRIGGERS Regler för verksamheten som tas med i modellen! - Beställningspunkt skall kontrolleras vid utleverans - Inrapporterad körsträcka måste överstiga förgående inrapporterade körsträcka - Kunds kreditgräns får ej överskridas - Om beställningspunkt är större än antal-i-lager skall beställningsmeddelande skrivas ut TIDSINSTÄLLDA TRIGGERS aktiveras vid tider eller efter tidsintervall 41 Triggers händelse som utlöser (insert, update, delete, retrieve) objekt (attribut eller entitet) som berörs villkor som utlöser triggern åtgärder när triggern utlöses 42

22 Triggers exempel CREATE TRIGGER Signalera_stora_ökningar: AFTER UPDATE OF SALARY ON EMPLOYEE REFERENCING NEW AS n OLD AS o FOR EACH ROW MODE DB2SQL IF n.salary > 1.1 * o.salary SIGNAL SQLSTATE ( Salary increase > 10 % ) EMPLOYEE Name Adress Salary Kalle Byvägen Olle Solstigen Stina Ekgränd Kurt Byvägen Kontrollera relationer genom normalisering (Analytisk databasdesign) 44

23 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. 45 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. 46

24 Transitivt funktionellt beroende Ett funktionellt beroende X Y i en relationsschema R utgör ett transitivt funktionellt beroende omm: Det finns en mängd attribut, Z, som varken utgör en kandidatnyckel för R eller är delmängd av en sådan X Z och Z Y gäller 47 1NF, 2NF and 3NF according to Codd 1 NF A relation is in first normal form iff every attribute is single-valued for each tuple 2NF A relation is in second normal form iff it is in first normal form and all the non-key attributes are fully functionally dependent on the key 3NF A relation is in third normal form iff it is in second normal form and no non-key attribute is transitively dependent on the key Notera att key, som sagt, kan tolkas på minst två sätt! 48

25 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. 49 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. 50

26 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. 51 2NF En tabell är i 2NF omm den är i 1NF och alla icke-nyckel attribut är funktionellt beroende av hela primärnyckeln. Vi fortsätter exemplet från 1NF: Pnr Namn Ort Postnr Ann Kista Maria Kista Kalle Södertälje Maria Södertälje Lisa Kista NF 2NF -NAMN Pnr Ort Postnr Pnr Namn Kista Ann Södertälje Maria Södertälje Kalle Kista Maria Lisa Pnr, Namn Ort, Postnr gäller. Dvs. för varje par av värden på Pnr och Namn så finns det högst ett värde på såväl Ort som Postnr. Men både Ort och Pnr bestämms också av enbart Pnr. Alltså gäller Pnr Ort, Postnr. Ort och Postnr är alltså inte beroende av hela nyckeln. Bryt ut Pnr och de attribut som Pnr bestämmer till en egen tabell! Som synes får vi samma lösning som lösning 2. när vi försökte gå från 0NF till 1NF. Lösning 2. var alltså redan i 2NF! 52

27 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 53 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 primär-nyckeln. -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 NF (och 3NF!) För tabellen har vi två funktionella beroenden att ta hänsyn till: Pnr Postnr, Ort Postnr Ort Notera att det första beroendet egentligen är två: Pnr Pnr Postnr Ort Ort är alltså både Pnr direkt beroende Postnr och av primär-nyckeln och transitivt beroende av primär-nyckeln. 54

28 Något om notation och inferens-regler för funktionella beroenden (sid 479 Fundamentals ). Primärnyckel I: A, B CD II: B, C D Relation R(ABCD) Notera notation : X,Y { X, Y } IR4: A,B C ( OCH A,B D) IR1: A,B B (eftersom B är en delmängd av vänsterledet) IR5: A,B B,C (IR1 och IR4 tillsammans) Nu har vi alltså både A, B B,C och B, C D! Dvs transitiva regeln (IR3) gäller. Har vi då ett transistivt beroende? Ja om B,C inte är en kandidatnyckel, eller delmängd av kandidatnyckel, för relationen R. 55 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 50 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 F

29 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! 57