Nun ist auch die Datenwelt keine flache Scheibe mehr, nicht mehr schachbrettartig gegliedert in Spalten und Reihen, die Werte bergen, welche sich zueinander in Beziehungen setzen lassen. Neben dieses flache relationale Modell ist ein dreidimensionales getreten. Im Internet werden Dokumente bewegt, die nicht nur aus Buchstaben und Zahlen bestehen, sondern andere Datentypen für Bilder, Videos oder Musik bis hin zu kompletten Anwendungen umfassen, die auch noch in mehreren Ebenen baumartig (Tree) miteinander und mit anderen Dokumenten verknüpft sind. Die Grundlage dieser komplexen Dokumente, die man auch als Sammlung von Dateien ansehen könnte, ist die Metasprache XML.
Kritische Distanz: Die Grundlage des nebenstehenden Beitrags bildet die vor einem Monat erschienene Studie „Database Management Systems - Managing Relational and XML Data Structures“ von der Butler Group. In der 241 Seiten umfassenden Untersuchung schneiden die relationalen Datenbanken von Oracle, IBM und - mit geringen Abstrichen - Microsoft besonders gut ab. Daher ist zu erwarten, dass die Studie von diesen Herstellern zu Marketing-Zwecken ausgeschlachtet wird. Davor sei gewarnt.
Denn die Butler-Studie weist erhebliche Defizite auf: Sie listet nur die technischen Features von Datenbanksytemen auf, ohne zu hinterfragen, ob bestimmte Features performant arbeiten oder überhaupt notwendig sind. Letzteres führt zu Verzerrungen, da die Studie für Features Punkte unabhängig davon vergibt, um welchen Typ von Datenbank es sich handelt. So steht eine native XML-Datenbank wie Tamino im direkten Vergleich mit IBMs DB2 und Oracle 9i - und schneidet prompt schlecht ab, weil dem Produkt der Software AG relationale Features fehlen. Ein Vergleich von Äpfel und Birnen, weil Tamino nach seinem technischen Konzept nicht gegen, sondern ergänzend zu relationalen Systemen positioniert ist.
Auch die XML-bezogenen Checkpunkte der Studie sind nicht immer nachvollziehbar. So wird auf Entity-Start- und -End-Marker Wert gelegt, nicht aber auf die Unterstützung verschiedener Abfragesprachen und APIs. Diese Aspekte kommen nur in den Erläuterungen zu den einzelnen Produkten zur Sprache, werden dort aber nicht gleichermaßen beleuchtet. In einigen Punkten bestehen eklatante Widersprüche zu vorherigen Aussagen.
Aus solchen Gründen könnte sich der Blick in eine Studie lohnen, die zum gleichen Thema das US-amerikanische Unternehmen Zapthink herausgebracht hat: „XML Data Storage Technologies and Trends - Native XML Data Stores (NXDs) and XML Extensions to RDBMS“. Da sie im März dieses Jahres erschienen ist, ist sie im Falle Oracle 9i nicht auf dem aktuellen Release-Stand 2.
Zunächst schien es unausweichlich, dass es für die neuen Datentypen entsprechender spezieller Methoden zu ihrer Speicherung und Analyse bedürfe, nämlich nativer XML-Datenbanken. Unter den diversen Angeboten ist „Tamino“ das weltweit mit Abstand erfolgreichste Produkt. Und dem Anbieter, der Darmstädter Software AG, verspricht es rosige Zeiten. Das Marktforschungsunternehmen IDC rechnet für das Segment der XML-Datenbanken mit jährlich rund 130 Prozent Wachstum und einem Marktvolumen von rund 700 Millionen Dollar im Jahr 2004. IDC-Analyst Anthony Picardi sah bereits zwei parallele Datenbankwelten entstehen: „XML-Datenbanken werden die relationalen ergänzen. Erstere eignen sich besser für die Speicherung von Dokumenten und Letztere für Texte und Zahlen.“
Doch die neuen Marktchancen wollten sich auch die Anbieter von relationalen Datenbanken nicht entgehen lassen. Schon 1999 stellten IBM und Oracle erstmals Zusatzfunktionen beziehungsweise Versionen ihrer Produkte vor, die - wenn auch noch arg begrenzt - XML-Dokumente speichern konnten. Das zugkräftige Argument der Branchengrößen lautet seither: Es ist ökonomischer, alles in einer Datenbank zu haben, als zwei Systeme nebeneinander pflegen, aufeinander abstimmen und miteinander integrieren zu müssen. Außerdem böten sich die relationalen Datenbank-Management-Systeme (RDBMS) als verlässliche und skalierbare Speicher für Informationen an, während die Dokumente nicht mehr seien als ein Präsentationsformat.
Diese oberflächliche Sichtweise hat sich geändert. In allen Verlautbarungen der RDBMS-Anbieter dieses Jahres stehen nicht funktionale Optimierungen ihrer relationalen Systeme im Vordergrund, sondern deren - angeblich bis zur Perfektion - verbesserten XML-Fähigkeiten. Im Prinzip aber hat sich nicht viel geändert: XML-Dokumente werden zwar als neue Datentypen angesehen, die sich ansonsten aber wie relationale Daten oder Objekte behandeln lassen. Wie das geschieht, stellt eine Untersuchung der Butler Group „Database Management Systems - Managing Relational and XML Data Structures“ dar. Auf dieser Analyse basiert weitgehend die folgende Zusammenfassung. Sie konzentriert sich dabei auf die am weitesten fortgeschrittenen XML-Integrationsansätze in IBMs DB2-Version 7 mit dem Zusatz „XML-Extender“, Oracle 9i und Microsofts SQL Server 2000.
Große Objekte in flachen Tabellen
Die einfachste Methode, ein XML-Dokument in eine relationale Datenbank zu übernehmen, besteht darin, es komplett als „Character Large Object“ (Clob) oder „Binary Large Object“ (Blob) in deren Tabellenstruktur abzubilden. Dabei lassen sich die Zusatzinformationen eines Dokuments, etwa die Definition seines Layouts, noch separat ablegen, um Such- und Sortieroperationen nicht zu aufwändig zu gestalten.
Sowohl Oracle als auch IBM und Microsoft verwenden diese Technik, wenn auch in unterschiedlicher Ausprägung, denn sie hat Nachteile: Ein Update der Dokumente, beispielsweise von „Straße/Nummer“, „Postleitzahl“ und „Ort“, richtet sich nicht gezielt auf diese Einzelelemente, sondern verlangt den Aufruf des gesamten Dokuments. Das senkt den Datendurchsatz deutlich. Noch mehr Zeit kostet es, wenn es um ein Update komplexerer Dokumente geht. Deren Strukturen bilden relationale Datenbanken über „Joins“ nach, was noch mehr Zeit kostet.
Dem Problem lässt sich dadurch begegnen, dass man das XML-Dokument mehr oder minder zerlegt, um es in seinen Einzelteilen bearbeiten zu können. Anhand der „Document Type Definitions“ (DTDs) oder seiner „Tags“ ist es möglich, ein Dokument zu „schreddern“ und in ein relationales System aus Spalten und Zeilen einzupassen. Allerdings hat dieses Verfahren den Nachteil, speicherfressend zu sein.
Im Datenschredder zerlegt
IBM verwendet zur Übertragung der XML-Dokumente auf DB2 (und umgekehrt zu ihrer Wiederherstellung) den kostenlosen Datenbankzusatz XML-Extender als zwischengeschaltete Instanz. Die DTDs werden durch IBMs proprietäre „Data Access Definition“ (DAD) übersetzt, die auf Elemente in relationalen Tabellen weisen. Die Dokumente lassen sich dabei komplett als Clob, nach Typen fragmentiert oder als Einzelelemente („shredded“) ablegen.
In dieser unterschiedlichen Granularität kann auch Microsofts SQL Server 2000 XML-Dokumente speichern. Die Lösung hat hier den Namen „XML for SQL Server“, abgekürzt „XMLSQL“. Es handelt sich dabei um ein „Feature Pack“ zum SQL Server 2000, das zum kostenlosen Download zur Verfügung steht. Microsoft geht XML nicht so sehr unter dem Aspekt einer Erweiterung der Datenbank an, sondern hält die Integration eher für eine Frage der Middleware. „Unser Ziel ist der Zugang zu Informationen, unabhängig davon, wo sie sich befinden“, erklärt Tom Rizzo, für SQL Server zuständiger Microsoft-Manager. Es ist auffällig, dass der Microsoft-Ansatz im Gegensatz zu IBM und Oracle XML-Syntax wie „Processing Instruction Information“ über in den Dokumenten integrierte Programme oder „Namespace
Declarations“ nicht unterstützt.
Oracle behandelt XML-Dokumente als eigenen Datentyp „XML-Type“, der vorzugsweise als Clob gespeichert wird. In der Datenbank finden sich neben den Dokumenten separat abgelegte Attribute und XML-Schemata. Letztere haben gegenüber den DTDs den Vorteil, Datentypen wie Datum und Zeit kennzeichnen zu können, was die Bearbeitung von Dokumenten erleichtert.
IBM und Oracle unterstützen in ihren Lösungen die wichtigsten Schnittstellen DOM und SAX zur Programmierung von Anwendungen (APIs). Das Document Object Model ermöglichst es Anwendungen, die Strukturen von Dokumenten zu durchsuchen und ihre Elemente zu bearbeiten. Über die „Simple API for XML“ (SAX) lassen sich Parser-Prozesse anstoßen. Nach Auskunft der Butler-Studie ist nicht klar, ob Microsofts Ansatz solche nativen XML-APIs nutzen kann.
Links:
In Sachen Abfragesprachen stimmen die drei Produkte überein. Die klassische Abfragesprache für relationale Datenbanken, SQL, eignet sich nicht für hierarchische XML-Dokumente - jedenfalls solange diese nicht zuvor auf das zweidimensionale System heruntergebrochen sind. Ein Lösungsansatz ist die Erweiterung „SQLX“.
Query-Sprachen weiterentwickeln
Der ursprüngliche Query-Standard XQL ist inzwischen überholt. Sein von der Standardisierungsorganisation W3C empfohlener Nachfolger, „Xpath“, wird von Oracle, Microsoft und IBM unterstützt. Xpath macht es nicht nur möglich, den Inhalt eines Dokuments zu durchforsten, sondern funktioniert auch in der tieferen logischen Struktur (Tree) eines Dokuments und kann so auch mit dessen Teilen oder Elementen operieren.
Die viel weitergehende Abfragesprache „Xquery“ verwenden nur native XML-Datenbanken wie Tamino. Sie umfassst auch die wichtigsten Funktionen anderer Query-Systeme wie XML-QL, XQL, OQL und sogar SQL. Xquery war ursprünglich eine von der Software AG entwickelte proprietäre Abfragesprache. Inzwischen liegt sie mit Unterstützung von IBM dem W3C als Vorschlag zur Standardisierung vor. IBM hat angekündigt, in (unbestimmter) Zukunft Xquery zu unterstützen, während Oracle bisher dieser Technik als nicht hinreichend performant ablehnend gegenübersteht.
Oracle will sich künftig vor allem darauf verlegen, XML noch tiefer als bisher in den Kernel seiner Datenbank zu integrieren. Mit dem Release 2 von Oracle 9i sind die ersten Schritte dazu getan. So ist es möglich, Xpath-Queries mit SQL-Ausdrücken zu mischen. Nach Ansicht von Oracle ist ein dualer Datenbank-Kernel die beste Methode, um der eigenen Maxime „Eine Datenbank statt Datenredundanzen“ zu entsprechen.
Eine Datenbank oder viele?
Bei IBM heißt die XML-Zukunft „Xperanto“. Die Projektgruppe verfolgt einen externen Ansatz. Sie arbeitet an einem Middleware-Framework, das eines Tages den DB2-Zusatz Extender ersetzen könnte. In die wahrscheinlich im November dieses Jahres erscheinende Version 8 von DB2 wird es aber noch nicht eingehen. Xperanto basiert auf Xquery und soll es möglich machen, sowohl strukturierte als auch unstrukturierte Daten zu erfassen und zu bearbeiten. Daten aus relationalen Systemen lassen sich in XML-Ansichten darstellen sowie mit Web-Services und Textsuche verbinden. Die Kernstrategie von IBM besteht darin, es bei heterogenen Datenhaltungssystemen zu belassen, sie aber über die Xperanto-Middleware zu verbinden, um Datenredundanzen zu vermeiden.
Microsoft arbeitet unter dem Titel „Yukon“ an der nächsten Generation des SQL Server 2000. Die Fertigstellung ist grob für 2004 angekündigt, nach einer Betaversion im kommenden Jahr. Künftig soll es unter anderem nicht mehr nötig sein, XML-Daten zunächst zu konvertieren, bevor sie in SQL-Server-basierenden Applikationen Verwendung finden können. Strategisch folgt Microsoft der Oracle-Maxime, dass strukturierte und unstrukturierte Daten in einem einzigen Datenhaltungssystem vereint sein sollten.