Eksamensoppgåve i TDT4145 Datamodellering og databasesystem

Transkript

1 Institutt for datateknikk og informasjonsvitskap Eksamensoppgåve i TDT4145 Datamodellering og databasesystem Fagleg kontakt under eksamen: Roger Midtstraum: Svein Erik Bratsberg: Eksamensdato: 17. august 2016 Eksamenstid (frå-til): 15:00-19:00 Hjelpemiddelkode/Tillatne hjelpemiddel: D Ingen trykte eller handskrivne hjelpemiddel tillatne. Bestemt, enkel kalkulator tillate. Annan informasjon: Målform/språk: Norsk nynorsk Sidetal: 7 Sidetal vedlegg: 0 Kontrollert av: Svein-Olaf Hvasshovd (sign.) Dato Sign. Merk! Studentane finn sensur i Studentweb. Har du spørsmål om sensuren må du kontakte instituttet ditt. Eksamenskontoret vil ikkje kunne svare på slike spørsmål.

2 Oppgåve 1 Datamodellar (18 %) Lag ein ER-modell (du kan bruke alle modellelement som er med i pensum) for denne situasjonen: Ein skal lage ein applikasjon for å halde oversikt over vegar, vegstandard, fartsgrenser og ulykker. Vegnettet er organisert som illustrert i figuren under. Vi har endepunkt (vist med bokstavar i figuren) som har ein kjent posisjon (x-koordinat, y-koordinat og høgde). Mellom to endepunkt kan det vere eit vegsegment som har eit startpunkt, eit endepunkt og ei lengde (vist med tall i figuren). Ein veg består av eit eller fleire vegsegment, nummerert slik at vi får ein samanhengande veg frå start- til endepunkt. Eit vegsegment kan ikkje vere med i fleire vegar og det kan vere vegsegment som ikkje er del av nokon veg. Vi har nokon førehandsdefinerte fartsgrenser. Alle vegsegment har ei fartsgrense. Om ein ønskjer å differensiere fartsgrensa innan eit vegsegment, må dette vegsegmentet splittas opp i fleire vegsegment, slik at kvart vegsegment får ei og same fartsgrense. Tilsvarande har vi nokon førehandsdefinerte vegstandardar, kvar med ein forklarande tekst. Alle vegsegment har ein vegstandard og splittas om nødvendig opp i fleire vegsegment for at det skal vere slik. Ein veg har eit eintydig vegnummer, eit vegnamn og ei samla veglengde. Ulykker blir registert med tid, dag, månad og år, samt ein tekst som omtalar ulykka. Ulykker klassifiserast etter kor alvorlege dei var, basert på eit førehandsdefinert klassifikasjonssystem. På den eine sida registrerast ulykka si menneskelege konsekvens ( dødsulykke, alvorlig personskade, mindre personskade, liten eller ingen personskade ) og på den andre sida registrerast ulykka si materiell konsekvens ( omfattande materielle skada, mindre materielle skada, liten eller ingen materiell skade ). Knytt til kvart nivå finst det ein tekst som gjer klart kriteria for å klassifisere ulykka på dette nivået. For ei ulykke skal ein kunne registrere kor mange køyretøy som var med og om ulykka var årsaka av trafikkregelbrot eller ikkje. For å posisjonere ei ulykke skal den plasserast i aktuelt vegsegment, med ei lengde (offset) som viser kor langt frå vegsegmentet sitt startpunkt ulykka skjedde. Forklar kort eventuelle føresetnader du finn det nødvendig å gjere. Side 2 av 7

3 Oppgåve 2 Relasjonsdatabaser, ER-modellar, relasjonsalgebra og SQL (18 %) Gitt eit relasjonsdatabase-skjema for ein smakstest-database for brus. Primærnøklar er understreka. SoftDrink(SDID, ProductName, Taste) TestPerson(TPID, Name, Sex, Age) Ranking(RID, Description) TasteTest(TTID, TPID, SDID, RID, TTYear, TTMonth, TTDay) TPID er framandnøkkel mot TestPerson-tabellen. Kan ikkje ha NULL-verdi. SDID er framandnøkkel mot SoftDrink-tabellen. Kan ikkje ha NULL-verdi. RID er framandnøkkel mot Ranking-tabellen. Kan ikkje ha NULL-verdi. Relasjonsalgebra kan formulerast som tekst eller grafar. Om du kan begge notasjonane føretrekk vi at du svarer med grafar, men du blir ikkje trekt for å svare med tekst. a) I figuren under har vi vist to alternative ER-modellar for denne databasen. Kva for eit alternativ samsvarar best med relasjonsskjemaet? Du må grunngje svaret ditt. NB! Oppgavesettet fortsetter på neste side. Side 3 av 7

4 b) Lag ei spørjing i relasjonsalgebra som finn namn, kjønn og alder for alle som har testa brus (eng: soft drink) med pineapple-smak. Resultatet skal ikkje innehalde duplikat (like rader). c) Ein ønskjer at alle testpersonar skal gjere smaksvurdering av alle brusar. Lag ei spørjing i relasjonsalgebra som finn TPID og SDID for kombinasjonar av testperson og brus som manglar i databasen. d) Skriv ei spørjing i SQL som finn gjennomsnittsalder for testpersonar som har gitt brus med pineapple-smak rangering med definisjonen (eng: description) awesome. e) Skriv ei spørjing i SQL som for kvar rangering finn ut kor mange smakstestar som har gitt denne karakteren. Resultatet skal innehalde RID, Description og talet på smakstestar, og skal vere sortert på RID (i stigande rekkefølgje). f) Skriv ei spørjing i SQL som finn alle brusar med orange-smak som har fått fleire enn 5 awesome vurderingar frå kvinnelege testpersonar. Resultatet skal innehalde SDID, ProductName og talet på awesome vurderingar. Oppgåve 3 Datamodellering og relasjonsdatabasar (7 %) a) Kva vil det seie at ei spesialisering (eng: specialization) av ein entitetsklasse er disjunkt? b) Kva vil det seie at ei spesialisering av ein entitetsklasse er total? c) Kva vil det seie at tabellar (relasjonar) i relasjonsdatabasar har referanseintegritet (eng: referential integrity)? Oppgåve 4 Normaliseringsteori (5 %) Under er vist ein tabellførekomst for tabellen R. Finn alle funksjonelle avhengnadar (eng: functional dependencies) som ikkje kan gjelde for tabellen om denne tabellførekomsten er gyldig. Side 4 av 7

5 Oppgåve 5 Normaliseringsteori (12 %) a) (2 %) Gitt tabellen R(A,B,C,D) og F={A->C, B->D}. Anta at tabellen oppfyller første normalform. Forklar kvifor dette er den høgste normalforma som oppfyllast av tabellen. b) (5 %) Gitt tabellen R(A,B,C,D) og F={A->C, B->D}. Anta at tabellen oppfyller første normalform. Finn ei dekomponering der alle komponenttabellar er på Boyce-Codd normalform (BCNF) og som oppfyller alle andre eigenskaper som ein normalt ønskjer. Forklar kvifor det er slik. c) (5 %) Gitt tabellen R(A,B,C,D) og F={A->C}. Ei dekomponering i R1(A,B) og R2(B,C,D) har ikkje tapsløst-join eigenskapen. Lag eit konkret eksempel (med tabellførekomstar) som viser at det er slik. Oppgåve 6 B+-trær (10 %) Sett inn følgjande nøklar i eit B+-tre: 23, 11, 12, 16, 30, 17, 6, 4, 7, 13. Føresett at det er plass til tre nøklar per blokk, både på lauvnivå og lengre opp i treet (men 4 peikare til nivået under). Vi tilstanden til B+-treet kvar gang du skal til å splitte ei blokk, og vis treet til slutt. Side 5 av 7

6 Oppgåve 7 Queries og join (10 %) a) Vi har ein tabell Staff (staffno, fname, lname, depno, position, salary) Det er to typar SQL-setninger som er vanlige i databasen: 1) SELECT fname, lname, salary FROM Staff WHERE salary = (SELECT MAX(salary) FROM Staff); 2) UPDATE Staff SET Salary = Salary *Salary WHERE staffno=123456; Korleis burde denne tabellen lagrast og indekserast for at dei to typane av queries skal kunne utførast effektivt. Gi ei forklaring for ditt svar. b) I tillegg til tabellen i a) har vi tabellen Department (depno, dname, managerno, location) Vi skal utføre ein nested loop-join mellom dei to tabellane. Staff er her lagra i ei heapfil med 1000 blokker, mens Department er lagra i ei heapfil med 30 blokker. Vi har eit buffer tilgjengeleg med 7 blokker. Kor mykje I/O får vi ved ein nested loop-join? Gi svaret i talet på blokker du må lese inn frå disk. Du treng ikkje rekne med skriveoperasjonar her. Oppgåve 8 Historie og tofaselåsing (2PL) (10 %) Gitt følgjande historie: H1: r1(x); r2(y); r1(y); r3(x); r3(y); w1(x); c1; w3(y); c3; r2(x); w2(z); c2; a) Tekn opp presedensgrafen og avgjør om historien er konfliktserialiserbar. b) Innfør tofaselåsing (2PL, rigorous) med lese- og skrivelåsar i H1. Skriv om historien H1 slik at han gjør bruk av låsar og vis korleis han da utførast. Når ein transaksjon må vente på ein lås, stopper denne transaksjonen, men andre transaksjonar kan fortsette. Den stoppede transaksjonen kan fortsette når dei blokkerande låsane slippast. Låsoppgradering er mogleg. Side 6 av 7

7 Oppgåve 9 Recovery (10 %) a) Ved bruk av ARIES-recovery har vi tre forskjellige testar som vi kan gjøre slik at vi veit at ein loggpost ikkje treng REDO. Kva for tester er det? b) Kva skjer med logg- og databuffer i ARIES når ein transaksjon committer? Side 7 av 7