[Modellierung] Verstoß gegen die NF?

[DefconDev]

Hallo zusammen,

ich bin mir nicht sicher ob ich gegen die Normalisierung verstoße, folgende Relationen:

SpielerID___Name___Elo-Rating
0_________Ole_____1600
1_________Gustav__1700

ID___SpielerID___Punkte
0____0_________5
1____1_________4
2____0_________-7

Die Spalte Punkte drückt aus, was ein Spieler pro Spieltag an Punkte generiert, abhängig davon ob er verliert oder gewinnt.

Die Spalte Elo-Rating soll immer den aktuellen Stand der Punkte widerspiegeln, also per update am jeweiligen Spieltag aktualisiert werden.

Jetzt war aber mein Gedanke die Relation umzugestalten:

SpielerID___Name___Start-Elo-Rating___Aktuelles-Elo-Rating
0_________Ole_____1500____________1498
1_________Gustav__1500____________1504

In diesem Modell, würde das Start-Elo-Ratung unverändert bleiben, und die zweite Spalte Aktuelles-Elo-Rating sich pro Spieltag verändern.
Theoretisch könnte man im ersten Beispiel das Start-Rating immer ableiten aus der Summe der Punkte die bis dahin erzielt worden sind. Im zweiten Beispiel wäre eine Abfrage für das das Start-Rating simpler zu gestalten.

Daher ist das zulässig im Sinne der NF?

 

[Flown]

Was du hier fragst hat nichts mit der Normalisierung zu tun.

 

[DefconDev]

Ist das keine Redundanz?
Wenn es kein Normalisierungsptoblem ist, ist meine Idee zulässig?

 

[truesoul]

Hallo.

Vielleicht ist das mal was für dich:

http://www2.cs.uni-paderborn.de/fachbereich/AG/boettcher/lehre/WS0102/dbis/dbw99k5n.html

Also zu deinen beiden fragen: Nein und Ja.

Wenn es kein Normalisierungsptoblem ist, ist meine Idee zulässig?

SpielerID___Name___Start-Elo-Rating___Aktuelles-Elo-Rating
0_________Ole_____1500____________1498
1_________Gustav__1500____________1504

Das kann auch so gemacht werden:

ID___SpielerID___Start-Elo-Rating___Aktuelles-Elo-Rating
ID___0_________1500____________1498
ID___1_________1500____________1504

 

[truesoul]

Hallo.

Vielleicht ist das mal was für dich:

http://www2.cs.uni-paderborn.de/fachbereich/AG/boettcher/lehre/WS0102/dbis/dbw99k5n.html

Also zu deinen beiden fragen: Nein und Ja.

Wenn es kein Normalisierungsptoblem ist, ist meine Idee zulässig?

SpielerID___Name___Start-Elo-Rating___Aktuelles-Elo-Rating
0_________Ole_____1500____________1498
1_________Gustav__1500____________1504

Das kann aber auch so gemacht werden:

ID___SpielerID___Start-Elo-Rating___Aktuelles-Elo-Rating
ID___0_________1500____________1498
ID___1_________1500____________1504

 

[DefconDev]

Mir ist schon bewusst was der Begriff Redundant bedeutet, aber was mich halt irritiert ist die Spalte aktuelles Rating, die indirekt auch eine wiederholte Information ist.

 

[Meniskusschaden]

Welchen Zweck hat denn die Elo-Zahl in der Spieler-Tabelle (bei Ole 1600). Sie entspricht ja weder dem Startranking, noch dem aktuellen Ranking? Apropos Startranking: Start wovon? Startwert für ein Turnier, Startwert am Spieltag, Erster Wert, den der Spieler jemals hatte, ...?

 

[truesoul]

Ja schon, wenn zwei Spieler ein aktuelles Rating von 1498 hat.

ID___Aktuelles-Elo-Rating___SpielerID
0______1498____________0
1______1498____________1
2______1504____________2

Würde natürlich gut gehen und wäre meine Wahl. Lass Spielertabelle auch als solche.

 

[DefconDev]

Sobald ein Spieler erstellt wird bekommt er einen elowert, dieser wird eingetragen in Start-Elo-Rating. Das hat nich mit dem Ranking zu tun. Da wird auch nichts sortiert.

 

[truesoul]

Die rede war von Aktuelles-Elo-Rating nicht von Start-Elo-Rating.

Aber wenn, warum auch immer, die Start-Elo-Rating unterschiedlich ausfallen sollte, wäre dann die gezeigte Variante #8 besser.

 

[Meniskusschaden]

Die rede war von Aktuelles-Elo-Rating nicht von Start-Elo-Rating.

Für mich geht es darum, die Aufgabenstellung zu verstehen. Die ist in meinen Augen nämlich noch völlig unklar. Anfangs hatten wir beispielsweise zwei Einträge für Spieler 0 (+5 und -7), die dann zu einer Zeile (1500 und 1498) verdichtet wurden. Sind das nun zwei Spieltage für Spieler 0, oder zwei Wertungen an demselben Spieltag? Hätte es also statt der Zeile (1500, 1498), die zwei Zeilen (1500, 1505) und (1505, 1498) gegeben, wenn die Wertungen nicht zum selben Tag gehören? Soll man nachträglich die Ratings vergangener Spieltage ermitteln können oder genügt immer das aktuelle Rating? Ich kann mir aktuell noch ziemlich viele Möglichkeiten vorstellen, wie das alles gemeint sein kann. Die Diskrepanz zwischen aktuellem Rating (1498) und Rating in der Spielertabelle (1600) ist auch immer noch unklar.

 

[DefconDev]

Der Anfangselowert ist ein Wert der einmal festgelegt wird, in der Regel von mir als Admin. Also der erste Wert eines Spielers der jemals gesetzt wurde.

@Meniskusschaden
Die Werte stehen nicht direkt im zusammenhang.

Aktueller elo wert ist der Wert der sich aus Start-Elo-Rating und punkte pro Spieltag ergibt. Spieltag ist aber ein Zeitraum an dem ein Spieler mehrere Spiele absolvieren kann.

 

[mrBrown]

Ich würde deinen ersten Ansatz nutzen, und den Startwert pro Spiele und die Veränderung pro Tag speichern.
Zusammen ergibt das jeweils das aktuelle Ranking, und du verlierst die Entwicklung des ganzen nicht.

Sollte die Performance zu schlecht werden, würde ich zusätzlich (auch wenn es zu Lasten der Redundanz geht) eine zusätzliche Tabelle für "Snapshots" des aktuellen Rankings anlegen, welche dann zb täglich oder bei Änderungen aktualisiert wird - so ein bisschen Event-Sourcing-mäßig

Ja schon, wenn zwei Spieler ein aktuelles Rating von 1498 hat.

ID___Aktuelles-Elo-Rating___SpielerID
0______1498____________0
1______1498____________1
2______1504____________2

Würde natürlich gut gehen und wäre meine Wahl. Lass Spielertabelle auch als solche.

Das ist aber keine wirkliche Redundanz, Werte sind ständig redundant, nur Entitäten sollten nicht Redundant sein.

Die ID ist in der Tabelle auch ziemlich überflüssig, und damit auch die ganze Tabelle, man kann das Ranking direkt im Spieler unterbringen...

 

[Thallius]

Weder das eine noch das andere Rating hat was in der Tabelle zu tun. Wenn Du das Rating brauchst, dann rechne es aus der anderen Tabelle aus.

 

[Flown]

Leg dir eventuell eine View an die dir das gewünschte Ergebnis Tag für Tag präsentiert (wie @Thallius schon erwähnt hat).

 

[Meniskusschaden]

Der Anfangselowert ist ein Wert der einmal festgelegt wird, in der Regel von mir als Admin. Also der erste Wert eines Spielers der jemals gesetzt wurde.

Das ist mir leider immer noch zu konfus. Der Anfangselowert ist also der Wert, der in der Spielertabelle festgelegt wird? Bei Ole demnach 1600?

Aktueller elo wert ist der Wert der sich aus Start-Elo-Rating und punkte pro Spieltag ergibt. Spieltag ist aber ein Zeitraum an dem ein Spieler mehrere Spiele absolvieren kann.

Das heisst "Start-Elo-Rating" ist der Startwert des Spielers an dem Spieltag und "Aktueller Elo Wert" ist der Endwert des Spielers an dem Spieltag? In folgender Tabelle gibt es demnach eine Zeile pro Spieler und Spieltag, also mehrere Zeilen pro Spieler?:

Jetzt war aber mein Gedanke die Relation umzugestalten:

SpielerID___Name___Start-Elo-Rating___Aktuelles-Elo-Rating
0_________Ole_____1500____________1498
1_________Gustav__1500____________1504

Ich würde es wie @mrBrown machen. Das hat auch den Vorteil, dass man nachträgliche Umbewertungen vornehmen kann, ohne dass man sämtliche Folgewerte updaten muß (höchstens die Snapshots). So ähnlich macht man es in Buchhaltungssytemen ja auch. Andererseits müsste die Umbewertung eines Spielers ja auch zur Umbewertung seiner Gegenspieler und mittelbar zur Umbewertung von deren Gegenspielern führen, so daß man im Endeffekt doch alles neu durchrechnen müßte. Das wäre dann doch ein Unterschied zu einem Buchhaltungssystem.

 

[Thallius]

Ich würde deinen ersten Ansatz nutzen, und den Startwert pro Spiele und die Veränderung pro Tag speichern.
Zusammen ergibt das jeweils das aktuelle Ranking, und du verlierst die Entwicklung des ganzen nicht.

Sollte die Performance zu schlecht werden, würde ich zusätzlich (auch wenn es zu Lasten der Redundanz geht) eine zusätzliche Tabelle für "Snapshots" des aktuellen Rankings anlegen, welche dann zb täglich oder bei Änderungen aktualisiert wird - so ein bisschen Event-Sourcing-mäßig

Sorry aber jetzt mal ehrlich. Wozu soll man die Punktesummen speichern? Performance? Selbst wenn ein Spieler 100 spiele pro tag macht, was was ich eher nicht glaube, dann hätte er 36500 Werte pro Jahr pro Spieler. Also in 10 Jahren (Eine Zeitspanne die bisher noch kaum Spiel überlebt hat) dann 365000. Diese zu summieren sollte selbst für eine mySQL Datenbank auf einem altersgeplagten Windows XP Rechner nicht mehr als 100ms dauern.

Wozu also bitte irgendwas speichern, dass nur dazu führt das man komplett unflexibel wird was die Auswertung angeht?

 

[mrBrown]

Sorry aber jetzt mal ehrlich. Wozu soll man die Punktesummen speichern? Performance? Selbst wenn ein Spieler 100 spiele pro tag macht, was was ich eher nicht glaube, dann hätte er 36500 Werte pro Jahr pro Spieler. Also in 10 Jahren (Eine Zeitspanne die bisher noch kaum Spiel überlebt hat) dann 365000. Diese zu summieren sollte selbst für eine mySQL Datenbank auf einem altersgeplagten Windows XP Rechner nicht mehr als 100ms dauern.

Den Punkt mit "Sollte die Performance zu schlecht werden", womit der Absatz beginnt, hast du aber schon gelesen?

Wozu also bitte irgendwas speichern, dass nur dazu führt das man komplett unflexibel wird was die Auswertung angeht?

Warum wird man unflexibel, wenn man jede einzelne Veränderung einzeln ablegt, und damit so ziemlich alles machen kann, was möglich ist?

 

[Meniskusschaden]

(Eine Zeitspanne die bisher noch kaum Spiel überlebt hat)

Schach aber schon. Und da es hier um ELO-Auswertungen geht, ist das Spiel mit hoher Wahrscheinlichkeit Schach. Falls es um einen Schachserver geht, auf dem auch Blitz- und Bullet-Partien gespielt werden, sind 100 Partien am Tag für einen Spieler bestimmt auch nicht so ungewöhnlich.

 

[DefconDev]

Sorry, das meine Antwort so verspätet kommt. Habe es, wie empfohlen von euch, mit einer View erledigt.