Oracle 26ai Domains und Annotations Deep Dive
Der Bereich der Datenmodellierung war in relationalen Datenbanken lange Zeit erstaunlich stabil. Mit Oracle 26ai ändert sich das grundlegend: Domains und Annotations sind zwei neue Features, die die Modellierung vereinfachen, standardisieren – und erstmals eine Brücke zwischen klassischer Datenbankstruktur und modernen KI-Anwendungen schlagen. Domains ermöglichen benutzerdefinierte Datentypen mit zentral verwalteten Constraints und Default-Werten. Annotations sind eine neue SQL-DDL-Erweiterungsklasse, die strukturierte Metadaten direkt an Datenbankobjekte bindet – ein entscheidender Baustein für die semantische Anreicherung von Daten im Zeitalter von KI und Large Language Models.
- Annotations – strukturierte Metadaten für die Datenbank
- Anwendung von Annotations
- Annotations abfragen: Metadata Views
- Annotations als Fundament für KI und Vector Search
- Domains – benutzerdefinierte Datentypen mit Mehrwert
- Arten von Domains
- Domain-Funktionen
- Vordefinierte Domains
- Vorteile von Domains
- Einschränkungen und Überlegungen
- Anwendungsfälle
- Fazit: Auf dem Weg zur Data Intention Language
Annotations – strukturierte Metadaten für die Datenbank
Bisher konnten Zusatzinformationen über Tabellen und Spalten nur über Kommentare gespeichert werden. Diese sind jedoch eingeschränkt: nur ein Kommentar pro Tabelle und Spalte, keine Struktur, keine Mehrfachwerte.
Mit Oracle 26ai kommen Annotations – eine neue Möglichkeit, strukturierte Metadaten in Form von Schlüssel-Wert-Paaren an nahezu jedes Datenbankobjekt zu hängen. Die annotation-Klausel ist eine Common SQL DDL Clause, die in vielen create - und alter-Befehlen verfügbar ist.
Annotations können direkt beim Anlegen eines Objekts oder später mit einem alter-Statement hinzugefügt werden. Die Operatoren add, drop und replace lassen sich optional mit if [not] exists kombinieren, was skriptgesteuerte Änderungen vereinfacht.
Anders als Kommentare sind Annotations nicht auf Tabellen, Views und deren Spalten beschränkt, sondern auch für Indizes und weitere Objekttypen verfügbar.
Annotations und die if [not] exists-Optionen sind seit den letzten Quartals-Updates auch in Oracle 19c verfügbar.
drop table if exists resource_job;
create table emp_tasks (
emp_id raw(16) not null annotations (SurrogateKey, UUID, PK),
task_id raw(16) not null annotations (SurrogateKey, UUID, PK),
start_ts timestamp annotations (content 'actual start of work', UI_Display '["long", "date_time_local_tz"]'),
changed_by varchar2(100) annotations (UI_Display 'hidden', Classification 'change tracking'),
changed timestamp annotations (UI_Display 'hidden', Classification 'change tracking'),
)
annotations (relation '["emps", "tasks"]', visibility 'hidden');Listing 1: Syntax-Beispiel für Annotations
Anwendung von Annotations
Keys und Werte sind Freitext. Keys können bis zu 1024 Zeichen lang sein, Werte bis zu 4000 – und dürfen auch strukturiertes JSON enthalten. So lässt sich beispielsweise eine UI_Display-Annotation mit '[{"format":"long"}, {"tz": "utc"}, {"label": "Work Start"}]' belegen, um komplexe Darstellungslogik direkt in den Metadaten abzubilden. Annotations haben keine direkte Auswirkung auf das Verhalten der Datenbank, können aber einfach abgefragt und von Anwendungen interpretiert werden.
Schauen wir uns das Beispiel aus Listing 1 an: Die Spalte emp_id erhält die Annotations SurrogateKey, UUID und PK. Alle drei Annotationen bestehen nur aus einem Key – ihre Bedeutung erschließt sich auch ohne Wert. Die Annotation UI_Display könnte in einer Anwendung genutzt werden, um die Spalte im Formular auszublenden oder Datumswerte speziell zu formatieren. Die Umsetzung liegt dabei komplett in der Hand der Anwendungsentwickler.
Da sensible Daten zunehmend reguliert sind, können Annotations auch helfen, Compliance-Informationen wie DSGVO-Klassifizierungen direkt in der Datenbank zu hinterlegen. ETL-Prozesse und Data-Science-Tools können diese Metadaten verwenden, um Daten besser zu interpretieren oder automatisch zu validieren.
Annotations abfragen: Metadata Views
Oracle stellt für Annotations eigene Data-Dictionary-Views bereit: [USER|ALL|DBA]_ANNOTATIONS liefert die Annotation-Namen, ANNOTATIONS_USAGE zeigt die vollständigen Schlüssel-Wert-Paare inklusive der zugeordneten Objekte und Spalten, und ANNOTATION_VALUES gibt nur die Werte zurück. Diese Views machen es einfach, Annotations programmatisch auszuwerten – sei es für automatisierte Dokumentation, Compliance-Prüfungen oder die Anbindung an KI-Tools.
Annotations als Fundament für KI und Vector Search
Mit dem rasanten Aufstieg von KI und Large Language Models (LLMs) wird die Speicherung von Kontextinformationen zu einem entscheidenden Erfolgsfaktor. LLMs arbeiten mit Embeddings – hochdimensionalen Vektoren, die die semantische Bedeutung von Daten abbilden. Oracle AI Vector Search ermöglicht es, solche Vektoren direkt in der Datenbank zu speichern und effizient zu durchsuchen. Doch Vektoren allein reichen nicht aus: Damit ein LLM oder eine Retrieval-Augmented Generation (RAG)-Pipeline sinnvolle Ergebnisse liefern kann, braucht es Kontext über die Daten.
Genau hier kommen Annotations ins Spiel. Sie liefern eine strukturierte, maschinenlesbare Metadatenebene, die beschreibt, was eine Spalte enthält, wie die Daten zu interpretieren sind und welche Geschäftsregeln gelten.
Ein konkretes Beispiel verdeutlicht den Unterschied: Eine Tabelle XYZ mit den Spalten C1, C2, C3, C4 ist für ein LLM nicht interpretierbar. Ergänzt man jedoch Annotations wie Purpose 'Employee_Detail' auf der Tabelle sowie Salary 'USD' auf C1, Name 'First & Last' auf `C2` und `Department 'Abbreviated' auf C3, kann das LLM die Frage "Wie hoch ist das durchschnittliche Gehalt pro Abteilung?" korrekt beantworten – ohne dass ein Entwickler die Abfrage manuell formulieren muss.
Annotations helfen dabei nicht nur KI-Systemen, sondern drei Zielgruppen gleichermaßen: Entwicklern, die das Datenmodell verstehen und pflegen müssen, Endanwendern, deren Werkzeuge die Metadaten für benutzerfreundliche Darstellungen nutzen können, und KI-Systemen, die auf Kontext angewiesen sind, um Daten korrekt zu interpretieren.
Ein LLM, das auf eine annotierte Datenbank zugreift, kann beispielsweise automatisch erkennen, dass eine Spalte personenbezogene Daten enthält (DSGVO_Kategorie: 'personenbezogen'), welche Einheit ein numerischer Wert hat (Unit: EUR) oder ob ein Feld für die Volltextsuche relevant ist (SearchRelevance: 'high').
In Kombination mit Oracle AI Vector Search entsteht so ein mächtiges Zusammenspiel: Annotations beschreiben die semantische Bedeutung der strukturierten Daten, während Vector Search die Ähnlichkeitssuche über unstrukturierte Inhalte ermöglicht. Eine RAG-Pipeline kann die Annotations nutzen, um den Kontext für generierte Antworten anzureichern und Halluzinationen zu reduzieren. Auch bei der automatischen Generierung von SQL-Abfragen durch ein LLM (Text-to-SQL) sind Annotations wertvoll: Sie geben dem Modell Hinweise auf Beziehungen, Datentypen und Geschäftslogik, die aus dem Schema allein nicht ersichtlich wären.
Annotations können in Kombination mit Domains automatisch an Spalten angehängt werden – ein Mechanismus, der die semantische Anreicherung großer Datenbestände erheblich vereinfacht.
Oracle arbeitet zudem an einem AI Enrichment for Metadata-Workflow im SQL Developer, der KI-gestützte Vorschläge für Annotations generieren kann. Damit lassen sich Schemas, Tabellen und Spalten schrittweise annotieren – unterstützt durch automatische Empfehlungen und ein fortlaufendes Reporting über den Enrichment-Fortschritt.
Domains – benutzerdefinierte Datentypen mit Mehrwert
Domains sind benutzerdefinierte Datentypen, die Datentyp, Constraints, Default-Werte, Anzeige- und Sortierfunktionen sowie Annotations zusammenfassen können. Sie ermöglichen konsistente Definitionen ähnlicher Spalten über die gesamte Datenbank hinweg.
In der Oracle-Welt waren Domains bislang nur aus Tools wie dem Oracle Data Modeler bekannt. Mit dem SQL-Standard:2023 sind Domains nun offiziell Teil der SQL-Spezifikation – auch PostgreSQL unterstützt sie bereits. Oracle 26ai geht mit seiner Implementierung über den Standard hinaus und integriert Domains als erstklassiges Feature direkt in die Datenbank-Engine.
Domains können mehrere Spalten umfassen, Constraints zentral verwalten und neue Funktionen für Anzeige und Sortierung definieren.
drop domain if exists uuid force;
drop domain if exists short_string force;
drop table if exists emps;
create domain short_string as varchar2(30);
create domain uuid
as raw(16) default sys_guid() not null
annotations (UI_Display 'UUID', Classification 'uuid')
display lower(
substr(lpad(rawtohex(uuid),32,'0'), 1, 8)||'-'||
substr(lpad(rawtohex(uuid),32,'0'), 9, 4)||'-'||
substr(lpad(rawtohex(uuid),32,'0'), 13, 4)||'-'||
substr(lpad(rawtohex(uuid),32,'0'), 17, 4)||'-'||
substr(lpad(rawtohex(uuid),32,'0'), 21));
create table emps
(id uuid primary key,
name short_string);
insert into emps (name) values ('John');
select id, domain_display(id) from emps;
ID DOMAIN_DISPLAY(ID)
-------------------------------- ------------------------------------
22BC6158C0EA05E4E0630200590A169C 22bc6158-c0ea-05e4-e063-0200590a169cListing 2: Syntax-Beispiel für Domains
Durch den Einsatz von Domains bleiben create table-Statements übersichtlich. Änderungen an einer Domain werden automatisch in allen abhängigen Tabellen wirksam.
Arten von Domains
Die einfachste und häufigste Form sind Single-Column-Domains, die Typ, Default und Regeln für eine einzelne Spalte bündeln. Wer zusammengehörige Spalten gemeinsam absichern möchte, greift zu Multi-Column-Domains: Eine Adress-Domain kann etwa Straße, Hausnummer, PLZ und Ort zusammenfassen und Check-Constraints über alle vier Spalten hinweg formulieren. Flexible-Domains gehen noch einen Schritt weiter und wählen basierend auf dem Wert einer Diskriminator-Spalte dynamisch eine Sub-Domain aus – etwa unterschiedliche Adressformate je nach Ländercode.
Dies ist auch ein Killer-Feature für die JSON-Validierung: Unterschiedliche API-Versionen lassen sich so gegen jeweils passende JSON-Schemas prüfen. Schließlich gibt es Enumeration-Domains, die benannte Wertelisten mit numerischer Zuordnung definieren. Sie lassen sich in SQL-Statements wie Read-Only-Tabellen abfragen und bringen automatisch Check-Constraints, Display- und Sort-Funktionen mit.
Domain-Funktionen
Oracle 26ai stellt fünf neue SQL-Funktionen für die Arbeit mit Domains bereit. Mit `domain_display(expr)` lässt sich ein Wert über die in der Domain definierte Display-Funktion formatieren – ein Beispiel zeigt Listing 2. Das Pendant domain_sort(expr) erzeugt einen Sortierwert nach der Domain-Logik. Ob ein konkreter Wert die Constraints einer Domain erfüllt, prüft domain_check(expr), während domain_check_type(expr) sich auf die reine Datentypprüfung beschränkt. Für Metadaten-Analysen und dynamische Abfragen ist domain_name(column) nützlich: Sie gibt den Namen der Domain zurück, die einer Spalte zugeordnet ist.
Vordefinierte Domains
Nicht alles muss selbst gebaut werden: Oracle 26ai liefert über hundert vordefinierte Domains mit – darunter email_d, uri_d, Domains für Währungen, Längen, Gewichte, Kreditkartennummern und vieles mehr. Sie enthalten bereits Constraints, Default-Werte, Anzeige- und Sortierfunktionen, werden von Oracle gewartet und sind sofort einsatzbereit.
Vorteile von Domains
Der zentrale Gewinn von Domains liegt in der Standardisierung: Wiederkehrende Datentypen wie E-Mail-Adressen oder Telefonnummern werden einmal definiert und überall gleich behandelt. Ändert sich eine Validierungsregel, erfolgt die Anpassung einmal in der Domain-Definition – alle betroffenen Spalten übernehmen die neue Regel automatisch. Entwickler müssen bei neuen Tabellen nicht mehr jedes Mal Datentypen und Constraints von Hand spezifizieren, sondern greifen auf vordefinierte Domains zurück. Das reduziert den Entwicklungsaufwand, minimiert Fehlerquellen und erleichtert die langfristige Wartung erheblich.
Einschränkungen und Überlegungen
Die Evolution von Domains ist bewusst eingeschränkt: Per alter domain lassen sich nur Display- und Order-Funktionen sowie Annotations anpassen. Datentypen und Check-Constraints erfordern ein drop und create der Domain. Beim Entfernen gibt es drei Varianten: Ein einfaches `drop domain` schlägt fehl, solange die Domain noch Spalten zugeordnet ist. `drop domain ... FORCE` löst die Zuordnung und entfernt Domain-Constraints, Defaults und Annotations von den Spalten. `drop domain ... FORCE PRESERVE` entfernt die Domain, belässt aber Constraints und Defaults auf den Spalten – hier ist Vorsicht geboten, da nach dem Neuanlegen doppelte Constraints entstehen können. In jedem Fall muss die neu erstellte Domain allen Tabellenspalten wieder zugewiesen werden, und bei inkompatiblen Daten sind Migrationen erforderlich.
Daneben gilt es zu bedenken, dass Domain-Constraints auf SQL-Ausdrücken basieren und nur innerhalb derselben Zeile prüfen können. Für tabellenübergreifende oder komplexere Validierungslogik müssen weiterhin andere Mechanismen wie Trigger oder Application-Logic eingesetzt werden.
Anwendungsfälle
Domains eignen sich besonders für Szenarien, in denen eine hohe Standardisierung und Wiederverwendbarkeit von Datentypen und Validierungsregeln gefragt ist:
Ein naheliegender Einsatz ist die Datenvalidierung: Domains stellen sicher, dass Telefonnummern, E-Mail-Adressen oder Postleitzahlen überall im gleichen Format gespeichert werden. Ebenso lassen sich Geschäftsregeln wie zulässige Rabattbeträge oder Lagerbestände zentral in Domains abbilden, statt sie über zahlreiche Tabellen zu verstreuen. Für sicherheitskritische Felder – etwa Kreditkartennummern, die spezielle Validierungen oder Verschlüsselung erfordern – bieten Domains einen einheitlichen Schutzrahmen.
Besonders wirkungsvoll sind Domains in Kombination mit JSON: Prüfungen gegen JSON-Schemas lassen sich in Domains definieren und auf mehrere Spalten anwenden. Über Flexible-Domains können diese Prüfungen sogar dynamisch abhängig vom Inhalt anderer Spalten erfolgen – etwa um verschiedene API-Versionen gegen das jeweils passende Schema zu validieren.
Schließlich spielen Domains auch im KI-Kontext eine wachsende Rolle: Da sie Annotations für die semantische Beschreibung von Spalten mitbringen können, wird in Kombination mit Oracle AI Vector Search die automatisierte Anreicherung von Daten für KI-gestützte Analysen möglich.
Fazit: Auf dem Weg zur Data Intention Language
Domains und Annotations machen Datenmodellierung in Oracle 26ai konsistenter und wartungsfreundlicher. Doch sie sind mehr als nur technische Features: Zusammen bilden sie die Grundlage einer Data Intention Language (DIL) – einer Möglichkeit, nicht nur Struktur, sondern auch Absicht und Bedeutung von Daten direkt im Schema auszudrücken. Annotations liefern den semantischen Kontext, Domains die standardisierte Struktur mit Validierung, Anzeige- und Sortierlogik. Gemeinsam schaffen sie eine maschinenlesbare Beschreibungsebene, die Entwicklern, Endanwendern und KI-Systemen gleichermaßen hilft, Daten zu verstehen.
Insbesondere die Kombination von Annotations mit Oracle AI Vector Search und Large Language Models eröffnet neue Möglichkeiten: von der semantischen Anreicherung relationaler Daten über intelligente RAG-Pipelines bis hin zur automatischen SQL-Generierung. Da Domains auf dem SQL-Standard:2023 basieren, ist diese Entwicklung nicht auf Oracle beschränkt – sie markiert einen breiteren Paradigmenwechsel in der Datenmodellierung.
Wer mehr über Domains und Annotations erfahren möchte: Ich habe das Thema auf den IT Tagen 2025 im Dezember in Frankfurt vorgestellt. Die Folien und weiterführende Materialien sind auf meiner Website verfügbar.
