Datenbanken Online Lexikon TH Köln, Campus Gummersbach
Aktuelle Änderungen - Suchen:

CONSTRAINT

Mit Constraints (deutsch �Zwangsbedingungen�) werden in diversen Programmiersprachen bzw. Datenbanken Bedingungen definiert, die zwingend vom Wert einer Variablen erf�llt werden m�ssen, damit der Wert ins System �bernommen werden kann.

Das Keywort CONSTRAINTS geh�ren zum CREATE-TABLE-Befehl und erzwingen Integrit�tsbedingungen auf den Daten der Tabelle.

Man unterscheidet folgende CONSTRAINTs:

NULLlegt fest, dass eine Spalte NULL sein kann (optionale Eingabe, default).
NOT NULLlegt fest, dass eine Spalte nicht NULL sein kann (Pflichteingabe).
UNIQUEbestimmt eine oder mehrere Spalten als eindeutigen Schl�ssel. Die Werte dieser Schl�sselspalten sind immer eindeutig. Mehrere Unique Keys sind je Tabelle definierbar. F�r die Schl�sselspalten wird automatisch ein Index angelegt. Es wird so das relationale Konzept der Zweitschl�ssel implementiert.
PRIMARY KEYbestimmt eine oder mehrere Spalten als Prim�rschl�ssel.Die Werte dieser Schl�sselspalten sind immer eindeutig und d�rfen nicht NULL sein (implizite NOT NULL-Bedingung). Maximal ist ein Prim�rschl�ssel je Tabelle definierbar. F�r die Prim�rschl�sselspalten wird automatisch ein eindeutiger Index angelegt.
FOREIGN KEYbestimmt eine oder mehrere Spalten als Fremdschl�ssel, die Prim�rschl�ssel in einer anderen Tabelle sind und damit der referentiellen Integrit�t? gen�gen m�ssen. Foreign Keys realisieren 1:n Beziehungen aus dem ER-Modell. Es ist das einziges Constraint mit Fehlerkorrektur-M�glichkeit. F�r Fremdschl�ssel, die als Tabellenbedingung spezifiziert werden, muss die umfangreichere FOREIGN KEY-Syntax verwendet werden.
REFERENCES-Klauselidentifiziert die Master-Tabelle der Fremdschl�sselbeziehung. Werden keine Spalten angegen, so werden automatisch die Prim�rschl�sselspalten der Master-Tabelle referenziert. Die Klausel geh�rt zum FOREIGN-KEY-Constraint. Als Spaltenbedingung ist diese Syntax ausreichend f�r die Definition eines Fremdschl�ssels.
CHECKlegt eine Bedingung fest, die jeder Datensatz der Tabelle erf�llen muss. Bei ORACLE und DB/2 sind nur sehr eingeschr�nkte Suchbedingungen formulierbar, wie Vergleiche mit Konstanten bzw. zwischen zwei Spalten der zugeh�rigen Tabelle. Es sind hier nicht wie im Standard-SQL SELECT-Anfragen auf andere Tabellen m�glich. Es ist noch nicht einmal m�glich, in einem CHECK-CONSTRAINT die Systemvariable SYSDATE zu verwenden.

Constraints geh�ren zu der Tabelle, f�r die sie mittels CREATE TABLE- oder ALTER TABLE-Befehl definiert wurden. Sie sind keine eigenst�ndigen DB-Objekte. Wird die Tabelle gel�scht, werden auch automatisch alle zugeh�rigen Constraints gel�scht. Ein einzelnes Constraint wird mittels ALTER TABLE xyz DROP CONSTRAINT constraint_name gel�scht.

Bis auf das NOT NULL-Constraint, welches ja nur als Spaltenbedingung formulierbar ist, k�nnen alle �brigen Constraints in der CREATE- bzw. ALTER TABLE-Anweisung an zwei verschiedenen Stellen spezifiziert werden, woraus sich zwei recht unterschiedliche Syntax-Vorgaben ergeben:

F�r die Constraints PRIMARY KEY, UNIQUE, NOT NULL, CHECK stellt die Fehlermeldung und das Zur�ckrollen zum Anfang der Transaktion bei verz�gert gepr�ften Constraints bzw. bis vor die aktuelle, fehlerverursachende Datenmanipulation bei unmittelbar gepr�ften die einzig m�gliche Reaktion auf einen Integrit�tsfehler dar je nach Pr�fungszeitpunkt bzw. bis vor die aktuelle DML-Anweisung. Lediglich beim FOREIGN KEY-Constraint besteht die M�glichkeit, vordefinierte Fehlerkorrektur-Aktionen auszuw�hlen. Freiprogrammierbare Fehlerkorrekturen sind nicht vorgesehen. (vgl. Integrit�tspr�fung)

Bei Oracle m�ssen die CONSTRAINTS mit einem Namen bezeichnet werden, sonst vergibt das DBMS einen systemeigenen Namen.

siehe auch Transaktion,Datenkonsistenz?, Integrit�tsart, Fehlerkorrektur, Integrit�tspr�fung, TRIGGER, SET-CONSTRAINTS

Quellen:

  • ANSI/ISO/IEC 9075-1:2003. Part 1 "SQL/Framework", ISO International Organization for Standardization / ANSI American National Standards Institute, September 2003
  • ANSI/ISO/IEC 9075-2:2003. Part 2 "SQL/Foundation", ISO International Organization for Standardization / ANSI American National Standards Institute, Dezember 2003
  • Elmasri, Ramez/Navathe, Shamkant B.: "Grundlagen von Datenbanksystemen" , Pearson Studium, M�nchen, 2002, ISBN 3-8273-7021-3
  • Faeskorn-Woyke, Heide/Bertelsmeier, Birgit/Riemer, Petra/Bauer, Elena: "Datenbanksysteme - Theorie und Praxis mit SQL2003, Oracle und MySQL", Pearson Education, M�nchen, 2007, ISBN 978-3-8273-7266-6
  • Kemper, Alfons/Eickler, Andr�: "Datenbanksysteme", Oldenbourg, M�nchen, 2009, 978-3-486-59018-0
  • Melton, Jim/Simon, Alan R.: "SQL: 1999 - Understanding Relational Language Components", Morgan Kaufmann, San Francisco, 2001, ISBN 1558604561
  • Oracle� Database SQL Language Reference 11g Release 2 (11.2), E17118-03, August 2010, http://download.oracle.com/docs/cd/E11882_01/server.112/e17118.pdf
  • Saake, Gunter/Sattler, Kai-Uwe/Heuer, Andreas: "Datenbanken - Konzepte und Sprachen", mitp-Verlag, Redline GmbH, Heidelberg, 2007, ISBN 3-8266-1664-2
  • Vossen, Gottfried: "Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme", Oldenbourg, M�nchen, 2008, ISBN 978-3-486-27574-2

Kategorie: SQL, C