Open Registry of Game Information 

  • Datenmodell: allgemein

  • 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

 #36108  by MZ per X
 11 Jul 2012, 20:48
Es ist an der Zeit, unser Datenmodell mal übersichtlich zu Papier zu bringen. Die Informationen sind zur Zeit in vielen einzelnen Threads versteckt und für Außenstehende schwer zu überschauen.

Ich habe daher einfach mal eine Wikiseite angefangen, wo ich die Dinge strukturiert festhalten will, die mir beim Modellieren der X-Wing-Serie so durch den Kopf schießen. Mir ist bewusst, dass eine grafische Übersicht sicher besser wäre, aber die kann ja später noch folgen. Ich komme mit dem Wiki gerade gut zurecht und will auch ein paar ausführliche Erläuterungen zu einzelnen Aspekten einfließen lassen.

Ihr findet die Wikiseite genau hier.
 #36191  by MZ per X
 04 Aug 2012, 22:25
gene wrote:Ich konnte deine "ASCII-Diagramme" nicht mehr mit ansehen ;-)
:D Coole Sache, das. Werde mich bald damit befassen.
 #36198  by gene
 11 Aug 2012, 14:14
Du bist da ja sehr aktiv, wie man sieht:
Image

Wie ist das, machst du dir die Arbeit nicht doppelt zu mir?
Image

Ich überlege nämlich, ob ich an "meinem" Modell weitermache, aber unsere beiden Modelle sehen unterschiedlich aus.
 #36199  by MZ per X
 11 Aug 2012, 23:07
gene wrote:Wie ist das, machst du dir die Arbeit nicht doppelt zu mir? Ich überlege nämlich, ob ich an "meinem" Modell weitermache, aber unsere beiden Modelle sehen unterschiedlich aus.
Mein Datenmodell-Entwurf steht ja noch am Anfang. Wir sollten uns natürlich schon irgendwann auf ein gemeinsames Datenmodell einigen und die Differenzen ausdiskutieren. :) Ich würde es bevorzugen, wenn wir die Arbeit im Wiki tun, da können alle zugucken und dieses PlantUML funktioniert auch gut.
 #36362  by gene
 26 Sep 2012, 20:24
Nun, da wir das neue Wiki haben, werden wir das Datenmodell bzw. die grafische Darstellung davon ja umstellen auf ein "Gliffy Diagramm" denke ich.

Ich habe mal angefangen.

Ich habe eine Frage im Hinblick auf deine bisherige UML-Grafik im alten Wiki:
Wozu genau dienen die "Connection"-Objekte? Die machen das Datenmodell sehr unübersichtlich, lass es uns doch erstmal ohne versuchen. Die "echten" Objekte sind viel wichtiger.

Vielleicht kannst du mir "umgangssprachlich" erklären, wozu die Connection-Objekte bzw. die darin abgelegten Informationen dienen sollen?
 #36363  by MZ per X
 26 Sep 2012, 22:37
gene wrote:Vielleicht kannst du mir "umgangssprachlich" erklären, wozu die Connection-Objekte bzw. die darin abgelegten Informationen dienen sollen?
Die Connections dienen dazu, zwei Objekte zu verbinden, die in einer m-n-Beziehung stehen. Wenn Du zwei Tabellen mit m-n-Beziehung verbinden willst, dann brauchst Du eine Verbindungstabelle.

Beispiel:

2 klassische Haupttabellen unseres Datenmodells sind Release und Person. An einem Release sind meist mehr als eine Person beteiligt und eine Person hat sehr oft an mehreren Releases mitgewirkt, sodass diese beiden Objekte in einer klassischen m-n-Beziehung stehen. Um diese Beziehung darstellen zu können, brauchst Du eine Verbindungstabelle:

Schlüssel-ID | Release-ID | Person-ID
1 | 25 | 101
2 | 25 | 102
3 | 25 | 103
4 | 26 | 102
5 | 26 | 103
6 | 26 | 104

Du siehst, dass an Release #25 die drei Personen 101-103 mitgewirkt haben und an Release #26 die Personen 102-104.

Das schöne an einer Verbindungstabelle ist aber, dass Du zu dieser Beziehung zusätzliche Daten speichern kannst, wie in meinem Beispiel die Rollen:

Schlüssel-ID | Release-ID | Person-ID | Rolle
1 | 25 | 101 | Programmierer
2 | 25 | 102 | Grafiker
3 | 25 | 103 | Musiker
4 | 26 | 102 | Grafiker
5 | 26 | 103 | Musiker
6 | 26 | 104 | Programmierer

Und genau das ist der Zweck meiner Connections, es handelt sich um Verbindungstabellen. :D Du hast ja auch schon welche in Deinem obigen Datenmodell-Entwurf drin, nämlich u.a. genau mein Beispiel: PersonRoleInRelease.
 #36366  by gene
 27 Sep 2012, 20:10
Okay, sowas habe ich mir natürlich schon gedacht. War ja auch naheliegend.

Aber:
Wenn wir in UML unser Objektmodell entwickeln, dann sind das noch nicht unbedingt direkt Tabellen. Tabellen sind ja schon die physische Abbildung des logischen Datenmodells.
Es gibt später evtl. mehrere Möglichkeiten, unser logisches Datenmodell in ein konkretes physisches umzuwandeln. Und dir wird es hoffentlich egal sein, welche Tabellen rauskommen - wenn wir die Fachlichkeiten alle abbilden, solltest du zufrieden sein :D

Übrigens nennt man sowas im UML-Umfeld "Association Class", hier kann man etwas darüber lesen.

Also: fachlich genau richtig so, weitermachen! 8)
 #36375  by gene
 28 Sep 2012, 05:06
hydr0x wrote:Ist halt die Frage ob man wirklich ein Datenmodell und ein E/R-Modell braucht ;)
Ich finde wir brauchen erstmal ein logisches Datenmodell ohne Persistenz-Bezug (also ohne direkten Zusammenhang zu Tabellen).
Daraus machen wir dann irgendwann ein konkretes physisches Datenmodell.

Ein Entity-Relationship-Modell ist halt etwas anders gelagert, es ist zum Einen eine andere Notation und ist von meinem Gefühl her schon etwas näher an dem physischen Modell.

Ich wäre also dafür, das Objektmodell als UML-Klassendiagramm zu erarbeiten und dann sehen wir weiter.
 #36377  by MZ per X
 28 Sep 2012, 08:12
gene wrote:Es gibt später evtl. mehrere Möglichkeiten, unser logisches Datenmodell in ein konkretes physisches umzuwandeln. Und dir wird es hoffentlich egal sein, welche Tabellen rauskommen - wenn wir die Fachlichkeiten alle abbilden, solltest du zufrieden sein :D
Nicht nur zufrieden! Wenn wir wirklich später alle Fachlichkeiten abbilden können, dann bin ich glücklich. :D

Nein, es ist ja kein Geheimnis, dass ich nur Laienerfahrung mit solchen Dingen habe. Wie Ihr Profis dann später meine Versuche in funktionierende Technik umsetzt, ist mir relativ egal, da ich eh nicht mitreden kann. Mir ist wichtig, dass wir viel über das Datenmodell diskutieren und viel daran rumbasteln und testen, damit es solide ist.
gene wrote:Also: fachlich genau richtig so, weitermachen! 8)
Mache ich! 8) Ich habe mir überlegt, dass ich eventuell die Connections zwischen den Objekten nur noch beschrifte und dann separat (darunter oder eine eigene Seite im Wiki) aufliste, um die Übersichtlichkeit des Modells zu steigern. Werde bei Gelegenheit mal probieren, wie das aussieht.
 #36381  by StevenStorm
 29 Sep 2012, 00:42
* PersonRoleInRelease: Was soll das darstellen? Soll hier der Marketing Verantwortliche für den Release eingetragen werden? Unterscheiden sich die Entwickler bei gleichen Spielen von Release zu Release?
* ReleaseCountry: Was soll hier für ein CountryKey benutzt werden? ISO Code? Soll wirklich für jedes Land das Release eingetragen werden? Regionen halte ich hier für teilweise sinnvoller, alleine schon aus dem Grund, dass man nicht die Welt aus dem Jahr xxxx abbilden muss.
Beispiel: Ein Spiel das 2000 in Jugoslawien erschien. Jugoslawien gibt es heute so nicht mehr, dafür haben wir Serbien & Montenegro (erst als eins, dann als zwei). Wie ist das zu handeln?
* Möglicher Fehler: Ich interpretiere das Modell aktuell so: Ein Release kann mehrere ReleaseGroups haben, diese bilden ab auf welchen Systemen ein Spiel erschienen ist. Das Release Datum ist aber an das Release gebunden - wie werden unterschiedliche Releasedaten für verschiedene Systeme abgebildet?
 #36386  by MZ per X
 02 Oct 2012, 21:02
StevenStorm wrote:* PersonRoleInRelease: Was soll das darstellen? Soll hier der Marketing Verantwortliche für den Release eingetragen werden? Unterscheiden sich die Entwickler bei gleichen Spielen von Release zu Release?
In der Theorie sollten sich die beteiligten Personen bei zwei Releases des gleichen Spiels nicht unterscheiden, die Praxis sieht aber meist anders aus, besonders bei Handbuch-Credits. Da fehlen auf einmal Personen, andere wurden hinzugefügt, da werden die Mitarbeiter des aktuellen Distributors mit aufgeführt, das Lokalisierungsteam ergänzt, oder Namen werden falsch geschrieben. Das Thema ist noch nicht ausdiskutiert, aber meine Meinung ist, dass wir zu jedem Release Credits speichern können müssen, auch wenn da einige Redundanz auftritt. Wenn die beteiligten Personen wirklich identisch sind (wie zB bei In-Game-Credits), dann können wir das ja im Datenmodell vermerken.
StevenStorm wrote:* ReleaseCountry: Was soll hier für ein CountryKey benutzt werden? ISO Code? Soll wirklich für jedes Land das Release eingetragen werden? Regionen halte ich hier für teilweise sinnvoller, alleine schon aus dem Grund, dass man nicht die Welt aus dem Jahr xxxx abbilden muss.
Beispiel: Ein Spiel das 2000 in Jugoslawien erschien. Jugoslawien gibt es heute so nicht mehr, dafür haben wir Serbien & Montenegro (erst als eins, dann als zwei). Wie ist das zu handeln?
Auch das Thema haben wir noch nicht diskutiert, ein gutes Beispiel. Ich denke auch, dass wir mit Ländern und Regionen arbeiten müssen. Insbesondere ältere Spiele sind ja teilweise in vielen Ländern identisch erschienen bzw. unterscheiden sich pro Land nur durch den Distributor. Was Dein Beispiel angeht, sehe ich eine Region "Balkan" und die vier Länder Jugoslawien, Serbien & Montenegro, Serbien und Montenegro.
StevenStorm wrote:* Möglicher Fehler: Ich interpretiere das Modell aktuell so: Ein Release kann mehrere ReleaseGroups haben, diese bilden ab auf welchen Systemen ein Spiel erschienen ist. Das Release Datum ist aber an das Release gebunden - wie werden unterschiedliche Releasedaten für verschiedene Systeme abgebildet?
Nein: Ein Spiel kann mehrere ReleaseGroups haben, mindestens eine pro System. Und jedes Release wird einer oder mehreren ReleaseGroups zugeordnet.Und jedes Release kann eine oder mehrere ReleaseDate(s) haben, je nach Quellenlage.

Das Datenmodell ist insgesamt noch ziemlich vorläufig und wird gerade weiter entwickelt. Und jeder, der mitdenkt, hilft viel dabei. :)
 #36387  by Sidasa
 02 Oct 2012, 21:57
moin.

Zur Länderfrage: ich finde es schon sehr wichtig, dass das Land wie es zum Zeitpunkt der Veröffentlichung hieß, so auch benannt wird. Vergleichbar mit dem Preis (z.B. DM versus EUR). Man kann ja immer noch - zusätzlich - aktuelle Infos mit ausgeben (wie z.B. den umgerechneten Preis als Vergleich).

Beispiel: Recherchen nach Computerspielen aus der DDR. Das muss IMO möglich sein.
Wäre die Suche nur nach Land plus Zeitraum möglich und wäre statt der DDR hier nur die BRD wählbar, hätte man bei den Suchtreffern inhaltlich Ergebnisse aus Ost- und Westdeutschland.