PMG2022/DB Beleg/Elia

Wiki-Quelltext dieser Seite.

<language>SQL</language>
== Idee & Ziel der Datenbank  ==
 Idee: Online Analytics Tool für das Spiel "League of Legends" nach dem Vorbild von [https://u.gg u.gg]
Ich selbst spiele gerne League of Legends. Bei diesem MOBA (Multiplayer-Online-Battle-Arena) spielen zwei Teams bestehend aus je 5 Spielern in einer Arena, der "Kluft der Beschwörer" gegeneinander.
Um zu gewinnen, muss ein Team den Nexus (eine Art Kristall) des gegnerischen Teams zerstören. [[Bild:Hilseduck_Lanes_cropped.jpg|400px|thumb|left|League of Legends Map]]Jeder Spieler spielt dabei einen der über 140 Champions, und übernimmt eine der 5 Rollen: entweder spielt er auf der "Top-Lane", der "Mid-Lane", im "Jungle", oder auf der "Bot-Lane" (dort spielen Supporter und ADC zusammen). Zudem wählt man vor dem Spiel Runen für seinen Champion aus, die unterschiedliche Vorteile bringen. Über das Spiel hinweg generiert man durch das töten von Minions / Monstern oder durch einen Kill an einem gegnerischem Spieler Gold, mit dem man sich dann Items kaufen kann. Diese verbessern stark die Fähigkeiten des eigenen Champions, z.B. mit mehr Schaden oder Rüstung. Gewinnt man ein Match, steigt man im Ligasysten (Eisen, Bronze, Silber, Gold, Diamant,..) auf. Jetzt ist natürlich interessant zu wissen, z.B. welche Runen extrem gute Spieler in hohen Ligen verwenden, oder was sie sich für Items auf dem Champion "XY" kaufen. Das ist der grundlegende Nutzen von Seiten wie [https://u.gg u.gg]. Sie tracken alle Spiele in League of Legends, speisen diese Datenmengen in eine Datenbank, und machen sie jedermann zugänglich. Selbstverständlich können die Datenmengen dann noch sinnvoll analysiert werden, und so z.B. festgestellt werden, welche Items gerade mit welchen Champions eine hohe Winrate (also auf alle Spiele gerechnet prozentuale Erfolgswahrscheinlichkeit) haben. Programme wie "Mobalytics" gehen dann noch einen Schritt weiter, analysieren die Spieler des gegnerischen Teams, und zeigem einem vor dem Spiel ihre Schwächen und Stärken auf. So raffiniert das auch klingen mag, alles basiert auf einer Datenbank, und dieser will ich mich hier annehmen. Um den Aufwand im machbaren Bereich zu halten, werde ich mich bei z.B. Items oder Runen auf wenige, beispielhafte, Parameter beschränken.


== ERM-Modell ==
[[Bild:Hilseduck_Erm_modulation(1)SMALL.jpg|1200px]]
<br><b>Entitäten:</b> Player, Game<br>
<b>Relations:</b> spielt<br>
<b>Kardinalitäten:</b><br>
[spielt]:<br>
Ein Player spielt mehrere Games.<br>
In einem Game spielen mehrere Player.<br>
>> Beziehung Game - Player = n:m<br><br>
Ich musste lange nachdenken, bis ich zu einem für mich zufriedenstellenden Ansatz für ein ERM-Modell gekommen bin.
Mein ursprünglicher Plan war, einzelne Entitäten für Player, Game, Item, Champion und Rune zu erstellen. Das daraus resultierende Konstrukt ergab allerdings stets keinen Sinn.
Denn Item, Champion und Runen sind in jedem Game unterschiedlich, aber werden gleichzeitig auch nur von einem Spieler gespielt. Nach langem Rätseln bin ich dann endlich auf die rettende Lösung gekommen:
Champion, Rune, und Item sind Attribute der Beziehung zwischen Player & Game (namens "spielt").
Denn ein Player "spielt" in einem Game Champion xy, kauft sich und somit spielt Item xy & spielt den Runenpfad xy in einem Game; somit ist es für mich völlig logisch, diese als Attribute der Beziehung "spielt" zu werten.
== Relationenmodell ==
[[Bild:Hilseduck_Rm_modell_v1.jpg]]<br>
<em>um das ERM Modell in ein RM Modell zu transferieren, befolgte ich die folgenden Schritte:</em><br>
<b>Grundgerüst:</b><br>
<b>1.</b> 2 Tabellen für die beiden Entitäten Game & Player<br>
<b>2.</b> Tabelle für die n:m-Beziehung "spielt" dieser Entitäten Game & Player >> Name: "Game_Player". game_id & player_id als Fremdschlüssel; bilden zusammen den Primärschlüssel. Wichtig: Attribute der <br>Beziehung "spielt" wie champion_id, champion_name, item_id, rolle, win/team, etc. werden als weitere Nichtschlüsselattribute in die Tabelle Game_Player eingefügt.
<br><br>
<b>Normalformen:</b><br>
<b>1. NF</b>; alle Attribute sind bereits atomisiert (liegen in ihrer kleinstmöglichen Form da); nichts zu verändern<br>
<b>2. NF</b>; alle Nichtschlüsselattribute hängen vom vollständigen Primärschlüssel ab.<br>
<b>3. NF</b>; einige Nichtschlüsselattribute in Tabelle Game_Player hängen voneinenander ab; z.B. champion_name von champion_id. >> Auslagerung von allen Champion-, Item-, und Rune-Attributen in eigene Tabellen (namens Champion, Item, Rune). champion_id, item_id, rune_id als Fremdschlüssel in Game_Player.
<br><br>
<b>letzte Veränderungen:</b><br>
lange Attribute wie z.B. champion_id werden mit c_id abgekürzt, selbiges für item_... & rune_... >> i_... | r_...<br>
Der Einheitlichkeit wegen wurden noch Start_Time bzw. End_Time von Game zu g_start_time bzw. g_end_time.<br>
Der Primärschlüssel für Game_Player ist zusammengesetzt aus g_id und p_id, da ein Spieler in einem Game stets nur einmal spielt >> Einzigartig, keine Dopplungen >> eignet sich für Primärschlüssel.
== SQL ==
<code id="622b63825b0d6"></code><run id="622b638c37b67"></run>
== Reflexion ==
== Quellen ==
<b>Verwendete Software:</b><br>
[https://sqliteonline.com/ sqlite.com] >> schöner online sql editor/compiler, mit nützlichen Features wie Vervollständigungsvorschlägen<br>
[https://erdplus.com/ ERDplus.com]<br>
<b>SQL-Tutorials:</b><br>
[https://www.tutorialspoint.com/sqlite/sqlite_constraints.htm sqlite check constraints]<br>
[https://sqlandme.com/2013/11/18/sql-server-custom-sorting-in-order-by-clause/ sql order by case]<br>
[https://stackoverflow.com/questions/50117301/how-do-i-subtract-two-columns-with-datetime-in-sqlite 2 datetime werte voneinander abziehen >> via temporärer umwandlung ins julianday format]<br>
<b>Projekt-Inspirationen:</b><br>
[https://u.gg u.gg]<br>
<br>