ZaphoodB wrote:Ich erstelle eine Tabelle "Kunde" und eine Tabelle "Datum"... und eine Beziehungstabelle "Termin" mit KundenId und Datum..DatumID ?
Fast. Ich führe mal "Stepke-DSL"s Antwort weiter aus.
Die Tabelle "Kunde" ist klar. Aber die andere Tabelle heißt nicht "Datum", sondern "Termin". Weil das ein Termin ist, der an einem bestimmten Datum (das wird dann ein Attribut der Tabelle "Termin") stattfindet. Ein Attributt entspricht einer Spalte der Tabelle. Man könnte eine weitere Spalte in "Termin" definieren, die nennt sich beispielsweise "Beschreibung": da könnte man Text unterbringen, was das überhaupt für ein Termin ist.
Und jetzt kommt es drauf an, ob das eine 1:N-Beziehung ist (das heißt, ein Kunde kann an N Terminen teilnehmen - so sieht es bisher aus), oder ob es eine M:N-Beziehung ist (das würde bedeuten, dass nicht nur ein Kunde zu verschiedenen Terminen kommen kann, sondern dass an jedem Termin auch mehrere verschiedene Kunden kommen können - das kann ich von hier aus nicht beurteilen).
Machen wir erst Fall 1 (1:N Beziehung):
Jede Tabelle bekommt grundsätzlich immer das Feld "id", das ist der Primärschlüssel, der wird grundsätzlich immer als Integer mit AUTO_INCREMENT definiert. Weil das nur der Primärschlüssel der jeweiligen Tabelle ist, nichts sonst.
Dann bekommt die Tabelle "Termin" eine Spalte "Kunde_id" (ich würde grundsätzlich mit genormten Spaltennamen arbeiten). Da wird die "id" desjenigen Kunden gespeichert, der diesen Termin wahrnimmt. Die Tabelle Kunde bekommt kein entsprechende Spalte, da stehen nur Kunden-Attribute drin (id, Name, Vorname, Ort usw.). Damit sieht die Tabelle "Termin" mindestens so aus:
id, Kunde_id, Datum
Ob da noch eine Beschreibung dazu kommt, wie oben angedeutet, mußt Du selbst entscheiden. Oder meinetwegen ein Attribut "Wichtigkeit" oder was auch immer - das mußt Du festlegen, was Du über diesen Termin wissen willst. Im Feld Datum steht natürlich das Datum (wobei da auch die Uhrzeit drin stehen darf, wie letztendlich das Format für das Datum aussieht, mußt Du auch selbst festlegen). So, wie Du es am besten verarbeiten kannst. Der Form halber schreiben wir auch noch die Tabelle Kunde auf, die sieht ungefähr so aus:
id, Name, Vorname, Ort, Strasse, Telefon
Ich habe einfach irgendwas geschrieben - wichtig ist, dass Du erkennst, dass in der Kundentabelle kein sog. "Fremdschlüssel" enthalten ist, sondern nur in der Tabelle "Termin" (nämlich die id des Kunden "Kunde_id" - so etwas nennt sich "Fremdschlüssel" - Foreign Key auf Englisch, den Begriff wirst Du oft lesen).
So, nun der schwierigere Fall, nämlich die M:N-Beziehung, es dürfen dann zu einem Termin auch mehrere Kunden kommen, außerdem darf (wie bisher) ein Kunde zu mehreren Terminen kommen.
Nun könnte man natürlich wieder anfangen, bei den Terminen Spalten dazuzufügen, a la "kunde_id_1", "kunde_id_2" usw. - aber genau das geht eben nicht, weil man dann ständig die Tabelle ändern muss, je mehr Kunden an einem Termin kommen dürfen. Gleiches Problem wie Dein Eingangsproblem. Für die Lösung des Problem muss man eine eigenständige, neue Tabelle definieren, und die ist eine Zusammensetzung der beiden vorhandene Tabellen und kombiniert diese; deswegen nennen wir die Tabelle sinnvollerweise "Kunde_Termin". Diese Tabelle bekommt (wie jede Tabelle) eine "id" (der Primärschlüssel) und dann nur noch genau zwei weitere Felder, nämlich einmal einen Verweis auf einen Kunden, dafür brauchen wir wieder kunde_id, und einmal einen Verweis auf einen Termin, als eine termin_id. Im Gegenzug fliegt aus der Tabelle "Termin" die Spalte "kunde_id" heraus, denn die ist nun in der neuen Tabelle "Kunde_Termin" gelandet und wird nur noch dort benötigt.
Und jetzt ist eigentlich schon alles klar, wir schauen uns die neue Tabelle Kunde_Termin mal an:
id, kunde_id, termin_id
Jeder Datensatz aus dieser Tabelle entspricht genau einem Kunden an genau einem Termin. Mit jedem Datensatz, der in dieser Tabelle angelegt wird, wird also festgelegt, welcher Kunde an welchem Termin zu erscheinen hat. Und damit ist es natürlich einfach, mehrere Kunden zum gleichen Termin zuzuordnen: man legt einfach mehrere Datensätze mit derselben termin_id an, aber bei kunde_id stehen jeweils andere Primärschlüssel. Diese Kunden haben gemeinsam diesen Termin.
Und auch anders herum geht es einfach: wenn ein Kunde zu verschiedenen Terminen kommen soll (ist das gleiche in grün), legt man für jeden Termin dieses Kunden einen Datensatz in der Tabelle Kunden_Termin an, da steht immer die gleiche kunde_id drin, aber verschiedene termin_id.
D.h.: weder in der Tabelle Kunde, noch in der Tabelle Termin wird ein Fremdschlüssel gespeichert. Dort stehen wirklich nur die Attribute, die diesen Kunden bzw. die diesen Termin beschreiben. Und die Beziehung, die es zwischen den Kunden und den Terminen gibt, die ist vollständig ausgelagert in die "Hilfstabelle" Kunde_Termin.
Theoretisch könntest Du das auch jetzt schon so machen, aber wenn Du wirklich nur eine 1:N Beziehung hast, wäre der Aufwand nicht gerechtfertigt, denn es gäbe in dieser neuen Tabelle keine doppelten termin_id (weil an einem Termin ja nur ein Kunde kommt). Deswegen kannst Du dann den oben gezeigten Weg gehen und direkt beim Termin selbst reinschreiben, um welchen Kunden es sich handelt und sparst dir diese Hilfstabelle.
Du solltest Dir unbedingt auch solche Namenskonventionen aneignen, wie ich sie hier vorgeführt habe. Sprich: Primärschlüssel heißt immer id, ein Fremdschlüssel heißt immer tabellenname_id (wobei "tabellenname" durch den entsprechenden Namen der Tabelle zu ersetzen ist). Das macht das Programm lesbar und verständlich.