Oracle Database · · 3 Min.

SQL Assertions in 26ai

Wie Regeln über mehrere Tabellen direkt als Datenbankintegrität gelten.

Veröffentlicht am 17.10.2026 · Verfasst von Veysi Guenay

Primär- und Fremdschlüssel sichern Beziehungen zwischen Tabellen. Manche Geschäftsregeln betreffen jedoch mehrere Tabellen gleichzeitig: Zum Beispiel darf kein Auftrag ohne mindestens eine Position abgeschlossen werden. Solche Regeln wurden oft in Triggern oder Anwendungscode verteilt. Oracle AI Database 26ai unterstützt SQL Assertions, mit denen sich boolesche Bedingungen als Schemaobjekt definieren und bei Änderungen transaktional prüfen lassen.

Einordnung: Eine Assertion ist eine datenbankweite Integritätsregel über Tabellenabfragen. Oracle prüft sie bei Änderungen und verhindert den Commit, wenn die Bedingung verletzt ist. Das verlagert die Regel an eine Stelle, die für alle Anwendungen gilt.

1. Eine tabellenübergreifende Regel formulieren

Eine Assertion kann beispielsweise sicherstellen, dass es keine Aufträge ohne Position gibt:

CREATE ASSERTION order_requires_line
  CHECK (
    NOT EXISTS (
      SELECT 1
      FROM orders o
      WHERE NOT EXISTS (
        SELECT 1
        FROM order_lines l
        WHERE l.order_id = o.order_id
      )
    )
  );

Die Regel drückt eine fachliche Invariante als SQL-Bedingung aus: Es darf keine Zeile in orders geben, für die keine passende Position existiert. Sie gilt unabhängig davon, ob die Änderung aus APEX, ORDS, einem Batch oder einem anderen Client kommt.

2. Wann die Prüfung erfolgt

Assertions folgen den Zuständen von Integritätsbedingungen. Standardmäßig werden sie aktiviert und validiert: bestehende Daten müssen passen, und jede spätere Änderung wird geprüft. Mit DEFERRABLE INITIALLY DEFERRED kann die Prüfung bis zum Transaktionsende verschoben werden.

Das ist nützlich, wenn eine fachlich gültige Änderung mehrere DML-Schritte benötigt und der Zwischenzustand innerhalb der Transaktion kurzzeitig unvollständig ist. Am Ende muss die Regel dennoch erfüllt sein, sonst schlägt der Commit fehl. Deferrable sollte daher nur gewählt werden, wenn die Anwendung ihre Transaktionsgrenzen bewusst steuert.

3. Einführung in bestehende Schemas

Vor dem Anlegen einer Assertion sollte genau die zugrunde liegende Abfrage ausgeführt werden. So werden bestehende Verstöße sichtbar, bevor die Validierung das Deployment stoppt. Bei großen Tabellen sind Ausführungsplan, passende Indizes für die korrelierten Schlüssel und die zusätzlichen Kosten bei DML zu messen.

Assertions unterstützen Zustände wie ENABLE VALIDATE und ENABLE NOVALIDATE. NOVALIDATE prüft neue Änderungen, garantiert aber nicht, dass der historische Datenbestand bereits regelkonform ist. Plane deshalb einen separaten Bereinigungs- und Nachweisprozess ein, bevor du die vollständige Validierung als abgeschlossen meldest.

4. Rechte und Betriebsaspekte

Zum Erstellen im eigenen Schema ist das Systemprivileg CREATE ASSERTION nötig. Verweist die Bedingung auf Tabellen eines anderen Schemas, sind dafür spezielle ASSERTION REFERENCES-Objektrechte erforderlich; Synonyme werden in Assertions nicht unterstützt. Assertions und Constraints teilen sich außerdem denselben Namensraum.

Bei einer Verletzung wird die Änderung mit einem Datenbankfehler abgewiesen. Anwendungen sollten diesen Fall als fachliche Validierung behandeln, den Nutzer verständlich informieren und keine automatische Retry-Schleife starten. Für DBAs gehören Assertion-Zustand, Fehlerhäufigkeit und Laufzeit in Deployment- und Monitoring-Prozesse.

5. Praktische Einführungs-Checkliste

  1. Regel als klare boolesche Aussage mit allen betroffenen Tabellen formulieren.
  2. Die Assertion-Abfrage zuerst direkt ausführen und vorhandene Verstöße dokumentieren.
  3. Indizes und DML-Kosten für die geprüften Join-Schlüssel bewerten.
  4. Validierungszustand und gegebenenfalls Bereinigung des Altbestands planen.
  5. DEFERRABLE nur bei tatsächlich mehrstufigen Transaktionen einsetzen.
  6. Anwendungsfehler, Deployment und Monitoring auf Assertion-Verletzungen vorbereiten.
Praxisregel: Assertions eignen sich für Regeln, die mehrere Tabellen oder Beziehungen umfassen. Einfache Spaltenregeln bleiben als CHECK-, UNIQUE- oder FOREIGN KEY-Constraints meist direkter und leichter zu verstehen.

Fazit

SQL Assertions in Oracle AI Database 26ai schließen eine Lücke zwischen einfachen Tabellen-Constraints und selbstgebauter Triggerlogik. Sie legen komplexere Invarianten deklarativ im Datenbankschema ab und erzwingen sie für alle Zugriffswege. Ein sorgfältiger Check der Bestandsdaten, Query-Kosten und Transaktionsgrenzen macht den Einsatz planbar.

Weiterführend: Oracles SQL-Referenz zu CREATE ASSERTION, die Betriebsdokumentation zu Assertion-Zuständen und die Hinweise zu Assertions statt komplexer Triggerprüfungen.