Erste Seite Zurück Weiter Letzte Seite Übersicht Grafik

Referenzielle Integrität


Notizen:

Referenzielle Integrität: Regelsystem in der Datenbank, welches die Gültigkeit von Beziehungen garantiert und Datensatzanomalien verhindert. Sie gewährleistet, dass...
...in ein Fremdschlüsselfeld einer Detailtabelle kein Wert eingegeben werden kann, der nicht im zugehörigen Schlüsselkandidaten der Mastertabelle vorkommt (weder durch Einfügen noch durch Ändern eines Datensatzes).
...aus einer Mastertabelle kein Wert des entsprechenden Schlüsselkandidaten „verschwinden“ kann (weder durch Löschen noch durch Ändern), wenn übereinstimmende Tupel in einer Detailtabelle vorhanden sind .
Der 2. Punkt kann durch so genannte „Kaskaden“ (Weitergaben) umgangen werden:
Löschweitergabe: Wird ein Tupel aus einer Mastertabelle gelöscht, werden alle übereinstimmende Tupel der Detailtabelle gelöscht.
Aktualisierungsweitergabe: Wird der Primärschlüsselwert einer Mastertabelle geändert, werden alle übereinstimmende Werte der Detailtabellen mit dem geänderten Wert aktualisiert.
Referenzielle Integrität liegt vor, wenn keine Fremdschlüssel in irgendwelchen Detailtabellen die Referenzforderung verletzen. Würden immer alle Operationen in der Datenbank korrekt ausgeführt werden, bliebe die RI auch erhalten. Da man davon aber nicht ausgehen kann, können die meisten DBS die RI zwangsweise durchsetzen. Das kann z.B. algorithmisch (durch Programmieren sog. Trigger, s.u.) erfolgen. Lässt das DBMS die Definition der Referenziellen Integrität auf Designebene zu, so spricht man von
Deklarative Referenzielle Integrität
Deklarative Referenzielle Integrität liegt vor, wenn ein DBMS auf Designebene das Deklarieren von Beziehungen zulässt.
In einem graphischen Designwerkzeug meistens durch Drag & Drop implementiert.
In SQL durch die sog. FOREIGN KEY-Constraint (gleichnamige Klausel in den CREATE TABLE- bzw. ALTER TABLE-Statements).
Ist eine Beziehung zwischen zwei Tabellen deklariert, verhindert das DBMS Falscheingaben (aus welchem Grund auch immer: UPDATE oder DELETE in der Kopftabelle, INSERT oder UPDATE in der Detailtabelle)
Wenn ein DBMS nicht über DRI verfügt, bleibt nur die Möglichkeit, Beziehungen selbst durchzusetzen. Am besten, weil vom Designansatz her am „tiefsten“ in die DB-Struktur gewoben: Triggerprogrammierung
Trigger sind im Grunde nichts anderes als Ereignisroutinen, die aufgerufen werden, wenn ein Insert-, ein Update- oder ein Delete-Ereignis bei einer Tabelle eintritt. Im Trigger muss der Programmierer „händisch“ überprüfen, ob in einer anderen Tabelle betroffene Datensätze vorhanden wären (z.B. durch auswerten eines select count(*)-statements) und geeignete Maßnahmen ausprogrammieren (Cascade, Restrict oder Set Null)
Trigger ermöglichen auch „intelligente“ Kaskaden, z.B. in die andere Richtung: Wenn Detaildatensätze gelöscht werden, passiert so lange nichts, bis der letzte Detaildatensatz gelöscht wird. Beim Löschen des letzten Detaildatensatzes wird auch der Kopfdatensatz gelöscht.