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



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

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

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

Lösningsförslag till Tentamen,

Karlstads Universitet, Datavetenskap 1

Logisk databasdesign

Informationssystem och databasteknik

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

IT i organisationer och databasteknik

Databaser Design och programmering

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

Lösningsförslag till Exempel tentamen

Analytisk relationsdatabasdesign

Funktionella beroenden - teori

Tentamen plus lösningsförslag

Karlstads Universitet, Datavetenskap 1

Normalisering. Christer Stuxberg Institutionen för Informatik och Media

Föreläsning 6: Normalisering & funktionella beroenden

NORMALISERING. Mahmud Al Hakim

Universitetet: ER-diagram

Lösningsförslag Tentamen, 25 april 03

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

Grunderna för relationsmodellen!

Relationell databasdesign

Konceptuella datamodeller

Lösningar till Algebra och kombinatorik

Tentamen i Databasteknik

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

Exempel-Tentamen III

Lösningar till tentamen i EDAF75

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

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

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

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

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

Lösningsförslag, tentamen i Databaser

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

Diskret Matematik A för CVI 4p (svenska)

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

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

Definitionsmängd, urbild, domän

729G04 - Diskret matematik. Lektion 3. Valda lösningsförslag

DIVISIONSEXEMPEL RELATIONSALGEBRA OCH SQL. r s använder vi för att uttrycka frågor där ordet alla figurerar:

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

Föreläsning 8 i kursen Ma III, #IX1305, HT 07. (Fjärde föreläsningen av Bo Åhlander)

Databasdesign. E-R-modellen

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

Tentamen Databasteknik

Uppsala Universitet Matematiska Institutionen Thomas Erlandsson

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

Lösningsförslag till övningsuppgifter, del II

Algebra och Diskret Matematik A (svenska)

Explorativ övning 9 RELATIONER OCH FUNKTIONER

Vektorgeometri för gymnasister

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

Tentamen i TDDC75 Diskreta strukturer

1. Inledning, som visar att man inte skall tro på allt man ser. Betrakta denna följd av tal, där varje tal är dubbelt så stort som närmast föregående

KOMBINATORIK OCH BINOMIALSATSEN

Karlstads Universitet, Datavetenskap 1

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

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

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

LMA033/LMA515. Fredrik Lindgren. 4 september 2013

Skriftlig tentamen i kurserna TDDD12 och TDDB48 Databasteknik kl

Övningshäfte 3: Funktioner och relationer

Relationsdatabasdesign

inte följa någon enkel eller fiffig princip, vad man nu skulle mena med det. All right, men

Filosofisk logik Kapitel 15. Robin Stenwall Lunds universitet

Lösningar till Algebra och kombinatorik

Kappa 2014, lösningsförslag på problem 5

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

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

Mängder och kardinalitet

Uppsala universitet Institutionen för lingvistik och filologi. Grundbegrepp: Mängder och element Delmängder

Övningshäfte 1: Logik och matematikens språk

Motivet finns att beställa i följande storlekar

Explorativ övning 5 MATEMATISK INDUKTION

Databaser - Design och programmering. Operationer i relationsalgebra. Att söka ut data. Exempel DBschema. Att plocka ut data, forts

Utsagor (Propositioner) sammansatta utsagor sanningstabeller logisk ekvivalens predikat (öppna utsagor) kvantifierare Section

Grundläggande 1 övningar i kombinatorik

Databasteori. Övningar

Informationssystem och Databasteknik

Webbprogrammering, grundkurs 725G54

Tentamen i. Databasteknik

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

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

TDDI60 Tekniska databaser

Mer om analytisk geometri

Tentamen för DD1370 Databasteknik och informationssystem

MYSTERIER SOM ÅTERSTÅR

Databaser och Datamodellering Foreläsning IV

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

Introduktion till algoritmer - Lektion 4 Matematikgymnasiet, Läsåret Lektion 4

Relationer. 1. Relationer. UPPSALA UNIVERSITET Matematiska institutionen Erik Melin. Specialkursen HT07 23 oktober 2007

Inlämningsuppgift, LMN100

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

Kontinuitet och gränsvärden

Relationer och funktioner

Tentamen i Databasteknik

Transkript:

ÖVNING 1. PRODUKT(Nummer, Namn, Typ, Klass, Prisklass, Vikt, Volym, Fraktkostnad) Nummer, Typ Namn, Klass, Pris, Prisklass, Vikt, Volym, Fraktkostnad Namn, Typ Nummer Typ Klass Pris Prisklass Vikt, Volym, Fraktkostnad Pga att (Nummer och Typ) tillsammans bestämmer övriga attribut funktionellt väljer vi (Nummer, Typ) till primärnyckel: PRODUKT(Nummer, Namn, Typ, Klass, Prisklass, Vikt, Volym, Fraktkostnad) En alternativ skulle vara att välja (Namn, Typ) till PN. I så fall måste vi visa att (Namn,Typ) bestämmer övriga attribut funktionellt: Vi har att: Namn, Typ Nummer Reflexiva lagen ger: Namn, Typ, Typ Nummer, Typ Vilket kan skrivas om som: Namn, Typ Nummer, Typ Och eftersom Nummer, Typ alla övriga attribut så ger transitiva lagen att Namn, Typ också bestämmer övriga attribut funktionellt. 2NF Vi har att Typ Klass. Eftersom {Typ} är en delmängd av {Nummer, Typ} (dvs Typ är en delmängd av primärnyckeln) så har vi ett partiellt funktionellt beroende mellan primärnyckeln och icke-nyckelattributet Klass. Alltså bryter vi ut på följande vis: TYPKLASS(Typ, Klass) PRODUKT(Nummer, Typ, Namn, Pris, Prisklass, Vikt, Volym, Fraktkostnad), PRODUKT.Typ << TYPKLASS.Typ 3NF Eftersom Prisklass är bestämd av Pris och Fraktkostnad är bestämd av Vikt och Volym och samtliga dessa är bestämda (funkt. bestämda) av primärnyckeln så har vi alltså ett transitivt beroende mellan PN och Prisklass, respektive Fraktkostnad (eftersom vare sig Pris eller (Vikt, Volym) är del av PN). FRAKT (Vikt, Volym, Fraktkostnad) PRIS(Pris, Prisklass) PRODUKT(Nummer, Typ, Namn, Vikt, Volym, Pris), PRODUKT.Typ << TYPKLASS.Typ PRODUKT.Pris << PRIS.Pris PRODUKT.(Vikt, Volym) << FRAKT. (Vikt, Volym) TYPKLASS(Typ, Klass)

Notera att vi kan visa att för tabellen PRODUKT så gäller följande: Nummer, Typ {visades i A} Namn, Typ Pris, Vikt, Volym. Således skulle man kunna hävda att ett transitivt beroende föreligger mellan Pris, respektive (Vikt, Volym) och primärnyckeln. Så är dock inte fallet eftersom (Namn, Typ) utgör en kandidatnyckel.

ÖVNING 2. Primärnyckel för tabellen R blir (Art+Habitat+Byte) tillsammans. Detta eftersom inget av attributen Art, Habitat respektive Byte ensamt räcker till för att bestämma alla övriga attribut. Till exempel har Art flera värden på Habitat (Tiger har habitaten Savann och Lövskog, Habitaten Savann har t ex arten Tiger och Lejon, Bytet Gnu jagas av både Tiger och Lejon osv.). Inte heller någon kombination av två av attributen räcker till för att identifiera det kvarvarande attributet funktionellt (Tiger plus Savann har flera värden på byte, Tiger plus Gnu har flera värden på habitat: Savann och regnskog, och Gnu plus Savann har flera värden på art: Lejon och Tiger). Alltså måste alla attributen ingå i primärnyckeln. Tabellen blir en så kallad all-key tabell. Den resulterande tabellen är i 3NF Tabellen är all-key så villkoren för 2NF (alla icke-nyckelattribut ska vara funktionellt beroende av hela nyckeln: vi har inga icke-nyckelattribut här) och 3NF (det ska inte finnas några transitiva beroenden mellan något icke-nyckel attribut och nyckeln: vi har inga icke-nyckelattribut) är uppfyllda.

ÖVNING 3 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

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!

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...):

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

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!

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!

ÖVNING 4 LÅT U VARA EN MÄNGD AV ATTRIBUT och D en mängd av funktionella beroenden över attributen i U. Låt SAT(D) beteckna mängden av de relationer över U som uppfyller beroendena i D. a) Låt U = {a,b,c,d} och D = {b fi c, ad fi d}. Ge ett exempel på en relation som tillhör SAT(D) och en relation som inte tillhör SAT(D). a) Följande relation tillhör SAT(D) a b c d x x y y x x y z Följande relation tillhör inte SAT(D) a b c d x x y y x x z z b) Avgör för vart och ett av påståendena nedan om det är sant eller falskt. i) Om D1 D2 så SAT(D1) SAT(D2) ii) Om D1 D2 så SAT(D2) SAT(D1) iii) Om SAT(D1) SAT(D2) så D1 D2 iv) Om SAT(D2) SAT(D1) så D1 D2

i) Om D1 D2 så SAT(D1) SAT(D2) FALSKT. Motexempel enligt nedan: D1 = {a b} D2 = {a b, c d} För att visa att det inte gäller SAT(D1) SAT(D2) räcker det att uppvisa en relation som tillhör SAT(D1) men inte SAT(D2). En sådan relation är: a b c d x x y y x x y z

ii) Om D1 D2 så SAT(D2) SAT(D1) FALSKT om vi använder strikt delmängd. I så fall kan vi låta D1 = {a b, b c} och D2 = {a b, b c, a c}. Då stämmer vänsterledet men högerledet är inte sant pga att SAT(D2) = SAT(D1). SANT om vi använder icke-strikt delmängd. Bevis enligt nedan. Låt D1 = {f 1,,f n }, D2 = {f 1,,f n,.f n+1,,f n+k } Vad som behöver visas är att för varje relation A gäller följande implikation: om A tillhör SAT(D2) så A tillhör A SAT(D1). Låt A vara en relation Antag A tillhör SAT(D2) Då uppfyller A de funktionella beroendena f 1,,f n,.f n+1,,f n+k. Således uppfyller A f 1,,f n Per definition så gäller A tillhör SAT(D1). Och därmed är implikationen visad.

iii) Om SAT(D1) SAT(D2) så D1 D2 FALSKT. Motexempel enligt nedan. Vi ska nu anta att SAT(D1) SAT(D2) gäller. Det är samma sak som att säga att antalet tupler i SAT(D1) är färre än antalet tupler i SAT(D2). Vilket i sin tur är samma sak som att säga några tupler i SAT(D2) bryter mot några funktionella beroenden i D1 (eftersom de inte är element i SAT(D1). Vilket i sin tur betyder att D1 alltså har fler funktionella beroenden än D2. Således kan inte D1 vara en delmängd av D2. Alternativt ger man bara D1 och D2 några värden, där D1 är har fler element än D2: D2 = {a b} D1 = {a b, c d} Enligt i) så gäller vänsterledet, dvs vi vet att : SAT(D1) SAT(D2) Och vi ser ju att D1 INTE är en delmängd av D2, dvs högerledet gäller inte. Ännu enklare, låt D2 vara tomma mängden. Då gäller definitivt vänsterledet, men inte högerledet.

iv) Om SAT(D2) FALSKT. SAT(D1) så D1 D2 Motexempel: Låt D1 = {a b, b c, a c} Låt D2 = {a b, b c, d a} SAT(D2) är en delmängd av SAT(D1) eftersom, den upprätthåller alla funktionella beroenden i D1 OCH dessutom ett beroende till vilket kommer att diskvalificera vissa relationer som finns i SAT(D1) men som bryter mot d a. Men D1 är inte en delmängd av D2.