Institutionen för Data- och Systemvetenskap IT-universitetet Maria Bergholtz Exempel-Tentamen III Inga hjälpmedel tillåtna (syntaxsammanställning behövs inte på denna tentamen) Skriv bara på en sida av pappret Skriv namn på varje papper Skriv läsligt, annars är det svårt att rätta tentamen Lycka till!
Sidan 2 av 6 Uppgift KONSTRUERA ETT KONCEPTUELLT SCHEMA Partiella attribut (attribut som har minvärde 0), samt partiella associationer/relationer (associationer/relationer som har båda rollerna partiella, dvs med minvärde 0 i båda rollerna) ska undvikas! En hundutställning består av ett antal bedömningar av hundar. Varje bedömning kan ses som en tävling där en hund vinner. Vinnande hundar i varje bedömning går vidare till final-bedömningen där någon hund väljs till Best in Show.. Hundar tilllhör olika hundraser. Varje ras hör till en viss grupp, det finns olika grupper, bl a drivande hundar, sällskapshundar, dvärghundar och spetsar De olika bedömningarna av hundar (se punkt ) är baserade på grupper, dvs en bedömning av drivande hundar sker, en bedömning av spetsar sker och så vidare. Sen tävlar vinnande spets med övriga grupp-vinnare om titeln Best in Show. För varje grupp finns ett antal bedömningskriterier. För spetsar bedöms noslängd, svanslängd, mankhöjd och färg. För drivande hundar bedöms skall-kvalitet, noslängd och mankhöjd. Olika bedömningskriterier har olika typer av betyg. För skall-kvalitet gäller betygen utmärkt, gott och otillfredställande. För mankhöjd gäller lagom, liten eller för hög. När en hund deltar i en bedömning erhåller den ett betyg på varje kriterium som gäller för den grupp hunden tillhör. Hunden Fido är av typen Spets och är 40 cm hög (mankhöjd). Spetsar har median-mankhöjden 50 cm. Fido blev Best in Show på utställningen Stora Stockholm som gick av stapeln i Stockholm december 2005. Karo vann drivande-hund-gruppen på Crufts i London januari 2005. Collien Lassie (tillhör gruppen sällskapshundar) deltog i Stora Stockholm i december 2005 men placerade sig inte. (8 p)
Sidan 3 av 6 GRUPPBEDÖ MNING Domare :.. gäller INDIVIDBEDÖ MNING Placering :....*..* avser KRITBEDMNING Erhållet_värde :....* ingår_i UTSTÄLL NING UNamn :.. Stad :....* avser gäller KRITVAL Skala :.. Enhet :.. BiS för HUNDTYP Ras :.. Median_mankhöjd :.. HUND Namn :.. Mankhöjd :.. av_typ KRITERIUM Namn :.. UNIK avser Uppgift 2 a) Konstruera en tabell som är i NF men inte är i 2NF. (2p) Krav på lösning: En tabell med angivet namn, angivna kolumner och angiven primärnyckel. Eventuella funktionella beroenden (som råder mellan kolumnerna) som ni anser behövs. Motivering till varför tabellen är i 2NF men inte i 3NF. TABELL(A, B, C, D) där A,B C, D B C Eftersom C är bestämd bara av halva nyckeln (A, B) och dsv C är bestämd av {B} och {B} utgör en delmängd till {A, B} så har vi ett partiellt funktionellt beroende mellan C och nyckeln. b) Betrakta följande definition av tabellen OSTTILLVERKNING: CREATE TABLE OSTTILLVERKNING( OstID integer NOT NULL, OstNamn varchar(50) NOT NULL, Antal integer NOT NULL Datum Date NOT NULL, Pris Integer NOT NULL, Primary key(ostid, Datum); Storlek datatyper: Varchar: byte per allokerat tecken, en varchar(50) upptar 50 bytes Integer: 4 byte
Sidan 4 av 6 Date: 4 byte Följande funktionella beroenden råder: OstId, Datum - Pris, OstNamn, Antal Antal Pris a) Tabellen är i NF, Normalisera denna tabell till högsta möjliga normalform. För varje normaliseringssteg du gör, motivera varför du gör det! (4p) OSTPRIS(Antal, Pris) OSTTILLVERKNING(OstiID, Datum, OstNamn, Antal), där OSTTILLVERKNING. Antal << OSTPRIS.Antal Skälet till att OSTPRIS skapades är att Pris är transitivt bestämd av primärnyckeln (OstiID, Datum Antal, Antal Pris och Antal ingår inte i en kandidatnyckel). b) Vad effekter kommer normaliseringen att leda till i just detta fall med avseende på hur mycket utrymme databasen kommer att uppta och hur lång tid den kommer att ta att läsa eller skriva (du kan anta att läsningar/skrivningar sker ad hoc, dsv alla rader läses ibland, enstaka rader ibland blandat med skrivningar). Motivera ditt svar! (4p) Vanligen kan man förvänta sig att databasen tar mindre plats normaliserad än icke normaliserad. I detta fall viner vi 4 byte ( integer) för att vi slipper upprepa Pris på varje rad i OSTTILLVERKNING. Å andra sidan måste vi dubbellagra den främmande nyckeln Antal som också tar 4 byte. Om antalet unika värden i Antal är många är det inte säkert att databasen kommer att bli mindre även om vi normaliserar. Om å andra sidan har en distribution av värden för kolumnen Antal som innebär att få unika värden finns (låt oss anta att man kanske tillverkar i fasta antal, säg 0, 00 och 000 och inga andra Antal) så kommer vi att slippa upprepa Pris för alla de rader i OSTTILLVERKNING som uttnyttjar något av det tre värdena på Antal. Läsning av databasen tar vanligen längre tid i normaliserat tillstånd eftersom join kostar. Vissa transaktioner (de som bara går mot _endera_ OSTPRIS _eller_ OSTTILLVERKNIG) kommer dock att går fortare i normaliserat tillstånd. Skrivning går snabbar mot normaliserade tabeller, här behöver vi bara lägga in Pris:et på EN rad (i OSTPRIS) osv för uppdatering och bortttag. Uppgift 3 Betrakta följande konceptuella schema:
Sidan 5 av 6 GEO_OBJEKT Namn :.. UNIK STAD Antal_invånare :.. Borgmästare :....* mitt_land huvud_stad LAND Antal_innvånare :.. 0.. gränsar_till Översätt det konceptuella schemat till ett databas-schema. Du kan använda följande struktur för definition av databas (dvs CREATE TABLE-satser ska inte skrivas): (6p) TABELLNAMN(Primärnyckelkolumn, Primärnyckelkolumn2, annankolumn, annankolumn2) TABELLNAMN2(Primärnyckelkolumn, annankolumn, annankolumn2) TABELLNAMN2.(annankolumn,annankolumn2)<<TABELL.(Primärnyckelkolumn,Primärnyckelkolumn2). Där sista raden betyder att tabellen TABELLNAMN2 har en främmande nyckel mot tabellen TABELLNAMN. GEOOBJEKT(Namn) STAD(Namn, Antal_invånare, Borgmästare, MittLand), STAD.MittLand << LAND.Namn LAND(Namn, Antal_invånare, Huvudstad), LAND.Huvudstad << STAD.Namn GRÄNSAR_TILL(Land, Land2),GRÄNSAR_TILL.Land<< LAND.Namn, GRÄNSAR_TILL.Land2 << LAND.Namn Alternativt en egen tabell för det partiella attributet MittLand i STAD. Uppgift 4 Betrakta följande tabeller: SJUKHUS(Namn, Adress, Postnr, Stad, SJUKHUSDirektör ) KLINIK(KLINIKNamn, SJUKHUSNamn, Klinikföreståndare) RUM(RUMNr, KLINIKNamn, SJUKHUSNamn, Ickerökare) SÄNG(SÄNGNr, RUMNr, KLINIKNr, SJUKHUSNamn, Mjukhet) PERSON(Pnr, Namn, Adress, Postnr, Stad, Telefon, Närmaste_anhörig) INTAGNING(Pnr, SÄNGNr, RUMNr, KLINIKNr, SJUKHUSNamn) Primränycklar i fetstil. Främmande nycklar: KLINIK.SJUKHUSNamn << SJUKHUS.Namn RUM.(KLINIKNamn, SJUKHUSNamn) << KLINIK.(KLINIKNamn, SjukhusNamn) SÄNG.(RUMNr, KLINIKNamn, SjukhusNamn) << RUM. (RUMNr, KLINIKNamn, SjukhusNamn)
Sidan 6 av 6 INTAGNING.(SÄNGNr, RUMNr, KLINIKNamn, SjukhusNamn) << SÄNG.(SÄNGNr, RUMNr, KLINIKNamn, SjukhusNamn) INTAGNING.Pnr << PERSON.Pnr Definiera följande fråga i SQL och relationsalgebra: Ta fram alla sjukhus som haft minst 30 personer inlagda men aldrig några personer från New-York (5+5p) SELECT SjukhusNamn AS Namn FROM INTAGNING GROUP BY SjukhusNamn HAVING COUNT(*) > 30 /* icke unika personer ok här */ UNION SELECT SJUKHUS.Namn FROM SJUKHUS WHERE SJUKHUS.Namn NOT IN (SELECT SJUKHUS.Namn FROM SJUKHUS, INTAGNING, PERSON WHERE SJUKHUS.Namn = INTAGNING.SjukhusNamn AND INTAGNING.Pnr = PERSON.Pnr AND PERSON.Stad = New York ) IckeNYsjukhus(Namn) PI Namn (SJUKHUS) PI Sjukhusamn (SIGMA Stad= New York ((PERSON X INTAGNING) X SJUKHUS) PERSON.Pnr= INTAGNING.SjukhusNamn= INTAGNING.Pnr SJUKHUS.Namn Antal_per_sjukhus(Namn, Antal) SjukhusNamn G COUNT(*) (INTAGNING) Svar PI Namn (SIGMA Antal > 30 (Antal_per_sjukhus X IckeNYsjukhus)) Antal_per_sjukhus.Namn = IckeNYsjukhus.Namn