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

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... 11 Eksamenssett 5: Matoppskrifter modellering... 13 Eksamenssett 6: Matoppskrifter SQL og normalisering... 16 Løsningsforslag julegaver... 18 Løsningsforslag konsulentdatabase... 21 Løsningsforslag maskindatabasen på Ifi modellering versjon 1... 24 Løsningsforslag maskindatabasen på Ifi modellering versjon 2... 30 Løsningsforslag maskindatabasen på Ifi SQL og normalisering... 43 Løsningsforslag matoppskrifter modellering... 49 Løsningsforslag matoppskrifter SQL og normalisering... 59 1

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 12345611GR 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

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

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

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

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

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 2007. 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

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

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

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

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

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

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 40-45 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

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

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

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

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

Løsningsforslag julegaver modellering Oppgave 1 - Modellering Kommentarer Et hovedpoeng her er å skille mellom Gaveartikkel, hvor hver gaveartikkel kan forefinnes i flere eksemplarer, og Julegave, som representerer de konkrete eksemplarene som overbringes fra giver til mottaker. Forøvrig er de eksterne entydighetene av interesse. Den som ligger i nærheten av Julegave, uttrykker at til samme jul kan ikke samme mottaker få samme gaveartikkel av samme giver mer enn én gang. (Onkel Fredrik har fått mange slips, men det er bare om ett han kan si: "Dette grå 110 cm lange silkeslipset fikk jeg av tante Laura julen 1952".) Men da regnes i tilfelle de 6 kjøkkenglassene som tante Laura fikk av onkel Fredrik året etter, som én julegave selv om glassene var pakket inn enkeltvis i et humoristisk forsøk på å få gaven til å fremstå som mer overdådig enn den var. Dette gir oss en entydig referanse til Julegave, nemlig 18

kombinasjonen av varenummeret, årstallet, giverreferansen og mottakerreferansen. For Person har vi i utgangspunktet bare referansen Navn (som er fornavnet, alternativt et kjælenavn), som ikke er entydig i seg selv, men er entydig innen en bopel. Dette er uttrykt gjennom den eksterne entydigheten i nærheten av Person. Kombinasjonen av lengdegrad, breddegrad, etasje og fornavn/kjælenavn gir oss altså en entydig referanse til Person. Oppgave 2 - Gruppering Lager(lagernr, sjef, tlfnr) Lagervare(lagernr, varenr, antall) Produsent(prodnavn, tlfnr) Bankkonto(kontonr, prodnavn) Gaveartikkel(varenr, beskrivelse) Produksjon(varenr, prodnavn) Person(navn, lengdegrad, breddegrad, etasje) Julegave(varenr, årstall. franavn, fralgd, frabrd, fraetg, tilnavn, tillgd, tilbrd, tiletg, antall) Fremmednøkler: lagernr i Lagervare til lagernr i Lager varenr i Lagervare til varenr i Gaveartikkel prodnavn i Bankkonto til prodnavn i Produsent varenr i Produksjon til varenr i Gaveartikkel prodnavn i Produksjon til prodnavn i Produsent varenr i Julegave til varenr i Gaveartikkel (franavn, fralgd, frabrd, fraetg) til (navn, lengdegrad, breddegrad, etasje) i Person (tilnavn, tillgd, tilbrd, tiletg) til (navn, lengdegrad, breddegrad, etasje) i Person Kommentarer Navn på attributter er valgt rimelig fritt. Den lange entydighetspilen på faktatypen mellom Gaveartikkel og Produsent resulterer i en begrepsdannelse som her er blitt til relasjonen Produksjon. Det kunne nok for grupperingens del vært en fordel å la Person ha en kortere referansemåte: 19

Hvis vi da velger pid som preferert referansemåte, slipper vi unna med langt færre attributter i Julegave. Til gjengjeld inneholder Person en kandidatnøkkel i tillegg til (den nye) primærnøkkelen: Person(pid, navn, lengdegrad, breddegrad, etasje) Julegave(varenr, frapid, tilpid, årstall, antall) 20

Løsningsforslag konsulentdatabase SQL og normalisering Oppgave 1 CREATE TABLE Timeliste ( Anskode CHAR(4) REFERENCES Ansatt(Anskode), Uke INTEGER, Kontrollør CHAR(4) REFERENCES Ansatt(Anskode), PRIMARY KEY (Anskode,Uke) ); Oppgave 2 SELECT Anskode, Uke, Lnr FROM Timelistelinje WHERE NOT (Timer % 5 = 0); Oppgave 3 SELECT FROM WHERE Anskode, Uke, Lnr Timelistelinje (Prosject = A AND O-kode!= ) OR (O-kode = B AND NOT (Prosjekt LIKE K% )) OR (O-kode = AND (Dag = 6 OR Dag = 7)); Oppgave 4 SELECT Anskode, Uke, Dag FROM Timelistelinje WHERE O-kode = GROUP BY Anskode, Uke, Dag HAVING SUM(Timer) NOT IN (0,75); Oppgave 5 CREATE VIEW Data(ProsjType, SumTimer) AS (SELECT S, SUM(Timer) FROM Timelistelinje T, Ansatt A WHERE Avdeling = Salg AND T.Anskode = A.Anskode AND Uke > 200700 AND Prosjekt LIKE S% ) UNION (SELECT M, SUM(Timer) FROM Timelistelinje T, Ansatt A WHERE Avdeling = Salg AND T.Anskode = A.Anskode AND Uke > 200700 AND Prosjekt LIKE M% ) UNION (SELECT A, SUM(Timer) FROM Timelistelinje T, Ansatt A WHERE Avdeling = Salg AND T.Anskode = A.Anskode AND Uke > 200700 AND NOT (Prosjekt LIKE M% OR Prosjekt LIKE S% OR Prosjekt = A ) ); (Oppg. 5 forts. neste side) 21

SELECT FROM ProsjType, (100.0*SumTimer)/SUM(SumTimer) AS Prosent Data; Oppgave 6 CREATE VIEW Data1(Anskode, A-timer) AS (SELECT Anskode, SUM(Timer) FROM Timelistelinje WHERE Uke = <ukenr> AND O-kode = A GROUP BY Anskode ) UNION (SELECT Anskode, -SUM(Timer) FROM Timelistelinje WHERE Uke = <ukenr> AND Prosjekt = A GROUP BY Anskode ); CREATE VIEW Data2(Akode, A-timer) AS (SELECT Anskode, SUM(A-timer) FROM Data1 GROUP BY Anskode ) UNION (SELECT Anskode, 0 FROM Ansatt WHERE Anskode NOT IN (SELECT Anskode FROM Data1) ); UPDATE Ansatt SET Flexikode = Flexikode + (SELECT A-timer FROM Data2 WHERE Akode = Anskode); Oppgave 7 CREATE VIEW LevertListe AS SELECT Anskode, MAX(Uke) AS SisteUke FROM Timeliste GROUP BY Anskode; CREATE VIEW SisteUke(SisteFakturaUke) AS SELECT MIN(SisteUke) FROM LevertListe; SELECT MAX(P.P-navn) AS Prosjektnavn, MAX(A.Navn) AS Konsulent, SUM(T.Timer) AS AntallTimer FROM Kunde K, Prosjekt P, Ansatt A, Timelistelinje T, SisteUke WHERE K-navn = <kundens navn> AND K.Kundenr = P.Kundenr AND P.P-kode = T.Prosjekt AND A.Anskode = T.Anskode AND T.Uke > K.SistFakturert AND T.Uke <= SisteFakturaUke GROUP BY Anskode, P-kode ORDER BY Prosjektnavn, AntallTimer DESC; 22

Oppgave 8 Fjern første linje i WHERE-klausulen, legg til MAX(K.K-navn) AS Kundenavn først i SELECT-klausulen og legg Kundenavn først i ORDER BY-klausulen. (FROM- og GROUP BY-klausulene forblir uendret.) Oppgave 9 Attributter: Kundenr, K-navn, Salgskontakt, SistFakturert, P-kode, P- navn, P-leder FDer: Kundenr K-navn, Salgskontakt, SistFakturert P-kode P-navn, P-leder, Kundenr (disse får vi fra primærnøklene i de opprinnelige tabellene) Primærnøkkel: P-kode Tabellen er på 2NF fordi FD-en Kundenr K-navn, Salgskontakt, SistFakturert bryter med 3NF (Kundenr inneholder ikke kandidatnøkkelen P-kode og er altså derfor ingen supernøkkel; K-navn er ikke et nøkkelattributt (og det er heller ikke Salgskontakt eller SistFakturert)), samtidig er FDen på 2NF (Kundenr er ikke en ekte delmengde av P-kode). 23

Løsningsforslag maskindatabasen på Ifi modellering v. 1 24

25

26

27

28

Oppgave 6 Primærnøkler er understreket. Andre kandidatnøkler har stiplet understrekning. Ansatt (Brukernavn_for, U_nr_er_arb_plass); Diverse (U_nr_for, Beskrivelse_av_utstyr); Faktura (Firmanavn_med, FakturaNr_for, Firmanavn_for, OrdreNr_for, NOK_paa, Kildekode_belastes_for, Kildenavn_belastes_for ); FakturaLinje (Firmanavn_med, FakturaNr_med, LinjeNr_for, NOK_paa, Kildekode_belastes_for, Kildenavn_belastes_for); Feil (U_nr_med, Dato_feilmeldt, Brukernavn_meldte, RepStatus_for, Symptom_har, Dato_rettet, RepRefNr_for); Installasjon (Op_syst_har, Kategori_med, Filnavn_for); Maskin (U_nr_for, Op_syst_for, Kategori_for); Ordre (Firmanavn_fikk, OrdreNr_for); Postering (Kildekode_belastes_for, Kildenavn_belastes_for, Firmanavn_har, FakturaNr_har, LinjeNr_har, NOK_paa); Programmer (Op_syst_har, Kategori_har, Prognavn_i); Tilleggs_utstyr (U_nr_for, U_nr_med); Utstyr (U_nr_for, Dato_levert, Dato_slutt_service, Info_om, Kildekode_finansierer, Kildenavn_finansierer, Brukernavn_bruker, Serienr_for, S_type_avtale_for); Tre fremmednøkler (det er mange flere...): Fra Ansatt(U_nr_er_arb_plass) til Maskin(U_nr_for) Fra Postering (Firmanavn_har, FakturaNr_har, LinjeNr_har) til FakturaLinje (Firmanavn_med, FakturaNr_med, LinjeNr_for) Fra Utstyr(Brukernavn_bruker) til Ansatt(Brukernavn_for) 29

Løsningsforslag maskindatabasen på Ifi modellering v. 2 Oppgave 1 Utstyr har referansemåten Enhetsid (denne fremkommer først på sidene med perfekte broer s. 35-36), som er serienummer hvis dette fins, og et internnummer/løpenummer ellers. Alternativt kan man bruke et rent internt løpenummer pluss en faktatype som angir serienummer for de enhetene som har det. Underbegrepene til Utstyr er kun en illustrasjon av hvordan det gjøres; klassifiseringen er ikke uttømmende. 30

Oppgave 2 utstyr Her er det valgt å ikke innføre noe fellesbegrep for Ansatt og Ifi_sentralt fordi dette ville ha medført felles representasjon, noe som virker kunstig. Vi har videre valgt å modellere arbeidsplassmaskin som noe annet enn utstyr som disponeres. Arbeidsplassmaskiner er knyttet til ansatte via arbeidsplasser, se Oppgave 2 arbeidsplass. Som finansieringskilde oppgis RU, faggruppenavn, prosjektnavn eller ansattnavn (antar at alle navn er forskjellige). 31

Oppgave 2 - arbeidsplass 32

Oppgave 3 installasjonsimage En maskinkonstellasjon er bestemt av operativsystem og bruksnivå (derfor den eksterne entydigheten). Hvert installasjonsimage har en entydig plassering, i modelleringen foreslått realisert ved en URL (se s. 35-36). Et program kan inngå som standardpakke i flere maskinkonstellasjoner (derfor lang pil). 33

Oppgave 4 serviceavtaler Her er gjort noen antakelser, som at ikke alt utstyr har serviceavtale og at alt utstyr har anskaffelsesdato. Da blir denne datoen også startdato for serviceavtalen. 34

Oppgave 4 feilmelding Forutsetter maks en feilmelding pr. dag pr. utstyr. Da kan feilmeldingen identifiseres ved utstyrets enhetsid og dato for feilmeldingen. Antar at feilmeldingen alltid får en reparasjonsreferanse før feilen forsøkes reparert. En mer realistisk modellering av reparasjonsreferansen er at den bestemmes av leverandøren (det er altså ikke gjort her). 35

Oppgave 5 ordre Ordrenummer bestemmes av forhandler. Derfor den eksterne entydigheten mellom Forhandler_med og Ordrenummer_på_ordre. Linjenummer kan gjenbrukes på tvers av ordre, det sørger ekstern entydighet mellom Ordre_med_ordrelinje og Linjenummer_for_ordrelinje for. 36

Oppgave 5 faktura Det hadde vært naturlig å ha Ordre snarere enn Ordrenummer i diagrammet over. Da må man i tilfelle ha ekvivalente stier (equivalence of path eop) mellom Faktura-Ordre-Forhandler (mot venstre, via rollen Faktura_er_delleveranse_av) og Faktura -Forhandler (mot høyre, via rollen Faktura_gjelder_forhandler) for å sikre at forhandleren på ordren er den samme som forhandleren på fakturaen. Men i vårt tilfelle er det faktisk enklere å legge inn bare Ordrenummer direkte og la forhandler for ordren som fakturaen er en delleveranse av, underforstått være den samme som den som fremkommer via rollen Faktura_gjelder_forhandler. 37

Oppgave 5 fakturadetaljer Konto for fakturalinje (Fakturalinje_belastes/Konto_for_belastning) angis bare hvis linjen skal belastes en annen konto enn fakturaen generelt (Faktura_belastes_primært/Konto_er_primærkonto_for). Formålet med detaljlinjer er å spesifisere andre konti for deler av en fakturalinje. Det kan være flere detaljlinjer pr. fakturalinje. En og samme konto skal ikke være 38

gjentatt for flere detaljlinjer for en og samme fakturalinje. Dermed fås en ekstern entydighet mellom Konto_for_belastning_av og Fakturalinje_har_dellinje. Totalprisen (se faktatypen Pris_er_totalpris_på/Faktura_har_totalpris) skal stemme med summen av fakturalinjeprisene (som kan beregnes på grunnlag av faktatypene Fakturalinje_har_enhetspris/Pris_er_enhetspris_for og Fakturalinje_gjelder_antall_enheter/Antall_enheter_er_antall_enheter_levert). Totalprisen må modelleres særskilt i databasen i form av en stored procedure (ikke pensum i INF1300) og er altså ikke angitt i ORM-diagrammet, men slik informasjon kan med fordel påføres diagrammet som vanlig norsk tekst. 39

Perfekte broer I 40

Perfekte broer II 41

Oppgave 6 Primærnøkler er understreket. Andre kandidatnøkler har stiplet understrekning Ansatt (Ansattnr, Arbeidsplassid, Navn); Arbeidsplass (Arbeidsplassid, hovedmaskin); Detaljlinje (Forhandler, Fakturanr, Linjenr, Kontonr, Detaljinjenr, Antall) I Detaljlinje er dessuten (Forhandler, Fakturanr, Linjenr, Detaljinjenr) kandidatnøkkel Faktura (Forhandler, Fakturanr, Primaerknr, Ordrenr, Totpris) Fakturalinje (Forhandler, Fakturanr, Linjenr, Antall, Enhetspris, Utstyrstype, Kontonr) Fast_ansatt (Ansattnummer, Arbeidsplassid) Feilmelding (Enhetsid, Regdato, Ansatt_meldte_feil, Symptom) Feilmelding_Feil (Enhetsid, Dato, Feiltype) Feilmelding_Reparasjonsr (Reparasjonsrefnr, Enhetsid, Dato) Maskinkonstellasjon (OS, Bruksnivaa, Image_URL) Maskinkonstellasjon_Prog (OS, Bruksnivaa, Standardprogram) Ordre (Ordrenr, Forhandler, Dato) Ordrelinje (Ordrenr, Forhandler, Linjenr, Antall, Enhetspris, Utstyrstype) Reparasjon (Enhetsid, Repforsoeksdato, Repid, Repdato, Problemloest) Serviceavtale (Serviceavtaleid, Avtaletypebetegnelse, Servicelengde) Utstyr (Enhetsid, Anskaffelsesdato, Finansieringskilde, Operativsystemtype, Bruksnivaanavn, Id_er_serienummer, Utstyrstypenavn, Ansatt_disponerer, Ifi_disponerer, Serviceavtaleid, Tilleggsutstyr); Tre fremmednøkler (det er mange flere): Fra Fast_ansatt(Ansattnummer, Arbeidsplassid) til Ansatt(Ansattnr,Arbeidsplassid) Fra Reparasjon(Enhetsid, Repforsoeksdato) til Feilmelding_Reparasjonsr(Enhetsid, Dato) Fra Ansatt(Arbeidsplassid) til Arbeidsplass(Arbeidsplassid) 42

Løsningsforslag maskindatabasen på Ifi SQL og normalisering Oppgave 1 select prosjektid, ansattid, dato, timer from Prosjekttimer where status = 'merknad' order by prosjektid, ansattid; Oppgave 2 Fra primærnøkkelen has FDen (1) ansattid, prosjektid, dato timer, status, godkjennerid Fra oppgaveteksten has i tillegg FDen (2) prosjektid, dato, status godkjennerid Eneste kandidatnøkkel er primærnøkkelen: (ansattid, prosjektid, dato). (1) er på BCNF fordi venstresiden er en kandidatnøkkel og dermed en supernøkkel. (2) er på 2NF fordi venstresiden ikke er delmengde av kandidatnøkkelen. Den bryter 3NF fordi venstresiden ikke er en supernøkkel og høyresiden ikke er et nøkkelattributt. Totalt er derfor tabellen på 2NF. Den bryter 3NF. Oppgave 3 create table Detaljlinje ( leverandør varchar(30) references Leverandør(navn), fakturanr varchar(30), linjenr integer, antall integer not null, konto varchar(30), primary key (leverandør, fakturanr, linjenr, konto), foreign key (leverandør, fakturanr, linjenr) references Fakturalinje(leverandør, fakturanr, linjenr) ); 43

Man kan også vurdere om man skal ha med foreign key (leverandør, fakturanr) references Faktura(leverandør, fakturanr). Det kan godt stå 'not null' på nøkkelattributtene også, men dette påtvinges automatisk via primary key og er derfor ikke nødvendig å ha med. Oppgave 4 Fremmednøkkelen fra Fakturalinje til Faktura består av attributtene (leverandør, fakturanr). De tilsvarende attributtene i Faktura er dens primærnøkkel (denne heter også (leverandør, fakturanr).) Når det legges inn et nytt tuppel i Fakturalinje, må det sjekkes at det fins et tilhørende tuppel i Faktura (dvs. attributtverdier i Faktura-tuppelets primærnøkkel er likt verdiene i fremmednøkkelen i Fakturalinje-tuppelet). Det samme gjelder hvis et tuppel i Fakturalinje får endrede verdier i fremmednøkkelen. Når det fjernes et tuppel fra Faktura, må det sjekkes at det ikke fins tupler i Fakturalinje med tilsvarende verdier i fremmednøkkelen. Det samme gjelder hvis et tuppel i Faktura får endrede primærnøkkelverdier; da må de verdiene som ble overskrevet, ikke ha tilhørende tupler i Fakturalinje. Oppgave 5 select s.navn as navn, max(s.e-post) as e-post, sum(beløp) as totalbeløp from Leverandør s, Faktura f where s.navn = f.leverandør and f.leveringsdato > 2007 group by s.navn order by totalbeløp; (Noen DBMSer godtar at s.e-post brukes uaggregert i select fordi e-post er entydig for et gitt navn, men generelt skal det aggregeres over attributter i select som ikke forekommer i group by. Når vi vet at alle verdiene i s.epost vil være like for en gitt verdi i s.navn, kan vi i såfall få tak i s.e-post ved å si max(s.e-post).) Oppgave 6 Summer først opp beløpene som står implisitt i Fakturalinje for gitt faktura med leverandør x og fakturanummer y. Det som egentlig står, er antall og stykkpris, så beløpene må beregnes for hver fakturalinje. Siden dette ikke kan gjøres i argumentet til sum, må vi ha en egen beregning av disse før det summeres. 44

create view SumFakturalinje as select sum(pris) as linjepris from (select antall * stykkpris as pris from Fakturalinje where leverandør = x and fakturanr = y ); Sammenlign så totalbeløpet i Faktura med den beregnede summen fra Fakturalinje. select f.beløp - l.linjepris as diskrepanse from SumFakturalinje as l, Faktura f where f.leverandør = x and f. fakturanr = y and f.beløp - l.linjepris!= 0; Oppgave 7 En delleveranse fremkommer ved at det fins minst én faktura for vedkommende ordre. At ikke hele ordren er levert, er kjennetegnet ved at antallet enkeltvarer i fakturaene summerer seg til mindre enn antallet angitt i ordren. Så man kan rett og slett summere antall enheter og slik få en sjekksum som indikerer om ordren er komplett. Sjekksum for ordrene: create view OrdreSjekksum as select leverandør, ordrenr, sum(antall) as sjekksum from Ordrelinje group by leverandør, ordrenr; Sjekksum for leveransene: create view LeveranseSjekksum as select f.leverandør as leverandør, f.ordrenr as ordrenr, sum(antall) as sjekksum from Faktura f, Fakturalinje l where f.leverandør = l.leverandør and f.fakturanr = l.fakturanr group by f.leverandør, f.ordrenr; Svaret er ordre hvor disse er forskjellige: select o.leverandør, o.ordrenr from OrdreSjekksum o, LeveranseSjekksum d where o.leverandør = d.leverandør and o.ordrenr = d.ordrenr and o.sjekksum!= d.sjekksum; 45

Oppgave 8 La w være den aktuelle kontoen. Fakturaer som gjelder w, summerer seg opp slik: create view SumFaktura as select sum(beløp) as f-beløp from Faktura where konto = w and leveringsdato > 2007 ; Fra disse beløpene skal trekkes beløp vedrørende fakturalinjer som gjelder andre konti. Disse beløpene summerer seg til følgende: create view SumFakturalinjerAndre as select sum(beløp) as la-beløp from (select l.antall * l.stykkpris as beløp from Fakturalinje l, Faktura f where l.leverandør = f.leverandør and l.fakturanr = f.fakturanr and f.konto = w and f.leveringsdato > 2007 and l.konto is not null and l.konto!= w ); I tillegg til de fakturaene som gjelder w, kommer fakturalinjer hvor tilhørende (hoved-)faktura gjelder en annen konto, men hvor fakturalinjene gjelder w. Disse beløpene summerer seg til følgende: create view SumFakturalinjer as select sum(beløp) as l-beløp from (select l.antall * l.stykkpris as beløp from Fakturalinje l, Faktura f where l.leverandør = f.leverandør and l.fakturanr = f.fakturanr and f.leveringsdato > 2007 and f.konto!= w and l.konto = w ); 46

Til fratrekk fra beløp som stammer fra slike fakturalinjer, kommer fakturadetaljlinjer som gjelder andre konti: create view SumDetaljlinjerAndre as select sum(beløp) as da-beløp from (select d.antall * l.stykkpris as beløp from Detaljlinje d, Fakturalinje l, Faktura f where d.leverandør = l.leverandør and d.fakturanr = l.fakturanr and d.linjenr = l.linjenr and l.leverandør = f.leverandør and l.fakturanr = f.fakturanr and f.leveringsdato > 2007 and f.konto!= w and l.konto = w and d.konto!= w ); I tillegg kommer detaljlinjer hvor tilhørende faktura ikke gjelder w, en fakturalinje heller ikke gjelder w, men hvor detaljlinjen skal belastes w: create view SumDetaljlinjer as select sum(beløp) as d-beløp from (select d.antall * l.stykkpris as beløp from Detaljlinje d, Fakturalinje l, Faktura f where d.leverandør = l.leverandør and d.fakturanr = l.fakturanr and d.linjenr = l.linjenr and l.leverandør = f.leverandør and l.fakturanr = f.fakturanr and f.leveringsdato > 2007 and f. konto!= w and (l.konto is null or l.konto!= w ) and d.konto = w ); Det kan strengt tatt tenkes at en hovedfaktura som nevner w som konto, har en eller flere fakturalinjer som nevner en annen konto, og hvor detaljlinjer igjen nevner w som konto. Det burde riktignok være et krav at hovedkonto ikke får gjentas i detaljlinjer; i den grad det er fakturalinjer hvor noen deler skal belastes hovedkonto og noen andre konti, bør fakturalinjen heller gjenta hovedkonto (dvs. med en null-forekonst i attributtet konto), og med avvikende konti i detaljlinjene. Men vi kan jo ta slike beløp med for å være på den sikre siden. De fremkommer ved å gjøre følgende: 47