Gerhard Skagestein: Systemutvikling fra kjernen og ut, fra skallet og inn.

Transkript

1 Gerhard Skagestein: Systemutvikling fra kjernen og ut, fra skallet og inn. Oppgaver til kapittel 5 - Datamodellering med UML Oppgave 6. Ugruppert og gruppert modell Et mindre bilutleiefirma ønsker å få utviklet et datamaskinbasert informasjonssystem som hjelp i den daglige driften. Systemet skal omfatte følgende opplysninger: bilenes kjennetegn bilmerke/årsmodell bilgruppe døgnpris kilometerpris tidspunkt for utlevering tidspunkt for tilbakelevering kilometerstand ved utlevering kilometerstand ved tilbakelevering kundens navn kundens adresse Lag en datamodell både på ugruppert og gruppert form som dekker informasjonsbehovet! Gjør rede for de forutsetningene som ligger til grunn for modellen. Over vises modellen på ugruppert form. Med litt øving kan man arbeide med både den ugrupperte og den grupperte varianten samtidig, og veksle mellom dem. Utfordringen her ligger i å komme på begrepet Utleie, som ikke er nevnt eksplisitt i oppgaveteksten. Valg av representasjon for Utleie er fremdeles åpen hva med en gjennomløpende nummerering innenfor hvert enkelt år? Adresse inneholder hele adressen, inkludert postnr og poststed. Den kan selvsagt med hell deles opp i sine enkelte bestanddeler. Videre går modellen ut fra at prisene bestemmes av bilgruppen, ikke av de individuelle bilene. Mulig at i tillegg bør avtalte priser knyttes direkte til Utleie det gjør at systemet kan håndtere individuelle avtaler som følge av rabatter og lignende. Systemutvikling kjernen/skallet: Løsningsforslag kapittel 6. Side

2 Oppgaver til kapittel 6 - Den redundansfri modellen Oppgave Her følger noen eksempler på opplysninger som en bruker ønsker å kunne trekke ut av et informasjonssystem. 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. Systemutvikling - fra kjernen og ut, fra skallet og inn er pensum i INF050 Bok boktitel {id} er_pensum Emne emnekode {id} Multiplisitetene er interessante her. Det er jo ikke alltid vi har bare én bok, som i INF050. 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? b. Juvikfolke spilles på Det Norske Teatret 6. mars Forestilling spillested spilledag teaternavn {id} dato {id} Teaterstykke tittel {id} Teater Dag 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? Systemutvikling kjernen/skallet: Løsningsforslag kapittel 6. Side 2

3 c. Skagestein foreleser i Sophus Lies auditorium 8. februar kl 25 Auditorium auditoriumnavn {id} Forelesning foreleser Tidspunkt dato,klokkeslett {id} navn {id} Person 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, må vi bruke eksterne entydighetsskranker, se læreboka avsnitt 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: Person navn {id} 0: # {id} bestiller Dag dato {id} Antall Ordrelinje Vare ordrelinjenr{id} varenr {id} listepris ordredag Kunde kundenr {id} Ordre ordrenr {id} Gateadresse adresse {id} Produsent orgnr {id} forelesningstidspunkt Poststed postnr {id} Stedsnavn stedsnavn {id} Beløp #NOK {id} 0.. avtalt_pris Systemutvikling kjernen/skallet: Løsningsforslag kapittel 6. Side 3

4 a. Gruppér modellen ved å generere fremmednøkler. Person navn {id} 0: Kunde kundenr {id} adresse {fk} postnr {fk} Gateadresse adresse {id} Poststed postnr {id} stednavn {fk} dato {id} # {id} bestiller Dag Antall ordrenr {id} kundenr {fk} bestiller {fk}{null} ordredag {fk} Ordrelinje ordredag Ordre Vare orgnr{fk}{id} varenr {id} listepris listepris{fk} ordrenr {fk}{id} ordrelinjenr{id} varenr{fk} antall {fk} avtalt_pris{fk}{null} Produsent orgnr {id} Stedsnavn stedsnavn {id} Beløp #NOK {id} 0.. avtalt_pris 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). Systemutvikling kjernen/skallet: Løsningsforslag kapittel 6. Side 4

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. 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. Er det mulig og/eller interessant å flytte grensen mellom skjema og forekomster? Systemutvikling kjernen/skallet: Løsningsforslag kapittel 6. Side 5

6 Ugruppert form: Hvis det er en mulighet for at det kan finnes flere interessante komponenter enn olje, gass og vann (spør oljeekspertisen!), kan vi opprette et nytt begrep som vi for eksempel kan kalle Komponent (og som i nåværende modell vil ha de tre forekomstene olje, gass, vann). Vi knytter dette begrepet til Brønn med en mange-til-mangeassosiasjon, knytter en assosiasjonsklasse KomponentIBrønn til assosiasjonen, og knytter Andel til assosiasjonsklassen. Dermed har vi flyttet på grensen mellom skjema og forekomster, i og med at tekststrengene "olje", "gass" og "vann" er fjernet fra modellen og henvist til å være forekomster. Den siste utformingen er mer fleksibel overfor tilgang av nye komponenter. Systemutvikling kjernen/skallet: Løsningsforslag kapittel 6. Side 6

7 Gruppert form, med forslag til strykninger: Relasjonsdatabasestrukturen følger direkte av modellen. Husk delmengdeskranker (referanseintegriteter)! Oppdatert. september 2006 GS. Oppdatert 5. februar 2007 GS Systemutvikling kjernen/skallet: Løsningsforslag kapittel 6. Side 7