Max

Aus ProgrammingWiki

Information: Die Wiki-Seite ist bereit zur Bewertung!

Themenwahl und Ziel des Beleges

In meinem Datenbankbeleg möchte ich die Umsetzung eines Rollenspiel-Videospieles realisieren. Dieses Thema wählte ich, da ich mich freizeitlich oft an der Entwicklung interaktiver Inhalte, wie zum Beispiel Videospiele, versuche. Das Entwerfen eines geeigneten Datenbanksystems zu dieser Thematik schätzte ich somit als herausforderndes, aber ebenso anschauliches Exempel für die Anforderungen an den Beleg an.

Mit dem Datenbanksystem möchte ich lediglich den ansatzweisen Grundstein einer möglichen Umsetzungsidee solch eines Rollenspiels anstreben. Selbstverständlich würde mit steigender Komplexität der Spielinhalte auch der Umfang des Modelles zunehmen. Für diese grundlegenden Spielideen, welche ich unter dem Punkt "Gameplay" erläutert habe, versuche ich ein dennoch möglichst passendes und anwendbares Modell zu entwickeln, welches bei Bedarf problemlos erweitert werden könnte. Durch das Ausdenken kreativer Abfragen innerhalb der erstellten Datensätze wird zusätzlich ein sinnvoller Umgang mit der Datenbank erprobt, welcher gleichzeitig die Logik aller Beziehungen meines Modelles auf Herz und Nieren überprüft.

Gameplay

Zum Verständnis weiterer Inhaltsaspekte des Beleges ist ein Verständnis über die verwendeten Strukturen, welche auf dem Spielfluss des Rollenspieles (dem so genannten Gameplay) basieren, notwendig. Daher werden diese im Folgenden kurz erläutert, um eventuelle Missverständnisse oder sogar Unverständlichkeiten im ERM zu vermeiden.

Spieler- Die zentrale Entität

Vom Spieler gehen die zentralen Beziehungen aus. Für jeden Spieler wird eine neue, eindeutige Player_ID verwendet. Um im Spiel unter einem Synonym in Erscheinung treten zu können, wird ein Username benutzt. Ein Level zeigt, wie fortgeschritten ein Spieler ist. Für einen Levelaufstieg ist die Erfahrung ausschlaggebend. Wird eine bestimmte Erfahrungsgrenze überschritten, so steigt der Spieler ein Level auf, dabei wird das Erfahrungslevel wieder auf 0 . Wie hoch diese Erfahrungsgrenze ist, wird über einen weiteren Mechanismus (welcher im Modell selbstverständlich nicht implementiert ist) errechnet. Dieser sollte ermöglichen, dass Spieler eines höheren Levels mehr Erfahrung zum Levelaufstieg benötigen, als solche eines niedrigeren Levels. Umzusetzen wäre diese Technik beispielsweise über einen logarithmischen Zusammenhang. Die Lebenspunkte zeigen, wie viel Schaden ein Spieler erleiden kann, bevor er im Spiel stirbt.

Monster

Monster geben Spielern die Möglichkeit im Spiel weitere Erfahrung für einen Levelaufstieg zu erhalten. Jedes Monster besitzt dabei eine eindeutige ID sowie einen Namen, welcher im Spiel angezeigt werden könnte, sobald sich ein Spieler nähert. Tötet ein Spieler ein Monster, so erhält er dessen zugehörige Menge an Erfahrungspunkten.

Clan

Clans sollen Spielern die Möglichkeit geben, Bündnisse, in welchen sie gemeinsam in Erscheinung treten können, zu erstellen. Jeder Spieler kann dabei in genau einem Clan sein, natürlich kann es auch Spieler ohne festen Clan geben, somit kann man den aktuellen Clan auch jederzeit verlassen. Neben einer eindeutigen ID besitzt jeder Clan einen Namen und einen Anführer, welcher durch die jeweilige ID des Spielers festgelegt wird. Dieser kann als spezielle Einstellung im Clan eine Levelgrenze festlegen, welche bestimmt, welches Minimumlevel Spieler besitzen müssen, welche dem Clan beitreten wollen. Somit kann ausgeschlossen werden, dass neue Spieler mit einem niedrigen Level den Clan belästigen. Die Kapazität des Clans gibt an, wie viele Mitglieder er maximal aufnehmen kann.

Perk

Ein Perk stellt eine permanent anhaltende Fähigkeit dar, welche dem Spieler, solange er diese ausgerüstet hat, einen bestimmten Effekt verleiht. Dieser Effekt wird dem Perk dabei jeweils unter der zugehörigen Effekt-ID vermerkt. Über einen Namen und die dazugehörige Beschreibung kann ein Spieler beispielsweise in einem Auswahlmenü kompakt alle notwenidgen Informationen zum Perk erhalten. Wichtig ist, dass jeder Spieler lediglich einen Perk ausgerüstet haben kann, natürlich kann man diesen zu jedem beliebigen Zeitpunkt gegen einen anderen eintauschen.

Item

Items sind Gegenstände mit einer eindeutigen ID. Jedes Item besitzt zur Übersicht einen Namen und eine Beschreibung, welche der Besitzer einsehen kann. Ein Item kann, ähnlich eines Perks, einen bestimmten Effekt besitzen. Ist dieser über eine ID zugeordnet, so erhält der Spieler den Effekt so lange, wie er im Besitz des jeweiligen Items ist. Ein Spieler kann beliebig viele Items besitzen.

Effekt

Neben einer eindeutigen ID besitzt jeder Effekt einen Namen und eine Beschreibung, durch welche dem Spieler die Wirkungsweise erklärt wird. Effekte alleine haben keinen Bestand, sie sind also immer einem Item oder einem Perk zugeordnet.

Modellierung der Datenbank

Die Anlegung der Modelle erfolgte skizzenhaft auf einem Blatt Papier, im Anschluss wurden ERM und RM im Programm Dia mit den vordefinierten Designbögen "RM" und "Datenbank" modelliert.

Entity Relationship Model (ERM)

Konkretes Relationship Model (RM)

Grundlegende Begriffe mit Bezug zum Modell

Die im Modell angewandten Techniken sind auf Grundkenntnisse der Datenbankmodellierung zurückzuführen. Durch die nun folgende Wiederholung einiger Bestandteile versuche ich darüberhinaus zu begründen, wieso, bzw. wie, ich die Umsetzung auf diesem Weg vollzogen habe. Die einzelnen Entitäten werden zur Übersichtlichkeit deshalb im Folgenden (wie im ERM) in Großbuchstaben (Capslog) dargestellt.

Normalform

Bei der Modellierung liegt ein besonderer Wert auf der Einhaltung der ersten drei Normalformen, da diese Voraussetzung für ein gezielteres und einfacheres Arbeiten mit den Datensätzen begünstigen.

Erste Normalform

Alle Attribute der einzelnen Entitäten liegen atomar vor, sie sind somit nicht auf weitere Grundbestandteile aufzuspalten.

Zweite Normalform

Alle Nichtschlüsselattribute sind nur von einem Primärschlüssel abhängig, in meinem Modell von den jeweiligen IDs.

Dritte Normalform

Keine Nichtschlüsselattribute stehen in direkter Verbindung mit weiteren Nichtschlüsselattributen, ohne selbst als Primärschlüssel aufgespalten zu sein. Die Abhängigkeit zur jeweiligen ID ist eindeutig.

Begriffe in den Datenbankmodellen

Entität (Entity)

Ein übergeordnetes Datenobjekt, welches für die Datenbank relevantes, untergeordnete Eigenschaften besitzt. Entitäten sind im ERM rechteckig dargestellt.

Attribut

Attribute sind untergeordnete Eigenschaften einer Entität. Im ERM sind diese - rund dargestellt - durch eine direkte Verbindung zur jeweils angehörigen Entität gekennzeichnet.

Beziehungen (Relationen)

Beziehungen geben einen konkreten Zusammenhang zwischen zwei Entitäten an und können(!) selbst konkrete Attribute besitzen, welche die Relation genauer beschreibt. Im Modell sind Relationen durch rhombenförmige Symbole gekennzeichnet, welche neben der Verbindung mit den jeweiligen Entitäten auch einen konkreten Beziehungstypen angeben (siehe Abschnitt "Kardinalitäten"). Durch ein beschreibendes Wort (meist Verb) wird angegeben, wie der Zusammenhang zwischen den Entitäten verstanden werden kann. Meist ist diese Beziehungen beidseitig lesbar - ein mal aktiv (zB. A bearbeitet B) und ein mal passiv (zB. B wird von A bearbeitet).

Kardinalitäten

Die zwischen den Entitäten vorherrschenden Beziehungen geben Aufschluss über die gegenseitigen Strukturen, welche sich primär durch logische Konsequenzen aus dem Spielfluss (dem Gameplay) des Rollenspiels ergeben. Zur speziellen Erläuterung dafür dient der vorhergehende Inhaltsabschnitt "Gameplay".

1:1-Beziehung

Diese Kardinalität, welche lediglich zwischen SPIELER und MONSTER herrscht, ermöglicht eine jeweils eineindeutige Zuordnung. Diese habe ich in diesem Fall gewählt, da jeweils ein SPIELER genau ein MONSTER besiegen kann, bzw. zu einem Zeitpunkt ein MONSTER von nur genau einem SPIELER getötet werden kann.

1:n-Beziehung

Für die meisten Relationen erwies sich diese Kardinalität für am sinnvollsten. Dies lässt sich unter der Maßgabe der im Voraus erklärten Gameplay-Strukturen besonders damit begründen, dass jeder SPIELER als zentrales Objekt lediglich die Möglichkeit der Nutzung genau eines PERKs, bzw. dem Beitritt in nur einem CLAN besitzt. Zwischen PERK, bzw. ITEM und EFFEKT wird diese Kardinalität verwendet, da beide Entitäten jeweils nur einen Spezialeffekt nutzen sollen. Die Umsetzung dieser Kardinalität wird durch die Verwendung eines Fremdschlüssels erreicht. Diese wird bei mir besonders im RM erkennbar, da eine Visualisierung im ERM nicht möglich war. Die jeweilige Kennzeichnung der betreffendes IDs als Fremdschlüssel wird auch bei der Erstellung der Tabellen vorgenommen (FOREIGN KEYs).

n:m-Beziehung

Eine n:m-Kardinalität fand in meinem Modell lediglich bei der Relation zwischen SPIELERn und ITEMs Verwendung. Da viele (verschiedene) SPIELER im Besitz von mehreren ITEMs sein können, ist diese mehrdeutige Entitätszuordnung sinnvoll. Umgesetzt wurde sie (wie im RM erkennbar) durch eine Relationstabelle, in welcher Spieler_ID und Item_ID als Fremdschlüssel in Verbindung gesetzt wurden. Das problemlose Eintragen mehrerer Items über die zugehörige ID zum gleichen Spieler ist mit dieser Lösung ohne Weiteres möglich.

Transformation ins konkrete Relationenmodell (RM)

Nach der Modellierung des ERM wurde das Modell durch die Einhaltung der Transformationsregeln ins RM übernommen. Jede einzelne Entität wurde dabei zur eigenen Tabelle, in welcher Primärschlüssel kenntlich gemacht wurden. Die betreffenden Datentypen wurden jeweils nach logischem Kontext vergeben. Wie im Abschnitt "Kardinalitäten" erläutert, wurden je nach Beziehungstyp Fremdschlüssel in die jeweilige Entität eingefügt, bzw. entstand auf Grund einer n:m-Beziehung eine weitere Tabelle mit mehreren Fremdschlüsseln.

Erstellen der Datenbank

Erstellung der Tabellen

Durch die genaue Modellierung des RM aus dem ERM ist eine Übernahme der dortigen Tabellen durch Anwendung der SQL-Syntax möglich. Auch Primär- und Fremdschlüssel wurden in den jeweiligen Tabellen deutlich gemacht.

DROP TABLE IF EXISTS SPIELER; CREATE TABLE SPIELER( Player_ID int AUTO_INCREMENT, Username varchar(20), Level int, Erfahrung int, Lebenspunkte int, Coins int, Clan_ID int, Perk_ID int, PRIMARY KEY (Player_ID) ); DROP TABLE IF EXISTS CLAN; CREATE TABLE CLAN( Clan_ID int AUTO_INCREMENT, Name varchar(20), Kapazitaet int, Levelgrenze int, Anfuehrer_ID int, PRIMARY KEY (Clan_ID) ); DROP TABLE IF EXISTS MONSTER; CREATE TABLE MONSTER( Monster_ID int AUTO_INCREMENT, Name varchar(20), Erfahrung int, PRIMARY KEY (Monster_ID) ); DROP TABLE IF EXISTS PERK; CREATE TABLE PERK( Perk_ID int AUTO_INCREMENT, Name varchar(20), Beschreibung varchar(128), Effekt_ID int, PRIMARY KEY (Perk_ID) ); DROP TABLE IF EXISTS ITEM; CREATE TABLE ITEM( Item_ID int AUTO_INCREMENT, Name varchar(20), Beschreibung varchar(128), Effekt_ID int, PRIMARY KEY (Item_ID) ); DROP TABLE IF EXISTS EFFEKT; CREATE TABLE EFFEKT( Effekt_ID int AUTO_INCREMENT, Name varchar(20), Beschreibung varchar(128), PRIMARY KEY (Effekt_ID) ); DROP TABLE IF EXISTS besitzt; CREATE TABLE besitzt( Player_ID int, Item_ID int );

Erstellung der Datensätze

Um für die folgenden Abfragen auch geeignete "Testobjekte" zur Verfügung zu haben, eignet sich eine kompakte Palette von Datensätzen. Diese sind natürlich alle frei und ohne jeglichen Bezug zu real existierenden Personen erdacht!

INSERT INTO SPIELER VALUES(1, 'Schloool', 100, 250, 10, 10000, 1, 2); INSERT INTO SPIELER VALUES(2, 'ReitzOnTour', 23, 140, 10, 7346, 1, 1); INSERT INTO SPIELER VALUES(3, 'Helmbrecher2001', 12, 0, 10, 50, NULL, NULL); INSERT INTO SPIELER VALUES(4, 'BaytuzLP', 352, 254, 10, 152, 2, 1); INSERT INTO SPIELER VALUES(5, 'AlbarnerAlban', 13, 12, 10, 200, 3, 1); INSERT INTO SPIELER VALUES(6, 'KokosPalme', 53, 234, 10, 1636, 3, 3); INSERT INTO SPIELER VALUES(7, 'KillerSchulsprecher', 12, 250, 10, 10000, NULL, 1); INSERT INTO SPIELER VALUES(8, 'Teichrose', 454, 250, 10, 16354524, 2, 4); INSERT INTO SPIELER VALUES(9, 'FeuerFeuerFEEEEUER', 23, 52, 10, 434, 1, 1); INSERT INTO SPIELER VALUES(10, 'JeckerJeschke', 47, 245, 10, 3433, 1, 3); INSERT INTO SPIELER VALUES(11, 'NiedererSchuster', 32, 250, 10, 3672, 3, 2); INSERT INTO SPIELER VALUES(12, 'Bobicar', 1, 0, 10, 0, NULL, NULL); INSERT INTO SPIELER VALUES(13, 'Metal4Life', 100, 24, 10, 10000, 2, NULL); INSERT INTO SPIELER VALUES(14, 'MakeGodsWordHappen', 140, 56, 10, 13060, 3, 4); INSERT INTO CLAN VALUES(1, 'Schlossergilde', 10, 75, 1); INSERT INTO CLAN VALUES(2, 'Hardcorezockerbande', 25, 75, 8); INSERT INTO CLAN VALUES(3, 'Die Heidenverfolger', 20, 20, 14); INSERT INTO MONSTER VALUES(1, 'Kanalratte', 10); INSERT INTO MONSTER VALUES(2, 'Giftmettigel', 20); INSERT INTO MONSTER VALUES(3, 'Gurkenfressender Eber', 50); INSERT INTO MONSTER VALUES(4, 'Schweinebärmann', 100); INSERT INTO MONSTER VALUES(5, 'Nacktmull mit Pollunder', 100); INSERT INTO MONSTER VALUES(6, 'Kruseltier', 125); INSERT INTO PERK VALUES(1, 'Schnelläufer', 'Lauf schneller als Usain Bolt!', 1); INSERT INTO PERK VALUES(2, 'Hochspringer', 'Spring höher als ein afrikanischer Springfloh!', 2); INSERT INTO PERK VALUES(3, 'Angreifer', 'Füge mehr Schaden als jemals zuvor zu!', 3); INSERT INTO PERK VALUES(4, 'Verteidiger', 'Erhöhe deine Verteidigung signifikant!', 4); INSERT INTO ITEM VALUES(1, 'Heiltrank', 'Heilt 5 Lebenspunkte', 5); INSERT INTO ITEM VALUES(2, 'Laufschuhe', 'Deine Beine laufen wie von alleine', 1); INSERT INTO ITEM VALUES(3, 'Fettes Stahlschild', 'Wehrt Angriffe besser ab', 4); INSERT INTO ITEM VALUES(4, 'Schwert des Unterganges', 'Zerstört jeden kläglichen Gegner', 3); INSERT INTO ITEM VALUES(5, 'Flügel des Icarus', 'Du lernst das Fliegen', 6); INSERT INTO ITEM VALUES(6, 'Göffel', 'Küchenutensil mit spitzen Zinken', 3); INSERT INTO EFFEKT VALUES(1, 'Geschwindigkeit', 'Erhöht Laufgeschwindigkeit'); INSERT INTO EFFEKT VALUES(2, 'Sprung', 'Erhöht Sprunghöhe'); INSERT INTO EFFEKT VALUES(3, 'Angriff', 'Erhöht Angriff'); INSERT INTO EFFEKT VALUES(4, 'Verteidigung', 'Erhöht Verteidigung'); INSERT INTO EFFEKT VALUES(5, 'Heilung', 'Erhöht Lebenspunkte'); INSERT INTO EFFEKT VALUES(6, 'Flug', 'Erlernt das Fliegen'); INSERT INTO besitzt VALUES(1, 2); INSERT INTO besitzt VALUES(1, 3); INSERT INTO besitzt VALUES(2, 5); INSERT INTO besitzt VALUES(4, 1); INSERT INTO besitzt VALUES(4, 2); INSERT INTO besitzt VALUES(4, 4); INSERT INTO besitzt VALUES(7, 3); INSERT INTO besitzt VALUES(9, 2); INSERT INTO besitzt VALUES(9, 3); INSERT INTO besitzt VALUES(11, 2); INSERT INTO besitzt VALUES(11, 5); INSERT INTO besitzt VALUES(13, 1); INSERT INTO besitzt VALUES(14, 2); INSERT INTO besitzt VALUES(14, 4); INSERT INTO besitzt VALUES(14, 6);

Abfragen

Die dargebotenen Abfragen greifen alle auf die von mir entwickelte Datenbank zurück und sind in aufsteigender Komplexität angeordnet. Vielleicht kann die eine oder andere Abfrage als Übungsstoff für euch dienen - falls ihr auf keinen geeigneten Ansatz kommt, könnt ihr euch über die beiliegenden Tipp-Boxen Hilfe holen. Falls ihr kurz vor einem Nervenzusammenbruch steht, ist die Lösungsbox eure finale Rettung. Über die am Ende liegende Box könnt ihr selbst kreativ werden und weitere (für ein Videospiel dieser Art) relevante Abfragen erstellen - oder natürlich hirnrissigen Schwachsinn.

1) Welche Spieler sind im Spiel angemeldet und was sind ihre zugeordneten Attribute?

SELECT * FROM SPIELER;

ausführen

2) Welche Monster gelten als bedrohlich, dh. lassen beim Tod mehr als 75 Erfahrungspunkte fallen?

SELECT * FROM MONSTER WHERE Erfahrung > 75;

ausführen

3) Was sind die 5 besten Spieler, dh. besitzen das höchste Level?

SELECT Username, Level
FROM SPIELER
ORDER BY Level DESC
LIMIT 5;

ausführen

4) Welche Clans (mit Namen und Kapazität) gibt es, und was sind ihre jeweiligen Anführer?

SELECT CLAN.Name, CLAN.Kapazitaet, SPIELER.Username AS Anführer
FROM CLAN, SPIELER
WHERE SPIELER.Player_ID = CLAN.Anfuehrer_ID;

ausführen

5) Welche Items besitzt der Spieler mit der ID 14?

SELECT ITEM.Name 
FROM SPIELER, ITEM, besitzt 
WHERE ITEM.Item_ID = besitzt.Item_ID AND besitzt.Player_ID = 14 AND SPIELER.Player_ID = 14;

ausführen

6) Welche Eigenschaften (Name, Beschreibung, Effekt-ID) besitzen alle Perks und Items, die den Effekt "Angriff" nutzen?

Achtung: Die in der Musterlösung verwendete "UNION"-Anweisung komprimiert die Informationen verschiedener Tabellen in einer einzigen Spalte. In einer alternativen Lösung könnten diese Informationen zB. in lediglich einer Zeile angezeigt werden.

SELECT PERK.Name AS Name, PERK.Beschreibung AS Beschreibung, PERK.Perk_ID AS ID
FROM PERK, EFFEKT
WHERE EFFEKT.Name = 'Angriff' AND PERK.Effekt_ID = EFFEKT.Effekt_ID

UNION

SELECT ITEM.Name, ITEM.Beschreibung, ITEM.Item_ID
FROM ITEM, EFFEKT
WHERE EFFEKT.Name = 'Angriff' AND ITEM.Effekt_ID = EFFEKT.Effekt_ID;

ausführen

Box für freies Herumspielen am wahnsinnigen System

ausführen

Reflexion der Datenbank

Ein für mich sehr positiver Aspekt war eine erhöhte Arbeitseffizienz bei der Umsetzung, da ich nach dem exakt ausgearbeiteten Schema des Relationsmodelles arbeiten konnte. Nachdem ich das Konzept des Online-Rollenspieles von Beginn an im Kopf hatte und die einzelnen Gameplay-Elemente ausfeilte - besonders wie sie gegenseitig beeinflussen - war das ERM eine perfekte Möglichkeit, die einzelnen Beziehungen visuell darzustellen. Somit konnte ich von Anfang an einen besonderen Wert darauf legen, die einzelnen Entitäten in einer möglichst effizienten und übersichtlichen Art und Weise anzuordnen, sodass das Modell am Ende relativ übersichtlich ist. Aufgrund der zentralen Rolle der Spieler-Entität wirken viele der weiteren Entitäten nur noch ergänzend für das Gesamtbild der Datenbank. Nach der Ausarbeitung des Modelles war die Transformation mit Einhaltung der erläuterten Regeln ein Einfaches. Innerhalb der Arbeitsphase konnte ich insgesamt oft von der Darstellung im ERM, bzw. RM, profitieren. Ebenso sinnvoll erachte ich die gewählten Kardinalitäten zwischen den Entitäten, die ein kompaktes Beziehungssystem der Daten ermöglichen, zum anderen aber auch deren Integrität gewährleisten.

Neben der gezielten und erfolgreichen Umsetzung der geplanten Ideen, ergaben sich während der Arbeit an der Datenbank einige Probleme und Verbesserungsintensionen. Mit Hinblick auf einen anhaltenden Spielspaß ist selbsterklärend, dass die erstellte Datenbank lediglich ein absolutes Minimum an Funktionen zum eigentlichen Gameplay hinzufügt. So könnten beispielsweise Berechnungen für das Level-Up-System bereits im Datenbanksystem geschehen. Ebenso wäre ein direkter Einfluss der einzelnen Effekte auf den Spieler von Vorteil (zB. Erhöhung eines bestimmten Attributes wie Angriff, Verteidigung, Schnelligkeit,...). Einige Attribute könnten dabei zusätzlich in Verbindung zu Gegnern (anderen Spielern oder Monstern) stehen, um beispielsweise zu zeigen, wie viel Schaden ein bestimmter Angriff mit einem Item anrichten würde, was allerdings von Beginn an voraussetzen würde, dass zwischen einzelnen Entitäten ein anderer Beziehungstyp vorlieg. Eine derartige Ummodellierung wäre bei einer intensiveren Vorarbeits- und Arbeitsphase natürlich möglich, wurde in meinem Beleg aber vernachlässigt.

Auch wenn die Datenbank perfekt zum Sammeln und Verwalten von Spielerdaten ist, wäre eine serverseitige, systemnähere Datenverwaltung an manchen Stellen geeigneter. So würde beispielsweise die Sammlung von gameplayorientierten Inhalten (dem so genannten "Content") wohl unmittelbar im Programm, bzw. der Engine des Spieles umgesetzt werden. Dies würde in meinem Beispiel konkret Monster und sämtliche Items sowie Perks betreffen. Somit könnte die im vorhergehenden Punkt angesprochene Wechselwirkung zwischen diesen Komponenten viel simpler implementiert werden. Die Zuordnung der Items zum Spieler über die Datenbank halte ich wiederum für eine bessere Idee, da somit ein Synchronisieren der Daten um einiges vereinfacht wird.

Alles in Allem wurde durch die Anfertigung des Beleges für mich erkennbar, dass durch eine ausgiebige Planung eine noch bessere Umsetzung der Modelle möglich gewesen wäre. Im konkreten Beispiel eines Videospieles, in dem ein Großteil der gameplaybasierenden Daten effizienterweise unmittelbar im Spiel implementiert werden könnte, bleibt je nach Zweck und Datenverwaltungsaufwand des Spieles seperat abzuwägen, inwieweit dir Verwaltung über ein Modell wie dieses sinnvoll wäre.

Changelog

11.01.19 Konzeptidee, Skizzierung der ERM und RM in Dia, Anlegung der Tabellen im Wiki

18.01.19 Einfügen aller Grafiken, Einfüllen der Datensätze, Anlegung erster Abfragen und der Themenwahl, sowie nervenaufreibendes Fixen auftretender Fehler

19.01.19 - 24.01.19 Einfügen weiterer Datensätze und Abfragen, Struktur des Beleges mit gezielten Nachweisen am Datenbankmodell, Beginn der kritischen Reflexion, Übungsschema für Abfragen, Design- und Übersichtsverbesserungen

25.01.19 Finaler Feinschliff, Erweitern der Reflexion, Designoptimierung, Einbauen lustiger Spielereien

Quellenverzeichnis

Verwendete Programme/Tools

>Zur Modellierung der Relationenmodelle (ERM und RM) wurde das Tool DIA verwendet. (Download: https://www.heise.de/download/product/dia-43176)

>Zum Abbilden der releavnten Abschnitte der Modelle wurde das auf Windows vorinstallierte Tool SnippingTool benutzt.

Sonstige verwendete Quellen

>Neben meinen mickrigen Gehirnwindungen halfen besonders die offiziellen Microsoft-SQL-Docs bei der Klärung von Definitionen und Abfragestrukturen. (https://docs.microsoft.com/de-de/sql/)