Datenmodell: allgemein

[MZ per X]

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.

[gene]

Ich konnte deine "ASCII-Diagramme" nicht mehr mit ansehen

Schau mal hier:
http://oldwiki.oregami.org/index.php/UML-Testseite

Alle Möglichkeiten von PlantUML sind in diesem PDF beschrieben.

[MZ per X]

Ich konnte deine "ASCII-Diagramme" nicht mehr mit ansehen

Coole Sache, das. Werde mich bald damit befassen.

[gene]

Du bist da ja sehr aktiv, wie man sieht:


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.

[MZ per X]

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.

[gene]

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?

[MZ per X]

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. Du hast ja auch schon welche in Deinem obigen Datenmodell-Entwurf drin, nämlich u.a. genau mein Beispiel: PersonRoleInRelease.

[gene]

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

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

Also: fachlich genau richtig so, weitermachen!

[hydr0x]

Ist halt die Frage ob man wirklich ein Datenmodell und ein E/R-Modell braucht

[gene]

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.

[MZ per X]

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

Nicht nur zufrieden! Wenn wir wirklich später alle Fachlichkeiten abbilden können, dann bin ich glücklich.

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.

Also: fachlich genau richtig so, weitermachen!

Mache ich! 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.

[StevenStorm]

* 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?

[MZ per X]

* 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.

* 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.

* 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.

[Sidasa]

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.