Die Speicherung von XML-Daten in der Datenbank

(Auszug aus "Oracle PL/SQL: Das umfassende Handbuch", Kapitel 16 "Arbeiten mit XML", von Jürgen Sieben)

Zur Speicherung des Datentyps XMLType stehen grundsätzlich drei verschiedene Methoden zur Verfügung:

  1. Speicherung als »CLOB«
    Bei dieser Art der Speicherung wird die XML-Instanz als Textstream in ein CLOB (Character Large Object) geschrieben. Weißraum und Sortierung der XML-Instanz bleiben erhalten. Diese Speicherungsform ist das einfachste und für das reine Schreiben und Lesen der gesamten XML-Instanz auch das schnellste Verfahren. Möchten Sie allerdings Teile der XML-Instanz auslesen oder verändern, ist es zur Manipulation entweder erforderlich, einen DOM-Baum des gesamten Dokuments zu erzeugen, oder das gesamte Dokument wird ausgelesen, extern verändert und komplett in die Datenbank geschrieben. Diese Operationen erfordern viel Zeit und Ressourcen. Aufgrund leistungsfähigerer Methoden wird diese Variante in Zukunft wohl weniger Verbreitung finden.
  2. Speicherung als »BinaryXML«
    Bei dieser neuen Speicherungsform (ab Version 11) wird ein Format verwendet, das Oracle Compacted Schema-aware XML (CSX) nennt. Die Speicherung ist ähnlich kompakt wie bei einer komprimierten Speicherung, ist allerdings daraufhin optimiert, einen feingranularen Zugriff auf die Elemente der XML-Instanz zu ermöglichen. Dies erleichtert die Indizierung solcher Dokumente und erlaubt es, Validierungen und teilweise Änderungen und Erweiterungen des Dokuments durchzuführen, ohne dafür einen DOM-Baum zu benötigen. Oracle unterstützt diese Speicherform durch aktualisierte Parser, die es erlauben, auch über das Netzwerk die XML-Instanz im Format CSX auszutauschen und somit erhöhte Performance sicherzustellen. BinaryXML ist kompakt, wird schnell geschrieben und gelesen und ist einfach und schnell zu durchsuchen und zu bearbeiten.
  3. Speicherung in objektrelationalen Tabellen
    Im Gegensatz zu den ersten beiden Speicherformen, die jeweils mit einem XML-Schema assoziiert sein können oder auch nicht, ist dies bei der objektrelationalen Speicherung von XML-Instanzen Pflicht, denn das Schema wird über Annotationen so erweitert, dass erkennbar ist, welche Elemente in welche objektrelationalen Tabellen aufgeteilt werden sollen. Es entsteht ein automatisiertes Mapping zwischen XML-Elementen und objektrelationalen Tabellen, die auf Wunsch auch von Oracle direkt angelegt werden können. Diese Speicherungsform garantiert einen maximal schnellen Zugriff auf einzelne Elemente der XML-Instanz, auch ist eine entsprechende Indizierung über B*-Baum-Indizes möglich, während die anderen Speicherungsformen den ebenfalls nicht schlechten, aber generischen XMLIndex verwenden. Diese Speicherungsform ist etwas langsamer beim Lesen und Schreiben der gesamten XML-Instanz, weil die Instanz zerlegt und wieder zusammengesetzt werden muss. Zudem sind die Reihenfolge und der Weißraum nicht geschützt, sodass sich diese Speicherung nur anbietet, wenn diese Informationen nicht wesentlich sind. Der Vorteil ist der sehr schnelle Zugriff auf Element- und Attributwerte.

Dann müssen Sie generell die Frage beantworten, ob die zu speichernden XML-Instanzen gegen ein Schema validieren sollen oder nicht. Wir werden die Details der Registrierung eines Schemas noch unter Dokumente über XDB verwalten beleuchten, hier nur so viel: Um innerhalb der Datenbank gegen ein Schema validieren zu können, müssen Sie dieses Schema in die Datenbank laden und registrieren. Dafür steht ein spezielles PL/SQL-Package dbms_xmlschema bereit. Anschließend wird das Schema bei der Erstellung der Tabelle oder der XMLType-Spalte über seinen Namensraum referenziert. Diese Arbeiten sind erforderlich, falls Sie XML objektrelational speichern möchten, doch auch bei den beiden anderen Speicherformen können Sie mit der Registrierung eines Schemas die XML-Instanzen vor dem Einfügen validieren und so eine höhere Datenqualität erreichen.

Die Wahl der richtigen Speicherungsform wird also wesentlich durch den Einsatzzweck bestimmt, eine nachträgliche Änderung ist nur sehr aufwendig möglich. Natürlich ist es immer schwierig, eine generelle Einschätzung zu geben, zu unterschiedlich sind die Einsatzszenarien. Doch finde ich die Diskussion zu den unterschiedlichen Speicherungsformen in der Literatur, der Online-Dokumentation und auch in einigen Forenbeiträgen zu sehr aus der XML-Sicht geführt: Die Frage, ob XML in jedem Fall in der Datenbank persistiert werden muss, steht hier oftmals nicht zur Debatte. Dabei ist aus meiner Sicht diese Frage die erste, die geklärt werden muss: Warum müssen Daten im Format XML in der Datenbank abgelegt werden? Das Beispiel eines Bestellsystems, das alle Bestellungen als XML-Instanzen in der Datenbank ablegt, mag ich eigentlich überhaupt nicht: Das ist aus meiner Sicht ein nachrichtenbasiertes System, diese XML-Informationen würde ich, wenn nicht wirklich gute Gründe dagegensprächen, direkt auf relationale Tabellen verteilen wollen. Ob ich aber eine solche Speicherung über von Oracle erzeugte objektrelationale Tabellen erlauben würde, daran hätte ich so meine Zweifel. Meine Bedenken kommen hauptsächlich daher, dass ein objektrelationales Datenmodell mir Einschränkungen in der Auswertung durch SQL auferlegt, die untypisch für relationale Datenbanken sind.

Wenn Sie jedoch XML in der Datenbank speichern möchten oder müssen, dann ist die entscheidende Frage aus meiner Sicht, ob Sie mit den Daten innerhalb der XML-Instanz etwas anfangen müssen oder ob Sie die XML-Instanz nur als Ganzes interessiert. Ist das so, bietet sich die Speicherung entweder als XMLType und CLOB-Speicherung oder als BinaryXML an, wobei dieser zweite Ansatz dann besser ist, wenn Sie auch auf Elemente der XML-Instanz zugreifen möchten. Interessiert Sie eigentlich gar nicht, dass es sich um XML handelt, und benötigen Sie lediglich eine Ablage, denken Sie doch alternativ über eine Speicherung in BLOB (CLOB könnte Probleme bei der Zeichensatzkodierung nach sich ziehen) nach.

Falls Sie allerdings eine feingranulare Speicherung in relationalen Tabellen benötigen und XML lediglich ein Transportmedium ist, bietet sich entweder die objektrelationale Speicherung oder aber das händisch programmierte Schreddern der XML-Instanz auf relationale Tabellen in Java (weil wir dort mit SAX arbeiten können und nicht den DOM-Baum benötigen) an. Ist die Struktur der eingehenden XML-Instanzen darüber hinaus relativ trivial, oder entsprechen die Elementnamen sogar den Tabellennamen, kann auch ein direktes Mapping durch das Package dbms_xmlstore verwendet werden, um eine XML-Instanz direkt in die angesprochenen Tabellen zu speichern. Komplexere Mapping-Aufgaben lassen sich allerdings mit diesem Package nicht durchführen.

Die objektrelationale Methode ist initial einfacher zu realisieren, aber eventuell aufwendiger in der späteren Arbeit und der Administration. Reizwort ist hier (wie immer in Datenbanken) das Thema Schemamigration, also die Frage, wie Ihre Datenbank auf Änderungen des Nachrichtenformats reagieren soll. Zudem müssen Sie die Einschränkungen bezüglich des Zugriffs mit SQL beachten. Meiner Beobachtung nach haben vor allem solche Entwickler ein Interesse an der objektrelationalen Speicherung von XML, die aus Sicht der Anwendung blicken und eine unproblematische Abbildung auf die Datenbank wünschen. Zusätzlich interessant könnte für diese Entwickler die Tatsache sein, dass durch die annotierte Schemadatei auch die Erstellung der Objekttypen und sogar von JavaBeans zur Arbeit mit diesen Objekttypen automatisiert erfolgen kann. Zu diesen Entwicklern gehöre ich allerdings nicht, daher habe ich keine so große Sympathie für diesen Ansatz. Aber das muss nun wirklich nicht Ihr Maßstab sein.

Neuerungen in Version 12c
Insgesamt ist eine starke Tendenz in Hinblick auf die Vereinheitlichung der eingesetzten Technologien zu beobachten. Schon in Version 11g begonnen, setzt XQuery seinen Siegeszug zur Verarbeitung bereits existierender XMLType-Instanzen in der Datenbank fort. Daher sind proprietäre Funktionen, wie extract, updatexml etc. sämtlich deprecated zugunsten der XQuery-Pendants XQuery, XMLTable, XMLExists etc. Das ist nicht immer im Sinne des Benutzers, insbesondere die Funktion updatexml war intuitiver zu benutzen als eine komplexe XQuery-Abfrage, aber so ist nun einmal die Entwicklung. Es scheint, als gehöre die Einarbeitung in XQuery nun zum Pflichtprogramm für XML-Entwickler, die auch mit der Oracle-Datenbank arbeiten.
Zur Erzeugung von XMLType-Instanzen aus relationalen Daten scheint Oracle den SQL/XML-Funktionen wie xmlelement, xmlattributes und xmlforest den Vorrang vor der objektorientierten Erzeugung mittels sys_xmlgen zu geben, die als deprecated eingestuft ist.
Zur Speicherung als XMLType-Instanz ist die Speicherung als CLOB zugunsten der Speicherung als BinaryXML abgelöst worden, die Indizierung kann, wie schon in Version 11g, lediglich durch den Domänenindex XMLIndex durchgeführt werden. Ausnahme bleibt die nach wie vor mögliche Speicherung in einer objektrelationalen Tabellenlandschaft. Doch scheint unter den aktuellen Voraussetzungen diese Speicherung ebenfalls seltener erforderlich zu sein, weil die Zugriffsgeschwindigkeit auf XML-Elemente durch den XMLIndex deutlich erhöht wurde.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Oracle & XML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © Rheinwerk Verlag, Bonn 2014, 2. Auflage
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Oracle PL/SQL: Das umfassende Handbuch" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, www.rheinwerk-verlag.de, service(at)rheinwerk-verlag.de