Skript Datenbanken I - Praktische Informatik Universität Kassel

32
Beispiel 3–3
KDNR KNAME STADT
4711 Meier Frankfurt
4712 Müller Frankfurt
4701 Schmidt Hamburg
4715 Schmidt Hamburg
Tab. 3–1
• {KDNR} ist Schlüsselkandidat.
Datenbanken I
• KDNR ist Primärschlüssel (Kundennummer nicht zweimal vergeben
und kein Kunde ohne Kundennummer!).
• KNAME und auch {KNAME, STADT} sind keine Schlüssel, da
zwei Kunden gleichen Namens in der selben Stadt existieren können.
• {KDNR, KNAME} identifiziert zwar auch eindeutig jedes Tupel,
wegen des überflüssigen Attributs KNAME ist die Kombination
jedoch kein Schlüssel.
Der schnelle Zugriff auf Tupel über die Angabe des Primärschlüsselwerts,
hier KDNR, sollte vom System immer unterstützt werden. Der Zugriff auf
die Tabelle über die Kombination Kundenname und Stadt sollte allerdings
auch unterstützt werden, da häufig Kunden ihre Kundenummer nicht
parat haben. Man spricht dann von Sekundärschlüsseln (engl. alternate
keys).
Hinweis: Häufig wird dieser Begriff auch für Attribute benutzt, für die
ein Index existiert, auch wenn die Schlüsseleigenschaft selbst nicht gegeben
ist, z. B. „Sekundärschlüssel“ KNAME.
Übung 3–10
Entwerfen Sie für die Entity-Typen LEHRER, SCHÜLER, KLASSEN
geeignete Relationenschemata und bestimmen Sie die Schlüssel. Die Auf-