Eksamensoppgaver. Og for all del: Vær kritiske til de løsningsforslagene vi presenterer! Vi påstår ikke at de er optimale.

Transkript

1 Eksamensoppgaver Under følger eksempler på tre eksamensoppgaver innen modellering og tre innen relasjonsdatabaser samt løsningsforslag. Merk at det er nettopp dette løsningsforslagene er: Forslag til løsninger. Særlig modelleringsoppgaver kan ha flere vidt forskjellige og likevel likeverdige løsninger. Det frarådes på det sterkeste at dere nøyer dere med å lese teksten på eksamenssettene og deretter lese gjennom løsningsforslagene; dere blir ikke bedre til å besvare eksamensoppgaver av det. Eneste måte å bli bedre på, er å først prøve seg på eksamenssettene, og deretter se på løsningsforslagene og sammenlikne med hva dere selv har gjort. Og for all del: Vær kritiske til de løsningsforslagene vi presenterer! Vi påstår ikke at de er optimale. Innhold Eksamensoppgaver... 1 Eksamenssett 1: Julegaver modellering... 2 Eksamenssett 2: Konsulentdatabase SQL og normalisering... 4 Eksamenssett 3: Maskindatabasen på Ifi modellering... 8 Eksamenssett 4: Maskindatabasen på Ifi SQL og normalisering Eksamenssett 5: Matoppskrifter modellering Eksamenssett 6: Matoppskrifter SQL og normalisering Løsningsforslag julegaver Løsningsforslag konsulentdatabase Løsningsforslag maskindatabasen på Ifi modellering versjon Løsningsforslag maskindatabasen på Ifi modellering versjon Løsningsforslag maskindatabasen på Ifi SQL og normalisering Løsningsforslag matoppskrifter modellering Løsningsforslag matoppskrifter SQL og normalisering

2 Eksamenssett 1: Julegaver modellering (Fra eksamensoppgave i IN111 Filbehandling 1985) Etter å ha mottatt hauger av klagebrev på julegavetildelingen i fjor (tante Laura fikk en tube barberkrem, og onkel Fredrik, som er 72 år og innbarket ungkar, fikk tre sett strømpebukser, samt et abonnement på "Det nye"), har Julenissen bestemt seg for å modernisere virksomheten og ta i bruk et databasesystem. Julenissen har en sentral gavekatalog hvor alle tenkelige varer er listet opp. Hver gaveartikkel har et entydig gavenummer (f.eks. betyr GR grått silkeslips, 110cm). Jullenissen ønsker å lagre en beskrivelse av hver gaveartikkel og synes vi bør sette av 40 tegn til dette. Gavene blir lagt på lager når de er kjøpt. (Det er 7 lagre og de 7 små dvergene er lagersjef for hvert sitt.) Julenissen vil vite på hvilket lager gaven ligger, hvor mange eksemplarer han har på lager, navnet på produsenten, produsentens telefonnummer, og produsentens banknummer eller -numre (hvis han har noen, da). Julenissen har god hjelp av lederreinen Rudolf når han skal dele ut gavene. Rudolf vet alltid nøyaktig på meteren hvor langt han er fra Nordpolen og hvor langt han er fra null-meridianen. I tillegg til denne lengde- og breddebeskrivelsen har Julenissen notert seg i hvilken etasje hvert sted han skal besøke ligger. Disse tre tallene bestemmer besøksstedene entydig. For hvert sted har han en liste over navnene til dem som bor der. Julenissen bruker helst bare fornavn, men må av og til ta med kjælenavn o.l. for å kunne skille alle med samme bopel. Julenissen mener han kan klare seg med 20 tegn totalt til navnet. Hovedhensikten med databasesystemet er å holde rede på hvem som får hva av hvem. Julenissen er nemlig så beskjeden at han som oftest setter en merkelapp med navnet på en giver på presangene. Julenissen mener derfor at systemet må holde rede på hver eneste presang som skal deles ut. Han vil vite hva som blir gitt, hvor mange eksemplarer (f.eks. 6 kjøkkenglass), hvem som får presangen og hvem som har gitt den. Dessuten vil han ta vare på årstallet for å tidfeste hvilken jul dette gjelder. Julenissen ønsker under planleggingen av gaveutdelingen å kunne få svar på hvilke gaver en gitt person kommer til å få, og hvilke gaver en gitt person kommer til å gi. Ved begge disse spørsmålene vil han også ha svar på hva de henholdsvis fikk og ga i fjor. Etter jul skal han lage oversikter over hvem som fikk en gitt gave og totaloversikter over hvor mange eksemplarer av hver gave han har delt ut. 2

3 Oppgave 1 Hvordan ser datamodellen for julenissens databasesystem ut? Oppgave 2 Grupper datamodellen til et relasjonsdatabaseskjema. For hver relasjon, angi navn på relasjonen og attributtnavn. Marker primærnøkler med én understrekning og eventuelle andre kandidatnøkler med to. Angi fremmednøkler. (Ikke bruk SQL i denne delen, og ikke ta med datatyper. Undertrykte begreper skal ikke tas med.) (Slutt eksamenssett 1) 3

4 Eksamenssett 2: Konsulentdatabase SQL og normalisering (Fra eksamensoppgave II i INF1300 Introduksjon til databaser 2007) Vi skal se på en database som brukes av et datakonsulentfirma til å registrere kunder, prosjekter, ansatte og deres timeforbruk fordelt på prosjekter. Firmaet er organisert i tre avdelinger: Salg, Prosjekt og Administrasjon med hver sin avdelingsleder. Øverste sjef har tittelen «Direktør». Salg er den minste avdelingen. Den har to oppgaver: Salg av prosjekter rettet mot en bestemt kunde og generell markedsføring. Prosjekt er den klart største avdelingen. Det er der prosjektene utføres. Alle ansatte har en entydig ansattkode på fire tegn som vanligvis består av de to første bokstavene i for- og etternavnet til den ansatte. Dette gjør det lett å huske ansattkodene, og de brukes i all skriftlig intern kommunikasjon i firmaet. Hver ansatt er ansatt i én avdeling. Avdelingslederne er ansatt i den avdelingen de leder; direktøren er ansatt i administrasjonen. Om alle ansatte registrerer vi navn, avdeling og antall avspaseringstimer de har til gode. Prosjektene har kode og navn, og de har alltid en prosjektleder og en kunde som har bestilt prosjektet. For å få samme håndtering av interne og eksterne prosjekter, er avdelingene lagt inn i kunderegisteret. Alle kunder er tildelt en ansvarlig selger. Dessuten registrerer vi siste uke de har fått faktura for. Alle ansatte må føre timelister. Så snart som mulig leverer de timelisten for forrige uke til avdelingslederen som kontrollerer og godkjenner listen før den leveres til administrasjonen for registrering. Avdelingslederne leverer sine timelister til direktøren, som leverer sin timeliste til internrevisoren, en vanlig ansatt i administrasjonen. Dersom den som normalt kontrollerer en timeliste er fraværende, leveres listen til en annen avdelingsleder eller til internrevisoren. Arbeidstiden er åtte timer pr dag, hvorav en halvtime går bort til matpause. Dermed blir netto arbeidstid 7,5 timer pr. dag. Absolutt alle timer på timelistene skal knyttes opp til et prosjekt. Prosjektene har entydige 8-tegns prosjektkoder. Første tegn avgjør hvilken type prosjekt det er. Det er mange prosjekttyper, men vi skal hovedsakelig få bruk for disse fire: K prosjekt som faktureres til kunder S salgsprosjekt (timer brukt på et salg/anbud) M markedsføringsprosjekt (timer brukt på markedsføring) I internprosjekt (timer brukt på kurs, møter, føring av timelister, o.l.) Dessuten har vi et spesielt prosjekt med prosjektkode A som brukes for å registrere avspasering av overtid. 4

5 Fysisk er timelisten et ferdig trykket skjema. Øverst er det ett felt for ansattkoden og ett for ukenummeret. Ukenummeret er et sekssifret tall der de fire første sifrene er årstallet og de to siste ukenummeret. I tillegg er det et felt for ansattkoden til den som kontrollerer listen. Resten av skjemaet er en tabell med følgende kolonner: Lnr 2-sifret linjenummer Dag ett siffer (1 = mandag, 2 = tirsdag,..., 7 = søndag) Prosjekt 8-tegns prosjektkode Timer antall timer brukt på prosjektet (3 siffer, se nedenfor) O-kode 1-tegns overtidskode som har 3 lovlige verdier: o <blank> normaltimer (ikke overtid) o A overtid som skal avspaseres o B overtid det skal betales overtidsgodtgjørelse for Timer lagres som et 3-sifret heltall der siste siffer egentlig står bak komma. Eksempel: Verdien 75 betyr 7,5 timer. Vær også oppmerksom på følgende regler: Hver arbeidsdag skal det registreres nøyaktig 7,5 normaltimer Lørdager og helgedager skal det bare registreres overtid B-overtid kan bare registreres på K-prosjekter Avdelingsledere og direktøren kan ikke ha B-overtid Avspasering (prosjektkode A) føres alltid som normaltimer En uke hvor alle har fått sine timelister registrert, kalles fakturerbar. Ansattes timelister registeres kronologisk, så alle uker før en fakturerbar uke er selv fakturerbare. 5

6 Oversikt over datastrukturen (Tabellnavn og attributter) Kunde Kundenr integer K-navn varchar(40) Salgskontakt char(4) SistFakturert integer Prosjekt P-kode P-navn P-leder Kundenr char(8) varchar(40) char(4) integer Avdeling AvdNavn varchar(15) Leder char(4) Ansatt Anskode char(4) Navn varchar(40) Avdeling varchar(15) Flexikonto integer Timeliste Anskode char(4) Uke integer Kontrollør char(4) Timelistelinje Anskode char(4) Uke integer Lnr integer Dag integer Prosjekt char(8) Timer integer O-kode char(1) Merk: NULL er ikke tillatt i noe attributt 6

7 Oppgave 1 Skriv SQL-kode for å definere tabellen Timeliste. Ikke glem primær- og fremmednøkler! Oppgave 2 Anta at uttrykket X%Y i din dialekt av SQL gir deg resten når du dividerer heltallet X med heltallet Y. Bruk dette til å finne ansattkode, ukenummer og linjenummer på alle timelistelinjer hvor siste siffer i Timer hverken er 0 eller 5. Oppgave 3 Finn ansattkode, ukenummer og linjenummer på alle timelistelinjer hvor avspasering ikke er ført som normaltimer, avspaseringskode B er ført på et prosjekt hvor prosjektkoden ikke begynner med K, eller det er ført normaltimer på en lørdag eller søndag. Oppgave 4 Finn alle registrerte kombinasjoner av ansattkode, ukenummer og dagnummer hvor summen av normaltimer hverken er 0 eller 7,5 timer. Oppgave 5 Finn prosentvis fordeling av timer brukt på salg, markedsføring og annet i salgsavdelingen i Oppgave 6 Skriv en UPDATE-setning som for en gitt uke oppdaterer attributtet Flexikonto for alle ansatte (dvs. A-overtid legges til og avspasering trekkes fra den forrige verdien i attributtet, i henhold til innlevert timeliste for uken). Oppgave 7 Du skal lage datagrunnlaget for fakturering av en kunde: Fra kunden sist ble fakturert til og med siste fakturerbare uke skal du lage en liste med navn på prosjekter og konsulenter (personer i Prosjekt som har ført timer på prosjektene) og antall timer hver konsulent har arbeidet på prosjektet i fakturaperioden. Sorter listen på prosjektkode og deretter på synkende timetall. (Du kan gå ut fra at fakturaperioden ikke inneholder uker fra to forskjellige år.) Oppgave 8 Hvordan kan du enkelt utvide løsningen din av oppgave 7 til å lage fakturagrunnlag for alle kundene? (Du trenger ikke skrive SQL-kode.) Oppgave 9 Du skal denormalisere datastrukturen ved å slå sammen (joine) tabellene Kunde og Prosjekt. Hvilke attributter får den nye tabellen, og hva blir primærnøkkel i den? Hvilken normalform har den nye tabellen (begrunn svaret)? (Slutt eksamenssett 2) 7

8 Eksamenssett 3: Maskindatabasen på Ifi modellering (Fra eksamensoppgave I i INF1300 Introduksjon til databaser 2008) Ifi har mye datautstyr, og mer skal det bli. Når vi flytter inn i nytt hus om snaut to år, skal det aller meste av utstyret fornyes og registreres i en utstyrsdatabase. Planlegging av denne databasen må starte nå. Grunnet mange andre arbeidsoppgaver og forestående permisjon, er driftsavdelingens kapasitet til å drive slik egenutvikling redusert. Derfor blir det din oppgave å designe denne databasen. Utstyret som skal registreres, er alt datautstyr pluss alt utstyr som har serienummer og som er lett å omsette, f.eks. prosjektører og mobiltelefoner. Datautstyr er i all hovedsak maskiner og skjermer. Tastatur, mus og ekstrabatteri til bærbare maskiner regnes som rekvisita og skal ikke registreres, mens dockingstasjoner til bærbare maskiner skal legges inn i databasen. Maskiner er mangeartet. De dekker alt fra små, bærbare maskiner opp til store filtjenere som står på spesielle maskinrom. Enkelte maskiner har tilleggsutstyr, f.eks. dockingstasjon til bærbare, og det er viktig at databasen klarer å holde styr på hvilket tilleggsutstyr som til enhver tid hører til en gitt maskin. Legg i denne sammenheng merke til at maskiner slett ikke trenger å ha tilleggsutstyr, og for de som har det, vet vi i utgangspunktet ikke hvor mange ulike deler det er snakk om. Dessverre har ikke alt utstyr som skal inn i databasen et unikt serienummer. F.eks. er ikke alle skjermer fra Dell utstyrt med serienummer. Oppgave 1 Lag et forslag til hvordan alle de ulike utstyrstypene skal representeres. Ifi har et vedtatt tildelingsregime for utstyr. I korte trekk går det ut på at Ifi forplikter seg til å utstyre alle ansatte med én, og bare én, arbeidsplassmaskin. Sagt på en annen måte: Alle ansatte skal disponere en maskin, og ingen skal dele maskin. En normal arbeidsplass er en bærbar maskin med ekstern skjerm og dockingstasjon, men ikke alle har ekstern skjerm og dockingstasjon. Det er også mulig å ha en vanlig stasjonær maskin som arbeidsplassmaskin. De som ønsker utstyr utover dette, må selv sørge for finansiering, men da kan de kjøpe så mye utstyr som de har penger til. Ifi vil sørge for driften. Noen ansatte arbeider deltid, typisk en dag i uken. Disse har gjerne tilgang til et kontor som de deler med andre deltidsansatte som er der på andre ukedager. Hvis et slikt kontor har en stasjonær maskin, regnes den som disponert av Ifi sentralt. Databasen må altså lagre finansieringskilden for alt registrert utstyr. Ifi/RU (Ressursutvalget ved Ifi) er den største kilden. Andre kilder er prosjektmidler (i så fall må prosjektet nevnes med navn), faggruppemidler (faggruppene har egne navn), personlige tiltak (dvs. Midler disponert av enkeltpersoner) m.fl. Videre er det viktig at databasen sikrer at hver enkelt person bare får én arbeidsplassmaskin finansiert av Ifi/RU. De kan imidlertid ha andre maskiner finansiert av Ifi/RU, f.eks. tungregnetjenere, tjenere for ytingsmålinger på databaser o.a. Laboratorieutstyr og maskiner på terminalstuene regnes som disponert av instituttet sentralt, og de er derfor ikke underlagt dette tildelingsregimet, men også disse maskinene skal registreres i databasen. 8

9 Oppgave 2 Lag en ORM-modell som dekker plassering og finansiering av det utstyret som skal registreres i databasen. Pass på at modellen sikrer at Ifis tildelingsregime overholdes. Du trenger ikke ta med de representasjonsmåtene du beskrev i oppgave 1 i modellen din. For å kunne installere en maskin korrekt, må det lagres informasjon om hvilket operativsystem den skal kjøre, og på hvilket nivå den skal brukes (ansatt/master eller bachelor). Gitt operativsystem og nivå, skal det også automatisk dukke opp informasjon om hvor installasjonsimaget ligger og en liste over programmer som skal legges inn som en standardpakke. Oppgave 3 Utvid ORM-modellen din slik at databasen kan registrere brukernivå, operativsystem og innholdet i den standardpakken med programmer som skal legges inn. Dessverre hender det fra tid til annen at utstyr ryker slik at vi må ringe etter reparatør. På det aller meste utstyret har vi tre års service-avtale, men på en del av tjenerne har vi fem år. Databasen må altså kunne lagre startdato for serviceavtalen og lengden på serviceperioden. Startdatoen er den dagen utstyret kom inn i huset. Hver serviceavtale angir én av to måter utstyret kan repareres på. Den ene er at reparasjonen blir gjort på stedet ved å bytte ut den defekte delen. Dette kalles NBDOS (Next Business Day On Site). Dette gjelder bl.a. maskiner. Den andre varianten er at hele utstyrsenheten blir byttet ut med en ny eller reparert enhet av samme type. Dette kalles NBDNU (Next Business Day New Unit). Databasen må kunne lagre disse to verdiene, slik at den som feilmelder utstyr kan stille de rette kravene overfor supporttjenesten hos leverandørene. De har dessverre ikke alltid helt oversikt over hva slags avtaler de har med oss. En del av utstyret er av veldig god kvalitet og går uten feil helt til det blir byttet ut med noe nytt. Noe utstyr må ha en eller to reparasjoner i driftstiden sin, og av og til støter vi på skikkelige mandagseksemplarer. Slike maskiner må repareres mange ganger, ofte for den samme feilen. Ikke sjelden må driftsavdelingen feilmelde en maskin samme dag den er forsøkt reparert. Dog blir det aldri utført mer enn en reparasjon pr maskin pr dag. Databasen skal kunne lagre reparasjonshistorikk, d.v.s. alle reparasjoner utført på en gitt utstyrsenhet, og det gjelder ikke bare maskiner. For hver slik reparasjon skal det lagres opplysninger om hvem som meldte feilen, feilsymptom, reparasjonsreferansenummer (som vi får oppgitt av supporttelefonen hos de ulike leverandørene), datoen feilen ble reparert, og om dette løste problemet. Oppgave 4 Utvid ORM-modellen din slik at databasen kan registrere informasjon om pågående og avsluttede reparasjoner. Det er ganske mange som er interesserte i opplysninger om utstyr som blir kjøpt inn for norske skattepenger. Riksrevisjonen med Jørgen Kosmo i spissen krever at UiO har rutiner som sikrer at alle innkjøp skjer i samsvar med gjeldende avtaler og, for UiOs del, på billigste måte. For å kunne etterprøve at Ifi holder seg til regelverket, må databasen kunne lagre opplysninger om ordrenummer og fakturanummer. Sammenhengen er at et ordrenummer omfatter mange utstyrsenheter. En gitt ordre blir av og til levert i flere omganger, og da blir det en 9

10 faktura (med eget fakturanummer) for hver dellevering. Hver faktura består normalt av flere linjer, og noen ganger må selv fakturalinjer splittes opp fordi de skal belastes mer enn én konto i universitetsregnskapet. Et typisk eksempel er kjøp av 20 like maskiner hvor 15 kjøpes av Ifi/RU mens de resterende skal betales med ulike prosjekt- og gruppemidler. Oppgave 5 Utvid ORM-modellen din slik at databasen kan håndtere ordre og fakturaer. Legg vekt på å utforme modellen slik at det blir enkelt å lage et applikasjonsprogram som minimaliserer mengden av data som brukeren må registrere. Oppgave 6 Grupper ORM-modellen til et relasjonsdatabaseskjema. Resultatet skal presenteres som en liste av relasjoner. For hver relasjon skal du oppgi relasjonsnavnet og navn på hvert attributt. Du skal ikke angi representasjoner (datatyper) på attributtene og heller ikke bruke SQL. Attri-buttene i primærnøkkelen skal være understreket. Under-trykte referanserelasjoner skal ikke være med i listen. Beskriv til slutt tre fremmednøkler du har i databaseskjemaet ditt (hverken flere eller færre). (Slutt eksamenssett 3) 10

11 Eksamenssett 4: Maskindatabasen på Ifi SQL og normalsering (Fra eksamensoppgave II i INF1300 Introduksjon til databaser 2008) Del I Scenario: Timeregnskap I en organisasjon fører de ansatte hver dag ved arbeidsdagens slutt timer på de prosjektene de har arbeidet på i løpet av dagen. Til dette brukes følgende tabell (primærnøkkelen er understreket): Prosjekttimer(ansattID, prosjektid, dato, timer, status, godkjennerid) Ved begynnelsen av hver ny uke går enten prosjektleder eller en stedfortreder igjennom samtlige nye timeanførsler for sitt prosjekt. Nye timer kan gjenkjennes ved at de har "ny" i attributtet status (og "null" i attributtet godkjennerid). De timeanførslene som godkjennes, får endret status til "godkjent". For de timene som ikke godkjennes, settes status til "merknad", og den prosjektmedarbeideren som har ført timene, får en melding om å sjekke og eventuelt rette timeantallet. Uansett legges ansattid for den som gjennomgikk timelistene, inn i godkjennerid. Når timetallet for de postene som fikk en merknad er revurdert av medarbeideren, kan status bli satt til "attestert" av prosjektleder, og prosjektleders ansattid legges i godkjennerid. Det er bare prosjektleder selv som kan endre status på de postene som har fått en merknad. Dette betyr at prosjektid, dato og status sammen bestemmer verdien i godkjennerid. Oppgave 1 (10%) Oppgave 2 (15%) Bruk SQL til å lage en liste over prosjekttimer med status "merknad". Hver linje skal bestå av prosjektid, ansattid, dato og antall timer. Sorter listen på prosjektid og ansattid. Angi hvilke funksjonelle avhengigheter (FDer) som gjelder i Prosjekttimer, og gi et begrunnet svar på hvilken normalform tabellen har. Del 2 Scenario: Maskindatabasen på Ifi Det finnes mange mulige løsninger på hvordan maskindatabasen skal utformes. Vi skal her ta utgangspunkt i én mulig løsning og se på noen av de tabellene som inngår i denne løsningen: Leverandør(navn, adresse, e-post, sentralbord, supporttelefon) Ordre(leverandør, ordrenr, dato) Ordrelinje(leverandør, ordrenr, linjenr, varenr, antall) Faktura(leverandør, fakturanr, ordrenr, leveringsdato, beløp, konto) 11

12 Fakturalinje(leverandør, fakturanr, linjenr, varenr, antall, stykkpris, konto) Detaljlinje(leverandør, fakturanr, linjenr, antall, konto) Her er primærnøklene understreket. Attributtene med navn konto sier hvilken konto i universitetsregnskapet som skal belastes. I Faktura skal konto alltid oppgis. I Fakturalinje skal konto bare oppgis hvis den er forskjellig fra konto i Faktura. Tabellen Detaljlinje brukes bare når deler av en fakturalinje skal belastes en annen konto enn resten av fakturalinjen. Husk at hver ordre kan bli oppfylt med flere delleveranser og at det er eksakt én faktura pr. delleveranse. Oppgave 3 (10%) Oppgave 4 (10%) Gå ut fra at både leverandør, fakturanr og konto har datatype VARCHAR(30). Definer tabellen Detaljlinje med SQL. Husk å definere primær- og fremmednøkler. Beskriv fremmednøkkelen fra Fakturalinje til Faktura og forklar hva databasehåndteringssystemet må gjøre for å håndheve den. De følgende oppgavene skal løses med SQL. Det er lov å bruke views. Oppgave 5 (10%) Oppgave 6 (10%) Oppgave 7 (15%) Oppgave 8 (20%) Lag en liste over navn og e-postadresse på leverandører og det totale beløp de har fakturert for i år. Sorter listen slik at de som har har solgt mest, kommer først. For en gitt faktura, kontroller at totalbeløpet på fakturaen stemmer med det som er oppgitt på fakturalinjene. Skriv ut differansen mellom fakturaens totalbeløp og det beløpet fakturalinjene indikerer hvis tallene ikke stemmer overens. Lag en liste over ordre som har minst en delleveranse, men hvor ikke hele ordren er levert. For en gitt konto, finn ut hvor mye den er belastet for i år. (Slutt eksamenssett 4) 12

13 Eksamenssett 5: Matoppskrifter modellering (Fra eksamensoppgave I i INF1300 Introduksjon til databaser 2009) En hardbarket realist av den gamle skole med utallige laboratorietimer bak seg, har besluttet seg for å ta opp en ny hobby: matlaging. Hittil har hans største prestasjoner på området vært steking av speilegg og frosne hamburgere og oppvarming av ferdige porsjonspakninger til å sette rett inn i mikrobølgeovnen. På siste legekontroll fikk han imidlertid beskjed om at hamburgere med egg 4 dager i uken ble litt vel ensidig i lengden. Vår venn er en grundig person som gjør ting ordentlig og profesjonelt hvis de i det hele tatt skal gjøres. Følgelig gikk han til verket som en sann realist og begynte med å anskaffe nødvendig faglitteratur: Han kjøpte inn flere store kokebøker og var til og med så heldig å få overta Fogtdals matleksikon i 21 bind fra en gammel tante som nylig var kommet på pleiehjem. Klassikerne Hanna Winsnes (Man tager 2 halve Svinehoveder...) og Schønberg Erken ble heller ikke glemt. Han satte opp bokhylle på kjøkkenet, anskaffet en ringperm til oppskrifter fra aviser og liknende, skaffet seg noen pipetter, et litermål og en skikkelig vekt for måling av råvarer, og etter et nærmest ruinerende raid i ymse kjøkken- og interiørbutikker, var han klar til innsats. Da kom sjokket: Han, med sin erfaring fra laboratoriearbeid både innen organisk og uorganisk kjemi, forsto ikke den enkleste oppskrift! Hør bare: "I en halv kopp mel blandes et kryddermål allehånde." Mel visste han hva var. Allehånde var tydeligvis et krydder, men hvor mye er et kryddermål, og hvor stor er en kopp? Det gikk minst 15 av hans små kaffekopper i den største tekoppen hans. Dette var høyst uvitenskapelig! Vår venn bestemte seg øyeblikkelig for å lage et lite informasjonssystem for å holde orden på nødvendige data om oppskrifter. (Det var akkurat plass til en Mac ved siden av mikrobølgeovnen.) For det første må systemet kunne gi svar på hvor mye alle enheter blir, omregnet til SI-mål 1. Eksempler: Hvor mange ml er et kryddermål? Eller en kopp? Hva skal termostaten stå på når oppskriften sier: "Stekes i middels varm ovn i minutter"? Dessuten er det greit å vite at et kryddermål er en 1/5 teskje og at dette faktum skrives slik i faglitteraturen: "1 krm = 1/5 ts". Dernest vil han gjerne ha et register over de oppskriftene han har i utklippsboken (ringpermen) og et erfaringsregister over de matrettene han har laget. 1 SI står for le Système international d'unités, eller Det internasjonale enhetssystemet; det er en videreføring av det metriske systemet. 13

14 Utklippene identifiseres med et løpenummer innenfor hver dato. Han vil lagre informasjon om hvem han har fått oppskriften fra og eventuelt hvilken avis den er klippet fra. Han vil også lagre hvilke ingredienser som inngår i hver rett og hvor lang tid han må regne med på å bruke for å lage retten. Han lagrer selvfølgelig rettens navn, og han bestemmer seg for at han vil ha mulighet for å skrive inn spesielle kommentarer og hint i forbindelse med retten i databasen. Dessuten vil han altså lagre sine erfaringer med de enkelte rettene. For de rettene som står i utklippsboken, er det for så vidt greit. For disse har han lagret en liste over alle ingrediensene. Det er litt verre med oppskrifter fra kokebøkene. Da må han skrive inn disse i databasen første gang han prøver dem. Problemet er hvordan disse oppskriftene skal identifiseres. Systemet med utklippsdatoen passer ikke inn her. På den annen side er det klønete å ha to forskjellige måter å referere til en rett på, avhengig av om oppskriften er fra en kokebok eller et utklipp. I erfaringsdatabasen må han selvfølgelig ha med datoen han lagde retten. Han vil også ha med nøyaktig mål på hver ingrediens og hvor lang tid de enkelte fasene tar. (Eksempel: For brød noterer han hevingstid for deigen, tid for heving etter at brødene er formet og steketid.) Dessuten er han svært opptatt av å vite hvilke kryddere han har brukt og hvor mye av hvert. Videre vil han kunne notere sine inntrykk av hvorvidt retten ble vellykket, og eventuelt hva som bør rettes på til neste gang. De gangene han lager mat til gjester, vil han også ta med informasjon om hvilke gjester han hadde og hvilke drikkevarer han serverte. Hensikten er å finne ut hva han serverte forrige gang han hadde en gjest på besøk. Slik håper han å unngå å servere det samme gang etter gang. Oppgave 1 (15%) Lag et forslag til hvordan de forskjellige typene oppskrifter skal representeres. Tegn tilhørende ORM-diagram. Oppgave 2 (20%) Lag en ORM-modell som beskriver innholdet i en oppskrift, dvs. ingredienser og fremgangsmåte. Oppgave 3 (25%) Lag en ORM-modell for erfaringsdatabasen, dvs. det som skal til for å beskrive faktiske forsøk på tilberedning av oppskrifter. Oppgave 4 (20%) Lag en ORM-modell for å holde rede på hvilke gjester som har vært invitert, når, og hvilke menyer som er blitt servert dem. 14

15 Oppgave 5 (5%) Lag en ORM-modell som beskriver forskjellige måleenheter, hvilken/hvilke notasjon(er) som brukes, og konverteringer mellom dem. Oppgave 6 (15%) Grupper ORM-modellen til et relasjonsdatabaseskjema. For hver relasjon, angi relasjonens navn og navnet til hvert attributt. Du skal ikke angi datatyper for attributtene, og ikke bruke SQL i denne oppgaven. Understrek primærnøklene. Undertrykkede relasjoner skal ikke være med i listen. Beskriv tre av fremmednøklene som gjelder i databaseskjemaet ditt (hverken flere eller færre). (Slutt eksamenssett 5) 15

16 Eksamenssett 6: Matoppskrifter SQL og normalisering (Fra eksamensoppgave II i INF1300 Introduksjon til databaser 2009) Kort sammendrag av scenariet fra første deleksamen: En hardbarket realist har laget et informasjonssystem for å holde rede på matoppskrifter og fra hvilke kokebøker de enkelte oppskriftene er hentet. For hver oppskrift er det en liste over de ingrediensene som inngår i oppskriften, hvor mye av hver ingrediens og hva slags måleenhet som er brukt. Dessuten inneholder informasjonssystemet hvilke gjester han har invitert og når, de menyene han har servert dem, hvilke retter/oppskrifter som inngikk i menyen, hvilke drikkevarer som ble servert til de enkelte rettene, og i hvilken rekkefølge de enkelte rettene ble servert. Det finnes mange mulige løsninger på hvordan en slik database skal utformes. Vi skal her ta utgangspunkt i én mulig (litt forenklet, og ikke perfekt) løsning og se på noen av de tabellene som inngår i denne løsningen: Oppskrift(oppskriftsid, tittel, fremgangsmåte, bokid, sidenr, boktittel) Ingrediensoversikt(oppskriftsid, ingrediens, mengde, måleenhet) Meny(menyid, menydato) Menylinje(menyid, rettnr, oppskriftsid, drikke) Gjesteliste(gjest, menydato) Her er primærnøklene understreket. I Meny er menydato kandidatnøkkel; det er altså slik at menyid bestemmer menydato entydig og menydato bestemmer menyid entydig fordi det aldri er to selskaper samme dag. I Oppskrift bestemmer bokid attributtet boktittel entydig. Fremmednøkler er angitt ved likelydende attributtnavn; f.eks. er oppskriftsid i Ingrediensoversikt fremmednøkkel til oppskriftsid i Oppskrift. Oppgave 1 (vekt 10%) Gå ut fra at både menyid, rettnr og oppskriftsid har datatype INTEGER, mens drikke har datatype VARCHAR(30). Definer tabellen Menylinje med SQL. Husk å definere primær- og fremmednøkler. Oppgave 2 (vekt 15%) Angi hvilke funksjonelle avhengigheter (FDer) som gjelder i Oppskrift, og gi et begrunnet svar på hvilken normalform tabellen har. Oppgave 3 (vekt 5%) Beskriv fremmednøkkelen fra Gjesteliste til Meny og forklar hva databasehåndteringssystemet må gjøre for å håndheve den. 16

17 De følgende oppgavene skal løses med SQL. Det er lov å bruke views. Oppgave 4 (vekt 10%) Finn de oppskriftene som krever bruk av stekeovn. Disse oppskriftene har alle ordet «stekeovn» som del av teksten i attributtet fremgangsmåte. Skriv ut oppskriftsid og tittel på disse oppskriftene. Oppgave 5 (vekt 10%) Skriv ut menyen som ble servert 23. juni i år. For hver rett/oppskrift som ble servert, skal du skrive ut tittelen på retten og hvilken drikke som ble servert til den. Sorter utskriften slik at rettene kommer i den rekkefølgen de ble servert. SQLs datoformat er yyyy-mm-dd. Oppgave 6 (vekt 10%) Skriv ut for hver meny hvor mange retter den inneholder. Oppgave 7 (vekt 10%) Finn den/de menyene som inneholder flest retter. Skriv ut menyid og antall retter. Oppgave 8 (vekt 15%) Finn de gjestene som aldri er blitt invitert oftere enn maksimalt én gang i året. Skriv ut navnene på disse gjestene. Hint: Du kan trekke ut årstal let fra en dato ved å skrive EXTRACT(YEAR FROM dato-attributt). Eksempel: SELECT EXTRACT(YEAR FROM menydato) AS aar FROM Gjesteliste; (finner alle årstall som forekommer i gjestelisten) Oppgave 9 (vekt 15%) Finn ut om det er noen ingredienser som aldri har vært benyttet i noen meny. (Slutt eksamenssett 6) 17