Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Extensible Markup Language (XML)/XML-Datenbanken glänzen bei komplexen Dokumenten


08.02.2002 - 

Kein Patentrezept für die Speicherung

Anbieter von relationalen Datenbanken bewerben die XMLFähigkeit ihrer Produkte. Gleichzeitig sehen viele junge Unternehmen in ihren XML-Datenbanken das ideale Medium, um strukturierte Dokumente zu speichern. In der Praxis haben beide Recht: Die Wahl des richtigen XML-Speichers hängt primär von der Anwendung ab. Von Peter Fankhauser und Thomas Tesch*

Die Auszeichnungssprache XML hat in den vergangenen Jahren als Lingua Franca des Internet breite Akzeptanz in der Industrie gefunden. Dabei hat sich XML nicht nur in seiner angestammten Domäne des Dokumenten-Management durchgesetzt, sondern auch als Technologie für den Nachrichtenaustausch sowie als Datenmodell zur Integration heterogener Datenbestände vor allem für E-Business-Anwendungen. Die damit einhergehende Durchdringung von IT-Architekturen erfordert neue skalierbare Werkzeuge zur Speicherung und zum Durchsuchen von XML. Dabei kommt es nicht nur auf das Lesen eines gesamten XML-Dokuments aus einer Datenbank an, sondern auch auf die effiziente Abfrage von Teilen eines Dokuments, die dann weiterverarbeitet werden.

Anforderungen an XML-DatenbankenFür die richtige Speicherung eines XML-Dokuments gibt es kein Patentrezept. Dies hängt sowohl vom konkreten Anwendungsfall als auch von der Beschaffenheit des Dokuments selbst ab. Datenorientierte XML-Dokumente folgen eher dem relationalen Paradigma, indem sie sehr flach und regelmäßig strukturiert sind. Zudem kann dort die Reihenfolge der Elemente meistens vernachlässigt werden. Die Textknoten eines datenorientierten Dokuments lassen sich in der Regel eindeutig einzelnen Datentypen wie Integer oder String zuordnen. Typische Vertreter für datenorientiertes XML sind elektronische Produktkataloge nach dem BMEcat-Standard.

Im Gegensatz dazu nutzt dokumentenorientiertes XML alle Fähigkeiten dieser Auszeichnungssprache aus. Dokumente sind tiefer und unregelmäßiger strukturiert, ferner ist die Reihenfolge der Elemente bei der Verarbeitung zu berücksichtigen. Auch gemischte Inhalte, bestehend aus Text und weiterem Markup (mixed content), werden genutzt. Beispiele sind Web-Inhalte und technische Dokumentationen.

Neben diesen unterschiedlichen Dokumentklassen spielen auch die Anwendungsanforderungen bei der Suche nach der besten Speichermethode eine wesentliche Rolle. Hier ist wichtig, ob feingranulare Zugriffe auf die Dokumentenstruktur nötig sind oder Dokumente nur im Ganzen gelesen und geschrieben werden. Ebenfalls zu berücksichtigen sind die zu erwartenden Anfragen: Werden vorwiegend bestimmte Muster in der Struktur eines Dokuments gesucht, oder sind die Anfragen eher inhaltsorientiert über das gesamte Dokument? Weitere wichtige Parameter bei der Auswahl der Speichermethode sind die Unterstützung von Dokumentenkollektionen sowie Transaktionseigenschaften wie Mehrbenutzerzugriff und Atomarität.

Zwei Standardisierungsbestrebungen des W3-Consortiums (W3C) sind für XML-Datenbanken besonders relevant: XML Schema und XQuery. Beide Standards versuchen, den Anforderungen der dokumentorientierten und der datenorientierten Sicht gleichermaßen gerecht zu werden.

XML Schema wurde im Mai 2001 als W3C-Empfehlung verabschiedet. Es erweitert Document Type Definitions (DTDs) um differenzierte Datentypen (wie "date", "double", "string") und unterstützt die Definition von wiederverwendbaren, benutzerdefinierten Datentypen und Datenstrukturen. Es erlaubt aber auch beliebig tief geschachtelte, unregelmäßige Strukturen.

XQuery wurde im Februar 2001 zum erstenmal als Arbeitsversion veröffentlicht. Der aktuelle, wesentlich stabilere Entwurf stammt vom Dezember 2001. XQuery nutzt XPath zur Auswahl von Dokumentfragmenten und erweitert XPath um SQL-artige Konstrukte für die Kombination und Restrukturierung von Dokumentfragmenten. Zur Darstellung von XML-Anfrageresultaten nutzt XQuery konsequenterweise XML selbst. Darüber hinaus definiert XQuery die notwendigen Funktionen und Operatoren für alle eingebauten Datentypen von XML Schema.

Eine naheliegende Möglichkeit zur Speicherung von XML ist der Einsatz relationaler Datenbanken (RDBMS). In diese Technolgie haben die meisten Unternehmen in der Vergangenheit investiert. Die Erfahrungen mit den Produkten sind überwiegend positiv und es sind zumeist schon geschulte Mitarbeiter und Administratoren vorhanden.

Elementare UnverträglichkeitenBei der XML-Verarbeitung mit RDBMS sind zwei Fälle zu unterscheiden: Sollen aus bestehenden Daten lediglich XML-Dokumente generiert oder beliebige XML-Dokumente im System abgelegt werden? Der erste Fall ist relativ einfach mit ein wenig Anwendungsprogrammierung und SQL lösbar. Die Speicherung beliebiger XML-Dokumente stellt die Systeme jedoch noch vor größere Probleme. Um XML in relationalen Systemen abzulegen, muss das baumorientierte Datenmodell von XML möglichst vollständig und verlustfrei in das mengen- beziehungsweise tabellenorientierte Modell relationaler Datenbanken abgebildet werden. Eine solche Abbildung hat auch die XML-Spezifika wie Attribute, die Reihenfolge der Elemente, gemischte Inhaltsmodelle sowie Processing Instructions und Kommentare zu berücksichtigen. Aufgrund dieser elementaren Unverträglichkeit ist eine generische Abbildung nicht zu vernünftigen Bedingungen möglich.

Die heute von den Anbietern favorisierte Lösung ist das Erstellen einer Abbildungsvorschrift für XML-Dokumente, die einem gegebenen Dokumententyp (DTD) gehorchen. Dabei wird festgelegt, welche Elemente und Attribute in welchen relationalen Tabellen abgelegt werden. Aber auch diese Lösungen können nur mit erhöhtem Aufwand gemischte Inhaltsmodelle, Processing Instructions und Kommentare verarbeiten. Hauptproblem aus Anwendungssicht ist indes das Fehlen adäquater Abfragemöglichkeiten auf XML-Ebene. Die Unverträglichkeit der Datenmodelle führt letztlich zu Mehraufwand bei der Anwendungsentwicklung, da diese nur durch Rückgriff auf die Abbildungsvorschrift und relationaler SQL-Abfragetechnik auf die XML-Daten zugreifen kann.

Viel Aufwand trotz HilfskonstrukteGerade für XML-typische Abfragen, die die Dokumentenstruktur ausnutzen, führen zu vermehrten Join-Operationen, der bekanntermaßen teuersten SQL-Operation. Auch inhaltsorientierte Abfragen können bei textlastigen XML-Dokumenten ohne zusätzlichen Volltextindex zur Geduldsprobe werden. Sie können leicht einen aufwändigen Scan gesamter Tabellen auslösen. Die Nachteile der Zerlegung in relationale Tabellen machen sich am stärksten bei der Rekonstruktion des ursprünglichen XML-Dokuments bemerkbar, da hier die Ursprungsreihenfolge über mehrstufige Join- und Sortier-Operationen reproduziert werden muss. Daher empfielt sich oftmals die zusätzliche Ablage des gesamten Dokuments als Volltext in einem eigens dafür vorgesehenen CLOB-Feld.

Alle Hersteller relationaler DBMS bieten Erweiterungen zur Speicherung von XML in ihren Systemen an. Darüber hinaus gibt es eine wachsende Zahl von Middleware-Anbietern, die herstellerunabhängige Lösungen zur XML-Speicherung entwickelt haben. Diese bieten auch Werkzeuge zur Erstellung datenbankübergreifender XML-Sichten an. Aber auch ohne diese Werkzeuge lässt sich XML, wie skizziert, in einem relationalen System verarbeiten. In beiden Fällen sollte ein Lösungentwickler immer bedenken, dass er den beschriebenen methodischen Einschränkungen unterliegt. Bei der Verarbeitung von datenorientierten XML fallen diese Nachteile am wenigsten ins Gewicht: Die Abbildung ist aufgrund der flachen Dokumentenstruktur einfach, die Reihenfolge spielt eine untergeordnete Rolle, und auf Stilelemente wie gemischter Inhalt oder Processing Instructions kann verzichtet werden.

Um die Schwächen relationaler Systeme beim Umgang mit XML zu überwinden, haben sich im vergangenen Jahr native XML-Datenbanken am Markt etabliert. Diese Systeme setzen auf durchgängige XML-Architekturen und die direkte Unterstützung von etablierten XML-Standards, um die problematischen Brüche im Datenmodell zu vermeiden. Dabei kommen je nach Produkt eigens für XML geschaffene Abfragesprachen wie XPath, XQL oder XQuery zum Einsatz. Typisch für diese Systeme ist auch die konsequente Ausnutzung von Web-Standards wie HTTP.

Eine abgestimmte UmgebungNative XML-Datenbanken speichern XML in speziell auf seine Eigenschaften ausgerichteten Index- und Speicherungsstrukturen. Daraus ergibt sich eine wesentlich bessere und effizientere Unterstützung von XML-Eigenheiten wie Dokumentreihenfolge sowie rekursiver und gemischter Inhaltsmodelle. Einige Systeme wie "Infonyte-DB" (siehe Kasten) kommen sogar völlig ohne zusätzliche Schemainformationen aus und können ohne weitere Hilfsmittel wohlgeformte XML-Dokumente verarbeiten. Dies ist besonders bei Anwendungen mit stark divergierenden und/oder tief geschachtelten Datenstrukturen unabdingbar. Je nach Anwendungsfall ist die Nutzung verschiedener Abfragesprachen möglich. Der mittlerweile weit verbreitete Xpath-Standard des W3C erlaubt, unter Ausnutzung der Dokumentenstruktur und Beachtung der Reihenfolge, die Selektion einzelner Teile eines Dokuments. Der kurz vor der Verabschiedung stehende Xquery-Standard bietet auf Xpath-Basis auch Unterstützung für Datentypen sowie den gezielten Aufbau von Ergebnisdokumenten. Als Programmier-Schnittstelle hat sich das Document Object Model (DOM) des W3C durchgesetzt.

Standards noch nicht durchgängigUneinigkeit herrscht dort, wo die Standardisierung noch nicht weit genug fortgeschritten ist. So müssen die verfügbaren Systeme bei der Unterstützung von Dokumentenkollektionen noch auf proprietäre Erweiterungen setzen. Es mangelt ebenfalls an einer deklarativen Update-Sprache. Hier sollen die nächsten Versionen der genannten Standards bald Abhilfe schaffen.

Native XML-Datenbanken sind eine viel versprechende junge Technologie. Die existierenden Lösungen unterscheiden sich sowohl vom Funktionsumfang als auch in puncto Skalierbarkeit und Robustheit noch stark voneinander. Getrieben durch verschiedene Anforderungen zur Verarbeitung von dokumentenorientierten XML (Electronic Books versus Content Management System) wird sich der Markt für native XML-Datenbanken in den nächsten 24 Monaten diversifizieren. Entscheidend für den Erfolg der Systeme wird auch die Nutzung gemeinsamer Standards wie XML Schema und XQuery sein, um Anwendern Investitionssicherheit zu geben. (ws)

*Peter Fankhauser ist Leiter des XML-Kompetenzzentrums des Fraunhofer-IPSI in Darmstadt, Thomas Tesch ist Geschäftsführer der Infonyte GmbH in Darmstadt.

OrientierungAngesichts der zunehmenden Verbreitung von XML stellt sich für viele Anwender die Frage, wie derartige Daten am besten zu speichern sind. Relationale Datenbanken (RDBMS) bieten den Vorteil, dass sie in den meisten Unternehmen schon vorhanden sind und IT-Mitarbeiter über entsprechendes Know-how verfügen. Die Autoren vertreten die These, dass sich RDBMS vornehmlich für datenorientierte Umgebungen eignen, während XML-Datenbanken besonders im Dokumentenumfeld ihre Stärken ausspielen können. Zugute kommt ihnen dabei die Umsetzung von wesentlichen Standards wie DOM, Xpath und zukünftig Xquery.

Infonyte-DBDie Infonyte GmbH mit Sitz in Darmstadt ist ein Startup des Fraunhofer-Instituts für Integrierte Publikations- und Informationssysteme. Infonyte entwickelt und vermarktet das native XML-Datenbanksystem Infonyte-DB. Das System vermeidet die Schwächen herkömmlicher Datenbanktechnologie wie hohe Systemanforderungen und Wartungskosten. Aufgrund seiner schlanken, völlig in Java gehaltenen Implementierung ist es auf allen gängigen Plattformen vom Handheld bis zum Server-System einsetzbar. Infonyte-DB basiert auf einer persistenten Implementierung des W3C-DOM-API sowie einem Web-fähigen Anfrageprozessor, der alle gängigen XML-Anfrage- und -Transformationssprachen unterstützt.

Abb: Typische XML-Datenbankarchitektur

Beispiel Infonyte-DB: Zur Anwendungsseite hin wird die Unterstützung von Abfragestandards wie XPath oder künftig Xquery erwartet. Quelle: Fankhauser/Tesch