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

Transkript

1 Institutionen för Data- och Systemvetenskap SU/KTH Maria Bergholtz Exempel-tentamen + Lösningsförslag Inga hjälpmedel är tillåtna. Skriv bara på en sida av pappret Skriv namn på varje papper Skriv läsligt, annars är det svårt att rätta tentamen

2 Uppgift, 0p. A) KONSTRUERA ETT KONCEPTUELLT SCHEMA (FÖRSLAGSVIS ETT UML KLASSDIAGRAM) som ger möjlighet att representera samtliga utsagor nedan. Ange avbildningsregler (eng. cardinality constraints) för samtliga associationer: Pennor finns av typen billig blyerts, kulspets typ I och kulspets typ II. Billiga blyertspennor kostar alla max 5 kr styck. Kulspets typ I och II kostar vadsomhelst och förekommer i flera färger. Pennorna av typen blyerts-penna säljs endast i en färg, lite blekt gul. Kulspetspennor av typ II tillverkas i både guld, silver och rostfritt stål. TypI-kulspetspennorna endast i rostfritt stål. Kulspetspennor består av en patron och ett hölje. Patroner finns för bläck respektive vanlig färg. Kulspetspennorna av typ II kan förses med både bläck- och vanlig färgpatron. Pennorna av typ I (kulspets de också) tillverkas bara för färgpatroner. Pennor (inklusive patron) och patroner säljs av diverse företag. Företaget Solna-pennan sålde två billiga kulspetspennor och kulspetspenna av typ II med bläckpatron till Lisa Andersson 2 mars Företaget Djurgårdens penn-gross sålde en bläckpatron, en blyertspenna och en kulpenna av typ I till Oskar Nilsson 2 mars 200. Djurgårdens penn-gross tar 4 kr för billiga blyertspennor, 20 kr för kulpennor av typ I, 40 kr för kulpennor av typ II med färgpatron och 80 kr för kulpennor av typ II med bläckpatron. Vanliga färgpatroner kostar 0 kr att köpa separat och en bläckpatron som säljs separat kostar 50 kr. Solna-pennan tar 5 kr för billiga blyertspennor, 20 kr för kulpennor av typ I, 45 kr för kulpennor av typ II med färgpatron och 70 kr för kulpennor av typ II med bläckpatron. Enskilda bläckpatroner kostar här 40 kr och vanliga färgpatroner 5 kr. Modellera på ett sådant sätt att partiella attribut och associationer undviks! ( Ett attribut är partiellt om dess min-värde = 0, en association kan sägas vara partiell om båda dess roller har ett min-värde som är lika med 0). (6p) B) Kravspecifikationen ovan innehåller ett antal regler. Hur bör/kan dessa regler modelleras/implementeras? I det konceptuella schemat? I databasen? I kontroll-kod? Motivera ditt svar! Lösningsförslag:

3 PRODUKTTYP FÖRETAG KUND Namn :.. 0..* PRISRAD Pris :.. Namn :....*..* Namn :....* PATRONTYP PENNTYP KÖP avser Datum :.. Totalpris :.. 0..*..* BLÄCKPAT RON FÄRGPA TRON BLYERTS TYP KULSPETSTYP Möjliga_färger :..* ORDERRAD Antal :.. ingår_i ingår_i 0..* ÖVRIGA ÄDLAKULSP ETSAR KULSPETSRAD Färg :.. Metall :.. Patron : Boolean 0..* Rättning och svar på b)-uppgiften: Detta schema är rätt stort (man behöver inte ha det så stort för full poäng) och försöker modellera rätt många regler (men inte alla). Notera hur regeln om att blyertspennor inte har färger har lett till att PENNTYP delats upp i BLYERTSTYP och KULSPETSSTYP. Där den sista har ett antal möjliga färger som egenskap. Man hade kunnat gå vidare här och modellera upp olika FÄRGYTYPER och olika KULSPETSTYPER. Och sen låtit typ-ii-pennorna ha en association till alla färger medan typi-pennorna bara kunde ha metallfärg. Notera vidare hur regeln om att vissa kulspetspennor kan ha alla typer av patroner medan vissa bara kan ha färgpatroner har lett till att KULSPETSTYPER delats upp i två subtyper. Där vissa associeras till supertypen av PATRONoch därmed alltså kan relateras till både BLÄCKPATRONER och FÄRGPATRONER) medan ÖVRIGA bara är associerade till FÄRGPATRON:er. Ett alternativ till ovan hade varit att inte dela upp KULSPETSTYP:erna (och PATRONTYP:erna) i olika subtyper (se nedan) PRODUKTTY P Namn :.. ingår_i PENNTYP PATRONTYP Vilka_färger :..* Typ_av_patron :.. 0..*Vilka_material :..* och istället haft bara en association mellan PENNTYP och PATRONTYP. Då hade man istället fått implementera regeln om vilka pennor som kunde ha vilka patroner i tex databasen som en trigger (som körs när man gör INSERT på antingen PENNTYP eller PATRONTYP eller båda). Alternativt, och som sista alternativ, implementerat regeln i kontrollkod i något gränssnitt som arbetar mot databasen. Vanligen är detta det sämsta alternativet. Detta eftersom man dels här inte har något stöd för implementering av sådana regler (vilket man har

4 i databasen), dels för att regeln implementeras senare i (system-) utvecklingskedjan och kanske av andra personer än de som modellerade databasen. Med större risk för fel och konsistensproblem. Fördelen med den andra lösningen är att schemat blir mindre och därmed mer översiktligt, antalet subklasser utan attribut blir färre. Med andra ord, nackdelen med att implementera regler som jag gjort i det konceptuella schemat (det större schemat alltså) är att schemat blir större och många klasser får inga egna attribut (men väl olika egna associationer). Det kan gör schemat mer oöverskådligt. Det behövs inte heller många regler förrän strukturer med multipelt arv måste införas, vilket logiskt är helt ok, men som fysiskt kan ge problem vid implementering eftersom inte alla miljöer stöder multipelt arv. Övrigt om schemat ovan. Man behöver skilja på template-nivå (som här har blivit PENNTYPER och PATRONTYPER osv.) och nån slags konkret nivå av enskilda pennor (som här har blivit ORDERRAD, men man kan även dela upp det i PENNA, PATRON osv. ). Man behöver också en klass för att hålla reda på att ett KÖP sker (kan kallas KÖP, ORDER eller vad man vill) som relaterar till ett FÖRETAG och en KUND. Sist och slutligen vill man kunna se vad en viss produkt kostar hos ett visst företag, även innan KÖP inträffar. Därav relationsobjektet PRISRAD (inte så bra namn) mellan PRODUKTTYP och FÖRETAG. Uppgift 2, 8p. Betrakta följande konceptuella schema. de konceptuella schema. ALFA a a2..* BETA b b2 b3 b4..*..* DELTA d..* d2 d3..*..* GAMMA c..* ALFA identifieras av attributet a. BETA identifieras av sin association till ALFA samt attributen b och b2. GAMMA identifieras av sin association till BETA samt attributet c. DELTA identifieras av attributen d och d2.

5 ÖVERSÄTT DET KONCEPTUELLA SCHEMAT OVAN TILL ETT RELATIONSDATABASSCHEMA. Ange för varje relation vad som utgör primärnyckel samt vad som eventuellt utgör främmande nycklar (främmande nycklar måste specificeras med alla korrekta kolumner). I fallet främmande nycklar skall även specificeras mot vilken relation de utgör främmande nyckel. Översättningen får ej innebära att avsteg från den konceptuella modellen görs (annat än de avsteg som måste göras för att realisera relationsmodellen). Surrogatnycklar får inte införas. Använd följande notation med understrykning av primärnycklar: PERSON(namn, adress, telnr), HUND(hundid, ägarnamn, ägaradress, ras) Relationen HUND innehåller ett attribut benämnt ägare som utgör främmande nyckel mot tabellen PERSON. Detta skrivs på följande sätt: HUND.(ägarnamn, ägaradress) << PERSON.(Namn, adress) där Namn, adress utgör primärnyckel i tabellen PERSON. ALFA(a, a2, d, d2) BETA(a, b, b2, b3, b4) GAMMA(a, b, b2, c, a, b, b2, c) DELTA(d, d2, d3) BD(a, b, b2, d, d2) BD2(a, b, b2, d, d2) ALFA.(d, d2) << DELTA(d, d2) BETA.a << ALFA.a GAMMA.(a, b, b2) << BETA(a, b, b2) GAMMA.(a, b, b2, c) << GAMMA(a, b, b2, c) BD(a, b, b2) << BETA(a, b, b2) BD(d, d2) << DELTA(d, d2) BD2(a, b, b2) << BETA(a, b, b2) BD2(d, d2) << DELTA(d, d2) Uppgift 3, 7p. a) Beskriv data-abstraktionen power type relationships ( template-copy-relationships ). I din beskrivning ska ingå vad abstraktionen innebär, ett exempel och en motivering till när man ska använda denna typ av relation i databasl modellering. Logiska fördelar: Powertypes medför en abstraktionsnivå som hjälper till att placera rätt attribut på rätt klass eller tabell. Notera att i detta fall vinner vi oftast mindre i termer av att slippa partiella attribut (varje DJUR har en DJURART och därmed exakt en medelvikt och så vidare) men genom att analysera den information vi ska lagra med hjälp av power-types (alltså vad som kan tänkas vara abstrakt/beskrivning av ett fenomen och vad som utgör fenomenet självt) skapar men helt enkelt mera korrekta klasser. Där korrekt avser att en klass ska utgöras av en grupp av attribut som berör ett specifikt fenomen. En annan fördel är att då vi skiljer på både power-typen och det den bestämmer (ibland benämnt copy ) syns ju dessa klasser i kraft av egna namn vilket gör dem lättare för en domänkunnig att validera. Logiska nackdelar: Ett konceptuellt schema skulle potentiellt kunna bli för detaljerat och explodera i power-typesrelationer av för hög granularitet. Jag skulle dock vilja påstå att risken är mindre för detta än för isa-relationer.

6 b) Beskriv data-abstraktionen isa-relationships. I din beskrivning ska ingå vad abstraktionen innebär, ett exempel och en motivering till när man ska använda denna typ av relation i konceptuell modellering. Logiska fördelar: Logiskt distribuerar man ut attribut som bara hör till vissa (delmängder av) klasser på ett korrekt sätt vilket leder till att man slipper ha partiella attribut i modellen (och sen inte NULL-värden i den fysiska databasen), vilket är en fördel i sig. Vidare syns informationen om delmängder av klasser på ett bättre sätt då dessa ges egna namn (tex KATT och HUND istället för bara en klass DJUR) och kan därmed enklare valideras mot användare som kan domänen. Isa-relationer gör dessutom modellen flexiblare, läs enklare att bygga ut (vid förändringar/nya användarkrav) (svårt att säga om detta är en logisk eller fysisk fördel). Logiska nackdelar: Nackelen logiskt är att modellen lätt exploderar i mängder av isa-relationer där varje klass kanske bara skiljer sig i ngt enstaka attribut, vilket gör den konceptuella modellen oöverskådlig och rörig. Förutsätter man dessutom att multipelt arv existerar (vilket det ju gör i den verklighet som vår modell ska avspegla) utvecklas modellen lätt till ett latice (nät) av korsande isa-relationspilar. Användande av vyer löser i och för sig (nästan ) upp detta problem. c) Påverkar användandet av power types i modellering av databaser, prestanda för samma databas? Motivera ditt svar i termer av rum (hur stor plats databasen tar) och tid (tid det tar att läsa en godtycklig del av databasen). Fysiska fördelar: UTRYMMESVINSTER. Som vissa noterat utgör eg. powertype-kopia en nedbrytning liknande den vid normalisering. Ta exemplet med ART DJUR. Om ART utgör power type mot DJUR (kopian) kan vi anta att antalet instanser av DJUR vida överstiger antalet instanser av ART. Att då slippa lagra tex en stor beskrivning av ART:en påv varje enskild DJUR (-rad) i en databas ger betydande utrymmes (och konsistens) -vinster. Fysiska nackdelar: Skiljer sig de power-type och kopia åt bara i ngt enstaka attribut kan utrymmesvinsterna vändas till utrymmesförluster (om främmande nycklarna större än längden på de attributvärden som bara finns hos enstaka klass tillsammans med de administrativa utrymmen som behövs för metadata om de olika klasserna). Join-problematik, distribuerar man information mellan olika tabeller så tar det längre tid när man sen ska läsa samman dem (om en transaktion kräver att man gör det). d) Påverkar användandet av isa-relationer i modellering av databaser, prestanda för samma databas? Motivera ditt svar i termer av rum (hur stor plats databasen tar) och tid (tid det tar att läsa en godtycklig del av databasen). Fysiska fördelar: Fysiskt gör isa-relationer som sagt att vi slipper NULL-värden vilket påverkar databasen positivt med tanke på konsistens och i bästa fall även något mindre outnyttjat utrymme. Fysiska nackdelar: Relationsdatabaser implementerar arv på ett lite klumpigt sätt via främmande nycklar. Skiljer sig de olika sub-klasserna åt bara i ngt enstaka attribut kan utrymmesvinsterna vändas till utrymmesförluster (om främmande nycklarna större än längden på de attributvärden som bara finns hos enstaka klass tillsammans med de administrativa utrymmen som behövs för metadata om de olika klasserna). Däremot får man lite oönskade effekter vad gäller svårigheter vid sökning. Dvs med isa-relationer så kommer ett antal joins att behövas jämfört med om man lagrat all information i samma tabell. Uppgift 4, 0p. Betrakta följande relationsschema (och motsvarande kod för relationsschema) som är i NF: TENTAMENSRESULTAT(Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum, Maxpoäng, Antal_poäng, Personnummer) CREATE TABLE TENTAMENSRESULTAT(Kursstart Date not null, Kursslut Date not null, Kursbeskrivning char(500) not null, Tentamensdatum Date not null, Maxpoäng integer not null, Antal_poäng integer not null, Personnummer char() not null, Primary key(kursstart, Kursslut, Kursbeskrivning, Tentadatum, Personnummer)) Utrymme datatyper: Datatypen char upptar byte per tkn som är definierat, en char(6) upptar 6 byte.

7 Datatypen integer upptar 4 byte Datatypen date upptar 8 byte Följande funktionella beroenden råder: Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum, Personnummer Antal_poäng, Maxpoäng Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum Maxpoäng a) Normalisera TENTAMENSRESULTAT till 3NF. Motivera ditt svar så att det framgår varför normaliseringen gjorts! Krav på lösning: tabellnamn, primärnyckel, eventuella främmande nycklar, motivering. Förslag till lösning: Tabellen ovan är inte i 2NF pga att det finns ett partiellt funktionellt beroende mellan Maxpoäng och primärnyckeln. Alltså bryter man ut Maxpoäng plus den determinant som bestämmer Maxpoäng (dvs vänster-ledet i det funktionella beroendet Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum Maxpoäng) till en egen tabell. Kvar i den gamla tabellen blir primärnyckeln plus Antal_poäng. TENTA(Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum, Maxpoäng) TENTARESULTAT(Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum, Personummer, Antal_poäng) TENTARESULTAT.(Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum) << TENTA(Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum) b) Vilka effekter kommer normaliseringen ha på databasens prestanda i detta fall? Motivera ditt svar i termer av de nedbrytningar du gjort i a) Man minskar redundansen vilket har positiva effekter på skrivningar mot databasen (i detta fall behöver man tex bara uppdatera maxpoäng på ett ställe per tentamen i tabellen TENTA (om man nu skulle få för sig att ändra antalet poäng som var max på en tenta), istället för att som förut ändra på varje rad där en student skrivit en TENTA i tabellen TENTAMENSRESULTAT). För läsningar mot databasen blir det oftast värre, eftersom en godtycklig transaktion förmodligen involverar fler tabeller = fler joins behöver göras = fler sekundärminnesaccesser = längre transaktionstider. De transaktioner som bara går mot endera tabellerna TENTA och TENTAMENSRESULTAT kan dock förväntas gå snabbare även i normaliserat tillstånd sas. Vad gäller rum så tar en normaliserad databas oftast mindre plats eftersom redundansen minskar, detta givet att tabellerna är någorlunda stora och/eller att antalet främmande nycklar som normaliseringen ger upphov till är kortare än de kolumner som annars skulle dubbellagrats. I just det här fallet är detta villkor förmodligen inte uppfyllt. Dvs vi vinner förvisso i plats i termer av att Maxpoäng bara lagras en gång för varje tenta, men denna vinst äts med råge upp av att vi måste dubbellagra den mycket långa främmande nyckeln (Kursstart, Kursslut, Kursbeskrivning, Tentamensdatum), där just Kursbeskrivning är speciellt problematisk (läs mycket lång i förhållande till övriga kolumner). Blir antalet rader (studenter) stort (vi vinner 4 byte per student i termer av att Maxpoäng inte dubbellagras) så kommer vi förr eller senare (25 studenter väger upp just dubbelllagringen av Kursbeskrivning) att vinna i plats ändå. Diskussion om surrogatnycklar är på sin plats här, självklart vore det en bättre lösning, inte bara av prestandaskäl utan också av redundans och därmed uppdateringsskäl. Uppgift 5, 0p. Betrakta följande relationsschema LAND(Landsnamn, Antal_innevånare) STAD(Stadsnamn, Landsnamn, Antal_innevånare) PERSON(Namn, Adress, Telefon) BESÖK(Namn, Stad, Land)

8 (primärnycklar i fet stil) STAD.Landsnamn << LAND.Landsnamn BESÖK. (Stad, Land) << STAD.(Stadsnamn, Landsnamn) BESÖK.Namn << PERSON.Namn a) Formulera följande fråga i SQL: Vad är invånarantalet i det land som besökts av flest personer? CREATE VIEW antal_besök AS (SELECT Land, COUNT(Namn) AS antal FROM BESÖK GROUP BY Land) SELECT Antal_innvånare FROM LAND, antal_besök WHERE Land = Landsnamn AND antal = (SELECT MAX(antal) FROM antal_besök) b) Formulera följande fråga i relationsalgebra: Vilka personer har aldrig besökt Sverige men i övrigt besökt alla andra länder. Sverige_besökare π (Namn) (σ Land= Sverige (BESÖK)) Besökt_alla_utom_Sverige π (Namn) ((π (Namn, Land) (BESÖK)) (σ Land <> Sverige (LAND)) SVAR Besökt_alla_utom_Sverige - Sverige_besökare Uppgift 6, 5p. Betrakta följande två tabeller (relationsscheman): PERSON(Namn, Adress, Telefon) HUND(HundId, ÄgarNamn, ÄgarAdress, Vikt, Färg) Där (Namn, Adress) utgör primärnyckel för tabell PERSON och HundId utgör primärnyckel för tabell HUND. Och där (ÄgarNamn, ÄgarAdress) utgör främmande nyckel från tabellen HUND mot tabellen PERSON. Vidare gäller följande verksamhetsregel:: Alla HUND:ar har en ägare. Om någon uppdaterar databasen i termer av att ta bort (göra DELETE) på en viss rad i tabellen PERSON ska även motsvarande rader i tabellen HUND tas bort. Rent allmänt gäller förstås att databasen alltid ska vara konsistent dvs bla upprätthålla entity och referential integrity. Det kan tex ta sig uttryck som regler av typen: Om någon uppdaterar databasen i termer av att ändra en persons Namn och/eller Adress så ska motsvarande rader i tabellen HUND också uppdatera? Uppgift: Definiera två CREATE TABLE-sats som implementerar tabell PERSON och HUND respektive. Satsen ska inkludera de båda verksamhetsreglerna ovan. CREATE TABLE PERSON(Namn varchar(50) NOT NULL, Adress varchar(25) NOT NULL, Telefon integer, primary key(namn, Adress)) CREATE TABLE HUND(HundId varchar(25) NOT NULL, ÄgarNamn varchar(25) NOT NULL; ÄgarAdress varchar(50) NOT NULL, Vikt integer NOT NULL, Färg varchar(0) NOT NULL, primary key(hundid), foreign key(ägarnamn, ÄgarAdress) REFERENCES PERSON(Namn, Adress) ON DELETE CASCADE ON UPDATE CASCADE)