Dette er gamle løsningsforslag tilpasset 3. utgave av boken.
Notasjonen for ER-diagrammer er endret noe fra 3. til 4. utgave. Gå til nye løsningsforslag for 4. utgave.
Bygninger og avgiftstyper.
Viser kun E/R-diagrammet etter utvidelsen til avgiftskode. Uten dette tillegget kan bygningstype håndteres som et attributt ved bygning.
Timelister.
Strengt tatt krever teksten kun at vi for hver kombinasjon konsulent/kunde/måned lagrer antall timer for hver sammenhengende arbeidsperiode. For å knytte arbeid til måned kan det være naturlig å lagre startdato og sluttdato for hver arbeidsperiode. Det gir følgende løsning:
Alternativt kunne man innført en ekstra entitet Timeliste som kun inneholdt attributter År og Måned, med forhold til Konsulent og Arbeid. Forekomster av Arbeid ville svare til "linjer" på en slik timeliste (for en bestemt konsulent for en bestemt måned).
Produktoppbygging.
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.
Jeg bruker tidspunkt + pasient for å identifisere en avtale. Jeg kunne brukt lege (eller kanskje 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 to entiteter Bygning og Rom. Strengt tatt kunne man klart seg kun med entiteten Rom (navn på bygning ville da bli et attributt i Rom). Motsatt, hvis det er ønskelig å lagre informasjon om hver enkelt fløy og etasje ville det være naturlig å innføre entiteter Fløy og Etasje.
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.
Eksamenssystem.
Legg merke til egenforholdet mot Kurs: et kurs kan bygge på mange andre kurs, og mange andre kurs kan bygge på et kurs.
Diskusjonsforum.
Sosialt nettverk.
De to forholdene mellom Innlegg og Person gjør at vi for hvert innlegg kan vite hvem som skrev det og på hvilken nettsiden det skal vises. Det svake forholdet mellom Person og Gruppe gjør at en (konkret) gruppe tilhører en bestemt person (en av vennelistene til personen). Mange-til-mange forholdet mellom Person og Gruppe vil bli til en koblingstabell i databasen.
Valg av datatype for attributtet ProfilBilde i Person avhenger av hvordan man vil lagre profilbilder. Hvis de skal lagres utenfor databasen (i bildefiler) er det naturlig å velge et (relativt romslig) tekstfelt som lagrer filnavn (med katalogsti). Hvis profilbildene skal lagres i databasen bør man velge en BLOB-datatype (Binary Large Object). Det kan være ønskelig å splitte Adresse i gateadresse, postnr (og kanskje til og med land).
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.
Utgave 2 av læreboken hadde en utvidet versjon av denne oppgaven. Her er et løsningsforslag til denne:
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.
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. 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!
Vikarbyrå
Løsningsforslag foreligger ikke ennå, men vil bli laget.
Cruisebåter
Løsningsforslag foreligger ikke ennå, men vil bli laget.