Databases Reference
In-Depth Information
Anweisung aus Listing 5.7 schlägt fehl; wir haben die Möglichkeit von Inkonsis-
tenzen weiter eingeschränkt. Ein einfacher Fremdschlüssel kann alternativ in stark
verkürzter Syntax zusammen mit seiner Spalte vereinbart werden:
create table spielkarten(
farbe varchar(20) references farben,
karte varchar(20),
primary key(farbe , karte)
)
Gelegentlich erkennen wir Fremdschlüssel erst, wenn die Tabelle bereits existiert.
Eine nachträgliche Definition ist mit
alter table
möglich:
create table spielkarten(
farbe varchar(20),
karte varchar(20),
primary key(farbe, karte)
);
alter table spielkarten
add constraint fk_farben foreign key(farbe) references farben
Die Integritätsregel, die eine Schlüssel-Fremdschlüssel-Regel ausdrückt, wird
auch als
referenzielle Integrität
bezeichnet. Wir sehen hier, wie die referenziel-
le Integrität einen Beitrag zur logischen Konsistenz der Tabellen leistet: Es kann
keine Verweise ins Nirwana geben. Zu jedem Wert der Spalte
farbe
in der Tabel-
le
spielkarten
muss es ein passendes Tupel in der Tabelle
farben
geben. Das
RDBMS akzeptiert nichts anderes.
Zwischen welchen Tabellen referenzielle Integritätsregeln bestehen, bestimmt ein-
zig und allein die Semantik: Wir selbst haben dem Attribut
farbe
seine Bedeu-
tung gegeben. Ebensogut hätte es aber auch eine der vier Grundfarben Rot, Gelb
und Blau repräsentieren können. Wir haben das Attribut
farbe
in den Kontext
der Farbwerte von Spielkarten gestellt.
Eine referenzierte Tabelle kann nicht gelöscht werden: Das RDBMS weigert sich,
die Anweisung
drop table farben
auszuführen. Zuvor muss entweder die Tabelle
spielkarten
oder die Integri-
tätsregel gelöscht werden:
alter table spielkarten drop constraint fk_farben
So weit ist das alles schlüssig. Im folgenden Abschnitt werden wir jedoch sehen,
dass wir bei der Definition der beiden Tabellen
spielkarten
und
farben
etwas
übersehen haben.
