Uppgift 1
...
Uppgift 2
Det skulle kunna vara så att bara en mask kan bo i varje äpple,
eller att det måste bo minst en mask i varje äpple,
eller att det bara kan växa ett äpple på varje träd,
eller att det måste växa minst ett äpple på varje träd.
Det finns inget i scenariot som motsäger dessa ytterligare villkor,
men eftersom de lägger mer bergränsningar på databasen än
vad som uttryckligen står i scenariot,
har jag i alla fallen valt den mindre restriktiva tolkningen.
Uppgift 3
Nej, "många till många", "ett till många" och så vidare handlar inte om hur många äpplen och träd det finns,
utan det handlar om hur många äpplen ett träd kan kopplas ihop med,
och hur många träd ett äpple kan kopplas ihop med.
Varje träd kan kopplas ihop med många äpplen, för det kan växa många äpplen på varje träd.
Alltså ska det vara många åt det hållet i sambandet.
Varje äpple kan kopplas ihop med ett enda träd, för ett äpple växer bara på ett enda träd, inte flera.
Alltså ska det vara ett åt det hållet i sambandet.
Uppgift 4
Scenariot går att tolka på flera olika sätt,
och för varje scenario kan man sen rita ER-diagrammet på flera olika sätt.
Här är i alla fall ett sätt, kanske det enklaste:
Några kommentarer:
-
Det stod i uppgiften att barnen kan önska sig, och få, presenter, men
vad är en present?
Den frågan måste vi reda ut innan vi ritar ER-diagrammet.
Vi ska antagligen ha en entitetstyp som heter Present,
men:
-
Är en sån present en viss enskild present,
som till exempel den här Sony Playstation 2 som står här på hyllan?
-
Eller är det en typ av vara, till exempel Sony Playstation 2,
som tomten sen delar ut hundratals exemplar av?
Det här har stor betydelse för hur vi ska rita resten av ER-diagrammet.
Själva entitetstypen Present ser kanske likadan ut,
men om en present är en typ av vara kan vi ge samma present till många barn.
Om en present är en viss enskild present, så ska vi nog inte göra det.
I det följande antar vi att presenter är typer av varor, inte enskilda saker,
men i verkligheten skulle vi ha frågat tomten
och diskuterat vad som blir bäst för vår databas.
-
Av det där med presenter ovan lär vi oss att
vi måste dokumentera, dvs skriva förklaringar till,
vad ER-diagrammet betyder.
Det räcker alltså inte alltid att rita upp och namnge entitetstyper och sambandstyper,
för de kan fortfarande betyda olika saker.
-
En annan sak som man kanske skulle vilja diskutera med tomten är att lagra om
barnen varit snälla eller inte. Ska inte det vara med i databasen?
Tomten räknade inte upp det bland de saker han ville ha med,
men beror det på att det faktiskt inte ska vara med, eller bara på att han glömde det?
Som professionell datamodellerare måste man ofta tänka ännu lite djupare och längre
än klienten, den som egentligen är experten på området!
Jultomten är ju expert på julklappar, men inte på datamodellering.
-
Vi måste skapa en nyckel för att unikt kunna identifiera varje barn.
Namn, adress och land räcker förmodligen inte.
Vi väljer ett enkelt nummer, Id.
-
Länder har visserligen redan en nyckel (Namn),
men det är ett ganska långt textfält,
och det är opraktiskt att referera till från andra tabeller.
Därför hittar vi på ett enkelt nummer, Id, för varje land,
som vi använder som primärnyckel.
-
Det står i uppgiften att vi ska kunna lagra önskelistor,
och om man vill kan man göra en entitetstyp som heter Önskelista.
Men även N:M-sambandstypen Önskar i ER-diagrammet ovan beskriver ju önskningarna,
dvs vilka presenter som varje barn har önskat,
och det är en enklare lösning.
-
Tänk på att N:M-samband bara tillåter en enda sambandsinstans per kombination,
så lille Felix, två år, kan bara önska sig en Sony Playstation 2.
Han kan inte önska sig Sony Playstation 2 en gång till, längre ner på sin önskelistan.
-
Barnen väljer sina önskningar ur samma mängd av presenter som de sedan får.
Tomten kanske skickar ut en katalog inför julen,
och så får barnen kryssa för de presenter de vill ha?
Om barnen skriver önskelistor på fri form kan de förstås önska sig helt andra saker
än de som tomten har, och önskningarna kan vara mer generella
("TV-spel" i stället för "Sony Playstation 2"),
otydbara eller bara konstiga.
Ska man hantera allt detta blir ER-diagrammet annorlunda.
En annan lösning:
Kommentarer om den andra lösningen:
-
Här har vi gjort en egen entitetstyp, Önskelista,
som representerar önskelistorna.
Därigenom kan vi spara information om själva önskelistorna,
till exempel vilket datum en viss lista ankom till jultomtens kontor.
Vi kan också hantera flera flera önskelistor från samma barn,
till exempel om barnet ändrar sig och skickar en ny önskelista.
Det är ganska typiskt för ER-diagram att saker som man vill lagra information om,
eller som man av någon annan anledning är extra intresserad av,
blir egna entitetstyper.
Saker som inte är lika intressanta kan ibland bli sambandstyper.
Vilket man väljer beror på vad som är mest praktiskt för det man ska använda databasen till,
och vad som känns naturligast i just det fallet.
-
Här har vi gjort önskningarna till en svag entitetstyp.
Thomas Padron-McCarthy
(thomas.padron-mccarthy@oru.se),
3 november 2022