spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das wäre aber nicht zwingend korrekt.
Natürlich hat ein Schüler mehrere Lehrer. Selbst wenn dem nicht so ist und es um Klassenlehrer geht: ich würde das nicht beschränken, indem ich in die Schüler-Tabelle einfach ne Lehrer-id speichere.
Bei sowas würde ich beide sogar eher in Gruppen stecken und untereinander garkeine direkte Zuordnung geben (sondern beide belongsTo group/class). Aber das kommt eh aufs Bedürfnis an.

Gängig ist eine Tabelle, welche nur die Zuordnungen beinhaltet:

lehrer
id
...

schueler
id
...

lehrer_schueler
(id)
lehrer_id
schueler_id

Schüler eines Lehrers abfragen z.B.:
SELECT schueler.* FROM lehrer_schueler, schueler WHERE lehrer_schueler.lehrer_id = #some_id# AND lehrer_schueler.schueler_id = schueler.id
Entsprechend umgekehrt möglich.

Richtig, die Relation "y unterrichted x" bzw. "x wird von y unterrichted" sollte in einer eigenen Tabelle dargestellt werden. Im konkreten Fall würde man für diese Tabelle unter Umständen dann einen Composite Primary Key aus Schüler und Lehrer ID in Erwägung ziehen...

Also wen du den Fall hast das ein Lehrer mehrer Schüler und mehrere Schüler meherer Leher hat, dann würde man von einer m zu m Beziehung sprechen.(viele zu viele)
diesen Fall löst man in der Regel über eine Zwischentabelle.

Falls du aber nur den Fall hast das ein Leherer mehere Schüller hat dann würde man von einer 1 zu m Beziehnung sprechen.
Du würdest in diesem Fall ein Verweis in der Schülertabelle zum ensprechenden Leherer eintragen(Foreign key)

Hoffe ich konnte helfen
Grüsse blubb

Um noch ein paar Fachbegriffe reinzubringen:

Wenn das hier zutrifft:

Ein Lehrer - > mehrere Schüler
Ein Schüler -> mehrere Lehrer

Dann hast du eine "m zu n" - Beziehung, die in eine eigene Tabelle muß (m Lehrer zu n Schülern).

Wenn du nur sowas hier hast:
Ein Lehrer -> mehrere Schüler
ist es eine "1 zu m" - Beziehung. Die kann aufgelöst werden indem du in der Schüler-Tabelle einen Fremdschlüssel auf die Lehrer-Tabelle einbaust.

Es wurde ja bereits darauf hingewiesen, dass es sich wahrscheinlich um eine m-zu-n Beziehung handelt (und auch, dass man bei einer entsprechenden Zwischentabelle die Fremdschlüssel als zusammengesetzten Primärschlüssel verwenden könnte).

Allerdings solltest du dir erstmal Gedanken machen, ob dein Modell so auch vollständig ist.
Unterrichtet ein Lehrer einzelne Schüler, oder unterrichtet er mehrere, in eine Klasse/einen Kurs/... zusammengelegte Schüler? Da das Beispiel "Lehrer" und "Schüler" umfasst, würde ich Klassen als sehr wahrscheinlich ansehen. Diese würden dann wiederum aus mehreren Schülern bestehen und von Lehrern unterrichtet werden, während Lehrer mehrere Klassen unterrichten.
Was wird unterrichtet? Abhängig davon, was für deine Anwendung relevant ist, könnte das noch eine relevante Information sein. Da es sich weder um eine reine Information über den Lehrer (Lehrer können meist mehrere Fächer unterrichten), noch über die Klasse (Klassen können Unterricht in mehreren Fächern erhalten) handelt, ist es eine Eigenschaft der Beziehung und müsste in der Zwischentabelle vermerkt werden.
Beim letzten Punkt bin ich davon ausgegangen, dass die Schüler in "Klassen" zusammengefasst werden, welche in mehreren Fächern unterrichtet werden. Es könnte aber auch sein, dass stattdessen "Kurse" erstellt werden, welche bereits den Unterricht in genau einem bestimmten Fach (ggf. bei einem bestimmten Lehrer) implizieren, wo die Information über den Inhalt des Unterrichts wieder eine Eigenschaft des Kurses wäre.

Mal angenommen, jeder Schüler hätte tatsächlich nur einen Lehrer. Es wurde bereits geschrieben, dass eine solche 1-zu-n Beziehung realisiert werden kann, indem die n-Element-Tabelle (Schüler) um einen Fremdschlüssel erweitert wird. Allerdings gehören zu dieser Beziehung eventuell noch weitere Eigenschaften, wie das Fach, der Termin inklusive Raum etc. Diese Eigenschaften könnten natürlich dem Schüler zugewiesen werden, da über ihn die Beziehung realisiert wird.
Das Problem dabei ist jedoch, dass entweder bestimmte Eigenschaften der Beziehung erforderlich sind _und_ die Beziehung vorhanden sein müssen, oder dass die Beziehung optional ist, ohne dass Eigenschaften der Beziehung erforderlich sein können. Mit etwas komplizierteren Constraints kann man ein solches Verhalten hinbekommen, einfacher wäre es aber immernoch eine Zwischentabelle anzulegen, bei der der Fremdschlüssel zum Schüler einmalig oder gar der Primärschlüssel der Tabelle ist. So kann die Beziehung optional sein _und_ Pflichtfelder beinhalten.
Ein weiterer Vorteil einer solchen Umsetzung ist, dass es einfacher ist, die Beziehung in eine m-zu-n Beziehung abzuwandeln. Die Einmaligkeit des Schüler Fremdschlüssels müsste nur in eine Einmaligkeit der Kombination Schüler<->Lehrer umgewandelt werden.
Ein anderes Beispiel wären Adressen in einem Online-shop. Man geht vielleicht davon aus, dass ein Benutzer eine eigene Adresse hat, die er ggf. ändern kann, dennoch wäre es von Vorteil, wenn der Benutzer diese bspw. nicht von Anfang an eingeben muss, man aber dennoch die Prüfungen hätte -> separate Tabelle für Adressen, die eine Referenz auf den Benutzer besitzen. Stellt sich später heraus, dass die Benutzer häufiger unterschiedliche Adressen verwenden (bspw. wenn die Rechnungsadresse sich häufiger von der Lieferadresse unterscheidet) und dass es komfortabel wäre, wenn sie diese ebenfalls alle speichern könnten, dann wäre es einfacher, einfach mehrere Einträge in bereits besagter Tabelle zuzulassen (Einmaligkeit des Benutzer-Fremdschlüssels entfernen). Amazon beispielsweise erlaubt es einem, mehrere Adressen zu verwalten.

Ein zusamengesetzter Primärschlüssel (Composite Primary Key) besteht im Gegensatz zu einem normalen Primärschlüssel nicht aus einem einzigen Wert, sondern aus mehreren. Um bspw. einen ganz bestimmten Datensatz abzurufen, muss man auch da den gesamten Primärschlüssel angeben, welcher eben aus mehreren Werten besteht.

Dir ist aber klar, dass du mit der Query eimal die ganze Datenbank umrührst oder?

Ich glaube ich hätte das etwas anders gemacht. Ein Lehrer (ggf. sogar viele - kann ja mal vorkommen, dass 2 Lehrer gleichzeitig unterrichten) und viele Schüler sind Teil einer Unterrichtseinheit. Diese Unterrichtseinheit findet in einem Raum statt. Über den Tag verteilt finden in dem Raum mehrere Unterrichtseinheiten statt. Damit sich nichts überschneidet könnte ein Trigger oder eine Prüfung durch dein Programm erfolgen.
Das Schüler immer vom selben Lehrer unterrichtet werden kommt glaube ich nicht ganz hin und wenn ja, dann wird er bestimmt nicht den ganzen Tag das gleiche mit den Schülern machen.

Schöne Grüße

Fb

Edit: Tipp von mir, zeichne eine Klassendiagramm und deren Beziehung, danach wandelst du das in ein Relationsmodell um oder noch besser du benutzt ein ORM Mapper, der diese lästige Arbeit für dich übernimmt.