Lösningsförslag till fiktiv tentamen för DD1370 Databasteknik och informationssystem Hösten 2011
1. a) Jag följer kokboken (förel 3, bild 34) a. Regeln säger att alla objektklasser med e-termer ska bilda tabeller: Prenumerant (Pnr, Namn, Adress, Tel) b. Objektklasser utan E-termer som finns på N-sidan i en 1:N-sambandsklass bildar tabell men andra objektklasser utan E-termer försvinner. Den enda objektklassen på N-sidan i en 1:N-sambandsklass (Prenumerant) har redan bildat tabell enligt föregående regel. Tidning och Dagtyp försvinner. c. Sambandsklasser av högre grad (ordning) än två bildar tabell Prenumerant (Pnr, Namn, Adress, Tel) d. Sambandsklasser av typ M:N bildar tabell Prenumerant (Pnr, Namn, Adress, Tel) Prenumeration (Namn, Pnr) e. Sambandsklasser av typ 1:N försvinner men I-termen på 1-sidan blir E-term i tabellen som objektklassen på N-sidan har bildat. Prenumerant (Pnr, Namn, Adress, Tel, ID) Prenumeration (Namn, Pnr) f. Det finns inga sambandsklasser av typ 1:1 Klart! Resultatet: Prenumerant Utdelare Distrikt Distribution Prenumeration (Pnr, Namn, Adress, Tel, ID) (Pnr, Namn, Adress, Tel) (ID, Adress) (Pnr, Typ, ID) (Namn, Pnr) b) Det bästa är att lägga till en sambandsklass som visar att en viss prenumerant mellan två specificerade datum ska ha sina tidskrifter till en annan adress 1 av 5
Tidning Prenumeration Eftersändning Prenumerant Datum Tillhör Utdelare Distribution Distrikt Dagtyp Då behöver man inte göra något speciellt åt det som redan finns i egenskapsmatrisen utan endast lägga till objektklassen Datum och sambandsklassen Eftersändning Typ Namn I-termer E-termer Obj Datum Datum Samb Eftersändning Namn, Pnr, Datum SlutDatum, Adress Detta i sin tur ger en tabell till enligt regel c: Prenumerant (Pnr, Namn, Adress, Tel, ID) Prenumeration (Namn, Pnr) Eftersändning (Pnr, Typ, Datum, Slutdatum, Adress) 2. a) Eftersom kurser ges vid sina institutioner och institutionerna ger mer än en kurs drar jag slutsatsen att KNr -> INamn och att KNr -> Knamn. Dessutom säger uppgiftstexten att ett projekt hör till en kurs men att varje kurs har flera än ett projekt så PNr -> Knr. PNr -> Pnamn, Start och Slut eftersom de hör till projektet, också enligt uppgiften. Man skulle kunna tänka sig att Start och Slut hör till kursen (alla kursens projekt startar och slutar samtidigt men det står inte så) Slutligen anser jag att Snr -> SNamn, SAdress, SINamn Det enda problemet är att det inte finns något som håller ihop studenter med deras projekt. Avsaknaden av beroende kan bero på att det just är detta tabellen ska beskriva Av allt detta drar jag slutsatsen att eftersom KNr -> KNamn, INamn PNr -> PNamn, Start, Slut, Knr Snr -> SNamn, SAdress, SINamn och PNr och Snr hör ihop så blir det en bättre struktur med 2 av 5
Kurs ((KNr), KNamn, INamn) Projekt (PNr, PNamn, Start, Slut, Knr) Student (Snr, SNamn, SAdress, SINamn) Projarbete (Snr, PNr) En mer formell väg vore att utgå ifrån (INamn, KNr, KNamn, PNr, PNamn, Start, Slut, Snr, SNamn, SAdress, SINamn) och använda metoden från föreläsning 7 för att hitta en nyckel. Ta bort allt som bestäms av KNr, sedan allt som bestäms av PNr och sist allt som bestäms av Snr. Kvar blir bara PNr och Snr och vi har en första normalform: (PNr, Snr, INamn, KNr, KNamn, PNamn, Start, Slut, SNamn, SAdress, SINamn) För att komma till andra normalform använder vi PNr -> PNamn, Start, Slut, Knr (och KNr -> KNamn, INamn) samt Snr -> SNamn, SAdress, SINamn och får (Snr, PNr) (PNr, PNamn, Start, Slut, Knr, KNamn, INamn) samt (Snr, SNamn, SAdress, SINamn) För att komma till tredje normalform använder vi KNr -> KNamn, INamn på tabell två i listan och får en uppdelning (Snr, PNr) (PNr, PNamn, Start, Slut, Knr) (Knr, KNamn, INamn) samt (Snr, SNamn, SAdress, SINamn) och behöver bara sätta namn på dem. Vill man kan man nu göra en reverse engineering för sin egen kontroll och se att det blir OK (modellen verkar bra) b) Man kommer få alla de problem vi gick igenom på föreläsningen (OBS att vi utgår ifrån uppgiftslydelsen): borttagningsproblem: Om man tar bort ett projekt så försvinner all information om studenter eller tvärtom om en student hittills är den enda studenten på ett projekt och den studenten hoppar av så försvinner all info om projektet. insättningsproblem: Vi kan inte mata in data om ett projekt utan att ha åtminstone en student knuten till projektet. uppdateringsproblem: Om ett projekt byter namn måste vi gå igenom hela tabellen för att ändra på okänt antal ställen. 3. a) Vilka chefer har fler underlydande än genomsnittet? b) Vilken är genomsnittslönen för varje våning? c) select avd, count(namn) from Anställd where avd in (select avd from försäljning where varunr in (select varunr from vara where typ = bröd )) group by avd 3 av 5
4. a) Om man utgår från reglerna för övergång till databasstruktur ser man att Den övre modellen ger en tabell D (I A, I B, I C ) med SQL-deklarationen (enligt förel 4) där jag skriver ihop till IA, IB,... och hittar på att typen är integer: IA integer not null, IB integer not null, IC integer not null, primary key (IA, IB, IC), foreign key IC references C Den nedre modellen ger D (I D, I A, I B, I C ) där man enligt föreläsning 4 skulle deklarera tabellen enligt ID integer not null, IA integer, IB integer, IC integer, primary key (ID), foreign key IC references C Här ser vi att modellerna inte uttrycker samma sak eftersom alla främmande nycklar ska ha ett existerande värde i tabellen de refererar till eller vara null, vilket de inte kan i den övre modellen eftersom de ingår i primärnyckeln. Alltså kan man i den undre modellen ha bara en referens till A eller B eller C eller till två av dem men det går inte i den övre. b) Visst kan man se till att det blir samma sak (utom med avseende på den extra I-termen (I D ) i det senare fallet) med hjälp av SQL Man kan deklarera att ingen får vara null (ett steg på vägen): ID integer not null, IA integer not null, IB integer not null, IC integer not null, primary key (ID), foreign key IC references C 4 av 5
och vill man också ha ett index kopplat till kombinationen I A, I B, I C så går man ett steg längre och deklarerar kombinationen som unik och då fungerar de båda tabellerna med avseende på relationen till omgivande tabeller exakt lika i båda fallen: ID integer not null, IA integer not null, IB integer not null, IC integer not null, primary key (ID), foreign key IC references C, unique (IA, IB, IC) 5 av 5