Eine Datenbank kennt traditionell den technischen Datentyp einer Spalte – zum Beispiel NUMBER, VARCHAR2 oder DATE. Ob ein Wert aber eine Kundennummer, eine Währung oder ein vertrauliches Geburtsdatum darstellt, liegt häufig in separaten Anwendungstabellen oder im Code. Oracle AI Database 26ai bietet mit Application Usage Domains und Schema Annotations eine zentrale, deklarative Ergänzung.
1. Usage Domain als fachlicher Dateneinsatz
Ein Usage Domain beschreibt, wie Daten verwendet werden. Es kann beispielsweise gemeinsame Constraints, Default-Ausdrücke, Suchregeln, Anzeige- oder Sortierlogik kapseln. Dabei bleibt der zugrunde liegende Oracle-Datentyp erhalten. Ein bestehendes NUMBER- oder VARCHAR2-Feld kann damit fachlich präziser beschrieben werden, ohne alle abhängigen Anwendungen auf einen neuen benutzerdefinierten Typ umzustellen.
Ein einfaches Enumeration-Domain kann etwa erlaubte Statuswerte zentral modellieren:
CREATE DOMAIN order_status AS VARCHAR2(20)
ENUM (new_order = 'NEW',
released = 'RELEASED',
cancelled = 'CANCELLED');
Die konkrete Modellierung sollte mit dem fachlichen Besitzer abgestimmt werden. Ein Domain ist kein Ersatz für Primär- oder Fremdschlüssel und sollte nicht als allgemeine Ablage für beliebige Geschäftslogik missbraucht werden.
2. Gemeinsame Regeln statt Copy-and-paste
Wenn dieselbe fachliche Regel für viele Tabellen gilt, liegt ihr Vorteil in der Wiederverwendung. Eine einheitliche Währungs- oder Länder-Code-Definition kann von mehreren Spalten genutzt werden. Änderungen und Reviews konzentrieren sich dadurch auf ein Datenbankobjekt statt auf viele voneinander abweichende Check Constraints oder UI-Konfigurationen.
Vor der Einführung sollte geprüft werden, ob vorhandene Daten die neue Regel erfüllen. Für produktive Migrationen gehören eine Bestandsprüfung, ein bereinigender Change und ein klarer Rückweg ins Runbook. Besonders bei Enumeration-Domains dürfen neue Werte nicht ungeplant bestehende Integrationen brechen.
3. Schema Annotations für zusätzliche Metadaten
Annotations sind leichtgewichtige Metadaten für Tabellen, Spalten, Indizes und Domains. Sie können beispielsweise ein Anzeige-Label, eine Gruppierung, ein Format, eine Sensitivitätskennzeichnung oder erlaubte UI-Operationen beschreiben:
CREATE TABLE customers (
customer_id NUMBER ANNOTATIONS (Identity),
display_name VARCHAR2(120)
ANNOTATIONS (Display 'Kundenname'),
birth_date DATE ANNOTATIONS (Confidential)
) ANNOTATIONS (Display 'Kunden');
Die Datenbank interpretiert solche Kennzeichnungen nicht automatisch als Maskierung, Autorisierung oder Rendering. Sie stellt sie als deklarierte Information bereit; APEX, APIs, Reporting-Tools oder eigene Services müssen festlegen, wie sie diese auswerten.
4. Dictionary und Governance
Für die Auswertung stehen unter anderem USER_ANNOTATIONS, USER_ANNOTATION_VALUES und die entsprechenden ALL_- oder DBA_-Views bereit. Damit lässt sich ein Metadaten-Check in CI/CD integrieren: Sind sensible Spalten gekennzeichnet? Haben zentrale Domains einen Owner? Existieren Display- oder Formatregeln für neue UI-relevante Spalten?
Die Governance sollte Namenskonventionen, erlaubte Annotation-Schlüssel, Owner, Review-Zyklen und den Umgang mit unbekannten Werten definieren. So bleiben die Metadaten maschinenlesbar und entwickeln sich nicht zu einer zweiten, unkontrollierten Dokumentationssprache.
5. Praktische Einführungs-Checkliste
- Fachliche Datenkonzepte identifizieren, die über mehrere Anwendungen hinweg gelten.
- Usage Domains von reinen Anzeige-Annotations klar trennen.
- Bestandsdaten gegen neue Constraints und Enumeration-Werte prüfen.
- Annotations mit Owner, Schlüsselkonvention und erlaubter Bedeutung dokumentieren.
- Dictionary-Views in Migrations- und Qualitätschecks einbeziehen.
- APEX, APIs und Reporting-Tools testen: Metadaten helfen erst, wenn Clients sie konsistent verarbeiten.
Fazit
Application Usage Domains und Schema Annotations in Oracle AI Database 26ai bringen fachliche Semantik näher an das Datenmodell. Gemeinsame Constraints und Nutzungsinformationen werden wiederverwendbar, ohne den technischen Basistyp unnötig zu verändern. Mit klarer Governance entsteht damit eine gute Grundlage für APEX-Oberflächen, APIs, Reporting und automatisierte Datenqualitätsprüfungen.
Weiterführend: Oracles Übersicht zu Application Data Usage, die Anleitung zu Schema Annotations und die SQL-Referenz zu CREATE DOMAIN.