UNIVERSITETET I OSLO



Like dokumenter
UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Repetisjon: (nesten) alt du trenger å kunne om ORM og realisering

Løsningsforslag til eksamen i IN2090 Databaser og datamodellering og INF1300 Introduksjon til databaser 6. desember :30 18:30 (4 timer)

Dagens tema: Relasjonsmodellen (funksjonelle avhengigheter og nøkler, integritetsregler) Realisering: Fra ORM til relasjoner

INF1300 Introduksjon til databaser

Dagens tema: Oppdateringsanomalier Normalformer

Repetisjon: (nesten) alt du trenger å kunne om ORM og realisering

Repetisjon: (nesten) alt du trenger å kunne om ORM og realisering

UNIVERSITETET I OSLO

Oppdateringsanomalier Normalformer

UNIVERSITETET I OSLO

IN2090 Introduksjon til databaser

INF1300 Introduksjon til databaser

Sensorveiledning for IN2090 og INF desember :30 18:30 (4 timer)

INF212 - Databaseteori. Kursinnhold

Oppdateringsanomalier. Normalformer. Institutt for informatikk INF

Oppgaver INF3100. Oversikt over innholdet

UNIVERSITETET I OSLO

INF1300 Introduksjon til databaser

Obligatorisk oppgave nr. 3 i INF1300 høsten 2011

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Relasjonsdatabasedesign

Relasjonsdatabaseteori

INF1300 Introduksjon til databaser

Databaser. - Normalisering -

UNIVERSITETET I OSLO

Plenum: Nøkler, normalformer og funksjonelle avhengigheter

Relasjonsdatabasedesign

HØGSKOLEN I SØR-TRØNDELAG

Eksamen i IBE211 Databaser Våren 2017

1. Normalisering Kommentarer til læreboka

EKSAMEN 6102 / 6102N DATABASER

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn

EKSAMEN DATABASER

Det matematisk-naturvitenskapelige fakultet. Kontroller at oppgavesettet er komplett før du begynner å besvare det.

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Repetisjon: Normalformer og SQL

Databaser: Relasjonsmodellen, del I

IN2090 Databaser og datamodellering. Databasedesign og normalformer

INF3100 Databasesystemer

Oppgaver INF3100. Oversikt over innholdet

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Det matematisk-naturvitenskapelige fakultet. Kontroller at oppgavesettet er komplett før du begynner å besvare det

Relasjonsdatabasedesign

1. Relasjonsmodellen Kommentarer til læreboka

INF3100 Databasesystemer

Integritetsregler i SQL

Normalisering. Hva er normalisering?

Normalformer or Normalisering 1NF, 2NF, 3NF, BCNF

Normalisering. Hva er normalisering?

Relasjonsdatabasedesign

Relasjonsdatabasedesign. Ekstramateriale: Normalformer utover 4NF (ikke pensum)

Relasjonsdatabasedesign (forts.)

Integritetsregler i SQL. Primærnøkler

UNIVERSITETET. Relasjonsdatabasedesign

Normalformer utover 4NF (ikke pensum)

Flere skranker i ORM Integritetsregler med «CHECK» i SQL

Relasjonsdatabasedesign

HØGSKOLEN I SØR-TRØNDELAG

Høgskolen i Telemark EKSAMEN 6102 DATABASER Tid: Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1

Høgskolen i Telemark EKSAMEN 6102 DATABASER 5602 DATABASER Tid: 9-13 (9-14 for konte-eksamen i 5602) Hjelpemidler:

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Relasjonsdatabasedesign (forts.)

Oppgaver Oppgave a: Sett opp mulige relasjoner

Oppgave 3 - normalisering

Relasjonsdatabasedesign

Normalisering. Hva er normalisering?

UNIVERSITETET I OSLO. Relasjonsmodellen. Relasjoner og funksjonelle avhengigheter. Institutt for Informatikk. INF Ellen Munthe-Kaas 1

INF1300 Introduksjon til databaser

Hva kjennetegner god relasjonsdatabasedesign? Eksempel: Grossistdatabase versjon 1

Relasjonsdatabasedesign

UNIVERSITETET I OSLO

Versjon

Transkript:

UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i INF1300 Introduksjon til databaser Eksamensdag: 1. desember 2014 Tid for eksamen: 09.00 15.00 Oppgavesettet er på 5 sider. Vedlegg: ORM 2 Graphical Notation, 5 sider Tillatte hjelpemidler: Halpin & Morgan: Information Modeling and Relational Databases. 2 A4-ark (4 sider) håndskrevne notater. Kontroller at oppgavesettet er komplett før du begynner å besvare spørsmålene. For å bestå eksamen, må del A sensureres til karakteren E eller bedre. Del A (vekt 50 %) Her skal du lage en ORM2-modell som beskriver et interesseområde knyttet til informasjon om musikere, band og konserter. Du kan dele opp ORM-modellen over flere sider, men det beste er å bruke en side pr ORM-oppgave. Ha gjerne med kommentarer i modellen. Om du mener noe er uklart i oppgaveteksten, kan du spesifisere med kommentarer i modellen hvilke antakelser du har lagt til grunn. Tegn og skriv tydelig Oppgave 1 Lag en ORM2 modell som fanger opp følgende informasjon om musikere: a) Hver musiker identifiseres av en unik id (f.eks. 2342). b) Musikere har navn (f.eks. Musiker med id 2342 har navnet Laila). Hver musiker har nøyaktig ett navn. Flere musikere kan ha samme navn. c) I tillegg kan musikere ha kallenavn. Kallenavn er entydig identifisert ved tekst. (f.eks. 'Countrykongen fra Seljord'). For eksempel musikeren med id 2342 har kallenavnet 'Countrykongen fra Seljord'. Hver musiker kan ha maks ett kallenavn, og ingen musikere kan ha samme kallenavn. Dersom informasjon om hvilket år musikeren fikk sitt kallenavn er tilgjengelig, skal systemet kunne lagre dette (f.eks. musikeren med id 2342 har kallenavnet 'Countrykongen fra Seljord'. Musikeren fikk dette kallenavnet i 2004). d) Det skal være mulig å lagre informasjon om hvilke instrumenter en musiker kan spille. (f.eks. Musikeren med id 2342 spiller gitar og munnspill). Instrumenter representeres unikt av sitt navn (f.eks. gitar, fiolin osv.). Det er mulig at noen musikere kan spille flere instrumenter, og at flere musikere kan spille samme type instrument. 1

e) Musikere kan ha sertifisering fra en musikkskole i å spille ett instrument. En musikkskole er unikt representert ved sitt navn. F.eks. musikeren med id 2342 har sertifisering fra Norges Musikkhøgskole til å spille fiolin. En musiker kan ha sertifisering i å spille ett gitt instrument fra maks en musikkskole. En sertifisering kan bare gjelde for et instrument som musikeren spiller ifølge punkt d) ovenfor. f) Musikere kan bli fast ansatt av organisasjoner. (f.eks. Musikeren med id 2342 er ansatt i Den Norske Opera). Organisasjoner er unikt identifisert av en kode (f.eks. OperaNor). En musiker kan være fast ansatt hos maks en organisasjon. Det er så klart mulig for en organisasjon å ha flere musikere fast ansatt. I tillegg er det et krav at en musiker må være sertifisert på et instrument fra en musikkskole for å være fast ansatt. g) Musikere kan eie musikkutstyr (for eksempel kan en musiker eie tre gitarer i vår sammenheng er den enkelte gitar musikkutstyr). Der er selvfølgelig mulig at en musiker eier mer enn en type musikkutstyr. Musikkutstyr kan kun ha en eier. Utstyr er representert av en unik kombinasjon av en produsent (unikt representert av en kode), en produksjonslinje (unikt representert av et nummer), og en unik id for produksjonslinjen (unikt representert av en id). Musikkutstyret (for eksempel en gitt gitar) er unikt representert av en kombinasjon av SAM (produsent), 343 (produksjonslinje), og 2898 (en unik id i denne produksjonslinjen). Oppgave 2 Utvid modellen på følgende måte med informasjon om musikkband: a) Musikkband er representert av unike navn (for enkelhets skyld antar vi at ingen band har samme navn). b) Det er mulig for en musiker å være medlem av flere band, og et band kan bestå av flere musikere. For hvert slikt musiker-band medlemskap skal en startdato for når musikeren ble med i bandet registreres. En sluttdato kan registreres når musikeren har sluttet i et band (for enkelhets skyld antar vi at en musiker kan bli med i/slutte i et band høyst én gang). c) Modellen burde også kunne fange opp informasjon om musikeres interesse for å bli medlem i et band. En musiker kan være interessert i å bli medlem i flere band, og et band kan være interessert i å rekruttere flere musikere. Selvfølgelig kan ikke en musiker ønske å bli medlem i et band som musikeren allerede er med i. d) Hvert band har maksimalt en leder. Det er mulig for en musiker å lede flere band. En musiker som leder et band, må selvsagt også være medlem av dette bandet. Oppgave 3 Utvid modellen på følgende måte med informasjon om konserter: a) Musikkband signerer kontrakter. Kontrakter representeres av en unik id. Kontrakter er for konserter. Konserter identifiseres av et unikt navn. For eksempel er kontrakten med id 1323 for konserten Gitarfestivalen signert av bandet Gitarkammeratene. En kontrakt kan maksimalt signeres av ett band. Det er mulig for et band å signere flere kontrakter. Tilsvarende er hver kontrakt knyttet til maksimalt en konsert, og en konsert kan være tilknyttet flere kontrakter. I tillegg er det slik at for hver kombinasjon av band og konsert så finnes det maksimalt en kontrakt slik at dette 2

bandet signerer denne kontrakten og denne kontrakten er for denne konserten. Det er et krav å eksplisitt bruke begrepet kontrakt i denne oppgaven, ikke begrepsdannelse. b) Musikkband spiller på konserter. Det er mulig at et band spiller på mer enn en konsert, og for en konsert at mer enn ett band spiller på konserten. For at et band skal kunne spille på en konsert må bandet ha en kontrakt for denne konserten. For eksempel, hvis bandet 'Gitarkammeratene' spiller på konserten 'Gitarfestivalen' så må 'Gitarkammeratene' ha signert en kontrakt for konserten med f.eks. id 1323 og denne kontrakten gjelder 'Gitarfestivalen'. c) Musikkband stemmes over til en rang/plassering på konserter (f.eks. av publikum etter hver konsert). Plasseringer er entydig representert av tall (f.eks. plass 1, 2, 3 osv.). Et band kan stemmes inn til høyst én plassering på samme konsert (f.eks. kan ikke "Gitarkammeratane" ha både plassering 1 og 2 på konserten "Gitarfestivalen"). I tillegg er det et krav at flere band ikke kan stemmes inn til samme plassering i samme konsert (f.eks. er det umulig at både "Gitarkammeratane" og "Telemarkingane" stemmes til 1. plass på konserten "Gitarfestivalen"). Det er opplagt at band som det stemmes over på en konsert må ha spilt på konserten.. Oppgave 4 Grupper ORM2-modellen nedenfor til et relasjonsdatabaseskjema. Det resulterende relasjonsskjema bør være korrekt (tilsvarer ORM2 konseptuelle skjema), effektivt (unngå redundans og begrens antall tabeller), og klart (lett å forstå). Bruk grupperingsalgoritmen for å generere et slikt relasjonsdatabaseskjema. For hver relasjon, angi relasjonens navn og navnet på hvert attributt. Du skal ikke spesifisere datatype/domene for attributtene og heller ikke bruke SQL i denne oppgaven. Sett én strek under primærnøkler. Marker andre kandidatnøkler med to streker. Bruk piler for fremmednøkler. For realisering av underbegreper, del attributtene i over- og underbegreper i denne oppgaven. 3

Del B SQL (vekt 50 %) Oppgave 5 a) Skriv create-setninger som oppretter tabellene fra skjemaet du laget i forrige oppgave. b) Skriv en select-setning som sjekker om det finnes tupler som bryter delmengdeskranken i modellen i oppgave 4. Resten av oppgavene er mot et databaseskjema som modellerer informasjon som minner om interesseomådet fra del A. Det frarådes at du modellerer for/etter dette skjemaet i oppgave 4. Person (pid, navn, kallenavn, tlfnr, postadresse) navn er ikke entydig. (Navn, kallenavn) er entydig. Kallenavn kan ikke være null. tlfnr er unikt for en person. Spiller (pid, instr) Dette er en tabell med informasjon om hvilke musikkinstrumenter en person (med personid pid) spiller. KonsertInfo (kid, dato, sted, arrangør) inneholder informasjon om konserter: konsertens id, dato, sted og arrangør. Konsert (pid, kid, instr) Denne relasjonen mellom person, konsert og instrument angir at en person har spilt på en konsert med instrumentet instr. Merk at en person kan ha brukt et instrument på en konsert, selv om dette instrumentet ikke finnes for denne personen i tabellen Spiller. Et slikt instrument kaller vi et fremmedinstrument. Konsert inneholder informasjon om både instrumenter og fremmedinstrumenter. Når det i det følgende er snakk om personer (musikere) som spiller et instrument regnes ikke evt. fremmedinstrumenter fra denne tabellen med. Alle attributter er VARCHAR. Datoer er på formen ÅÅÅÅMMDD, f.eks. 20091231. Primærnøkler er understreket. Oppgave 6 a) Skriv ned alle kandidatnøkler i relasjonen Person. b) Hvilke av disse attributtmengdene er ikke en supernøkkel i Person? 1 (navn, tlfnr) 2 (navn, postadresse) 3 (pid, navn, kallenavn, tlfnr, postadresse) 4 (navn, kallenavn, postadresse) 5 (kallenavn, postadresse) 6 (tlfnr, postadresse) c) Finnes det funksjonelle avhengigheter (FD) i Person som bryter med BCNF? Nevn i såfall hvilke. 4

d) Hvilken normalform er Person på? I de neste oppgavene skal du skrive select-setninger og views. Definer gjerne views først for å gjøre spørringene mer lettleste. Der det står at du skal lage et view, blir det litt trekk dersom du bare skriver select-setningen. Oppgave 7 Skriv views/select-setninger som inneholder/skriver ut følgende informasjon: a) et view med navn MusikereITroms med kallenavn og telefonnummer for personer som har en adresse som inneholder ordet Troms eller inneholder en tekststreng med 4 tegn som starter med tegnet 9. b) navn på musikere og hvilke instrumenter de spilte på på konserter i Oslo (sted) i november 2014. Ta også med steder som f.eks. Oslo spektrum eller Rockefeller Oslo. c) pid, navn og kallenavn for alle personer som ikke har et unikt navn. d) antall musikere som spiller bare ett instrument. e) oversikt over alle musikere (navn) som spiller minst 5 instrumenter og som aldri har deltatt på konsert i desember måned. f) et view med antall instrumenter en musiker (pid) spiller, inklusive evt. fremmedinstrumenter spilt på konserter. g) navn og kallenavn på alle musikere som spiller alle instrumenter (ikke regn med evt. fremmedinstrumenter). h) navn på musiker som spilte på mer enn ett fremmedinstrument på en konsert. Ta med navn på fremmedinstrumentene samt dato og sted for konserten. i) navn og fremmedinstrument for personer som ikke spiller noe instrument og som har deltatt på mer enn 10 konserter med dette fremmedinstrumentet j) navn på musikere som har spilt på alle konserter i Oslo i perioden 20140710 20140719 (fra og med 10. juli til og med 19. juli 2014). k) et view med pid og navn for personer som har opptrådt med færre enn 4 instrumenter på minst én konsert. Kall dette viewet Max3instr. l) et view med informasjon om personer som har spilt (minst) et fremmedinstrument på en konsert. Kall dette viewet FremmedSpiller. m) navn på alle musikere som spiller minst fire instrumenter (fra tabellen Spiller) og som har spilt på samtlige av disse og ingen fremmedinstrumenter på alle konserter de har vært medvirkende. 5