nicht angemeldet
Hallo Frederic,
Daran knacke ich nun schon den ganzen Tag und sehe inzwischen vor Bäumen den Wald nicht mehr.
Also ich würde sowas vorschlagen:
Spieler <-- 1:n --> Bewertung <-- n:1 --> Saison
A <-- 1:n --> B liest sich als "1 A hat n B" (n im Sinne von beliebig viele). Eine improvisierte Variante von < ER-Modellen http://de.wikipedia.org/wiki/Entity-Relationship-Modell>
Sowas ist ganz nett, um einen überblick zu bekommen. Es gibt da Zick Varianten mit viel Blabla dazu, aber im wesentlichen reduziert es sich auf eine grafische Notation der Beziehungen wie ich es hier gemacht habe
Ein Spieler hat also viele Saisons in denen er spielt und viele Bewertungen, die er bekommt.
Daraus ergeben sich nun direkt die Tabellen:
Spieler
---------------------
id primary key
... weitere daten
Saison
---------------------
id primary key
... weitere daten
Bewertung
---------------------
id primary key
spieler ref(Spieler.id)
saison ref(Saison.id)
... weitere daten
Das ist natürlich ein sehr einfaches Modell. Es gibt ja z.B. gar kein Spiel in diesem Modell. Es wäre also erstmal sinnvoll, möglichst alle wichtigen Objekte zu identifizieren. Womöglich sind die jetzt identifizierten Relationen eigentlich nur indirekt und eine Bewertung ist nur über ein Spiel mit einer Saison verknüpft.
Zwischen Saison und Spieler gibt es zwar auch eine Relation, die sollte sich aber aus der zwischen Bewertung und Saison und Spieler und Saison ergeben.
Hatte ich nur gemacht, weil ich ja auch den Verein und seinen Trainer einem Spieler für eine bestimmte Saison zuordnen will.
Hier wird es etwas komplizierter. Erstmal gibt es Trainer, womöglich können Trainer auch noch gleichzeitig irgendwo Spieler sein. Vielleicht sollte man Personen extra modellieren und Spieler und Trainer nur als darauf verweisende Rollen betrachten? Da tun sich einige Fragen auf, die Du Dir erstmal stellen solltest.
Zum eigentlichen Problem. Für Spieler gibt es Daten, die von der Saison abhängen. Die Eigenschaften kann man daher weder dem Spieler noch der Saison zuordnen. Also denken wir uns eben ein neues Objekt "Vereinszugehoerigkeit" oder sowas aus.
Eine Vereinszugehoerigkeit hat nun offensichtlich Beziehungen zu einem Spieler, einem Verein und einer, oder besser vielleicht mehrerer Saisons.
Der Trainer ist eine Eigenschaft des Vereins, nicht der Zugehörigkeit.
Du kannst Dir das ja mal als Bild aufmalen ich schreib mal direkt Tabellen hin:
Verein
-------------------
id primary key
trainer ref(Trainer.id), ref(Person.id), String, oder was immer der Anwendung angemessen ist.
...
Vereinszugehoerigkeit
-------------------
id primary key
spieler ref(Spieler.id)
VereinszugehoerigkeitZuSaison
-------------------
zugehoerigkeit ref(Vereinszugehoerigkeit.id)
saison ref(Saison.id)
Das letzte ist eine reine Zuordnungstabelle, die man braucht um n-zu-n-Relationen abzubilden.
Bei normalen Tabellen repräsentiert ja eine Zeile ein Objekt und die Relationen zwischen Objekten sind irgendwie mit darin verstaut. (Über Fremdschlüssel)
Im Falle dieser Zuordnungstabellen wird nur die Relation dargestellt.
Deine Postings wären übrigens angenehmer zu lesen, wenn Du nicht ganz so viele Absätze machen würdest ;-)
Grüße
Daniel