Open Registry of Game Information 

  • Datenmodell

  • Hier werden Fachthemen diskutiert. Welche Daten soll das System enthalten? Welche Funktionen soll das Neusystem enthalten?
Hier werden Fachthemen diskutiert. Welche Daten soll das System enthalten? Welche Funktionen soll das Neusystem enthalten?

Moderators: MZ per X, gene

 #34923  by mr orange
 04 May 2011, 12:45
Ich habe mir das mit den Datenmodellen mal angeschaut. Allerdings klingt das alles sehr kompliziert und unflexibel. Mal mein Vorschlag (Der sicher noch diskussionswürdig ist). Kurzer Exkurs zu Magento (OS-Shop-System). Dort ist es so, dass man sog. "Configurables" und "Simples" hat. Das kann man sich wie eine Vererbung vorstellen: Die Configurables sind das eigentliche Produkt, die Simples hingegen könnte man als Varianten/Versionen/Was auch immer bezeichnen. Das würde bedeuten, dass es als Configurable das eigentliche Spiel (z. B. "Lotus 2") gibt. Das Configurable könnte enthalten:

- Originaltitel
- Hersteller
- Genre
- etc.

Davon gibt es jetzt Simples, die enthalten können:

- Unterschiedliche Titel (Falls es Unterschiede gibt (z. B. für europ. Markt <-> Japan. Markt)
- Unterstützte Hardware
- Sprachen
- Veröffentlichund
- etc.

Das als erster Ansatz.

Hardware und Spiele würde ich in eine n:m-Beziehung stellen. Dabei dann auch nicht unterscheiden, ob jetzt etwas Konsole ist oder PC oder sonst etwas. Das hat meiner Meinung nach dort nichts verloren.
 #34924  by gene
 04 May 2011, 21:16
Das mit den "Configurables" und "Simples" hört sich ja verlockend an. Erstaunlich, dass man, wenn man danach googlet, einige Seiten findet, die das als "toll" anpreisen.

Aber im Prinzip machen wir das schon so, wir nennen es nur nicht so :D
Ernsthaft: Natürlich hört sich das toll an, wenn man durch so eine Art "Vererbung" das Ganze vereinfachen kann. Aber das täuscht nur darüber hinweg, dass man trotzdem das Datenmodell so genau gestalten sollte, wie es nur geht.
Klar packen wir alle "übergreifenden" Felder wie z.B.d as Genre auf die oberste Ebene. Die anderen beiden von dir genannten Felder "Originaltitel" und "Hersteller" sind schon wieder problematisch anzusehen, denn die können je System schon wieder variieren, und zack - bist du damit wieder auf einer der unteren Ebene.

Hast du dir meine grafischen Modelle angesehen? Daran kann man ganz gut erkennen, was momentan wo zugeordnet werden kann.
 #34925  by mr orange
 05 May 2011, 11:43
dass man trotzdem das Datenmodell so genau gestalten sollte, wie es nur geht.

Ich sehe da keinen Widerspruch.
und zack - bist du damit wieder auf einer der unteren Ebene

Ok, das stimmt - aber wo ist da das Problem?


Ich sehe die Gefahr, dass hier eine unglaublich komplizierte Struktur erdacht wird, die später nur mit ganz wilden Klimmzügen benutzbar wird. Darauf sollte man auch achten. Was bringt einem die tollste Datenstruktur, wenn man sie nicht effizient nutzen kann?

Das, was ich mit dem oben genannten Prinzip machen wollte, ist, die Daten möglichst generisch zu handeln. Ich weiß nicht, ob es reicht, die Daten in Form von

Spiel -> System -> Erstveröffentlichung -> etc

zu strukturieren. Das sieht in meinen Augen zu speziell zugeschnitten aus.
 #34926  by gene
 05 May 2011, 19:33
Okay, ich denke, ich habe nun etwas besser verstanden, was du meintest.

Ich möchte es nochmal anders formulieren:

Angenommen, Spiel X ist für 5 Systeme erschienen.
Wenn nun bei den Systemen 1 bis 4 der Systeme der gleiche Entwickler E1 zuständig war, und nur bei System 5 ein anderer Entwickler E2, dann würde das mit dem bisherigen Entwurf so aussehen:

-- Spiel X
-- -- System 1
-- -- -- Entwickler E1
-- -- System 2
-- -- -- Entwickler E1
-- -- System 3
-- -- -- Entwickler E1
-- -- System 4
-- -- -- Entwickler E1
-- -- System 5
-- -- -- Entwickler E2

Mit deinem Vorschlag hätte man weniger Daten zu erfassen:

-- Spiel X
-- -- Default-Entwickler E1
-- -- System 1
-- -- System 2
-- -- System 3
-- -- System 4
-- -- System 5
-- -- -- Entwickler E2

Die Systeme 1 bis 4 würden den Entwickler E1 "erben" vom weiter oben vorgegebenen Default-Entwickler.

Das scheint auf den ersten Blick eine sinnvolle Sache zu sein - man erspart sich viele Doppelt-Eingaben.
Ich frage mich aber, wie übersichtlich das dann noch ist, wenn verschiedene Personen die Daten zu einem Spiel eingeben und man dann das, was der andere meinte, verstehen muss. Denn man muss es dann ja u.U. korrigieren.

Außerdem kann man eine Eingabe aller einzelnen Daten über eine geschickte Eingabe-Oberfläche auch so gestalten, dass man - wenn ein Entwickler E1 einmal im System angelegt ist - einfach z.B. über Checkboxen auswählen kann, bei welchen Systemen der Entwickler zugeordnet werden soll. Die "Doppel-Eingabe" ist dann genauer gesagt eine Mehrfach-Zuordnung einer einzigen Eingabe.

Ist es das, was du mit deiner Idee hauptsächlich meintest? Oder meintest du "mehr" ? Falls ja, wäre es evtl. hilfreich, wenn du eines meiner bisherigen Beispiele (siehe andere Threads) mal mit deinem Ansatz erläuterst.
 #34928  by mr orange
 06 May 2011, 12:40
wenn ein Entwickler E1 einmal im System angelegt ist - einfach z.B. über Checkboxen auswählen kann,

Sehe ich auch so - So was sollte man in jedem Fall als Entity ablegen, genau wie Hardware-Systeme, etc.
Ist es das, was du mit deiner Idee hauptsächlich meintest?

Nee - Du hast das ziemlich gut beschrieben. Auf die Art und Weise lassen sich Versionen mit beliebigen Attributen erstellen. So könnte man z. B. ein Spiel so aufbauen:

Spiel (Configurable)
- Entwickler
- Screenshot
- Titel

Spiel Version 1 (Simple)
- Anderer Entwickler
- Anderer Titel
- Erscheinungsdatum sowieso

Spiel Version 2 (Simple)
- Erscheinungsdatum

Spiel Version 3 (Simple)
- Anderer screenshot

Das heißt, man kann Versionen mit beliebigen Attributen erstellen.


Noch was anderes: Addons. Man könnte ja auch pro Spiel ein Attribut festlegen, um was für einen Typ es sich handelt (Spiel, Addon, ...) und dann ggf. auf das dazugehörige Spiel referenzieren.
 #34942  by floruc
 15 May 2011, 14:09
Im Grundsatz stimme ich vollkommen zu, dass das Datenmodell eine gewisse Flexibilität benötigt, um die Komplexität bei der Beschreibung abzudecken. Auf der anderen Seite sollte mit dem Modell klar und nachvollziehbar sein, was und wie etwas dokumentiert wird.

Um bei dem Beispiel Entwickler zu bleiben: Auch ich würde dafür plädieren den Entwickler auf der obersten Hierarchieebene abzulegen, weil ich es für eine wichtige und zentrale Information zum Spiel halte. Dennoch gibt es inzwischen zahlreiche Beispiele dafür, dass mehrere Entwickler an einem Spiel beteiligt sind (z.B. einer für den Singleplayer, ein anderer für den Multiplayer, z.B. für verschiedene Systeme, z.B. durch die Wechsel eines Spiels von einem zu einem anderen Studio,...). Daher erscheint es sinnvoll, den Entwickler direkt einem System zuordnen zu können. Ich würde dafür plädieren, das erstmal zu beizubehalten. Auf der obersten Ebene könnte man ja einfach alle Entwickler erneut aufführen. Das ist dann aber eine Sache der Präsentation.
 #34947  by gene
 16 May 2011, 07:42
Ich finde immer noch, dass diese Geschichte mit dem "Default-Entwickler" und das Anlegen von "Configurables" und "Simples" keine direkte Frage des Datenmodells ist, sondern eine Frage der Eingabeoberfläche.

Denn: Das Datenmodell sollte so exakt wie möglich sein. Nutz man so etwas wie "Vererbung", dann wird eine Anzeige für einzelne Systeme und eine gezielte Datenbankabfrage sehr schwierig (mach mal einen SQL auf Daten, die von anderen Daten erben - das ist absolut unüblich, und das wird seine Gründe haben).

Wenn man den "Entwickler auf oberster Ebene ablegt", dann ist man gezwungen, bei jeder (weiteren) Veröffentlichung, die einen abweichenden Entwickler hat, diesen Entwickler auch explizit anzugeben. Das würde sogar dann gelten, wenn man den Entwickler einer Veröffentlichung aus irgend einem Grund nicht kennt. Dann müsste man einen Eintrag wie "nicht bekannt" auswählen, denn sonst würde diese Veröffentlichung ja den "Default-Entwickler" erben. Auch wenn der Entwickler bekannt ist aber eben abweichend und man ihn nicht eingibt, wird er falsch geerbt.

Daher ist meine Meinung:
Das Datenmodell muss so exakt und so detailliert wie möglich sein. Das, was hier als "Vereinfachung" beschrieben wird, können wir auch durch komfortable Eingabemasken erhalten. Diesen Weg sollten wir beschreiten.
 #34948  by mr orange
 16 May 2011, 12:12
Dann verstehe ich trotzdem das Problem nicht. So, wie ihr das beschreibt, wird der/die Entwickler ja bei jeder Version des Spiels mit gespeichert werden müssen. Das ist ja dann das selbe, wie das, was ich beschrieben habe, nur, dass das "Configurable" eben keine Default-Werte dafür besitzt.

Vielleicht sollte man auch diese Sache mit den Default-Werten komplett vergessen, und das "Configurable" nur als - ich sag mal - Verbindung zwischen den einzelnen Versionen nutzen.