1:n Beziehung

[Generic1]

Hallo nochmal,

bzgl. 1:n Beziehung hätte ich noch eine Frage,
Ich habe unten die Tabelle TParticipant erstellt mit dem SQL- Befehl und möchte jetzt noch eine Tabelle TClub zum DB- Schema geben. Zwischen den Tabellen TParticipant und TClub besteht eine 1:n Beziehung, d.h. mehrere Participants (n) können beim selben Club sein.
Meine Frage wäre jetzt, wie kann ich das unten mit den SQL- Befehlen abbilden, sodass ein Club von mehreren Participants referenziert werden kann?
Muss ich da in der Tabelle Participants eine neue Spalte einführen?
Besten Dank,
lg

CREATE TABLE TParticipant(id INT NOT NULL AUTO_INCREMENT,
                                    PRIMARY KEY(id),
                                    firstname VARCHAR(100),
                                    surname VARCHAR(150),
                                    chipnumber VARCHAR(8),
                                    UNIQUE (chipnumber)
                                    ) ENGINE = INNODB;

CREATE TABLE TClub(clubid INT NOT NULL,
                             clubname VARCHAR(100)
                             ) ENGINE = INNODB;

 

[Gast2]

Da Club auch eine entity ist würde ich da eine Mapping Tabelle empfehlen:
TClubMember(
club,
participiant,
PRIMATY KEY(club,participiant),
FOREIGN KEY(club) REFERENCES TClub(clubid),
FOREIGN KEY(participiant) REFERENCES TParticipant(id),
)

Das sieht mir eher wie ein m:n Beziehung aus

 

[Generic1]

Also an was ich mich noch errinnern kann bzgl Vorlesung ist, dass ich bei einer 1:n Beziehung keine Zwischentabelle brauch und ich will das DB- Schema jetzt auch nicht unbeding komplizierter machen, da ich das dann auch mit Hibernate im Programmcode abbilden will.

Also was ich jetzt glaube ist, ich werden eine Spalte in der Tabelle TParticipant einfühen müssen (z.B. mit dem Namen club).
Lieg ich da richtig dass mir das nicht erspart bleibt?

 

[Geeeee]

Mappingtabelle brauchst du nur, wenn man n:n abbildet.
Hier würde die einfacher erweiterung der TParticipant um eine Spalte mit FK ClubId völlig ausreichen.

Edit: Ich sehe gerade in deinem ersten Post, dass du evtl. auch die id als key und unique angeben solltest.

 

[Generic1]

Edit: Ich sehe gerade in deinem ersten Post, dass du evtl. auch die id als key und unique angeben solltest.

ich habe id als Primary key(id) definiert und dann müsste meiner Meinung nach id auch unique sein, da Primary keys unique sind?
oder was meinst du genau?

 

[Generic1]

Ok, ich muss also jetzt 4 Foreign- Key- Spalten zu meiner "Haupttabelle" hinzufügen. Ist das noch im Rahmen oder ist da mein Schema falsch, Unten hab ich mal mein Model hinzugefügt:

Participant -> Club, Born, Adress und Gender haben eine 1:n Beziehung, deshalb 4 Foreign- Spalten für die Tabelle Participant.

 

[Gast2]

Also kann es nie passieren das eine Person in mehreren Clubs ist? Scheint mir vom Domänenmodell her unlogisch... Zumindest was ich mir drunter vorgestellt habe

 

[Geeeee]

Naja er nennt es ja 1:n, da gehe ich mal einfach von aus

 

[Generic1]

Also es sprich nichts gegen 4 Foreign Keys in einer Tabelle,
auch bzgl Normalformen?
B.D.

 

[Geeeee]

Hatte dein Bild von oben nicht gesehen vorhin beim Post. Eigentlich spricht nix gegen die FKs. Das mit der Normalisierung kann ich dir nicht beantworten.

 

[Java.getSkill()]

Meinst du mit der Tabelle BORN das Geburtsdatum?

Und willst du jedem möglichen Datum eine eigene ID geben, und statt dem Geburtsdatum nur die zugehörige ID bei einem Participant eintragen?

bei einer 1:n Beziehung packst du einfach in der n-Entitätstabelle den primary key der 1-Tabelle als fk rein

Nur wie war das mit ref.Integrität, dass fk nicht null sein dürfen?
du hast 4 fk felder, aber was ist wenn einer Obdachlos ist?

 

[tuttle64]

Nur wie war das mit ref.Integrität, dass fk nicht null sein dürfen?
du hast 4 fk felder, aber was ist wenn einer Obdachlos ist?

Diese Integritätsregel muss nicht von belang sein, erst recht nicht, solange klar ist, wie null Werte zu behandeln sind.