XML in relationalen Datenbanken [original]

The increasing im-

portance of XML also

induces the vendors

of relational database

systems to provide

adequate interfaces.

On the one hand, it

should be possible to

retrieve relational

data in XML format;

on the other hand, it is

also advantageous if

XML data can be dir-

ectly saved in the

database. The present

article describes

several approaches

and gives insights into current implementations.

Categories and subject descriptors:

H.2.3 [Database Management]: Languages ±

SQL; H.2.4 [Database Management]: Systems ± re-

lational databases, textual databases; I.7.2 [Docu-

ment and Text Processing]: Document Preparation ±

XML

1 Einleitung

Relationale Datenbanksysteme

haben sich im Laufe der ver-

gangenen zwanzig Jahre zur beherrschenden Tech-

nologie für die Speicherung und Verwaltung von

Daten entwickelt. Dieser Erfolg beruht nicht zuletzt

auf der herstellerunabhängigen Anfragesprache

SQL, die die Abfrage und Manipulation der in den

Datenbanktabellen gespeicherten Daten erlaubt.

SQL wird bereits seit 1986 von amerikanischen

(ANSI) und internationalen (ISO) Standardisie-

rungsgremien normiert und liegt nun in der aktuel-

len Version SQL:1999 vor. Mit dieser Version wurden

der Sprache eine Reihe von objektorientierten Ei-

genschaften wie benutzerdefinierte Typen und Me-

thoden, Vererbung und Objektidentität hinzugefügt.

Systeme, die solche Merkmale implementieren,

werden oft als ¹objekt-relationalª bezeichnet.

Eine Erfolgsstory ganz anderer Art feierte in den

letzten fünf Jahrendie Auszeichnungssprache XML.

Als Nachfolgerin von HTML entwickelt sie sich im-

mer mehr zum Standard für die Darstellung von In-

halten im Internet. Ihre Erweiterbarkeit und Platt-

formunabhängigkeit prädestinieren sie als Sprache

für den Datenaustausch in beliebigen Anwendungs-

gebieten. XMLwurde vom W3C (World Wide Web

Consortium) entwickeltund liegt seit 1998 in der Ver-

sion 1.0 vor (als Empfehlung des W3C). Obwohl noch

jung an Jahren, hat sie sich ± ähnlich wie die Pro-

grammierspracheJava±imZugedesInternet-Booms

bereits zu einer etablierten Technologie entwickelt.

Wegen ihrer immensen Bedeutung und Ver-

breitung treffen relationale Datenbanksysteme und

XML in der Praxis oft aufeinander. Riesige Mengen

von Unternehmensdaten sind in

relationalen Datenbanken ge-

speichert und müssen zur Dar-

stellung und Übermittlung im

Internet ins XML-Format umge-

wandelt werden. Andererseits gibt es schon groûe

Mengen von XML-basierten Dokumenten, die nun

in relationalen Datenbanken gespeichert und ver-

waltet werden sollen. Obwohl schon etliche Spezial-

lösungen zur Speiche-

rung von XML-Daten

existieren, wie z.B. Do-

kumentmanagementsy-

Informatik_Spektrum_24_Dezember_2001 357

XML in relationalen Datenbanken

Jost Enderle

Universität Ulm, Abt. Datenbanken und Informationssysteme,

D-89069 Ulm

E-Mail: [email protected]m.de

}HAUPTBEITRAG / XML IN RELATIONALEN DATENBANKEN

Die zunehmende Bedeu-

tung von XML zwingt auch

die Hersteller relationaler

Datenbanksysteme zur Be-

reitstellung entsprechen-

der Schnittstellen. Einer-

seits sollte es möglich sein,

relationale Daten im XML-

Format auszugeben; ande-

rerseits ist es auch von Vor-

teil, wenn XML-Daten

direkt im Datenbanksystem

gespeichert werden kön-

nen. Der vorliegende Arti-

kel beschreibt verschiedene

Ansätze und gibt Einblicke

in aktuelle Implementie-

rungen.

XML ± Relationale Datenban-

ken ± Textdatenbanken ± SQL

steme und spezielle XML-Datenbanken, kommt

deren Einsatz oft nicht in Betracht, da die in XML

darzustellenden Daten weiterhin in relationalen

Systemen verwaltet werden oder schon bestehen-

de XML-Daten zusammen mit anderen (relatio-

nalen) Daten verwendet und abgefragt werden

sollen.

In Abschnitt 2 wird zunächst eine kurze Ein-

führung zu XML gegeben. Anschlieûend werden in

den Abschnitten 3 und 4 allgemeine Konzepte zur

Speicherung und Ausgabe von XML-Daten in rela-

tionalen Systemen betrachtet. Abschnitt 5 behandelt

den SQL/XML-Ansatz des SQL-Komitees der ISO.

Lösungen verschiedener Hersteller werden dann in

Abschnitt 6 näher beleuchtet.

2 XML ± eine Einführung

XML (eXtensible Markup Language) [8] ist eine

vereinfachte Untermenge von SGML (Standard Ge-

neralized Markup Language), einem textbasierten

Datenformat für strukturierte Dokumente. Sie ist

wie HTML (HyperText Markup Language) eine

Auszeichnungssprache, die die Kennzeichnung ein-

zelner Dokumentbestandteile mit sog. Tags erlaubt.

Während HTML jedoch nur einen festen Satz von

Tags besitzt (die im Wesentlichen der Formatierung

von Text dienen), lassen sich in XML vom Benutzer

neue Tags definieren. Diese werden dann im Allge-

meinen nicht zur Formatierung eingesetzt (dies ge-

schieht in XML separat durch sog. Stylesheets),

sondern dienen der Anreicherung des Textes mit

Metainformationen.

Beispiel:

<Leute>

<Mail>[email protected]</Mail>

</Person>

<Name>Berta</Name>

<Mail>[email protected]om</Mail>

</Person>

</Leute>

Dieses XML-Fragment enthält einige Informationen

(Name, Alter, Mail-Adresse, Muttersprache) über

zwei Personen (Alex und Berta). Wie man sieht, gibt

es zu jedem Tag (. . .) auch ein End-Tag (. . .) Der

von einem Tag und einem zugehörigen End-Tag

eingeschlossene Inhalt wird als Element bezeichnet.

Elemente können (eingeschachtelte) Subelemente

besitzen; es ergibt sich somit eine hierarchische

Dokumentstruktur. Neben Elementen gibt es auch

Attribute (hier: ¹Spracheª), die direkt in ein (Start-)

Tag integriert werden. Die Entscheidung, ob Infor-

mationen als Elemente oder Attribute modelliert

werden sollen, ist nicht immer eindeutig (¹Spracheª

hätte hier auch als Element modelliert werden kön-

nen). Während Elemente auch Subelemente besitzen

können, sind Attribute stets atomar.

XML ist gleichzeitig auch eine Metasprache, mit

deren Hilfe sich andere Auszeichnungssprachen für

spezielle Anwendungszwecke definieren lassen. Von

dieser Möglichkeit wird in der Praxis auch reger

Gebrauch gemacht, wie die groûe Zahl der mit Hilfe

von XML definierten Sprachen beweist:

· CML (Chemical Markup Language)

· MathML (Mathematical Markup Language)

· BSML (Bioinformatic Sequence Markup Language)

· AIML (Astronomical Instrument Markup Language)

· cXML (CommerceXML)

· XFDL (Extensible Forms Description Language)

· XUL (User Interface Language)

· BML (Bean Markup Language)

· CPML (Call Policy Markup Language)

·...

Die Struktur solcher Sprachen lässt sich mit Hilfe

von DTDs (Document Type Definitions) festlegen,

die die Menge der zulässigen Tags definieren und

festlegen, wie diese auf den Text angewandt werden

können.

Beispiel: Eine mögliche DTD für das obige XML-

Fragment

<!DOCTYPE Leute [

<!ELEMENT Leute (Person*)>

<!ELEMENT Person (Name, Alter,Mail)>

<!ATTLIST Person Sprache CDATA

#REQUIRED>

<!ELEMENT Name (#PCDATA)>

<!ELEMENT Alter (#PCDATA)>

<!ELEMENT Mail (#PCDATA)>

358 Informatik_Spektrum_24_Dezember_2001

{XML IN RELATIONALEN DATENBANKEN

Hinter dem Schlüsselwort DOCTYPE muss das

Wurzelelement des Dokuments angegeben werden

(in diesem Fall ¹Leuteª). Der Stern (*) ist eine Kar-

dinalitätsangabe und bedeutet ¹keinmal oder belie-

big oftª. Das Element ¹Leuteª enthält also beliebig

viele (oder keine) Subelemente des Typs ¹Personª.

Weitere mögliche Kardinalitätsangaben sind ¹ + ª

(einmal oder beliebig oft) und ¹?ª (keinmal oder

einmal). ¹Personª besitzt wiederum die drei Sub-

elemente ¹Nameª, ¹Alterª und ¹Mailª, und das ge-

nau in dieser Reihenfolge. ¹Personª besitzt ebenfalls

ein Attribut ¹Spracheª, dessen Typ ¹CDATAª (Cha-

racter DATA, d.h. beliebiger Text) ist und auf jeden

Fall angegeben werden muss (#REQUIRED; Alter-

native wäre #IMPLIED, d.h. optional). ¹Nameª, ¹Al-

terª und ¹Mailª sind jeweils vom Typ ¹PCDATAª

(Parsed Character DATA, d.h. Text, der keine Tags

mehr enthält). In DTDs gibt es keine verschiedenen

Datentypen für (Blatt-)Elemente, alles ist Text.

Vor kurzem wurde vom W3C ein Nachfolge-

standard für DTDs namens ¹XML Schemaª definiert

[25, 26, 27] (Tabelle 1). Wesentliche Kennzeichen von

XML Schema (gegenüber DTDs) sind die XML-Syn-

tax (d.h. ein XML-Schema ist auch ein XML-Doku-

ment) und die Einführung von Datentypen (auch

benutzerdefinierte). Auf XML Schema wird an die-

ser Stelle nicht näher eingegangen.

3 Speicherung von XML-Daten

in relationalen Datenbanken

Viele Hersteller relationaler Datenbanken unter-

stützen heute schon die Speicherung von XML-Da-

ten in ihren Systemen. Im Allgemeinen werden da-

bei zwei verschiedene Ansätze verfolgt. Beim ersten

Ansatz erfolgt die Speicherung des gesamten XML-

Dokuments als CLOB (Character Large Object) in

einer Tabellenspalte. Dieser Ansatz lässt sich zwar

einfach realisieren, bietet jedoch nur eingeschränkte

Funktionalität bzw. Effizienz, wenn auf einzelne

Teile der XML-Daten zugegriffen werden soll. Da

das Datenbanksystem nicht über die innere Struktur

des XML-Dokuments Bescheid weiû, müssen ent-

sprechende Funktionen bereitgestellt werden, die

einen Zugriff auf einzelne Teile des Dokuments er-

möglichen.

Beim zweiten Ansatz werden die zu spei-

chernden XML-Dokumente zunächst strukturell

analysiert und dann die im XML-Dokument ent-

haltenen Daten in relationaler Form in einer oder

mehreren Tabellen abgespeichert. Dabei werden

z.B. Blattelemente des XML-Dokuments auf ent-

sprechende Spalten abgebildet und hierarchische

Strukturen auf entsprechende Tabellen, die über

Primär- und Fremdschlüssel miteinander ver-

knüpft werden. Dazu muss eine feste Abbildung

zwischen dem Schema der zu speichernden Doku-

mente und dem entsprechenden Relationenschema

definiert sein. Dieser Ansatz ist weitaus mächtiger

als der erste, da nun die komplette Funktionalität

des Datenbanksystems (Anfrageverarbeitung, In-

dexe usw.) zur Verwaltung der eingespeicherten

Daten bereitsteht.

Prinzipiell ist also der zweite Ansatz dem ersten

vorzuziehen. Allerdings erweist sich dessen Reali-

sierung in der Praxis als problematisch. Da sich das

hierarchische Datenmodell von XML wesentlich

vom Relationenmodell unterscheidet, ist es manch-

mal sehr schwer bis unmöglich, eine vernünftige

Informatik_Spektrum_24_Dezember_2001 359

Wichtige W3C-Spezifikationen rund um XML

XML Path Language [22] Sprache zur Adressierung der Inhalte (Teile) von

XML-Dokumenten

XML Query [23, 24] Abfragesprache für XML-Daten

XML Schema [25, 26, 27] Sprache zur Spezifikation von XML-Dokumenttypen

(ersetzt DTDs)

XSL Transformations [28] Sprache zur Transformation von XML-Dokumenten in

XML-Dokumente mit anderer Struktur und/oder ande-

rem Vokabular; basiert auf XPath

Tabelle 1

Abbildung des Schemas der einzulesenden XML-

Daten auf ein Relationenschema zu finden.

Hersteller relationaler Datenbanksysteme han-

deln pragmatisch und führen eine Klassifizierung

der zu speichernden XML-Dokumente ein. Doku-

mente, die eine hinreichend kompatible Struktur

zum Relationenmodell aufweisen, werden als

¹strukturiertª oder ¹datenorientiertª bezeichnet;

für diese lässt sich meist auf einfache Weise ein

entsprechendes Relationenschema definieren. Wo

sich die Abbildung allerdings als sehr schwierig er-

weist, wird häufig von ¹unstrukturiertenª oder

¹dokumentenorientiertenª XML-Daten gesprochen.

Hier bleibt dann nur die Speicherung als CLOB

übrig.

Diese Aufteilung der XML-Dokumente in zwei

Klassen mag auf den ersten Blick etwas willkürlich

erscheinen, erweist sich in der Praxis aber als recht

brauchbar. Im Folgenden werden die beiden Ansät-

ze näher beleuchtet.

3.1 Speicherung von XML-Daten als CLOB

Wie oben besprochen, lässt sich das Schema man-

cher XML-Dokumente nur schwer auf ein entspre-

chendes Relationenschema abbilden. Es folgt eine

Aufzählung der möglichen Ursachen.

XML-Daten weisen eine hierarchische Schachte-

lung auf, relationale Daten jedoch nicht. Es muss

eine entsprechende Abbildung auf mehrere Tabellen

gefunden werden. Auûerdem lassen sich XML-

Schemas definieren (es wird hier nicht zwischen

DTDs und XML-Schemas i.e.S. unterschieden), die

eine rekursive Schachtelung von Elementen erlau-

ben. Eine Abbildung auf ein Relationenschema ist

dann prinzipiell nicht mehr möglich.

Während die Komponenten eines XML-Doku-

ments aufgrund der Serialisierung eine feste Rei-

henfolge aufweisen, sind die Tupel einer Tabelle un-

geordnet. Bei der simplen Abbildung von XML-Ele-

menten auf Tabellentupel geht also die Ordnungsin-

formation verloren. Soll die Reihenfolge erhalten

bleiben, müssen zusätzliche Spalten zur Speiche-

rung dieser Information eingeführt werden.

XML-Elemente können gemischte Inhalte auf-

weisen. Darunter versteht man die gleichwertige

Aneinanderreihung von Text und Subelementen in-

nerhalb eines übergeordneten XML-Elements. Ty-

pisches Beispiel hierfür sind Formatierungsanwei-

sungen:

Normaler Text<fett>Fetter Text

</fett>Normaler Text

</Absatz>

Das entsprechende DTD-Fragment dazu könnte fol-

gendermaûen aussehen:

<!ELEMENT Absatz (#PCDATA|fett)*>

<!ELEMENT fett (#PCDATA)>

Der Operator ¹|ª kennzeichnet eine Alternative. Das

heiût, ein Absatz kann Text oder das Subelement

¹fettª enthalten, und das beliebig oft hintereinander

(Operator ¹*ª). Damit entsteht ein gemischter In-

halt.

Es ist unklar, wie gemischte Inhalte auf Tabel-

lenspalten abgebildet werden sollen. Eine direkte

Abbildung von XML-Elementen auf Tabellenspalten

ist hier sicherlich nicht sinnvoll.

XML lässt bei der Modellierung semantisch

identischer Sachverhalte syntaktisch unterschiedli-

che Lösungen zu. Zum Beispiel können zur Be-

schreibung der Eigenschaften eines XML-Elements

sowohl XML-Attribute als auch Subelemente ver-

wendet werden:

ist z.B. äquivalent zu

<Angestellter ><Gehalt>80000

</Gehalt ></Angestellter>

Wird das Angestelltenelement auf eine Angestell-

tentabelle mit einer Spalte ¹Gehaltª abgebildet, muss

neben der eigentlichen Information auch gespei-

chert werden, ob beim Auslesen der XML-Daten aus

der Datenbank XML-Elemente oder -Attribute er-

stellt werden sollen.

XML-Dokumente enthalten neben den eigentli-

chen Daten Konstrukte, die Metadaten oder zusätz-

liche Funktionalität bereitstellen:

· Kommentare,

· Verarbeitungsanweisungen für Programme, die auf das

Dokument zugreifen,

· sog. CDATA-Blöcke, die die Interpretation von Zeichen als

Markup verhindern (Escape-Mechanismus),

360 Informatik_Spektrum_24_Dezember_2001

{XML IN RELATIONALEN DATENBANKEN

· sog. Entities zur Definition von Textmakros,

· Angabe des XML-Schemas, dem das Dokument entspricht.

Es ist ebenfalls unklar, wie solche Konstrukte auf

Tabellen abgebildet werden sollen.

Nach dieser Aufzählung dürfte klar sein, dass es

nicht möglich bzw. sinnvoll ist, XML-Dokumente

beliebig komplexer Struktur auf ein Relationen-

schema abzubilden, ohne dabei einen gewissen In-

formationsverlust in Kauf zu nehmen. Für Doku-

mente, die nach dem Auslesen aus der Datenbank

den exakt gleichen Aufbau wie vor dem Einspei-

chern haben sollen, bietet sich daher nur die Spei-

cherung als CLOB an. Dokumente, auf die dieses

Kriterium zutrifft, dienen meist der Visualisierung

der in ihnen gespeicherten Daten. Hier spielen die

Erhaltung der Elementordnung und gemischte In-

halte eine groûe Rolle. Bei einem XML-Dokument,

das z.B. in einem Web-Browser angezeigt werden

soll, dürfen keine Komponenten vertauscht werden;

ansonsten erscheint der in ihm enthaltene Text nicht

mehr in der richtigen Reihenfolge.

Relationale Systeme, die eine Speicherung von

XML-Dokumenten als CLOB erlauben, bieten oft

entsprechende Suchfunktionen an, die die Lokali-

sierung einzelner Teile des Dokuments erlauben.

Textindexe können dabei die Suche beschleunigen.

Neben der primitiven Textsuche werden manchmal

auch XML-spezifische Suchmöglichkeiten geboten;

z.B. können über XPath-Ausdrücke [22] bestimmte

Knoten im Dokument lokalisiert werden.

Sollen ausschlieûlich Dokumente dieser Art ge-

speichert und verwaltet werden, bietet sich die Ver-

wendung eines speziellen Dokument- oder Content-

managementsystems an.

3.2 Abbildung der XML-Daten auf ein

Relationenschema

Nicht in jedem Fall muss mit XML-Dokumenten

beliebig komplexen Inhalts gerechnet werden. Wo

XML hauptsächlich als Medium zum Datenaus-

tausch zwischen verschiedenen Systemen eingesetzt

wird (z.B. Übermittlung von Bestellungen, Pro-

duktdaten etc.), hat man es meist mit sehr struktu-

rierten Daten zu tun, die sich auch einfach auf ein

Relationenschema abbilden lassen. Gemischte In-

halte treten hier praktisch nicht auf, und auch die

Reihenfolge von Geschwisterelementen (z.B. ver-

schiedene Angestellte einer Abteilung) spielt hier in

der Regel keine Rolle. Hierarchische Strukturen

ohne Rekursivität lassen sich unmittelbar auf meh-

rere Tabellen mit entsprechenden Fremdschlüssel-

beziehungen abbilden.

Dieser Ansatz bietet entscheidende Vorteile ge-

genüber dem ersten. Da sich die eingelesenen XML-

Daten hier nicht mehr von anderen relationalen

Daten unterscheiden, können diese mit den norma-

len Mechanismen des Datenbanksystems bearbeitet

werden (SQL-Anfragen, Indexe etc.). Die Wieder-

herstellung des XML-Dokuments ist allerdings auf-

wändiger, da nun die Daten aus verschiedenen Ta-

bellen zusammengesucht werden müssen (und nicht

einfach aus dem CLOB ausgelesen werden können).

Bezüglich der konkreten Abbildung zwischen

XML- und Relationenschemas existieren schon ei-

nige Untersuchungen [4, 9, 13, 18], die auch Richtli-

nien und Algorithmen zur (automatischen) Sche-

matransformation enthalten. Die verschiedenen

Verfahren schränken die Klasse der transformier-

baren XML-Schemas mehr oder weniger ein (z.B.

keine gemischten Inhalte) und zeigen auch ¹Notlö-

sungenª für problematische Fälle auf (z.B. Erhalten

der Ordnung, Unterscheidung zwischen Elementen

und Attributen). Bourret [4] schlägt z.B. folgendes

Verfahren zur Erstellung eines relationalen Schemas

aus einer DTD vor:

1.Erzeuge für jeden Elementtyp mit Subelementen bzw.

gemischtem Inhalt eine Tabelle mit einer Primärschlüssel-

spalte.

2.Erzeuge für jeden Elementtyp mit gemischtem Inhalt eine

separate Tabelle zur Speicherung der PCDATA-Komponente.

Diese Tabelle wird mit der Tabelle des Elementtyps über

deren Primärschlüssel verknüpft.

3.Erzeuge in der Tabelle eines Elementtyps für jedes einwer-

tige1Attribut des Elementtyps und jeden nur einmal vor-

kommenden Subelementtyp, der nur PCDATA enthält, eine

Spalte. Wenn der Subelementtyp bzw. das Attribut optional

sind, muss die Spalte den Wert NULL annehmen können.

4.Erzeuge für jedes mehrwertige Attribut eines Elementtyps

und für jeden Subelementtyp, der ein Mehrfachvorkommen

erlaubt, jedoch nur PCDATA enthält, eine separate Tabelle

zur Speicherung der Werte. Diese Tabelle wird mit der Ta-

belle des Elementtyps über deren Primärschlüssel ver-

knüpft.

Informatik_Spektrum_24_Dezember_2001 361

1Ein Attribut kann auch eine Liste von Werten enthalten.

5.Verknüpfe für jeden Subelementtyp mit Subelementen

oder gemischtem Inhalt die Tabelle des Elementtyps mit der

Tabelle des Subelements über den Primärschlüssel des Ele-

menttyps.

3.3 Hybride Ansätze

In der Praxis erweisen sich Mischformen der beiden

oben erläuterten Ansätze oft als nützlich. Soll auf

XML-Dokumente in der Datenbank nur lesend zu-

gegriffen werden, bietet es sich z.B. an, die Doku-

mente sowohl als CLOB in der Datenbank abzulegen

als auch eine entsprechende (verlustbehaftete) Ab-

bildung auf ein Relationenschema durchzuführen.

Bei diesem Vorgehen können die gespeicherten Do-

kumente einerseits exakt rekonstruiert werden, an-

dererseits lassen sich effiziente Anfragen auf den in

Tabellen gespeicherten Daten stellen. Manche Sy-

steme lassen es sogar zu, Updates auf dem im CLOB

gespeicherten XML-Dokument direkt auf die ent-

sprechenden relationalen Daten zu propagieren.

Manchmal ist es auch hilfreich, ein XML-Doku-

ment auf mehrere CLOBs abzubilden. Soll z.B. ein

Buch im XML-Format in der Datenbank gespeichert

werden, kann es sinnvoll sein, einzelne Abschnitte

des Dokuments in verschiedenen CLOBs zu spei-

chern. Die darüber liegende Struktur des XML-Do-

kuments wird dagegen auf Tabellen abgebildet. Da-

mit sind direkte Anfragen über die Struktur (z.B.

welche Abschnitte gehören zu welchem Kapitel) und

Metadaten (z.B. Autor) des Dokuments möglich.

Innerhalb der eigentlichen Textabschnitte kann mit

entsprechenden Textfunktionen gearbeitet werden.

4 Ausgabe von relationalen Daten

im XML-Format

Wie oben dargestellt, können bei der Abbildung von

XML-Schemas in Relationenschemas einige Proble-

me auftreten. Solange bestehende relationale Daten

einfach im XML-Format ausgegeben werden sollen,

lassen sich schnell praktikable Lösungen finden. Die

Ergebnisstruktur einer SQL-Anfrage kann mit ent-

sprechenden Rowset-, Row- und Column-Tags

nachgebildet werden, wie z.B. von Bourret [4] und

Martin et al. [13] beschrieben:

<ROW>

...

</ROW>

<ROW>

...

</ROW>

...

</ROWSET>

Entspricht dieses von der Datenbank gelieferte (ka-

nonische) Format nicht den gewünschten Vorstel-

lungen, bietet es sich an, XSL-Transformationen

[28] auf die ausgegebenen XML-Daten anzuwenden.

Mit deren Hilfe ist es möglich, XML-Dokumente

über Baumtransformationen in fast beliebiger Weise

umzustrukturieren (z.B. Umwandlung eines Sub-

elements in ein Attribut).

Sollen von der Datenbank prinzipiell komplexer

strukturierte XML-Daten (die nicht dem kanoni-

schen Tabellenformat entsprechen) ausgegeben

werden, erscheint es sinnvoll, XML-orientierte An-

fragesprachen zu verwenden. Shanmugasundaram

et al. [18] schlagen vor, XML-QL-Anfragen [7] des

Benutzers in entsprechende SQL-Anfragen umzu-

wandeln und die zurückgelieferten Ergebnisse ent-

sprechend der XML-QL-Anfrage zu strukturieren.

Andere Ansätze propagieren die Erweiterung von

SQL um strukturgebende Operatoren, mit deren

Hilfe komplexe XML-Ergebnisse direkt erzeugt

werden können. Ein solches Verfahren wird im

nächsten Abschnitt vorgestellt.

5 Der Ansatz des SQL-Komitees: SQL/XML

Im vorigen Jahr erkannte das SQL-Standardisie-

rungskomitee der ISO die Notwendigkeit, sich um

eine Normung der Schnittstelle zwischen SQL und

XML zu kümmern, um einen Wildwuchs proprietä-

rer Lösungen zu vermeiden. Da das für die Standar-

disierung von XML (und verwandten Technologien)

zuständige W3C bis zu diesem Zeitpunkt keine be-

sonderen Maûnahmen in dieser Richtung unter-

nommen hatte, wurde von Melton [14] die Erweite-

rung von SQL:1999 um einen neuen Teil SQL/XML

vorgeschlagen, der sich ausschlieûlich mit der Be-

ziehung zwischen SQL und XML auseinander setzt.

Als mögliche Inhalte wurden u.a. festgelegt:

362 Informatik_Spektrum_24_Dezember_2001

{XML IN RELATIONALEN DATENBANKEN

· Spezifikationen für die Darstellung von SQL-Daten (d.h.

Tupeln, Tabellen, Views, Anfrageergebnissen) im XML-For-

mat,

· Spezifikationen bezüglich der Abbildung zwischen SQL-

Schemas und XML-Schemas,

· Spezifikation der Art und Weise, wie SQL mit XML-Daten

umgehen kann.

Die Arbeiten zu diesem neuen Teilstandard (ISO

9075±14; Tabelle 2) stecken noch in den Anfängen.

Bisher wurden nur die Abbildungen der SQL-Zei-

chensätze auf die XML-Zeichensätze, der SQL-Be-

zeichner auf die XML-Namen und der vordefi-

nierten SQL-Datentypen auf die entsprechenden

XML-Schema-Datentypen genauer spezifiziert

[21]. Für die Darstellung von SQL-Daten im XML-

Format liegen schon konkrete Vorschläge vor [12,

11, 19], von denen einer hier kurz vorgestellt wer-

den soll.

Kulkarni et al. [12] schlagen einige Erweiterun-

gen zu SQL vor, die die Konstruktion beliebig

komplexer (auch rekursiver) XML-Dokumente di-

rekt in SQL erlauben. Anhand des folgenden Bei-

spiels werden diese Erweiterungen näher betrach-

tet.

Gegeben sei das folgende Relationenschema:

Abteilungen(ID INTEGER, AbtName VAR-

CHAR(20))

Angestellte(ID INTEGER, AbtID INTE-

GER, AngName VARCHAR(20))

Es gibt Abteilungen und Angestellte. Beide Tabellen

haben ein ID-Feld, das jeweils als Schlüssel dient.

Jeder Angestellte referenziert über AbtID die Abtei-

lung, zu der er gehört. Eine Abteilung soll nach fol-

gendem Muster in XML ausgegeben werden:

<AbtName>Forschung</AbtName>

<AngName>Maier</AngName>

</Angestellter>

<AngName>Bauer</AngName>

</Angestellter>

...

</Angestellte>

</Abteilung>

Informatik_Spektrum_24_Dezember_2001 363

Die aktuellen Teilstandards von SQL (SQL:1999 umfasst nur die ersten fünf Teile)

ISO 9075±1 SQL/Framework Übersicht für den kompletten Standard

ISO 9075±2 SQL/Foundation Kerndokument, beschreibt alle grundlegenden

SQL-Features

ISO 9075±3 SQL/CLI (Call-Level Interface) Aufruf von SQL-Befehlen durch Programmiersprachen

ISO 9075±4 SQL/PSM (Persistent Stored Modules) Erweiterung von SQL um imperative Sprachkonstrukte;

gespeicherte Prozeduren und Funktionen

ISO 9075±5 SQL/Bindings (Host Language Bindings) Einbettung von SQL-Befehlen in Programmiersprachen

ISO 9075±7 SQL/Temporal Unterstützung von zeitbasierten Datentypen

ISO 9075±9 SQL/MED (Management of External Data) Unterstützung von externen (nicht im Datenbanksystem

gespeicherten) Daten

ISO 9075±10 SQL/OLB (Object Language Bindings) Beschreibung von SQLJ (in Java eingebettetes SQL)

ISO 9075±11 SQL/Schemata Beschreibung von SQL-Schemas

ISO 9075±13 SQL/JRT (SQL Routines and Types Using

the Java Programming Language)

Unterstützung von Java-Routinen und -Typen in SQL

ISO 9075±14 SQL/XML Unterstützung von XML in SQL

Tabelle 2

Die folgende Anfrage liefert das gewünschte Ergeb-

nis:

SELECT abt.AbtName, Abt-

Func(abt.ID,abt.AbtName,AngList

(abt.ID))

FROM Abteilungen abt

Die Anfrage erzeugt für jede Abteilung in der Ab-

teilungstabelle ein Tupel mit zwei Spalten. Die erste

Spalte enthält den Namen der Abteilung und die

zweite Spalte die XML-Darstellung der Abteilung.

AbtFunc und AngList sind skalare SQL-Funktionen.

AngList erzeugt die XML-Darstellung aller Ange-

stellten einer Abteilung, und AbtFunc erzeugt die

Darstellung für die Abteilung selbst. AbtFunc ist

folgendermaûen definiert:

CREATE FUNCTION AbtFunc(id INTEGER,

abtname VARCHAR(20),

anglist CLOB(10000))

RETURNS CLOB(10000) LANGUAGE XML

RETURN

<AbtName>{abtname}</AbtName>

<Angestellte>{anglist}

</Angestellte>

</Abteilung>

Der XML-Rückgabewert dieser Funktion wird über

ein XML-Template definiert. Im Template wird {x}

durch den Wert des Parameters x ersetzt. Man be-

achte, dass XML-Fragmente hier in Variablen des

Typs CLOB gespeichert werden. Die Definition für

die AngList-Funktion sieht wie folgt aus:

CREATE FUNCTION AngList(abtid INTE-

GER)

RETURNS CLOB(10000) LANGUAGE SQL

RETURN

SELECT XMLAGG(<Angestellter

id = ||ang.ID||>||

ang.AngName||

</Angestellter>)

FROM Angestellte ang

WHERE ang.AbtID = abtid

Die AngList-Funktion erzeugt die Liste von Ange-

stellten, die zu einer Abteilung gehören, im XML-

Format. Die neue Aggregatfunktion XMLAGG er-

zeugt aus der ihr übergebenen Zeichenkette das Er-

gebnis-CLOB.

6 Was machen die Hersteller?

Im Folgenden werden die Ansätze von Oracle und

IBM DB2 bezüglich der Speicherung und Ausgabe

von XML-Daten näher beleuchtet.

6.1 Oracle9i

Banerjee et al. [2] beschreiben die in der aktuellen

Oracle-Version [15] vorhandene XML-Funktionali-

tät.

6.1.1 Der CLOB-Ansatz

Oracle stellt seit der Version 9i einen speziellen Da-

tentyp ¹XMLTypeª bereit, dessen Instanzen intern

als CLOB gespeichert werden. XMLType kann wie

jeder andere Oracle-Datentyp zur Definition von

Tabellenspalten oder innerhalb von gespeicherten

Prozeduren und benutzerdefinierten Funktionen

zur Definition von Variablen, Parametern und

Rückgabewerten verwendet werden.

Auf XMLType sind systemseitig bereits einige

nützliche Funktionen definiert, die die Erzeugung

von XMLType-Instanzen und das Auslesen von

Fragmenten aus solchen Instanzen erlauben:

· createXML() nimmt einen Wert vom Typ VARCHAR oder

CLOB, überprüft, ob es sich um ein gültiges XML-Fragment

handelt, und liefert eine entsprechende XMLType-Instanz

zurück.

· extract() liefert für eine XMLType-Instanz und einen XPath-

Ausdruck ein oder mehrere XML-Fragmente (vom Typ

XMLType), die dem XPath-Ausdruck entsprechen.

· existsNode() prüft für eine XMLType-Instanz und einen

XPath-Ausdruck, ob in der Instanz ein dem Ausdruck ent-

sprechendes XML-Fragment enthalten ist.

Mit Hilfe von createXML() lassen sich z.B. direkt

XML-Fragmente in XMLType-Spalten einfügen:

INSERT INTO Tabelle_mit_XMLType_

Spalte

VALUES (..., sys.XMLType.createXML

(<Tag1>...XML_Text...</Tag1>))

Die folgende Anfrage liefert für einen gegebenen

XPath-Audruck (hier: /Auftrag/Kunde) die qualifi-

364 Informatik_Spektrum_24_Dezember_2001

{XML IN RELATIONALEN DATENBANKEN

zierenden XML-Fragmente (also<Kunde>-Frag-

mente innerhalb von<Auftrag>-Elementen) zurück:

SELECT t.XML_Spalte.extract

(/Auftrag/Kunde)

FROM Tabelle_mit_XMLType_Spalte t

WHERE ...

Enthalten die selektierten XML-Fragmente nur noch

reinen Text (d.h. keine weiteren XML-Subelemente

mehr), kann dieser auch direkt angefragt werden

(ohne umgebende Tags):

SELECT ...

FROM Tabelle_mit_XMLType_Spalte t

WHERE t.XML_Spalte.extract

(/Auftrag/Kunde/Name/text()

).getStringVal() LIKE %Maier%

Zu weiteren Anfragemöglichkeiten auf XML-Do-

kumenten mit Hilfe von XPath sei auf [22] verwie-

sen.

Die InterMedia-Text-Cartridge (spezielles

Oracle-Erweiterungspaket, das die Textsuche in

CLOBs erlaubt) wurde so erweitert, dass nun

auch eine indexunterstützte Suche auf XML-Da-

ten möglich ist. Mit Hilfe eines speziellen CON-

TAINS-Operators kann nach Text innerhalb be-

stimmter XML-Elemente oder -Attribute gesucht

werden:

SELECT *

FROM Tabelle_mit_XMLType_Spalte

WHERE CONTAINS(XMLType_Spalte,

Tulpenweg WITHIN Adresse)>0

Diese Anfrage liefert alle Tupel der Tabel-

le_mit_XMLType_Spalte zurück, die in der XML-

Type_Spalte ein XML-Dokument enthalten, das an

beliebiger Stelle den folgenden Text enthält:

<Adresse>... Tulpenweg ...</Adresse>

Durch Verschachtelung von WITHIN-Operatoren

kann die Suche mit CONTAINS auf gröûere Zusam-

menhänge ausgedehnt werden:

... CONTAINS(Spalte,(Irrweg WITHIN

Strasse) WITHIN Adresse)>0

Der CONTAINS-Operator unterstützt auch die

Textsuche mit Hilfe von XPath-Ausdrücken. Auf die

genaue Syntax wird hier nicht näher eingegangen.

¾ndernde Zugriffe auf einzelne Komponenten

einer XMLType-Instanz sind (wie beim zugrunde

liegenden Typ CLOB) in Oracle leider nicht möglich.

XMLType-Instanzen können nur als Ganzes über-

schrieben werden.

6.1.2 Ausgabe von Anfrageergebnissen

im XML-Format

Oracle bietet die Möglichkeit, innerhalb von SQL-

Anfragen XML-Fragmente zu generieren. Dazu

werden zwei neue SQL-Funktionen bereitgestellt:

· SYS_XMLGEN nimmt ein einzelnes Argument eines einge-

bauten oder benutzerdefinierten Typs und wandelt es (je

nach Typ) in ein entsprechendes XML-Element um.

· SYS_XMLAGG nimmt eine Menge von XML-Fragmenten

und hängt diese aneinander (wird im Folgenden nicht mehr

betrachtet).

Handelt es sich beim Argument von SYS_XMLGEN

um einen skalaren Wert, werden einfach entspre-

chende Tags für das Argument erzeugt. Die Anfrage

SELECT SYS_XMLGEN(Gehalt)

FROM Angestellte

WHERE PersNr = 1234

könnte z.B. die folgende Ausgabe liefern:

<?xml version = 1.0?>

Bei der Umwandlung werden auch sämtliche ob-

jekt-relationalen Typen von Oracle unterstützt.

Handelt es sich beim Argument von SYS_XMLGEN

um einen Objekttyp mit mehreren Attributen, wer-

den für diese im XML-Resultat separate Subelemen-

te erzeugt. Oracle-Kollektionen (Arrays und ver-

schachtelte Tabellen) werden entsprechend auf Li-

sten von Elementen abgebildet.

Oracle stellt dem Benutzer auch ein Programm

namens XSU (XML SQL Utility) zur Verfügung, das

die Ergebnisse ganzer SQL-Anfragen ins XML-For-

mat umwandelt. Diese Abbildung ist relativ statisch

und liefert für rein relationale Anfragen die schon in

Abschnitt 4 beschriebene XML-Struktur mit Row-

Informatik_Spektrum_24_Dezember_2001 365

set-, Row- und Column-Tags. Wird z.B. eine Anfrage

wie

SELECT PersNr, Name, Gehalt

FROM Angestellte

als Textstring an XSU übergeben, so wird ein Resul-

tat ähnlich dem folgenden zurückgeliefert:

<?xml version = 1.0?>

<Name>Huber</Name>

</ROW>

...

</ROW>

...

</ROWSET>

Durch Setzen bestimmter Parameter lassen sich die

Schlüsselwörter ROWSETund ROW in der XML-

Ausgabe durch konkrete Namen ersetzen (im obigen

Beispiel z.B. ROWSET durch ¹Angestelltenlisteª und

ROWdurch ¹Angestellterª). Auûerdem kann bei der

Formulierung der Anfrage festgelegt werden, welche

Werte auf XML-Attribute (und nicht auf Elemente)

abgebildet werden sollen. Wie oben beschrieben,

werden auch hier bei der XML-Ausgabe sämtliche

objekt-relationalen Typen von Oracle unterstützt.

Es kann vorkommen, dass die von XSU aus den

Anfrageergebnissen automatisch erzeugten XML-

Dokumente nicht die von der Anwendung benötigte

Struktur haben. Da der eigentliche Abbildungspro-

zess nur wenige Freiheitsgrade bietet, muss entwe-

der die Eingabe für XSU so angepasst werden, dass

nach der Transformation das Gewünschte heraus-

kommt, oder das Ergebnis muss nachträglich noch

entsprechend adaptiert werden:

· Mit Hilfe sog. Objektsichten ist es möglich, relationalen Ta-

bellen eine komplexe (objekt-relationale) Struktur aufzu-

prägen, die dann von XSU in eine entsprechend verschach-

telte XML-Struktur abgebildet wird.

· Der XML-Parser von Oracle stellt einen XSL-Prozessor zur

Verfügung, der die automatische Transformation von XML-

Anfrageergebnissen erlaubt.

6.1.3 Einlesen von XML-Daten in Tabellen

XSU erlaubt auch das Einlesen von XML-Daten in

Tabellen. Dazu müssen an XSU als Parameter der

Name einer bestehenden Tabelle und ein XML-Do-

kument übergeben werden, dessen Schema mit dem

Schema der spezifizierten Tabelle korrespondiert

(nach obigem Muster). XSU erzeugt dann entspre-

chende SQL-INSERT-Befehle, die die Daten des

XML-Dokuments in die Tabelle einspeichern. Pas-

sen das XML- und das relationale Schema nicht

(exakt) überein, kann man sich wieder mit Objekt-

sichten und XSL-Transformationen behelfen.

6.2 IBM DB2 Universal Database, Version 7

Cheng und Xu [5] beschreiben die Funktionalität

des in der aktuellen DB2-Version bereitgestellten

XML-Extenders [10].

6.2.1 Der CLOB-Ansatz

DB2 stellt für die Speicherung von XML-Dokumen-

ten in einer Spalte drei spezielle Datentypen zur

Verfügung:

· XMLCLOB: Speicherung des XML-Dokuments als CLOB in

DB2 (auûerhalb der Tabelle);

· XMLVARCHAR: Speicherung des XML-Dokuments als VAR-

CHAR in DB2 (innerhalb der Tabelle);

· XMLFile: Speicherung des XML-Dokuments als externe Da-

tei.

Beim Einspeichern der XML-Dokumente in eine

Tabellenspalte können diese gegenüber einer DTD

validiert werden, die der Spalte zugeordnet ist. Da-

mit kann gewährleistet werden, dass nur Dokumen-

te eines bestimmten Schemas in der Spalte gespei-

chert werden.

Neben der reinen Speicherung der XML-Doku-

mente als Textobjekte erlaubt DB2 die Extraktion

der Werte einzelner Elemente und Attribute aus den

Dokumenten, die dann in Spalten so genannter

¹Seitentabellenª abgespeichert werden. Auf diese

Daten kann dann wie auf andere relationale Daten

zugegriffen werden (nur lesend); insbesondere las-

sen sich die Spalten der Seitentabellen indexieren.

Bei ¾nderungen des XML-Dokuments werden auch

die Seitentabellen automatisch aktualisiert. Auf die-

se Weise kann auf häufig benötigte Daten in den

XML-Dokumenten sehr effizient zugegriffen wer-

den.

366 Informatik_Spektrum_24_Dezember_2001

{XML IN RELATIONALEN DATENBANKEN

DieAbbildungvonElementenundAttributender

zu speichernden XML-Dokumente auf entsprechen-

de Seitentabellen wird in sog. DAD-Dateien

(DAD = Document Access Definition) spezifiziert.

Jede Spalte einer Seitentabelle wird darin einem be-

stimmten Elementoder AttributderDTDzugeordnet

(über einen XPath-Ausdruck), die den zu speichern-

den XML-Dokumenten zugrunde liegt. Auf die ge-

naue Struktur der DAD-Dateienund das Schema der

Seitentabellenwird hier nicht näher eingegangen.

Beim Anlegen einer Tabelle, die eine XML-Spal-

te enthält, wird dieser Spalte eine DAD-Datei zuge-

ordnet. Diese wird vom System ausgelesen, und die

entsprechenden Seitentabellen werden automatisch

erstellt. Ebenso werden beim Einspeichern von

XML-Dokumenten in die XML-Spalte die Seitenta-

bellen automatisch aktualisiert.

Zur Speicherung der Dokumente in der XML-

Spalte stellt DB2 verschiedene Funktionen zur Typ-

umwandlung bereit. Es sind z.B. folgende INSERT-

Befehle möglich:

INSERT INTO Tabelle_mit_XMLVAR-

CHAR_Spalte

VALUES (..., db2xml.XMLVARCHAR(:Var-

charVariable_mit_XML))

INSERT INTO Tabelle_mit_

XMLCLOB_Spalte

VALUES (..., XMLCLOBFromFile(c:\da-

tei.xml))

Auf einzelne Elemente und Attribute der XML-Do-

kumente kann direkt zugegriffen werden. Im ein-

fachsten Fall werden die gesuchten Daten bereits in

Seitentabellen verwaltet. Ein Zugriff auf die eigentli-

chen XML-Dokumente kann dann unter Umständen

völlig vermieden werden. Aber auch wenn die ge-

suchten Informationen nur in den XML-Dokumen-

ten selbst vorliegen (z.B. weil überhaupt keine Sei-

tentabellen angelegt wurden), ist ein einfacher Zu-

griff möglich. DB2 stellt (ähnlich wie Oracle) spezi-

elle ¹Extraktionsfunktionenª bereit, die anhand

einer XPath-Angabe jedes beliebige Element oder

Attribut eines XML-Dokuments auslesen können:

SELECT extractINTEGER(XML_Spalte,

/Auftrag/Kunde/KundenNr)

FROM Tabelle_mit_XML_Spalte

WHERE ...

Für jeden DB2-Datentyp gibt es eine separate Ex-

traktionsfunktion. Der aus dem XML-Dokument

ausgelesene Knoten wird in den entsprechenden

DB2-Datentyp umgewandelt (soweit möglich). Die

XML_Spalte kann einen beliebigen XML-Typ

(XMLVARCHAR, XMLCLOB oder XMLFile) aufwei-

sen.

Genauso einfach lassen sich Updates auf einzel-

nen Elementen und Attributen durchführen:

UPDATE Tabelle_mit_XML_Spalte

SET XML_Spalte = Update(XML_Spalte,

/Autrag/Kunde/Name,Maier)

WHERE ...

DB2 stellt auch ausgefeilte Textsuchfunktionen für

XML-Dokumente bereit. Dabei wird zwischen

struktureller Textsuche (Suche nur in bestimmten

Elementen oder Attributen, spezifiziert durch

XPath-Ausdrücke) und Volltextsuche (Suche im ge-

samten Dokument) unterschieden. Auf die Syntax

des entsprechenden CONTAINS-Operators wird

hier nicht näher eingegangen.

6.2.2 Abbildungen zwischen DTDs

und Relationenschemas

DB2 gestattet die Speicherung von XML-Daten in re-

lationaler Form. Die dafür nötige Abbildung zwi-

schen dem Schema der zu speichernden XML-Do-

kumente und dem Schema der entsprechenden Ta-

bellen kann vom Benutzer frei gewählt werden. Je

nachdem, ob schon bestehende XML-Dokumente

auf Tabellen abgebildet oder schon bestehende rela-

tionale Daten im XML-Format ausgegeben werden

sollen, wird man entweder zu einem XML-Schema

ein passendes Relationenschema oder zu einem Re-

lationenschema ein passendes XML-Schema suchen.

Die exakte Abbildung zwischen den Elementen und

Attributen der XML-Dokumente und den Spalten der

Tabellen wird wieder in einer DAD-Datei festgelegt.

DB2 stellt zwei Funktionen zur Verfügung, die

die Generierung bzw. Zerlegung eines XML-Doku-

ments entsprechend einer DAD-Spezifikation vor-

nehmen:

· dxxGenXML() erzeugt ein XML-Dokument aus einer Menge

von Tabellen;

Informatik_Spektrum_24_Dezember_2001 367

· dxxShredXML() zerlegt ein XML-Dokument in eine Menge

von Tabellen.

Die Spezifikation einer entsprechenden DAD-Datei

ist recht aufwändig und wird hier nicht beschrieben.

Auch auf die genaue Benutzung der beiden Abbil-

dungsfunktionen wird nicht näher eingegangen.

Bei der Bearbeitung der im relationalen Format

vorliegenden XML-Daten muss stets im Auge be-

halten werden, welche Auswirkungen ¾nderungen

der Daten auf die evtl. später wieder zu erzeugenden

XML-Dokumente haben. So kann z.B. die Löschung

eines Tupels in einer Tabelle die Löschung eines

kompletten XML-Dokuments nach sich ziehen,

wenn das Tupel dem Top-Level-Element des XML-

Dokuments entspricht.

7 Fazit

Wieder einmal scheinen es relationale Datenbank-

systeme zu schaffen, sich den wechselnden Anfor-

derungen des Datenbankmarktes anzupassen. Wur-

den bisher zur Verwaltung semistrukturierter Daten

wie XML aus Effizienzgründen meist spezielle Sy-

steme verwendet, können heute in den meisten Fäl-

len auch vorhandene relationale Systeme zur Spei-

cherung dieser Daten eingesetzt werden. Die Her-

steller sind eifrig dabei, die gebotene XML-Funktio-

nalität weiter auszubauen, und das SQL-Komitee

sorgt durch entsprechende Standards für langfristi-

ge Kompatibilität zwischen den verschiedenen Im-

plementierungen. Nur wo besondere Anforderun-

gen an die Verwaltung von XML-Dokumenten be-

stehen, wie z.B. Versionierung oder lange Transak-

tionen, sollte weiterhin auf entsprechende

Spezialsysteme (z.B. Contentmanagementsysteme)

zurückgegriffen werden.

Literatur

1. Abiteboul, S., Buneman, P., Suciu, D.: Data on the Web: From Relations to Semi-

structured Data and XML. Hove: Morgan Kaufmann 2000

2. Banerjee, S., Krishnamurthy, V., Krishnaprasad, M., Murthy, R.: Oracle8 i ± The XML

Enabled Data Management System. Proc. 16th ICDE, San Diego 2000

3. Beech, D.: A Snapshot of XSQL: A Query Language for XML. Discussion paper,

WG3:HEL-029, H2±2000±440, August 2000

4. Bourret, R.: XML and Databases. http://www.rpbourret.com/xml/XMLAndDatabases.

htm (2001)

5. Cheng, J., Xu, J.: XML and DB2. Proc. 16th ICDE, San Diego 2000

6. Deckers, M., Eisele, R., Petkovic, D.: German National Position about the Direction of

SQL/XML. Discussion Paper, WG3:HEL-053, September 2000

7. Deutsch, A., Fernandez, M., Florescu, D., Levy, A., Suciu, D.: XML-QL: A Query Lan-

guage for XML. Submission to the W3C, August 1998. http://www.w3.org/TR/NOTE-

xml-ql/

8. Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation, 6

October 2000. http://www.w3.org/TR/REC-xml

9. Florescu, D., Kossmann, D.: Storing and Querying XML Data using an RDBMS. Bulletin

of the Technical Committee on Data Engineering 22( 3), 27±34 (1999)

10. IBM DB2 Universal Database ± XML Extender: Administration and Programming,

Version 7. IBM Corporation, 2000

11. Krishnamurthy, V., Krishnaprasad, M.: Effectively Publishing XML Data Using Object-

Relational Technology. Discussion paper, WG3:HEL-032, H2±2000±457

12. Kulkarni, K., Pirahesh, H., Shanmugasundaram, J., Shekita, E., Yannakopoulos, A.,

Zeidenstein, K.: SQL Extensions for Publishing Relational Data as XML Documents.

Discussion paper, WG3:HEL-032, H2±2000±449R1

13. Martin, D., Birbeck, M., Kay, M. et al.: Professional XML. Chicago: Wrox Press 2000

14. Melton, J.: XML-Related Specifications (SQL/XML). Subproject proposal, WG3:

HEL-026R2, H2±2000±331R2, October 2000

15. Oracle9i Application Developer's Guide ± XML, Release 1 (9.0.1). Oracle Corporation,

June 2001. Part No. A88894±01

16. Quin, L.: Open Source XML Database Toolkit: Resources and Techniques for Improved

Development. New York: John Wiley & Sons 2000

17. Shanmugasundaram, J., Shekita, E., Barr, R., Carey, M., Lindsay, B., Pirahesh, H.,

Reinwald, B.:Efficiently Publishing Relational Data as XML Documents. Discussion

paper, WG3:HEL-033, H2±2000±458, August 2000 (published in: Proc. 26th VLDB

Conf., Cairo 2000)

18. Shanmugasundaram, J., Tufte, K., He, G., Zhang, C., DeWitt, D., Naughton, J.: Rela-

tional Databases for Querying XML Documents: Limitations and Opportunities. Proc.

25th VLDB Conf., Edinburgh 1999, pp. 302±314

19. Shaw, P.: A JDBC-Oriented XML DTD for SQL Result Sets. Discussion paper, WG3:

HEL-035, H2±2000±186, March 2000

20. Zeidenstein, K., Kulkarni, K., Pirahesh, H., Shanmugasundaram, J., Shekita, E.: Dis-

cussion on SQL/XML Program of Work. Discussion paper, WG3:HEL-031,

H2±2000±448, August 2000

21. XML-Related Specifications (SQL/XML). ISO-ANSI Working Draft, WG3:YYJ-012,

H2±2001±149, June 2001

22. XML Path Language (XPath), Version 1.0. W3C Recommendation, 16 November 1999.

http://www.w3.org/TR/xpath

23. XQuery 1.0 and XPath 2.0 Data Model. W3C Working Draft, 7 June 2001. http://

www.w3.org/TR/query-datamodel/

24. XML Query Requirements. W3C Working Draft, 15 February 2001. http://

www.w3.org/TR/xmlquery-req/

25. XML Schema Part 0: Primer. W3C Recommendation, 2 May 2001. http://

www.w3.org/TR/xmlschema-0/

26. XML Schema Part 1: Structures. W3C Recommendation, 2 May 2001. http://

www.w3.org/TR/xmlschema-1/

27. XML Schema Part 2: Datatypes. W3C Recommendation, 2 May 2001. http://

www.w3.org/TR/xmlschema-2/

28. XSL Transformations (XSLT), Version 1.0. W3C Recommendation, 16 November 1999.

http://www.w3.org/TR/xslt

368 Informatik_Spektrum_24_Dezember_2001

{XML IN RELATIONALEN DATENBANKEN