Definition "Schlüssel" in einer Datenbank

[faux]

Hallo!

Ich beschäftige mich gerade etwas genauer mit Datenbanksystemen. Im Prinzip weiß ich was genau ein Schlüssel ist, jedoch muss ich für ein Referat eine genaue Definition finden. Im Wikipedia steht unter Schlüssel (Datenbank) folgender Satz:

Zitat:

Ein Schlüssel dient in einer Relationalen Datenbank dazu, die Tupel einer Relation eindeutig zu identifizieren. Anschaulich kann man sich eine Relation als Tabelle vorstellen. Der Schlüssel einer solchen Tabelle ist dann eine Gruppe von Spalten, die so ausgewählt wird, dass jede Zeile in dieser Gruppe eine einmalige Wertekombination hat.
...
Fremdschlüssel: Ein Attribut einer Relation, welches auf einen Primärschlüssel einer anderen Relation verweist.

Jetzt stellt sich allerdings für mich die Frage, wie man eine 1:n (oder n:m) Beziehung darstellen kann, wenn laut dieser Definition jeder Wert nur einmal vorkommen darf?

Beispiel:

Code:

+--------------+
| Abteilungen  |
+----+---------+
| ID | Name    |
+----+---------+
| 1  | EDV     |
| 2  | Telekom |
| 3  | Zubehör |
+----+---------+

+------------------+
| Mitarbeiter      |
+------+-----------+
| Name | Abteilung |
+------+-----------+
| Mayr | 2         |
| Böck | 3         |
| Faux | 2         |
+------+-----------+

Abteilung wäre laut der Definition ein Fremdschlüssel (auch ein Index, wodurch er laut Definition eines Indexes wieder zu einem Schlüssel werden muss). Hier muss ich aber 2 öfter als einmal vorkommen lassen, da ich sonst keine 1:n Beziehung erstellen kann, wodurch die Grunddefinition eines Schlüssels nicht mehr stimmt (...identifiziert eine Entität eindeutig...). :?
Habe ich da einen Denkfehler, oder ist die Definition wirklich nicht okay?

Grüße
Faux

[Pfoto]

Hallo,

letzendlich könnte die Tabelle Mitarbeiter wieder eigene Primärschlüssel haben...

Es ist zudem nicht ungültig, wenn die Fremdschlüssel in der Tabelle Mitarbeiter öfter vorkommen; weisen sie doch unmissverständlich auf den richtigen Eintrag der Tabelle Abteilungen

Gruß
Pfoto

[faux]

Zitat:

Zitat von Pfoto

letzendlich könnte die Tabelle Mitarbeiter wieder eigene Primärschlüssel haben...

Bei mir ist der Name der Primärschlüssel. :tongue:
Es ist ja nur ein Beispiel...

Zitat:

Zitat von Pfoto

Es ist zudem nicht ungültig, wenn die Fremdschlüssel in der Tabelle Mitarbeiter öfter vorkommen; weisen sie doch unmissverständlich auf den richtigen Eintrag der Tabelle Abteilungen

Achsoooo, das identisch bezieht sich deiner Meinung nach nicht auf den Frendschlüssel selbst, sondern sein "Ziel"?

Grüße
Faux

[Jürgen Thomas]

Tja, so ist das mit den Definitionen. Aus der Wiki-Erklärung geht indirekt hervor, dass Schlüssel als Kurzform für Primärschlüssel (Primary Key) verstanden wird. Der Fremdschlüssel (Foreign Key) stellt eine Beziehung (Relation) dar, die auf den Primärschlüssel der anderen Tabelle verweist.

Bei Deinem Beispiel gilt:
Abteilungen hat einen Primärschlüssel, nämlich ID.
Mitarbeiter hat keinen Primärschlüssel, aber einen Fremdschlüssel, bei dem das Feld "Abteilung" auf den Primärschlüssel der anderen Tabelle verweist.

Jeder Schlüssel kann sich auf ein oder mehrere Felder beziehen. Aus Geschwindigkeitsgründen und wegen der besseren Wartungsmöglichkeit sind Schlüssel für ein Feld meistens besser. Tabellen ohne Primärschlüssel sind "quasi verboten" (nicht unbedingt was die Theorie betrifft, sondern von der Praxis).

Ich hoffe, ich konnte zur Klarheit beitragen. Jürgen

Nachtrag:

Zitat:

Zitat von Faux

Achsoooo, das identisch bezieht sich deiner Meinung nach nicht auf den Frendschlüssel selbst, sondern sein "Ziel"?

So ist es.

Der Name ist als Primärschlüssel völlig ungeeignet, auch in der Kombination mit Vorname oder Geburtstag. Auch dafür ist eine ID das sinnvollste; das sollte man sich als Regel für (fast) jede Tabelle vornehmen. Ausnahmen wären allenfalls Tabellen, bei denen alle Felder gemeinsam als Primärschlüssel gelten würden und jedes Feld zu einem Fremdschlüssel gehört.

[faux]

Danke sehr für die Erklärung.

Zitat:

Zitat von Jürgen Thomas

Der Name ist als Primärschlüssel völlig ungeeignet, auch in der Kombination mit Vorname oder Geburtstag. Auch dafür ist eine ID das sinnvollste; das sollte man sich als Regel für (fast) jede Tabelle vornehmen. Ausnahmen wären allenfalls Tabellen, bei denen alle Felder gemeinsam als Primärschlüssel gelten würden und jedes Feld zu einem Fremdschlüssel gehört.

Das mit dem Namen-Primärschlüssel war auch nichts ernst gemeint. ;)

[Reinhard Kern]

Zitat:

Zitat von faux

Hallo!

Ich beschäftige mich gerade etwas genauer mit Datenbanksystemen. Im Prinzip weiß ich was genau ein Schlüssel ist, jedoch muss ich für ein Referat eine genaue Definition finden. Im Wikipedia steht unter Schlüssel (Datenbank) folgender Satz:

Zitat:

Ein Schlüssel dient in einer Relationalen Datenbank dazu, die Tupel einer Relation eindeutig zu identifizieren. Anschaulich kann man sich eine Relation als Tabelle vorstellen. Der Schlüssel einer solchen Tabelle ist dann eine Gruppe von Spalten, die so ausgewählt wird, dass jede Zeile in dieser Gruppe eine einmalige Wertekombination hat.
...
Fremdschlüssel: Ein Attribut einer Relation, welches auf einen Primärschlüssel einer anderen Relation verweist.

Jetzt stellt sich allerdings für mich die Frage, wie man eine 1:n (oder n:m) Beziehung darstellen kann, wenn laut dieser Definition jeder Wert nur einmal vorkommen darf?
...
Grüße
Faux

Hallo,

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.

Eine Auftragsdatenbank hat z.B. einen eindeutigen Primärschlüssel, das ist die Auftragsnummer, und Sekundärschlüssel wie z. B. Kunde oder Lieferdatum, die nicht eindeutig sind - ein Kunde kann ja mehrere Aufträge erteilt haben.

Gruss Reinhard

[alzaimar]

Zitat:

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 :freak:

[Hansa]

Zitat:

Zitat von alzaimar

...Hoffe, mich nicht verhaspelt zu haben :freak:

Ne, aber trotzdem fast. :mrgreen: Es geht darum, die DB-Felder bzw. die Daten an sich unabhängig zu machen von dem ganzen Drumrum. Deshalb gibt es die IDs, die allerdings nur intern verwendet werden sollten. Wenn man im eigenen Programm den Müller in Mueller umbenennen will, dann bleibt die ID immer noch, wie sie ist. Der lässt sich also immer noch eindeutig identifizieren. Abhängige Daten beziehen sich also dann immer noch auf die ID. Dieses Prinzip sollte man wissen.

[marabu]

Hallo,

ein paar Anmerkungen:

Zitat:

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

der Primärschlüssel ist ein Begriff aus dem Relational Model for Database Management, die "weiteren Schlüssel" von Reinhard sind eine begriffliche Ungenauigkeit aus einem anderen Themengebiet. Für Definitionen sollte man stets Primärliteratur zu Rate ziehen.

Zum Begriff Schlüssel findet man in Chris J. Date: An Intoduction to Database Systems Vol. I zu Beginn von Chapter 11 folgenden Absatz:

C.J. Date über Schlüssel (1986)

The term "key" is one of the most overworked in the entire database field. In the relational model alone we find primary, candidate, alternate, and foreign keys. In other areas of database technology we meet index keys, hash keys, search keys, secondary keys, ordering keys, parent keys, child keys, and many other kinds of key. It therefore seems advisable to avoid use of the unqualified term "key" and always to state explicitly in any discussion of the subject just what kind of key is meant. However, if any one of that multiplicity of keys does deserve to be called just the key, it is clearly the primary key. The primary key is easily the most important one of all.

Also beim Referat darauf achten: Definition und Abgrenzung - beides ist wichtig. Primäre Quelle für alle Begriffsdefinitionen im RDBMS-Bereich ist für mich Edgar F. Codd: The Relational Model for Database Management: Version 2.

Freundliche Grüße vom marabu

[Hansa]

Zitat:

Zitat von faux

Jetzt stellt sich allerdings für mich die Frage, wie man eine 1:n (oder n:m) Beziehung darstellen kann, wenn laut dieser Definition jeder Wert nur einmal vorkommen darf?

Beispiel:

Code:

+--------------+
| Abteilungen  |
+----+---------+
| ID | Name    |
+----+---------+
| 1  | EDV     |
| 2  | Telekom |
| 3  | Zubehör |
+----+---------+

+------------------+
| Mitarbeiter      |
+------+-----------+
| Name | Abteilung |
+------+-----------+
| Mayr | 2         |
| Böck | 3         |
| Faux | 2         |
+------+-----------+

Habe ich da einen Denkfehler, oder ist die Definition wirklich nicht okay?

Denkfehler : ja. Definition Okay ? Nein. :angel: Warum ? Tabelle Abteilungen ist ja ok. In Tabelle Mitarbeiter fehlt : ID und ID_Abteilung. Gäbe bei mir lediglich 4-6 von 15 Punkten. Vielleicht auch 8. :mrgreen: