Entity-Relationship-Modell

Daniel Künne

Das Entity-Relationship-Modell von Peter Chen geht davon aus, dass die Welt nur aus Entitäten und deren Beziehungen zueinander besteht. Es bietet somit einen sehr einfachen Ansatz Datenbanken zu modellieren, da diese ebenfalls aus Tabellen (den Entitätstypen) und Schlüsseln (den Beziehungen) bestehen.

Import-Schema der OpenStreetMap-Daten

Wie bereits unter OpenStreetMap erwähnt ist, werden zuerst die geographischen Daten von den Spielregionen in den Server importiert und dort aufbereitet. Damit es zu keinen Inkonsistenzen zwischen Original-OpenStreetMap-Daten und den innerhalb eines Spiels verwendeten Koordinaten kommt, werden die Daten in unterschiedlichen Schemata auf der Datenbank vorgehalten.

Abb. 1: Datenbank-Schema osm_data

Die obige Grafik zeigt die vier Entitäten, die die importierten OpenStreetMap-Daten beinhalten. Dabei ist die Anzahl der Attribute von nodes und ways bewusst gering gehalten um keinen unnötigen Overhead durch die Vielzahl der Datensätze zu erzeugen. Allein die aktuell in der Datenbank gespeicherten Werte von Niedersachsen und Berlin umfassen circa 20 Millionen Datensätze und haben ein Datenvolumen von etwa 2,5 Gigabyte.

Die Tabelle showable_tags ist nicht direkt mit den OpenStreetMap-Daten verbunden, sondern beinhaltet die Tags, die für den Spieler erreichbare Knoten definieren.

Schema mit den Daten des Spiels

Die Informationen, die für ein laufendes Spiel gespeichert werden, liegen auf einem eigenen Datenbank-Schema pgs_prod. Dabei lassen sich zwei große Bereiche voneinander abgrenzen. Auf der einen Seite sind die Informationen, die zu einem konkreten Spiel gehören und auf der anderen die Daten eines konkreten Spielers.

Abb. 2: spielbezogene Daten des Datenbank-Schemas pgs_prod

In obigem ER-Diagramm sieht man, dass von dem Entitätstypen games zwei Relationships ausgehen. Zum einen ist dies die Verbindung zu der Spielerverwaltung mit dem Entitätstypen teams und zum anderen die Verwaltung der relevanten Informationen zu einer Spielfläche in gamefields. Zu den dort vorgehaltenen Daten gehören dabei die einzelnen Teilbereiche des Spielfeldes (areas), die Menge der für den Spieler erreichbaren Punkte (osmnodes) sowie die Informationen zu Tresoren (safes) und Geschenkpaketen (gifts). Im gezeigten Diagramm sieht man auch, dass intern alle Entitätstypen mit einem Positionsbezug von nodes abgeleitet sind und somit intern einfacher zu vergleichen sind.

Die Schnittstelle von spiel- zu spielerbezogenen Daten bilden die Entitätstypen teams und players. Beide verfügen über eine Beziehung mit einem Inventar, welche wiederum mit den unterschiedlichen gefundenen Gegenständen verbunden ist.

Eine Entität des Typen players ist immer genau einem Benutzer (users) zugeordnet, da es diesem erlaubt ist zeitgleich in nur einem Spiel aktiv zu sein. Außerdem wird zu einem Spieler gespeichert welche Effekte (effects) gerade für ihn aktiv sind. Dabei wird unterschieden zwischen den Sichtbarkeitseffekten der einzelnen Spielfelder und der Sichtbarkeit von Mitspielern, Tresoren und Geschenkpaketen.

Abb. 3: spielerbezogene Daten des Datenbank-Schemas pgs_prod


Page last modified on March 21, 2011, at 06:01 PM