# Übersichtliche Zuweisung von Daten in Tabellen



## Darokh (30. Dez 2011)

Hi,
ich hoffe, ich bin hier im richtigen Forum gelandet...

Ich möchte Daten, die ich in einem Spiel erhalte, in einer Datenbank speichern, um sie später auswerten zu können.

Es gibt Spiele und so genannte "Subspiele". Ein Beispiel:

Spiel A soll die Reaktionsfähigkeit von Patienten verbessern. Dazu wird zunächst ein SubSpiel a gestartet. Nach einer gewissen Zeit wird aber ein weiteres Subspiel b parallel dazu geschaltet, um den Schwierigkeitsgrad zu erhöhen. Der Patient absolviert also mehrere Aufgaben parallel.

Spiel B könnte nun seinerseits auch aus SubSpiel a bestehen, aber noch SubSpiel c, d und e beinhalten.

Ein Spiel könnte auch als eine Zusammenstellung von SubSpielen verstanden werden, die "nach belieben" zusammengewürfelt werden können.

Also hätten wir schoneinmal soetwas:
Spiel A
SubSpiel a​SubSpiel b​Spiel B
SubSpiel a​SubSpiel c​SubSpiel d​SubSpiel e​
Jedes SubSpiel hat ein selbstständig laufendes Level / Schwierigkeitsgrad, welches sich mit der Zeit ebenfalls verändert.
Pro Level in einem SubSpiel sollen Durchschnittswerte gespeichert werden, wie beispielsweise Reaktionszeit, Geschwindigkeit, Anzahl korrekter Antworten. Das ist wiederum pro SubSpiel unterschiedlich.

Ab diesem Punkt fängt mein Kopf an zu schmerzen, wie ich diese Daten in MYSQL am besten tabellarisch auffange.

*Nochmals zusammengefasst*

- eine Session, zu einem bestimmten Zeitpunkt, Dauer
- einen Patienten / Spieler
- Spiele, welche aus verschiedenen SubSpielen bestehen

Konkrektes Beispiel: 
- Spiel A, bestehend aus SubSpiel a + b
- Spiel B, bestehnd aus SubSpiel a, c, d, e
- SubSpiel a erfasst PRO LEVEL (Level 1-10): Reaktionszeit
- SubSpiel b erfasst PRO LEVEL (Level 1-6): Anzahl korrekter Antworten, Anzahl falscher Antworten
- SubSpiel c, d, e erfassen PRO LEVEL ( Level 1-9): Reaktionszeit, Geschwindigkeit


Als erstes wollte ich für jedes SubSpiel eine eigene Tabelle anlegen. Dann pro Spiel wiederum auch eine Tabelle, und dort die SubSpieldaten wieder zusammenfügen. Dann wiederum pro Session zusammenführen.
Mir erscheint das zwar übersichtlich in Sachen Tabellenkonstruktion, aber glaube, dass es dann sehr viele unnötige Verweise gibt.
Das ganze sollte eben möglichst gut damit klarkommen, wenn ich noch mehrere Spiele / SubSpiele hinzufüge. 
Bei den ganzen Querverweisen habe ich dann aber irgendwie Angst, dass ich da nicht ordentlich mit umgehen kann.

Viele Grüße,
darokh


----------



## nillehammer (30. Dez 2011)

Nach dem Überfliegen Deiner Beschreibung sieht es für mich so aus, dass alle Spiele (egal ob Root-Spiel oder Sub-Sub-Subspiele) jeweils die gleichen Daten abspeichern. Das heißt für mich, es gibt genau eine Tabelle. Die Referenz auf das Parent machst du mit einer Fremdschlüsselspalte "parent", die auf den Primary key der selben Tabelle referenziert.

Der SQL-Code könnte ungefähr so aussehen (aus dem Gedächtnis getippt, also nich ungeding 100% korrekt):

```
CREATE TABLE Spiel
(
   id INTEGER UNSIGNED NOT NULL PRIMARY KEY,
   parent_id INTEGER UNSIGNED,
   description VARCHAR(40),
   FOREIGN KEY(parent_id) REFERENCES Spiel(id)
      ON DELETE CASCADE ON UPDATE CASCADE
);
```


----------



## bERt0r (30. Dez 2011)

@nillehammer: Das kann so nicht funktionieren, weil du eine m:n Beziehung zwischen Spielen und Subspielen hast: Ein spiel kann mehrere subspiele haben, ein subspiel kann in mehrerern parent spielen sein.

Im allgemeinen sollte man für sowas ein ER-Diagramm machen, besonders dann wenns zu kompliziert wird.
Nachtrag:
Eine m:n Beziehung löst man über eine seperate Tabelle (z.B Spiel_Hierarchie) auf, die dann aus 2 Fremdschlüssel von Spiel besteht und quasi die sub-super Mappings beinhält.
In wie weit es sinnvoll ist, die Ergebnisse wie Reaktionszeit, etc. auch noch extra als Tabell/Attribut zu erfassen hängt dann vom Anwendungsfall ab.


----------



## JanHH (2. Jan 2012)

Hm das ist doch eigentlich simpel. Ich würde daraus eine java-Klassenhierarchie bauen, daraus ergibt sich per JPA dann ja automatisch das Datenbankschema.

Eine Klasse Spiel und eine Klasse SubSpiel und eine Klasse Level.

in Spiel gibt es eine Liste

@OneToMany
private List<SubSpiel> subSpiele;

und in SubSpiel wiederum

@OneToMany
private List<Level> levels;

und ein int, welches den Typ des SubSpiels angibt (1=a, 2=b usw).

und in der Klasse levels gibts halt die member-Variablen/Properties Reaktionszeit usw, die Du da aufführst.

Wenn Du willst kann ich da gerne auch noch mal etwas mehr Code zu schreiben.


----------



## Darokh (2. Jan 2012)

Frohes neues Jahr erstmal!

Puh, das ist ja ne ganz schöne Menge nachzulesen  Zusätzlich zu meinem derzeitigen Java-Pensum.
Hm, über etwas mehr Code wäre ich sehr dankbar, dann check ist das sicherlich etwas schneller...


----------



## nillehammer (3. Jan 2012)

bERt0r hat gesagt.:
			
		

> @nillehammer: Das kann so nicht funktionieren, weil du eine m:n Beziehung zwischen Spielen und Subspielen hast: Ein spiel kann mehrere subspiele haben, ein subspiel kann in mehrerern parent spielen sein.


@bERt0r: Ich glaube, hier irrst Du. Wenn ich mich nicht völlig verlesen habe, hat jedes (Sub-)Spiel entweder keinen Parent oder genau einen Parent und damit ist es eine klassische Parent-Child-Beziehung, also 1:n.


----------



## bERt0r (3. Jan 2012)

Also ich habs so aufgefasst: 
Spiel 1 besteht aus Subspiel A und B
Spiel 2 besteht aus Subspiel A, C ,D und E


----------



## nillehammer (3. Jan 2012)

> Also ich habs so aufgefasst:
> Spiel 1 besteht aus Subspiel A und B
> Spiel 2 besteht aus Subspiel A, C ,D und E


Stimmt, steht da so...  Dann also m:n mit Beziehungstabelle...


----------



## Darokh (3. Jan 2012)

Jup, genau, n:m Beziehung.

Und jedes SubSpiel erhebt unterschiedliche Daten. Pro Level werden diese Daten dann gemittelt oder als Summe gespeichert --> also pro Lvl ein Wert pro Variable (also bspw. Reaktionszeit, Geschwindigkeit).


----------



## bERt0r (3. Jan 2012)

Wenn dieser wert immer Numerisch ist isses ja ganz einfach:
Tabelle Ergebnis, Fremdschlüssel für Spiel und Level, fertig.


----------



## Darokh (3. Jan 2012)

Also meinst du soetwas wie:
*Ergebnisse SubSpiel 1:*

ErgebnisIDSubSpiel_1---Level---Reaktionszeit---Geschwindigkeit---korrekte Antworten


*Ergebnisse SubSpiel 2:*

ErgebnisIDSubSpiel_2---Level---Korrekte Antworten---nocheinenWertDenIchErhebe


*Spiel 1 besteht aus SubSpiel 1+2:*

Spiel_1_ID---Fremschlüssel:ErgebnisIDSubSpiel_1---Fremschlüssel:ErgebnisIDSubSpiel_1


*MasterTabelle*
SessionID---User---FremdSchlüssel:Spiel_x_ID

Haut das hin?


----------



## bERt0r (3. Jan 2012)

Ich hab ein bisschen in einem Programm gespielt  :

Anhang anzeigen 3905

3 m:n Beziehungen: 
Zwischen Spiel und Spiel (Drückt eine Hierarchie aus mit Sub und Super-Spielen)
Zwischen Spiel und Ergebnistyp (Jedes Spiel hat eine Auswahl an Messgrößen, die es ermittelt)
Zwischen Ergebnis und Ergebnistyp (Hier stehen die erzielten Werte eines Spiels dann drinn)

Ich glaube das sollte so hinhaun.


----------



## JanHH (4. Jan 2012)

Was habt ihr denn da mit n:m immer? Das stimmt doch gar nicht.

Klar können mehrere Spiele SubSpiel A haben, aber das ist doch nicht das gleiche Exemplar von SubSpiel A, sondern ein anderes SubSpiel, aber halt ebenfalls vom Typ A. Das ist eine 1:n Beziehung, ganz eindeutig.

Ein Spiel hat eine 1:n-Beziehung zu den SubSpielen, wobei natürlich mehrere SubSpiele vom Typ "SubSpiel A" existieren können! Jedem Spieler sein eigenes, logischerweise.

Ein SubSpiel wiederum hat eine 1:n-Beziehung zu den Levels, aus denen es besteht.


----------



## Darokh (4. Jan 2012)

Da hat JanHH recht...


----------



## bERt0r (4. Jan 2012)

Du willst das ganze also in einem ODBMS speichern? Nun das ist dann wieder eine andere Geschichte. Ich weis nicht wie du dir das in einer relationalen DB vorstellst. Wie unterscheidest du die verschiedenen SubSpiel A Objekte in der Datenbank? Wie findest du das richtige für dein Spiel und Ergebnis? Wenn z.B der Highscore in Spiel A Subspiel A von Spiel B Subspiel A überboten wird, merkst du das nicht.


----------



## Darokh (4. Jan 2012)

Hm, vielleicht habe ich das noch schwer verständlich ausgedrückt oder etwas missverstanden.

Spiel 1 besteht aus SubSpiel 1, 2 und 3
Spiel 2 besteht aus SubSpiel 2, 3 und 4

Spiel 1 und 2 stehen für sich komplett isoliert - auch deren SubSpiele sind nicht untereinander vergleichbar.
Also 
Spiel 1 - SubSpiel 2  
Spiel 2 - SubSpiel 2

sind zwar praktisch gesehen genau die gleichen Spiele, aber können trotzdem nicht miteinander verglichen werden, da die Spiele unterschiedliche SubSpiele (oder sogar Aufgabenstellungen, bei gleichen Spielen) haben und somit der Schwierigkeitsgrad auch ein anderer ist.

Also in Spiel 1 ist SubSpiel 2 einfacher, weil die anderen SubSpiele einfacher sind.

Hilft das weiter?


----------



## narotiuncdwhear (4. Jan 2012)

Du willst also sowas ähnliches wie das hier programmieren?
Multitask | Puzzle & Skill Games | Play Free Games Online at Armor Games

Bist du dir wirklich sicher, dass die einzelnen Spiele dann auch nochmal unterteilt werden sollen? Irgendwann wirds nämlich einfach übertrieben schwer


----------



## JanHH (5. Jan 2012)

Hier mal der rudimentäre Java-Code für JPA-Entity-Klassen / Datenmodell. Getter/Setter wg. Übersichtlichkeit weggelassen.


```
@Entity
class Level
{
	@Id
	@Column
	@GeneratedValue(strategy=GenerationType.AUTO)
	private long id;

	private int reaktionszeit, anzRichtig, anzFalsch, geschwind;
}

@Entity
public class SubSpiel
{
	public static final int SUBSPIEL_TYP_A=1;
	public static final int SUBSPIEL_TYP_B=2;
	public static final int SUBSPIEL_TYP_C=3;
	public static final int SUBSPIEL_TYP_D=4;
	public static final int SUBSPIEL_TYP_E=5;

	@Id
	@Column
	@GeneratedValue(strategy=GenerationType.AUTO)
	private long id;

	private int type;

	@OneToMany
	private List<Level> levels;
}

@Entity
public class Spiel
{
	@Id
	@Column
	@GeneratedValue(strategy=GenerationType.AUTO)
	private long id;

	@OneToMany
	private List<SubSpiel> subSpiele;
}
```


----------

