nicht angemeldet
Hallo Eddie,
es gibt ja logischerweise Tabellen, auf die nicht verwiesen wird (mittels Fremdschlüssel). Eigentlich bräuchte man da also nicht unbedingt einen Primärschlüssel - er wird ja nicht genutzt.
Du musst zwischen "Attribut" (auch "Spalte", "Feld") und "Schlüssel" unterscheiden. Ein Schlüssel ist nicht auf ein einziges Feld beschränkt. Ein Primärschlüssel dient lediglich dazu, einen Datensatz in einer Tabelle eindeutig (!) zu identifizieren. Der Schlüssel kann über mehrere Attribute oder auch nur ein Attribut angelegt werden; wenn er über mehrere Attribute geht, dann definieren die Attribute in ihrer Gesamtheit den Datensatz, sprich: wenn der Primärschlüssel über zwei Attribute geht, dann kennzeichnen die Wertepaare (1,2), (2,1), (1,1) und (2,2) vier verschiedene Datensätze.
Häufig werden in Tabellen Integer-Spalten (id) angelegt, die dann zum alleinigen Primärschlüssel gemacht werden. Allerdings ist dies auch nicht die einzige Möglichkeit und auch nicht immer die sinnvollste.
Beispiel: die Hilfstabelle, die ich für eine n:m-Relation nehme, enthält eigentlich nur 2 Fremdschlüssel - mehr erscheint mir nicht nötig.
Doch, bei m:n-Relationstabellen sind beide Einzelspalten jeweils Fremdschlüssel, beide Spalten _zusammen_ bilden den Primärschlüssel. Denn bei einer m:n-Verknüpfung ist ja ein einzelner Eintrag in der Tabelle eindeutig. Sprich: Das Wertepaar (4, 6) sollte bloß einmal in der Tabelle stehen, sonst bekommst Du bei JOINs doppelte Datensätze.
Du kannst in genau einem Fall auf Primärschlüssel bei Tabellen verzichten (und dann musst Du es sogar), nämlich genau dann, wenn doppelte Datensätze (d.h. Datensätze, bei denen *ALLE* Attribute der Tabelle den gleichen Wert haben) abgespeichert werden sollen *UND* Du die Datensätze *NICHT* eindeutig identifizieren können musst. Aber mir fällt gerade kein Beispiel ein, wo so etwas mal sinnvoll sein könnte - nicht, dass es sowas nicht geben mag, aber ich hab's noch nie gebraucht.
Viele Grüße,
Christian