Databases Reference
In-Depth Information
Dabei hat „
NOT NULL
“ nicht direkt etwas mit
UNIQUE
zu tun,
es wurde im Beispiel nur ergänzt um zu zeigen, wie mehrere
Constraints hintereinander stehen können. Die alternative
Schreibweise „
UNIQUE NOT NULL
“ wäre auch korrekt.
Die gleiche Bedingung kann man auch als Tabellenconstraint
angeben. Die gleichwertige Formulierung lautet:
CONSTRAINT EindeutigerName UNIQUE(Name)
X Y
27 42
27 NULL
NULL 42
NULL NULL
UNIQUE(X,Y)
ergibt „wahr“
UNIQUE(X)
ergibt „falsch“
UNIQUE(Y)
ergibt „falsch“
Abb. 6-6:
Auswertung von UNIQUE
Bei
UNIQUE
können auch mehrere Spaltennamen angegeben
werden. Die Forderung lautet dann, dass die entstehenden
Wertekombinationen eindeutig sein sollen. Ein Beispiel ist in
Abb. 6-6 angegeben.
Betrachtet man, was man alles mit den vorgestellten
Constraints beschreiben kann, so sieht man, dass sie wesentlich
zur Umsetzung der referenziellen Integrität beitragen und eine
gewisse Qualität für die Daten garantieren können.
Die vorgestellten Constraints beziehen sich immer genau auf
eine Zeile der Tabelle, was die Ausdrucksmächtigkeit stark ein-
schränkt. Möchte man die Erlaubnis, Daten in eine Tabelle ein-
zutragen, davon abhängig machen, dass die Daten zusammen
in der Tabelle eine weitere Eigenschaft haben, z. B. dass der
Durchschnitt nicht unter einen bestimmten Wert sinken soll, ist
dies mit den vorgestellten Constraints nicht möglich. Noch wei-
tergehende Forderungen, in denen andere Tabellen und ihre
Inhalte in die Überprüfung mit einbezogen werden, können
ebenfalls mit den vorgestellten Constraints nicht umgesetzt
werden.
Verschiedene Datenbank-Managementsysteme bieten weitere
Möglichkeiten, Überprüfungen zu definieren. Hierzu gehören
Zusicherungen, so genannte
Assertions
, in denen Regeln defi-
niert werden können, die mehrere Tabellen zusammen erfüllen
sollen und die bei Änderungen vergleichbar wie Constraints
überprüft werden können.
Mächtigkeit von
Constraints
Assertion
139
