Zitat von
Reinhard Kern:
wörtlich genommen ist die Wikipedia-Aussage falsch. Es gibt normalerweise einen Primärschlüssel, der eindeutig ist, und weitere Schlüssel, nach denen die Tabelle gezielt durchsucht werden kann, die aber eben nicht eindeutig sind, wichtigstes Beispiel ist der Name: schliesslich kann ich ja keinen Müller als Kunden ablehnen, weil schon einer in der Tabelle steht. In der nach Namen sortierten Anzeige kommen die Müllers eben nacheinander. In den meisten Datenbanken kann man wählen, ob ein bestimmter Schlüssel eindeutig sein muss oder nicht.
Das klingt mir zusehr nach
Paradox. Nach Deiner Definition wären somit alle Spalten einer Tabelle gleichzeitig 'Schlüssel'. Primärschlüssel identifizieren ein Objekt oder einen Datensatz eindeutig. Daneben gibt es dann eine Reihe weiterer (zusammengesetzter) Schlüssel, die aber eines gemeinsam haben: Sie sind eindeutig! Insofern ist die Wiki-Definition korrekt. Selbst ein scheinbar mehrdeutiger Schlüssel ist intern eindeutig, weil die Datensatz-ID (Record-ID) mit abgespeichert wird. Schliesslich muss die
DB-Engine ja den zu dem Schlüssel gehörigen Datensätz finden können. Desweiteren bauen die verwendeten Datenstrukturen (B-Baum) auf einer totalen Ordnung auf. Und die bedingt nunmal Eindeutigkeit (und Ordnung).
Ich würde das so machen:
Tabelle "Abteilung" besteht aus
AbteilungID (PK) | Abteilung
Tabelle "Mitarbeiter" besteht aus
MitarbeiterID (PK)| Mitarbeiter
Tabelle "Abteilungsmitglieder" besteht aus
AbteilungID (FK) | MitarbeiterID (FK)
(PK)=Primary Key (FK)=Foreign Key.
Die Tabelle "AbteilungMitglieder" definiert die Relation (Mitarbeiter) "ist Mitglied von" (Abteilung). Damit hättest Du deine m:n Beziehung. Jeder Mitarbeiter kann in beliebig vielen Abteilungen sein und jede Abteilung kann beliebig viele Mitarbeiter beinhalten.
Die Tabelle "Abteilungsmitglieder" hat hier keinen PK. Könnte sie aber (sollte sie vielleicht auch, obwohl ich das nicht mache).
Durch die Bedingung, das die Kombination AbteilungID/MitarbeiterID eindeutig sein muss (ist also ein "Candidate Key", laut Wiki), ist die m:n Beziehung sauber definiert.
Eine 1:n Beziehung (Jeder Mitarbeiter ist in genau einer Abteilung) bekommst Du hin, indem Du in die Tabelle "Mitarbeiter" eine Spalte "AbteilungID" anfügst, und auf die Relation "ist Mitglied von" verzichtest.
Hoffe, mich nicht verhaspelt zu haben
