HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring Kandidatnr: Eksamensdato: 7.desember 2009 Varighet: 0900-1200 Fagnummer: Fagnavn: Klasse(r): LC238D Datamodellering og databaser HING2008HA Studiepoeng: 6 Faglærer(e): Hjelpemidler: Oppgavesettet består av: Vedlegg består av: Faglærer: Else Lervik. Lærebøker, alle håndskrevne og trykte hjelpemidler. 3 oppgaver og 5 sider (inkludert forside og vedlegg) 1 side Merknad: Oppgaveteksten kan beholdes av studenter som sitter eksamenstiden ut. Lykke til! OBS! Dersom du mener det mangler opplysninger, setter du dine egne betingelser. 1
Oppgave 1 vekt 40% En database er laget med scriptet i vedlegg 1. Relasjonsmodellen ser slik ut: vare(varenr, varenavn, utsalgspris, grense) grossist(grossistnr, grossistnavn, adresse) parti(grossistnr*, partinr, varenr*, størrelse, antall_solgt, innkjøpsdato, innkjøpspris) matvare((grossistnr, partinr)*, holdbarhetsdato, land) Primærnøkler er streket under, mens fremmednøkler er markert med stjerne. Databasen holder orden på varebeholdningen i en dagligvarebutikk. Butikken får levert varepartier fra mange forskjellige grossister. Vi skiller mellom matvarepartier og andre typer varer. Alle partiene er registrert i tabellen parti, mens matvarene i tillegg er registrert i tabellen matvare. For matvarene gjelder spesielt at holdbarhetsdato og opprinnelsesland for de enkelte partiene er registrert. Utsalgsprisen pr. enhet er den samme for alle partiene av en vare. Innkjøpsprisen pr. enhet varierer naturlig nok fra parti til parti. I første deloppgave nedenfor skal du tegne et EER-diagram. Deretter følger en rekke SQL-spørringer som du skal sette opp. Du står fritt om du ønsker å lage virtuelle tabeller (views) for å løse oppgavene. Oppgave b) og d) forholder seg til DATE-datatypen. Det gis tips om syntaksen i JavaDB, men føl deg ikke bundet til dette. Bruk gjerne pseudokode for å referere til datoer, om du syns det er greiest. a) Tegn EER-modell som beskriver databasen. Bruk UML-notasjon. b) Hvor mye har kjøpmannen betalt for alle partiene han har kjøpt i 2009? Du henter ut årstallet fra en datokolonne ved å bruke funksjonen year() på kolonnen. c) Lag en liste over antall partier pr. land. Listen skal være sortert etter synkende antall og vise både antall og land. (Denne spørringen gjelder kun matvarer.) d) Lag en liste over matvarer som har gått ut på dato, og som det fortsatt er noe igjen av på lager. CURRENT_DATE gir deg dagens dato. Mengde igjen på lager er lik (størrelse - antall_solgt). Listen skal inneholde varenr, varenavn, grossistnr, grossistnavn og antall enheter på lager. Listen skal være sortert på varenavn. e) Finn navn og adresse til den eller de grossistene som har levert flest varepartier. f) Finn verdien av varebeholdningen med unntak av matvarer. For de varene det gjelder skal utsalgsprisen multipliseres med størrelsen av alle varepartiene. 2
Oppgave 2 vekt 20% Også her skal du jobbe med databasen i vedlegg 1. Hver gang varer selges blir verdien til kolonnen antall_solgt i tabellen parti økt. Anta at butikkapplikasjonen sørger for at (størrelse - antall_solgt) aldri blir negativ. Imidlertid bør butikkeieren varsles dersom mengden av en vare blir under grense i tabellen vare. Lag en trigger som sørger for at det sendes en epost til butikkeieren dersom en update-setning på tabellen parti medfører at totalmengden av denne varen (for alle partier av denne varen) kommer under grense. Se i denne omgang bort fra holdbarhetsdatoen på matvarer. Eposten skal si hvilken vare (varenummer, varenavn) det nå begynner å bli lite av. Anta at det eksisterer en ferdig Java-metode sendepost() som tar teksten i eposten som argument og sender eposten til rette vedkommende. Oppgave 3 vekt 40% En produsent av stoler ønsker seg et ordre- og produksjonssystem for å administrere bestillinger av ulike stoler fra kunder, samt å overvåke produksjonen av stolene. Dagens situasjon Siden bedriften typisk mottar mange "små" ordre på spesialbestilte enkeltstoler er det vanskelig å masseprodusere. Derfor må hver stol produseres for hånd. Det går mye tid med til å finne ulike deler og stofftype til hver enkelt stol. Det finnes ingen direkte kobling mellom ordrebestillinger og selve produksjonen. Produksjonen foregår ved at spesifikasjonen (delene og stofftype) for hver stol skrives ut på et ark som leveres til de ansvarlige på fabrikken. Det finnes heller ingen god oversikt over hvilke deler som finnes på lager. Dette gjør det vanskelig å fastslå leveringstiden (produksjonstiden) for en stol. Fremtidige behov Bedriften ønsker seg en sterkere kobling mellom ordre og produksjon. Hver stol produseres fortløpende etter hvert som ordrene kommer inn. De fleste stolene kan spesialbestilles i ulike stofftyper, rygghøyder, understell m.m. En stol består av ulike deler. Delene skal finnes på ulike arbeidsstasjoner (moduler) i fabrikken som er knytt til et felles samlebånd (produksjonslinje). Produksjonen av en spesifikk stol vil inkludere flere arbeidsstasjoner avhengig av hvilke deler stolen består av (stolen vil gå gjennom ei rute av arbeidsstasjoner før den når målet - pakkestasjonen). Alle spesialbestilte stoler produseres fortløpende på dette felles samlebåndet (såkalt kaosproduksjon). Stoldelene monteres fortsatt for hånd ved hver arbeidsstasjon. Stoff skiller seg fra de øvrige delene en stol består av, ved at det er nødvendig at alt stoffet til en ordre må tas fra den samme stoffrullen. Grunnen til dette er at fargenyanser kan variere fra rull til rull. Stoffet plukkes ut når produksjonen av en ordre starter. Stoffrullen følger ordren langs produksjonslinjen. Bedriften leverer også en begrenset mengde masseproduserte standardstoler. Dette skal inn i det nye systemet. 3
Krav til et nytt system En ordre skal ha et entydig nummer. Om ordren skal ordredato og antatt leveringsdato registreres. En kunde skal også identifiseres med et entydig nummer. I tillegg skal navn og adresse inn i databasen. (Vi ser bort fra øvrig kontaktinformasjon i denne oppgaven.) En kunde kan ha mange ordrer i systemet. Det må være mulig å registrere en avtalt rabatt i tilknytning til en ordre. Etter at ordren er effektuert, skal reell leveringsdato lagres i databasen. Betalingsstatus skal også inn. Dette lar vi være et tekstfelt der brukeren til enhver tid kan registrere status vedrørende betalingen. En stol er av en bestemt modell med modellnavn og stoltype (typisk kontorstol eller konferansestol). Vi skiller mellom standardstoler og spesialstoler. En standardstol er av en bestemt modell, og vi lagrer kun prisen og lagerbeholdningen i databasen. En ordre består av bestillinger av et antall standardstoler og spesialstoler av ulike typer, der det er et antall pr. type. Spesialstolene krever omfattende behandling: En spesialstol består av flere deler. Alle arbeidsstasjoner i fabrikken må registreres. En arbeidsstasjon identifiseres med et nummer og i tillegg må plassering (tekstfelt) lagres. De ulike delene en stol kan bestå av, er lagret ved arbeidsstasjonene. En bestemt deltype finnes kun ved én arbeidsstasjon. Antallet av denne deltypen, samt ved hvilken arbeidsstasjon den er lagret, må inn i databasen. Hver deltype har videre et entydig nummer, navn, farge, pris og beskrivelse. For deler som skal trekkes med stoff (for eksempel seter og rygger) må stoffbehovet inn i databasen. Stoff kan betraktes som en spesiell deltype med nr, navn, farge, pris og beskrivelse. I tillegg må alle stoffrullene registreres. En rull identifiseres med deltypenummer til stoffet samt nummeret på rullen. Både for ordinære deler og for den enkelte stoffrullen må lagerbeholdningen til enhver tid kunne finnes ved å slå opp i databasen. Antakelser i denne oppgaven Det er tilstrekkelig med stoff til en ordre i én rull. Man leverer ikke delordre. Oppgave Lag datamodell (EER) for problemstillingen. Bruk UML-notasjon. Oversett datamodellen til relasjonsmodellen. Strek under primærnøkler og marker fremmednøkler med stjerne. 4
Vedlegg 1 CREATE TABLE vare( varenr INTEGER GENERATED ALWAYS AS IDENTITY, varenavn VARCHAR(20) NOT NULL, utsalgspris REAL NOT NULL, -- pr. enhet grense INTEGER NOT NULL, -- nedre grense for bestilling CONSTRAINT vare_pk PRIMARY KEY(varenr)); CREATE TABLE grossist( grossistnr INTEGER GENERATED ALWAYS AS IDENTITY, grossistnavn VARCHAR(20) NOT NULL, adresse VARCHAR(20) NOT NULL, -- begrenser kontaktinfo. til navn og adresse CONSTRAINT grossist_pk PRIMARY KEY(grossistnr)); CREATE TABLE parti( grossistnr INTEGER NOT NULL, partinr INTEGER NOT NULL, varenr INTEGER NOT NULL, størrelse INTEGER NOT NULL, -- antall enheter antall_solgt INTEGER DEFAULT 0, -- antall enheter innkjøpsdato DATE DEFAULT CURRENT_DATE, innkjøpspris REAL NOT NULL, -- pr. enhet CONSTRAINT parti_pk PRIMARY KEY(grossistnr, partinr)); CREATE TABLE matvare( grossistnr INTEGER NOT NULL, partinr INTEGER NOT NULL, holdbarhetsdato DATE NOT NULL, land VARCHAR(15) NOT NULL, CONSTRAINT ferskvare_pk PRIMARY KEY(grossistnr, partinr)); ALTER TABLE parti ADD CONSTRAINT parti_fk1 FOREIGN KEY(grossistnr) REFERENCES grossist; ALTER TABLE parti ADD CONSTRAINT parti_fk2 FOREIGN KEY(varenr) REFERENCES vare; ALTER TABLE matvare ADD CONSTRAINT matvare_fk FOREIGN KEY(grossistnr, partinr) REFERENCES parti; 5