Viele fachliche Fragen drehen sich nicht um einzelne Datensätze, sondern um Beziehungen: Welche Kunden hängen über Aufträge zusammen? Welche Systeme sind von einer Komponente abhängig? Welche Transaktionen teilen einen gemeinsamen Pfad? Oracle AI Database 26ai unterstützt dafür native SQL Property Graphs und SQL/PGQ-Abfragen nach dem SQL:2023-Standard.
1. Relationale Quellen als Graph modellieren
Ein SQL Property Graph definiert, welche Tabellen oder Views als Vertices und Edges dienen und welche Spalten Eigenschaften liefern. So können beispielsweise Kunden und Produkte Knoten sein, während Bestellungen oder Abhängigkeiten als Kanten modelliert werden.
Die wichtigste Designentscheidung ist nicht die Syntax, sondern die Semantik: Welche Identität verbindet zwei Knoten? Welche Beziehungen sind zeitlich gültig? Welche Daten dürfen in die Graphsicht einfließen? Eine klare Definition verhindert, dass spätere Traversierungen zufällige oder fachlich mehrdeutige Pfade liefern.
2. SQL/PGQ für nachvollziehbare Abfragen
Oracle AI Database 26ai unterstützt SQL Property Graph Queries nach dem SQL/PGQ-Standard. Damit können Pfade und Muster in relational vertrauter SQL-Umgebung beschrieben werden. Für Entwickler ist das interessant, weil Graphabfragen nicht zwingend über eine separate Graphplattform laufen müssen.
Beginnen Sie mit kleinen, überprüfbaren Abfragen: direkte Nachbarn, kurze Pfade oder eine klar begrenzte Abhängigkeitssuche. Erst danach sollten längere Traversierungen, zentrale Knoten oder komplexe Muster produktiv eingesetzt werden. Begrenzungen für Tiefe und Ergebnismenge schützen vor unerwartet teuren Abfragen.
3. Berechtigungen und Datenherkunft
Für die Anlage eines Property Graphs sind passende Graph-Privilegien erforderlich. Der Graph-Owner benötigt außerdem Zugriff auf die zugrunde liegenden Tabellen oder Views. Die Rechte sollten so vergeben werden, dass ein Graph nur die fachlich vorgesehenen Quellen sichtbar macht.
Dokumentieren Sie pro Graph Owner, Quellen, fachliche Bedeutung, Aktualitätsannahme und sensible Eigenschaften. Ein Graph kann Beziehungen sichtbar machen, die in einer einzelnen Tabelle weniger auffällig wären. Deshalb gehören Datenschutz, Mandantentrennung und Row-Level-Security in die Architekturprüfung.
4. Schemaänderungen und Abhängigkeiten testen
Property Graphs hängen von den definierten Tabellen, Spalten und Ausdrücken ab. Änderungen an verwendeten Objekten können den Graph ungültig machen oder nachgelagerte Materialized Views beeinflussen. Vor einem Deployment sollte daher geprüft werden, ob Spalten umbenannt, Typen verändert oder Kantenbedingungen angepasst werden.
Ein sinnvoller Test umfasst DDL-Validierung, Beispielpfade, Berechtigungen und Ausführungspläne. Zusätzlich sollte der Betrieb wissen, wie ein Graph neu kompiliert, ersetzt oder kontrolliert zurückgenommen wird. Graphdefinitionen gehören in dasselbe Versions- und Freigabesystem wie Tabellen und Views.
5. Praktische DBA-Checkliste
- Graphziel, Knoten, Kanten, Identitäten und fachliche Gültigkeit definieren.
- Quellen, Owner, Privilegien und sensible Eigenschaften dokumentieren.
- Direkte Pfade und begrenzte Traversierungen als Regressionstests anlegen.
- Maximale Tiefe, Ergebnismenge und Ressourcenverbrauch überwachen.
- Schemaänderungen gegen Graphdefinitionen und abhängige Objekte prüfen.
- Graphdefinition, Rollback und fachliche Freigabe im Deployment-Prozess versionieren.
Fazit
SQL Property Graphs in Oracle AI Database 26ai erweitern relationale Daten um eine standardisierte Beziehungssicht. Mit SQL/PGQ lassen sich Abhängigkeiten, Pfade und Netzwerke direkt in der Datenbank untersuchen. Der produktive Nutzen entsteht durch ein präzises Modell, begrenzte Abfragen, geprüfte Rechte und ein Deployment, das Graphabhängigkeiten berücksichtigt.
Weiterführend: Oracles Überblick zu den Property-Graph-Neuerungen in 26ai, die CREATE PROPERTY GRAPH-Referenz und die Property-Graph-Übersicht.