Database Reference
In-Depth Information
ben, damit der Sinn eindeutig erkennbar ist. Die entsprechende
Tabelle müsste dann aufgebaut sein, wie in Bild 3.41 darge-
stellt.
Bild 3.41:
Rekursive
Tabelle
Musiker
MNr
DNr
Name
1
2
Schmid
2
3
Karajan
3
2
Bernstein
4
2
Müller
5
3
Meier
Kurzschreibweise
:
Musiker
(
MNr
, DNr, Name)
Diese Tabelle besitzt den ID-Schlüssel „MNr“ (Musiker-Nr.) und
den Fremdschlüssel „DNr“ (Dirigenten-Nr.), welcher aus dem
ID-Schlüssel „MNr“ gebildet wurde. Auf den ersten Blick
scheint dies zu funktionieren. Es lässt sich klar bestimmen,
dass Karajan ein Dirigent ist, welcher die Musiker Schmid,
Bernstein und Müller dirigiert, weil seine Musiker-Nr. im Attri-
but „DNr“ vorkommt.
Allerdings treten nun folgende Unstimmigkeiten auf:
Der Fremdschlüssel „DNr“ müsste „MNr“ heissen, weil „DNr“
ja aus dem ID-Schlüssel „MNr“ gebildet wurde. Dann hätten
aber zwei Attribute die gleiche Bezeichnung.
Wenn man wissen möchte, ob Karajan ein Dirigent ist, muss
man alle Attributwerte von „DNr“ nach dem ID-
Schlüsselwert von Karajan durchsuchen. Dies ist bei einer
großen Entitätsmenge unübersichtlich.
Das gewählte Beispiel soll verdeutlichen, dass eine rekursive
Beziehung nicht verwendet werden darf. Die Tabelle „Musiker“
wird deshalb in die Tabellen „Musiker“ und „Dirigenten“ trans-
formiert, wobei dann zwischen den beiden Tabellen eine
Mehrfachbeziehung entsteht, wie dies Bild 3.42 zeigt.
