Tentamen plus lösningsförslag



Relevanta dokument
Lösningsförslag till Exempel tentamen

Exempel-Tentamen III

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

Lösningsförslag till Tentamen,

Lösningsförslag Tentamen, 25 april 03

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

Tentamen. Databasmetodik Lördag 27 september 2014 kl

Informationssystem och databasteknik

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

Logisk databasdesign

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

Konceptuella datamodeller

Inst. för Data- och Systemvetenskap SU Maria Bergholtz. Tentamen. 21/ kl Inga hjälpmedel är tillåtna (annat än ordbok).

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

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

Tentamen i Databasteknik

IT i organisationer och databasteknik

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

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!

Databaser Design och programmering

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

Analytisk relationsdatabasdesign

NORMALISERING. Mahmud Al Hakim

Universitetet: ER-diagram

Karlstads Universitet, Datavetenskap 1

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

TENTAMEN För kursen. Databasteknik. Ansvarig för tentamen: Anna Palmquist. Förfrågningar: Anslås inom 3 veckor

Tentamen i Databasteknik

Normalisering. Christer Stuxberg Institutionen för Informatik och Media

Exempel-tentamen 1. + Lösningsförslag. Inga hjälpmedel är tillåtna.

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

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

Tentamen ISGB01, ISGB24. Databasdesign 7,5 Poäng

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

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

TENTAMEN TDDB77 Databaser och Bioinformatik 24 april 2004, kl 14-18

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

Skriftlig tentamen i kurserna TDDD12 och TDDB48 Databasteknik kl

TENTAMEN TDDB77 Databaser och Bioinformatik 15 mars 2002, kl 14-18

Tentamenskod: Tentamensdatum: Tid: 14:00-19:00. Inga hjälpmedel är tillåtna

Tentamen ISGB01 (delkurs i ISGB24) Databasdesign 7,5 Poäng

TDDI60 Tekniska databaser

Tentamen. i Databasteknik. lördagen den 13 mars Tillåtna hjälpmedel: Allt upptänkligt material

Webbprogrammering, grundkurs 725G54

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

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

TER3. Försättsblad till skriftlig tentamen vid Linköpings universitet G28 TEN1 Webprogrammering och databaser Tentamen IDA 1 (7)

Karlstads Universitet, Datavetenskap 1

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

Tentamen NDA01G Öppen för alla. Tentamenskod: Inga hjälpmedel är tillåtna

Lite om databasdesign och modellering

Ett arbetsexempel Faktureringsrutin

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

Tentamen för DD1370 Databasteknik och informationssystem

Skriftlig tentamen i kurserna TDDD12 och TDDB48 Databasteknik kl

Relationsmodellen och syntetisk databasdesign

Design och underhåll av databaser

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

An English version of the questions is found at the back of each page.

Databaser och Datamodellering Foreläsning IV

TENTAMEN. TDDD12 Databasteknik TDDD46 Databasteknik. 16 augusti 2010, kl 14-18

Relationsdatabasdesign

Tentamen DATABASTEKNIK - 1DL116

TENTAMEN TDDB77 Databaser och Bioinformatik 12 juni 2007, kl 14-18

Karlstads Universitet, Datavetenskap 1

Databaser. Vad du ska lära dig: Ordlista

Tentamen för DD1370 Databasteknik och informationssystem

Tentamen och lösning,

Relationell databasdesign

Föreläsning 6: Normalisering & funktionella beroenden

Tentamen för DD1370 Databasteknik och informationssystem

TDDI 60 Tekniska databaser

Grunderna för relationsmodellen!

Lösningsförslag, tentamen i Databaser

Fiktiv tentamen för DD1370 Databasteknik och informationssystem

Lösningar till tentamen i EDAF75

Databasteknik för D1, SDU1 m fl

Tentamen i. Databasteknik

TENTAMEN TDDD12 Databasteknik 7 januari 2010, kl 14-18

Tentamen för DD1370 Databasteknik och informationssystem

Tentamen för DD1370 Databasteknik och informationssystem

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

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

TENTAMEN TDDB77 Databaser och Bioinformatik 19 april 2002, kl 14-18

Databasdesign. E-R-modellen

Databaskunskap 7,5 högskolepoäng Provmoment: Ladokkod: Tentamen ges för:

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 TDDB77 Databaser och Bioinformatik 17 mars 2005, kl 8-12

Viktigt! Glöm inte att skriva Tentamenskod på alla blad du lämnar in.

Tentamen Databasteknik

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

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

Tentamen för 1E1601. Måndag 10 mars 2003, kl Alla hjälpmedel tillåtna

Tentamen DATABASTEKNIK - 1DL116, 1MB025

ÖVNING 14. (Primärnycklar är angivna med fetstil.)

Transkript:

Inst. för Data- och Systemvetenskap SU/KTH Maria Bergholtz, Paul Johannesson Tentamen plus lösningsförslag 2I-1100 Informationssystem och databasteknik 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 Lycka till! Maxpoäng är 32. För betyg 3 krävs 20 poäng, för betyg 4 krävs 24 poäng och för betyg 5, 28 poäng. Uppgift 1

Konstruera ett konceptuellt schema, förslagsvis i form av ett UML klassdiagram, som kan representera följande. Ditt schema får innehålla högst 5 klasser, 6 attribut och 5 associationer. - Medelvikten för lejon i Kenya är 300 kg - Medelvikten för lejon i Tanzania är 350 kg - Medelvikten för antiloper i Kenya är 200 kg - Medelvikten för antiloper i Tanzania är 200 kg - Medellivslängden för tigrar i Indien är 12 år - Medellivslängden för tigrar i Pakistan är 13 år - Medellivslängden för lejon i Kenya är 9 år - Medellivslängden för kängurur i Australien är 22 år - Medellängden för lejon i Zimbabwe är 3,1 m. - Medellängden för antiloper i Angola är 2,1 m. (6 poäng) Lösningsförslag: DJUR ART namn EGEN- SKAP namn OBSER- VATION LAND namn MÅTT värde enhet Uppgift 2 Betrakta följande relationsdatabasschema: R1(A, B, C) R2(B, D, E) R3(A, B, F) R4(B, G) R5(B, H) R6(J, K) R7(A, B, J)

Primärnycklar är understrukna. Följande främmande nyckelsamband finns: R1.B << R2.B R3.A << R1.A R3.B << R2.B R4.B << R2.B R5.B << R2.B R7.J << R6.J R7.(A, B) << R3.(A, B) Konstruera ett konceptuellt schema (t.ex. ett UML klassdiagram) som uppfyller följande villkor: Om det konceptuella schemat översätts till ett relationsdatabasschema så erhålls det relationsdatabasschema som anges ovan. (6 poäng) Lösningsförslag: R1 a c R2 d e R3 f R4 g R5 h R7 R6 j k Uppgift 3 Betrakta följande relationsdatabasschema: HUND Hundnamn Ras Färg PERSON Personnummer Telefon Skostorlek HUNDÄGANDE Person Hund

ART Artnamn Medelvikt UTBREDNING Artnamn Land LAND Landsnamn Huvudstad Antal_invånare Primärnycklar är angivna i fetstil. Följande främmande nyckel förhållanden råder: HUNDÄGANDE.Person << PERSON.Personnummer HUNDÄGANDE.HUND << HUND.Hundnamn HUND.Ras << ART.Artnamn UTBREDNING.Artnamn << ART. Artnamn UTBREDNING.Land << LAND.Landsnamn Formulera följande frågor i relationsalgebra och SQL (OBS båda delar!): a) Vad heter den person som har störst skostorlek av alla personer som aldrig ägt en hund? (Namn och skostorlek ska returneras) b) Vilka arter finns i alla länder? (Artnamnen ska returneras) Lösningsförslag: (6 poäng) a) Relationsalgebra: Aldrig_hund_ägare (Personnummer) PI Personnummer (PERSON) - PI Person (HUNDÄGANDE) Ej_ägare_med_skor Aldrig_hund_ägare NATURAL JOIN PERSON Storskon PI Skostorlek ( Personnummer F Max(Skostorlek) (Ej_ägare_med_skor)) Svar PI Personnummer, Skostorlek (Aldrig_hund_ägare JOIN STORSKON.Skostorlek=Aldrig_hund-gare.Skostorlek STORSKON) Anm. Här har vi gokänt även de som inte gjort de sista steget. SQL: SELECT Personnummer, Skostorlek FROM PERSON WHERE Skostorlek = (SELECT Max(Skostorlek) FROM PERSON WHERE Personnummer NOT IN (SELECT Person FROM HUNDÄGANDE) AND Personnummer NOT IN

(SELECT Person FROM HUNDÄGANDE) Anm. Sista behövs för att utesluta de hundägare som råkar ha samma storlek som den största icke-hundägaren. b) Relationsalgebra: Svar UTBREDNING KVOT PI Landsnamn (LAND) SQL: SELECT U.Artnamn FROM UTBREDNING U WHERE NOT EXISTS (SELECT Landsnamn FROM LAND WHERE Landsnamn NOT IN (SELECT Land FROM UTBREDNING WHERE Art=U.Art)) Uppgift 4 Betrakta följande relation: PROJEKT Projnummer Anstnr Deltagandegrad ProjErsättning Telefon 1 Eva 100 25000 11111 1 Olle 50 10000 22222 2 Eva 100 25000 11111 3 Eva 50 15000 11111 2 Olle 50 10000 22222 3 Olle 100 20000 22222 4 Olle 100 20000 22222 Följande funktionella beroenden finns (vilka även illustreras av raderna i relationen)

Projnummer, Anstnr Deltagandegrad, ProjErsättning, Telefon Anstnr, Deltagandegrad ProjErsättning Anstnr Telefon a) Ange vilken normalform den resulterande relationen (med angiven primärnyckel) är i. Motivera ditt svar! (2 poäng) Relationen är i 1FN (alla attribut är atomära) men inte i 2NF. Detta pga att attributet Telefon är beroende av bara halva primärnyckeln ( Anstnr ). b) Föreslå nedbrytning (-ar) av relationen R som resulterar i relationer i BCNF. I svaret bör namnet på varje ny relation anges, de ingående kolumnerna namnges, primärnyckel för varje tabell anges, samt eventuella främmande nycklar. Utför normaliseringen steg för steg, d v s gå från en normalform till närmast högre, motivera varför nedbrytningen gjorts/inte gjorts och så vidare. För att komma till 2NF bryter vi ut Telefon tillsammans med sin determinant Anstnr till en ny relation: TELEFON Anstnr Telefon Kvar blir PROJEKT Projnummer, Anstnr, Deltagandegrad, ProjErsättning Anstnr i PROJEKT utgör främmande nyckel mot tabellen TELEFON. Nu är vi i 2NF men inte i 3NF. Detta pga att det finns ett transitivt beroende mellan nyckeln i relatoionen PROEJEKT och attributet Projersättning. Projnummer, Anstnr ProjErsättning Projnummer, Anstnr Deltagandegrad Projnummer, Anstnr Anstnr Projnummer, Anstnr Anstnr, Deltagandegrad. Därav följer att Projnummer, Anstnr Anstnr, Deltagandegrad ProjErsättning. {Anstnr, Deltagandegrad} utgör inte kandidatnyckel eller delmängd av en sådan. Mao vi har ett transitivt beroende. För att hamna i 3NF bryter vi ut det som orsakade brottet mot 3NF, dvs attributet Projersättning och dess determinant Anstnr, Deltagandegrad till en ny relation: ERSÄTTNING: Anstnr, Deltagandegrad, Projersättning

Kvar i PROJEKT blir PROJEKT Projnummer, Anstnr, Deltagandegrad {Anstnr, Deltagandegrad} i relationen PROJEKT utgör främmande nyckel mot relationen ERSÄTTNING. (3 poäng) c) Motivera varför det är önskvärt med normaliserade relationer, exemplifiera gärna med resultatet i uppgift b) ovan (eller med andra exempel). Finns det några nackdelar med att normalisera? Att underlätta att hålla databasen konsistens är det viktigaste skälet för normalisering. Ett fakta på endast ett ställe gör att det blir enklare att underhålla databaser, framför allt map uppdateringar, borttag och inlägg. Sk. uppdateringsanomalier inträffar vid för lågt normaliserade tabeller. Ett exempel är om man lagrar telefonnummer till en lärare i en tabell som handlar om de kurser denna lärare har.tar man bort den sista kursen en lärare har försvinner även alla personuppgifter om läraren. Får läraren en nytt telefonnummer måste man ändra i alla kurstupler där denna lärare förekommer. Etc. En annan fördel är att databasen (oftast) blir mindre utrymmeskrävande. Även om man faktiskt inför en viss kontrollerad redundans i form av främmande nycklar så kommer utrymmet för dessa data att ta mindre plats jämfört med att lagra redundant information som t ex i exemplet med kurser och telefonnummer ovan. Har man långa nycklar i kombination med korta övriga attribut och få rader i tabellerna kan dock databasen ta större plats att lagra om man normaliserar. Att joina tabeller tar dock tid, i en övernormaliserad databas (där man t ex lagrar allt i binära tabeller med nyckeln plus endast ett attribut till) måste man läsa samman flera tabeller för att sammanställa information som gäller en användarfråga som spänner över flera tabeller. Detta tar vanligen längre tid och kräver mer komplicerad optimering än att hämta data från endast en tabell. (3 poäng) Uppgift 5 Exemplifiera första, andra och tredje ordningens feedback. Du kan välja att illustrera via ett enda exempel-system där alla de nämnda typerna av feedback förekommer, eller helt enkelt skissa tre olika situationer där en eller flera typer av feedback förekommer. I svaret bör du förklara vad som kännetecknar de olika typerna av feedback och hur detta manifesterar sig i de exempel du valt.

Två lösningar stod i en klass för sig: Gunnars godiskiosk och aktiviteterna i ett stålverk, här kommer godiskiosk-förslaget (courtesy of Lars Holmberg): Gunnars Godiskiosk har ett mycket fördelaktigt medlemspris på 2:90/hg för lösgodis. För att bli medlem i Godiskioskens Vänner måste man dock handla för minst 500 kr per halvår. De kunder som ansöker om medlemskap får av Gunnars Automatiska Deterministiska Godis-Entreprenörs- Greja (GADGET) vänligt men bestämt avslag om de inte handlat för så mycket det senaste halvåret, och uppmanas att handla mer och ansöka igen senare. Denna typ av återkoppling är ett exempel på första ordningens feedback. Karaktäristiskt för denna typ av feedback är att avvikelser från systemets förutbestämda mål, (handla för minst 500 kr halvåret), dämpas genom negativ feedback, dvs kundens input till systemet, godissumman, jämförs med målet, och alla avvikelser justeras mot målet (ingen rabatt om inte godisinköpen ökar). GADGET har även möjlighet att ta hänsyn till om den ansökande händelsevis spelar mycket på flipperspelet utanför kiosken (som Gunnar också äger). Om så är fallet kan den släppa igenom en ansökan som inte fullt uppfyller graden av godissugenhet per halvår. Denna typ av återkoppling (som är av andra ordningen) förutsätter att systemet har någon typ av minne och alltså även håller reda på hur det gått med andra faktorer än bara det ursprungliga jämförelseobjektet (köpta godissumman) och har möjlighet att ändra (positiv feedback som alltså förstärker avvikelser från målet) målet, önskvärd godissumma, i enlighet med ett antal förutbestämda alternativa mål. Gunnar har också planer på att införa en funktion som påminner medlemmar om att de kommer att förlora sitt medlemskap till nästa halvårsperiod om de inte handlar si och så mycket mer godis till halvårsskiftet. Påminnelserna ska givetvis skickas ut med diskret avsändare ( Gretas Gravyr ) så att kunder som inte vill skylta med sina godisinköp inför brevbärare och grannar skonas. Detta förfarande är ett exempel på så kallad feedforward, som kan ingå i feeback-system av tredje ordningen. Karaktäristiskt för feedforward är att systemet försöker undvika målavvikelser redan innan de uppstår (alltså innan man genomför komparationen mellan jämförelseobjekt och mål). Andra karaktäristika för tredje ordningens feedbacksystem är att systemet har möjlighet att omstrukturera målet till andra alternativ än bara sådana som är förutbestämda. Även detta förutsätter att systemet har ett minne och till yttermera visso kan använda lagrad information för att skapa nya mål. Denna typ av feedback, som är typisk för maskininlärningssystem där systemet lagrar systemanvändarens feedback och använder informationen för att skapa nya sätt att exekvera, är dock ännu inte implementerad i GADGET. (6 poäng)