Databasteknik: Svar till övningar - kapitel 2, övning 1, Jultomtens databas

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.

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.