# MySQL, Problem mit 1:n Beziehung.



## bgauch (29. April 2010)

Hallo zusammen

Ich habe ein Problem in meiner MySQL Datenbank, und komme einfach auf keinen grünen Zweig.
Deshalb bitte ich euch um Hilfe.

Ich versuche es einigermassen verständlich aufzuzeigen.

Ausgangslage:
-	In der Datenbank geht es um Renneinsätze. Wer fährt wo, in welchem, Team, Auto, Strecke, etc.
-	Nun gibt es leider Rennen die gehören zu mehreren Meisterschaften. Aktuelles Beispiel: Es gibt einige Rennen die zählen zum skandinavischen Tourenwagen Cup, sind aber gleichzeitig  auch Bestandteil von der schwedischen und der dänischen Meisterschaft.
-	Ich erfasse also drei Meisterschaften, aber die Rennen natürlich nur einmal. Weise ein betroffenes Rennen einfach allen drei Meisterschaften zu.

Soweit so gut. Nur gibt es nachher einen Schönheitsfehler in der Abfrage nach Fahrern und Teams. Diese nehmen nebst dem skandinavischen Cup natürlich nur jeweils an einer Meisterschaft (Schweden oder Dänemark) teil. Da sie aber nur das Rennen zugewiesen kriegen, zeigt es dann alle drei Meisterschaften an. Dito bei Anfragen nach Teams.

Ich habe dir Tabellen so gut es geht normalisiert. Für das Problem relevant sind:
-	Tabelle Saison: ID, Bezeichnung, etc.
-	Tabelle Rennen: ID, Datum, Bezeichnung, Zugehörigkeit zu Saison (Saison 1, Saison 2, Saison 3), etc.
-	Tabelle Land: ID, Bezeichnung
-	Tabelle Fahrer: ID, Name, etc.
-	Tabelle Team: ID, Name, etc.
-	Tabelle Auto: ID, Bezeichnung
-	Lead Tabelle History: ID, Startnummer, ID vom Rennen, ID vom Team, ID vom Auto, ID vom Fahrer, etc.

In der Lead Tabelle noch einmal Saison 1 bis 3 einfügen wäre ein Witz.
Aber wie schaffe ich es ein Resultat hinzukriegen, wo:
-	Das Rennen wie bis jetzt nur einmal erfasst ist, und der einen oder mehreren Saison zugewiesen ist.
-	Pro Renneinsatz (Fahrer fährt ein Rennen) wie bisher nur ein Datensatz erfasst wird.
-	Es aber möglich ist zu definieren, an welchen Meisterschaften der Fahrer teilgenommen hat, wenn ein Rennen zu mehreren Meisterschaften gehört.

Wenn jemand eine Idee hat, und sich ernsthaft dem Problem annehmen möchte, kann ich auch gerne Layout und Scripts mailen.

Sage schon mal vielen Dank!

Gruss
bgauch


----------



## FrankBooth (29. April 2010)

Hallo,

ich habe dein Problem jetzt gerade kurz überflogen. Ich glaube die Lösung deines Problemes sind Kreuztabellen (m : n).
Hab leider gerade keine Zeit und könnte erst am Wochenende (Sonntag) mehr dazu schreiben.
Ich schau Sonntag wieder rein. Bis dahin X-Tabellen anschauen und auf die Anderen hoffen 

Grüße


----------



## FrankBooth (3. Mai 2010)

Hallo,

komm erst heute dazu. wie sieht es aus?
Bist du schon weiter?

Grüße


----------



## bgauch (3. Mai 2010)

Hi

Nein, komme leider zurzeit auch nicht dazu.
Aber da ich schon lange dran "rum-doktere" werde ich wohl eh auf keine Lösung kommen.

Bin also für externe Hilfe sehr dankbar.


----------



## Xervos (3. Mai 2010)

Hallo, 

ich glaube ich weiß was du für ein Problem hast. 

Also wenn du willst kann ich dir helfen die Strukturen aufzubauen. 

lg 
Chris


----------



## bgauch (3. Mai 2010)

Hi

Ok, dann her mit euren Ideen.


----------



## Xervos (3. Mai 2010)

Hallo, 

also ich würde die zugehörigkeit der Rennen nicht in der Tabelle Rennen definieren. 

Mach hierzu eine eigene Tabelle mit dem Namen sagen wir mal "TABSaisonRennenZuord". Hier weißt du die Rennen den Saisonen zu. Mit Primarykey über die SaisonID und der RennenID. Die Tabelle der Rennen sollte wirklich nur die Definition der Rennen sein. Ich weiß ja nicht wie deine Tabellen jetzt aussehen. Aber ich mache es immer so. 

Poste mal deine Tabellen Rennen und Saison

LG


----------



## bgauch (3. Mai 2010)

Hi

Eine Tabelle mehr wäre eine Möglichkeit. Ist dann halt noch eine Tabelle mehr die gejoint wird.

Saison:
ID   smallint  (PK)
name  varchar
short  varchar
full  varchar
year  varchar
complete  varchar
single  char

Rennen:
ID  smallint  (PK)
name    varchar
land  smallint
season  smallint
season2  smallint
season3  smallint
date  date


----------



## FrankBooth (3. Mai 2010)

Xervos hat gesagt.:


> Mach hierzu eine eigene Tabelle mit dem Namen sagen wir mal "TABSaisonRennenZuord". Hier weißt du die Rennen den Saisonen zu. Mit Primarykey über die SaisonID und der RennenID. Die Tabelle der Rennen sollte wirklich nur die Definition der Rennen sein. Ich weiß ja nicht wie deine Tabellen jetzt aussehen. Aber ich mache es immer so.



... was ja nichts anderes als eine Kreuztabelle ist. DIe Antwort steht also schon da. Ich  find es ja auch immer gut, wenn man mal weis, was man da eigentlich macht 
Also mal Kreuztabellen in der Literatur ansehen.


----------



## Xervos (4. Mai 2010)

FrankBooth hat gesagt.:


> ... was ja nichts anderes als eine Kreuztabelle ist. DIe Antwort steht also schon da. Ich  find es ja auch immer gut, wenn man mal weis, was man da eigentlich macht
> Also mal Kreuztabellen in der Literatur ansehen.



Naja ich brauch mir das nicht ansehen ^^ ich bin ja schon seit jahren in dem Job. Fals du mich mit der Ausage gemeint hast


----------



## Xervos (4. Mai 2010)

bgauch hat gesagt.:


> Hi
> 
> Eine Tabelle mehr wäre eine Möglichkeit. Ist dann halt noch eine Tabelle mehr die gejoint wird.
> 
> ...



Ich würde das so machen: 

Nimm die season, season2, season3 aus der Tabelle Rennen. Also so 


```
TABRennenDef:
nRennID  smallint  (PK)
nLandID  smallint
szName    varchar
dtDate  date
```


```
TABSaisonDef:
nSaisonID   smallint  (PK)
szName  varchar
szShort  varchar
szFull  varchar
szYear  varchar
szComplete  varchar
single  char
```

Die Tabelle Saison kannst du so lassen. Weiß zwar nicht was das alles bedeuten soll aber ok  

Die Zuord Tabelle machst du dann in etwa so: 


```
TABSaisonRennenZuord
nSaisonID smallint  (PK)
nRennID  smallint  (PK)
usw.
```

Somit kannst du jedes Rennen jeder Saison genau einmal zuordnen wegen dem join das wird dann noch leicher glaub mir den jede Kombi gibt es genau einmal. 

lg


----------



## FrankBooth (4. Mai 2010)

Hallo,

was du weis oder nicht weis ist mir egal.
Wenn man in der Literatur sucht , um mal über den Tellerand zu schauen, dann weis der Autor und jeder Leser eben wonach er suchen muss.
Das ging aus deiner zweifellos richtigen Antwort nicht hervor. Mehr wollte ich nicht sagen.

Grüße

P.S: Glückwunsch zur Berufserfahrung!


----------



## Xervos (4. Mai 2010)

FrankBooth hat gesagt.:


> Hallo,
> 
> was du weis oder nicht weis ist mir egal.
> Wenn man in der Literatur sucht , um mal über den Tellerand zu schauen, dann weis der Autor und jeder Leser eben wonach er suchen muss.
> ...



Ich weiß nicht warum du mich jetzt so anmachst ? Ich habe doch nur versucht ihm zu Helfen


----------



## FrankBooth (4. Mai 2010)

Xervos hat gesagt.:


> Naja ich brauch mir das nicht ansehen ^^ ich bin ja schon seit jahren in dem Job. Fals du mich mit der Ausage gemeint hast



Ich mache niemanden an. Ich hab nur erklärt was ich aussagen wollte.
Ich habe klar stellen wollen, was ich gemeint habe. Du hast mehr oder weniger gefragt, ob ich dich damit meine.
Ich habe geantwortet wen ich meine und warum ich das gepostet habe.

Grüße


----------



## Xervos (4. Mai 2010)

Wie du siehst hat er auf deinen Vorschlag einer Kreuztabelle nicht geantwortet was mich vermuten ließ das er nicht weiß was das ist, also habe ich versucht ihm zu erklären wie er vorgehen kann mehr nicht.... naja viel spass noch.

@bgauch viel glück noch du schaffst das schon


----------



## FrankBooth (4. Mai 2010)

Na und das ist doch das Gute an diesem Forum. Man bekommt Hilfestellung zu konkreten Problemen und  Literaturhinweise.


----------



## gorefest (4. Mai 2010)

Was bitte ist eine Kreuztabelle?

Ohne mal klugscheissen zu wollen ... was er braucht ist eine n:m Relation und die hat genau zwei Spalten, nämlich die IDs beider Tabellenzeilen, die in Relation zueinander stehen.

Eine KREUZTABELLE ist eine Tabellenverknüpfung zwischen zwei Tabellen, deren Ergebnis eine dynamische Anzahl SPALTEN hat und somit relational in dieser Form nicht speicherbar ist, sondern vielmehr das aufbereitete Ergebnis eines JOINS zwischen den drei Tabellen (T1, n:m Relation, T2).

Grüße
gore


----------



## Xervos (4. Mai 2010)

gorefest hat gesagt.:


> Eine KREUZTABELLE ist eine Tabellenverknüpfung zwischen zwei Tabellen, deren Ergebnis eine dynamische Anzahl SPALTEN hat und somit relational in dieser Form nicht speicherbar ist, sondern vielmehr das aufbereitete Ergebnis eines JOINS zwischen den drei Tabellen (T1, n:m Relation, T2).
> 
> Grüße
> gore



Aha ok danke für den hinweiß  



> Was bitte ist eine Kreuztabelle?
> 
> Ohne mal klugscheissen zu wollen ... was er braucht ist eine n:m Relation und die hat genau zwei Spalten, nämlich die IDs beider Tabellenzeilen, die in Relation zueinander stehen.



Naja das hat er ja dann mit der TABSaisonRennenZuord oder ? vll kann er noch ein art szBesch mit einfügen wo er sich noch einen Hinweiß verspeichern kann. 
lg


----------



## FrankBooth (4. Mai 2010)

FrankBooth hat gesagt.:


> Hallo,
> ich habe dein Problem jetzt gerade kurz überflogen. Ich glaube die Lösung deines Problemes sind Kreuztabellen (m : n).



So dann nochmal zu Literatur:

http://www.fb6.info/winf/bernd_bluemel/scriptewi1/datenbank.pdf

... ist ein Script oder so. Habe es gerade gefunden. Glaub S.18/19 mit einem schönen Bild wie ich finde.

Hier ist dann wohl ein Problem mit der Bennennung aufgetaucht (durch mich). Eine solche Tabelle wird mit Verbindungs- oder Beziehungstabelle
bezeichnet. Wobei die Antwort von Xervos noch immer richtig bleibt, ohne mal klugscheissen zu wollen.


----------



## gorefest (4. Mai 2010)

jein, eine beziehungsrelation ist nicht dasselbe wie eine kreuztabelle.

aber gemeint hat xervos das richtige. du brauchst etwas, was dir die schlüssel aus A auf die schlüssel von B abbildet. wird diese beziehungsrelation mit attributen angereichert spricht man datenbänkisch von einer attributierenden beziehungsrelation, während der OO-mensch von assoziationsklasse spricht.

[EDIT]

wenn du das ganze in ein klassenmodell verpacken kannst, kannst du genau dieses modell in eine datenbank bringen.

der klassische ERM-Ansatz ist zwar generell richtig, beisst sich aber an einigen stellen mit objektorientierten programmen.

[/EDIT]


grüße
gore


----------



## bgauch (4. Mai 2010)

Merci für euren Input!

Ich werde es mal so versuchen.


----------



## Xervos (4. Mai 2010)

Ja wenn du dann noch weiter Hilfe brauchst einfach hier schreiben. 

Wie gesagt dem Rennen nicht gleich bei der Def der Saison zuweißen. Wie ich das verstanden habe brauchst du sowas auch bei den Teams und Fahrern oder ? Hier auch wieder, eine Tabelle für Teams, eine Für Fahrer. Dann weißt du den Fahrer dem Team zu den ein Fahrer kann nur zu einem Team gehören.

lg


----------



## bgauch (4. Mai 2010)

schön wär's....

Manchmal setzen mehrere Teams zusammen ein Auto ein....
Manchmal sitzt ein Fahrer in einem Rennen auf mehreren Auto's.....

seufz....


----------



## Xervos (4. Mai 2010)

Nur eine Frage 

von welchen Rennen reden wir den hier ?  

Ich kenn mich bei Autorennen nicht so aus


----------



## bgauch (4. Mai 2010)

Von kleinen Tourenwagen-Serien bis zur Formel 1.

Im Falle von "ein Fahrer auf mehreren Autos" von Langstrecken-Rennen. Zum Beispiel 24 Stunden Rennen.


----------



## Xervos (4. Mai 2010)

Achso ok also wirklich so ein Großes schema. 

Hmm ich weiß nicht wie weit du schon bist oder wieviel erfahrung du in diesem Thema hast, aber ich mach es halt immer so. Setzt dich hin nimm dir ein Blatt papier und zerbrich das ganze in Teilstücke. 

Sagen wir mal so. Es gibt Folgende sportarten: 

Formel 1,
Formel 3000,
Nescar 

usw. 

Wenn du das hast überlegst du dir was ein so eine Sportart braucht. Strecken zb., Teams, diese Haben Fahrer und Autos. 

Sportarten haben Preise, Punkte die man pro rennen bekommen kann usw. einfach mal alles durch denken und dann fängst du an. Suche dir gemeinsamkeiten die solche Sportarten haben.

Fange dann ganz unten an also bei der Tabelle wo man die Sportarten eintragen kann dann gehst du nach oben 

Ich hoffe ich konnte dir ein bisschen helfen. Ich stehe gerne zur verfügung wenn du hilfe brauchst 

lg


----------

