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

Transkript

1 ÖVNING 10 2NF HÄST (Hästnamn, Mankhöjd, Favoritmat, Art, Medelvikt, Spiltnummer, Bredd, Höjd) PERSON(Personnummer, Namn, Adress, Telefon) RIDKURS(KursId, StartDatum, SlutDatum, Ledare) KURS(KursId, Svårighetsgrad) NY! 3NF HÄST (Hästnamn, Mankhöjd, Favoritmat, Art, Spiltnummer) ART(Art, Medelvikt) NY! NY! SPILTA(Spiltnummer, Bredd, Höjd) NY! NY! PERSON(Personnummer, Namn, Adress, Telefon) RIDKURS(KursId, StartDatum, SlutDatum, Ledare) KURS(KursId, Svårighetsgrad) NY!

2 ÖVNING 11 a) PERSON(Namn, Ålder, Stad, Land) Följande funktionella beroenden råder: Namn Ålder, Stad, Land Stad Land Denna tabell är inte ens i 3NF men väl i 2NF (om vi förutsätter att den är i 1NF). Den är i 2NF eftersom alla icke-nyckel attribut är fullständigt funktionellt beroende av primärnyckeln. Vi har ju bara ett attribut i nyckeln och då måste vi alltid ha 2NF om vi överhuvudtaget har 1NF. Men tabellen är inte i 3NF (och därmed inte heller i BCNF) eftersom det finns ett funktionellt beroende mellan två icke-nyckel attribut nämligen Stad Land och därmed ett transitivt beroende mellan ett icke-nyckelattribut och nyckeln. Varken STAD eller LAND ingår ju i primärnyckel eller eventuella kandidatnycklar (har vi inga här). Alltså måste vi först ordna till 3NF och sen kontrollera om vi på köpet hamnade i BCNF eller om vi måste gå vidare för att komma dit. Men först övergår vi till 3NF: PERSON(Namn, Ålder, Stad) STAD(Stad, Land) Dessa tabeller är i såväl 3NF som BCNF. Att de är i 3NF beror på att inga transitiva beroenden finns mellan icke-nyckelattributen och nyckeln. Att tabellerna är i BCNF beror på att ALLA determinanter är kandidatnycklar. (De enda funktionella beroenden vi hade var ju Namn Ålder, Stad respektive Stad Land och både Namn och Stad är ju primärnycklar. OBS att Stad i tabellen PERSON inte längre utgör en determinant i denna tabell. Det kan även vara bra att kontrollera om nedbrytning var non-loss. Jag gör det genom att JOIN:a PERSON med STAD-LAND och kontrollera att jag bara får tillbaka de tupler jag ursprungligen hade. Om jag får det så är dekomponeringen non-loss! Jag gör en NATURAL JOIN dvs. FN-attributet STAD kommer bara med en gång: Vi utgår från följande exempel tupler (där alla funktionella beroenden är uppfyllda): PERSON NAMN ÅLDER STAD LAND Maria 8 S-tälje Sverige Lisa 7 Säffle Sverige

3 Detta blev (efter 3NF-nedbrytning) : PERSON STAD-LAND NAMN ÅLDER STAD STAD LAND Maria 8 S-tälje S-tälje Sverige Lisa 7 Säffle Säffle Sverige NATURAL JOIN på PERSON och STAD-LAND: (jag återgår till det gamla namnet PERSON på den resulterande tabellen) PERSON NAMN ÅLDER STAD LAND Maria 8 S-tälje Sverige Lisa 7 Säffle Sverige Samma tupler som vi ursprungligen hade, dvs dekomponeringen var non-loss!

4 b) FÖRELÄSNING(Kurs, Lärare, Tid) Följande funktionella beroenden råder: Kurs Lärare Lärare, Tid Kurs FÖRELÄSNING(Lärare, Tid, Kurs) där alltså valts till PN = Lärare, Tid (En alternativ primärnyckel är Kurs+Tid) Gör en exempellistning som visar beroendena: FÖRELÄSNING LÄRARE TID KURS Maria oktober *62 Maria november *62 Petia november *58 Maria december DSVL1:5 Vi testar beroendena ett och ett: först Lärare,Tid Kurs: Eftersom alla fyra tuplerna har OLIKA värden på kombinationen Lärare,Tid så måste beroendet Lärare, Tid Kurs vara uppfyllt! Nu provar vi om Kurs Lärare håller: * 62 har bara ett värde på lärare nämligen Maria *58 har bara ett värde på lärare nämligen Petia DSVL1:5 har bara ett värde på lärare nämligen Maria Dvs även beroendet Kurs Lärare håller! Nu ska vi kontrollera om tabellen är i BCNF: Den är i 3NF (den är i 2NF eftersom det enda icke-nyckelattributet, Kurs, är fullständigt funktionellt beroende av primärnyckeln. Den är i 3NF eftersom det inte finnas några transitiva beroenden mellan vårt enda icke-nyckelattribut och nyckeln). Men, den är INTE i BCNF eftersom vi har en determinant ("det som står till vänster i ett funktionellt beronde") som INTE är en kandidatnyckel nämligen KURS. Alltså måste vi bryta ner tabellen FÖRELÄSNING till (till exempel...):

5 KURS-LÄRARE KURS LÄRARE *62 Maria *58 Petia DSVL1:5 Maria LÄRARE-TID LÄRARE Maria Maria Petia Maria TID oktober november november december Nu är tabellerna i BCNF (De är i 3NF och alla determinanter är kandidatnycklar). Vi provar även här att testa om komponeringen är non-loss eller inte: Vi gör alltså NATURAL JOIN över LÄRARE-TID Och KURS-LÄRARE (även här återtar jag namnet FÖRELÄSNING på den resulterande tabellen). FÖRELÄSNING LÄRARE TID KURS Maria oktober *62 Maria oktober DSVL1:5 Maria november *62 Maria november DSVL1:5 Petia november *58 Maria december *62 Maria december DSVL1:5

6 Här har vi fått tre NYA tupler (som inte fanns i ursprungliga föreläsningen) nämligen andra, fjärde och sjunde tupeln. Dekomponeringen var alltså INTE non-loss. De funktionella beroendena är inte längre uppfyllda t ex har samma kombinationa av LÄRARE,TID (Maria, Oktober i första och andra tupeln) TVÅ OLIKA värden på KURS!

7 Vi provar istället med att göra följande nedbrytning: KURS-LÄRARE KURS LÄRARE *62 Maria *58 Petia DSVL1:5 Maria KURS-TID KURS TID *62 oktober *62 november *58 november DSVL1:5 december Och så slår vi ihop dem via NATURAL JOIN igen: LÄRARE TID KURS Maria oktober *62 Maria november *62 Petia november *58 Maria december DSVL1:5 Jepp, bara de tupler som ursrpungligen fanns!

8 ÖVNING 12 GLASS(Namn, Pris, Fettinnehåll) GLASSÄTANDE(Personnummer, GlassNamn) PERSON(Personummer, Namn, Vikt) Motsvarande CREATE-TABLE-satser: CREATE TABLE GLASS( Namn varchar(50) NOT NULL, Pris Integer NOT NULL, Fettinnehåll Float NOT NULL, PRIMARY KEY(Namn)) CREATE TABLE PERSON( Personnummer integer NOT NULL, Namn varchar(50) NOT NULL, Vikt integer NOT NULL, PRIMARY KEY(Personnummer)) CREATE TABLE GLASSÄTANDE( Personnummer char(10) NOT NULL, Glassnamn varchar(50), PRIMARY KEY(Personnummer, Glassnamn), FOREIGN KEY(Personnummer) REFERENCES PERSON(Personnummer) ON DELETE CASCADE, FOREIGN KEY(Glassnamn) REFERENCES Glass(Namn) ON DELETE SET NULL) Lösningsförslag: Felen hade att göra dels med en datatyp på en främmande nyckel, att en del av primärnyckeln var deklarerad som att NULL tilläts, samt att en DELETE-regel tillät att en del av primärnyckeln fick vara NULL. Plus att det saknas UPDATEregler. Här är ett lösningsförslag: CREATE TABLE GLASSÄTANDE( Personnummer integer NOT NULL, Glassnamn varchar(50) NOT NULL, PRIMARY KEY(Personnummer, Glassnamn), FOREIGN KEY(Personnummer) REFERENCES PERSON(Personnummer) ON DELETE CASCADE ON UPDATE RESTRICT,

9 FOREIGN KEY(Glassnamn) REFERENCES Glass(Namn) ON DELETE RESTRICT ON UPDATE RESTRICT)