Databasteknik: Inlämningsuppgift 1 - ER-diagram

I den här kursen ska du lösa, och lämna in, ett antal uppgifter. Det här är den första.

I tabellen med uppgifter står när det är meningen att du ska göra den här uppgiften, och när den senast ska lämnas in.

Det finns två skäl att ha deadlines för inlämningsuppgifterna under kursens gång:

Mål

Förberedelser

Läs i boken, och kanske också annat material, om datamodeller, scheman, datamodellering och Entity-Relationship-modellen. Läs åtminstone detta: En bra förberedelse till den här uppgiften är övning 1 i kapitel 2, Jultomtens databas (s 52 i kursboken).

Scenario

Det finns en klass av dataspel som kallas massively multiplayer online role-playing games, eller MMORPG. Det är spel där man spelar en rollfigur, till exempel en riddare, som går runt i en simulerad värld och slåss med monster, samlar skatter eller bara pratar med andra spelare som spelar samma spel och går runt i samma simulerade värld. Ett par kända såna spel är EverQuest och World of Warcraft.

Redan på sjuttiotalet fanns det textbaserade liknande spel, där man (precis som i de moderna MMORPG-spelen) spelar en rollfigur, går runt i en simulerad värld, och interagerar med andra spelare. En klass av såna textbaserade spel kallas Multi-user dungeon, eller MUD. Man styrde sin rollfigur med kommandon som "gå norrut", "ta upp väskan" och "anfall björnen".

I den här uppgiften ska vi skapa en databas som kan användas för lagring av data i ett MUD.

De saker som ska lagras i databasen är följande:

  1. Spelare. En "spelare" är egentligen inte en representation av själva spelaren, utan av den rollfigur som spelaren spelar i spelet. Spelaren (dvs rollfiguren) har ett unikt namn, en (inte nödvändigtvis unik) beskrivning, och några "stats", dvs värden som beskriver rollfigurens egenskaper: styrka, skicklighet, friskhet och hur många poäng som spelaren samlat ihop. Spelarna måste finnas kvar i databasen även när de loggar ut. En spelare som dör i spelet försvinner inte, utan förlorar bara sina saker och en del av sina poäng.
  2. Monster. Ett "monster" behöver inte vara grönt och ha många tänder, utan alla figurer i spelet som styrs av datorn och inte av en spelare kallas för monster. Ett monster har, precis som en spelare, ett namn, en beskrivning och dessutom samma "stats" som spelarna. En skillnad är att namnet inte behöver vara unikt, utan det kan till exempel finnas många grodor som allihop heter Groda. Ett monster som dör i spelet försvinner.
  3. Rum eller platser. Det här är de platser som spelarna och monstren kan gå omkring i. Varje spelare som är inloggad i spelet befinner sig i ett visst rum. Spelare som inte är inloggade, befinner sig inte i något rum. En del rum kan vara tomma. Varje rum har ett unikt nummer, ett (inte nödvändigtvis unikt) namn och en (inte nödvändigtvis unik) beskrivning.
  4. Saker. Det här är de saker som finns i spelet, förutom rum, spelare och monster. Det kan till exempel vara stenar, guldmynt, svärd och tulpaner. Sakerna kan ligga och skräpa i rummen, och dessutom kan både spelarna och monstren plocka upp sakerna och bära omkring på dem. Varje sak befinner sig antingen i ett visst rum, eller på en viss spelare eller monster. Varje sak har ett (inte nödvändigtvis unikt) namn och en (inte nödvändigtvis unik) beskrivning.
  5. Servrar. Spelvärlden är så stor att den inte kan hanteras av en enda dator, utan den är uppdelad på ett antal olika datorer, eller servrar. Varje rum hör till en viss server. Spelarna och monstren kan däremot flytta sig mellan servrarna. Varje server har ett IP-nummer (dvs dess Internet-adress), som kan ändras ibland men som är unikt vid varje tillfälle.
De flesta mudden var ganska små, och kördes på en enda server. De innehöll kanske tio tusen rum eller platser, och några tiotal samtidiga spelare. Men nu tänker vi oss att vi ska konkurrera med EverQuest och World of Warcraft, så vi vill kunna hantera hundratalas servrar, miljoner rum, och tiotusentals spelare.

Några förslag:

  1. Om det inte finns någon unik nyckel i en entitetstyp, så kan man skapa ett särskilt unikt identitetsnummer bara för användning i databasen.
  2. Det är ofta klokt att skapa ett unikt identitetsnummer även om det redan finns en unik nyckel, om den nyckeln är en textsträng eller olämplig av andra skäl.
  3. Man behöver inte använda arv eller svaga entitetstyper i den här uppgiften.
Några problem som man kan tänka på:
  1. Finns det saker i rutan ovan som egentligen inte ska vara med i ER-diagrammet? Varför ska de inte vara med?
  2. Finns det saker i rutan ovan som är svåra eller omöjliga att rita i ER-diagrammet? Hur gör man då?
  3. Fattas det information som egentligen skulle behövas för att rita ER-diagrammet? Hur gör man då?

Uppgift

Skapa ett Entity-Relationship-schema, även kallat ER-diagram, för databasen.

Redovisning

Rita upp ER-diagrammet (för hand eller med dator), och lämna det till läraren.

Det ska helst vara på papper, men i nödfall får ni skicka det med e-post. Se då till att det är i ett enkelt läsbart format, till exempel PDF. Word-dokument är inte enkelt läsbara. För inlämningar på papper finns det en brevlåda utanför studentexpeditionen i Teknikhuset.

Om något i diagrammet behöver förklaras, så skriv en förklaring.

Glöm inte en tydlig rubrik som beskriver vad det hela handlar om, datum, och namn.

Tanken är att i första hand ska två studenter arbeta tillsammans, och lämna in en gemensam rapport, men det går också bra med grupper, och rapporter, på en eller (i nödfall) tre studenter.

Om samarbete på inlämningsuppgifterna: Varje grupp (som normalt består av en eller två studenter) ska göra en egen lösning, och skicka in den, men det är inte förbjudet att samarbeta eller fråga andra studenter om hjälp. Däremot ska man i så fall tydligt ange vilka som man samarbetat med. Varje lösning måste ange namnet på alla som bidrog i arbetet. Samarbete är alltså tillåtet, men måste redovisas.

Observera vad det står i rutan ovanför. Det står att samarbete är tillåtet, men varje grupp ska göra en egen lösning. Något som inte är tillåtet att utgå från en existerande lösning, som man till exempel fått av en kamrat, och ändra lite i den så man tror att läraren inte ska känna igen den. Man måste alltså göra en egen lösning.


Thomas Padron-McCarthy (thomas.padron-mccarthy@oru.se), 7 november 2013