Open Registry of Game Information 

  • prototypisches Datenmodell

  • Alles für Entwickler: Java, JavaScript, REST-API, AngularJS, HTML.
Alles für Entwickler: Java, JavaScript, REST-API, AngularJS, HTML.

Moderators: MZ per X, gene

 #35169  by gene
 09 Aug 2011, 22:42
Ich möchte mit T410 beginnen - ja, mit der Programmierung.
Dafür möchte ich mit einer "Vorab-Version" des Datenmodells die Speicherung der Daten prototypisch umsetzen.

Hier mein erster Entwurf eines prototypischen Datenmodells:
(28.72 KiB) Downloaded 1499 times
 #35170  by MZ per X
 10 Aug 2011, 08:51
gene wrote:Ich möchte mit T410 beginnen - ja, mit der Programmierung.

Chapeau! :)

gene wrote:Dafür möchte ich mit einer "Vorab-Version" des Datenmodells die Speicherung der Daten prototypisch umsetzen.

Ich würde vorschlagen, dass wir Schritt für Schritt vorgehen und das Datenmodell von unten aufbauen, da sollten wir uns von so Sachen wie Firmen, Personen, Spielseserien besser erstmal nicht ablenken lassen.

Das Wichtigste ist in meinen Augen die Basis Spiel-VÖG-VÖ, die muss erstmal sitzen. Danach sollten wir den Patchlevel dranbauen, als nächstes dann Compilations und Addons abbilden. Wenn wir das geschafft haben, dann haben wir schon verdammt viel. :)

Einverstanden?

Ich werde heute Abend mal drüber nachdenken und ein paar Änderungsvorschläge beisteuern. Obwohl, heute ist Fußball... :D
 #35172  by MZ per X
 10 Aug 2011, 19:41
So, vor dem Fußballspiel noch ein paar schnelle Bemerkungen zu Spiel und VÖG:

Ein neuen Spieleintrag in der Datenbank gibt es ja dann, wenn das Spiel existiert oder zumindest nachweislich geplant war. Auf dieser Ebene brauchen wir zunächst erstmal einen oder mehrere Namen und eine einführende Beschreibung des Spiels. Bei den Namen sollten wir beachten, dass jede VÖ eines Spiels einen anderen Namen tragen kann, d.h. dass die endgültige Speicherung der Namen bei den VÖ erfolgen muss. Auf Spielebene brauchen wir daher nur bis zu fünf bekannte Namen des Spiels (meinetwegen auch Abkürzungen oder sowas) zuordnen, damit das Spiel in der Datenbank gefunden werden kann, bis alle VÖs eingetragen sind.

Die VÖG hat als Eigenschaft zunächst nur einen Titel, ein System und optional eine kurze Beschreibung. Achtung, wichtig: Die Beziehung zwischen VÖG und VÖ ist eine n-m-Beziehung, da es auch VÖs gibt, die mehrere Systeme beinhalten (Multiplattform-Release).
 #35173  by gene
 10 Aug 2011, 21:48
Hmm, also das muss ich alles nochmal sacken lassen:

MZ per X wrote:Ein neuen Spieleintrag in der Datenbank gibt es ja dann, wenn das Spiel existiert oder zumindest nachweislich geplant war. Auf dieser Ebene brauchen wir zunächst erstmal einen oder mehrere Namen und eine einführende Beschreibung des Spiels.

Sehe ich genauso. Deswegen gibt's bei dem Spiel ja einen "hauptnamen". Eine Beschreibung füge ich noch hinzu.

MZ per X wrote:Bei den Namen sollten wir beachten, dass jede VÖ eines Spiels einen anderen Namen tragen kann, d.h. dass die endgültige Speicherung der Namen bei den VÖ erfolgen muss. Auf Spielebene brauchen wir daher nur bis zu fünf bekannte Namen des Spiels (meinetwegen auch Abkürzungen oder sowas) zuordnen, damit das Spiel in der Datenbank gefunden werden kann, bis alle VÖs eingetragen sind.

Aaaalso, nochmal langsam.
Du sagst, dass jede VÖ einen eigenen Namen haben kann? Wie ist denn der Bezug von Name einer VÖ zu dem Land der VÖ? Kann eine VÖ auch direkt mehreren Ländern zugeordnet werden? Das würde dann Doppel-Eingaben vermeiden. Aber was wäre dann mit den Namen?
Was hältst du davon, wenn man die Namen/Land-Kombinationen erstmal zentral beim Spiel (also bei der obersten Ebene) erfasst, und dann bei jeder VÖ eine oder mehrer der vorhandenen Namen der VÖ zuordnen kann. Damit würde man Doppel-Erfassungen vermeiden können. Durch eine intelligente Eingabe-Oberfäche beim Erfassen der Daten bekommt der Anwender diese Details hoffentlich gar nicht mit.

MZ per X wrote:Die VÖG hat als Eigenschaft zunächst nur einen Titel, ein System und optional eine kurze Beschreibung.

Wozu braucht man bei der VÖG einen Titel? Und wozu braucht man eine Beschreibung, wenn man schon eine Ebene höher schon eine Beschreibung hat?

MZ per X wrote:Achtung, wichtig: Die Beziehung zwischen VÖG und VÖ ist eine n-m-Beziehung, da es auch VÖs gibt, die mehrere Systeme beinhalten (Multiplattform-Release).

Guter Hinweis, auch wenn ich etwas brauchte, um das zu verstehen :D
Für diese Tatsache wird die Oberfläche kniffelig...

Nachtrag:
Ich habe das Datenmodell mal erweitert. Ich habe u.a. zu einer Veröffentlichung eine zu-n-Beziehung mit einem "LandVeroeffentlichung"-Objekt erstellt. Dadurch können wir abbilden, dass die gleiche Veröffentlichung in mehreren Ländern aber (potenziell) zu verschiedenen Zeitpunkten erschienen ist.
Außerdem habe ich noch Screenshots (an mehreren Ebenen) und Fotos (an der Veröffentlichung) hinzugefügt.
Dieses Modell gefällt mir so schonmal ganz gut.

"Große" Dinge, die jetzt noch fehlen:
Genre
Patchlevel (das muss mir nochmal jemand erklären)
Altersfreigabe
Systemanforderungen (hautpsächlich bei Games auf Computer-Systemen)
Nummern-Kennzeichnung (EAN usw.)

(42.74 KiB) Downloaded 1314 times
 #35179  by MZ per X
 11 Aug 2011, 20:07
gene wrote:Du sagst, dass jede VÖ einen eigenen Namen haben kann? Wie ist denn der Bezug von Name einer VÖ zu dem Land der VÖ? Kann eine VÖ auch direkt mehreren Ländern zugeordnet werden? Das würde dann Doppel-Eingaben vermeiden. Aber was wäre dann mit den Namen?

Ja, es passiert ja ständig, dass der Name einer Originalentwicklung in die jeweilige Sprache übersetzt wird, oder dass zB russische Low-Budget-Spiele in Deutschland unter fantasievollen neuen Namen veröffentlicht werden. Eine VÖ kann sogar mehrere Namen haben, denk bloß mal an den Fall, dass auf der Packung ein Name steht, auf dem Titelbild dann ein anderer.

Ein anderes Problem ist ja, dass derselbe Karton in mehreren Ländern veröffentlicht wird (zB bei Deutschland, Österreich, Schweiz gang und gäbe), dass diese VÖ aber zu unterschiedlichen Zeitpunkten erfolgen kann. Dein Modellentwurf ist daher schon goldrichtig, allerdings sehe ich noch ein Problem bei den Firmen: Bei solchen multinationalen VÖ unterscheiden sich meistens die Distributoren / Publisher pro Land. Das müssen wir irgendwie abbilden.
gene wrote:Was hältst du davon, wenn man die Namen/Land-Kombinationen erstmal zentral beim Spiel (also bei der obersten Ebene) erfasst, und dann bei jeder VÖ eine oder mehrer der vorhandenen Namen der VÖ zuordnen kann. Damit würde man Doppel-Erfassungen vermeiden können. Durch eine intelligente Eingabe-Oberfäche beim Erfassen der Daten bekommt der Anwender diese Details hoffentlich gar nicht mit.

Großartige Idee ! Bei der Eingabe einer VÖ kann der Anwender entweder einen / mehrere bestehende Namen zuordnen oder bei Bedarf neu eingeben. Zu jedem Namen sollte bei der VÖ vielleicht noch eine kurze Beschreibung möglich sein, zB "Name auf der Box" oder "Name auf dem Titelbild" oder gar "Fehlerhafte Schreibweise des Namens in der Readme-Datei". :) Außerdem müssen dem Spiel auch Namen ohne VÖ zuordenbar sein, wie zB gängige Abkürzungen (zB DOTT) oder inoffizielle Namen (zB The Bard's Tale 4).

gene wrote:Wozu braucht man bei der VÖG einen Titel? Und wozu braucht man eine Beschreibung, wenn man schon eine Ebene höher schon eine Beschreibung hat?

Solange es pro System nur eine VÖG gibt, ist es einfach: Der Anwender gibt eine neue VÖ ein, und die Datenbank ordnet sie entweder einer bestehenden VÖG zu oder legt eine neue an. Aber sobald es pro System mehrere VÖG gibt (zB The Witcher Enhanced oder The Fall Reloaded), müssen wir mE schon irgendwie kenntlich machen, wodurch sich die VÖG eines Systems voneinander unterscheiden.

gene wrote:Dieses Modell gefällt mir so schonmal ganz gut.

Mir auch, ein guter Anfang. :)

gene wrote:"Große" Dinge, die jetzt noch fehlen:
Genre

Das pappen wir einfach an die Spielebene dran, die Einzelheiten folgen, wenn wir unsere Genredefinition haben.
gene wrote:Patchlevel (das muss mir nochmal jemand erklären)

Hierzu muss ich erstmal meine eigenen Beiträge nochmal lesen und verstehen... :mrgreen:
gene wrote:Altersfreigabe

1-n-Beziehung auf VÖ-Ebene?
gene wrote:Systemanforderungen (hautpsächlich bei Games auf Computer-Systemen)

Zur Redundanzvermeidung müsste das eigentlich auf die VÖG-Ebene, besser und genauer wäre aber der Patchlevel. Aber wie gesagt, da muss ich auch nochmal drüber nachdenken.
gene wrote:Nummern-Kennzeichnung (EAN usw.)

Das müsste eigentlich eindeutig bei der VÖ hin, oder?
 #35181  by gene
 12 Aug 2011, 23:18
So Jungs, unsere ersten Daten sind gespeichert! :D

Code: Select all
        Spiel spiel = new Spiel();
        spiel.setHauptname("Monkey Island 2");
        spiel.setBeschreibung("Tolles Spiel mit viel Humor!");
       
        Veroeffentlichungsgruppe vogAmiga = new Veroeffentlichungsgruppe(Spielsystem.Amiga);
        vogAmiga.addVeroeffentlichung(new Veroeffentlichung("Euro-Release", Distributionsweg.NormalePackung));
        spiel.addVeroeffentlichungsgruppe(vogAmiga);
       
        Veroeffentlichungsgruppe vogMsdos = new Veroeffentlichungsgruppe(Spielsystem.MSDOS);
        vogMsdos.addVeroeffentlichung(new Veroeffentlichung("Euro-Release", Distributionsweg.NormalePackung));
        vogMsdos.addVeroeffentlichung(new Veroeffentlichung("USA-Release", Distributionsweg.NormalePackung));
       
        spiel.addVeroeffentlichungsgruppe(vogMsdos);
       
        spiel.addTitel(new Titel("The Secret of Monkey Island 2", Sprache.DE));
        spiel.addTitel(new Titel("The Secret of Monkey Island 2: Le Chuck's Revenge", Sprache.EN));
 


Dieser Code mach diese SQLs:
Code: Select all
Hibernate: insert into Spiel (version, beschreibung, hauptname) values (?, ?, ?)
Hibernate: insert into Titel (version, name, spiel_id, sprache) values (?, ?, ?, ?)
Hibernate: insert into Titel (version, name, spiel_id, sprache) values (?, ?, ?, ?)
Hibernate: insert into Veroeffentlichungsgruppe (version, spiel_id, system) values (?, ?, ?)
Hibernate: insert into Veroeffentlichung (version, beschreibung, distributionsweg, spiel_id) values (?, ?, ?, ?)
Hibernate: insert into Veroeffentlichung (version, beschreibung, distributionsweg, spiel_id) values (?, ?, ?, ?)
Hibernate: insert into Veroeffentlichungsgruppe (version, spiel_id, system) values (?, ?, ?)
Hibernate: insert into Veroeffentlichung (version, beschreibung, distributionsweg, spiel_id) values (?, ?, ?, ?)


Und das sieht dann so aus:
(21 KiB) Downloaded 1137 times

(23.68 KiB) Downloaded 910 times

(13.33 KiB) Downloaded 739 times

(25.05 KiB) Downloaded 885 times


Macht Spaß! :mrgreen:
 #35183  by MZ per X
 13 Aug 2011, 13:12
gene wrote:Macht Spaß! :mrgreen:

Das glaube ich gerne. :D Schade, dass ich nur ein Programmierlaie bin, ich würde Dich gerne unterstützen. Aber man kann nicht alles haben.

Nur zur Info: Ich arbeite zur Zeit im Wiki am Datenmodell von Monkey Island. Ich brauche einfach mal ein paar echte Daten, um noch tiefer ins Modell einsteigen zu können.
 #35686  by gene
 02 Dec 2011, 09:13
Ich habe unser Datenmodell mal in die englisch-sprachige Welt transformiert ! Das wird die Basis für alles Weitere sein.
Modell_2011-11-30.gif
Modell_2011-11-30.gif (22.8 KiB) Viewed 24491 times
Und den gesamten Programmcode (und damit auch die Tabellen-Namen der Datenbank) ebenfalls:
tabellen_2011-11-20.gif
tabellen_2011-11-20.gif (31.41 KiB) Viewed 24491 times
Damit wurden auch die URLs englisch:
http://demo.oregami.org/games
http://demo.oregami.org/game/1
 #35699  by gene
 05 Dec 2011, 21:54
Mir ist beim ersten Versuch, eine Web-Anzeige zu programmieren, aufgefallen, dass wir bei einer mehrsprachigen Webseite sofort Probleme haben werden, wenn man "Freitext-Beschreibungen" für die Spieledaten eingeben kann. Ich hatte an diversen Stellen im Datenmodell ein "description"- oder ein "name"-Feld vorgesehen, aber bei einer mehrsprachigen Anzeige macht das herzlich wenig Sinn.

Hier eine Liste der bisherigen "Namens- und Beschreibungs-Felder", mit denen wir also irgendwas machen müssen:

ReleaseGroup und Release
name und descripton
Bisher hatte ich da sowas eingetragen wie "Verbesserte CD-Version" oder "Veröffentlichung 1-1 (PC, 5,25, DV, 256 Farben)" als Kopie der Überschrift aus unserem Wiki. Aber das macht wenig Sinn, eben wegen der Mehrsprachigkeit. Wir müssten also alle Dinge "ankreuzbar" oder "auswählbar" im Datenmodell ablegen. Teilweise ist das vorgesehen (ReleaseGroupType=Original|Enhanced|...), müsste dann in der Anzeige auch in jeder Sprache passend angezeigt werden. Solche Dinge wie "Farben-Anzahl", "Medium" usw. müssen dann halt auch ins Datenmodell, eben als Teil der Hardware-Details.

Game
description
Eine Beschreibung des Spiels halt. Ich denke, dies müssten wir dadurch lösen, dass man Beschreibungen in jeder beliebigen Sprache hinterlegen kann (jeweils eine). Würde das Datenmodell dann natürlich etwas aufblähen.

Title
Dies ist das ulitmative Beispiel für "Mehrsprachigkeit". Im Datenmodell ist bereits vorgesehen, dass man bei jedem Titel eine Sprache angeben muss, in der dieser Titel verfasst wurde. Ich frage mich dann allerdings, ob der Titel dann besser auf Release-Ebene zugeordnet werden sollte (oder sogar bei Besonderheiten pro Sprache dann halt noch eine Ebene Tiefer - also bei der Release-Land-Zuordnung).

Screenshot
description
Brauchen wir hier wirklich ein Beschreibungs-Feld? Es müsste dann wie oben bei den anderen Objekten ebenfalls mehrsprachig hinterlegbar sein, was das Datenmodell (hier meiner Meinung nach unnötig) aufbläht. Besser fände ich hier ein sinnvolles Tagging-System, mit dem ScreenshotType haben wir da schonmal eine Kategorisierung vorgesehen, die man ggf. erweitern könnte. Das Beschreibungs-Feld würde ich hier ganz gerne streichen.

Was meint ihr?
 #35706  by MZ per X
 09 Dec 2011, 21:04
Ich will zunächst mal ein paar allgemeine Gedanken zur Mehrsprachigkeit äußern. Wir hatten das irgendwo auch schonmal andiskutiert, ich finde es aber jetzt gerade nicht.

Grundsätzlich müssen wir ja unterscheiden zwischen Interface-Sprache und Datensprache. Die Interface-Sprache betrifft die statischen Teile unserer Seiten, die Datensprache die dynamischen. Wenn das Layout/Interface unserer Seiten einmal steht, werden wir sicher relativ schnell mehr Interface-Sprachen als Deutsch/Englisch anbieten können, da es sich um relativ einfache Übersetzungen handeln wird. Bei den Datensprachen sieht das anders aus. Hier muss eine neue Sprache komplett ins Datenmodell integriert werden, wie Du das oben schon gut ausgeführt hast.

Das bedeutet aber auch, dass wir für die jeweilige Sprache mehrere Mods haben müssen, die ihr mächtig sind und auch einen entsprechenden Forumsbereich. Die Community muss also auch in der Lage sein, eine neue Datensprache zu unterstützen. Für uns Gründer bedeutet das, dass wir ein Stück weit die Kontrolle abgeben müssen, weil wir die Qualität der Texte und Supports in der neuen Sprache nicht mehr beurteilen können. Wir müssen also etablierte Mitglieder/Mods haben, die der neuen Sprache mächtig sind und denen wir vertrauen können. Aus diesem Grund denke ich, dass als Datensprachen am Anfang ausschließlich Deutsch/Englisch in Betracht kommen, die Einführung einer weiteren Datensprache wird noch lange auf sich warten lassen.

Und wir müssen den Usern die Unterscheidung zwischen Interface- und Datensprache sehr deutlich machen, am besten über Profil-Einstellungen. Der Benutzer kann sich also eine Interface-Sprache auswählen und er kann eine bevorzugte Datensprache wählen. Weiterhin müssen bei allen descriptions Übersetzungsmöglichkeiten ins System eingebaut werden.
gene wrote:ReleaseGroup und Release
name und descripton
Bisher hatte ich da sowas eingetragen wie "Verbesserte CD-Version" oder "Veröffentlichung 1-1 (PC, 5,25, DV, 256 Farben)" als Kopie der Überschrift aus unserem Wiki. Aber das macht wenig Sinn, eben wegen der Mehrsprachigkeit. Wir müssten also alle Dinge "ankreuzbar" oder "auswählbar" im Datenmodell ablegen. Teilweise ist das vorgesehen (ReleaseGroupType=Original|Enhanced|...), müsste dann in der Anzeige auch in jeder Sprache passend angezeigt werden.
Was hältst Du davon, die Sprachen hardzucoden? Also ein feld "description_de" und eins "description_en"? Das wäre sicher die einfachste Variante, hat aber wahrscheinlich große Nachteile, wenn später mal noch eine neue Datensprache dazukommen soll.
gene wrote:Title
Dies ist das ulitmative Beispiel für "Mehrsprachigkeit". Im Datenmodell ist bereits vorgesehen, dass man bei jedem Titel eine Sprache angeben muss, in der dieser Titel verfasst wurde. Ich frage mich dann allerdings, ob der Titel dann besser auf Release-Ebene zugeordnet werden sollte (oder sogar bei Besonderheiten pro Sprache dann halt noch eine Ebene Tiefer - also bei der Release-Land-Zuordnung).
Hierzu hatten wir auch schonmal diskutiert, glaube ich. Wir wollten auf Spielebene für einfaches Suchen eine Titelliste ablegen, auf Ebene der VÖ sollte der User dann Titel zuordnen können nach dem Schema:
Beschreibung - Titel
Titel auf Box - Giana Sisters
Titel auf Ingame-Titelbild - Siana Gisters
Titel auf Handbuch-Cover - Giana's Sister
Weiterhin wird es noch Titel geben, die nur auf Spielebene abgelegt werden, wie zB informelle Titel oder allgemein anerkannte Abkürzungen.

gene wrote:Screenshot
description
Brauchen wir hier wirklich ein Beschreibungs-Feld? Es müsste dann wie oben bei den anderen Objekten ebenfalls mehrsprachig hinterlegbar sein, was das Datenmodell (hier meiner Meinung nach unnötig) aufbläht. Besser fände ich hier ein sinnvolles Tagging-System, mit dem ScreenshotType haben wir da schonmal eine Kategorisierung vorgesehen, die man ggf. erweitern könnte. Das Beschreibungs-Feld würde ich hier ganz gerne streichen.
Bitte nicht! Schau Dir mal die Screenshot-Beschreibungen bei MobyGames an. Die bieten von tollem Humor bis zusätzlichen Infos nahezu alles an. Man kann sogar Screenhots-Reihen erstellen, wo man beispielsweise einen Spielablauf in Bildern darstellt und in den Beschreibungen erläutert. Darauf würde ich nur ungern verzichten wollen.
 #35707  by MZ per X
 09 Dec 2011, 21:06
MZ per X wrote:Hierzu hatten wir auch schonmal diskutiert, glaube ich. Wir wollten auf Spielebene für einfaches Suchen eine Titelliste ablegen, auf Ebene der VÖ sollte der User dann Titel zuordnen können nach dem Schema:
Die Diskussion ist ein paar Beiträge weiter oben! :)
 #35708  by MZ per X
 09 Dec 2011, 21:07
gene wrote:Wie wäre es mit einem *etwas* ausführlichereren Feedback? :)
Nur der kurze Hinweis, dass ReleaseGroup und Release in einer n-n-Beziehung stehen müssen.