Uppgift 1
1 = användare
2 = webbklient (eller webbläsare eller web browser)
3 = renderad (dvs "uppritad") webbsida
4 = datornät
5 = GET-request
6 = klientkällkod (HTML-kod)
7 = webbserver
8 = serverkällkod (HTML-kod med servertillägg)
9 = webbprogrammerare
Uppgift 2
Så här kanske:
Uppgift 3
...
Uppgift 4
-
Varje student kan bara läsa tre kurser.
Vad händer när en student vill läsa en fjärde kurs?
-
En del SQL-frågor blir krångligare.
Om man till exempel vill hitta alla studenter som läser en viss kurs,
måste man söka i tre olika kolumner.
Om man, som ett annat exempel,
vill hitta de studenter som läser samma kurser,
måste man göra nio olika jämförelser!
-
Det blir tomma rutor (null) för de studenter
som läser färre än tre kurser,
och eftersom alla jämförelser med null blir falska
kan förekomsten av null i databasen ibland göra SQL-frågor krångligare.
Uppgift 5
Det är inte ett riktigt ER-diagram.
"Punkt punkt punkt" finns inte i ER-modellen.
Uppgift 6
Nu kan man lagra hur många kurser som helst för varje student,
men det finns ingen koppling till entitetstypen Kurs.
Det borde vara en sambandstyp och inte ett flervärt attribut.
Uppgift 7
Varje kurs kan bara läsas av en enda student!
Uppgift 8
Nu kan varje student läsa flera kurser,
och varje kurs kan läsas av flera studenter.
Men det dubbelsidiga fullständiga deltagandet
kan skapa problem när man ska lägga in data i en tom databas.
Det går inte att börja med att lägga in en student,
eftersom studenten måste läsa en kurs,
och då måste man alltså börja med att lägga in en kurs.
Men en kurs får inte finnas i databasen
utan att det finns studenter som läser den kursen,
och då måste man alltså börja med att lägga in en student!
Uppgift 9
Kanske så här:
Uppgift 10
Det finns flera fel:
-
Enligt ER-diagrammet är A1 och A2 unika var för sig,
så de är två olika kandidatnycklar.
De kan inte bilda en sammansatt primärnyckel,
eftersom primärnyckeln måste vara minimal.
Man behöver välja en av dem som primärnyckel.
-
Det finns inget i ER-diagrammet som säger att
E1, E2 och E3 är unika tillsammans,
eller om alla tre i så fall behövs för att de ska vara unika.
Såvitt vi vet är den kombinationen varken unik eller minimal,
så vi kan inte välja den som primärnyckel.
Vi bör införa en surrogatnyckel, till exempel kallad ID.
-
Sambandstypen B mellan entitetstyperna A och C
är ett många-till-många-samband,
så vi måste skapa en egen tabell för den sambandstypen.
Attributet B1 har ett värde för varje enskilt samband,
och måste bli en kolumn i den tabellen.
-
Attributet C2 är ett flervärt attribut,
och vi måste skapa en separat tabell för det.
-
Kolumnen C.E1 är en främmande nyckel som
refererar till kolumnen E.E1.
Men E.E1 är inte en kandidatnyckel i tabellen E,
utan bara en del av en sådan.
Värdet av en främmande nyckel måste alltid kopplas till en enskild rad
i den andra tabellen,
så den måste referera till en kandidatnyckel (normalt primärnyckeln).
-
Sambandstypen D mellan entitetstyperna C och E
är vänd baklänges i tabellerna!
Den är ett ett-till-många-samband,
där varje instans av C kan höra ihop med flera instanser av E.
Då måste E-tabellen referera till C-tabellen,
så man för varje E-instans kan ange vilken C-instans
den hör ihop med.
Även Attributet D1 måste bli en kolumn i E-tabellen.
Uppgift 11
Så här kanske
(om vi antar att samma värde på C2
inte kan förekomma flera gånger för samma C-instans,
men flera gånger för olika C-instanser):
A(A1, A2, A3, A4)
B(A1, C1, B1)
C(C1)
C2(C1, C2)
E(ID, E1, E2, E3, C1, D1)
Man skulle också kunna rita upp samma tabeller så här:
Thomas Padron-McCarthy
(thomas.padron-mccarthy@oru.se),
7 december 2022