Institutionen för Data- och Systemvetenskap SU/KTH Maria Bergholtz Tentamen 2I033, IT i Organisationer och Databasteknik lördag 7/4 2004, kl. 0 5 LÖSNINGSFÖRSLAG Inga hjälpmedel tillåtna. Skriv bara på en sida av pappret Skriv namn på varje papper Skriv läsligt, annars rättas inte tentamen Lycka till!
Tenta Sidan 2 av 4 Uppgift KONSTRUERA ETT KONCEPTUELLT SCHEMA som modellerar verksamheten hos en ridskola. Schemat ska möjliggöra representation av samtliga typer av utsagor nedan: Ridskolan erbjuder ridlektioner till elever. Ridlektioner leds av en ledare. Lisa och Kalle arbetare som ledare på ridskolan. Anna och Olle är elever på ridskolan. Olle väger 6 kg, Lisa väger 55 kg. Ridlektionen 2 december kl. 3 kl. 4 går av stapeln i sal A. Det går även en ridlektion i sal A kl. 6 7 2 december. Sal B används för lektionen 23 december. Lisa är bokad som ledare till ridlektionen som går 2 december kl. 3 kl. 4. Hästen Darley Arabian rids av Olle på ridlektionen 2 december. Darley Arabian rids av Anna på ridlektionen 22 december. Anna rider Bayerly Turk på lektionen 23 december. Anna rider Ego Boy på lektionen 2 december. Kalle ledde ridlektionen som gick 2 december kl. 3 kl. 4 (pga att Lisa blev sjuk) Darley Arabian är ett arabiskt fullblod (mankhöjd.62). Ego Boy är en ponny av rasen Connemara. Ego Boy har en mankhöjd på.35 men Connemara-ponnyer i allmänhet har en mankhöjd som ligger 0 cm lägre. Arabiska fullblod kan ridas av alla oberoende av vikt. Ponnyer kan ridas av personer som väger mindre än 60 kg. 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! (8 p)
Tenta Sidan 3 av 4 PERSON Namn :.. Pnr :.. Adress :.. 0..* ÄNDRING Från :.. Till :.. Orsak :.. 0.. ELEV Vikt :.. utförd_ledning LEDARE planerad 0..* LEKTION Datum :.. Från :.. Till :.. 0..* RIDNING..* 0..* HÄST HÄSTTYP Namn :.. Ras :.. Mankhöjr :.. 0..* Snittmankhöjd :.. PONNY MaxAntalKilo :.. ÖVRIGA Schemat ovan får väl sägas vara en minimal lösning. Rättning: Den stora stötestenen verkar ha varit klassen RIDNING (också benämnd lektionstillfälle, närvaro etc.). Denna klass fanns tyvärr inte med i de flestas scheman. Vilken den måste göra. Det räcker alltså inte att relatera hästar, elever etcetera till en och samma ridlektion. Man måste ju också hålla reda på vem som red vilken häst på denna lektion. Klassen RIDNING är egentligen ett relationsobjekt mellan tre klasser: LEKTION, ELEV och HÄST. Sen skulle man även hålla reda på vem som lett en lektion. Det kunde bli så att den som var planerad att leda inte gjorde det och i så fall vill man se det också. Här finns flera möjliga lösningar som alla har det gemensamt att klassen LEKTION modelleras via två klasser. Dels LEKTION, dels någon annan klass som antingen modellerar den bokade lektionen eller en klass som modellerar den fullbordade lektionen (det är inte så hankigt om man väljer det ena eller andra). Så någon typ av klass (kanske kallad bokad_lektion, fullbordad_lektion eller helt kort och gott ändring) behövs förutom LEKTION. HÄST och HÄSTTYP verkar de flesta ha modellerat. Man bör här skilja på egenskaper hos arten, t ex snitt-mankhöjd och egenskaper hos den enskilda hästen, t ex mankhöjd. Eventuellt kan man dela upp HÄSSTYP:en i PONNY:er och ÖVRIGA. Eftersom just ponnyer hade en maxvikt som de klarar av. Man kan även lägga den egenskapen i HÄSTTYP och strunta i ponnyer och övriga. Notera att relationer mellan klasser visas via associationer med namn och avbildningsregler, inte via attribut. Uppgift 2
Tenta Sidan 4 av 4 a) Konstruera en tabell som är i 2NF men inte är i 3NF. (2p) Lösningsförslag: KURS(KursId, Antal-poäng, Ansvarig, Ansvarig-telefon) 2i033, 8, Olle, *62, 4, Olle, *58, 4,. Stina, 2345 2i034, 4, Nasrin, 22222 DSV:DB, 4, Peter, 33333 Följande funktionella beroenden gäller: KursId Antal_poäng, Ansvarig, Ansvarig-telefon Ansvarig Ansvarig-telefon Eftersom KursId Ansvarig och Ansvarig Ansvarig-telefon och Ansvarig inte utgör en kandidatnyckel så har vi ett transitivt beroende mellan primärnyckeln och ett ickenyckelattribut. Således bryter vi mot 3NF. Eftersom vi har in icke-sammansatt primärnyckel så måste vi vara i 2 NF (förutsatt att vi är i åtminstone NF). Alla attribut är atomära i databasen ovan, således är vi i NF. b) Konstruera en tabell som är i 3NF men inte i BCNF (2p) VIKTER(Typ, Viktklass, MaxVikt), PN är nu sammansatt. Pudel, A 25 Pudel B 25 Pudel C 60 Tax A 0 Tax C 20 Typ Viktklass MaxVikt Maxvikt Typ Vi har inga transitiva beroenden och inget attribut som bara är beroende av en del av primärnyckeln. Inga icke-atomära attribut finns. Således är vi i 3NF. Vi är dock inte i BCNF eftersom det finns en determinant som inte kan utgöra kandidatnyckel, nämligen Maxvikt. För både a) och b) gäller att ni både ska definiera tabellen (namn, kolumner och primärnyckel) samt lista minst 5 exempel-rader för varje tabell. Plus definiera funktionella beroenden som gör att tabellen är eller inte är i en viss normalform. Motivera alla svar. c) Överför, med utgångspunkt från svaret i a) och b) respektive tabell till 3NF respektive BCNF. Lista de nya raderna för de nya tabellerna. Ange nya tabellnamn, primärnycklar och främmande nycklar. (2p) Lösningsförslag: KURS(KursId, Antal-poäng, Ansvarig 2i033, 8, Olle *62, 4, Olle *58, 4,. Stina 2i034, 4, Nasrin
DSV:DB, 4, Tenta Sidan 5 av 4 Peter TELEFON(Ansvarig, Ansvarig-telefon) Olle Stina 2345 Nasrin 22222 Peter 33333 Vi bröt ut determinanten (Ansvarig) och det den bestämde till en ny tabell TELEFON. Nu gäller att TELEFON. Ansvarig utgör främmande nyckel mot KURS.Ansvarig. Båda tabellerna uppfyller nu 3NF. Vidare skapar vi två nya tabeller för att lösa upp BCNF-problematiken: VIKTER(Typ, MaxVikt) Pudel 25 Pudel 60 Tax 0 Tax 20 VIKTER2(MaxVikt, Viktklass) 25 A 25 B 60 C 0 A 20 C Nu är alla determinanter för respektive tabell kandidatnycklar (eller snarare valda primärnycklar). Vidare gäller nu att VIKTER2.MaxVikt utgör främmande nyckel mot VIKTER.MaxVikt. d) Med utgångspunkt från svaren i a), b), c): Motivera varför man normaliserar! Exemplen bör innefatta det ni gjort i uppgift a-c. Finns det något som talar mot att normalisera? Man normaliserar för att undvika redundans. Varje faktum på ett ställe. Om vi tar exemplet med KURS-tabellen så var man i det första fallet tvungen att varje gång en lärare gav en kurs upprepa vilket telefonnummer den läraren har. Vilket leder till risk för inkonsistens. Dvs om man ändrar telefonnummer på en lärare måste man ändra i alla rader där den läraren förekommer. En positiv bieffekt av normalisering är att databasen oftast tar mindre plats. I exemplet ovan så vinner vi på att vi bara behöver tala om vilket telefonnummer en lärare har på EN rad istället för på varje kurs-rad där läraren förekommer. Givet att antalet rader är någorlunda stort så kommer detta att leda till utrymmesvinster. Nackdelen med normalisering är att vi förlorar i tid, dvs det tar längre tid att söka i databasen eftersom vi oftare måste joina tabeller när informationen är spridd över flera tabeller. (2p)
Uppgift 3 Tenta Sidan 6 av 4 Skriv en kort (max 50 rader) redogörelse för hur begreppen SCM, CRM, Decision Support Systems, Management Information Systems och Transaction processing system relaterar till begreppet e-business. (8p) Här har jag inte gjort något specifikt lösningsförslag. Både SCM, CRM, e-business och de olika typerna av informationssystem finns definierade på föreläsningsbilderna. Rättning: Bra beskrivningar av SCM; CRM, TPS, MIS och DSS ger max 4 poäng. Relatering till e-business av dessa begrepp ger vidare poäng upp till 8. Uppgift 4 Betrakta följande tabeller: SJUKHUS(Namn, Gata, Postnummer, Postadress) KLINIK(Knamn, Snamn, Sgata, Spostnummer, Spostadress, Ansvarig) VÅRDPLATS(Vpnr, Knamn, Snamn, Sgata, Spostnummer, Spostadress, Ickerökare) PERSON(Pnr, Namn, Gata, Postnummer, Postadress, Telefon) INSKRIVNING(Personnummer, Datum, Tid, Vårdplats, Klinik, Sjukhus, Sgata, Spnr, Spadr) Primärnycklar är angivna i fetstil. KLINIK.(Snamn, Sgata, Spostnummer, Spostadress) << SJUKHUS. (Namn, Gata, Postnummer, Postadress) VÅRDPLATS(Knamn, Snamn, Sgata, Spostnummer, Spostadress) << KLINIK.( Knamn, Snamn, Sgata, Spostnummer, Spostadress) INSKRIVNING.Personnummer << PERSON.Pnr INSKRIVNING. (Vårdplats, Klinik, Sjukhus, Sgata, Spnr, Spadr) << VÅRDPLATS.(Vpnr, Knamn, Snamn, Sgata, Spostnummer, Spostadress Med uttrycket Tabell.Kolumn << Tabell2.Kolumn2 avses att Kolumn i Tabell utgör främmande nyckel mot primärnyckeln (Kolumn2) i Tabell2. a) Definiera begreppet surrogatnyckel. (2p) En surrogatnyckel är en konstgjord identifierare som genereras av databashanteringssystemet för att tjäna som identifierare av en rad. Begreppet utsträcks ibland till även betyda användardefinierade konstgjorda nycklar, dvs en extra kolumn som införts av användaren (med användaren avses här den person som definierar en databas) oftast av typen heltal (eller räknare ) som identifierar en rad i en tabell. b) Finns det några surrogatnycklar i schemat ovan? Motivera ditt svar oberoende om du tycker att svaret är ja eller nej. (2p) JA eller NEJ godtas förutsatt att rimlig motivering ges. Lösningsförslag nedan. JA: Begreppet personnummer kan ses som en konstgjord identifierare, avsedd att identifiera begreppet PERSON. Om vi nu har en tabell PERSON skulle vi kunna se kolumnen Personnummer som en surrogat-nyckel. Detta eftersom personnummer inte svarar mot något riktigt egenskapsvärde, utan just tillkommit för att identifiera en person.
Tenta Sidan 7 av 4 NEJ: Det finns inga konstgjorda identifierare i databasschemat ovan. Alla kolumner svarar mot riktiga identifierade egenskaper i domänen. Även begreppet personnummer får numera anses vara en egenskap så god som någon (i klass med namn, vikt, adress etc) vad gäller begreppet PERSON. c) Ange vilka typer av så kallade key business rules, dvs regler för främmande nycklar (ange såväl DELETE- som UPDATE-regler) som du tycker ska gälla för främmande nyckel-förhållandet mellan INSKRIVNING och VÅRDPLATS. Dvs. vad ska hända med raderna i INSKRIVNING om man tar bort/uppdaterar en VÅRDPLATS? Motivera ditt svar genom att beskriva vad som är problemet och föreslå lösning! Lösningen kan ges i kod (CREATE TABLE-sats) eller bara förklaras i naturligt språk! (4p) ON DELETE RESTRICT: En vårdplats ska inte tas bort om det finns inskrivningar som pekar på vårdplatsen. Här kan man fundera i termer av hur många inskrivningar som ska hållas aktuella? Eftersom det förmodligen är viktigt med historik så borde egentligen aldrig en vårdplats som någonsin hyst någon person få tas bort. ON UPDATE CASCADE: Antingen tycker man att om en vårdplats ändrar namn så ska denna ändring propageras ner till inskrivningen. Eller också tycker man att inga vårdplatser som har folk inkrivna (eller har haft folk inskrivna) ska få ändras (ON UPDATE RESTRICT). SJUKHUS(Namn, Gata, Postnummer, Postadress) INSKRIVNING(Personnummer, Datum, Tid, Vårdplats, Klinik, Sjukhus, Sgata, Spnr, Spadr) d) Översätt följande fråga till såväl SQL som relationsalgebra: Vilka personer (Namn och Telefonnummer) har varit intagna på alla sjukhus? SQL: SELECT Namn, Telefonnummer FROM PERSON P WHERE NOT EXISTS (SELECT (Namn, Gata, Postnummer, Postadress) FROM SJUKHUS S WHERE NOT EXISTS (SELECT * FROM INSKRIVNING I WHERE I.Personnummer = P.Pnr AND I.Sjukhus=S.Namn AND I.Sgata =S.Gata AND I.Spnr=S.Postnummer AND I.Spadr=S.Postadress)) Här godkänns även en NOT IN konstruktion framför sista nästalade SELEC-klausulen. I många DBMS:ar går det dock inte att göra NOT IN på flera kolumner tillsammans. Relationsalgebra: Alla-sjukhus PI(Namn, Gata, Postnummer, Postadress) (SJUKHUS) Nyakolumner-i-inskrivning(Pnr, Datum, Tid, Vårdplats, Klinik, Namn, Gata, Postnummer, Postadress) INSKRIVNING
Tenta Sidan 8 av 4 Rätt-personer PI(Pnr) (Nyakolumner-i-inskrivning KVOT Alla-sjukhus) Svar PI(Namn, Telefon) (PERSON NATURAL JOIN Rätt-personer) Du ska här utgå från databasen som den är beskriven ovan, alltså INNAN eventuella ändringar med avseende på fråga c) gjorts. (5p + 5p) Rättning: Jag hade tänkt mig att problemet skulle ligga på att skriva kvoter mot tabeller med sammansatt identifierare men det verkar snarare som om det är själva kvoterna som är problematiska. Jag har dragit bort en poäng om kvoterna är rätt skrivna men man använt sig av enkla identifierare. Det vanligaste var dock att kvoterna inte var implementerade alls vilket gett 0 poäng.
Tenta Sidan 9 av 4 Uppgift 5 Ett typiskt användningsfall för användning av en bankomat är följande: En kund stoppar in sitt bankkort i bankomaten. Systemet kontrollerar att kortet är giltigt och att det inte är spärrat. Kunden matar in sitt lösenord och systemet kontrollerar att detta stämmer med kortet. Dessa kontroller kan ta ett antal sekunder. Medan kontrollerna sker kan kunden börja utföra sina transaktioner. Kunden anger vilken typ av transaktion som skall utföras, samt vilka belopp som skall sättas in, tas ut eller överföras. Innan någon transaktion kan genomföras måste kontrollen av kortet och lösenordet vara klara. En insättning går till så att kunden fysiskt sätter in rätt antal sedlar (vi antar för enkelhets skull att man bara kan sätta in 00-lappar). Sen kontrolleras att sedlarna håller godtagbar kvalitet. Om inte spottas sedeln (sedlarna) ut och användaren får möjlighet att mata in nya (eller avbryta). För överföring och uttag måste rätt summa finnas på det konto som pengar ska tas ifrån. Om tillräckliga belopp finns på kontona (och de inte är spärrade) så utförs transaktionen, i fallet uttag matar bankomaten ut rätt antal sedlar som kunden måste ta bort från sedeluttaget innan nästa transaktion kan påbörjas. En kund kan utföra flera transaktioner i följd. När alla transaktioner är klara får kunden tillbaka bankkortet och ett kvitto på de utförda transaktionerna. Det finns ett fall där kunden inte får tillbaka kortet, nämligen om det anmälts som borttappat. Modellera användningsfallet med hjälp av ett Petri nät med tid (6p) Kommentarer: Så mkt nytta av tid eller resurser gav väl inte detta användningsfall. Den som vill kan modellera pengarna och kortet som en resurs (ej gjort här). Ev. kan inmatning av lösenord göras parallellt med kontrollen av kortet. Rättning: Problemet med nästan alla inlämnade svar var att man blandar ihop semantik för transitioner och places. En transition kan inte utlösas om inte alla places som föregår den är enablade (dvs har en token). Detta leder bland annat till att man inte kan loopa tillbaka till en och samma transition (men väl till en och samma place). Gör man det kommer nämligen inte transitionen någonsin att kunna utlösas. Första gången pga att transitionen väntar på att en place längre fram ska bli enablad och andra gången (det blir ju i och för sig ingen andra gång) pga att den första placen inte längre är enablad. Ett specialfall utgör places med tokens som svarar mot resurser. Här har de som modellerat detta helt korrekt placerat en token i respektive input-place. Problemet här är att man sen aldrig frigör resurserna igen och då kommer eventuella loopar tillbaka inte heller att fungera. I detta fall har jag dock inte dragit av några poäng eftersom Petrinätet skulle bli orimligt stort om man krävde loopar för frisättande av resurser. Nästa problem är att OM en transition kan utlösas så kommer i sin tur ALLA grenar som går ut från transitionen att utföras, vilket leder till den parallellitet som efterfrågades på vissa ställen i uppgiften. Helt ok på rätt plats men man kan alltså inte använda transitioner för att simulera XOR, dvs låta tex en test utfalla i ja och nej grenar ut från transitionen. För det behövs istället en transition med EN gren ut som i sin tur leder till EN place som i sin tur har FLERA (XOR:ade) grenar ut. Omvänt kan man inte simulera AND via en place med tre grenar ut, bara EN av dessa kommer att utföras.
Tenta Sidan 0 av 4 Kort inmatat Mata in lösenord Z Testa kort Ogiltigt Spärrat Koll+ Val X Verifiera lösenord Fel lösenord Mata in lösenord Val av trans + summa AV- BRYT NY TRANS Lösen ok Kort ok Val ok Lösenord inmatat Y Val av trans + summa: AV- SLUTA Kort spärr? JA NEJ NEJ Kvitto + Kort Mata ut Sedlar kvar? JA Uttag medges ej Sätt in ok Sedlar utdelade Testa summa Sedlar OK? NEJ UT JA Börja transar NEJ IN Sedlar placerade? AV- BRYT ÖVER Konto II spärrat? Överf. nedges ej Summa överförd Testa summa NEJ JA