Database Reference
In-Depth Information
Beispiel
: In der Tabelle „Artikel (ArtNr, Artikelname, Preis)“
bildet das Attribut „ArtNr“ den ID-Schlüssel und es wird ange-
nommen, dass der Artikelname eindeutig ist, also nicht mehre-
re gleiche Attributwerte in der Tabelle vorkommen.
Aus
mathematischer Sicht
wäre dann der Preis sowohl funk-
tional abhängig von der Artikelnummer, als auch vom Artikel-
namen. Das bedeutet, dass sowohl anhand der Artikelnummer
als auch des Artikelnamens direkt auf den Preis geschlossen
werden kann. Zusätzlich wäre sowohl der Artikelname von der
Artikelnummer funktional abhängig, wie auch umgekehrt. Für
eine funktionale Abhängigkeit muss nur gelten: Aus x folgt y!
Aus
praktischer Sicht
wäre der Preis nur von der Artikel-
nummer funktional abhängig. Auch der Artikelname wäre nur
von der Artikelnummer funktional abhängig und nicht umge-
kehrt.
Der Praktiker geht von der Überlegung aus, dass letztendlich
aus jeder Entitätsmenge mindestens eine Tabelle entsteht. Da
jede Tabelle einen ID-Schlüssel braucht, legt man einfach das
entsprechende Attribut (oder Attributkombination) fest und
geht davon aus, dass alle anderen Attribute nur vom ID-
Schlüssel funktonal abhängig sind. Ob dies dann effektiv so ist,
wird erst später überprüft, wenn es um die volle bzw. transitive
Abhängigkeit geht. Einem geübten Datenbankdesigner käme es
jedenfalls im Traum nicht in den Sinn anzunehmen, dass der
Preis vom Artikelnamen abhängig sein könnte, wenn gleichzei-
tig eine wunderbare, eindeutige, ganzzahlige Artikelnummer
vorhanden ist, die sich als ID-Schlüssel geradezu aufdrängt.
Und gäbe es diese Artikelnummer nicht, so würde er sie erfin-
den, nur um nicht einen Artikelnamen mit variabler Länge und
inkompatibler Sortierung als ID-Schlüssel verwenden zu müs-
sen!
Voll
e
Abhängigkeit (mathematische Sicht):
Ein Attribut bzw. eine Attributkombination B ist
dann von einer Attribut
kombination
A
voll ab-
hängig
, wenn B nur von A, nicht jedoch schon
von einem Teil der Attributkombination A funktio-
nal abhängig ist.
