INF1050 Klasseromsoppgave Uke 6

Transkript

1 INF1050 Klasseromsoppgave Uke 6 Løsningsforslag Mer avansert datamodellering med UML Oppgave 1 Her følger noen eksempler på opplysninger som brukeren ønsker å kunne trekke ut av informasjonssystemer. Foreslå mulige datamodeller som kan ligge til grunn for hvert enkelt av disse systemene. Vær oppmerksom på at en enkelt setning er et relativt spinkelt grunnlag for å kunne trekke generelle slutninger! a) Kari arbeider som fullmektig i Posten Samme diskusjon som før om fornavnet. Er "Posten" her et eksempel på en lang rekke mulige arbeidsgivere, slik at vi for eksempel har med et medlemsregister i en fagforening å gjøre? Er vi bare interessert i fullmektiger? Da får vi den første modellen. Hvis det bare er en organisasjon, eller organisasjonen er irrelevant, mens stillingen "fullmektig" er en av flere mulige, får vi den andre modellen. Hvis både organisasjon og stilling er interessant, samtidig som en person kan ha bare en stilling (i en organisasjon), får vi den tredje modellen.

2 Hvis det derimot er slik at en person kan være ansatt i flere organisasjoner, og fullmektig er en av flere mulige stillinger i disse organisasjonene, får vi denne modellen. Eksemplet kan drøftes videre hva hvis vi skal skille mellom hovedarbeidsgiver og biarbeidsgivere, for eksempel? b) Systemutvikling fra kjernen og ut, fra skallet og inn er pensum i INF1050 Multiplisitetene er interessante her. Det er jo ikke alltid vi har bare én bok, som i INF1050. Hvis modellen er slik som over, hva skal vi da kalle det assosiasjonsbegrepet vi kan forestille oss, og hvilke opplysninger er det nærliggende å knytte til dette? c) Peer Gynt spilles på Det Norske Teatret 23. februar Her gjelder det å komme på begrepet Forestilling. Kommer man ikke på det uten videre, bør det dukke opp som assosiasjonsbegrep på assosiasjonen mellom Teater og Dag. Modellen gir problemer hvis det er mer enn en forestilling pr dag på det samme teateret enten fordi teatret har flere saler, eller fordi de kjører forestillinger etter hverandre i den samme salen. Hvordan løser vi det?

3 d) Skagestein foreleser i Sophus Lies auditorium 16. februar kl 1215 Nokså analogt med oppgave c), inntil man kommer på at foreleseren ikke kan gjøre flere ting samtidig. Siden vi ikke kan løse dette med enda flere «identifying», må vi "låne" eksterne entydighetsskranker fra ORM, se foil fra forelesning 11. februar dmuml2-28 Vi har nå to valg for representasjon (og dermed primærnøkkel) i forelesning, men forelesningssted+forelesningstid er vel fremdeles det mest nærliggende. Den andre eksterne entydighetsskranken blir en overlappende kandidatnøkkel, og realiseres ved hjelp av UNIQUE i SQL. Oppgave 2 Her følger en klassisk datamodell for et ordresystem, på ugruppert form:

4 a) Gruppér modellen ved å generere fremmednøkler. b) Sett opp tabellene i den tilsvarende tabelldatabasen. Marker primærnøkler med entydighetsskranker, og attributter som ikke tillater NULL med "NOT NULL". Delmengdeskranker (referanseintegriteter) behøver ikke settes på. Sett gjerne inn noen eksempler på forekomster (kan fungere som en god kontroll av at modell og database er fornuftig!) Ikke stryk noen klasser eller tabeller, selv om de kan synes overflødige. Kan du ved å kaste et blikk på modellen ovenfor si hvor mange tabeller det blir i tabelldatabasen? Like mange som det er klasser i modellen, så lenge det ikke er noen mange-tilmange eller en-til-en-assosiasjoner, eller underbegreper. Her er vist bare en tabell. De andre er helt analoge. c) Vurder hvilke klasser og tabeller som kan betraktes som overflødige og som derfor kan strykes. Gi en kort begrunnelse for hver strykning. Antall, beløp. Begrunnelse: Alle finnes som fremmednøkkel/attributt i andre tabeller. Ingen bruk for en separat tabell med mer eller mindre tilfeldige tall. Kan eventuelt etablere brukerdefinerte datatyper for beløp (liten vits for antall).

5 Stedsnavn, Gateadresse. Begrunnelse: Alle finnes som fremmednøkkel/attributt i Poststed eller Kunde. Dag. Kan eventuelt beholdes for å lagre en liste over lovlige datoer. Person. Tvilsom strykning. Det kan være greitt å ha en personoversikt uavhengig av bestillerattributtet i Ordre. Produsent. Tvilsom strykning. Det kan være greitt å ha en personoversikt uavhengig av orgnrattributtet i Vare. d) Hvilken endring må gjøres i modellen for å inkludere leveringsdag? En ny assosiasjon mellom Ordre (evt. ordrelinje) og Dag, der Dag spiller rollen som leveringsdag. e) Hvis bestilleren assosieres med Kunde istedenfor med Ordre, hvilken restriksjon finnes da i interesseområdet? Hver eneste kunde forutsettes å ha en eneste, fast bestiller. Og hvis denne faste bestilleren endrer seg, hvilken virkning har da dette på tidligere Ordre? f) Hvorfor kan det være lurt å ha avtalt_pris i tillegg til listepris? Listeprisen kan endre seg. Man får sikkert blidere kunder dersom man sender regning på en avtalt pris istedenfor på en oppdatert (og formodentlig høyere) listepris. Avtalte priser gir dessuten muligheter for rabatter. g) Hvis avtalt_pris assosieres med Vare istedenfor med Ordrelinje, hvilken restriksjon finnes da i interesseområdet? Hver enkelt vare selges da til samme avtalte pris til alle kunder. h) Hvis vi sløyfer ordrelinjenr{id} i Ordrelinje og istedenfor gjør assosiasjonen fra Ordrelinje mot Vare «identifying» (ikke å anbefale!), hvilken restriksjon innføres da i interesseområdet? Samme vare kan ikke gjentas innen samme ordre. Oppgave 3 Et forenklet informasjonssystem for oljeboring skal inneholde opplysninger om oljebrønner, lisenser, produksjonsmengder m.m. En oljebrønn dekkes av en lisens. Lisensen kan eies av flere firmaer, men bare ett firma er operatør for lisensen. Dato for opprettelse av lisensen skal registreres, likeså datoene for hver oljebrønns borestart, boreslutt og produksjonsstart. En oljebrønn inneholder olje, gass og vann. På flere dyp i brønnen måles elektrisk motstand. Siden produksjonsstart er det hentet ut flere typer olje i varierende mengder. Samlet mengde pr. oljetype skal registreres for hver brønn. Nedenfor finnes noen eksempler på rapporter fra informasjonssystemet. Tegn datamodell på ugruppert og gruppert form! Hvilke klasser vil du anbefale å stryke? Tegn opp den tilsvarende relasjonsdatabasestrukturen, med referanseintegriteter og NOT NULL.

6 BRØNN NR OPERATØR PROD.START OLJETYPE MENGDE (FAT) SHELL MOBIL MOBIL SHELL TA4 TC3 TC4 TC4 TA BRØNN NR DYP MOTSTAND (OHM) BRØNN NR PROSENT OLJE GASS VANN Ugruppert form:

7 Gruppert form, med forslag til strykninger: Relasjonsdatabasestrukturen følger direkte av modellen. Studentene bør nå sette på delmengdeskranker (referanseintegriteter) GS Oppdatert GS