Oracle Database · · 3 Min.

JSON Relational Duality Views

Wie relationale Daten als dokumentorientierte Schnittstelle nutzbar werden – ohne eine zweite Datenhaltung aufzubauen.

Viele Anwendungen brauchen beides: die Konsistenz relationaler Tabellen und die einfache Struktur eines JSON-Dokuments. JSON Relational Duality Views in Oracle Database 23ai verbinden diese Perspektiven. Die View speichert keine Kopie der Daten, sondern bildet Tabellen und Beziehungen als generierte Dokumente ab. Dadurch können APEX-, ORDS- oder andere API-Anwendungen ein passendes Dokumentmodell verwenden, während die Datenbank ihre relationale Struktur behält.

Der zentrale Vorteil: Eine fachliche Datenbasis kann für SQL-Reports und dokumentorientierte APIs genutzt werden, ohne Synchronisationslogik zwischen zwei Speichern.

1. Mit einer kleinen Dokumentform starten

Beginnen Sie mit einem überschaubaren Objekt, etwa einer Abteilung oder einem Kunden. Ein einfaches Beispiel aus der Oracle-Dokumentation sieht so aus:

CREATE JSON RELATIONAL DUALITY VIEW department_dv AS
  SELECT JSON { '_id'           : d.deptno,
                'departmentName' : d.dname,
                'location'       : d.loc }
    FROM department d WITH UPDATE INSERT DELETE;

Die Spalten werden dabei zu JSON-Feldern. _id identifiziert das Dokument; die Primärschlüsselspalte bleibt für die Identität besonders wichtig. Für verschachtelte Objekte und Arrays lassen sich weitere Tabellen über Unterabfragen und ihre Primärschlüssel-Fremdschlüssel-Beziehungen einbinden.

2. Schreibrechte bewusst deklarieren

Duality Views sind standardmäßig schreibgeschützt. Erst mit den Annotationen UPDATE, INSERT und DELETE wird festgelegt, welche Änderungen über das Dokument erlaubt sind. Das kann auf Tabellen- oder Feldebene geschehen. Ein guter Start ist eine read-only View für Such- und Detailseiten. Schreibrechte werden nur für Felder ergänzt, die der konkrete Prozess wirklich ändern muss.

Beispiel: Eine APEX-Anwendung darf den Status eines Auftrags aktualisieren, aber Kundendaten nur anzeigen. Diese Trennung gehört in die View-Definition und wird zusätzlich durch die Berechtigungen der Anwendung abgesichert. Eine Duality View ersetzt weder Authorization Schemes in APEX noch Rollen und serverseitige Prüfungen.

3. Mit APEX und ORDS einsetzen

Für eine APEX-Seite kann die View eine einheitliche Datenquelle für einen Detailbereich liefern. ORDS oder ein eigener REST-Endpunkt kann dasselbe Dokumentmodell an externe Clients ausgeben. So bleibt die fachliche Modellierung zentral in Oracle, während die Oberfläche nicht jede Join-Struktur der Tabellen kennen muss.

Vor dem produktiven Einsatz sollten Sie die Dokumentgröße, die erlaubten Operationen und die Abfragepläne prüfen. Für Listen eignen sich gezielte, kleinere Views besser als ein großes Dokument mit sämtlichen Beziehungen. Testen Sie außerdem parallele Änderungen: Die Dokumente können mit ETAG-bezogener Prüfung so aktualisiert werden, dass ein inzwischen veränderter Stand nicht still überschrieben wird.

4. Praktische Checkliste

  • Dokumente aus fachlichen Grenzen statt aus kompletten Tabellen ableiten.
  • _id und Primärschlüsselbeziehungen eindeutig definieren.
  • Schreibrechte standardmäßig geschlossen halten und feldweise öffnen.
  • APEX-Autorisierung, Datenbankprivilegien und Mandantengrenzen separat testen.
  • Dokumentgröße, ETAG-Verhalten und parallele Updates in realistischen Fällen prüfen.

Fazit

JSON Relational Duality Views sind besonders interessant, wenn eine bestehende Oracle-Datenbank zugleich SQL-Reporting und moderne JSON-Schnittstellen bedienen soll. Der Nutzen entsteht nicht durch eine möglichst große View, sondern durch ein klar abgegrenztes Dokumentmodell, bewusst deklarierte Schreibrechte und eine saubere Sicherheitsprüfung. Damit kann eine APEX- oder ORDS-Anwendung dokumentorientiert arbeiten, ohne die relationale Wahrheit aus der Datenbank herauszulösen.

Weiterführend: Überblick zu JSON Relational Duality Views und die Dokumentation zu schreibbaren Duality Views.