Wir diskutieren im folgenden kurz unterschiedliche Typen von Integritätsbedingungen sowie ihre Unterstützung in SQL. Es folgt eine Diskussion von Triggern und ECA-Regeln, welche nach integritätsgefährdenden Änderungen eine aktive Reaktion ermöglichen, um die DB-Konsistenz aufrechtzuerhalten. Weiterhin wird auf Implementierungsaspekte der DBS-seitigen Integritätskontrolle eingegangen (Abschnitt 13.3.3).
- Reichweite der Bedingung
Wichtige Fälle mit jeweils unterschiedlicher Datengranularität sind Attributwert-Bedingungen (z. B. Geburtsjahr > 1900), Satzbedingungen (z. B. Geburtsdatum < Einstellungsdatum), Satztyp-Bedingungen (z. B. Eindeutigkeit von Attributwerten) sowie satztypübergreifende Bedingungen (z. B. referentielle Integrität zwischen verschiedenen Tabellen)
- Statische vs. dynamische Bedingungen
Statische Bedingungen (Zustandsbedingungen) beschränken zulässige Zustände der Datenbank (z. B. Gehalt < 500.000), während dynamische Integritätsbedingungen (Übergangsbedingungen) zulässige Zustandsübergänge festlegen (z. B. Gehalt darf nicht kleiner werden). Eine Variante dynamischer sind temporale Integritätsbedingungen, welche längerfristige Abläufe betreffen (z. B. Gehalt darf innerhalb von 3 Jahren nicht um mehr als 25 % steigen).
- Zeitpunkt der Überprüfbarkeit: unverzögerte vs. verzögerte Integritätsbedingungen (s. o.)
- Festlegung von Wertebereichen für Attribute durch Angabe eines Datentyps bzw. Domains. Dabei besteht die Möglichkeit, einen Default-Wert zu spezifizieren, Eindeutigkeit von Attributwerten zu verlangen (UNIQUE), Nullwerte auszuschließen (NOT NULL) sowie über eine CHECK-Klausel allgemeine Wertebereichsbeschränkungen festzulegen.
- Spezifikation allgemeiner, z. B. tabellenübergreifender Bedingungen durch die Anweisung CREATE ASSERTION.
- Für jede Integritätsbedingung kann eine direkte (IMMEDIATE) oder verzögerte (DEFERRED) Überwachung erreicht werden.
Zur Einhaltung der DB-Konsistenz (integrity enforcement) ist die Standard-Reaktion auf die erkannte Verletzung einer Integritätsbedingung der Abbruch der betreffenden Änderungstransaktion. In [ESWA75] wurde daneben für die Verletzung "schwacher Integritätsbedingungen" (soft assertions) eine anwendungsseitige Reaktionsmöglichkeit vorgesehen, z. B. für interaktive Interventionsmöglichkeiten des Benutzers, Ausgabe von Fehlermeldungen, Aufruf von Korrekturprogrammen usw. Diese Vorgehensweise erlaubt zwar eine hohe Flexibilität, verlagert jedoch die Verantwortung zur Integritätskontrolle wieder auf die Anwendungsseite und widerspricht somit dem Hauptanliegen DBS-basierter Integritätskontrolle. Da zudem die Verletzung definierter Integritätsbedingungen mit dem Transaktionskonzept nicht vereinbar ist, wäre eine anwendungsseitige Reaktionsmöglichkeit nur dann akzeptabel, wenn danach vor dem endgültigen Commit die Einhaltung der Integritätsbedingungen erneut überprüft würde und bei Verletzung ein Transaktionsabbruch erfolgt.
Eine Alternative besteht darin, eine DBS-kontrollierte Reaktion auf die Verletzung einer Integritätsbedingung vorzusehen, welche zusammen mit der Integritätsbedingung zu spezifizieren ist. Solche erweiterten Integritätsbedingungen werden als Integritätsregeln bezeichnet und enthalten die Festlegung einer Reaktionsmöglichkeit zur Wahrung der DB-Konsistenz. Die in SQL92 vorgesehenen Spezifikationsmöglichkeiten zur Wartung der referentiellen Integrität (CASADE, SET NULL, SET DEFAULT, NO ACTION) sind Beispiele solcher Integritätsregeln (die Default-Reaktion, in SQL3 als RESTRICT-Option explizit zu spezifizieren, bewirkt die Abweisung einer Operation/Transaktion, welche zu einer Verletzung der referentiellen Integrität führt, und entspricht somit der Standard-Reaktion für verletzte Integritätsbedingungen).
Solche Regelmengen gestatten eine deklarative Beschreibung von Situationen/Ereignissen und den zugehörigen Reaktionen, ohne dabei die Programmabläufe, in denen sie auftreten können, vorausplanen und spezifizieren zu müssen. Die Erkennung solcher Situationen/Ereignisse und die prozedurale Umsetzung der spezifizierten Reaktion wird dabei dem DBS überlassen. Weiterhin gestatten sie eine leichte Erweiterbarkeit, was Hinzufügen, Löschen und Austauschen von Regeln sehr einfach gestaltet. Allerdings können Abhängigkeiten zwischen Regeln auftreten, wenn sie auf gemeinsame Daten Bezug nehmen und dabei Änderungen vollzogen werden. Das wird immer dann zu einem Problem bei der Regelausführung, wenn mehrere Regeln gleichzeitig ausgelöst und diese parallel bearbeitet werden sollen [REIN96].
Trigger können auch zur Überwachung statischer Integritätsbedingungen sowie zur Wartung der referentiellen Integrität herangezogen werden. Für einige DBS, welche die SQL92-Konstrukte zur Festlegung von Integritätsbedingungen nur begrenzt unterstützen, ist dies teilweise auch die einzige Möglichkeit, die fehlende Funktionalität auszugleichen. In Abb. 13.5 b ist z. B. gezeigt, wie die Fremdschlüsselbedingung aus Abb. 13.4 über einen Trigger realisiert werden kann. Trigger gestatten darüber hinaus die Formulierung von allgemeinen Integritätsregeln, da als Folgeaktion beliebig komplexe Vorgänge zur Herstellung eines konsistenten DB-Zustandes möglich sind oder auch um vor dem Transaktionsabbruch noch Benachrichtigungen an den Benutzer zu liefern. Es handelt sich dabei um eine weitgehend prozedurale Spezifikation, bei welcher der Zeitpunkt der Trigger-Ausführung (i. allg. vor bzw. nach Ausführung einer Änderungsoperation), die Verwendung alter und neuer DB-Werte sowie die einzelnen Aktionen genau festzulegen sind.
Ein derartiger Einsatz von Triggern hat im Vergleich zur Nutzung der deklarativen SQL92-Konstrukte wesentliche Nachteile:
- In derzeitigen Implementierungen sowie im SQL3-Standard wird die Trigger-Ausführung unmittelbar vor oder nach (BEFORE/AFTER) der betreffenden Änderungsoperation ausgeführt. Eine Ausführung am Transaktionsende, wie für verzögerte Integritätsbedingungen erforderlich, ist nicht möglich. Damit kann eine äußerst wichtige Klasse von Integritätsbedingungen mit derzeitigen Trigger-Implementierungen nicht abgedeckt werden.
- Die von Triggern durchgeführten Änderungen können selbst wieder Trigger auslösen, wodurch die Auswirkungen auf die Datenbank oft nur schwer einschätzbar sind sowie sich die Gefahr zyklischer und möglicherweise nicht terminierender Aktivierungen ergibt. Weiterhin besteht das Problem der Konfluenz, inwieweit also der Effekt von Triggern unabhängig von der Abarbeitungsreihenfolge parallel aktivierter Trigger ist. Zur korrekten Erstellung von Transaktionsprogrammen muß der Anwendungsprogrammierer jedoch die Wirkung aller definierter Trigger genau kennen, z. B. um eine doppelte Durchführung bestimmter Änderungen zu vermeiden. Das Hinzufügen eines neuen Trigger kann so auch leicht zu unerwarteten Nebenwirkungen mit vorhandenen Transaktionsprogrammen führen.
In [SIMO95] wird bemängelt, daß keine Tools existieren, um die Auswirkungen von Triggern zu erkennen und die Entwicklung sicherer Anwendungen bei Einsatz von Triggern zu unterstützen. Eine solche Unterstützung ist sicher nur schwer erreichbar; ihre Notwendigkeit steigt jedoch mit den Größe der Anwendung und der Anzahl benötigter Trigger.
Eine Verallgemeinerung der Trigger-Funktionalität wird von aktiven Datenbanksystemen [JASP98, WIDO96a] verfolgt. Sie verwenden anstelle von Triggern sog. ECA-Regeln, welche durch drei Komponenten gekennzeichnet sind:
- Condition (C): optionale Bedingung (analog zur WHEN-Klausel von Triggern)
- Action (A): auszuführende Aktionen.
- wann die Überprüfungen durchgeführt werden sollen (direkt bei der Änderungsoperation oder verzögert am Transaktionsende)
- wie die Überprüfungen realisiert werden (Erstellung eines Ausführungsplans für die durchzuführenden Prüfoperationen).
Für Transaktionsprogramme können im Rahmen der Vorübersetzung durch einen Prä-Compiler Operationen zur Prüfung von Integritätsbedingungen sowie zur Reaktion auf Integritätsverletzungen eingebettet werden. Voraussetzung dafür ist - wie bei statischem eingebettetem SQL der Fall - daß neben den jeweiligen Änderungsoperationen auch die Namen der betroffenen Tabellen und Attribute erkannt werden. Die Prüfanweisungen können sich dabei auf einzelne Änderungsoperationen oder aber das gesamte Transaktionsprogramm beziehen, etwa um verzögerte Integritätsbedingungen zu überwachen.
Da mit dieser Technik jedoch keine dynamischen SQL-Anweisungen sowie direkte (Ad-hoc-) Änderungen unterstützt werden können, ist eine weitergehende Integritätskontrolle erforderlich. So sind bei der Übersetzung und Optimierung von Änderungsoperationen im Ausführungsplan direkt entsprechende Prüfoperationen zu erzeugen, oder es erfolgt der Aufruf dynamischer Prüfroutinen eines eigenen Integritäts-Subsystems (bzw. eines Regel-Subsystems). Aus Leistungsgründen ist beim Aufruf solcher Prüfroutinen möglichst viel Kontextinformation zur Überprüfung bereitzustellen, um die Anzahl zu prüfender Integritätsbedingungen auf ein Minimum zu beschränken. Insbesondere sollte es möglich sein, die Prüfungen auf die von einer Änderung betroffenen Daten zu beschränken, um nicht große Teile der Datenbank auswerten zu müssen (z. B. bei Einfügen eines neuen Satzes sind die Integritätsbedingungen nur für diesen zu prüfen, nicht für die gesamte Tabelle).
Eine im Rahmen der Anfrageoptimierung nutzbare Technik zur Integritätskontrolle ist die für das DBS Ingres vorgeschlagene Anfragemodifikation (Query Modification) [STON75]. Dabei erfolgt eine Transformation von Änderungsoperationen durch Hinzunahme von Prädikaten einzuhaltender Integritätsbedingungen, so daß durch die resultierende Operation eine Verletzung der betreffenden Bedingungen umgangen wird. Diese in Abb. 13.6 beispielhaft illustrierte Methode ist jedoch nur für einfache statische und unverzögerte Integritätsbedingungen nutzbar. Sie führt zudem entgegen der üblichen Vorgehensweise nicht zum Abbruch der Transaktion, sondern verhindert lediglich die Ausführung einer integritätsgefährdenden Änderungsanweisung, was bei Transaktionen mit mehreren Operationen zu unerwarteten Effekten führen kann. Der offensichtliche Vorteil der Query-Modifikation liegt darin, daß die Integrität mit den vorhandenen Ausführungsmechanismen des DBS sichergestellt wird.
Eine allgemeine Realisierungsmöglichkeit zur Integritätskontrolle besteht darin, Trigger bzw. ECA-Regeln innerhalb des DBS heranzuziehen, selbst wenn eine deklarative Spezifikation der Integritätsbedingungen erfolgt. Denn wie erwähnt lassen sich darüber die meisten (einschließlich dynamischer) Integritätsbedingungen realisieren, wobei jedoch auch verzögerte Bedingungen zu unterstützen sind. Die Implementierung des ECA-Konzeptes ermöglicht darüber hinaus die Realisierung zahlreicher weiterer Kontrollaufgaben aktiver DBS. Die effektive Generierung von ECA-Regeln aus einer deklarativen Spezifikation von Integritätsbedingungen ist im allgemeinen Fall ein komplexes Problem und wurde u. a. in [GREF93, CERI94, GERT94] untersucht. Die Realisierung eines umfassenden Regelsystems steht für kommerzielle DBS noch aus, jedoch gibt es erste Implementierungen im Rahmen von Prototypen wie Postgres und Starburst.
In Postgres wurden zwei unterschiedliche Arten der Regelbehandlung realisiert [STON90, POTA96], wobei für jede Regel eine der beiden Realisierungsmöglichkeiten auszuwählen ist. Defaultgemäß wird ein zur Laufzeit wirksam werdendes und auf Tupelebene arbeitendes Regelsystem verwendet (tuple level rule system). Dabei werden bei der Spezifikation einer neuen Regel alle Tupel der Datenbank (bzw. ganze Relationen), welche die Qualifizierungsbedingung der Regel zu diesem Zeitpunkt erfüllen, mit einer permanenten Markierung für die Regel ("rule lock") versehen. Bei der Abarbeitung von Operationen wird für ein Tupel für alle Regeln, zu denen eine Markierung vorgefunden wird, eine entsprechende Regelauswertung angestoßen. Als Alternative wird ein zur Übersetzungszeit von DB-Operationen wirkender Query-Rewrite-Ansatz zur Regelbehandlung unterstützt, der eine Erweiterung der diskutierten Query-Modifikation darstellt. Die Entwickler räumen ein, daß die beiden Ansätze unter Umständen zu unterschiedlichen Ergebnissen führen können. In der vorgenommenen Implementierung ist die Regelauswertung auch direkt an DB-Operationen gekoppelt; eine als machbar angesehene verzögerte Auswertung von Regeln am Transaktionsende wurde nicht realisiert.
Demgegenüber liegt der Schwerpunkt des Regelsystems für den DBS-Prototyp Starburst in der mengenorientierten Regelauswertung am Ende von Transaktionen [WIDO91, WIDO96b]. Pro Transaktion werden dabei für jede geänderte Tabelle vier temporäre Relationen (transition tables) mit den von Änderungen betroffenen Sätzen geführt. In den Tabellen deleted und inserted werden dabei die gelöschten und eingefügten Sätze aufgenommen, während die Tabellen old-updated und new-updated für geänderte Sätze die Werte vor und nach der Änderung enthalten. Diese Tabellen ermöglichen eine Begrenzung der Regelauswertung auf die minimale Menge relevanter Daten. Die Nutzung dieser Tabellen wird innerhalb der Regeln festgelegt, welche für deklarativ spezifizierte Integritätsbedingungen im allgemeinen automatisch vom Compiler erzeugt werden können (siehe Beispiel in Abb. 13.7 unter Verwendung der Starburst-Syntax). In der Realisierung wurde der effizienten Verarbeitung rekursiv ausgelöster Regeln besondere Beachtung gewidmet, worauf hier jedoch nicht näher eingegangen werden kann.
Die zur Integritätskontrolle erforderlichen DB-Operationen führen natürlich generell zu einer Erhöhung der DBS-Last, welche auch beim physischen DB-Entwurf zu berücksichtigen ist. Anderenfalls kann die Überprüfung von Integritätsbedingungen zu intolerabel häufigen Relationen-Scans mit zahlreichen E/A-Vorgängen und hohem Sperrpotential führen. In [HÄRD92b, HÄRD96] wird die Zugriffspfadunterstützung zur effizienten Gewährleistung der Relationalen Invarianten untersucht. Es stellt sich u. a. heraus, daß aus Leistungsgründen dabei für jeden Primär- und Fremdschlüssel eine Indexunterstützung erforderlich ist. In [SIMO95] wurden für Trigger kommerzieller DBS zum Teil erhebliche Leistungsprobleme festgestellt, mitbedingt durch eine hohe Ausführungsfrequenz sowie verschärfte Sperrengpässe. In [BRÜC97] konnte für eine konkrete Anwendung der Einsatz von Triggern zur Integritätskontrolle im Einbenutzerbetrieb etwas bessere Leistungsmerkmale als eine anwendungsseitige Realisierung bewirken, insbesondere aufgrund der Einsparung an DBS-Aufrufen; noch bessere Antwortzeiten wurden jedoch bei Einsatz deklarativer Integritätsbedingungen gemessen.