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: Svein Erik Bratsberg: Roger Midtstraum: Eksamensdato: 1. juni 2015 Eksamenstid (frå-til): 09:00-13:00 Hjelpemiddelkode/Tillatne hjelpemiddel: D Ingen trykte eller handskrivne hjelpemiddel tillatne. Bestemt, enkel kalkulator tillate. Annan informasjon: Målform/språk: Norsk nynorsk Sidetal: 6 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 (20 %) a) (8 %) Under er vist eit ER-diagram med spesialisering. Vis korleis du vil omsetje dette til ein ekvivalent relasjonsdatabase (vis kva for tabellar du vil ha, med attributt, primærog framandnøklar). Forklar kort dei alternative løysingane som finst og grunngje valet ditt. b) (12 %) Under er vist eit ER-diagram for ein enkel kjøretøysdatabase. Du skal ta utgangspunkt i denne datamodellen og utvide den slik at den også kan ta vare på data om ulykker der eit eller fleire køyretøy er involvert. For kvar ulykke må vi kunne lagre ein tekst om ulykka, GPS-posisjon, dato, tid og ulykketype ( materiell skade, personskade, dødsulykke ). Vi ønskjer å kunne holde oversikt over alle involverte personar og køyretøy. For involverte køyretøy ønskjer vi å vite kven som var førar, kven som eventuelt var passasjerar og det skadeomfanget ( ingen, liten, omfattande, totalvrak ) køyretøyet vart påført i ulykka. For alle personar som var involvert i ulykka, skal ein kunne registrere skadeomfang ( uskadd, lett skada, alvorlig skada, livstruande skada, dødeleg skada ). For sjåførar skal ein kunne registrere om føraren hadde gyldig førarkort eller ikkje og om vedkommande var edru eller påverka av rusmiddel da ulykka skjedde ( ukjent, upåverka, påverka ). Side 2 av 6

3 I ER-modellen din kan du bruke alle modellelement som er med i pensum. Du kan bruke norske namn på entitetsklassar, relasjonsklassar og attributt. Forklar kort eventuelle føresetnader du finn det nødvendig å gjere. Oppgåve 2 Relasjonsalgebra og SQL (20 %) Ta utgangspunkt i denne relasjonsdatabasen (primærnøklar er understreka) for ein enkel fugleobservasjonar-database: BirdGroups(BGID, GroupName) BirdSpecies(BSID, SpeciesName, PrevalenceStatus, Prevalence, BirdGroupID) BirdGroupID er framandnøkkel mot BirdGroups-tabellen. BirdGroupID kan ikkje ha NULLverdi. Observation(ObsNo, ObsDay, ObsMonth, ObsYear, SpeciesID, LocationNo, BirdCount) SpeciesID er framandnøkkel mot BirdSpecies-tabellen. LocationNo er framandnøkkel mot Location-tabellen. SpeciesID og LocationNo kan ikkje ha NULL-verdi. Location(LNo, LocName, Description, MunicipalityNo) MunicipalityNo er framandnøkkel mot Municipality-tabellen. MunicipalityNo kan ikkje ha NULL-verdi. Municipality(Mno, MunName) Relasjonsalgebra kan formulerast som tekst eller grafar. Om du kan begge notasjonene føretrekk vi at du svarar med grafar, men du blir ikkje trekt for å svare med tekst. a) (3 %) Lag ei spørjing i relasjonsalgebra som finn namn på alle fugleartar (eng: bird species) som er trekkfuglar (PrevalenceStatus har verdien migratory). b) (4 %) Lag ei spørjing i relasjonsalgebra som finn namnet på alle fugleartar som er observert i Trondheim kommune (eng: Trondheim municipality) i c) (4 %) Lag ei spørjing i SQL som finn namn på alle fugleartar i fuglegruppa Thrushes (trostefuglar). Resultatet skal vere ordna i alfabetisk rekkefølgje. d) (4 %) Lag ei spørjing i SQL som finn artsnamn, talet på observasjonar av arten i 2015 og samla tal på observerte individ av arten i 2015 (BirdCount), for alle fugleartar som er observert i Resultatet skal vere ordna etter talet på individ i minkande rekkefølgje. e) (5 %) Lag ei spørjing i SQL som finn namn på alle fugleartar som er observert i Trondheim kommune, men ikkje i Trondheim i Oppgåvesettet fortset på neste side. Side 3 av 6

4 Oppgåve 3 Teori (20 %) a) (3 %) Ta utgangspunkt i tabellen Birds(SpeciesID, SpeciesName, BirdGroup, Status) med oppgitt innhald: Kva for funksjonelle avhengnadar (eng: functional dependencies) er det rimeleg å anta vil gjelde for denne tabellen? Forklar kva du legg til grunn for svaret. Du treng ikkje å ta med trivielle funksjonelle avhengnadar eller funksjonelle avhengnadar som ein kan utleie frå dei funksjonelle avhengnadane i svaret ditt. b) (3 %) Gitt R = {A, B, C, D, E} og F = {A -> B, B ->C, CD->E}. Finn alle kandidatnøklar i R. Du må grunngje svaret ditt. c) (4 %) Gitt R = {A, B, C, D, E} og F = {A -> B, B ->C, CD->E}. Gå ut frå at R oppfyller 1. normalform. Finn den høgaste normalforma som R oppfyller. Du må grunngje svaret ditt. d) (6 %) Gitt R = {A, B, C, D, E} og F = {A -> B, B ->C, CD->E}. Ein mogleg dekomponering av R er R1(A, B), R2(B, C) og R3(C, D, E). Er dette ei god dekomponering? Du må grunngje svaret ditt. e) (4 %) Ta utgangspunkt i tabellen Teaching(Lecturer, Subject, Campus). Gå ut frå at fleirverdi avhengnadane (eng: multi-value dependency) Lecturer ->> Subject og Lecturer ->> Campus gjeld og at desse radane er lagra i tabellen: (svein, db, gløs), (rune, db, gjøvik), (tore, db, kalvskinnet) og (mads, os, gløs). Teikn tabellen med rader og kolonnar slik at du viser alle rader som utan tvil må vere med i tabellførekomsten. Oppgåvesettet fortset på neste side. Side 4 av 6

5 Oppgåve 4 Lagring og skalering (5 %) Du jobbar i ein bedrift som lanserer ein webbutikk kor talet på kundar og kjøp er usikkert. Databasen består av tabellane Kunde, Ordre, Produkt og OrdreLinje. Kundar identifiserast ved hjelp av epost-adresse, og nesten alle aksessar av tabellane skjer direkte via primærnøkkel, dvs. epostadresse, kundenummer, ordrenummer og produktnummer. Kva for lagrings/indeksstruktur(ar) meiner du det er lurt å bruke for tabellane når du er usikker på om det blir 1000 eller kundar? Grunngjev svaret ditt. Oppgåve 5 B+-trær og queryutføring (15 %) Føresett følgjande tabell: CREATE TABLE Employee (empno INT PRIMARY KEY, lastname CHAR(30), firstname CHAR(30), CHAR(30), startyear INT, salary INT); Føresett at tabellen er lagra i eit clustered B+-tre med 1500 blokkar på lauvnivå. Empno er søkenøkkel i B+-treet. Vi føresett at B+-treet har høgd 3. a) (10 %) Gjør eit overslag på kor mange blokkar som aksesserast (lesast og skrivast) ved dei følgjande SQL-setningane: i) INSERT INTO Employee VALUES (123123,'Hansen','Hans','hans@ .org',2015, ); ii) SELECT lastname, firstname, , startyear, salary FROM Employee WHERE empno = ; iii) SELECT * FROM Employee; iv) SELECT COUNT(*) FROM Employee WHERE empno > ; Føresett at første tilsatte hadde empno = og at alle nummer er brukt fram til Lag ei grunngjeving/forklaring for kvart svar. b) (5 %) Viss queriet SELECT * FROM Employee WHERE startyear=2015 kjøyrast veldig ofte, ville du ha endra lagringa/indekseringen? Kvifor/kvifor ikkje? Oppgåve 6 Transaksjonar - recoveryeigenskapar (10 %) Føresett følgjande historier: H1: r1(a); w1(a); r2(b); c1; r2(a); w2(a); c2; H2: r1(a); w1(a); w2(a); c2; c1; H3: r1(a); r2(c); r1(c); r3(a); r3(b); w1(a); w3(b); r2(b); w2(c); w2(b); c1; c2; c3; Bestem recoveryeigenskapane til historiene (unrecoverable, recoverable, ACA, strict). Grunngjev svara. Side 5 av 6

6 Oppgåve 7 Transaksjonar - recovery (10 %) Føresett at vi bruker ARIES-recovery og la A, B, og C vere dataelement. Etter ein krasj blei følgjande logg funnet med ein loggpost i kvar rad av tabellen: LSN Last_lsn Transaction OpType Page_id Other_info T1 Update C T2 Update B T1 Commit 104 Begin_ckpt 105 End_ckpt T3 Update A T2 Update C T2 Commit a) Føresett T1, T2 og T3 er alle transaksjonane som finnast og at transaksjonstabellen som finnast i loggpost 105 ser slik ut: Transaction Last_lsn Status T1 103 Commit T2 102 In progress Dirty Page Table som finnast i loggpost 105 ser slik ut: Page_id Rec_lsn C 101 B 102 Korleis ser transaksjonstabellen og Dirty Page Table ut etter analysefasen av recovery? b) Kva for loggpostar vil leggjast til loggen under undofasen av recovery her? Side 6 av 6