svarforslag SLUTTEKSAMEN IBE211 Databaser, våren 2015

Transkript

1 svarforslag SLUTTEKSAMEN IBE211 Databaser, våren 2015 Dato: 11/ Tid: 4 timer, skriftlig, ingen hjelpemidler. Oppgave 1 (80 %) Vi skal lage et sterkt forenklet system for Sjøfartsdirektoratet som ønsker en sentral database for registrering av alle skipsanløp i alle norske havner. For hver havn vil vi vite hvem som er havnesjef, antall ansatte i havnevesenet og hvilke kaier som fins. For hver kai må vi vite størrelse, dybdeforhold og hva slags andre egenskaper som kaia har, f.eks fergeramper for bilkjøring om bord, oljepumper til lagertanker, spesialkraner, fiskemottak, osv. Dette må vi vite for å kunne dirigere de ulike skipene til riktig kai. Svar: Ifølge læreboken er ER diagram en skisse som viser sammenheng mellom entiteter. Primærnøklene understrekes. Fremmednøklene er ikke med ( de ser ut til å mangle, s. 129). En entitet er det vi vil lagre info om. HAVN (antar at et på havnen er unikt, som Oslo, Bergen ) (kan evt. være et på et poststed, hvis det var en entitet) sjef antall ansatte KAI størrelse dybdeforhold fergerampe oljepumpe spesialkraner fiskemottak andre egenskaper En HAVN kan ha 0 eller flere KAIer, mens en KAI tilhører en (og ikke flere) HAVNer. En kan tenke seg at en KAI kan eksistere uten at den er tilknyttet en spesiell HAVN, men teksten åpner vel ikke for den muligheten, så KAI settes som svak entitet og får en identifikator som delvis nedarves (som prefix) fra HAVN, f.eks. Bergen.Havn7. Havnens sjef er et forhold til PERSON (som finnes lenger ned i svaret).

2 For hvert anløp må vi vite hvilket skip det dreier seg om og dato og klokkeslett inn og ut. Vi må også vite hvor det det kom fra (by og land ) og hvor det skal videre (neste havn). Svar: SKIP skipsnummer (to skip kan ha samme, så kan ikke være identifikator). ANLØP inndato innklokkeslett (inndato og innklokkeslett kunne vel vært identifikator, da to skip neppe ankommer til nøyaktig samme tid). utdato utklokkeslett BY bykode (to byer kan ha samme, kan ikke være identifikator). LAND (antar at det ikke finnes to land med samme, så det kan være identifikator). Et ANLØP gjelder ett SKIP, mens ett SKIP kan ha 0 eller flere ANLØP. Hvis SKIPet forsvinner, er vel ANLØPet uaktuelt å lagre, så en kan ha dette forholdet som svakt. Et ANLØP betyr vel at SKIPet la til ei KAI, selv om det ikke står eksplisitt slik i oppgaven. Så et ANLØP sitt forhold til KAI blir da svakt (1 og bare 1 KAI), mens en KAI kan ha 0 eller flere ANLØP tilknyttet. Da nedarver ANLØP altså identifikator fra både KAI og SKIP, og har selv en inndato som bør sikre unik identifikator. Et ANLØP har forholdet kom fra til BY, som igjen har et forhold til LAND. Dette ifølge teksten. Egentlig høres det like greit ut om kom fra peker til en HAVN (forrige havn). Fra ANLØP har forholdet neste havn til en HAVN. Et ANLØP skal ifølge teksten ( må vite ) ha et slikt forhold til en HAVN (1 og bare 1). Motsatt kan en HAVN ha 0 (?) eller flere ANLØP. Dersom det skjer uhell i forbindelse med et anløp ønsker vi også å vite det.

3 Svar: UHELL uhellsnummer (en kan vel tenke seg at uhell er noe som loggføres med et stigende nummer) beskrivelse tidspunkt Teksten sier ikke om en skal kunne lagre flere UHELL per ANLØP. Eller, om en tenker seg en egenskap som sier ja (her var uhell) eller nei (ingen uhell). Eventuelt en teller (antall uhell) eller et større tekstfelt for å beskrive ett/flere uhell. I svarforslaget antas at en kan ha flere UHELL per anløp og faktisk skal lagre noe om hvert uhell. Teksten sier ikke hva en skal vite om et uhell. Men, en beskrivelse og et tidspunkt er vel av interesse. Tidspunkt kan kanskje utelates, i og med at ANLØPet er merket med fra/til. Så, et ANLØP har da et 1 til mange forhold til UHELL, da man kan tenke seg 0 eller flere uhell. UHELL er vel å betrakte som svak: Hvis ANLØP forsvinner kan en godt glemme UHELLet. Teksten sier bare forenklet ; hvis teksten hadde bedt om et minimalt design (færrest mulig entiteter og forhold), ville UHELL som en ja/nei egenskap vært best. For hvert skip vil vi vite (et kan endres ved eierskifte, men vi ønsker å ta vare på det forrige et også slik at vi kan følge historikken til spesielle skip), byggeår, mannskapsantall, type med egenskaper (cruiseskip antall passasjerer, oljetanker antall tonn, ferge både antall biler og antall passasjerer, tråler antall tonn, bilfrakteskip antall biler osv). Videre må vi vite hvilket rederi som eier skipet og hvilket land rederiet har valgt å registrere det i ( mange skip eid av norske rederier er registrert i andre land som f.eks Liberia). Svar: Her detaljeres SKIP (som ble nevnt tidligere i forbindelse med ANLØP). SKIP skipsnummer byggeår mannskapsantall registreringsland fradato tildato (det er eierskapets fra og tildato som representeres over). REDERI

4 Gjeldende eier representeres som et forhold eies av til REDERI. Ett SKIP kan kun ha en eies av, mens et REDERI kan stå som eier av 0 eller flere SKIP. Et SKIP har et registrert i forhold til LAND (nevnt tidligere). Kun ett (1) land, mens ett LAND vel kan ha 0 eller flere SKIP registrert. Det er ikke nevnt hvorvidt et SKIP kan være registrert i flere land i løpet av tiden den er eid av samme REDERI. Det må evt. løses ved at det lages et nytt SKIP med tidligere som peker til samme eier, men ulikt land. Et SKIP kan ha 0 eller flere koblinger til seg selv (rolle: tidligere ). Et eierskifte gjør at det blir et nytt skip med kobling til seg det forrige. Ett SKIP har 0 eller flere tidligere SKIP. Det antydes at en har ulike typer skip, hver med sine sære egenskaper. Det kaller for å bruke subtype. CRUISESKIP antall passasjerer OLJETANKER antall tonn FERGE antall biler antall passasjerer TRÅLER antall tonn BILFRAKTESKIP antall biler Disse fire subtypene arver da supertypen SKIP. En kan da si at TRÅLER er en SKIP. Dette vises i diagrammet med en halvsirkel som er flat mot subtypen og buet mot supertypen. En kunne eventuelt hatt PERSONFRAKTESKIP antall passasjerer FERGE antall biler der FERGE er en PERSONFRAKTESKIP, som igjen er en SKIP.

5 og (vi forfølger samme tanke): LASTFRAKTESKIP antall tonn OLJETANKER TRÅLER der både TRÅLER og OLJETANKER er en LASTFRAKTESKIP. Et tredje alternativ ville være å ikke subtype, men lage en SKIPSTYPE med, tonn og antall passasjerer. SKIP lenkes da til til en SKIPSTYPE. Alle skip gjennomgår sjødyktighetskontroller som utføres av klassifiseringsselskap, (som f.eks Det norske Veritas (DnV)), både når de er nye og med et antall års mellomrom siden. I løpet av et skips levetid, kan det være kontrollert av flere selskap, og vi må ta vare på kontrollhistorikken, (hvilket selskap har kontrollert og godkjent det, og når (mnd og år)). Svar: KONTROLL tidspunkt (måned og år). resultat kontrollør Et SKIP har 0 eller flere KONTROLLer utført, mens en KONTROLL kun gjelder ett SKIP. En kan vel tenke seg at KONTROLL er svak i forhold til SKIP, og at det har en identifikator som delvis nedarves fra SKIP, som M/T Berge Vanga At en KONTROLL har egenskapen resultat er delvis fri fantasi, men det nevnes i teksten at den kan resultere i en godkjenning (som jo er et resultat). For hvert rederi vil vi vite hvilke skip de eier, om mulig hvem som eier rederiet og hvor det har kontorer (land og by). I flere havner er det rederier som er enebruker av en eller flere kaier, (f.eks Kiel ferga og Danskebåtene i Oslo som har egne kaier). Dette ønsker vi også skal være med i modellen. Svar: For å løse dette må REDERI ha et forhold til PERSON ( eid av ), der en PERSON kan eie 0 eller flere REDERI, og motsatt, et REDERI er eid av 1 PERSON.

6 PERSON Et REDERI har kobling til 0 eller flere BYer der det har kontor. En BY har 0 eller flere REDERIer med kontor i byen. Dette blir da et mange til mange forhold som skal få stå slik i skissen. (Dette kunne alternativt, vært løst med at et REDERI har 1:1 kobling til et REDERIKONTOR (som ikke er tatt med i dette svaret) som igjen ville hatt 1:M kobling til til BY). Videre kan en KAI ha et forhold kun brukt av til et REDERI. En KAI har da 0 eller 1 REDERI tilkoblet slik, mens et REDERI kan ha 0 eller flere KAIer tilknyttet. Nedenfor finner du noen eksempler på spørsmål som kan stilles til et slikt system. Du kan bruke dem for å kontrollere at den ER modellen du ender opp med, (entiteter og attributter) fungerer tilfredsstillende. Hvor mange anløp har det vært i de enkelte havner av forskjellige skipstyper? Svar: Modellen viser HAVN til KAI til ANLØP til SKIP til SKIPSTYPE. Hvilke rederi har hatt flest anløp i Bergen og Oslo i år? Svar: ANLØP har inntid, velger de med år lik dette år (f.eks. 2015), og følger koblingen til KAI, videre til HAVN der en velger de med Bergen eller Oslo. Hvor mange cruiseskip har vært på besøk i de forskjellige havner? Svar: For hvert CRUISESKIP, finn ut hvilket SKIP dette er og finn alle ANLØP med dette SKIP, og kategoriser dette mot ANLØPets KAI (og dermed HAVN). Hvilke skip og rederier har vært involvert i uhell i forbindelse med anløp? Svar: For hvert UHELL, finn ut hvilket ANLØP det gjelder, hvilket gir kobling til SKIP som igjen er koblet til REDERI. Hvor mange Liberia registrerte skip har anløpt Slagentangen i mars? Svar: Hvis en antar at Slagentangen er en HAVN, må en ta alle ANLØP i mars til en KAI som er tilknyttet HAVNen Slagentangen. Hvis ANLØPet er koblet til et SKIP som har Liberia som registreringsland skal det telles med. Hvor stor prosent av skipene som anløp norske havner i fjor var kontrollert av Det norske Veritas? Svar: For hver KONTROLL i fjor (f.eks. 2014) vet vi hvilket KLASSIFISERINGSSELSKAP som gjorde kontrollen (velger de som er av Veritas). Dernest må en velge kun de SKIP som hadde ANLØP til norsk HAVN (eller KAI i norsk HAVN). Hvilket var det største skipet som anløp Kristiansand i april? Svar: For alle ANLØP til en KAI på Kristiansand HAVN i April, følger en koblingen til SKIP (fra ANLØP) og finner det som er størst. Det er ikke sagt om det er størrelse i antall tonn, passasjerer, mannskap. Hvilke skip som har anløpt norske havner har vært eid av mer enn to rederier? Svar: For hvert ANLØP som gjelder en KAI i en HAVN som er tilknyttet Norge som LAND... for hvert slikt ANLØP, følg koblingen til SKIP og finn ut hvor mange ganger SKIP har endret eier (følg tidligere ). Vis kun de som har skiftet eier to eller flere ganger.

7 Oppgaver du skal besvare 1. Lag en ER modell av et slikt system. Forklar hvilke forutsetninger og eventuelle valg du gjør. Svar: Se diskusjonen i svarene over. 2. Lag en relasjonsmodell med tabeller ut fra ER modellen. a. Marker primær og fremmednøkler tydelig. b. Forklar de valg du har foretatt. c. Nevn hva du eventuelt har utelatt. 3. Skriv CREATE TABLE for tabellene med skip og anløp. 4. Lag SQL som viser følgende: a. Alle skip med byggeår og ulike det har hatt siden byggeår. b. Alle uhell i forbindelse med anløp i c. Alle kaier som er eid av et rederi. Svar til oppgave 1.2. Her må en følge reglene for å oversette 1:1 (hver 1 side får motsatt sides primærnøkkel som fremmednøkkel),, 1:M (kopierer 1 sidens primærnøkkel inn på mangesiden), svake entiteter (nedarving av identifikator), og subtyper (velger Strategi 1 av de 3 strategier i boken). PERSON ( uid, ) her lagres både rederieiere og havnesjefer HAVN( havneid, sjefuid*, bykode*, antall ansatte) KAI( havneid*, kai, størrelse. dybdeforhold. fergerampe, oljepumpe. spesialkraner, fiskemottak. andre egenskaper, enebrukerrederi*) ANLØP ( skipsnummer*, kai*, inndato, innklokkeslett, utdato, utklokkeslett, forrigehavn*, nestehavn*) BY ( bykode,, land*) LAND ( ) REDERI (, eieruid*) REDERIKONTOR ( rederi*, bykode* ) for å løse opp N:M forholdet. REDERIEIER ( rederi*, eieruid* ) SKIP ( skipsnummer,, byggeår, mannskapsantall, eierrederi*, registreringsland*, fradato, tildato, tidligereskipsnummer*) Velger Strategi 1 for subtypene: får supertypens primærnøkkel som fremmednøkkel: CRUISESKIP ( skipsnummer*, antall passasjerer) OLJETANKER ( skipsnummer*, antall tonn) FERGE ( skipsnummer*, antall biler, antall passasjerer) TRÅLER ( skipsnummer*, antall tonn) BILFRAKTESKIP ( skipsnummer*, antall biler) KONTROLL ( skipsnummer*, tidspunkt, klassifiseringsselskap, resultat) Svar til oppgave 1.3. CREATE TABLE SKIP ( skipsnummer INT, VARCHAR(100),

8 ); byggeår INT, mannskapsantall INT, registreringsland VARCHAR(100), fradato DATE, tildato DATE, eierrederi varchar(50), tidligereskipsnummer INT CONSTRAINT skippn PRIMARY KEY (skipsnummer), CONSTRAINT skipsregistreringslandfn FOREIGN KEY registreringsland REFERENCES land(), CONSTRAINT eierrederifn FOREIGN KEY eierrederi REFERENCES rederi(), CONSTRAINT tidligereskipsnummerfn FOREIGN KEY tidligereskipsnummer REFERENCES skip(skipsnummer), CREATE TABLE ANLØP ( skipsnummer INTEGER PRIMARY KEY, kai VARCHAR(50) PRIMARY KEY, inndato DATE PRIMARY KEY, innklokkeslett TIME, utdato DATE, utklokkeslett TIME, forrigehavn INTEGER, nestehavn INTEGER, CONSTRAINT forrigehavnfn FOREIGN forrigehavn KEY REFERENCES havn(havneid), CONSTRAINT nestehavnfn FOREIGN nestehavn KEY REFERENCES havn(havneid), Svar til oppgave 1.4. Oppgave 2 (20 %) Svar på følgende spørsmål: 1. Det har vært strømbrudd midt i travleste arbeidstida. Forklar hvordan dette kan ha skadet databasen og hvordan du sikrer at mest mulig blir berget (at minst mulig går tapt ). Svar: Utsaget midt i travleste arbeidstida kan tolkes dithen at det jobbes mye, at at det derfor skjer mye inn/ut mot databasen. I så fall, hvis det er mye som skal inn (skrives) til databasen (oppdateringer), kan en si at strømbruddet skjer på verst tenkelige tidspunkt, fordi mengden ikkelagrede data er størst. a. Et strømbrudd er en instansfeil (ikke mediefeil). Så disken er ikke skadet. Men, bruddet kan ha gjort skade ved å etterlate databasen inkonsistent. Dette kan skje ved at en transaksjon som f.eks. ordreregistrering ikke blir fullført. En

9 transaksjon består av flere operasjoner ( SQL spørringer ), og strømbruddet kan inntreffe før transaksjonens avsluttende COMMIT eller ROLLBACK blir utført. Et eksempel er da at ordretabellen og ordrelinjene er/ble oppdatert, mens varelageret ikke er oppdatert. b. For å sikre at mest mulig blir berget (minst mulig blir tapt ) går en frem som følger. I og med at disken ikke er skadet, er det ikke (neppe) behov for å innhente sikkerhetskopier. Man starter maskinen og antar at databasen (DBHS prosessene) kommer i gang, muligens med diverse advarsler pga strømbruddet. Deretter tar man utgangspunkt i DBHS sin transaksjonslogg. Loggen befinner seg gjerne på et annet lagringssted enn selve databasen og skal inneholde logg over alle operasjoner (og transaksjoner) som er utført frem til strømbruddet inntraff. Konsekvensene avhenger av hvorvidt databasen bruker i) umiddelbar oppdatering eller ii) utsatt oppdatering. I siste tilfelle blir nemlig ikke operasjonene iverksatt før de er registrert i loggen. Med denne loggen kan man da enten i. ved umiddelbar oppdatering kan man forsøke å rulle tilbake ; lese loggen baklengs og gjøre UNDO ( angre ) på alle operasjoner, d.v.s. at nye verdier erstattes med gamle. ii. gjenta, lese loggen fra og med starten av avbrutte transaksjoner, og gjøre om igjen (REDO) de operasjoner som loggen sier ble gjort (frem til bruddet), samt også gjøre de operasjoner som ikke ble gjort p.g.a. samme strømbrudd, helt til transaksjonen avsluttes. 2. Hva er spørreoptimalisering? Hva er hovedreglene når man skal skrive optimalt, og hva (hvilken kvalitet) er det som blir bedre av at man optimaliserer? Svar: a. Spørreoptimalisering er å reformulere en spørring slik at den bruker minst mulig ressurser og gir raskest mulig svar. Arbeidet er delt inn i i. oversette SQL uttrykkene til relasjonsalgebra ii. omskrive uttrykket med etablerte regler for omskriving b. Hovedregelen når man skriver optimalt er å flytte seleksjon og projeksjon så langt ned i treet som mulig. Det vil si at en gjør filtreringen så tidlig som mulig i utførelsen av spørringen. Da må f.eks. WHERE plasseres så innerst som mulig i parantesene (for seleksjon). Fordelen er at mellomresultatene blir så små som mulig (sparer plass og tid). En kan også velge seg kun de kolonner i SELECT <kolonner> som er absolutt nødvendig for å komme frem til svaret (sparer plass). c. Den kvalitet man er opptatt av er altså plass (til mellomresultat) og tid. 3. Hva er en delspørring. Hva er en vekselvirkende delspørring? Svar: a. En delspørring er en SELECT..., der resultatet (av SELECT...) brukes som input til en annen SQL spørring (på et nivå over ). Nivåinndeling gjøres med paranteser, som sikrer at de innerste spørringene gjøres først). b. En vekselvirkende delspørring er en som for hver verdi V i ytre spørring, utfører den indre spørring (med hensyn på V). Litt som en forløkke. 4. Hva er målet med normalisering? Hva er forskjell på 2. og 3. normalform? Hva er denormalisering? Svar:

10 a. Målet med normalisering er å forenkle vedlikeholdet av data, primært ved å unngå redundans (at samme data/verdier lagres flere steder). I stedet for å redundant gjenta verdier om et objekt på N steder, lager man i stedet en tabell der objektet lagres 1 gang, og lager N lenker/koblinger (referanser) til dette objektet. Vedlikehold skjer da ett (1) sted. Koblingene trenger ikke forandres. Vedlikeholdet gjøres raskere (1 istedet for N operasjoner) og med færre sjanser for feil, f.eks. fordi man glemmer å ta alle N, eller at det inntreffer f.eks. strømbrudd halvveis. b. Forskjell på 2. og 3. normalform (2NF og 3NF) er at man i 3NF har fjernet alle transitive avhengigheter fra noe som er i 2NF. Med avhengighet forstås at ett/flere attributt bestemmer ( determinerer ) andre attributter. En transitiv avhengighet i tabell X betyr at A bestemmer B, der A ikke er en del av primærnøkkelen. Normaliseringssteget (fra 2NF til 3NF) er å lage en ny tabell Y( A, B) og heller lage kobling fra X til Y som følger: X(..., A*,...) c. Denormalisering betyr at man slår sammen tabeller som har vært dekomponert (pga. normalisering). Målet er å gi raskere svar, ved å slippe å koble to tabeller. Dette er altså en del av spørreoptimaliseringsarbeidet og kalles også kontrollert redundans. Eksempel her er at man for en person ikke bare lagrer postnummer, men også poststed (for å slippe å gjøre kobling mellom tabellene Person og Poststed). Da vil jo f.eks. Oslo lagres mange ganger i Person. Og det er kanskje akseptabelt, når en også vet at poststed endres veldig sjelden (Poststed tabellen er tilnærmet statisk).