Start

Unternehmen

Buch-Katalog

Seminare

Leserservice

Comelio-Blog

Datenbanken SQL MS SQL Server Oracle Trigger Module Pakete SQLX SysXMLGen XDB: Sichten XDB: XML Schema XDB: XSLT XDB: XMLType XDB: Konzepte XDB: PL/SQL XML-Speicheransätze SQLJ PHP UML C#.NET XML Schema XSLT

Übersicht

Alle Seminare Info-Broschüre Anmeldeformular Hotels & Anfahrt AGB

Comelio GmbH
Rellinghauser Straße 10
D-45128 Essen
Deutschland
Fon: 0201-437517-0
Fax: 0201-437517-10
info@comelio.com

Comelio GmbH
Goethestraße 34
D-13086 Berlin
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Glockengießerwall 17
D-20095 Hamburg
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Mainzer Landstraße 27-31
D-60329 Frankfurt
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Stiglmaierplatz/Dachauer Str. 37
D-80335 München
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Liebknechtstr. 33
D-70565 Stuttgart
Deutschland
info@comelio.com

Comelio GmbH
Nevinghoff 16
D-48147 Münster
Deutschland

Comelio GmbH
Friedrich - List - Platz 1
D-04103 Leipzig
Deutschland

Comelio GmbH
St. Johanner Strasse 41-43
D-66111 Saarbrücken
Deutschland

Comelio GmbH
Kaiser-Wilhem-Ring 27–29
D-50672 Köln
Deutschland

Comelio GmbH
Münsterstraße 248
D-40470 Düsseldorf
Deutschland

Comelio GmbH
Fürther Strasse
D-90429 Nürnberg
Deutschland

Comelio GmbH

Bremen
Deutschland

Comelio-Blog > Oracle > XML-Speicheransätze

Oracle und XML - Speicheransätze

Neben der Verwendung der speziellen XML-Datenbank Oracle XDB existieren sowohl für Oracle als auch für andere Datenbanken traditionelle Speicheransätze für XML-Daten. Sie lassen sich unabhängig vom Datenbanksystem verwenden, wobei in diesem Artikel der Schwerpunkt auf Oracle liegt. Dieser Artikel soll die allgemeinen Prinzipien von XML-Speicherung ohne spezielle XML-Unterstützung skizzenhaft darlegen.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > Oracle > XML-Speicheransätze Freitext

Oracle XDB: Traditionelle Speicheransätze von XML in Oracle

Auch die Verwendung von XML ist in Oracle in mannigfaltiger Weise gelöst. Es bestehen nicht nur Möglichkeiten, aus relationalen oder objektrelationalen Daten XML-Daten zu erzeugen, sondern es sind auch Lösungen vorhanden, über unterschiedliche Wege XML in der Datenbank zu speichern. Neben traditionellen Ansätzen der XML-Speicherung bietet das Datenbanksystem darüber hinaus auch eine eigene XML-Datenbank, die ohne zusätzliche Installation zur Verfügung steht. Dieses Kapitel soll die Abfrage, Speicherung und Verarbeitung von XML-Daten mit Hilfe von Oracle anhand unterschiedlicher Werkzeuge erläutern. Die Darstellung der Möglichkeiten, die sich mit XML und insbesondere auch durch die Verwendung von XMLType ergeben, hat Ihnen sicherlich auch gezeigt, wie einfach die Arbeit mit diesen Techniken ist. Daher sollen die traditionellen Speicheransätze, mit denen vielleicht noch bis zur Version 8i gearbeitet wurde und über die in der Version 9i möglicherweise noch Diskussionsbedarf herrschte, nur skizziert werden. Ihr Einsatzbereich ist relativ beschränkt bzw. wurde auch schon sehr ausführlich anhand der Abfragen von relationalen Daten dargestellt, die nur für die Ergebnismenge in XML benötigt wurden.

Verwendung von relationalen Tabellen

Ein sehr einfacher Speicheransatz für XML-Daten besteht darin, sie überhaupt nicht in XML zu speichern, sondern die Daten vielmehr so aufzubereiten, dass sie doch letztendlich wieder in relationaler Form gespeichert werden können. Dies gelingt insbesondere bei datenorientierten Dokumenten, wie sie während des ganzen Kapitels verwendet wurden. Bei dokumentenorientierten Dokumenten, die beispielsweise auch gemischte Inhaltsmodelle aufweisen, ist dies keine Lösung.

Ein datenorientiertes Dokument wie z. B. die schon verwendete Terminliste stammt letztendlich aus einer SQLX-Abfrage und rekrutiert seine Daten daher auch aus relationalen Formen. Es bestünde zunächst keine Notwendigkeit diese Tabelle in XML-Daten zu speichern, um dann nachher über zwar einfache, aber im Vergleich zu SQL dennoch komplizierte Suchmethoden die geeigneten Termine zu selektieren.

Ist es also so, dass die Daten sich prinzipiell auch in relationaler Form wie in einer einzigen Tabelle, in zwei Tabellen mit einer 1:n-Beziehung oder auch in mehreren Tabellen speichern lassen und dass diese Daten nur für eine Abfrage in XML benötigt werden, dann ist der Ansatz, sie in relationaler Form zu speichern, sicherlich richtig. Durch die diversen Möglichkeiten, sie in SQL oder PL/SQL wieder in XML-Form zu transformieren, bedeutet noch lange keine Notwendigkeit, extra XMLType zu verwenden und die Daten direkt in XML-Form zu speichern.

Ein erster traditioneller Speicheransatz von XML besteht demnach also darin, die Daten überhaupt nicht in XML-Form, sondern in relationaler Form zu speichern. Dafür müssen sie lediglich eine Struktur aufweisen, die eine solche Speicherung ermöglicht. In vielen Fällen ist dies der Fall, und man käme auch nicht auf die Idee, es anders zu machen Die Erzeugung in XML über einfache Abfrage ist dann kein Problem.

Verwendung von relationalen Tabellen: Spalten für Eltern-Elemente

Besteht die Möglichkeit, die Daten relativ flach zu gestalten, sodass z. B. nur eine Ebene existiert (eine Kursliste mit allgemeinen Kursangaben und Terminen sowie Dozenten), die mehrere Eltern-Elemente von einfachen Elementen oder auch wieder Eltern-Elementen enthält, dann lassen sich auch solche Daten wie in einer relationalen Tabelle speichern. Die Eltern-Elemente der oberen Ebene wären dann durch ihre Spalten bestimmt und müssten nicht extra in XMLType vorliegen, sofern sie nur einfache Textwerte enthalten. Dies wäre bei einer Kursliste der Fall bei der Kursnummer, dem Titel und Untertitel und dem Bereich. Wären diese Informationen allerdings wieder Kind-Elemente eines Eltern-Elements mit allgemeinen Kursangaben, dann könnte man sie entweder in eine eigene Tabelle auslagern oder auch einen XMLType für die Spalte der allgemeinen Angaben verwenden und diese Daten direkt als XML speichern.

Das gesamte Dokument hingegen wird nicht als komplettes XML gespeichert, sondern vielmehr nur seine einzelnen Bestandteile, die sich aus den Eltern-Elementen auf der obersten Ebene ergeben. Dies hat den Vorteil, dass man sowohl XMLType verwenden kann als auch skalare Datentypen für entsprechend einfache Elemente. Dieses Vorgehen eignet sich auch für Elemente mit gemischten Inhaltsmodellen und könnte dafür sorgen, dass der gesamte Text einer längeren Kursbeschreibung in einer solchen Spalte liegt, während alle anderen Informationen in einer gewohnt einfachen Form in der Tabelle gespeichert sind.

Falls diese Textspalten ohnehin nicht ständig durchsucht werden oder sehr flexible Längen oder Strukturen haben, die sie für eine Speicherung in Spalten einer verknüpften anderen Tabelle ungeeignet machen, dann stellt dies eine interessante hybride Lösung dar.

Für sich wiederholende Elemente eignet sich also entweder eine andere verknüpfte Tabelle oder eine XMLType-Spalte, die auch flexible Inhalte (gemischte Inhaltsmodelle insbesondere) enthalten kann. Dieser Speicheransatz hat den Vorteil, dass man weiterhin komplette XML-Daten über die einfachen Abfragetechniken erzeugen kann. Darüber hinaus lassen sich allerdings auch verschachtelte und flexible Strukturen einfach in anderen Tabellen oder XMLType-Spalten speichern.

Verwendung von objektrelationalen Tabellen

Da für einige der vorgestellten Abfragetechniken ohnehin Objekttypen und Tabellentypen, die auf Objekttypen beruhen, benutzt werden, ergibt sich die Möglichkeit, die Datenstrukturen der Abfrage mit denen der Speicherung zu kombinieren. Für Eltern-Elemente, die einfache Kind-Elemente enthalten, eignen sich daher Spalten mit Objekttypen als Datentyp, weil so mehrere Felder mit Informationen unter einem gemeinsamen Namen erstellt werden können. Dagegen eignen sich Tabellentypen für Felder, die wiederholende Elemente speichern können. Diese können natürlich auch wieder mehrere Felder besitzen und daher auf Objekttypen aufgebaut sein.

Ein solcher Ansatz ist in Oracle zu realisieren, hat allerdings in vielen anderen Datenbanken keine exakte Entsprechung sodass Sie ihn nur dann verwenden sollten, wenn Sie genau wissen, dass Sie auf lange Sicht weder die Datenbank wechseln noch Ihre Daten mit anderen Datenbanken austauschen werden. Allerdings wäre der Austausch wiederum über XML zu realisieren, sodass von dieser Seite aus weniger Kritik geübt werden kann. Für einfache SQL-Abfragen auf solchermaßen aufgebaute Tabellen ergibt sich allerdings ein erheblicher Mehraufwand und eine komplizierte Syntax, sodass diese Art der Speicherung zwar für XML und eine einheitliche Datenstruktur über Objekt- und Tabellentypen Vorteile bietet, andere Bereiche einer Anwendung allerdings auch belastet.

Verwendung von Binärdaten

Eine letzte Alternative – neben den Kombinationsmöglichkeiten der vorgestellten Varianten – besteht aus der Verwendung von externen Dateien bzw. anderen Binärformaten. Dies ist grundsätzlich immer möglich, allerdings nicht sonderlich raffiniert. Verwendet man Binärdaten, die direkt in der Datenbank liegen, und hätte man stattdessen auch XMLType verwenden können, verschenkt man alle Möglichkeiten, die mit diesem Datentyp zusammenhängen. Für eine solche Variante würde man sich nur dann entscheiden, wenn man sowieso Binärdaten verwendet und keinen Wert darauf legt, die speziellen XML-Funktionen komplett auszuschöpfen. Daher sind alle Kriterien, die eine Entscheidung zugunsten von Binärdaten herbeiführen können, aus dem Umfeld der Binärdaten-Verwendung stammen, auch hier von Bedeutung.