dbsys.info

Løsningsforslag til kapittel 7

Oppgave 1

Bygninger og avgiftstyper.

Den enkle versjonen (uten avgiftsbeløp) kan modelleres ved hjelp av en eneste entitet Bygning, og Bygningstype kan være et attributt i denne entiteten:

ER-diagram

For å knytte avgiftsbeløp til de ulike bygningstypene er det naturlig å la Bygningstype bli en egen entitet:

ER-diagram

Se logiske datamodeller.

Oppgave 2

Timelister.

Modellen under skiller mellom Timeliste og Arbeidsperiode. En forekomst av Timeliste hører til en bestemt konsulent og kan inneholde flere "sammenhengende arbeidsperioder" denne konsulenten utfører for samme kunde. I og med at en arbeidsperiode tilhører en timeliste (og dermed en bestemt måned) holder det å lagre dagnummer for start og slutt.

Man kunne eventuelt sløyfet Timeliste, og registrert startdato og sluttdato i Arbeidsperiode.

ER-diagram

Se logisk datamodell.

Oppgave 3

Produktoppbygging.

Oppgaven sier ikke noe om samme komponent kan kjøpes av flere leverandører. Dette er lagt til grunn i løsningsforslagene under ved at bedriften har en intern nummerserie for alle komponenter (KompNr). Hver komponent kan kjøpes inn fra et antall leverandører - til forskjellig innkjøpspris. Prisen er dermed plassert i en egen koblingsentitet LevKomp (leverandør/komponent).

En komponent kan kun inngå i ett bestemt produkt:

ER-diagram

En komponent kan inngå i vilkårlig mange produkter:

ER-diagram

Produkter kan være komponenter i andre produkter:

ER-diagram

Se logiske datamodeller.

Oppgave 4

Legesenter.

I første løsningsforslag blir avtaler identifisert ved hjelp av AvtaleNr, som gjerne kan være autonummerert.

ER-diagram

I neste løsningsforslag er AvtaleNr utelatt. Entiteten Avtale er nå svak og identifisert ved hjelp av tidspunkt + pasient (identifiserende forhold, heltrukken linje). Man kunne brukt lege eller rom i stedet for pasient.

ER-diagram

Oppgave 5

Lønnsøkning.

Diagrammet viser en løsning for å håndtere gamle verdier for stilling og lønn. Hvis kun nå-verdier skal lagres er det tilstrekkelig med entiteten Ansatt (inneholder attributter Stilling og Lønn). Det er valgt å lage separate entiteter for lønnshistorikk og stillingshistorikk, fordi en ansatt kan endre lønn uten å endre stilling (det motsatte er kanskje ikke så vanlig). Disse kunne vært slått sammen. Da ville en lønnsendring uten endring i stilling gi nullmerke i GammelStilling.

ER-diagram

Oppgave 6

Universitetsbygg.

Velger her en løsning med fire entiteter Bygning, Fløy, Etasje og Rom. Strengt tatt kunne man klart seg kun med entiteten Rom (navn på bygning, fløybokstav og etasjenr ville da bli attributter i Rom).

ER-diagram

Oppgave 7

Romreservasjonssystem.

Fordi undervisning i et kurs er felles for alle studenter som følger kurset (ikke "gruppedeling"), holder det å lagre hvilke kull (studentgruppe tatt opp på et bestemt studium et bestemt årstall) som følger undervisning i hvilke kurs (mange-til-mange forhold), og for hver reservasjon lagre hvilket kurs dette gjelder. Fra en reservasjon kan vi finne kurset, og fra kurset finner vi faglærer (kun 1) og kullene.

I forslaget under er Reservasjon svak mot Rom (som også er svak), som gjør at tilhørende tabell vil få en primærnøkkel sammensatt av 6 kolonner. Et alternativ er å innføre et løpenummer (ReservasjonsNr): Fjern understreking under Ukedag og StartTime, og endre til ikke-identifiserende forhold mot Rom.

ER-diagram

Oppgave 8

Eksamenssystem.

Det er valgt kun identifiserende forhold her: Studium, Kurs og Student har egne identifikatorer, alle de øvrige entitetene arver identifikator. KursIStudium, Opptak og Påmelding er koblingsentiteter, resultat av mange-til-mange forhold som er løst opp. Vi kunne i stedet innført surrogatnøkler (løpenumre) på en eller flere av disse entitetene.

Legg merke til egenforholdet mot Kurs: et kurs kan bygge på mange andre kurs, og mange andre kurs kan bygge på et kurs. Dette er et mange-til-mange forhold som må løses opp når vi oversetter til database.

ER-diagram

Se logisk datamodell.

Oppgave 9

Diskusjonsforum.

ER-diagram

Se logisk datamodell.

Oppgave 10

Sosialt nettverk.

Kommentarer:

ER-diagram

Se logisk datamodell.

Oppgave 11

Værstasjoner.

ER-diagram

Oppgave 12

SportWeb.

Verv er modellert som en kobling mellom idrettslag og person. Noen verv, for eksempel trenerverv, vil være knyttet til konkrete undergupper ("leder av fortballgruppa i Brann") og spillergrupper ("trener for J15 i fotballgruppa til Brann"). For å representere dette må modellen utvides med forhold mellom Verv og henholdsvis Undergruppe og Spillergruppe.

ER-diagram

Oppgave 13

Den Norske Fotturistforening.

Merk forskjellen på Turrute (rutebeskrivelsen) og en gjennomføring av en turrute (Fottur). Medlemmene melder seg på fotturer. Merk også hvordan entiteten DagsEtappe modellerer at en bestemt hytte er mål for en bestemt dag på en bestemt turrute. En-til-mange forholdet mellom Turrute og Hytte modellerer utgangspunktet for hele turen (starthytte).

ER-diagram

Se logisk datamodell.

Oppgave 14

Kart.

Dette løsningsforslaget kan man i høyeste grad diskutere!

Mark at det er mange-til-mange forhold mellom Punkt og Polylinje, og mellom Punkt og Polygon. Det åpner for at to polygoner kan "dele grense"; ett og samme punkt kan avgrense to fylker.

Merk også at det er en-til-en forhold mellom "geometri-objektene" Punkt, Polylinje og Polygon, og de andre objektene. Hadde vi hatt datatyper "Point", "Polyline" og "Polygon" kunne vi i stedet for egne entiteter lagt til et attributt "shape" i hver av entitetene By, Elv og Fylke. Les mer om slike objektorienterte mekanismer i kapittel 15.

ER-diagram

Oppgave 15

ER-diagrammer

Dette var nok en krevende oppgave – det er lett å bli forvirret når man lager en entitet som heter Entitet!

ER-diagram

Se logisk datamodell.


Løsningsforslag til oppgave 16 og 17 under er i første omgang tegnet med MySQL Workbench notasjon. Primærnøkler er vist med gule nøkkelsymboler, fremmednøkler som også er med i primærnøkkelen med røde nøkkelsymboler, og andre fremmednøkler med røde diamanter. For øvrige attributter brukes blå diamanter, fylte diamanter betyr NOT NULL.

 

Oppgave 16

Vikarbyrå

Dette løsningsforslaget er foreløpig lagt ut som en MySQL Workbench datamodell, og inneholder både primærnøkler (gule nøkler) og fremmednøkler (rød nøkler). Dette svarer til logiske datamodeller som forklart i kapittel 8.

Diagrammet under kan forenkles, det er tilstrekkelig med et en-til-mange forhold mellom Jobbsøker og Vikariat (et vikariat blir kun besatt av én jobbsøker). Dermed forsvinner behovet for koblingsentiteten Arbeidsforhold: Attributtene JobbsøkerEvaluering og VirksomhetEvaluering kan legges inn i Vikariat. Noen velger kanskje å plassere disse i en egen entitet Evaluering som kobles til Vikariat med et en-til-en forhold.

ER-diagram

Oppgave 17

Cruisebåter

Dette løsningsforslaget er foreløpig lagt ut som en MySQL Workbench datamodell, og inneholder både primærnøkler (gule nøkler) og fremmednøkler (rød nøkler). Dette svarer til logiske datamodeller som forklart i kapittel 8.

ER-diagram