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:
For å knytte avgiftsbeløp til de ulike bygningstypene er det naturlig å la Bygningstype bli en egen entitet:
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.
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:
En komponent kan inngå i vilkårlig mange produkter:
Produkter kan være komponenter i andre produkter:
Legesenter.
I første løsningsforslag blir avtaler identifisert ved hjelp av AvtaleNr, som gjerne kan være autonummerert.
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.
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.
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).
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.
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.
Diskusjonsforum.
Sosialt nettverk.
Kommentarer:
Værstasjoner.
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.
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).
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-diagrammer
Dette var nok en krevende oppgave – det er lett å bli forvirret når man lager en entitet som heter Entitet!
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.
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.
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.
