PMG1719/DB Beleg/Max

Wiki-Quelltext dieser Seite.

<language>SQL</language>
<p>Information: Die Wiki-Seite ist bereit zur Bewertung!</p>

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px"> Themenwahl und Ziel des Beleges </h2>
<p>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.</p>
<p>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.</p>

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px"> Gameplay </h2>
<p>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.</p>

<h5><u>Spieler- Die zentrale Entität</u></h5>
<p>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.</p>

<h5><u>Monster</u></h5>
<p>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.</p>

<h5><u>Clan</u></h5>
<p>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.</p>

<h5><u>Perk</u></h5>
<p>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.</p>

<h5><u>Item</u></h5>
<p>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.</p>

<h5><u>Effekt</u></h5>
<p>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.</p>

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px"> Modellierung der Datenbank </h2>
<p> 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.</p>

<h5><u> Entity Relationship Model (ERM) </u></h5>
[[Bild:Maxschloool_ERM_Screen.JPG]]

<h5><u> Konkretes Relationship Model (RM) </u></h5>

[[Bild:Maxschloool_RM_Screen.JPG]]

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px"> Grundlegende Begriffe mit Bezug zum Modell</h2>
<p>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.</p>

<h5><u> Normalform </u></h5>
<p>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.</p>

<u>Erste Normalform</u>
<p> Alle Attribute der einzelnen Entitäten liegen atomar vor, sie sind somit nicht auf weitere Grundbestandteile aufzuspalten. </p>
<u>Zweite Normalform</u>
<p> Alle Nichtschlüsselattribute sind nur von einem Primärschlüssel abhängig, in meinem Modell von den jeweiligen IDs. </p>
<u>Dritte Normalform</u>
<p> 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. </p>
<br>

<h5><u>Begriffe in den Datenbankmodellen</u></h5>
<u>Entität (Entity)</u>
<p>Ein übergeordnetes Datenobjekt, welches für die Datenbank relevantes, untergeordnete Eigenschaften besitzt. Entitäten sind im ERM rechteckig dargestellt.</p>
<u>Attribut</u>
<p>Attribute sind untergeordnete Eigenschaften einer Entität. Im ERM sind diese - rund dargestellt - durch eine direkte Verbindung zur jeweils angehörigen Entität gekennzeichnet.</p>
<u>Beziehungen (Relationen)</u>
<p>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).</p>

<h5><u>Kardinalitäten</u></h5>
<p>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".</p>

<u>1:1-Beziehung</u>
<p>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. </p>
<u>1:n-Beziehung</u>
<p>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).</p>
<u> n:m-Beziehung</u>
<p> 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.</p>

<h5><u>Transformation ins konkrete Relationenmodell (RM)</u></h5>
<p>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.</p>

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px"> Erstellen der Datenbank</h2>
<h5><u> Erstellung der Tabellen </u></h5>
<p> 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.</p>

<code id="5c4abbb8f3448">
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
);
</code>

<h5><u> Erstellung der Datensätze </u></h5>
<p> 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! </p>
<code id="5c417a2f3b656">
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);
</code>


<h2 style="background: lightgreen; border: 2px solid black; padding: 5px"> Abfragen</h2>
<p> '''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. </p>

'''1) Welche Spieler sind im Spiel angemeldet und was sind ihre zugeordneten Attribute?'''
<popup name="Tipp">
<p>Eine Abfrage, welche dir alle Elemente aus der Tabelle "SPIELER" anzeigt, erscheint hier sinnvoll!</p>
</popup>
<popup name="Lösung">
<pre>SELECT * FROM SPIELER;</pre>
</popup>

<run id="5c4176f7cb145"></run>

'''2) Welche Monster gelten als bedrohlich, dh. lassen beim Tod mehr als 75 Erfahrungspunkte fallen?'''
<popup name="Tipp">
<p>Über einen Vergleichsoperator kannst du das Attribut "Erfahrung" mit dem gegebenen Wert von 75 vergleichen.</p>
</popup>
<popup name="Lösung">
<pre>SELECT * FROM MONSTER WHERE Erfahrung > 75;</pre>
</popup>

<run id="5c460fadf1e6a"></run>

'''3) Was sind die 5 besten Spieler, dh. besitzen das höchste Level?'''
<popup name="Tipp">
<p>Statts aller Ergebnisse benötigen wir hier nur die Spalten "Username" und "Level".</p>
<p>Schlussendlich gibt es gleich Mehreres zu beachten: Eine Limitierung der Ergebnisse auf 5 (Hinweis: Befehl "LIMIT *Anzahl*"), sowie das Anordnen der ermittelten Ergebnisse nach dem Attribut "Level" in absteigender Reihenfolge (Hinweis: Befehl "ORDER BY *Spalte* DESC").</p>
</popup>
<popup name="Lösung">
<pre>
SELECT Username, Level
FROM SPIELER
ORDER BY Level DESC
LIMIT 5;
</pre>
</popup>

<run id="5c45fbe335bf2"></run>

'''4) Welche Clans (mit Namen und Kapazität) gibt es, und was sind ihre jeweiligen Anführer?'''
<popup name="Tipp">
<p>Hier musst du aus den beiden Tabellen "CLAN" und "SPIELER" auswählen, da du mit dem Fremdschlüssen "Anfuehrer_ID" eine Beziehung zum betreffenden Spieler ziehen kannst. Die Attribute musst du deshalb aus ihren jeweiligen Tabellen ermitteln (zB. "CLAN.Name").</p>
<p>Zum Schluss musst du die Spielernamen der Anführer zu ihrem betreffenden Clan zuordnen, indem die IDs von Spieler und Clan-Anführer verglichen werden.</p>
</popup>
<popup name="Lösung">
<pre>
SELECT CLAN.Name, CLAN.Kapazitaet, SPIELER.Username AS Anführer
FROM CLAN, SPIELER
WHERE SPIELER.Player_ID = CLAN.Anfuehrer_ID;
</pre>
</popup>

<run id="5c45fbe335c6b"></run>

'''5) Welche Items besitzt der Spieler mit der ID 14?'''
<popup name="Tipp">
<p>Neben den Tabellen "SPIELER" und "ITEM" ist aufgrund der n:m-Kardinalität hier auch ein Zugriff auf die Verknüpfungstabelle "besitzt" nötig.
Stimmen die Item_IDs in beiden Tabellen überein und sind die Player_IDs mit dem Wert 14 in beiden Tabellen vermerkt, so besitzt der Spieler ein Item.</p>
</popup>
<popup name="Lösung">
<pre>
SELECT ITEM.Name 
FROM SPIELER, ITEM, besitzt 
WHERE ITEM.Item_ID = besitzt.Item_ID AND besitzt.Player_ID = 14 AND SPIELER.Player_ID = 14;
</pre>
</popup>

<run id="5c4188a7afb0a"></run>

'''6) Welche Eigenschaften (Name, Beschreibung, Effekt-ID) besitzen alle Perks und Items, die den Effekt "Angriff" nutzen?'''
<p> <u>Achtung:</u> 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. </p>

<popup name="Tipp">
<p>In dieser hochkomplexen Aufgabe müssen ähnliche Abfragen für "ITEM" und "PERK" durchgeführt werden.
Der Name des Effekts des jeweiligen Items oder Perks muss dabei mit dem Wert 'Angriff' verglichen werden, um nur diesen Effekt zu "filtern". Ebenso muss dann die jeweilige Effekt-ID aus der Tabelle "EFFEKT" mit dem Fremdschlüssel aus der zweiten Tabelle verglichen werden, damit lediglich die Items, bzw. Perks angezeigt werden, welche den gesuchten Effekt tatsächlich besitzen.</p>
<p>Über den Befehl "UNION" kann optional für eine übersichtlichere Zuordnung eine Spalte für einheitliche übersichtlichere Darstellung gewählt werden, indem in zwei seperate "Suchanfragen" unterteilt wird.</p>
</popup>
<popup name="Lösung">
<pre>
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;
</pre>
</popup>

<run id="5c460fadf1efe"></run>

'''Box für freies Herumspielen am wahnsinnigen System'''
<run id="5c45f927503db"></run>

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px"> Reflexion der Datenbank</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px">Changelog</h2>
<p>'''11.01.19'''
Konzeptidee, Skizzierung der ERM und RM in Dia, Anlegung der Tabellen im Wiki</p>

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

<p>'''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</p>

<p>'''25.01.19'''
Finaler Feinschliff, Erweitern der Reflexion, Designoptimierung, Einbauen lustiger Spielereien</p>

<h2 style="background: lightgreen; border: 2px solid black; padding: 5px">Quellenverzeichnis</h2>
<u>Verwendete Programme/Tools</u>
<p>>Zur Modellierung der Relationenmodelle (ERM und RM) wurde das Tool DIA verwendet. (Download: https://www.heise.de/download/product/dia-43176)</p>
<p>>Zum Abbilden der releavnten Abschnitte der Modelle wurde das auf Windows vorinstallierte Tool SnippingTool benutzt.</p>

<u>Sonstige verwendete Quellen</u>
<p>>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/)</p>