Seminar 1912: XML und Datenbanken

Transcription

Seminar 1912 im Sommersemester 2002
XML und Datenbanken
Präsenzphase: 28. und 29. Juni 2002
Praktische Informatik IV
Inhalt
Übersicht XML
Lorel
Lore
XQL, XPath
YATL, YAT
XML-QL
Quilt, XQuery
Speicherung von XML-Daten in relationalen
Datenbanksystemen I
Speicherung von XML-Daten in relationalen
Datenbanksystemen II
XML-Sichten auf relationale Datenbanken
Natix, Tamino
Übersicht XML
Seminar XML und Datenbanken
Lehrgebiet Praktische Informatik IV, Prof. Dr. Güting
Seminararbeit im SS 2002
Autor: Edmund Buchbinder
Seminar „XML und Datenbanken“
Thema: Übersicht XML
Matrikel Nr. 5717574
Inhaltsverzeichnis
1. EINLEITUNG
4
2. GESCHICHTE UND ABGRENZUNG VON XML
4
2.1.
Geschichte von XML
4
2.2.
Abgrenzung und Gemeinsamkeiten mit SGML
4
2.3.
Abgrenzung und Gemeinsamkeiten mit HTML
5
2.4.
Abgrenzung und Gemeinsamkeiten mit XHTML
5
3. XML
5
3.1.
3.1.1.
Grundkonzept
Auszeichnungen im XML
5
5
3.2.
Aufbau eines XML-Dokuments
6
3.3.
XML-Körper
7
3.4.
3.4.1.
wichtige Begriffe und Hinweise für XML
wichtige Begrifflichkeiten
8
8
3.5.
3.5.1.
3.5.2.
Well-formed Dokumente vs. Valide Dokumente
well-formed Dokument
Valide Dokumente
9
9
10
3.6.
3.6.1.
3.6.2.
3.6.3.
DTD
Was ist eine DTD
Vor- und Nachteile einer DTD
Aufbau einer DTD
10
10
10
11
REFERENZ IM INHALT
11
REFERENZ IM ATTRIBUT-WERT
11
AUFTRETEN ALS ATTRIBUT-WERT
12
3.7.
3.7.1.
3.7.2.
3.7.3.
3.7.4.
3.7.5.
3.7.6.
3.7.7.
XML-Schema
Was ist ein XML-Schema
Vorteile eines XML-Schemas
Nachteile eines XML-Schemas
Aufbau eines XML-Schemas
Erweiterte Konzepte
Beispiel eines XML-Schemas
Abarbeitung eines XML-Schemas
17
17
17
17
17
20
20
22
3.8.
XLink und XPointer
22
3.9.
3.9.1.
3.9.2.
XML – Konvertierungen
CSS1 und CSS2
XSL
23
23
23
Edmund Buchbinder
24.06.02
Seite 2/33
4. XML-TOOLS
23
4.1.
Darstellung von XML in Browsern
23
4.2.
XML-Editoren
24
4.3.
XML-Prozessoren
24
5. EINSATZMÖGLICHKEITEN IN DER PRAXIS
6. VORSTELLUNG
PROJEKT
„XML
ALS
INSTANDHALTUNGSANWEISUNGEN DER DB AG“
24
FORMAT
FÜR
24
6.1.
Anforderungen
25
6.2.
Lösung
25
6.3.
Aktueller Projektstand
27
6.4.
Erfahrungen aus dem Projekt
27
7. ZUSAMMENFASSUNG UND AUSBLICK
28
8. VERZEICHNISSE
29
8.1.
Literaturverzeichnis
29
8.2.
Abbildungsverzeichnis
29
8.3.
Tabellenverzeichnis
29
9. ANHANG
9.1.
30
Anhang:vollständige XML-Grammatik in Extended-Backus- Nauer-Form
Edmund Buchbinder
24.06.02
30
Seite 3/33
1. Einleitung
Die Extensible Markup Language, im folgenden XML genannt, wurde nach Bray et al.
(2000) entwickelt, um die folgenden Ziele zu erreichen:
1. XML soll direkt über das Internet nutzbar sein.
2. XML soll eine große Bandbreite von Applikationen unterstützen.
3. XML soll mit SGML kompatibel sein.
4. Es soll einfach sein, Programme zu schreiben, die XML Dokumente verarbeiten.
5. Die Anzahl der optionalen Features in XML sollte auf ein absolutes Mininum
beschränkt sein, idealerweise null!
6. XML Dokumente sollten von einem Menschen lesbar und verständlich sein..
7. Das XML Design soll schnell vorbereitet werden können.
8. Das Design von XML sollte formal und knapp sein.
9. XML – Dokumente sollten einfach herzustellen sein.
10. Die Kürze (Bündigkeit) im XML-Markup ist von geringer Bedeutung.
XML Dokumente sind damit herstellerunabhängig. Ein weiterer Nutzen, der durch die
oben formulierten Ziele erreicht wird, liegt darin, daß XML Dokumente durch Internet
Suchmaschinen sehr viel leichter zu klassifizieren sind.
Die XML – Spezifikation wurde vom W3C Konsortium entwickelt und wird auch von
diesem weitergepflegt.
2. Geschichte und Abgrenzung von XML
2.1. Geschichte von XML
Die erste Version der XML – Spezifikation wurden vom W3C Konsortium im Februar
1998 veröffentlicht. Die eigentliche Entwicklung fand im Jahr 1996 statt. Leiter des
Teams, das XML entwickelte, war John Bosak von der Firma Sun Microsystems. XML
hat aktuell den Status einer W3C Recommendation. Der aktuelle Stand kann im WWW
unter http://www.w3.org/TR/REC-xml abgerufen werden.
Im folgenden werden die Vorläufer von XML sowie ähnliche Konzepte wie z.B. HTML
kurz vorgestellt.
2.2. Abgrenzung und Gemeinsamkeiten mit SGML
Die Standard Generalized Markup Language, kurz SGML, ist der umfassende Vorläufer
von XML. XML ist dabei als echte Untermenge der SGML zu sehen. Allerdings bedeutet
dies nicht, daß es durch XML keine Neuerungen gab. Vielmehr ist es so, daß
Neuerungen, die durch XML geschaffen wurden, im SGML nachgezogen wurden. Der
Nachteil von SGML war die hohe Komplexität der Sprache, die die Sprache schwierig zu
erlernen und anzuwenden machte. Dadurch war SGML eigentlich nur für große Firmen
(z.B. hat IBM mehrere hundert Millionen Seiten an Dokumentation im SGML Format)
bzw. staatliche Organisationen einsetzbar, die die notwendigen Ressourcen dafür hatten.
Hier soll jetzt XML eine Möglichkeit bieten, die Vorteile von SGML weiter zu nutzen,
SGML aber so zu beschränken, daß es einfacher einsetzbar wird. Dies hat natürlich auch
den Vorteil, daß die Tools (Editoren, Validierprogramme etc.) zur XML Bearbeitung
Edmund Buchbinder
24.06.02
Seite 4/33
deutlich einfacher (und aus wirtschaftlicher Sicht auch billiger) sind als die
entsprechenden Tools für SGML.
Es gibt in der Zwischenzeit eine Vielzahl von SGML Standards (sogenannte SGMLDTDs), die z.B. in der Luftfahrtindustrie im Einsatz sind. In der Praxis werden heute
häufig die SGML-DTDs in XML-DTDs bzw. XML-Schemata umgewandelt.
SGML wurde auf Basis von GML (Generalized Markup Language) entwickelt, einer
Sprache, die 1969 von IBM zur Verwaltung der Handbücher geschaffen wurde.
2.3. Abgrenzung und Gemeinsamkeiten mit HTML
Die Hypertext Markup Language (kurz HTML) ist das weit verbreitete Format, um
Information im Internet darzustellen. Allerdings hat HTML einige bedeutende Nachteile.
Die meisten Definitionen (Tags), die HTML anbietet, beziehen sich auf das Aussehen des
Dokuments und weniger den Inhalt. Gleichzeitig sind die Definitionen genau
vorgeschrieben, das bedeutet, daß der Autor seine Texte in diese Definitionen pressen
muß. Hier bietet XML eine erhöhte Präzision an, weil die Definition vom Autor selbst
erstellt werden kann. Daneben wird durch den Einsatz von XML eine Trennung von
Inhalt und Layout ermöglicht, die so im HTML nicht vorgesehen ist.
Gleichzeitig bietet XML den Vorteil, daß derselbe Text je nach Gerät auf die
unterschiedlichste Weise dargestellt werden kann.
2.4. Abgrenzung und Gemeinsamkeiten mit XHTML
Die Extensible Hypertext Markup Language (XHTML) ist eine Auszeichnungssprache,
die Ähnlichkeit mit HTML hat. Die Definition erfolgt über eine XML Dokument Typ
Definition (XML-DTD).
Dies ist ein logischer Schritt, da HTML ursprünglich als SGML-DTD definiert war. Der
Vorteil von XHTML liegt darin, daß die Sprache erweiterbar und somit an die speziellen
Belange anpaßbar ist.
Es gibt inzwischen sogar Konvertierungsprogramme wie z.B. Tidy, das HTML in
XHTML umwandelt.
3. XML
3.1. Grundkonzept
Das Grundkonzept von XML besteht darin, daß ein Dokument äquivalent z.B. zu einem
Auto aus einer Vielzahl von Teilen besteht, die nach einem bestimmten Schema
zusammengesetzt sind.
Die Darstellung der XML-Spezifikation wurde in Form von Backus-Nauer-Produktionen
vorgenommen. Die Einfachheit des Designs kann man z.B. auch daran erkennen, daß
insgesamt nur 89 erweiterte Backus-Nauer Produktionen (siehe Abschnitt 9.1) benötigt
wurden. Zum genauen Verständnis der Sprache ist es allerdings wichtig, daß auch die zu
den jeweiligen Produktionen gehörenden Beispiele mit beachtet werden.
XML Dokumente bestehen aus einzelnen Einheiten (Entities), die entweder geparsed
oder nicht geparsed werden. Die geparsten Einheiten sind entweder Auszeichnungen oder
Zeichendaten.
3.1.1. Auszeichnungen im XML
Tabelle 1 gibt eine Übersicht über die im XML möglichen Auszeichnungen. Alle anderen
Daten, die nicht in der Tabelle aufgeführt wurden, sind Zeichendaten.
Edmund Buchbinder
24.06.02
Seite 5/33
Tabelle 1: Auszeichnungen im XML
Auszeichnungstyp
Auszeichnungssyntax
Starttags
<elementName [attributes]
Schlusstags
...</elementName>
Leere-Element-Tags
<elementName [attributes] />
Entity-Referenzen
&entityName;
%parameterEntityName;
Zeichenreferenzen
&#decimalNumber; oder &#hexNumber
Kommentare
<!—comment -->
Delimitierer des CDATA-Abschnitts
<![CDATA[ cdata stuff ]]>
Dokumenttyp-Deklaration
<!DOCTYPE name externel ID? [DTD
Stuff]>
Verarbeitungsanweisungen
<?processorID data ?>
XML-Deklaration
<?xml version encoding standalone ?>
oder
3.2. Aufbau eines XML-Dokuments
Im folgenden wird der Aufbau eines XML-Dokuments anhand eines Beispiels vorgestellt
und diskutiert. Es handelt sich bei dem Beispiel um das Adreßbuch einer Firma. In
eckigen Klammern stehen bei vielen XML-Konstruktionen die erweiterten BackusNauer-Produktionen, auf denen die Konstruktion basiert.
Listing 1 (Abbildung 1) zeigt das Beispiel des XML-Dokuments. Dieses besteht aus drei
Elementen [1]: Es gibt einen Prolog, ein Element und einen Misc-Inhalt. Im folgenden
werden die einzelnen Elementeile näher vorgestellt.
3.2.1.1.
Prolog
Der Prolog [22] besteht im Listing aus den Zeilen 1 – 3. Dabei wird zunächst in Zeile 1
die XML-Version sowie die Zeichenkodierung festgelegt. Bei der XML-Version steht der
Wert auf 1.0, bei der Zeichendefinition wird UTF-8 angegeben. Dies ist der am
häufigsten verwendete Zeichencode für das amerikanische Englisch. Daneben wird bei
vielen Windows-Systemen häufig mit dem Code ISO-8859-1 gearbeitet.
Weiterhin wird in Zeile 2 die DTD[28] angegeben, d.h. die Dokumenttyp-Deklaration,
auf der das Dokument beruht. Hier wird als Dokumenttyp-Deklaration die Datei
addressbook.dtd angegeben. Diese liegt im selben Verzeichnis wie die eigentliche XML
Datei.
In der dritten Zeile wird der XSL-Stylesheet angegeben, der zur Formatierung der XMLDatei verwendet wird. Der Style-Sheet liegt im selben Verzeichnis wie das eigentliche
XML-Dokument und trägt den Dateinamen demo.xsl. Diese dritte Zeile ist optional, wird
sie auskommentiert, gibt es auch bei validierenden Browsern eine unformatierte Ausgabe.
Von der Syntax wird der Stylesheet in Form einer Prozessoranweisung an das System
übergeben.
Edmund Buchbinder
24.06.02
Seite 6/33
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE addressbook SYSTEM "addressbook.dtd" >
<?xml:stylesheet type="text/xsl" href="demo.xsl"?>
<addressbook>
<person employee-number="A0000" family-name="Gates" first-name="Bob">
<contact-info>

</contact-info>
<address city="Los Angeles" street="Pine Rd." number="1239" state="CA"/>
<job-info is-manager="no" job-description="Manager" employee-type="Full-Time"/>
<manager employee-number="A0000"/>
</person>
<person employee-number="A7000" family-name="Brown" first-name="Robert" middleinitial="L.">
<contact-info>
<email address="robb@iro.ibm.com"/>
<home-phone number="03-3987873"/>
</contact-info>
<address city="New York" street="118 St." number="344" state="NY"/>
<job-info is-manager="yes" job-description="Group Leader" employee-type="Full-Time"/>
</person>
<person employee-number="A7890" family-name="DePaiva" first-name="Kassie" middleinitial="W.">
<contact-info>

</contact-info>
<address city="Los Angeles" street="Pine Rd." number="1234" state="CA"/>
<job-info is-manager="no" job-description="Actor" employee-type="Full-Time"/>
<misc-info>One of the most talented actresses on Daytime.
Kassie plays the devious and beautiful Blair
Cramer on ABC's "One Life To Live."</misc-info>
</person>
<person employee-number="A7987" family-name="Smith" first-name="Joe">
<contact-info>
<email address="joes@iro.ibm.com"/>
<mobile-phone number="888-7657765"/>
</contact-info>
<address city="New York" street="W. 15th Ave." number="12789" state="NY"/>
<job-info is-manager="no" job-description="Hacker" employee-type="Part-Time"/>
</person>
</addressbook>
Abbildung 1: Listing 1 XML-Dokument eines Firmenadreßbuchs
3.3. XML-Körper
Ab Zeile 4 beginnt der Körper des Dokuments. In Zeile 4 steht dabei der Starttag des
Wurzel-Elementes des Dokuments[1], das addressbook. Entscheidend ist, daß jedes
XML-Dokument nur eine Wurzel haben darf. Der Schlußtag steht in Zeile 44. Wichtig ist
zu beachten, daß es für jeden Starttag auch einen Schlußtag geben muß. Weiterhin
müssen immer erst die inneren Elemente geschlossen sein, bevor ein äußeres geschlossen
werden kann.
In Zeile 5 beginnt der erste Ast des Dokuments mit dem Starttag für das Element person,
der Schlußtag findet sich dazu in Zeile 12. In Zeile 5 läßt sich erkennen, daß dem
Edmund Buchbinder
24.06.02
Seite 7/33
Element Person die Attribute [41] employee-number, family-name und first-name
zugeordnet sind. Die jeweiligen Werte für die Attribute finden sich hinter dem
Gleichheitszeichen in den doppelten Anführungsstrichen.
In Zeile 6 steht der Starttag für das Element contact-info. Dieses Element enthält einen
Kommentar und endet in Zeile 8. Der eigentliche Kommentar [15] steht in der Zeile 7.
In Zeile 9 ist ein leeres Element [44] address zu erkennen, dieses enthält nur die Attribute
city, street, number und state mit ihren jeweiligen Werten. Ebenfalls leere Elemente
befinden sich in den Zeilen 10 und 11.
Anschließend beginnt in Zeile 13 die nächste Person.
3.4. wichtige Begriffe und Hinweise für XML
XML berücksichtigt sowohl bei den Auszeichnungen als auch den Zeichendaten Großund Kleinschreibung. Bei der Anordnung der Tags ist zu berücksichtigen, daß der Tag,
der zuerst geöffnet wurde, zuletzt geschlossen wird. Es handelt sich damit also um eine
echte Baumstruktur.
3.4.1. wichtige Begrifflichkeiten
Im folgenden stelle ich die wichtigsten Begrifflichkeiten dar, die zum Verständnis eines
XML-Dokuments benötigt werden.
3.4.1.1.
Entitiy
Eine Einheit (entity) [70] besteht aus Buchstaben. Diese können entweder Mark-Up oder
„Charakter“ Data beschreiben! Als erlaubte Buchstaben gelten dabei das
Tabulatorzeichen, der Wagenumbruch (carriage return), der Wagenvorlauf und die
erlaubten Buchstaben von Unicode und ISO/IEC 10646.
3.4.1.2.
Literale
Ein Literal [11] ist eine beliebige, in Anführungszeichen eingeschlossene Zeichenkette,
die nicht das Anführungszeichen enthält, das zur Begrenzung der Zeichenkette verwendet
wird. Literale werden verwendet, um den Inhalt von internen Entities (EntityValue),
die Werte von Attributen (AttValue) und um externe Bezeichner (SystemLiteral)
anzugeben. Ein SystemLiteral kann analysiert (parsed) werden, ohne nach Markup
zu suchen.
3.4.1.3.
Zeichendaten und Auszeichnungen:
Text besteht wie bereits oben beschrieben aus miteinander vermengten Zeichendaten und
Auszeichnungen (siehe Tabelle 1).
Jeder Text, der nicht Auszeichnung ist, bildet die Zeichendaten des Dokuments.
Das &-Zeichen und das <-Zeichen dürfen in der literalen Form nur als Markup-Zeichen
oder innerhalb eines Kommentars benutzt werden. Ansonsten werden müssen die
Zeichen umschrieben ("escaped") werden durch "&" und "<". Gleiches gilt für
das >-Zeichen. Dieses wird ersetzt durch „>“.
3.4.1.4.
Tag
Für Tags gelten die folgenden Besonderheiten:
-
Tags dürfen nicht mit XML beginnen (d.h. weder XML, noch Xml, noch xml etc.)
-
Tags sollten keinen Doppelpunkt enthalten, da dieser in Zukunft für die Identifikation
eines Namensraums vorgesehen ist.
Edmund Buchbinder
24.06.02
Seite 8/33
-
Ein Tagname muß mit einem Buchstaben anfangen.
3.4.1.5.
Kommentare
Kommentare dürfen an jeder beliebigen Stelle außerhalb der Markups stehen. Ein
Kommentar darf dabei nicht mit einem –Zeichen enden.
3.4.1.6.
Prozessor Anweisungen
Durch Prozessor Anweisungen können einzelne Dokument Anweisungen für externe
Programme wie z.B. einen Java-Skript Interpreter enthalten.
3.4.1.7.
CDATA-Abschnitte
CDATA-Abschnitte enthalten Informationen, die an die Anwendung weitergegeben
werden sollen, ohne auf Auszeichnungen geparst zu werden. CDATA-Abschnitte dürfen
dabei nicht verschachtelt sein.
3.5. Well-formed Dokumente vs. Valide Dokumente
XML unterscheidet zwischen wohlgeformten Dokumenten (well-formed documents) und
validen Dokumenten (valid documents).
3.5.1. well-formed Dokument
Ein XML-Dokument ist wohlgeformt, wenn es die folgenden Anforderungen erfüllt:
-
Als ganzes gesehen fügt es sich in die als Dokument (siehe Anhang 9.1) bezeichnete
Produktion.
-
Es erfüllt alle Bedingungen zur Wohlgeformtheit, die in der Spezifikation (der XML1.0-Empfehlung) angegeben werden. Dazu gehört, daß ein XML-Dokument
mindestens ein Element enthalten muß. Daneben muß sichergestellt, daß es sich bei
dem Dokument um einen Baum handelt. Es muß eine eindeutig definierte Wurzel
vorliegen.
-
Alle geparsten Entities, auf die eine direkte oder indirekte Referenz im Dokument
besteht, sind wohlgeformt.
Im folgenden werden nun die Bedingungen für die Wohlgeformtheit aufgeführt:
-
Parameter-Entities in der internen Untermenge dürfen nur dort auftreten, wo
Auszeichnungen stehen können. Sie können nicht innerhalb der Auszeichnung
stehen.
-
Der Name im Schlußtag eines Elements muß dem Namen im Starttag entsprechen.
-
Ein Attributname kann nur einmal in jedem Starttag oder dem Tag für ein leeres
Element vorkommen.
-
Attributwerte können keine direkten oder indirekten Referenzen auf externe Entities
enthalten.
-
Der Ersetzungstext einer Entity, auf die direkt oder indirekt Bezug genommen wird
(außer „&lt“) darf kein < Zeichen enthalten.
-
Zeichen, auf die man sich mit Hilfe von Zeichenreferenzen bezieht, müssen zulässig
sein.
-
In einem Dokument ohne DTD, einem Dokument mit einer nur internen DTDTeilmenge ohne Referenz auf einer Parameter-Entity oder in einem Dokument mit
dem Wert „standalone=‘yes‘“ in der XML-Deklaration muß der Name, der in der
Entity-Referenz angegeben wird, dem in der Entity-Deklaration entsprechen. Eine
Edmund Buchbinder
24.06.02
Seite 9/33
Ausnahme besteht darin, daß wohlgeformte Dokumente keine der folgenden Entities
deklarieren müssen: &amp, &lt, &apos, &quot.
-
Grundsätzlich muß die Deklaration einer Parameter-Entity jeglicher Referenz auf sie
vorausgehen. Es gibt aber einige Situationen, in denen ein nicht-validierender XMLProzessor die Verarbeitung von Entity-Deklarationen beendet. Etwa, wenn der nichtvalidierende Prozessor davon ausgeht, daß alle Deklarationen gelesen und verarbeitet
wurden, kann er einen Fehler bei der Wohlgeformtheit deklarieren und die
Verarbeitung abbrechen, wenn er eine nicht deklarierte Entity findet. Andererseits ist
es kein Fehler, eine nicht deklarierte Entity zu finden, wenn der nicht-validierende
Prozessor aus irgendeinem dieser Gründe die Verarbeitung von Entities beendet hat.
-
Eine Entity-Referenz darf nicht den Namen einer ungeparsten Entity enthalten. Man
kann damit keine Binärdaten mitten in den Text einfügen, ohne irgendeine Art von
Verarbeitungsmechanismus zu deklarieren.
-
Eine geparste Entity darf keine rekursive Referenz aus sich selbst enthalten, weder
direkt noch indirekt.
-
Referenzen auf die Parameter-Entities dürfen nur innerhalb der DTD auftreten.
3.5.2. Valide Dokumente
Bei validen Dokumenten wird neben der Wohlgeformtheit auch überprüft, ob diese
Dokumente den Vorgaben einer DTD (siehe Abschnitt 3.6) oder eines XML-Schemas
(siehe Abschnitt 3.7) entsprechen. Validierende Parser dürfen ein Dokument erst
anzeigen, wenn es valide (gültig) ist. Damit können sich z.T. beträchtliche Wartezeiten
für den Benutzer ergeben.
3.6. DTD
3.6.1. Was ist eine DTD
Eine Dokumenttyp-Definition (Document Type Definition), im folgenden DTD genannt,
definiert die Form und die Syntax eines XML-Sprachkonstrukts. Sie beschreibt damit das
Vokabular, aus dem die einzelnen XML-Instanzen dann zusammengesetzt sind.
Es besteht dabei ein deutlicher Unterschied in der Syntax zwischen einem XMLDokument und einer XML-DTD.
Eine DTD muß in Ihrem Namen den Namen des Wurzel-Elements enthalten.
3.6.2. Vor- und Nachteile einer DTD
3.6.2.1.
Vorteile einer DTD
Eine DTD bietet die folgenden Vorteile:
-
Bietet die Möglichkeit, auch erweiterte Zeichensätze oder Codierungen zu nutzen.
-
Attributen können Standardparameter zugewiesen werden
-
Die Texterstellung kann während des Schreibprozesses validiert werden. Dies ist eine
wichtige Unterstützung für den Autor.
-
Editier-Werkzeuge können bei einer vorliegenden DTD den Autor unterstützen, in
dem sie ihm nur die zulässigen Element anbieten.
3.6.2.2.
Nachteile einer DTD
Den Vorteilen stehenden die folgenden Nachteile entgegen, die beim Einsatz einer DTD
mit abgewogen werden müssen:
Edmund Buchbinder
24.06.02
Seite 10/33
-
Durch die unterschiedliche Syntax werden von Autoren noch zusätzliche Kenntnisse
verlangt. In der Praxis läßt man sich häufig die DTD aus einem bereits erstellten
XML Dokument automatisch erzeugen. Diese wird bei Bedarf dann noch manuell
nachbearbeitet.
-
Die Komplexität des Parsers wird erhöht
-
Bei manchen Tools ist keine Zwischenspeicherung in einem nicht validen Zustand
erlaubt. Die Benutzer werden dadurch gegängelt.
-
durch externe Leseoperationen kann sich die Bearbeitungszeit beim Einsatz einer
DTD deutlich verlängern
3.6.3. Aufbau einer DTD
Eine DTD besteht aus der Deklaration der einzelnen Entities, die im Dokument
verwendet werden können. Als Entities sind dabei Parameter-Entities, allgemeine Entities
und ungeparste Entities möglich.. Daneben enthält eine DTD Elemente, die zu den
Elementen zugeordneten Attribute sowie Notationen.
3.6.3.1.
Entities
Ausgehend von der Vorstellung, daß ein XML-Dokument eine Ansammlung von Entities
ist, kann man eine Entity-Deklaration als Möglichkeit sehen, auf eine Instanz eines
bestimmten Objektes zu zeigen. Die Syntax sieht dabei in der Grundform wie folgt aus:
<!ENTITY name value >
Wie bereits erwähnt, wird dabei unterschieden zwischen Parameter-Entities, allgemeinen
Entities und ungeparsten Entities. Auf eine allgemeine Entity bezieht man sich mit dem
&-Zeichen:
&name
Auf eine Parameter-Entity mit dem %-Zeichen:
%name
Auch in der Deklaration unterscheiden sich die beiden Entity-Typen. Parameter-Entities
enthalten ein %-Zeichen vor dem Namen der Entity.
Ungeparste Entities funktionieren zusammen mit einer Notation. Die entsprechende
Notation muß deklariert sein, bevor sie in einer Entity verwendet werden kann.
Der folgende Abschnitt ist aus der XML-1.0 Empfehlung des W3C entnommen. Sie
beschreibt den Umgang mit Entities sowohl in den Dokumenten als auch in DTDs:
"Die folgende Tabelle (Tabelle 2) faßt zusammen, in welchem Kontext
Zeichenreferenzen, Entity-Referenzen und der Aufruf von nicht-analysierten Entities
stehen dürfen und wie sich ein XML-Prozessor in jedem Fall zu verhalten hat. Die
Einträge in der linken Spalte beschreiben den Kontext:
Referenz im Inhalt
ist eine Referenz zwischen Start-Tag und End-Tag eines Elements. Korrespondiert mit
dem Nicht-Terminal content.
Referenz im Attribut-Wert
ist eine Referenz entweder im Wert eines Attributes (im Starttag) oder ein Vorgabewert
in einer Attributdeklaration. Korrespondiert mit dem Nicht-Terminal AttValue.
Edmund Buchbinder
24.06.02
Seite 11/33
Auftreten als Attribut-Wert
als ein Name, nicht als Referenz, entweder als Wert eines Attributs, das als Typ ENTITY
deklariert wurde, oder als ein Wert einer Liste von Token (durch Leerzeichen getrennt) in
einem Attribut des Typs ENTITIES.
Referenz im Entity-Wert
ist eine Referenz innerhalb des literalen Entity-Werts in der Deklaration eines Parameteroder internen Entity. Korrespondiert mit dem Nicht-Terminal EntityValue.
Referenz in der DTD
ist eine Referenz in der internen oder externen Teilmenge der DTD, aber außerhalb eines
EntityValue oder AttValue.
Tabelle 2: Entity-Typen und ihre Auswirkung
Parameter
Referenz im Inhalt Nicht erkannt
Referenz im
Attribut-Wert
Auftreten als
Attribut-Wert
Referenz im EntityWert
Nicht erkannt
Nicht erkannt
Entity-Typ
Zeichen
intern,
extern-analysiert,
nichtallgemein
allgemein
analysiert
Inkludiert,
falls
Inkludiert
Verboten
Inkludiert
validierend
in
Literal
Verboten
Verboten
Inkludiert
inkludiert
Nicht
Verboten
Verboten
Informieren
erkannt
in
Literal
Durchgereicht
inkludiert
Als Parameter(PE) Verboten
Referenz in der DTD Entity
inkludiert
Durchgereicht
Verboten
Inkludiert
Verboten
Verboten
Verboten
Nicht erkannt
Außerhalb der DTD hat das Prozent-Zeichen (%) keine besondere Bedeutung. Folglich
wird das, was in der DTD ein Parameter-Entity wäre, im Inhalt nicht als Markup erkannt.
Ebenso werden die Namen von nicht-analysierten Entities nicht erkannt, es sei denn, sie
erscheinen als Wert eines entsprechend deklarierten Attributs.
Inkludiert
Ein Entity wird inkludiert, wenn sein Ersetzungstext an der Stelle der Referenz selbst
geladen und verarbeitet wird, so als ob es Teil des Dokumentes wäre und zwar an der
Stelle, an der die Referenz steht. Der Ersetzungstext kann sowohl Zeichendaten als auch
Markup enthalten (mit Ausnahme der Parameter-Entities), die in der üblichen Weise
behandelt werden, abgesehen davon, daß Ersetzungstext, der dazu dient, Markup-Zeichen
zu schützen (die Entities amp, lt, gt, apos, quot), stets als Zeichendaten behandelt
wird. (Die Zeichenkette »AT&T;« expandiert zu »AT&T;« und das übriggebliebene
et-Zeichen wird nicht als Begrenzung einer Entity-Referenz angesehen.) Eine
Zeichenreferenz wird inkludiert, wenn das referenzierte Zeichen an Stelle der Referenz
verarbeitet wird.
Inkludiert, falls validierend
Wenn der XML-Prozessor bei dem Versuch, ein Dokument zu validieren, auf eine
Referenz zu einem analysierten Entity stößt, dann muß der Prozessor dessen
Edmund Buchbinder
24.06.02
Seite 12/33
Ersetzungstext inkludieren. Wenn es sich um ein externes Entity handelt und der
Prozessor gar nicht versucht, das XML-Dokument zu validieren, ist es dem Prozessor
freigestellt, den Ersetzungtext zu inkludieren. Wenn ein nicht-validierender Parser einen
Ersetzungtext nicht inkludiert, muß er die Anwendung darüber informieren, daß er auf
ein Entity gestoßen ist, dieses aber nicht eingelesen hat.
Diese Regel basiert auf der Erkenntnis, daß die automatische Inkludierung, die durch den
Entity-Mechanismus von SGML und XML zur Verfügung steht und dazu gedacht war,
Modularität bei der Texterstellung zu ermöglichen, nicht unbedingt für andere
Anwendungen geeignet ist, insbesondere für das Dokument-Browsing. Beispielsweise
könnten Browser sich dafür entscheiden, eine Referenz auf ein extern-analysiertes Entity
visuell anzuzeigen und das Entity erst auf Anfrage zu laden und darzustellen.
Verboten
Das folgende ist verboten und stellt einen kritischen Fehler dar:
• das Erscheinen einer Referenz auf ein nicht-analysiertes Entity
• das Erscheinen einer Zeichen- oder allgemeinen Entity-Referenz in der DTD, es
sei denn sie steht innerhalb eines EntityValue oder AttValue
• eine Referenz auf ein externes Entity in einem Attribut-Wert
In Literal inkludiert
Wenn eine Entity-Referenz in einem Attribut-Wert erscheint oder wenn eine ParameterEntity-Referenz in einem literalen Entity-Wert erscheint, wird dessen Ersetzungstext an
Stelle der Referenz selbst verarbeitet; so, als ob er Teil des Dokuments an der Stelle
wäre, an der die Referenz steht. Eine Ausnahme ist, daß ein einfaches (Apostroph) oder
doppeltes Anführungszeichen im Ersetzungstext stets als normales Zeichen behandelt
wird und das Literal nicht beendet. Zum Beispiel ist folgendes wohlgeformt:
<!ENTITY % JN '"Ja"' >
<!ENTITY WasErSagte "Er sagte &JN;" >
Dieses jedoch nicht:
<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>
Informieren
Wenn der Name eines nicht-analysierten Entity als ein Token im Wert eines Attributs
erscheint, dessen deklarierter Typ ENTITY oder ENTITIES ist, dann muß ein
validierender Prozessor die Anwendung über den System- und Public-Identifier (falls
vorhanden) des Entity und dessen Notation informieren.
Durchgereicht
Wenn eine Referenz auf ein allgemeines Entity im EntityValue in einer EntityDeklaration erscheint, wird es unverändert durchgereicht.
Als PE inkludiert
Genau wie extern-analysierte Entities müssen auch Parameter-Entities nur dann
inkludiert werden, wenn das Dokument validiert wird. Wenn eine Parameter-EntityReferenz in der DTD erkannt und inkludiert wird, wird dessen Ersetzungstext um ein
führendes und abschließendes Leerzeichen (#x20) erweitert. Die Absicht ist es, den
Ersetzungstext so zu beschränken, daß er in sich geschlossene grammatikalische Token
der DTD enthält." (Bray et al.. 2000, Übersetzung durch Behme und Wintert)
3.6.3.2.
Elemente und Attribute
Grundsätzlich sieht eine ELEMENT-Deklaration in einer DTD wie folgt aus:
<!Element name content-model>
Edmund Buchbinder
24.06.02
Seite 13/33
Als Inhaltsmodell (content-model) können dabei beliebige terminale und nicht-terminale
Elemente gewählt werden. Nicht-terminale Elemente sind dabei andere Elemente, die
wiederum terminal oder nicht-terminal sein können. Terminale Elemente werden durch
den Typ #PCDATA beschrieben.
Zu jedem Element können Attribute in einer Attributliste zugeordnet werden. Für die
Attributliste gilt dabei die folgenden Syntax:
<!ATTLIST element-name
attribute-name-1 datatype default-data
attribute-name-1 datatype default-data
...>
Im Gegensatz zu den Elementen sind damit bei den Attributen mehrere terminale
Datentypen erlaubt. Tabelle 3 gibt eine Übersicht über die Attributs-Datentypen, die in
einer DTD verwendet werden können.
Tabelle 3: Attributs-Datentypen in einer DTD
Attributs-Datentyp
Beschreibung
CDATA
Zeichendaten, die einen String bilden.
ID
Eine benannte einzigartige ID innerhalb
eines Dokuments.
IDREF
Eine benannte
einzigartige ID
IDREFS
Eine benannte Liste von Referenzen auf
einzigartige
IDs
innerhalb
eines
Dokuments.
ENTITY
Eine benannte Referenz auf eine Entity, die
sich auf eine Notation bezieht.
ENTITIES
Eine benannte Liste von Referenzen auf
Entities, die sich auf Notationen bezieht.
NMTOKEN
Eine benannte Referenz auf ein NAMEToken.
NMTOKENS
Eine benannte Referenz auf eine Liste von
NAME-Token.
NOTATION
Eine aufgezählte Referenz auf eine Liste
von Notations-Datentypen. Dies ist die
Ausnahme von der Regel, daß alle
ungeparsten Entities extern sein müssen.
Referenz
auf
eine
Wie oben bereits beschrieben, bieten Attribute zusätzlich die Möglichkeit, Standarddaten
für das Attribut vorzugeben.
Edmund Buchbinder
24.06.02
Seite 14/33
Tabelle 4: Standarddaten für Attribute
Standarddatum
Bedeutung
#REQUIRED
Es wird kein Standardwert vorgegeben. In
einem validen XML-Dokument muß hier
ein Wert eingegeben werden.
#IMPLIED
Das Attribut muß
vorhanden sein.
"default-value"
Es gibt einen Standardwert. Dieser kann
überschrieben werden.
#FIXED "constant-value"
Es gibt einen Standardwert, dieser kann
nicht überschrieben werden
nicht
unbedingt
Tabelle 5: Frequenzindikatoren, die in XML-DTDs verwendet werden
Syntax
Bedeutung
?
Kein oder einmaliges Auftreten
+
Einmaliges oder mehrmaliges Auftreten
*
Kein oder mehrfaches Auftreten
(a|b)
Entweder a oder b, aber nicht beide
(a,b)
a gefolgt von b
3.6.3.3.
Notationen
Zu einer Notation gehört all das, was der XML-Prozessor nicht verstehen und auswerten
kann. Dabei sind sowohl binäre Daten denkbar als auch Text, der nicht für den XMLProzessor bestimmt ist. Bei der Verwendung von Notationen muß berücksichtigt werden,
daß ein Zugriff auf die entsprechende DTD zwingend erforderlich ist, um sie in einem
Dokument zu verwenden.
Die Syntax einer Notation sieht wie folgt aus:
<!NOTATION name identifier "helper">
3.6.3.4.
Beispiel einer DTD
Das folgende Listing 2 zeigt die zu dem XML-Dokument in Listing 1 passende DTD. In
Zeile 1 wird äquivalent zu einem XML-Dokument zunächst die Kodierung der DTD
definiert. In Zeile 2 ist zu erkennen, daß die Kommentare in einer DTD der Syntax der
Kommentare in einem XML-Dokument entsprechen. In den Zeilen 3 bis 11 werden
Parameter-Entities definiert. Dieses Vorgehen hat den Vorteil, daß die DTD später relativ
einfach auf verschiedene Länder angepaßt werden kann. Für einen deutschen Autor
müssen nur die Werte in den Anführungszeichen in die deutsche Sprache übersetzt
werden, z.B. wird aus dem "addressbook" das "Adreßbuch", aus dem "first-name" der
"Vorname" etc. Da es sich hier nur um eine Beispiel DTD handelt, wurden dabei nicht
alle später verwendeten Elemente und Attribute als Parameter-Entities definiert. Dies
müßte bei der endgültigen Verwendung noch nachgezogen werden.
Edmund Buchbinder
24.06.02
Seite 15/33
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
<?xml encoding="UTF-8"?>

<!ENTITY % Doctype "addressbook" >
<!ENTITY % Person "person">
<!ENTITY % Contact-info "contact-info">
<!ENTITY % Address "adress">
<!ENTITY % Job-info "job-info">
<!ENTITY % Manager "manager">
<!ENTITY % Misc-info "misc-info">
<!ENTITY % First-name "first-name">
<!ENTITY % Family-name "family-name">

<!ELEMENT %Doctype; ( %Person;)+>
<!ELEMENT %Person; (%Contact-info;, %Address;,%Job-info;,%Manager;,(%Miscinfo;)?)>
<!ATTLIST %Person;
%First-name;
CDATA #REQUIRED
%Family-name;
CDATA #REQUIRED
middle-initial
CDATA #IMPLIED
employee-number
ID #REQUIRED>
<!ELEMENT %Contact-info; (home-phone|mobile-phone|email)*>
<!ELEMENT home-phone EMPTY>
<!ATTLIST home-phone
number
CDATA #REQUIRED>
<!ELEMENT mobile-phone EMPTY>
<!ATTLIST mobile-phone
number
CDATA #REQUIRED>
<!ELEMENT email EMPTY>
<!ATTLIST email
address
CDATA #REQUIRED>
<!ELEMENT %Address; EMPTY>
<!ATTLIST %Address;
state NMTOKEN #REQUIRED
city CDATA #REQUIRED
street CDATA #REQUIRED
number CDATA #REQUIRED>
<!ELEMENT %Job-info; EMPTY>
<!ATTLIST %Job-info;
is-manager (yes|no) 'no'
job-description CDATA #REQUIRED
employee-type (Full-Time|Part-Time|Intern) 'Full-Time'>
<!ELEMENT %Manager; EMPTY>
<!ATTLIST %Manager;
employee-number
IDREF #REQUIRED>
<!ELEMENT %Misc-info; (#PCDATA)>
Abbildung 2: Listing 2 DTD für das Dokument aus Listing 1
Ab der Zeile 13 (nach einem Kommentar in Zeile 12) beginnt die Definition der
Elemente und Attribute. Das erste Element, das definiert wird, ist das Wurzelelement in
Zeile 13. Hier wird die in Zeile 3 definierte Parameter-Referenz auf den Wert
"addressbook" eingesetzt, d.h. im entsprechenden XML-Dokument heißt das WurzelElement addressbook. Gleichzeitig ist definiert, daß das Wurzelelement mindestens 1
Element vom Typ Parameter-Entity %Person enthalten muß.
In Zeile 14 wird das Element %Person definiert, dies enthält eine Kontakt-Information,
eine Adresse, eine Job-Information sowie keine oder eine gemischte Information. Dabei
ist festgelegt, daß die Bestandteile in einer festen Reihenfolge stehen müssen. Weiterhin
ist zu beachten, daß hier ebenfalls Parameter-Entities verwendet wurden.
Edmund Buchbinder
24.06.02
Seite 16/33
In Zeile 15 bis einschließlich Zeile 19 wird die zu dem Element %Person gehörige
Attributliste definiert. Pflichtattribute sind der %First-name, der %Family-name und die
employee-number. Das Attribut middle-initial muß dagegen nicht gefüllt werden. Die
Attribute %First-name, %Family-name und middle-initial sind vom Typ CDATA, das
Attribut employee-number vom Typ ID. An diesem Beispiel ist zu sehen, daß Attribute
sowohl direkt (in Zeile 18 und 19) als auch als Parameter-Entities definiert werden
können.
In Zeile 20 wird das Element %Contact-info definiert. Dieses besteht aus den Elementen
home-phone, mobile-phone und email. Es kann dabei eins von den drei Elementen
ausgewählt werden, die Auswahl kann aber null bis mehrmals hintereinander erfolgen.
In Zeile 20 wird das leere Element home-phone definiert. Dieses besteht nur aus einer
Attributliste, die das Pflicht-Attribut number vom Typ CDATA enthält.
In den Zeilen 38 und 40 ist zu erkennen, wie mit Vorschlagswerten für die
Attributbelegung gearbeitet wird. In Zeile 44 enthält das Element %Misc-info als
Bestandteil den terminalen Inhalt PCDATA.
3.7. XML-Schema
3.7.1. Was ist ein XML-Schema
Ein Schema ist eine weitere Möglichkeit, eine Vorlage für XML-Dokumente zu
definieren. Seit Mai 2001 hat das Schema den Status einer W3C-Recommendation.
XML-Schemata erlauben im Gegensatz zu DTDs echte Fehler- und Bereichsüberprüfung.
Damit können Dokumente schon bei der Erstellung auf die interne Validität überprüft
werden. Dies hat natürlich den Vorteil, daß man damit den Datenverkehr, der über die
Netzwerke läuft, deutlich reduzieren kann, weil keine „falschen“ Daten mehr verschickt
werden.
3.7.2. Vorteile eines XML-Schemas
Der Einsatz eines XML-Schemas bietet die folgenden Vorteile:
-
Das XML-Schema bietet eine Vielzahl von Datentypen an, so daß eine große Zahl
von Validierungen direkt bei der Eingabe vorgenommen werden können.
-
Die Unterstützung für reguläre Ausdrücke ist sehr gut.
-
Ein XML-Schema wird in XML geschrieben. Für die Autoren ist daher kein Erlernen
einer neuen Syntax notwendig
3.7.3. Nachteile eines XML-Schemas
Der Einsatz eines XML-Schemas hat die folgenden Nachteile:
-
XML-Schemata sind noch nicht so weit verbreitet wie DTDs. Entsprechend ist die
Tool-Unterstützung noch nicht so ausgeprägt.
-
Die Erstellung eines Schemas verleitet dazu, die Eingaben der Benutzer sehr stark
einzuschränken. Die Folge davon ist eine regelmäßige Veränderung an den
Schemata.
3.7.4. Aufbau eines XML-Schemas
Im folgenden werden die wichtigsten Bestandteile eines XML-Schemas vorgestellt. Es
wird empfohlen, zu diesem Abschnitt parallel den Abschnitt 3.7.6 zu beachten.
Edmund Buchbinder
24.06.02
Seite 17/33
Grundsätzlich werden bei XML-Schemata zwischen komplexen Datentypen und
einfachen Datentypen unterschieden. Einfache Datentypen dürfen keine Elemente als
Inhalt und keine Attribute besitzen.
Globale Elemente und Attribute werden direkt als Unterelemente des Schema-Elementes
vergeben. Auf diese kann dann über eine "ref"-Beziehung zugegriffen werden. Wichtig
ist, daß globale Elemente keine Referenzen enthalten dürfen. Daneben darf es bei
globalen Elementen keine Beschränkung der Kardinalität geben. Die Beschränkung darf
es nur bei einer Referenz auf die globalen Elemente geben.
In einem XML-Schema können per Definition die in Tabelle 6 folgenden simplen Typen
enthalten sein:
Tabelle 6 : Simple Typen (Tabelle aus Fallside, 2001)
Simple Type
string
normalizedString
token
byte
unsignedByte
base64Binary
hexBinary
integer
positiveInteger
negativeInteger
nonNegativeInteger
nonPositiveInteger
int
unsignedInt
long
unsignedLong
short
unsignedShort
decimal
float
double
boolean
time
Examples (delimited by
commas)
Confirm this is electric
-1, 126
0, 126
GpM7
0FB7
-126789, -1, 0, 1, 126789
1, 126789
-126789, -1
0, 1, 126789
-126789, -1, 0
-1, 126789675
0, 1267896754
-1, 12678967543233
0, 12678967543233
-1, 12678
0, 12678
-1.23, 0, 123.4, 1000.00
-INF, -1E4, -0, 0, 12.78E2, 12, INF, NaN
-INF, -1E4, -0, 0, 12.78E2, 12, INF, NaN
true,
false
1, 0
13:20:00.000,
13:20:00.000-05:00
dateTime
1999-0531T13:20:00.000-05:00
duration
P1Y2M3DT10H30M12.3
S
date
gMonth
gYear
gYearMonth
1999-05-31
--05-1999
1999-02
Edmund Buchbinder
24.06.02
Notes
see (3)
see (4)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
see (2)
equivalent to single-precision
32-bit floating point, NaN is
"not a number", see (2)
equivalent to double-precision
64-bit floating point, see (2)
see (2)
May 31st 1999 at 1.20pm
Eastern Standard Time which is
5 hours behind Co-Ordinated
Universal Time, see (2)
1 year, 2 months, 3 days, 10
hours, 30 minutes, and 12.3
seconds
see (2)
May, see (2) (5)
1999, see (2) (5)
the month of February 1999,
Seite 18/33
Simple Type
Examples (delimited by
commas)
Notes
regardless of the number of
days, see (2) (5)
the 31st day, see (2) (5)
every May 31st, see (2) (5)
XML 1.0 Name type
XML Namespace QName
XML Namespace NCName, i.e.
a QName without the prefix
and colon
gDay
gMonthDay
Name
QName
---31
--05-31
shipTo
po:USAddress
NCName
USAddress
anyURI
http://www.example.com/
,
http://www.example.com/
doc.html#ID5
valid values for xml:lang as
defined in XML 1.0
XML 1.0 ID attribute type, see
ID
(1)
XML 1.0 IDREF attribute type,
IDREF
see (1)
XML 1.0 IDREFS attribute
IDREFS
type, see (1)
XML 1.0 ENTITY attribute
ENTITY
type, see (1)
XML 1.0 ENTITIES attribute
ENTITIES
type, see (1)
XML 1.0 NOTATION attribute
NOTATION
type, see (1)
US,
XML 1.0 NMTOKEN attribute
NMTOKEN
Brésil
type, see (1)
XML
1.0
NMTOKENS
US
UK, attribute type, i.e. a whitespace
NMTOKENS
Brésil Canada Mexique
separated list of NMTOKEN's,
see (1)
Notes: (1) To retain compatibility between XML Schema and XML 1.0 DTDs, the
simple types ID, IDREF, IDREFS, ENTITY, ENTITIES, NOTATION, NMTOKEN,
NMTOKENS should only be used in attributes. (2) A value of this type can be
represented by more than one lexical format, e.g. 100 and 1.0E2 are both valid float
formats representing "one hundred". However, rules have been established for this
type that define a canonical lexical format, see XML Schema Part 2. (3) Newline, tab
and carriage-return characters in a normalizedString type are converted to space
characters before schema processing. (4) As normalizedString, and adjacent space
characters are collapsed to a single space character, and leading and trailing spaces are
removed. (5) The "g" prefix signals time periods in the Gregorian calender.
language
en-GB, en-US, fr
Neue simple Datentypen können aus existierenden simplen Datentypen gewonnen
werden, in dem z.B. eine Einschränkung des Bereichs vorgenommen wird.
In List-Typen hat das einzelne Zeichen für sich eine Bedeutung. Es besteht aus mehreren
atomaren Typen, die durch Leerzeichen getrennt sind. Auch hier sind Einschränkungen
möglich, wie die Länge, die maximale Länge, die minimale Länge oder auch
Aufzählungen.
Ein Union-Typ enthält alle möglichen Werte eines simplen Datentypen oder eines ListDatentypen.
Edmund Buchbinder
24.06.02
Seite 19/33
Daneben bietet ein Schema auch die Möglichkeit, anonyme Datentypen zu definieren.
Dies ist sinnvoll, wenn man die Datentypen noch nicht einschränken will.
Aus simplen Datentypen können neue komplexe Datentypen gewonnen werden.
Es gibt natürlich auch in einem XML-Schema die Möglichkeit, leere Elemente zu
definieren, die nur Inhalt enthalten.
anyType Objekte können jeglichen Inhalt enthalten, d.h. sowohl einfache als auch
komplexe Datentypen. Dieser Typ wird immer dann vom System angenommen, wenn
kein expliziter Datentyp erklärt wird.
Es gibt in einem XML-Schema drei Formen für Annotationen. Einerseits die
Dokumentations-Elemente, die helfen sollen, das Schema für einen menschlichen Leser
besser verständlich zu machen. Daneben gibt es das appInfo-Element. Dieses wird
eingesetzt, um Informationen an andere Applikationen zu liefern. Das AnnotationsElement ist das "Über"-Element für die beiden erwähnten Elemente.
Wird kein expliziter Namensraum angegeben, dann setzt der Prozessor automatisch den
Namensraum xsd:, den Namensraum für das allgemeine XML-Schema. Allerdings wird
empfohlen, explizit den Namensraum anzugeben, um so Verwirrungen vorzubeugen.
3.7.5. Erweiterte Konzepte
Im folgenden noch einige erweiterte Konzepte, diese werden aber nicht intensiver
behandelt. Weitere erweiterte Konzepte werden bei Fallside (2001) dargestellt.
3.7.5.1.
Schema in mehreren Dokumenten
Ein Schema kann aus mehreren Dokumenten bestehen. Entscheidend dafür ist, daß die
Dokumente denselben Target-Namespace benutzen. Es können dabei mehrere
Dokumente inkludiert werden.
3.7.5.2.
Ableitung von Typen durch Erweiterung
Neue komplexe Typen können auch durch Erweiterung von bestehenden komplexen
Typen entstehen.
3.7.6. Beispiel eines XML-Schemas
Im Listing 3 (Abbildung 3) wird ein Beispiel für ein XML-Schema vorgestellt. Das
Schema ist Fallside (2001) entnommen.
In Zeile 1 wird zunächst der Namensraum xsd durch den folgenden Zugriffspfad
http://www.w3.org/2001/XMLSchema definiert. In den Zeilen 2 – 7 erfolgt ein
Kommentar (documentation) als Unterelement einer Annotation.
In Zeile 8 erfolgt die Deklaration eines Elements aus dem Namensraum xsd. D.h. der
Elementbegriff bezieht sich hier auf den Namensraum xsd. Der Name des Elements lautet
purchaseOrder, es ist vom Typ PurchaseOrderTyp.
In Zeile 9 wird das Element (ebenfalls xsd Element) comment deklariert. Dieses hat den
einfachen Typ string.
Der Typ PurchaseOrderType ist dagegen ein komplexer Typ (Zeile 10). Dieser besteht
aus einer Sequenz (sequence), d.h. einer Reihenfolge der folgenden Elemente:
•
shipTo vom Typ USAddress (Zeile 12); dieses Element erscheint genau einmal
•
billTo vom Typ USAddress (Zeile 13); dieses Element erscheint genau einmal
Edmund Buchbinder
24.06.02
Seite 20/33
•
comment (Zeile 14), hier beschrieben als Referenz zu dem in Zeile 9 definierten
Element. Das Element comment muß in der Sequenz nicht vorkommen, dies wird
ausgedrückt durch die Beschreibung minOccurs="0"
•
items (Zeile 15), dieses Element erscheint genau einmal.
In Zeile 16 wird die Sequenz der Elemente innerhalb des komplexen Typs
PurchaseOrderTyp
abgeschlossen.
Daneben
enthält
der
komplexe
Typ
PurchaseOrderTyp noch das Attribut orderDate (Zeile 17) vom einfachen Typ date aus
dem Namensraum xsd. In Zeile 18 wird die Definition des komplexen Typs
PurchaseOrderTyp abgeschlossen.
Ab Zeile 19 erfolgt die Definition des komplexen Typs USAddress, dieser besteht aus
einer Sequenz von Elementen einfachen Typs (Zeile 21-25). Daneben enthält er ein
Attribut vom Typ NMTOKEN aus dem Namensraum xsd. Dieses Attribut muß den Wert
US haben, wird es im abgeleiteten Dokument nicht verwendet, enthält es dort
automatisch den Wert US. Abgeschlossen wird die Definition des komplexen Typs
USAddress in Zeile 29.
Ab Zeile 30 erfolgt die Definition des komplexen Typs Items. Besonders interessant ist
hier zunächst die Zeile 32, dort wird das Element item definiert. Dieses muß minimal
überhaupt nicht auftreten (minOccurs="0") und darf maximal unbegrenzt auftreten
(maxOccurs="unbounded").
Daneben ist besonders die Definition des Typ des Elements quantity interessant. Diese
wird aus dem einfachen Typ positiveInteger abgeleitet, wobei in Zeile 39 festgelegt wird,
daß das Element in einem abgeleiteten Dokument maximal den Wert 100 (einschließlich)
annehmen darf.
Weiterhin von besonderen Interesse ist die Definition des einfachen Datentyps SKU
(steht für Stock Keeping Unit) ab Zeile 53. Dieser wird vom Typ String abgeleitet. Dabei
erfolgt eine Restriktion auf einen regulären Ausdruck (Zeile 54 und 55). In einem
abgeleiteten Dokument dürfen hier Inhalte der folgenden Art eingefügt werden: Zunächst
müssen drei Zahlen kommen, anschließend ein Bindestrich und zum Abschluß zwei
Großbuchstaben.
In Zeile 58 wird die Definition des Schemas abgeschlossen.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Purchase order schema for Example.com.
Copyright 2000 Example.com. All rights reserved.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
<xsd:element name="comment" type="xsd:string"/>
<xsd:complexType name="PurchaseOrderType">
<xsd:sequence>
<xsd:element name="shipTo" type="USAddress"/>
<xsd:element name="billTo" type="USAddress"/>
<xsd:element ref="comment" minOccurs="0"/>
<xsd:element name="items" type="Items"/>
</xsd:sequence>
<xsd:attribute name="orderDate" type="xsd:date"/>
</xsd:complexType>
<xsd:complexType name="USAddress">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
Edmund Buchbinder
24.06.02
Seite 21/33
24.
25.
23.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:decimal"/>
<xsd:element
name="city" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:NMTOKEN"
fixed="US"/>
</xsd:complexType>
<xsd:complexType name="Items">
<xsd:sequence>
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="productName" type="xsd:string"/>
<xsd:element name="quantity">
<xsd:simpleType>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxExclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="USPrice" type="xsd:decimal"/>
<xsd:element ref="comment" minOccurs="0"/>
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="partNum" type="SKU" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

<xsd:simpleType name="SKU">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{3}-[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
Abbildung 3: Listing 3, ein Beispiel für ein XML-Schema
3.7.7. Abarbeitung eines XML-Schemas
Der erste Schritt beginnt damit, daß das Wurzelelement überprüft wird, anschließend
wird jedes folgenden Element überprüft. Zunächst wird für jedes Element nachgesehen,
wo dieses Element im Schema deklariert wurde. Anschließend werden die Namensräume
für das Element kontrolliert. Ist die Überprüfung bis zu diesem Punkt erfolgreich, werden
die Inhalte und Attribute des entsprechenden Elements kontrolliert. Grundsätzlich wird
von Prozessoren verlangt, daß sie darüber Bericht erstatten, welche Prüfung sie gerade
ausführen.
3.8. XLink und XPointer
XLink und XPointer sind die in XML verwendeten Verknüpfungsmechanismen. XLink
beschreibt dabei, wie Links erstellt und durchquert werden. Es handelt sich dabei um eine
Erweiterung des aus HTML bekannten Anker-Tags und bietet die folgenden zusätzlichen
Möglichkeiten:
-
Links auf mehrere Zielorte
Edmund Buchbinder
24.06.02
Seite 22/33
-
bidirektionale Links
-
Links, die auf Dokumente zeigen, die nur zum Lesen bestimmt sind
-
Links, die mit beschreibenden Titeln versehen sind, die klar machen, wie der Link
verwendet wird
-
Links, die sich vor Ort erweitern (Transklusion genannt), um externen Inhalt in ein
XML-Dokument einzubetten, so wie derzeit Bilder eingebettet werden.
-
Links, die automatisch durchquert werden, wenn das Dokument geladen wird. Dies
kann den Einschluß externen Inhalts oder die Ersetzung einer Seite durch eine andere
zulassen.
XPointer ist als eine auf XPath beruhende Unterstützung für XLink zu sehen. XPointer
bietet alle Funktionen, die in XPath definiert sind, mit einigen Erweiterungen. Es stellt
damit erweiterte Methoden zur Verfügung, wie man auf bestimmte Standorte oder
Bereiche innerhalb von Dokumenten zeigen kann.
3.9. XML – Konvertierungen
3.9.1. CSS1 und CSS2
Cascading Style Sheets (CSS) 1 sind eigentlich die erste praktikable Methode für das
Web, in der die Darstellung der Daten vom Inhalt der Daten getrennt wurde. CSS wurde
inzwischen zu CSS 2 weiterentwickelt. Dabei wurde vor allem die Mächtigkeit im
typographischen Bereich ergänzt. Beim Einsatz von CSS ist allerdings immer die
Browserunterstützung zu beachten. Nicht alle im Web aktuell benutzten Browser
unterstützen CSS2.
Noch nicht leisten kann dagegen CSS das Erstellen von Inhaltsverzeichnissen, das
Sortieren von Listen vor der Ausgabe oder bestimmte ungewöhnliche Layouttechniken.
3.9.2. XSL
XSL steht für Extensible Style Language. XSL unterstützt z.B. das automatische
Erstellen von Inhalts- und Stichwortverzeichnissen. Von der Implementierung ähnelt
XSL stark XML und HTML, so daß hier von einer hohen Lernkurve für den Entwickler
ausgegangen werden kann. Auch XSL besitzt eine DTD, d.h. es kann validiert werden.
Von der Leistungsfähigkeit kann festgehalten werden, daß XSL fast den gesamten
Funktionsumfang von CSS1 und CSS 2 unterstützt.
Insgesamt besteht XSL aus drei Teilen: Das eigentliche XSL, XSLT (XSL
Transformations und Xpath (XML-Adressierungssprache).
4. XML-Tools
4.1. Darstellung von XML in Browsern
Die Darstellung von XML in Browsern ist noch sehr unterschiedlich. Auf jeden Fall ist
zu bedenken, daß nicht alle Benutzer Browser des neuesten Typs im Einsatz haben. Bei
validen Dokumenten ist zu bedenken, daß die Leser der entsprechenden Dokumente
Zugriff auf alle benötigten DTDs und XML-Schemata benötigen. Gleichzeitig wird das
Dokument nicht eher angezeigt, bis die Validität des Dokuments bestätigt ist. Eine Art
Streaming, wie sie gerade bei großen Dokumenten von Benutzern gewünscht wird, ist
damit nicht möglich.
Edmund Buchbinder
24.06.02
Seite 23/33
4.2. XML-Editoren
Der Markt bietet inzwischen eine Vielzahl von XML-Editoren jeglicher Preis- und
Leistungsstufe. Vor dem Einsatz im Projekt sind dabei vor allem die folgenden Aspekte
zu überprüfen:
•
Welche Dokumente können erstellt werden? Handelt es sich ausschließlich um
XML-Dokumente, oder können auch XML-Schemata oder DTDs erstellt werden.
•
Unterstützt der Editor eine Validierung bei der Eingabe?
•
Bietet der Editor nur die Elemente bei der Eingabe an, die laut XML-Schema oder
DTD erlaubt sind?
•
Wenn der Editor weniger für Entwickler als für Endbenutzer genutzt werden soll, ist
zu überprüfen, inwieweit die Oberfläche angepaßt werden kann. Daneben ist die
Frage zu stellen, ob die Editoren eine deutsche Benutzungs-Oberfläche anbieten.
4.3. XML-Prozessoren
Entscheidend ist zu überprüfen, wieweit die Prozessoren die XML Dokumente
verarbeiten. Der SAP XML Prozessor baut z.B. aus dem XML-Dokument einen Baum
auf, führt aber keinerlei Konsistenzprüfung durch. Das heißt, die Überprüfung nach der
Validität der Eingaben erfolgt durch die Applikation.
5. Einsatzmöglichkeiten in der Praxis
XML wird in der Praxis in zwei großen Bereichen eingesetzt. Auf der einen Seite wird es
genutzt, um einen einfachen Datenaustausch zwischen verschiedenen Systemen zu
ermöglichen. Langfristiges Ziel ist dabei, Standards zu etablieren und damit die
Schnittstellenproblematik (für jede Schnittstelle eine neu zu definierende
Schnittstellenvereinbarung zu schaffen) zu entschärfen. Gleichzeitig werden die
Schnittstellen für den menschlichen Nutzer leichter verständlich. Vor diesem Hintergrund
kann z.B. das Bestreben vieler Firmen gesehen werden, die EDI (Electronic Data
Interchange) –Schnittstellen langfristig durch XML Schnittstellen zu ersetzen:
Bisher war der EDI-Austausch eigentlich nur für große Firmen möglich, da zunächst das
genaue Datenformat in einem komplexen Projekt zwischen den Projektpartnern
ausgearbeitet werden mußte. Anschließend mußte das Datenformat in die entsprechende
IT noch implementiert werden. Alles in allem ist diese Anstrengung für kleinere Firmen
kaum zu leisten gewesen.
Der zweite große Einsatzpunkt von XML ist in der Dokumentenerzeugung und
Dokumentenpublikation. Hier bietet sich XML an, weil es eine saubere Trennung von
Format und Inhalt der Dokumente gibt. Gleichzeitig ist es in Zukunft immer wichtiger,
aus dem selben Inhalt die Information auf verschiedene Kanäle zielgruppengerecht
publizieren zu können. Denkbar ist hier, dieselben Inhalte einmal für eine Web-Site, für
eine Zeitschrift und für ein WAP-Handy aufzubereiten. Hierfür bietet sich der Einsatz
von XML in Ergänzung mit XSL und XSLT an.
6. Vorstellung
Projekt
„XML
als
Format
Instandhaltungsanweisungen der DB AG“
für
Qualität und Wirtschaftlichkeit der Instandhaltung ist ein langfristiges Ziel vieler
Großunternehmen, unter anderem auch der Deutschen Bahn. Das im folgenden
beschriebene Projekt bezieht sich dabei auf die Instandhaltung von fahrendem Material,
also Lokomotiven und Wagen.
Edmund Buchbinder
24.06.02
Seite 24/33
6.1. Anforderungen
Durch eine entsprechende IT-Lösung soll das oben beschriebene Ziel unterstützt werden.
Vom Auftraggeber wurden dabei u.a. die folgenden Anforderungen an die SoftwareLösung und Technologie gestellt:
•
Durchgängigkeit
der
Informationskette
von
den
Autoren
Instandhaltungsregelwerke bis zu den Arbeitsscheinen für die Handwerkern
•
Langfristig lesbares
Softwareherstellern
•
Entlastung technischer Redakteure von Formatierungsarbeiten an Dokumenten
•
Rechtssichere Ablage der Dokumente
•
Möglichkeit eines einfachen Dokumentenaustausch mit verschieden Herstellern von
Fahrzeugen
•
gezielter Zugriff auf einzelne Elemente der Dokumente (wie z.B. Meßwerte,
Betriebsstoffe etc.)
•
Integration in das bestehende PPS-System der Deutschen Bahn (Es handelt sich
hierbei um eine große SAP R/3 Installation)
•
Publikation der Information über verschiedene Kanäle
Dokumentformat
ohne
Abhängigkeit
von
der
einzelnen
6.2. Lösung
In einer Prototypenphase wurden verschiedene Ansätze untersucht, wie diese
Anforderungen erfüllt werden können.
Aufgrund dieser Anforderungen fiel die Entscheidung, XML-Dokumente auf Basis eines
selbst erstellten XML-Schemas im SAP R/3 System zu erzeugen. Dadurch ist die
Möglichkeit gegeben, die Dokumente auch langfristig lesen und bearbeiten zu können.
Die Dokumente werden im SAP R/3 System durch einen selbstentwickelten Editor
erstellt. Die Validierung der Eingaben erfolgt dabei durch die Anwendung und nicht
durch das XML-Schema. Die Begründung liegt darin, daß der SAP XML-Prozessor das
Konzept einer DTD oder eines XML-Schemas nicht unterstützt. Das Schema dient somit
zur Kommunikation mit den Benutzern, zur Dokumentation und zur Erzeugung eines
leeren Musterdokuments, welches im Editierprozess dann bearbeitet wird. Die
Dokumentenablage erfolgt in dem Dokumentenverwaltungssystem (DVS-Modul) von
SAP. Damit können die Standardmechanismen für Check-In, Check-out und
Versionierung von Dokumenten benutzt werden.
Durch den Ansatz, die Dokumente im SAP System zu erstellen, wird die Möglichkeit
geboten, Daten, die im SAP System vorliegen wie z.B. eindeutige Materialnummern,
Fahrzeugnummern, Instandhaltungsnummern etc. auszulesen und zu nutzen. Es wird
damit die gesamte Schnittstellenproblematik, die sonst bei einem externen Zugriff in das
SAP-System hinein notwendig wäre, erspart.
Um die Dokumente in einen langfristige lesbaren Zustand zu überführen und in diesem
auch zukünftig archivieren zu können, werden die Dokument auf Bedarf der Redakteure
und auf jeden Fall bei der Freigabe in ein PDF-Dokument konvertiert. Das Vorgehen
dafür ist in Abbildung 4 dargestellt. Zunächst erfolgt die Transformation in das logische
Layout mit Hilfe einer XSLT-Transformation. In einem zweiten Schritt wird dann das
logische Layout in das eigentlich grafische Layout mit Hilfe der Rendering Enginge
konvertiert.
Edmund Buchbinder
24.06.02
Seite 25/33
XML à PDF • PDTec Layout Engine (PLE)
Throughout the whole transformation process, PLE enables keeping
control over every layouting and rendering step.
n At first the XML document is transformed to a set of XML structures that
can be interpreted by the PLE or by the custom layout component.
n After that the custom layout component controls high-level aspects
such as page sequences and feeds appropriate XML fragments into the
PLE. The PLE creates the PDF document.
White-Box
Transformation
White-Box
Transformation
Custom Layout
Original
XML Document
1
XSLT
Intermediate
XML Document
2
Rendering
Engine
Business Semantics
PLE (PDTec
Layout Engine)
PDF
Document
PDF Driver
Logical Layout
Graphical Layout
© 2002 PDTec GmbH • ProSTEP Symposium • 2002-04-17 • Ehrler / Buchbinder • 1
Abbildung 4: Konvertierung XML in ein PDF-Dokument
Für die Konvertierung selbst wurde die in Abbildung 5 dargestellte Architektur gewählt.
Aus dem SAP heraus wird ein Rendering Service über eine RFC-Schnittstelle aufgerufen.
Dieser ist dann für die Konvertierung des Dokuments zuständig. Anschließend wird das
konvertierte Dokument ebenfalls in das Dokumentenverwaltungssystem von SAP
eingecheckt. Die ganze Architektur ist dadurch skalierbar, daß pro SAP System mehrere
Rendering-Server möglich sind.
Insgesamt wird durch den gewählten Ansatz das XML vor den einzelnen Redakteuren
vollkommen verborgen. Die Redakteure nehmen die Eingaben in der speziellen
Redakteursoberfläche vor. Dort werden auch die Arbeitsergebnisse korrigiert. Zur
Betrachtung des gesamten Dokuments steht pentweder die PDF-Konvertierung oder als
Schnellkonvertierung eine HTML-Konvertierung zur Verfügung. Als rechtsverbindlich
gelten nur die Dokumente im PDF Format.
Edmund Buchbinder
24.06.02
Seite 26/33
PDM/ERP Integration • Example: SAP R/3 PLM
HTML
XML
PDF
PDF
GIF
TIFF
SAP GUI
Local Filesystem
Frontend
RFC Server
profiles
Profiles
Custom Layout
SAP PLM Application
Rendering
Service
SAP PLM
PDTec Layout Engine
profiles
XSLT
(ABAP API)
Rendering
Engine
PDF Driver
Rendering Server
SAP R/3
© 2002 PDTec GmbH • ProSTEP Symposium • 2002-04-17 • Ehrler / Buchbinder • 1
Abbildung 5: Architektur zur Konvertierung der XML-Dokumente
6.3. Aktueller Projektstand
Aktuell werden Arbeitsanweisungen in dem oben beschriebenen System erstellt. Die
Akzeptanz durch die Benutzer ist sehr gut. Vor allem die nicht mehr notwendige
Formatierung der Dokumente, die bisher sehr viel Zeit in Anspruch genommen hat, wird
immer wieder positiv hervorgehoben. Der Auftraggeber sieht es sehr positiv, daß durch
den gewählten Ansatz eine Standardisierung in der Erstellung der Dokumente erreicht
wird.
Die nächsten Schritte bestehen darin, verschiedene Arbeitsanweisungen zu sogenannten
Instandhaltungsbüchern zusammenzufassen. In diesem Rahmen gehört es auch dazu, daß
Verzeichnisse z.B. von Grenzwerten oder Meßwerkzeugen über Arbeitsanweisungen
hinweg erstellt werden. Auch hier greift ein weiterer Vorteil des XML-Ansatzes, da hier
die entsprechenden Informationen sehr viel leichter aus den Dokumenten ausgelesen
werden können als dies z.B. in Word- oder Excel-Dokumenten der Fall wäre.
Im nächsten Release ist dann die vollständige Integration in das PPS-System geplant. In
diesem Projektschritt ist es wichtig, daß es einerseits eine sehr hohe Verfügbarkeit des
Systems geben muß. Andererseits muß die Integration sukzessive erfolgen. Für einen
gewissen Zeitraum müssen die bisherigen Auftragsdokumente und die neuen
Auftragsdokumente parallel arbeiten können.
6.4. Erfahrungen aus dem Projekt
Die erste Erfahrung, die im Rahmen diese Projektes gemacht wurde, war, daß die XMLUnterstützung, die die einzelnen Tools bieten, häufig nicht den MarketingVersprechungen der Hersteller entsprechen. Hier ist eine entsprechende Überprüfung auf
jeden Fall notwendig. Der Markt an XML-Experten in Deutschland ist ein wachsender
Markt, zu Beginn unseres Projekts war es eine Herausforderung, das nötige Know-How
vorzuhalten.
Eine wichtige Entscheidung im Projekt war, die Daten mit Hilfe eines XML-Schemas
und nicht einer DTD zu modellieren. Die Begründung liegt in der größeren Flexibilität
Edmund Buchbinder
24.06.02
Seite 27/33
und den genaueren Definitionsmöglichkeiten eines Schemas. Auch hier ist aber wieder
bei allen beteiligten Tools zu überprüfen, inwieweit diese XML-Schemas unterstützen.
Bei dem Design der Anwendung ist kritisch zu überprüfen, ob die Validierung der
einzelnen Eingaben durch die Anwendung oder das XML-Schema erfolgen soll. Beide
Ansätze haben Vorteile und sind in jedem Projekt für sich abzuwägen.
7. Zusammenfassung und Ausblick
XML bietet alle Möglichkeiten für einen plattform- und systemübergreifenden
Datenaustausch. Die Unterstützung durch entsprechende Tools nimmt immer weiter zu.
Aus meiner Sicht wird sich das XML-Schema langfristig gegenüber der DTD
durchsetzen, da es einerseits eine größere Flexibilität bietet, andererseits ermöglicht es
eine genauere Überprüfung der Eingaben.
Zukünftig wird es standardisierte XML-Schemata (oder auch DTDs) für bestimmte
Problembereiche oder Anwendungsfälle geben, die dann direkt genutzt und den
persönlichen Bedürfnissen angepaßt werden können.
Im Rahmen der Weiterentwicklung von XML muß allerdings darauf geachtet werden,
daß die Herstellerunabhängigkeit des Formats erhalten bleibt. Eine Entwicklung, wie sie
sich eine Zeitlang für HTML abzeichnete oder sich z.T. noch abzeichnet, muß auf jeden
Fall vermieden werden.
Es bleibt noch zu erwähnen, daß bei der Arbeit mit XML die Daten- und
Dokumentsicherheit besonders zu beachten ist, da die Informationen im
unverschlüsselten Zustand sowohl durch den Menschen als auch die Maschine leicht
auszulesen und auch zu manipulieren sind. Hier bietet sich der Einsatz der
entsprechenden Verschlüsselungs- bzw. Signatursoftware an.
Edmund Buchbinder
24.06.02
Seite 28/33
8. Verzeichnisse
8.1. Literaturverzeichnis
T. Bray, J. Paoli, C. M. Sperberg-McQueen und E. Maler. Extensible Markup Language
(XML).
Second
Edition,
W3C
Recommendation,
2000,
http:/www.w3.org/TR/REC-xml
D. C. Fallside. XML Schema Part 0: Primer, W3C Recommendation, 2001,
http://www.w3.org/TR/xmlschema-0/
S. Adler et al. Extensible Stylesheet Language (XSL), Version 1.0. W3C
Recommendation,2001, http://www.w3.org/TR/xsl/
J. Clark. XSL Transformations (XSLT), Version 1.0. W3C Recommendation, 2001,
http:// www.w3.org/TR/xsl/
A. Philips. XML Modernes Daten- und Dokumentenmanagement , 2002, Markt +
Technik
8.2. Abbildungsverzeichnis
Abbildung 1: Listing 1 XML-Dokument eines Firmenadreßbuchs.................................... 7
Abbildung 2: Listing 2 DTD für das Dokument aus Listing 1 ......................................... 16
Abbildung 3: Listing 3, ein Beispiel für ein XML-Schema ............................................. 22
Abbildung 4: Konvertierung XML in ein PDF-Dokument............................................... 26
Abbildung 5: Architektur zur Konvertierung der XML-Dokumente................................ 27
8.3. Tabellenverzeichnis
Tabelle 1: Auszeichnungen im XML.................................................................................. 6
Tabelle 2: Entity-Typen und ihre Auswirkung ................................................................. 12
Tabelle 3: Attributs-Datentypen in einer DTD................................................................. 14
Tabelle 4: Standarddaten für Attribute ............................................................................. 15
Tabelle 5: Frequenzindikatoren, die in XML-DTDs verwendet werden.......................... 15
Tabelle 6 : Simple Typen (Tabelle aus Fallside, 2001) .................................................... 18
Edmund Buchbinder
24.06.02
Seite 29/33
9. Anhang
9.1. Anhang:vollständige
Nauer-Form
XML-Grammatik
in
Extended-Backus-
[1] document ::= prolog element Misc*
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
[3] S ::= (#x20 | #x9 | #xD | #xA)+ /* Whitespace is space, tab, cr, lf */
[4] NameChar ::= Letter | Digit | ‘.’ | ‘-’ | ‘_’ | ‘:’ | CombiningChar | Extender
[5] Name ::= (Letter | ‘_’ | ‘:’) (NameChar)*
[6] Names ::= Name (#x20 Name)*
[7] Nmtoken ::= (NameChar)+
[8] Nmtokens ::= Nmtoken (#x20 Nmtoken)*
[9] EntityValue ::= ‘“‘ ([^%&”] | PEReference | Reference)* ‘“‘ | “‘“ ([^%&’] | PEReference |
Reference)* “‘“
[10] AttValue ::= ‘“‘ ([^<&”] | Reference)* ‘“‘ | “‘“ ([^<&’] | Reference)* “‘“
[11] SystemLiteral ::= (‘“‘ [^”]* ‘“‘) | (“‘“ [^’]* “‘“)
[12] PubidLiteral ::= ‘“‘ PubidChar* ‘“‘ | “‘“ (PubidChar - “‘“)* “‘“
[13] PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-’()+,./:=?;!*#@$_%]
[14] CharData ::= [^<&]* - ([^<&]* ‘]]>’ [^<&]*)
[15] Comment ::= ‘’
[16] PI ::= ‘<?’ PITarget (S (Char* - (Char* ‘?>’ Char*)))? ‘?>’
[17] PITarget ::= Name - ((‘X’ | ‘x’) (‘M’ | ‘m’) (‘L’ | ‘l’))
[18] CDSect ::= CDStart CData CDEnd
[19] CDStart ::= ‘<![CDATA[‘
[20] CData ::= (Char* - (Char* ‘]]>’ Char*))
[21] CDEnd ::= ‘]]>’
[22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?
[23] XMLDecl ::= ‘<?xml’ VersionInfo EncodingDecl? SDDecl? S? ‘?>’
[24] VersionInfo ::= S ‘version’ Eq (“‘“ VersionNum “‘“ | ‘“‘ VersionNum ‘“‘)
[25] Eq ::= S? ‘=’ S?
[26] VersionNum ::= ([a-zA-Z0-9_.:] | ‘-’)+
[27] Misc ::= Comment | PI | S
[28] doctypedecl ::= ‘<!DOCTYPE’ S Name (S ExternalID)? S? (‘[‘ (markupdecl | PEReference |
S)* ‘]’ S?)? ‘>’ [ VC: Root Element Type ]
[29] markupdecl ::= elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment [ VC:
Proper Declaration/PE Nesting ] [ WFC: PEs in Internal Subset ]
[30] extSubset ::= TextDecl? extSubsetDecl
[31] extSubsetDecl ::= ( markupdecl | conditionalSect | PEReference | S )*
[32] SDDecl ::= S ‘standalone’ Eq ((“‘“ (‘yes’ | ‘no’) “‘“) | (‘“‘ (‘yes’ | ‘no’) ‘“‘)) [ VC:
Standalone Document Declaration ]
[33] LanguageID ::= Langcode (‘-’ Subcode)*
Edmund Buchbinder
24.06.02
Seite 30/33
[34] Langcode ::= ISO639Code | IanaCode | UserCode
[35] ISO639Code ::= ([a-z] | [A-Z]) ([a-z] | [A-Z])
[36] IanaCode ::= (‘i’ | ‘I’) ‘-’ ([a-z] | [A-Z])+
[37] UserCode ::= (‘x’ | ‘X’) ‘-’ ([a-z] | [A-Z])+
[38] Subcode ::= ([a-z] | [A-Z])+
[39] element ::= EmptyElemTag | STag content ETag [ WFC: Element Type Match ] [ VC:
Element Valid ]
[40] STag ::= ‘<’ Name (S Attribute)* S? ‘>’ [ WFC: Unique Att Spec ]
[41] Attribute ::= Name Eq AttValue [ VC: Attribute Value Type ] [ VC: Valid xml:lang ] [ WFC:
No External Entity References ] [ WFC: No < in Attribute Values ]
[42] ETag ::= ‘</’ Name S? ‘>’
[43] content ::= (element | CharData | Reference | CDSect | PI | Comment)*
[44] EmptyElemTag ::= ‘<’ Name (S Attribute)* S? ‘/>’ [ WFC: Unique Att Spec ]
[45] elementdecl ::= ‘<!ELEMENT’ S Name S contentspec S? ‘>’ [ VC: Unique Element Type
Declaration ]
[46] contentspec ::= ‘EMPTY’ | ‘ANY’ | Mixed | children
[47] children ::= (choice | seq) (‘?’ | ‘*’ | ‘+’)?
[48] cp ::= (Name | choice | seq) (‘?’ | ‘*’ | ‘+’)?
[49] choice ::= ‘(‘ S? cp ( S? ‘|’ S? cp )+ S? ‘)’ [ VC: Proper Group/PE Nesting ]
[50] seq ::= ‘(‘ S? cp ( S? ‘,’ S? cp )* S? ‘)’ [ VC: Proper Group/PE Nesting ]
[51] Mixed ::= ‘(‘ S? ‘#PCDATA’ (S? ‘|’ S? Name)* S? ‘)*’ | ‘(‘ S? ‘#PCDATA’ S? ‘)’ [ VC:
Proper Group/PE Nesting ] [ VC: No Duplicate Types ]
[52] AttlistDecl ::= ‘<!ATTLIST’ S Name AttDef* S? ‘>’
[53] AttDef ::= S Name S AttType S DefaultDecl
[54] AttType ::= StringType | TokenizedType | EnumeratedType
[55] StringType ::= ‘CDATA’
[56] TokenizedType ::= ‘ID’ [ VC: ID ] [ VC: One ID per Element Type ] [ VC: ID Attribute
Default ] | ‘IDREF’ [ VC: IDREF ] | ‘IDREFS’ [ VC: IDREF ] | ‘ENTITY’ [ VC: Entity Name ] |
‘ENTITIES’ [ VC: Entity Name ] | ‘NMTOKEN’ [ VC: Name Token ] | ‘NMTOKENS’ [ VC:
Name Token ]
[57] EnumeratedType ::= NotationType | Enumeration
[58] NotationType ::= ‘NOTATION’ S ‘(‘ S? Name (S? ‘|’ S? Name)* S? ‘)’ [ VC: Notation
Attributes ] [ VC: One Notation per Element Type ]
[59] Enumeration ::= ‘(‘ S? Nmtoken (S? ‘|’ S? Nmtoken)* S? ‘)’ [ VC: Enumeration ]
[60] DefaultDecl ::= ‘#REQUIRED’ | ‘#IMPLIED’ | ((‘#FIXED’ S)? AttValue) [ VC: Required
Attribute ] [ VC: Attribute Default Legal ] [ WFC: No < in Attribute Values ] [ VC: Fixed
Attribute Default ]
[61] conditionalSect ::= includeSect | ignoreSect
[62] includeSect ::= ‘<![‘ S? ‘INCLUDE’ S? ‘[‘ extSubsetDecl ‘]]>’
[63] ignoreSect ::= ‘<![‘ S? ‘IGNORE’ S? ‘[‘ ignoreSectContents* ‘]]>’
[64] ignoreSectContents ::= Ignore (‘<![‘ ignoreSectContents ‘]]>’ Ignore)*
[65] Ignore ::= Char* - (Char* (‘<![‘ | ‘]]>’) Char*)
[66] CharRef ::= ‘&#’ [0-9]+ ‘;’ | ‘&#x’ [0-9a-fA-F]+ ‘;’ [ WFC: Legal Character ]
[67] Reference ::= EntityRef | CharRef
Edmund Buchbinder
24.06.02
Seite 31/33
[68] EntityRef ::= ‘&’ Name ‘;’ [ WFC: Entity Declared ] [ VC: Entity Declared ] [ WFC: Parsed
Entity ] [ WFC: No Recursion ]
[69] PEReference ::= ‘%’ Name ‘;’ [ VC: Entity Declared ] [ WFC: No Recursion ] [ WFC: In
DTD ]
[70] EntityDecl ::= GEDecl | PEDecl
[71] GEDecl ::= ‘<!ENTITY’ S Name S EntityDef S? ‘>’
[72] PEDecl ::= ‘<!ENTITY’ S ‘%’ S Name S PEDef S? ‘>’
[73] EntityDef ::= EntityValue | (ExternalID NDataDecl?)
[74] PEDef ::= EntityValue | ExternalID
[75] ExternalID ::= ‘SYSTEM’ S SystemLiteral | ‘PUBLIC’ S PubidLiteral S SystemLiteral
[76] NDataDecl ::= S ‘NDATA’ S Name [ VC: Notation Declared ]
[77] TextDecl ::= ‘<?xml’ VersionInfo? EncodingDecl S? ‘?>’
[78] extParsedEnt ::= TextDecl? content
[79] extPE ::= TextDecl? extSubsetDecl
[80] EncodingDecl ::= S ‘encoding’ Eq (‘“‘ EncName ‘“‘ | “‘“ EncName “‘“ )
[81] EncName ::= [A-Za-z] ([A-Za-z0-9._] | ‘-’)* /* Encoding name contains only Latin characters
*/
[82] NotationDecl ::= ‘<!NOTATION’ S Name S (ExternalID | PublicID) S? ‘>’
[83] PublicID ::= ‘PUBLIC’ S PubidLiteral
[84] Letter ::= BaseChar | Ideographic
[85] BaseChar ::= [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] |
[#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] |
[#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8]
| [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] |
[#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] |
[#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] |
[#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE]
| [#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] |
[#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] |
[#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85#x0A8B] | #x0A8D | [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] |
[#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D |
[#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92#x0B95] | [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10] |
[#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61] | [#x0C85#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] |
#x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28] |
[#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 | [#x0E32-#x0E33] |
[#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A | #x0E8D | [#x0E94#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 | [#x0EAA-#x0EAB] |
[#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4] | [#x0F40#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103] |
[#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112] | #x113C | #x113E | #x1140 |
#x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159 | [#x115F-#x1161] | #x1163 | #x1165 |
#x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173] | #x1175 | #x119E | #x11A8 | #x11AB |
[#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9
| [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-
Edmund Buchbinder
24.06.02
Seite 32/33
#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] |
[#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] |
[#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3]
[86] Ideographic ::= [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87] CombiningChar ::= [#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 |
[#x064B-#x0652] | #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] |
[#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D |
[#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF | [#x09C0#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02 |
#x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] |
[#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] |
[#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48] |
[#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] |
[#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57 | #x0E31 | [#x0E34-#x0E3A] |
[#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] |
[#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39 | #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86#x0F8B] | [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 |
[#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F] | #x3099 | #x309A
[88] Digit ::= [#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F] |
[#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] |
[#x0ED0-#x0ED9] | [#x0F20-#x0F29]
[89] Extender ::= #x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 | #x0EC6 | #x3005 |
[#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]
Edmund Buchbinder
24.06.02
Seite 33/33
/RUHO
HLQH#$QIUDJHVSUDFKH#I•U#VHPLVWUXNWXULHUWH#'DWHQ
$XVDUEHLWXQJ#HLQHV#5HIHUDWV#LP#5DKPHQ#GHV
6HPLQDUV#4<45#%;0/#XQG#'DWHQEDQNHQ%/#66#5335
/HKUJHELHW#3UDNWLVFKH#,QIRUPDWLN#,9
Zugrundeliegender Artikel:
S. Abiteboul, D. Quass, J. McHugh, J. Widom und J.L. Wiener. The Lorel Query Language for
Semistructured Data. International Journal on Digital Libraries 1 (1), 68-88, 1997.
http://dbpubs.stanford.edu:8090/pub/1996-36
Inga Overkamp
Matrikel-Nr: q5688493
Studiengang Informatik (Bachelor)
München, den 16.06.2002
,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I•U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335
,QKDOWVYHU]HLFKQLV
4
(,1/(,781* 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111116
5
=8*581'(/,(*(1'(#'$7(102'(//( 11111111111111111111111111111111111111111111111111111111111111111117
514
2%-(&7#(;&+$1*(#02'(/#+2(0,111111111111111111111111111111111111111111111111111111111111111111111111111111111 7
515
2%-(&7#'$7$%$6(#0$1$*(0(17#*5283#+2'0*, 111111111111111111111111111111111111111111111111111111111111 8
6
/25(/#$/6#$1)5$*(0635$&+( 1111111111111111111111111111111111111111111111111111111111111111111111111119
614
&2(5&,211111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 9
615
9(5:(1'81*#921#(,1)$&+(1#3)$'$86'5h&.(1 11111111111111111111111111111111111111111111111111111111111111 :
616
9(5:(1'81*#921#$//*(0(,1(1#3)$'$86'5h&.(1 11111111111111111111111111111111111111111111111111111111111 ;
617
5(68/7$7(#921#/25(/0$1)5$*(1 1111111111111111111111111111111111111111111111111111111111111111111111111111111 43
7
/25(/#$/6#83'$7(0635$&+( 111111111111111111111111111111111111111111111111111111111111111111111111111 43
714
2%-(.7(567(//81*11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 44
715
1$0(16=8:(,681*(1 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 44
716
2%-(.783'$7(6 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 44
717
%8/.#/2$',1* 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 45
8
/25(/#,03/(0(17,(581*#,0#/25(#6<67(0 111111111111111111111111111111111111111111111111111111111 45
9
=86$00(1)$6681*#81'#6&+/8‰ 1111111111111111111111111111111111111111111111111111111111111111111111 45
:
/,7(5$7859(5=(,&+1,61111111111111111111111111111111111111111111111111111111111111111111111111111111111 47
2
4 (LQOHLWXQJ
Die Entwicklung des World Wide Web (WWW), eines multimedialen Hypertextsystems für dezentrale
Netzwerke auf der Basis des TCP/IP Protokolls, löste Anfang der 90er Jahre einen exponentiellen
Anstieg des weltweiten Datenaustausches aus. Aufgrund der verteilt erstellten Datensammlungen und
der hohen Dynamik des Internets sind diese Daten in ihrer Mehrheit lediglich semistrukturiert, ihre
Struktur ist also häufig
• implizit, d.h. ohne explizite Beschreibung des zugrundeliegenden Schemas
• irregulär, d.h. die Objekte können fehlen bzw. mehrmals auftreten und die verwendeten
Datentypen sind nicht zwangsläufig einheitlich
• partiell, d.h. neben strukturierten Daten können auch unformatierte Textelemente oder binäre
1
Daten abgelegt sein
Die Verwaltung von Daten ohne strenge Typisierung stellt spezielle Anforderungen an das verwendete
Datenbank Management System (DBMS). Beim Aufbau relationaler und objektorientierter Datenbanken
muss zunächst ein konzeptionelles Modell definiert werden. Diese Schemabildung setzt eine vollständige
Kenntnis der vorhandenen Strukturen und Beziehungen voraus. Gemäß ihrer Definition besitzen
semistrukturierte Daten solche einheitlichen und vollständigen Strukturen gerade nicht. Darüber hinaus
sollen die Datenbanken flexibel genug sein, um die dynamische Weiterentwicklung der semistrukturierten
Daten und ihrer Anwendungen abbilden zu können.
Für das effektive Retrieval von implizit und irregulär strukturierten Daten sollte das DBMS Mechanismen
zur Verfügung stellen, anhand derer Anfragen an die Datenbank formuliert werden können, ohne dass die
Struktur der Daten im Detail bekannt sein muss. Weiterhin sollten Anfragesprachen für semistrukturierte
Daten nicht lediglich die Inhalte der Datenbank, sondern auch die Struktur selber suchbar machen.
Insgesamt sind also die konventionellen DBMS nicht zur Verwaltung von semistrukturierten Daten
geeignet und daher wurde nach neuen Ansätzen gesucht.
2
Mit dem „Lightweight Object Repository“ (Lore) begann die Datenbank-Gruppe der Universität Stanford
1995 ein Projekt, das die Entwicklung eines Systems zur effektiven Verwaltung von semistrukturierten
Daten aus heterogenen Quellen zum Ziel hatte. Dabei basierte Lore zunächst auf einem eigenen Datenmodell (OEM). In den folgenden Jahren setzte sich XML als Quasi-Standard für die Repräsentation und
den Austausch von Daten im WWW durch. An dem ursprünglichen Lore-Datenmodell wurden daher 1999
einige Änderungen vorgenommen, um die Verwaltung von XML-Dokumenten vollständig unterstützen zu
3
können .
Die Datenmanipulationssprache Lorel („Lore Language“), die innerhalb dieses Projekts entwickelt wurde,
ist syntaktisch an die deklarative Object Query Language (OQL) angelehnt. Obwohl Lorel speziell als
Anfragesprache für Daten im Lore System entwickelt wurde, kann sie auch auf objektorientierte DBMS
übertragen werden. Die in der zugrundeliegenden Arbeit beschriebene Beispiel-Implementierung wird in
4
dieser schriftlichen Ausarbeitung allerdings nicht behandelt werden .
Die vorliegende schriftliche Ausarbeitung führt in Kapitel 2 zunächst kurz die dem Lore System
zugrundeliegenden Datenmodelle ein. In Kapitel 3 und 4 werden die wesentlichen Erweiterungen von
Lorel im Vergleich zu OQL dargestellt:
• Einführung von Mechanismen zur Umformung von Datentypen (Type Coercion)
• Verwendung von regulären Ausdrücken in Pfadangaben zur Abfrage von Daten in unbekannten
Strukturen
• Implementierung von Befehlen zur Datenmanipulation
Kapitel 5 gibt eine kurzen Einblick in die Implementierung der Lorel Anfragesprache im Lore DBMS und
im Kapitel 6 wird versucht, die in dieser Ausarbeitung vorgestellten Konzepte kritisch zu beurteilen.
1
vgl. (Greiner, 1999) und den entsprechenden Eintrag im Internet-Lexikon der Gesellschaft für Informatik: http://giserver.giev.de/informatik/lexikon
2
Weiterführende Informationen zu LORE finden sich auf der Projekt-Hompage: http://www-db.stanford.edu/lore
3
Die vorgenommenen Änderungen bei der Migration des Datenmodells auf XML sind ausführlich in (Goldman et al, 2000)
beschrieben
4
vgl. (Abiteboul et al, 1997, S. 83f)
3
5 =XJUXQGHOLHJHQGH#'DWHQPRGHOOH
Dieses Kapitel gibt einen Überblick über die Datenmodelle, die bei der Entwicklung des Lore-DBMS
berücksichtigt wurden.
514 2EMHFW#([FKDQJH#0RGHO#+2(0,
OEM ist ein Datenmodell, das für die Darstellung von semistrukturierten Daten geeignet ist. Ursprünglich
an der Universität Stanford für das Tsimmis Projekt (The Stanford-IBM Manager of Multiple Information
Sources) entwickelt, wurde das Modell im Sinne der Interoperabilität anschließend weiteren Projekten wie
3
5
zum Beispiel Lore und C zugrunde gelegt . Im Gegensatz zu XML gibt es in OEM kein Konzept zur
expliziten Beschreibung der Grammatik in Form von Document Type Defintions (DTD).
Ein Datenmodell zur Beschreibung semistrukturierter Daten muss sehr flexibel sein, um uneinheitliche
Ansammlungen von Informationen abbilden zu können. Im OEM werden Daten und ihre Beziehungen
untereinander als gerichtete Graphen dargestellt, wobei die OEM-Objekte durch die Knoten und ihre
Attribute durch die beschrifteten Kanten (Labels) repräsentiert werden. Jedem Objekt wird ein eindeutiger
Bezeichner (engl. "object identifier" = oid) zugewiesen. Man unterscheidet zwischen atomaren und
komplexen Objekten:
• Atomare Objekte sind die Blätter des OEM-Graphen. Sie enthalten Werte beliebiger
Basisdatentypen, z. B. integer, string, gif, mpeg, java.
• Alle restlichen Knoten im OEM-Graph werden als komplexe (zusammengesetzte) Objekte
betrachtet. Diese bestehen aus einer Menge von Attributen, die wiederum „Subobjekte“, d.h.
Referenzen auf untergeordnete Objekte sind. Objektreferenzen werden als Paar (Label, oid)
dargestellt.
Darüber hinaus besitzt jeder OEM-Graph mindestens eine benannte Wurzel, von der alle anderen
Objekte erreichbar sein müssen, wobei Zyklen innerhalb des Graphen erlaubt sind.
Die folgende Abbildung zeigt einen OEM Graphen für eine Datenbank zur Hausverwaltung:
Hausverwaltung
&1
Haus
Haus
Nachbarhaus
&2
&12
Nachbarhaus
PLZ
&3
81541
Straße
&4
Ort Wohnung
&6
&5
„Hagener
„München“
Str. 14“
Zimmerzahl Miete
&7
Wohnung Wohnung
&8
&13
Mieter
Besitzer
&44
Mieter
&21
3
&45
&49
„I. Overkamp“ 19555555
5
&15
qm
Name
qm qm
&14
78
Name KontoNr
Adresse
&16
&25
Besitzer
Ort
&31
&39
PLZ
Strasse
&26
&27
„München“ „81541“ „Hagener
Str. 12“
Vorname Nachname Ort Postleitzahl
112
&22
&32
&33
&34
&35
„Knut Frick“
„Meike“
„Schmidt“
„Hagen“
58084
Eine vollständige Beschreibung des Object Exchange Model findet sich bei (Goldman et al, 1996).
4
Der Knoten mit der oid &1 ist die Wurzel und gleichzeitig auch ein komplexes Objekt des OEM-Graphen
für die Datenbank zur Hausverwaltung. Weitere Beispiele für komplexe Objekte sind die Knoten &2, &6
und &31. Jedes komplexe Objekt besitzt eine Reihe von Attributen bzw. Referenzen auf Subobjekte, für
das Objekt &2 sind dies z.B. (Postleitzahl, &3), (Straße, &4), (Ort, &5), (Wohnung, &6)
und (Nachbarhaus, &12). Die Knoten &3, &4 und &26 repräsentieren atomare Objekte, die Werte
unterschiedlicher Basisdatentypen enthalten: 81541 ist vom Typ integer, während „Hagener Str. 14“ und
„81541“ als Zeichenketten (Strings) abgelegt sind.
Eine textuelle Darstellung obiger OEM-Datenbank könnte wie folgt aussehen:
Hausverwaltung &1
Haus &2
PLZ &3 81541
Straße &4 "Hagener Str. 14"
Ort &5 "München"
Wohnung &6
Zimmerzahl &7 3
Miete &8 "850 •%
Mieter &44
Name &45 "I. Overkamp"
KontoNr &49 19555555
Nachbarhaus &12
Haus &12
Nachbarhaus &2
Wohnung &13
qm &14 78
qm &16 112
Besitzer &44
Mieter &21
Name &22 "Knut Frick"
Wohnung &15
qm &16
Besitzer &31
Vorname &32 "Meike"
Nachname &33 "Schmidt"
Ort &34 "Hagen"
Postleitzahl &35 58084
Adresse &25
Ort &39 "München"
PLZ &26 "81514"
Strasse &27 "Hagener Str. 12"
Die Hausverwaltungs-Datenbank verdeutlicht die potentielle Irregularität semistrukturierter Daten.
Inhaltsverwandte Objekte können z. B.
•
uneinheitlich bezeichnet sein: „Postleitzahl“ <#Ä3/=³
•
in verschiedenen Ebenen innerhalb der Struktur abgelegt sein: „Straße“
•
unterschiedliche Attribute bzw. Subobjekte umfassen: Besitzer = „Name“, „KontoNr“, „Vorname“,
„Nachname“, „Ort“, „PLZ“
•
einzelne Attribute bzw. Subobjekte nicht oder wiederholt enthalten: „Wohnung“
•
von unterschiedlichem Datentyp sein: „PLZ“
515 2EMHFW#'DWDEDVH#0DQDJHPHQW#*URXS#+2'0*,
Anfang der 90er Jahre haben sich führenden Hersteller von objektorientierten Datenbank Management
Systemen (ODBMS) zur ODMG zusammengeschlossen und gemeinsam ein Datenmodell für
6
objektorientierte Datenbanken definiert . Der ODMG-Standard umfasst u.a. die Object Query Language
(OQL) zur Bildung von Anfragen auf Datenbankobjekten, die der SQL-Syntax angelehnt ist.
6
Weiterführende Informationen zum ODMG finden sich auf deren Homepage: http://www.odmg.org
5
Mit den folgenden Anpassungen ist es möglich, OEM Objekte ins ODMG Datenmodell zu integrieren:
•
Einführung von speziellen OEM-Datentypen ins ODMG Modell, z.B. OEM , OEMcomplex,
OEMstring, ..., OEMnil
•
Direkte Umsetzung der atomaren OEM-Objekte ins ODMG Datenmodell
•
Erweiterung der komplexen OEM-Objekte zu einheitlichen Tupeln aller in der Datenbank
vorkommenden Attribute. Als Konsequenz sind die komplexen Objekte anschließend alle vom
gleichen Datentyp (OEMcomplex).
7
6 /RUHO#DOV#$QIUDJH06SUDFKH
Um semistrukturierte Daten erfolgreich und effektiv abfragen zu können, wurde Lorel gegenüber OQL um
einige mächtige Mechanismen zur Typanpassung (Type Coercion) und zur Formulierung von
Pfadausdrücken erweitert.
614 &RHUFLRQ
Semistrukturierte Daten sind irregulär und daher würden strukturbasierte Anfragen an diese Daten
regelmäßig Fehlermeldungen zurückliefern. Folgende OQL-Anfragen können in der HausverwaltungsDatenbank aus Kap. 2.1 nicht erfolgreich abgearbeitet werden:
Beispiel 1:
select H.Wohnung
from Hausverwaltung.Haus H
where H.PLZ = "81541"
Fehlermeldung, da unterschiedliche Datentypen
(string <#LQWHJHU,#PLWHLQDQGHU#YHUJOLFKHQ#ZHUGHQ
sollen
Beispiel 2:
select W.Besitzer
from Hausverwaltung.Haus H,
H.Wohnung W
where W.qm = 78
Fehlermeldung, da in der where-Klausel versucht
wird, eine Vergleichsoperation auf einer Menge von
Zahlen durchzuführen (W.qm liefert für das Objekt
&13 die Ergebnismenge {78, 112})
Beim Retrieval nach semistrukturierten Daten können beim Nutzer keine detaillierten Kenntnisse über die
Struktur der komplexen Objekten oder über die präzisen Datentypen der atomaren Objekte vorausgesetzt
werden. Die Entwickler von Lorel haben den Grundsatz: „Doing the intuitive thing“ geprägt (vgl. Abiteboul,
1997, S. 73). Sie meinen damit, dass Lorel-Anfragen, die Sinn machen, keine Laufzeitfehler bei der
Ausführung auf OEM-Daten erzeugen sollen.
Zur Umsetzung der obigen Anfragen werden in Lorel Anpassungen (Coercion) auf verschiedenen
Ebenen vorgenommen:
• Beispiel 1: Vergleich von atomaren Objekten mit Werten
Zunächst müssen die atomaren Objekte dereferenziert und anschließend in vergleichbare Werte
konvertiert werden (Type Coercion). Die Umformung geschieht anhand von TypanpassungsRegeln, die vorher für alle in der Datenbank vorkommenden Basisdatentypen in Bezug auf die
gültigen Operationen definiert werden müssen. Ist für den Wert des atomaren Objektes keine
Umsetzung in den erforderlichen Datentyp möglich, wird der Rückgabewert false generiert.
Für die Auswertung der Gleichheitsoperation zwischen Werten der Typen integer und string
8
könnten z.B. folgende Regeln gelten :
81541 = 81541
Zwei integer Werte können ohne Umformung miteinander
verglichen werden. Rückgabewert: true
81541 = "test"
Der String kann nicht in einen integer Wert umgeformt
werden. Rückgabewert: false
81541 = "081541"
Die Umformung gelingt und anschließend wird ein Vergleich
durchgeführt. Rückgabewert: true
"81541" = "081541"
Beide Operanden sind vom Typ string und müssen daher
nicht umgeformt werden. Rückgabewert false
7
Der Typ OEM bildet eine Obermenge über die restlichen OEM-Datentypen
Obwohl in dem Beispiel lediglich der Gleichheitsoperator angewendet wird, gelten die Regel auch für die restlichen arithmetischen
Vergleichsoperationen, z.B.: <, >, ≠
8
6
• Beispiel 2: Vergleich eines Werts / atomaren Objektes mit einer Objektmenge
Um die zweite Anfrage gemäß den Erwartungen des Nutzers zu gestalten, wird bei der Umsetzung
der WHERE-Anfrage durch Lorel automatisch ein Existenz-Operator eingefügt:
where exists Q in W.qm : Q = 78
Die Variable Q wird nun nacheinander mit den Objekten aus der Objektmenge belegt. Im Anschluß
an die zusätzlich notwendige Type Coercion (s.o.) können die Vergleichsoperationen auf den
Werten durchgeführt werden.
Das letzte Beispiel macht bereits deutlich, dass Lorel die Rückgabe zu einer Anfrage immer als Menge
9
von OEM-Objekten interpretiert . Falls die abgefragten Attribute bei den betrachteten Objekten fehlen,
wird eine leere Ergebnismenge zurückgeliefert. Da die Abfrage der Existenz eines Elementes auf einer
leeren Menge lediglich ein Spezialfall der allgemeinen Operation ist, wird auch in diesen Fällen nie eine
Fehlermeldung ausgelöst.
Zur Vollständigkeit seien noch folgende Gleichheitsoperationen genannt:
• Vergleich zwischen Objekten: Bei der Prüfung der Objektidentität wird analog zu OQL true
zurückgeliefert, falls oid1 = oid2 gilt.
Darüber hinaus führt Lorel einen weiteren Vergleichsoperator (==) ausschließlich für atomare
Objekte ein. Dieser testet im Gegensatz zur Objektidentität, ob die Werte der Objekte gleich sind.
• Vergleich zwischen Objektmengen: Überprüfung der Mengenidentität, d.h. für jedes Objekt der
einen Menge muss ein identisches Objekt in der anderen Menge existieren.
• Vergleich eines Werts, atomaren Objektes oder einer Objektmenge mit einem komplexen
Objekt: Da es nicht eindeutig ist, welche Subobjekte des komplexen Objektes für den Vergleich
herangezogen werden sollen, wird false zurückgeliefert.
• Vergleich von String-Werten atomarer Objekte: Für den Vergleich von Zeichenketten stellt Lorel
zusätzliche Operatoren wie z.B. grep (Zeichenketten-Übereinstimmung) oder soundex
(phonetische Übereinstimmung) zur Verfügung.
615 9HUZHQGXQJ#YRQ#HLQIDFKHQ#3IDGDXVGU•FNHQ
Die Verwendung von Pfadangaben zur Selektion einer Menge von Objekten entspricht dem Durchlaufen
des gerichteten OEM-Graphen von einem benannten Einstiegspunkt bis zum Zielobjekt. Der Pfadausdruck setzt sich aus der Sequenz aller zwischen den beiden Objekten liegenden Kantenbezeichnungen
zusammen. Dabei ist darauf zu achten, das ein Lorel-Pfadausdruck einen, keinen oder auch mehrere
Datenpfade referenzieren kann, z.B.
Pfadausdruck: Hausverwaltung.Haus.Wohnung.Besitzer
Datenpfad1:
Hausverwaltung,&1,Haus,&12,Wohnung,&13,Besitzer,&44
Datenpfad2:
Hausverwaltung,&1,Haus,&12,Wohnung,&15,Besitzer,&31
Einfache Pfadausdrücke sind nicht mehr als syntaktische Bequemlichkeiten, sie werden bei der
Ausführung durch das Lore-System auf OQL-ähnliche Anfragen zurückgeführt. Je nachdem in welchem
Zusammenhang die Pfadangabe verwendet wird, müssen bei der Umsetzung spezifische Regeln
beachtete werden:
• FROM-Anweisung - Für jede Kantenbezeichnung der verwendeten Pfadangabe wird eine Variable
eingeführt. Bei Lorel-Anfragen ohne FROM-Klausel wird diese aus der SELECT-Anweisung
generiert.
• SELECT-Anweisung - Falls der vollständige Pfad bereits in der FROM-Anweisung benutzt wurde,
wird die entsprechende Variable wiederverwendet. Ansonsten muss der (Rest-) Pfad anhand einer
verschachtelten SELECT-Anweisung umgesetzt werden:
select Hausverwaltung.Haus.Adresse.Ort
Lorel-Anfrage
from Hausverwaltung.Haus.Wohnung.Mieter M
where M.Name = "Knut Frick"
select (select O from H.Adresse A, A.Ort O)
OQL-Anfrage mit
from Hausverwaltung.Haus H,
verschachtelter
H.Wohnung W,
Select-Anweisung
W.Mieter M
where M.Name = "Knut Frick"
9
Auf die genaue Struktur der Ergebnis-Mengen in Lorel wird in Kap. 3.4 eingegangen
7
• WHERE-Anweisung - Auch hier werden zunächst die entsprechenden Variablen aus der FROMAnweisung wiederverwendet. Falls der benötigte Pfad noch nicht vollständig referenziert wurde,
werden in der WHERE-Klausel neue Variablen eingeführt, die über Existenzquantoren gebunden
sind:
select Hausverwaltung.Haus
Lorel-Anfrage
from Hausverwaltung.Haus
where Hausverwaltung.Haus.Adresse.PLZ = 81541
select H
OQL-Anfrage mit
Existenzquantoren
where exists A in H.Adresse:
exists P in A.PLZ : P = 81541
Die Umformung der WHERE-Anweisung wird umso komplexer, je mehr Pfadangaben darin
vorkommen, die noch nicht in der FROM-Klausel verwendet wurden. Vor allem die Verknüpfung
mehrerer Bedingungen durch logische Operatoren kann zu ungewollten Einschränkungen des
Ergebnisses führen, weil der Exists-Operator bei ungünstiger Anordnung das Vorkommen aller
Attribute für die betrachteten Objekte beinhaltet.
select Hausverwaltung.Haus
Lorel-Anfrage
from Hausverwaltung.Haus
where Hausverwaltung.Haus.Adresse.PLZ = 81541
or (Hausverwaltung.Haus.Adresse.Ort = "München" and
Hausverwaltung.Haus.Adresse.Strasse = "Hagener Str.")
select H
Die Auswertung der
Bedingung in der
WHERE-Anweisung
exists P in A.PLZ :
liefert false zurück,
exists O in A.Ort :
falls das Adressenexists S in A.Strasse :
Objekt nicht alle
(P = 81541 or
Attribute (PLZ, Ort
(O = "München" and S = "Hagener Str."))
und Strasse) enthält
Um diese Fehlinterpretation zu umgehen, sollte die durch den exists-Operator gebunden
Variable der WHERE-Anweisung möglichst durch Klammerung mit der Auswertung der Bedingung
zusammengefaßt werden:
select H
OQL-Anfrage mit
geklammerten
Existenz-Operatoren
((exists P in A.PLZ : P = 81541) or
((exists O in A.Ort : O = "München") and
(exists S in A.Strasse : S = "Hagener Str.")))
Eine zweite Möglichkeit ist die Bildung einer Vereinigungsmenge mit dem Objekt oemnil des
Datentypes OEMnil, das als Objekt zwar eine Existenz hat, aber für jede Bedingung mit false
ausgewertet wird:
select H
OQL-Anfrage unter
Verwendung von
where exists A in (H.Adresse union set (oemnil)):
oemnil
exists P in (A.PLZ union set (oemnil)):
exists O in (A.Ort union set (oemnil)):
exists S in (A.Strasse union set (oemnil)):
(P = 81541 or
(O = "München" and S = "Hagener Str."))
616 9HUZHQGXQJ#YRQ#DOOJHPHLQHQ#3IDGDXVGU•FNHQ
Einfache Pfadausdrücke sind die grundlegenden Bausteine der Lorel-Anfragen, die durch den
zusätzlichen Einsatz von regulären Ausdrücken und Wildcards deutlich an Flexibilität gewinnen. Reguläre
Ausdrücke (engl. „general path expression“ oder gpe) dienen zur Definition von Mustern für die Teilpfade,
während die Stellvertreter (engl. „wildcards") eine Maskierung einzelner Kantenbeschriftungen (Labels)
erlauben. Anhand dieser Mechanismen wird die Behandlung von Daten in unbekannten Strukturen erst
möglich. Im Gegensatz zu den einfachen Pfadangaben können die allgemeinen Pfadausdrücke nicht
durch OQL-Anfragen repräsentiert werden.
8
Die folgende Tabelle listet die in Lorel verwendeten regulären Ausdrücke auf:
Reguläre Ausdrücke für Pfade
(Teilpfad|Teilpfad)
z.B.: .Adresse.(Strasse|Straße)
Disjunktion der Teilpfade, d.h. nach „Adresse“
muss im Pfad eine Kante „Strasse“ oder eine
Kante „Straße“ folgen
(Teilpfad)?
z.B.: .Haus(.Adresse)?.PLZ
Optionaler Teilpfad, d.h. der Pfad nach „Haus“
kann eine oder keine Kante mit der Beschriftung
„Adresse“ beinhalten
(Teilpfad)+
z.B.: .Haus(.Nachbarhaus)+
Wiederholter Teilpfad, d.h. die Kante
„Nachbarhaus“ ist mindestens einmal im Pfad
vorhanden oder kann beliebig häufig wiederholt
werden
(Teilpfad)*
z.B.: .Haus(.Nachbarhaus)*
Wiederholter Teilpfad, wobei die Kante
„Nachbarhaus“ auch nullmal im Pfad vorkommen
kann
Platzhalter für Kanten
%
z.B.: Besitzer.%name
Null oder beliebig viele Zeichen, d.h. es wird
sowohl das Objekt „Besitzer.Vorname“ als auch
„Besitzer.Nachname“ referenziert
#
z.B.: Hausverwaltung.#
Beliebig lange Pfadausdrücke, d.h. nach dem
Einstiegspunkt „Hausverwaltung“ können im Pfad
null oder beliebig viele Kanten folgen.
# steht als Abkürzung für „(.%)*“
Vorsicht ist vor allem bei der Formulierung sehr unpräziser Pfadangaben unter Verwendung der Zeichen
„*“ und „+“ geboten. Diese Ausdrücke können mit einer unendliche Menge an Datenpfaden
übereinstimmen, falls in dem zugrundliegenden OEM-Graphen Zyklen vorhanden sind, z.B. referenziert
der Pfad „Hausverwaltung.Haus(.Nachbarhaus)*“ folgende Datenpfade:
Hausverwaltung,&1,Haus,&2
Hausverwaltung,&1,Haus,&2,Nachbarhaus,&12
Hausverwaltung,&1,Haus,&2,Nachbarhaus,&12,Nachbarhaus,&2
Hausverwaltung,&1,Haus,&2,Nachbarhaus,&12,Nachbarhaus,&2,Nachbarhaus,&12
....
In Lorel wird das Problem dadurch unterbunden, dass jedes Objekt höchstens einmal innerhalb eines
regulären Pfadausdruckes, der mit „*“ oder „+“ abschließt, vorkommen darf. Lorel erzeugt also zu dem
10
obigen Beispiel lediglich die ersten drei Datenpfade .
Eine weitere Besonderheit stellt Lorel mit dem Konzept der Pfadvariablen zur Verfügung. Diese werden
unter Verwendung des Symbols „@“ an einen regulären Ausdruck innerhalb der Pfadangabe gebunden
und können so Informationen über die Struktur der in Lore abgelegten Daten geben. Als Werte wird den
Pfadvariablen eine Menge von Datenpfaden oder Kantenbeschriftungen zugewiesen, die anschließend
mit der Funktion path-of() in Strings umgeformt werden können, z.B.:
Anfrage
Ergebnismenge
select distinct path-of(B)
from Hausverwaltung.#@B X
where X grep "Str."
a) Pfade
Haus.Straße
Haus.Adresse.Strasse
Haus.Nachbarhaus.Straße
Haus.Nachbarhaus.Adresse.Strasse
select distinct path-of(B)
from Hausverwaltung.#.%@B X
where X grep "Str."
b) Labels
Straße
Strasse
10
Der dritte Datenpfad wird noch aufgelöst, weil das erste Vorkommen des Objekts &2 nicht an den regulären Ausdruck
(.Nachbarhaus)* gebunden ist
9
Darüber hinaus können in allgemeinen Pfadausdrücken auch Objektvariablen an beliebigen Stellen innerhalb der Pfads und nicht nur am Ende eines Pfades eingeführt werden. Lorel sieht für die Kennzeichung
dieser Objektvariablen die geschweiften Klammern vor, z. B. ist
select W
from Hausverwaltung.Haus{H}.Wohnung W
where H.(Adresse)?.Ort = "München"
identisch mit
select W
from Hausverwaltung.Haus H, H.Wohnung W
where H.(Adresse)?.Ort = "München"
617 5HVXOWDWH#YRQ#/RUHO0$QIUDJHQ
Das Ergebnis einer Anfrage in Lorel ist eine Multimenge von OEM-Objekten. Bei der Verwendung des
Schlüsselwortes DISTINCT in der Select-Anweisung werden vorhandene Objekt-Dubletten mittels eines
Abgleich der oid ermittelt und eliminiert.
Vor der Rückgabe an das Lore-System wird die Objektmenge mittels der Funktion to_oem in ein neu
erstelltes OEM-Objekt mit der Bezeichnung Answer zusammengeführt. Dabei können durch die Funktion
je nach Art der Rückgabe der SELECT-Anweisung (Wert, Wertemenge, Objekt, Objektmenge) neue
Objekte und Kanten im OEM-Graphen generiert werden.
Beispiele:
Anfrage
Ergebnis als OEM-Objekt
select W
Answer &111
from Hausverwaltung.Haus.Wohnung W
Wohnung &6
Wohnung &13
Wohnung &15
select W.Mieter, W.Besitzer
Answer &112
from Hausverwaltung.Haus.Wohnung W
Wohnung &113
Mieter &44
Wohnung &114
Besitzer &44
Mieter &21
Wohnung &115
Besitzer &31
Das Answer-Objekt kann umbenannt werden und steht damit zur Weiterverwendung in späteren
Anfragen zur Verfügung.
7 /RUHO#DOV#8SGDWH06SUDFKH
Im Vergleich zu OQL implementiert Lorel eine Reihe von zusätzlichen Befehlen zur Datenmanipulation,
z.B. zur Erstellung atomarer und komplexer Objekte, zur Zuweisung von Namen zu Objekten und zur
Änderung der Werte einzelner und einer Menge von Objekten.
10
714 2EMHNWHUVWHOOXQJ
Innerhalb von Lorel können unter Verwendung der Funktion new_oem sowohl atomare als auch
komplexe Objekte neu erstellt werden. Im Funktionsaufruf werden Datentyp (z.B.: integer, string,
complex) und die Werte übertragen, z.B.:
new_oem(int,5)
erstellt ein atomares OEM-Objekt vom
Typ integer mit dem Wert 5
new_oem
erstellt zunächst ein komplexes OEM(complex,
Objekt und anschließend zwei atomare
struct(Name:{new_oem(string,"Hohl")},
Subobjekte, die über die Kanten Name
Konto:{new_oem(int,12233445)})) und Konto mit dem komplexen Objekt
verbunden werden
Im Gegensatz zur Objekterstellung hat Lorel keinen expliziten Befehl zum Löschen eines Objektes
vorgesehen. Stattdessen wird ein Objekt automatisch durch den „Garbage Collector“ gelöscht, nachdem
in der Datenbank keine Referenz mehr auf das Objekt existiert und es somit unerreichbar geworden ist.
715 1DPHQV]XZHLVXQJHQ
Im Object Exchange Model wurde das Namenskonzept der ODMG übernommen, das eindeutige Namen
als Alias für Objekte und als Einstiegspunkte für eine Datenbank vorsieht. In Lorel können Namenszuweisungen im Anschluß an eine Objektselektion erfolgen. Da aber Namen immer nur auf genau ein
OEM-Objekt verweisen dürfen, muss die Rückgabe mittels der Funktion to_oem in ein komplexes Objekt
umgewandelt, falls mehr als eins zurückgeliefert wird.
Beispiele:
name meineWohnung := element11
(select Hausverwaltung.Haus.Wohnung
where Hausverwaltung.Haus.Wohnung.#.%name grep Overkamp)
name meineQM := element
(select Hausverwaltung.Haus.Wohnung.qm
where Hausverwaltung.Haus.Wohnung.#.%name grep Overkamp)
Darüber hinaus ist es auch möglich, Objekten bereits bei der Erstellung mit einem Namen zu belegen:
name neueAdresse := new_oem
(complex,
struct(Ort:{new_oem(string,"Göttingen")},
PLZ:{new_oem(integer,37073)},
Strasse:(new_oem(string,"Münchner Allee 13")}))
Über die folgende Syntax können Namen gelöscht werden:
name meineWohnung := null
716 2EMHNWXSGDWHV
Das Aktualisieren der Werte von benannten atomaren und komplexen OEM-Objekten erfolgt duch den
Update-Befehl, z.B.
update meineWohnung.Miete := "900 •% entfernt zunächst alle Kanten mit der
Bezeichnung Miete vom komplexen Objekt
meineWohnung und verbindet dieses
anschließend durch eine neue Kante mit
einem atomaren Objekt mit dem Werts „900 •³
update meineWohnung.qm += 64
fügt dem komplexen OEM-Objekt über eine
neue Kante qm eine zusätzliche Referenz auf
ein Objekt mit dem Wert 64 hinzu
update meineQM -= 10
dekrementiert den integer Wert des atomaren
Objektes meineQM um zehn
11
element ist ein Schlüsselwort in OQL, dass das Element einer einelementigen Menge zurückliefert
11
Zusätzlich zur Änderung einzelner OEM-Objekte, die eindeutig über einen Namen referenziert werden,
ermöglicht der Update-Befehl auch die Manipulation der Werte einer Menge von Objekten durch eine
einzige Anweisung. Dazu wird folgende Update-Syntax verwendet:
update H.PLZ += P
from Hausverwaltung.Haus{H}.Adresse.(PLZ|Postleitzahl) P
where P <= 80000
Diese Lorel-Anfrage weist allen Haus-Objekten, die der Where-Anweisung genügen, die zugehörige
Postleitzahl als direktes Unterobjekt zu.
717 %XON#/RDGLQJ
Lorel stellt eine weitere Funktion zum Laden von atomaren und komplexen Objekten aus einer Datei zur
Verfügung:
load <dateiname>
Bei dem sogenannten „Bulk Loading“ werden zunächst die Angaben aus der Textdatei ausgelesen und
anschließend die dort beschriebenen atomaren und komplexen Objekte erstellt. Die neuen Objekte
können sowohl als eigene Datenbank oder auch als Subobjekte zu eindeutig benannten Objekten einer
anderen Datenbank eingespielt werden.
8 /RUHO#,PSOHPHQWLHUXQJ#LP#/RUH#6\VWHP
12
Lorel wurde speziell für die Formulierung von Abfragen an das Lore Datenbank Management System
von Grund auf neu entwickelt. In diesem Kapitel soll die Implementierung der Anfragesprache im Lore
DBMS kurz erläutert werden.
Lore bietet den Anwendern verschiedene Nutzeroberflächen (z.B. ein textbasiertes Eingabefenster für die
Entwickler oder eine graphische Benutzeroberfläche für den Endnutzer) um Anfragen an das Datenbanksystem zu formulieren. Bevor der Objekt-Manager die eigentlichen Selektionen auf den abgespeicherten
Daten ausgeführen kann, muss die Anfrage in einer Reihe von Schritten aufbereitet werden:
1. Im Query Parser wird die textuelle Anfrage in die einzelnen Elemente zergliedert und in einer
Baumstruktur abgelegt.
13
2. Im Preprocessor wird die Lorel-Anfrage in eine OQL-ähnliche Syntax umgeformt .
3. Unter Verwendung des Query Plan Generator wird ein logischer Plan zur Abarbeitung der
Anfrage erstellt. Obwohl Lore ein objektorientiertes Datenmodell zugrunde liegt, wird die Anfrage
weiterhin in eine Sequenz von relationalen Datenbankoperationen (z.B. SCAN, JOIN, SELECT,
PROJECT) transformiert. Diese Operationen weichen aber in ihrer Realisierung z.T. deutlich von
den traditionellen Funktionalitäten ab, z.B. werden die regulären Pfadausdrücke erst durch eine
oder mehrere Iterationen des SCAN-Vorgangs interpretiert.
4. Anschließend erfolgt die Optimierung des logischen Plans anhand einiger fester Regeln. Darüber
hinaus wird überprüft, inwieweit Indexe bei der Abarbeitung der Anfrage herangezogen werden
können.
5. Aus dem optimierten logischen Anfrage-Plan wird in eine physischen Zugriffsplan generiert.
6. Abschließend wird die optimierten Anfrage auf dem Datenbestand ausgeführt.
Schließlich sei noch kurz auf das Konzept der "Data Guides" innerhalb von Lore hingewiesen. Diese
Struktur-Ansichten werden von Lore automatisch zu einer gegebenen OEM-Datenbank erstellt und
dynamisch gepflegt. Die Data Guides sind wiederum OEM-Graphen, aus denen aber im Vergleich zur
Gesamt-Datenbank jene identischen Pfadangaben entfernt wurden, die wiederholt auftreten. Data Guides
stellen daher die Struktur der zugrundeliegenden Datenbank deutlich übersichtlicher dar. Lore beinhaltet
eine graphische Oberfläche für Struktur-Ansicht, die es dem Endnutzer ermöglicht, darüber einfache
Suchanfragen an die Datenbank zu stellen. Darüber hinaus werden diese Informationen aber auch im
Rahmen der Anfrage Optimierung innerhalb des Lore DBMS verwendet.
12
13
Die Lore-Architektur ist in (McHugh et al, 1997) beschrieben
z.B. durch das Auflösen der einfachen Pfadausdrücke, vgl. Kap. 3.2
12
9 6FKOX‰EHPHUNXQJ
Lorel ist eine sehr leistungsfähige und flexible Anfragesprache, die auf der Basis von verbreiteten
Datenbank-Standards (z.B. ODMG, OQL und XML) alle Anforderungen erfüllt, die für die Verwaltung von
semistrukturierten Daten erforderlich sind:
•
Durch umfangreiche Regeln zur Datenumsetzung (Type Coercion) befähigt Lorel den Anwender,
Abfragen auf semistrukturierten Daten absetzen zu können, ohne daß genaue Kenntnisse über
die Struktur der komplexen Objekte oder über die präzisen Datentypen der atomaren Objekte
notwendig sind.
•
Das Konzept der regulären Ausdrücke in Pfadangaben und der Stellvertreter („wildcards") in
Labeln erlaubt die Formulierung von mächtigen Suchmustern auf der Datenstruktur, anhand
derer die Abfrage von implizit und irregulär strukturierten Daten erst möglich wird.
•
Über die Verwendung von Pfadvariablen innerhalb der allgemeinen Pfadangaben wurden den
Anwendern ein funktionales Hilfsmittel zur Analyse der unbekanten Datenstruktur zur Verfügung
gestellt.
Allerdings beinhaltet die hohe Flexibilität bei der Formulierung und Umsetzung von Lorel-Anfragen eine
Reihe von Problemen, von denen die Performance-Einbußen aufgrund der umfangreichen DatentypUmsetzungen (Type Coercion) vermutlich vom technischen Standpunkt noch am einfachsten zu lösen
14
sind .
In meinen Augen ist der Lorel-Grundsatz im Zusammenhang mit der Verwendung von regulären
Ausdrücken in Pfadangaben (“Doing the intuitive thing) zwar sehr pragmatisch angelegt, aber doch nicht
völlig unkritisch zu beurteilen. Immerhin kann eine Suchanfrage durch den unbedachten Einsatz sehr
mächtiger regulärer Ausdrück wie "*", "+" oder "#" so unpräzise werden, daß sie Ergebnisse zurückliefert,
die gerade nicht vom Anwender erwartet werden. Zum Beispiel liefert die folgende Suchanfrage auf der
OEM-Datenbank aus Kap. 2.1
select H
where H.#.(postleitzahl|plz) != 81541
das Objekt mit der oid &12 zurück, obwohl das Haus dem Postleitzahlenbereich 81541 zugeordnet ist.
Umso ungenauer Suchanfragen werden, umso größer wird der Anteil an unzutreffenden Treffern in der
Ergebnismenge. In diesem Zusammenhang finde ich vor allem die Entwicklung von graphischen
15
Benutzeroberflächen zur Selektion semistrukturierter Daten anhand dynamisch erstellter Data Guides
im Ansatz sehr überzeugend. Diese Sichten auf die Struktur erlauben - solange sie übersichtlich bleiben mit Sicherheit eine optimale Datenselektion durch den Anwender.
Als weiteres Problemfeld ist vermutlich noch die hohe Komplexität der Lorel-Syntax zu nennen. Auch in
dieser Beziehung müssen die angebotenen graphischen Nutzeroberflächen sehr mächtig sein, um dem
Endnutzer nicht lediglich einen eingeschränkten Funktionsumfang von Lorel zur Verfügung zu stellen.
14
15
vgl. http://www.eecs.wsu.edu/~cdyreson/teaching/advancedDatabase/011/discussions/fivereport.htm
vgl. (McHugh et al, .1997, S. 62f)
13
: /LWHUDWXUYHU]HLFKQLV
S. Abiteboul, D. Quass, J. McHugh, J. Widom und J.L. Wiener. The Lorel Query Language for
Semistructured Data. In: International Journal on Digital Libraries 1 (1), 68-88, 1997.
http://dbpubs.stanford.edu:8090/pub/1996-36
Gesellschaft für Informatik. Informatik-Lexikon.
http://giserver.gi-ev.de/informatik/lexikon
R. Goldman, S. Chawathe, A. Crespo, J. McHugh. A Standard Textual Interchange Format for the Object
Exchange Model (OEM). Technical Report, October, 1996.
ftp://db.stanford.edu/pub/papers/oemsyntax.ps
http://www-db.stanford.edu/lore/pubs/oemsyntax.pdf
R. Goldman, J. McHugh, J. Widom. From semistructured data to XML: Migrating the Lore data model and
query language. Markup Languages 2 (2), 153-163, 2000.
U. Greiner. Semistrukturierte Daten. 1999.
http://doesen8.informatik.uni-leipzig.de/de/seminararbeiten/semSS99/arbeit3/inhalt.html
J. McHugh, S. Abiteboul, R. Goldman, D. Quass, and J. Widom. Lore: A Database Management System
for Semistructured Data. In: SIGMOD Record, 26(3):54-66, September 1997.
ftp://db.stanford.edu/pub/papers/lore97.ps
http://www-db.stanford.edu/lore/pubs/lore97.pdf
14
Lore
Ein Datenbanksystem für semistrukturierte
Daten
Seminar XML und Datenbanken
Wolfgang Müßler
Lehrgebiet Praktische Informatik IV
Prof. Dr. Ralf Hartmut Güting
FernUniversität Hagen
Lore - ein DBMS für semistrukturierte Daten
1
2
3
4
5
6
Seite 2 von 17
Übersicht ............................................................................................................................ 3
Repräsentation semistrukturierter Daten............................................................................ 4
2.1
Das OEM-Datenmodell von Lore (Object Exchange Model).................................... 4
2.2
Das XML-Datenmodell von Lore .............................................................................. 5
Systemarchitektur............................................................................................................... 7
Überblick.................................................................................................................... 7
3.1
3.2
Top-Down-Ansatz der Abfrageverarbeitung ............................................................. 8
3.2.1
Abfrageoperatoren (Query operators) ................................................................ 9
3.3
Bottom-Up Ansatz der Abfrageverarbeitung ............................................................. 9
3.3.1
Lindex (Label Index).......................................................................................... 9
3.3.2
Vindex (Value Index)......................................................................................... 9
3.3.3
Abfrageplan mit Indexierung ........................................................................... 10
DataGuides ....................................................................................................................... 11
4.1
Definition und Eigenschaften von DataGuides ........................................................ 11
4.2
Unterstützung des Benutzers durch DataGuides ...................................................... 12
4.2.1
Unterstützung bei der Erfassung von Struktureigenschaften ........................... 13
4.2.2
Unterstützung bei der Formulierung von Abfragen ......................................... 14
4.3
Unterstützung des Systems durch DataGuides bei der Auswertung von Abfragen. 14
Zusammenfassende Bewertung von Lore ........................................................................ 16
Literatur............................................................................................................................ 17
Seite 3 von 17
1 Übersicht
Traditionelle Datenbanksysteme sind an ein explizit spezifiziertes Datenbankschema
gebunden. Dadurch entstehen möglicherweise folgende Schwierigkeiten:
1. Die Daten selbst sind irregulär und lassen sich nicht mit einem starren Schema
beschreiben.
2. Die Daten sind zwar regulär, aber im Voraus nicht bekannt, so daß das Schema
ständig aktualisiert werden muß.
Lore ("Leightweight Object Repository") ist ein Datenbanksystem, das mit
semistrukturierten Daten arbeitet. Semistrukturierte Daten genügen einer gewissen Struktur
(siehe unten), müssen aber nicht zuvor durch ein explizites Schema beschrieben werden. Das
Fehlen eines expliziten Schemas führt zu anderen Problemen, die mit der Entwicklung von
Lore erkannt und auch teilweise gelöst wurden:
1. Ein einfaches Datenmodell soll die semistrukturierten Daten beschreiben: zunächst
wurde Lore mit dem OEM ("Object Exchange Model") implementiert, einem sehr
einfachen und klaren Datenmodell, das die Daten durch einen gerichteten,
attributierten Graphen beschreibt. Aufgrund der zunehmenden Popularität von XML
wurde später das OEM-Datenmodell auf ein etwas komplexeres XML-Datenmodell
migriert. Erklärtes Ziel von Lore war nämlich, auch externe semistrukturierte Daten
integrieren zu können und derartige Daten liegen heute in der Regel in einem XMLFormat vor.
2. Eine Sprache zur Abfrage und Manipulation der Daten mußte entwickelt werden,
Lorel ("Lore-Language").
3. Traditionelle Bestandteile von Datenbanksystemen, wie Abfrageoptimierung oder die
Verwendung von Indizes wurden auch bei Lore effizienzsteigernd implementiert;
allerdings kann ein Index schwerlich vom Administrator verwaltet werden, da dieser
zunächst die Struktur der Daten nicht kennt.
4. Der Benutzer muß zur Formulierung von Abfragen eine gewisse Struktur der Daten
erkennen können, die durch sogenannte "Data-Guides" beschrieben wird. Data-Guides
sind eine dynamische prototypartige Abbildung der semistrukturierten Daten und
übernehmen die Rolle des statischen Datenbankschemas auch für systeminterne
Statistiken z.B. zur Abfrageoptimierung.
Im Rahmen meines Vortrags werde ich zuerst auf die Datenmodelle, anschließend auf die
Systemarchitektur mit Betonung der Abfrageverarbeitung und zum Schluß auf DataGuides
eingehen. Weitere interessante Komponenten von Lore, wie der externe Datenmanager,
würden leider den Rahmen meines Vortrages sprengen.
Seite 4 von 17
2 Repräsentation semistrukturierter Daten
2.1 Das OEM-Datenmodell von Lore (Object Exchange
Model)
Die Daten im OEM können als gerichteter, attributierter Graph repräsentiert werden:
• Knoten sind Objekte, jeder Knoten hat einen eindeutigen Objektidentifikator (z.B.
&1)
• Atomare Objekte sind Knoten mit einem atomaren Wert (z.B. Typ integer, real,
string, gif, java, audio etc.) ohne ausgehende Kante.
• Komplexe Objekte sind Knoten ohne atomaren Wert mit ausgehenden Kanten, die zu
Subobjekten zeigen.
• Kanten sind obligatorisch attributiert; das Attribut entspricht der Rolle, die ein
Subobjekt für ein Objekt hat (z.B. ist Objekt &4 ein Kunstfehler für Objekt &6,
während es für Objekt &2 eine Therapie darstellt).
• Namen sind Einsprungpunkte für Abfragen. Im Beispielsgraphen gibt es nur einen
Namen: "Krankheiten" ist ein Name für Objekt &1. Alle Objekte, die im Graphen
nicht über ein benanntes Objekt erreicht werden können, sind für Abfragen nicht
zugänglich und deshalb als "bedeutungslos" zu löschen.
In OEM lassen sich nicht nur baumartige, sondern auch zyklische Strukturen formulieren;
daraus resultieren verschiedene Probleme bei der dynamischen Berechnung von Abfragen und
Data-Guides.
Für OEM existiert eine Abfragesprache (OQL), auf der Lorel wesentlich aufbaut. Tatsächlich
wandelt der Präprozessor in Lorel formulierte Abfragen vor der weiteren Verarbeitung in eine
OQL-artige Syntax um.
Seite 5 von 17
2.2 Das XML-Datenmodell von Lore
Das XML-Datenmodell von Lore ist komplexer als das OEM. Im wesentlichen ist das Folge
des Ziels, auch externe Daten im XML-Format mit Lore verarbeiten zu können. Erstens kann
dieselbe Information als Attribut oder Subelement eines XML-Elements ausgedrückt werden.
Zweitens sind XML-Dokumente zunächst einmal Text und werden als XML-Elemente in
einer Ordnung aufgefaßt; ein DOM-Parser erzeugt aus dem Dokument einen Baum, dessen
Informationseinheiten Elementnamen und Text sind. Um zyklische Strukturen auf XML
abbilden zu können, muß zusätzlich ein validierendes Dokument vorhanden sein, das
bestimmte Attributwerte (Text) als Verweise kennzeichnet (Typ IDREF, IDREFS). Das
gleiche gilt für Texte, die Werte vom Typ string, integer usw. repräsentieren sollen; eine
derartige Semantik läßt sich durch ein dem XML-Dokument zugeordnetes XML-Schema
beschreiben.
Lore betrachtet die XML-Daten in zwei unterschiedlichen Modi: im semantischen Modus
werden Referenzen aufgelöst und die referenzierten Objekte zu Subelementen; im literalen
Modus werden Referenzinformationen wie andere Attribute betrachtet und der Graph des
Dokuments ist ein Baum.
<Krankheiten>
<Krankheit
Name=„Mandelentzündung“>
<Therapie ID=„t1“>
<Präparat>Penicillin</Präparat>
<Tage>10<Tage>
</Therapie>
</Krankheit>
<Krankheit Kunstfehler=„t1“>
<Name>Grippe</Name>
<Symptom>Schnupfen</Symptom>
</Krankheit>
</Krankheiten>
Das XML-Datenmodell läßt sich formell so beschreiben:
• ein XML-Element ist ein Paar (eid, value), wobei eid ein eindeutiger
Elementidentifikator ist,
• value ist entweder ein atomarer String oder ein komplexer Wert, der aus vier
Komponenten besteht:
1. einem tag vom Typ string
2. einer geordneten Liste von Attributpaaren (Attributname, Attributwert)
Seite 6 von 17
3. einer geordneten Liste von referenzierten Subelementen der Form (label, eid),
wobei label ein String ist
4. einer geordneten Liste normaler Subelemente der Form (label, eid), wobei label
ein String ist.
Ein XML-Dokument wird folgendermaßen auf das XML-Datenmodell abgebildet:
• tags und Attributpaare werden direkt aufeinander abgebildet
• im semantischen Modus werden Attributwerte vom Typ IDREF oder IDREFS auf
referenzierte Subelemente (label, eid) abgebildet, wobei der Attributname auf label
und der eid des referenzierten Objektes auf eid abgebildet wird
• Subelemente des Dokumentes werden direkt auf normale Subelemente (label, eid) des
Datenmodells abgebildet: label ist das tag des Subelements oder bei atomaren
Elementen der Wert "Text"
In unserem Beispiel hat Objekt &2 den Namen "Mandelentzündung" und Objekt &6 den
Namen "Grippe". Dies kann über Attribute oder Subelemente ausgedrückt werden. Bei der
Formulierung von Abfragen kann wahlweise über einen "path expression qualifier"
unterschieden werden, ob die Abfrage sich nur auf Subelemente, nur auf Attribute oder auf
beides bezieht:
Bezug
nur Subelemente
nur Attribute
beides
Symbol
>
@
Beispiel
Krankheiten.Krankheit.>Name
Krankheiten.Krankheit.@Name
Krankheiten.Krankheit.Name
Ergebnis
&7
"Mandelentzündung"
{&7, "Mandelentzündung"}
Seite 7 von 17
3 Systemarchitektur
3.1 Überblick
Lore ist in drei Schichten aufgebaut: verschiedene Benutzerinterfaces greifen über eine
schlanke API auf den Abfrageprozessor zu. Dieser verarbeitet Abfragen sequentiell in
mehreren Schritten und greift auf die darunterliegende Datenverarbeitungsschicht zu, die
Operatoren zur Navigation/Verarbeitung von Abfragen und einige Dienstprogramme, wie den
Data-Guide oder den externen Datenmanager anbietet.
Eine vom Benutzer über das API in Lore eingespeiste Abfrage wird zunächst vom Parser
geparst; der Parserbaum wird im Präprozessor in eine OQL-ähnlichen Abfragebaum
transformiert. Anschließend wird ein Abfrageplan berechnet und ggf. vor Ausführung noch
im Query Optimizer optimiert (z.B. durch peripherwärts-Verschiebung von Selektionen). Der
entgültige Abfrageplan (Query-Plan) wird dann durch Aufruf von Operatoren auf der
Datenverarbeitungsschicht ausgeführt.
Lore verarbeitet Abfragen auf zwei verschiedene Arten: Top-Down mit Iteratoren und
Objektzuweisungen zu Objektslots und Bottom-Up mit Indizes. Auf beide Modi wird im
folgenden detailliert eingegangen.
Wir betrachten dazu eine Abfrage zur unten dargestellten Datenbasis:
select O
from DBGroup.Member M, M.Office O
where exists A in M.Age: A>30
Seite 8 von 17
3.2 Top-Down-Ansatz der Abfrageverarbeitung
Bei diesem Ansatz beginnt die Abfrageverarbeitung am Wurzelknoten des Abfragebaums.
Jeder Knoten fordert von den Söhnen erschöpfend Objekttupel an und reicht jeweils ein
Objekttupel an den Vaterknoten weiter. Jeder Knoten fungiert somit als Iterator. Die Menge
der vom Wurzelknoten zurückgegebenen Tupel ist die Ergebnismenge der Abfrage.
Die Objekte werden tupelweise in den "Slots" des Tupels in Form von Objekt-IDs
gespeichert.
Seite 9 von 17
3.2.1 Abfrageoperatoren (Query operators)
Exemplarisch soll hier die Funktionsweise der Operatoren von obigem Beispiel erklärt
werden. Die Rückgabe erfolgt dabei über die Slots des globalen Objekttupels der Abfrage.
• Scan(Startslot, "Pfadausdruck", Zielslot) iteriert über aller Objekte, die vom Objekt
im Startslot über den angegebenen Pfad erreicht werden können und platziert diese im
Zielslot
• Join iteriert über alle Objekte beider Teilbäume
• Select (Slot, Operator, Vergleichswert) iteriert nur über die Objekte, für die der
Vergleich mit dem Vergleichswert "wahr" ist.
• Project (Slotmenge) ist der Projektionsoperator
• Aggr (Exists, Startslot, Zielslot) implementiert im Beispiel den Existenzquantor und
iteriert nicht über alle Objekte, sondern gibt "wahr" im Zielslot zurück, falls ein
Objekt vom peripheren Teilbaum zurückgegeben wurde, sonst "falsch".
3.3 Bottom-Up Ansatz der Abfrageverarbeitung
Lore implementiert zwei Arten von Indices: Kantenindices (Lindex) und Wertindices
(Vindex).
3.3.1 Lindex (Label Index)
Über einen Lindex lassen sich zu einem Objektidentifikator die inzidenten Kanten finden oder
mit einem Objektidentifikator und einem Label alle inzidenten Kanten mit einem dem Label
entsprechenden Attribut. Er unterstützt die Suche nach allen Eltern eines Knoten oder nach
denjenigen Eltern, die über eine bestimmte Rolle mit einem Objekt verknüpft sind. Lindexes
sind über lineares Hashing implementiert.
3.3.2 Vindex (Value Index)
Über einen Vindex lassen sich Punktanfragen und Bereichsanfragen von Daten der Typen
string, real und integer beschleunigen. Ein Vindex findet zu einem Label, einem Operator und
einem Vergleichswert alle atomaren Objekte, die eine inzidente Kante besitzen, die mit dem
Label attributiert sind und die Bedingung (Wert <Operator> Vergleichswert) erfüllen.
Vindexes sind als B+ Bäume implementiert.
Falls die Vergleichswerte unterschiedliche Datentypen haben (integer, real oder string), so
findet eine automatische Typumwandlung (object coercion) statt, nämlich von integer zu real
und von string zu real.
Entsprechend gibt es einen String-Vindex (mit stringbasierten Werten wie URL, string usw.),
einen Real-Vindex (mit Daten vom Typ integer und real) und einen String-zu-Real-Vindex
(mit allen Strings, die sich in integer- oder real-Werte umwandeln lassen).
Wird dann beispielsweise nach allen atomaren Werten mit Label "Age" gesucht, deren Wert
größer als der String "30" ist, so kann mit Stringvergleich im String-Vindex gesucht werden
("uralt">"30") und - da "30" sich in den real-Wert 30 umwandeln läßt, auch im String-zuReal-Vindex (z.B. 45>30).
Sucht man nach allen atomaren Werten mit Label "Age", deren Wert größer als 30 ist, so
kann mit Wertevergleich im Real-Vindex und im String-zu-Real-Vindex gesucht werden.
Seite 10 von 17
3.3.3 Abfrageplan mit Indexierung
Wir betrachten erneut die Abfrage:
select O
from DBGroup.Member M, M.Office O
where exists A in M.Age: A>30
Der Vindex-Operator findet alle Age-Objekte mit einem Wert kleiner als 30, der linke
Lindex-Operator alle mit einer "Age"-Kante verbundenen Väter. Jeder Vater wird nur einmal
berücksichtigt, auch wenn er mehrere "Age"-Subobjekte hat (der Operator "Once" fungiert
hier als Existenzquantor). Der rechte Lindex-Operator findet alle Väter des Objekts im Slot
OA1, die über eine "Member"-Kante mit diesem verbunden sind; davon werden diejenigen
berücksichtigt, die einen Namen "DBGroup" haben (Operator Named_Obj). Join und Scan
arbeiten analog dem Top-Down-Ansatz.
Seite 11 von 17
4 DataGuides
Im Gegensatz zu relationalen und objektorientierten Datenbanksystemen, die ihre Daten an
ein explizit spezifiziertes Schema binden, bezieht sich Lore auf semistrukturierte Daten, die
zu irregulär oder zu veränderlich sind, um gut auf ein festes Schema abgebildet zu werden.
Bei Lore sollen deshalb dynamische DataGuides einige der Funktionen der Schemata
traditioneller Datenbanksysteme übernehmen: Unterstützung des Benutzers bei der
Formulierung von Abfragen und Beschleunigung des Zugriffs auf Daten.
4.1 Definition und Eigenschaften von DataGuides
Ein DataGuide soll eine kurze, präzise und „praktische“ Zusammenfassung der
semistrukturierten Daten sein:
1. Jeder (auch mehrfach) in der Datenbasis s vorkommende „Kantenpfad“ (label path) soll
genau einmal im zugehörigen DataGuide d vorkommen.
2. In d sollen nur Kantenpfade vorkommen, die auch in s vorkommen.
3. DataGuides sollen selbst mit dem Datenmodell der Datenbasis modelliert werden
Hierbei ist ein Kantenpfad ein Pfad, der nur die Attribute der Kanten berücksichtigt, währen
die Identität der Knoten unberücksichtigt bleibt. Zwei Kantenpfade sind gleich, wenn sie
dieselbe Attributfolge ihrer Kanten aufweisen.
Die Konstruktion eines DataGuides bezüglich einer Datenbasis entspricht der Konstruktion
eines deterministischen endlichen Automaten (DEA) zu einem nichtdeterministischen
endlichen Automaten (NEA). Dieser Konstruktionsvorgang ist hinsichtlich seiner zeitlichen
Komplexität (und Speicherkomplexität) gut untersucht: ist der NEA ein Baum, so läßt sich
der zugehörige DEA in linearer Zeit konstruieren; ist der NEA ein zyklischer Graph, so kann
die Konstruktion des DEA im worst-case auch exponentielle Zeit (und Speicherplatz)
erfordern.
Aus der Automatentheorie ist außerdem bekannt, daß zu jedem NEA viele unterschiedliche
DEAs konstruiert werden können; wegen der Äquivalenz gilt das auch für DataGuides nach
obiger Definition: b und c sind verschiedene DataGuides zu a.
Seite 12 von 17
Aus einem NEA mit einer Knotenmenge V kann man einfach einen DEA mit der
Knotenmenge 2V konstruieren (also der Menge aller Mengen über V, der Potenzmenge von
V), indem man eine Tiefensuche von einem Wurzelknoten von V aus durchführt und jeweils
die über gleiche Kantenpfade erreichbaren Knotenmengen zu Knoten des DEA macht. Die
Menge der Objekte aus s, die über mehrere gleiche Kantenpfade von s erreicht werden,
entspricht dann genau der Objektmenge eines Knotens von d, die über den gleichen
Kantenpfad in d erreicht wird. Diese Objektmengen, die Knoten von d zugeordnet sind,
werden "target sets" genannt. Ein DataGuide, der diese Eigenschaft hat, wird strenger
DataGuide (strong DataGuide) genannt und kann über den gerade beschriebenen Algorithmus
konstruiert werden.
Experimentelle Untersuchungen haben gezeigt, daß die Konstruktion eines DataGuide für
viele Datenbasen in akzeptabler Zeit möglich war; außerdem wurden inkrementelle Verfahren
angegeben, mit denen sich der Aufwand für die Konstruktion (Einfügen oder Löschen von
Elementen) auf einzelne Schritte verteilen läßt. Allerdings war die Laufzeit für die „Internet
Movie database“ (www.imdb.com) mit 60.000 Knoten und 95.000 Kanten so lang, daß der
Test abgebrochen werden mußte. Als Lösung wurden „approximate DataGuides“ mit kürzerer
Konstruktionszeit untersucht oder die Beschränkung der Tiefensuche auf eine bestimmte
Tiefe vorgeschlagen.
4.2 Unterstützung des Benutzers durch DataGuides
Ein erklärtes Ziel der DataGuides war es, den Benutzer bei der Formulierung von Abfragen
zu unterstützen. Einerseits erkennt der Benutzer durch den DataGuide die strukturelle
Eigenschaften der Daten (z.B. existente Pfade in der Datenbasis), andererseits wird die
Formulierung von Abfragen - ähnlich Query by Example - graphisch unterstützt.
Seite 13 von 17
4.2.1 Unterstützung bei der Erfassung von Struktureigenschaften
Obige Abbildung zeigt eine Java-Schnittstelle, die einen DataGuide in Form eines Baumes
präsentiert (strenge DataGuides sind stets Bäume):
Ausgehend von der Wurzel DBGroup kann der Benutzer Teilbäume (markiert durch
Dreiecke) expandieren, bis er Blätter des Baumes erreicht (markiert durch Karos). Dieser Teil
der Schnittstelle repräsentiert also die Pfadstruktur des Baumes, aber nicht die Inhalte der
Knoten (also der "target sets").
Diese werden exemplarisch angezeigt, wenn der Benutzer ein Karo anklickt. Lore zeigt dann
in einem Pfadinformationsfenster den Pfad, die Größe des target sets (im Beispiel 33 über
diesen Pfad erreichbare Objekte) und eine willkürlich gewählte Teilmenge der Objekte im
target set (diese werden von Lore bereits bei der Berechnung des DataGuides als
"Annotationen" mit dem DataGuide gespeichert und nicht durch erneutes Durchsuchen der
Datenbasis berechnet).
Außerdem kann man das komplette target set anzeigen und auch noch durch Bedingungen
einschränken.
Seite 14 von 17
4.2.2 Unterstützung bei der Formulierung von Abfragen
Abfragen können textuell in Lorel formuliert werden (der DataGuide stellt dazu die in der
Datenbasis existierenden Pfade dar) oder eine Teilmenge der mit Lorel möglichen Abfragen
kann direkt im "Query by Example"-Stil durch Angabe von Bedingungen der where-Klausel
an den Blättern des DataGuides erzeugt werden.
4.3 Unterstützung des Systems durch DataGuides bei der
Auswertung von Abfragen
Strenge DataGuides können von Lore als Pfadindex verwendet werden. Beispiel:
Select DB_Group.Group_Member.Original_Home
findet alle Herkunftsorte der Group_Member der DB_Group.
Seite 15 von 17
Mit DataGuide muß einfach das bereits berechnete target set des label path
DB_Group.Group_Member.Original_Home ausgegeben werden (dafür sind lediglich 3
sequentielle Zugriffe nötig).
Ohne DataGuide müssen alle Group_Member daraufhin überprüft werden, ob sie ein
Subelement in der Rolle eines Original_Home haben.
Select DB_Group.Group_Member.Publication.Year
Where DB_Group.Group_Member.Publication.Year < 1990
Angenommen, das target set des Pfades DB_Group.Group_Member.Publication enthält
20.000 Objekte, von denen 5000 je ein Subobjekt in der Year-Rolle besitzen, von denen
wiederum 1.000 der Bedingung genügen. Weiterhin gebe es noch 5.000 andere Objekte in
einer Year-Rolle, deren Väter aber keine Publication sind, von denen 2.000 der Bedingung
genügen. Die Zahl der Group_Member sei 1.000.
Mit
DataGuide
wird
der
Durchschnitt
des
target
sets
von
DB_Group.Group_Member.Publication.Year Y mit dem Vindex V (Year, <, 1975) gebildet.
Y enthält 5.000 Elemente, V 3.000 Elemente. Der Durchschnitt kann durch Iteration über die
3.000 Elemente von V berechnet werden (zu jedem Objekt der Datenbasis kann über einen
"objectHash" in O(1) Zeit die Menge der target sets berechnet werden, die das Objekt
enthalten).
Ohne DataGuide muß über alle 1.000 Group-Member mit 20.000 Publikationen iteriert
werden und geprüft werden, ob diese ein Subobjekt in der Year-Rolle haben, das die
Bedingung erfüllt (im Beispiel wird also über 26.000 Objekte iteriert).
Seite 16 von 17
5 Zusammenfassende Bewertung von Lore
Lore wurde zur Verarbeitung semistrukturierter Daten entwickelt. Die Einbindung
vorhandener, nicht speziell für Lore erzeugter externer Daten im XML-Format gelang.
DataGuides unterstützen den Benutzer in verschiedener Weise optimal zur Formulierung von
Abfragen. Die Berechnung von DataGuides erfordert jedoch im worst case exponentielle Zeit;
bei einer großen bekannten Datenbasis terminierte die Berechnung auch nach Minuten nicht.
Mehrere Lösungsansätze wurden dazu experimentell untersucht (inkrementelle Verfahren,
approximate DataGuides); diese weisen aber andere Nachteile auf.
Durch die Verwendung von Indices konnte auch bei semistrukturierten Daten die
Verarbeitung von Abfragen in günstigen Fällen deutlich beschleunigt werden.
Das Lore-Projekt wurde „erfolgreich abgeschlossen“; ich schließe mich dieser Bewertung an.
Seite 17 von 17
6 Literatur
1. McHugh J, Abiteboul S, Goldman R, Quass D, Widom J (1997): Lore: A Database
management System for Semistructured Data. http://www-db.stanford.edu/lore
2. Goldman R, McHugh J, Widom J (1999): From Semistructured Data to XML:
Migrating the Lore Data Model and Query Language. http://www-db.stanford.edu/lore
3. Goldman R, Widom J (1997): DataGuides: Enabling query formulation and
optimization in semistrucutred databases. http://www-db.stanford.edu/lore
4. Goldman R, Widom J (1999): Approximate DataGuides. http://wwwdb.stanford.edu/lore
Seminar:
XML und Datenbanken
Thema:
XQL, XPath
Referentin:
Annette Gutjahr
Semester:
Sommersemester 2002
Annette Gutjahr
Prof. Dr. Ralf Hartmut Güting,
Dipl.-Inf. Dirk Ansorge
Matr. Nr. 4365666
Sonnenbergstr. 32/1
75395 Ostelsheim
E-Mail annette.gutjahr@web.de
Annette Gutjahr
Seminar: XML und Datenbanken: XQL, XPath
1
Einführung...................................................................................................................... 3
1.1
Szenarien für XML-Anfragen ........................................................................................ 3
1.2
Allgemeine Anforderungen an eine XML-Anfragesprache........................................... 4
1.3
Datenbankanfragen als Messlatte................................................................................... 4
1.4
Ein XML-Dokument (Beispiel) ..................................................................................... 5
1.5
Worin bestehen die Unterschiede zwischen relationalen Datenbanken und XMLDokumenten? ............................................................................................................................. 6
2
2.1
2.2
2.3
2.3.1
2.3.2
2.3.3
2.4
XQL (W3C Proposal, September 1998) ........................................................................ 7
Einführung und Motivation............................................................................................ 7
Beispiel........................................................................................................................... 7
Syntax und Semantik...................................................................................................... 8
Terminologie .............................................................................................................. 8
XML Patterns (Kernfunktionalität)............................................................................ 8
XQL-Erweiterungen................................................................................................... 9
Diskussion .................................................................................................................... 10
3
3.1
3.2
3.3
3.4
3.4.1
3.5
3.6
XPath Version 1.0 ........................................................................................................ 11
Einführung und Motivation.......................................................................................... 11
Das Datenmodell von XPath ........................................................................................ 12
Beispiel......................................................................................................................... 12
Syntax und Semantik.................................................................................................... 13
Ausdrücke................................................................................................................. 13
Diskussion .................................................................................................................... 14
Weiterentwicklung von XPath: .................................................................................... 15
4
Quellen, weitere Informationsmöglichkeiten ............................................................... 15
Seite 2
Annette Gutjahr
1 Einführung
„XML is a powerful, elegant technique for thinking about, exchanging, and presenting data in
a platform-independent manner.“ – XML auf einen Satz gebracht. [3, S. 15]
Bei XML-Dokumenten geht es also in erster Linie um das Arbeiten mit Daten. Sehr bald erkannte man, dass es dabei nützlich ist, über eine Anfragesprache zu verfügen, so dass man
gezielt auf Teile von XML-Dokumenten zugreifen und deren Inhalt weiterverarbeiten kann.
Man übergibt also einem Parser die gewünschten Kriterien und erhält als Ergebnis eine
Menge von Dokumentteilen, die diesen Kriterien genügen. Damit werden große XML-Dokumente quasi zu einer Datenbank. Außerdem sind solche Anfragen wichtig für Transformation
von XML-Dokumenten in andere XML-Dokumente oder in andere Datenbanken oder in
beliebige andere, eigene Anwendungen.
1.1 Szenarien für XML-Anfragen
Der Bedarf an Anfragesprachen für XML-Dokumente wurde auch von dem
Standardisierungsgremium World Wide Web Consortium (W3C) bald erkannt. Inzwischen
wurde dort eine eigene XML Query Working Group eingerichtet, die verschiedene Szenarien
für XML-Anfragen entwickelt hat [4]. XML-Anfragesprachen müssen sich nun daran messen
lassen.
Es geht hierbei je nach Ausgangsstruktur, auf der gearbeitet werden soll, um
• Anfragen an dokument- oder datenbasierte XML-Anwendungen. Dokumentbasierte
Anwendungen entsprechen der typischen Arbeit eines Editors: ein strukturiertes Dokument mit Text und Bildern, Fonts und Formatierungen. Datenorientierte Anwendungen sind üblich z.B. bei E-Commerce, wobei XML nur das Mittel für den Informationsaustausch zwischen verschiedenen Systemen ist. Die Informationen sind dabei
i.d.R. nicht formatiert und auch nicht für menschliche Leser bestimmt.
Anwendungsbeispiele:
o von Menschen zu lesende Dokumente (z.B. Handbücher) aus denen einzelne
Dokumente gesucht werden sollen, ein Inhaltsverzeichnis generiert werden
soll, nach Informationen aus der Dokumentstruktur gesucht werden soll oder
anhand derer neue Dokumente generiert werden sollen.
o datenbasierte Dokumente (z.B. aus XML-Repräsentationen von Daten aus
Datenbanken oder anderen Datenquellen) aus denen Daten herausgefiltert werden, oder in andere XML-Repräsentationen gewandelt werden oder Daten aus
verschiedenen Datenquellen sollen in ein neues Dokument integriert werden.
o „Mixed-model documents“: hier handelt es sich sowohl um dokument-orientierte als auch um datenorientierte Anfragen für Dokumente mit von anderen
Quellen eingebundenen Daten, wie z.B. Kataloge, Patienten- und Personalakten etc.
o Verwaltungsdaten: Anfragen in Konfigurationsdateien, Benutzerprofile oder
Logprotokolle, die in XML geführt werden.
• Anfragen auf XML-Datenströme (Streams), um Daten analog zu UNIX-Filtern für
Streams zu verarbeiten. Es geht dabei darum, Daten aus XML-Strömen zu filtern und
weiterzuleiten oder Daten auf XML-Ströme zu schreiben, z.B. für Log-Aufzeichnungen von E-Mail-Messages oder Netzwerk-Paketen, Aktienmarktdaten, Meldungen von
Nachrichtentickern, EDI, Wetterdaten.
• Anfragen auf DOM-Strukturen (DOM = Document Object Model), um Knotenmengen zu erhalten, die bestimmten Kriterien genügen.
• Anfragen auf Dokument-Sammlungen, die von native XML Repositories oder Web
Servern gemanagt werden.
Seite 3
Annette Gutjahr
•
Anfragen in Kataloge, die Dokumentserver, Dokumenttypen, XML-Schemas oder Dokumente beschreiben. Solche Kataloge sollten für die Suche auf mehreren Servern
kombiniert werden können. Für ein Dokumenten-Retrieval-System sollte der Benutzer
z.B. die Möglichkeit haben, Server-Kataloge (in XML) entsprechend der von den Servern gelieferten Informationen, nach Zugriffskosten oder nach Zugriffsberechtigung
auszuwählen. Anschließend könnte das Retrieval-System die Art der Dokumente auf
dem jeweiligen Server Anfragen und dem Benutzer ermöglichen, in diesen Dokumenten zu suchen.
Je nach Einsatzgebiet der Anfragesprache kann man verschiedene syntaktische Umgebungen
unterscheiden: z.B. eingebettet in eine URL, eine XML-Seite, oder eine JSP (Java Server
Pages) oder ASP-Seite (Active Server Pages); als String in einem Programm, das in einer allgemeinen Programmiersprache geschrieben wurde; als Argument auf der Befehlszeile oder
auf Standard-Input; oder unterstützt von einem Protokoll.
1.2 Allgemeine Anforderungen an eine XML-Anfragesprache
In der Diskussion innerhalb der W3C-Arbeitsgruppen war von Anfang an klar, dass die zu
definierende Anfragesprache baldmöglichst produktiv einsetzbar sein sollte, unklar war, inwieweit man auf vorhandenen Strukturen (d.h. auf XSL) aufbauen sollte. Auch musste erst
einmal definiert werden, welche Funktionen von einer Anfragesprache abgedeckt werden
sollten. Dabei kam anfangs (d.h. während des Workshops QL1 `98) die Frage auf, ob eine Anfragesprache allen Anforderungen genügen könne, oder ob man mehrere Anfragesprachen
bräuchte.
Inzwischen ergeben sich aufgrund der obigen Szenarien die folgenden Anforderungen an eine
XML-Anfragesprache:
• Sie sollte der Forderung von XML nach Einfachheit entsprechen, so daß sie schnell
gelehrt bzw. erlernt werden kann, für den Programmierer lesbar ist und in verschiedenen Umgebungen eingesetzt werden kann.
• Sie sollte ausreichend mächtig sein und Vorteile z.B. von (nicht notwendigerweise
vorhandenen) Schemas ausnutzen
• Sie sollte XML als Input erhalten und XML als Output liefern (die Frage des OutputFormats blieb anfangs in der Diskussion offen).
• Sie sollte skalierbar sein, so dass mit einem oder mit mehreren XML-Dokumenten
parallel gearbeitet werden kann.
1.3 Datenbankanfragen als Messlatte
XML-Dokumente haben hinsichtlich des Speicherns von Daten vieles mit Datenbanken gemeinsam. Deshalb ist für die Anforderungen an die Funktionalität einer XML-Anfragesprache
ein Vergleich mit den Möglichkeiten von Datenbank-Anfragesprachen hilfreich. Ein bekanntes Beispiel für alle, die irgendwann mit relationalen Datenbanken gearbeitet haben: SQL
(Structured Query Language).
Relationale Datenbank:
kurse-Tabelle
kursnummer kurstitel
termin
teilnehmerzahl
99
XML und Datenbanken
SS2002
11
referate-Tabelle
teilnehmerID kursnummer
referatthema
9999999
99
Überblick XML
1
QL ´98 war der Workshop für Query Languages, der 1998 vom W3C organisiert wurde
Seite 4
Annette Gutjahr
...
4365666
99
XQL, XPath
...
SQL bietet verschiedene Möglichkeiten, die Informationen aus den Tabellen zu filtern und zu
sortieren:
• Filtern der Informationen aus einer Datenbank nach bestimmten Kriterien:
o zeilenweise
SELECT *
FROM kurse
WHERE kurstitel = "XML und Datenbanken"
o
Spaltenweise
SELECT kurstitel, termin
FROM kurse
•
Zusammenfassen von Informationen: Mehrere Einzelinformationen aus mehreren
Datensätzen zu einer neuen Information aggregieren, z.B. Durchschnittsbildung
SELECT AVG(teilnehmerzahl)
FROM kurse
•
Sortieren von Informationen
SELECT kurse
ORDER BY teilnehmerzahl
•
Verschmelzen von Tabellen
o Inner Join, Equijoin
Oft benötigt man Informationen aus mehr als einer Tabelle, um ein sinnvolles
Ergebnis zu liefern
SELECT kurse.kurstitel, referate.referatthema
FROM kurse INNER JOIN kategorie ON kurse.kursnummer =
referate.kursnummer
WHERE referate.kursnummer= “99”
o Verschmelzen von Tabellen (Outer Join)
Benötigt man Informationen von mehreren Quellen, so möchte man oft die Informationen einer Tabelle ausgeben, selbst wenn die entsprechende Information in keiner anderen Tabelle vorliegt, z.B. um alle Kurse mit den dazugehörigen Referaten auszugeben. Das Ergebnis soll aber auch die Kurse mit ausgeben, für die keine Referate gehalten werden.
• Manipulation des Inhalts: Der Inhalt einer Datenbank kann in SQL selbst verändert
werden, durch Einfügen, Verändern oder Löschen von Datensätzen. Für diese Anforderungen gibt es aber andere Möglichkeiten in XML, z.B. DOM, sie müssen nicht von
einer Anfragesprache abgedeckt werden.
• Informationen aus mehr als einer Quelle: Manchmal benötigt man Informationen, die
aus mehreren Datenbanken zusammengefasst werden, z.B. eine Kursübersicht der
Kurse des Informatikfachbereichs und des Mathematik-Fachbereichs.
• Prozedurales Arbeiten: Die Möglichkeit, vordefinierte Prozeduren/Makros für bestimmte Arbeitsschritte zu verwenden.
Aber XML-Dokumente besitzen im Vergleich zu relationalen Datenbanken einige Besonderheiten. Wo liegen nun die Unterschiede zwischen Datenbanken und XML-Dokumenten?
Dazu betrachten wir folgendes Beispiel:
1.4 Ein XML-Dokument (Beispiel)
Als aktuelles Beispiel für ein XML-Dokument nehmen wir eine Liste zur Beschreibung dieses
Kurses:
<?xml version='1.0'?>
<!-—Diese Datei charakterisiert das Seminar: XML und Datenbanken -->
<kurs typ='seminar'>
<titel>XML und Datenbanken</titel>
Seite 5
Annette Gutjahr
<lehrgebiet>Praktische Informatik IV</lehrgebiet>
<betreuer>
<grad>Prof. Dr.</grad>
<vorname>Hartmut</vorname>
<nachname>Güting</nachname>
</betreuer>
<betreuer>
<grad>Dipl.Inf.</grad>
<vorname>Dirk</vorname>
<nachname>Ansorge</nachname>
</betreuer>
<literatur>Kurstext</literatur>
<termin>SS2002</termin>
<block thema='Überblick'>
<referat>
<referatthema>Überblick XML</referatthema>
<literatur>http://www.w3.org/TR/REC-xml</literatur>
<literatur>http://www.w3.org/TR/xsl</literatur>
<referent>
<vorname>Edmund</vorname>
<nachname>Buchbinder</nachname>
</referent>
<Beurteilung>sehr gut</Beurteilung>
</referat>
</block>
<block thema='Semistrukturierte Systeme'>
<referat>
<referatthema>Lorel</referatthema>
<referent>nn</referent>
</referat>
<referat>
<referatthema>Lore</referatthema>
</referat>
</block>
<block thema='Anfragesprachen für XML'>
<referat>
<referatthema>XPath, XQL</referatthema>
<referent>Annette Gutjahr</referent>
</referat>
...
</block>
</kurs>
1.5 Worin bestehen die Unterschiede zwischen relationalen
Datenbanken und XML-Dokumenten?
Auf den ersten Blick kann man den Inhalt des oben aufgeführten XML-Dokumentes man genausogut direkt in einer Datenbank abspeichern. Aber es gibt einige, teilweise gravierende,
Unterschiede zwischen XML-Dokumenten und Datenbanken.
• SQL-Zeilen haben eindeutige Bezeichner (primary key) – eindeutige Bezeichner sind
in XML möglich, aber nicht notwendig, da die Elemente in XML nach ihrer Reihenfolge sortiert sind
• SQL-Zeilen implizieren keine Reihenfolge, z.B. eine chronologische Reihenfolge der
Referate während des Seminars.
• SQL-Strukturen liefern keine hierarchische Kapselung, z.B. gibt es keine Möglichkeit,
die Referatthemen innerhalb der kurse-Tabelle beim Datensatz für den jeweiligen
Kurs zu kapseln. Man benötigt eine eigene Tabelle mit Verweisen, die zurück auf den
Seite 6
Annette Gutjahr
zugehörigen Kurs der anderen Tabelle verweisen. So erhält man 1 zu 1- und 1 zu nBeziehungen, die aber auf jedes beliebige Element der Datenbank verweisen können.
• XML unterscheidet syntaktisch zwischen Attributen und nur-Text-Inhalten von
Elementen. Semantisch sind jedoch beide identisch. Es sollte schlichtweg egal sein, ob
man in obigem Beispiel den Kurstitel als Text-Element oder als Attribut schreibt. Eine
XML-Anfrage sollte beide Möglichkeiten behandeln können.
• XML erlaubt Elemente mit verschiedenen Inhalts-Modellen (mixed content model) –
Elemente können sowohl Textinformation als auch Unter-Elemente enthalten, z.B. bei
einem Buch erscheint beliebiger Text, in den einige Markup-Elemente eingestreut
sind, z.B. für Hervorhebungen, Fußnoten, etc.
Anfragesprachen für XML müssen mit diesen Besonderheiten umgehen können und die damit
verbundenen Möglichkeiten möglichst vorteilhaft nutzen.
2 XQL (W3C Proposal, September 1998)
2.1 Einführung und Motivation
Bereits 1998 begannen mehrere Arbeitsgruppen an Vorschlägen für XML-Anfragesprachen
für das W3C zu arbeiten. 13 sog. Position Papers gingen für den QL´98 Workshop beim W3C
ein.
Einer der Vorschläge war die Sprache XML-QL (vgl. XML-QL-Referat). Hier richteten sich
die Autoren nach den Anfragemöglichkeiten in hierarchischen und relationalen Datenbanken:
Es wird eine Auswahl an Daten getroffen und die Ausgabeform dieser Daten festgelegt.
XML-QL ist sehr flexibel, aber es hat einige Nachteile: Die Reihenfolge der Daten aus dem
Ursprungsdokument geht verloren – ein Problem für XML-Text-Dokumente (z.B. ein Buch,
bei dem die Reihenfolge der Paragraphen verloren geht). Außerdem geht die Strukturinformation des ursprünglichen Dokumentes verloren, es sei denn, man schreibt diese noch einmal
komplett in die Anfrage hinein.
Etwa gleichzeitig mit dem Vorschlag für XML-QL ging ein zweiter Vorschlag bei der XSL
Working Group ein, der stärker strukturorientiert war: XQL (XML Query Language (XQL),
September 1998). Die Struktur und die Reihenfolge des Originaldokuments bleibt so weit wie
möglich erhalten, während der Inhalt gemäß der Anfrage reduziert wird. Dieser Vorschlag
fand u.a. durch "Microsofts evangelistische Bemühungen" (nach [6]) große Aufmerksamkeit.
2.2 Beispiel
Eine Anfrage, um eine Liste der Referatthemen zu erhalten, sieht in XQL so aus:
//referatthema
Die Anfrage liefert dann folgendes Ergebnis:
<xql:result>
<referatthema>Überblick XML</referatthema>
…
</xql:result>
Hier wird die Reihenfolge des ursprünglichen Dokuments beibehalten. In diesem Beispiel ist
noch ein <xql:result>-Container mit ausgegeben. Ein XQL-Prozessor kann auch einfach eine
sortierte Liste der <referatthema>-Elemente zurückliefern.
Auch hierarchische Informationen werden bei XQL erhalten. Wenn wir beispielsweise nur die
Referate des Blocks mit dem Titel „Semistrukturierte Systeme“ erhalten möchten, brauchen
wir die folgende Anfrage:
block[@thema=“Semistrukturierte Systeme”]/referat.
Als Ergebnis erhalten wir dann:
<xql:result>
<referat>
Seite 7
Annette Gutjahr
</referat>
<referat>
<referatthema>Lore</referatthema>
</referat>
</xql:result>
2.3 Syntax und Semantik
XQL ist als Erweiterung der XSL Pattern Syntax angelegt. Es baut auf die Möglichkeiten von
XSL auf, Knotenklassen zu finden und erweitert die Syntax um Boolean-Logik, Filter, Indizierung von Knotenmengen u.a.. Dadurch ermöglicht XQL über XSL hinaus die Suche nach
speziellen Elementen und nach Knoten mit bestimmten Eigenschaften.
2.3.1 Terminologie
Die XQL Pattern Syntax ist deklarativ, nicht prozedural angelegt: Man beschreibt was, d.h.
welche Art von Knoten, gesucht werden soll, nicht aber wie etwas gesucht wird.
• Werte: Knoten (node), Boolean, Zahl (number), String, set of values (nicht geschachtelt)
• Knoten: Dokument (document entity), Anweisung (pi), Kommentar, Element, Elementattribut, (markup-begrenzter) Textbereich;
• Ergebnis:
Die Menge, die von einem XQL-Ausdruck als Ergebnis geliefert wird, behält die Dokumentreihenfolge, die Hierarchie und die Identität – soweit diese definiert sind – bei:
Elemente werden also in der richtigen Reihenfolge ohne Wiederholungen geliefert; Attribute werden unsortiert, aber ohne Wiederholungen geliefert. Das Binärformat für das Ergebnis einer Anfrage ist nicht spezifiziert, d.h. eine Anfrage könnte einen Knoten, eine
Knotenliste, ein XML-Dokument, einen Array oder eine andere Struktur zurückliefern.
2.3.2 XML Patterns (Kernfunktionalität)
Die Syntax zur Navigation durch die Elemente eines XML-Baumes ähnelt der Notation für
das Navigieren in Dateiverzeichnissen.
• Collections:
Mehrere Elemente eines bestimmten Namens werden durch den Namen zusammengefasst:
kurs
•
Kinder und Nachfolger
"/" (child operator) und "//"(rekursiver Abstieg): links: Menge, aus der die Elemente ausgewählt werden sollen; rechts: eine Menge, die bestimmt, welche Elemente auszuwählen
sind
kurs/betreuer, kurs//referatthema,
kurs/literatur, kurs//literatur, kurs//referat/literatur
•
auf die Kind-Elemente des aktuellen Kontexts kann durch "*" verwiesen werden, ohne
einen Namen zu nennen
kurs/*, kurs/*/nachname, */*, *[@typ]
•
•
Such-Kontext:
XQL erlaubt die Auswahl des Wurzel-Kontexts ("/")oder des aktuellen Kontexts (Default
oder explizit "./"). "./"-Prefix nur nötig für ".//", d.h. für den rekursiven Abstieg relativ
zum aktuellen Kontext.
./betreuer (äquivalent zu betreuer), /kurs, //nachname
Attribute
Attribute ("@" vorangestellt) und Subelemente werden gleichbehandelt (Attribute können
keine Subelemente enthalten, deshalb keine Pfad-Operatoren auf Attribute anwenden)
@typ, block/@thema
Seite 8
Annette Gutjahr
•
Filter
Einschränkungen und Verzweigungen können auf alle Collections angewandt werden:
"[subquery]". Alle Elemente werden auf die subquery geprüft und falls sie zu FALSE ausgewertet werden, werden sie nicht in die Ergebnismenge aufgenommen. Wird eine Collection in den Filter gestellt, wird FALSE generiert, wenn diese leer ist, sonst TRUE.
Leere Filter sind nicht erlaubt. Aber es können beliebig viele Filter auf jeder beliebigen
Ausdrucksstufe aneinandergereiht werden.
kurs/betreuer[grad], kurs[@typ='seminar'], kurs[termin='SS2002']/title,
kurs[betreuer][literatur]
•
•
Gruppieren: durch Klammerung (für Klarheit, bzw. wo nötig)
Boolean Expressions: Syntax: lvalue $op$ rvalue
für Subqueries: z.B. um alle Knoten eines Wertes oder Wertebereiches zu finden.
• Boolean AND und OR: $and$, $or$
kurs[betreuer $and$ termin], referat [(referent $or$ literatur) $and$
referatthema]
•
Boolean NOT: $not$
referat[referatthema $and$ $not$ referent]
•
Äquivalenz: "=" bzw. $eq$; "!=" bzw. $ne$
' oder " als String-Begrenzung möglich
betreuer[nachname = 'Güting'], betreuer[nachname $eq$ 'Güting],
kurs[@typ != 'seminar'], kurs[@typ $ne$ 'seminar']
•
Methoden: fortgeschrittene Manipulation von Mengen (Collections)
Syntax {method}(arglist) – Bei Methodennamen wird Groß-Kleinschreibung unterschieden. Methoden beziehen sich auf den Referenz-Knoten.
referent[text() = 'Bob'], referent[vorname!text() = 'Bob']
Bang-Operator: gleichbedeutend mit dem zweiwertigen Child-Operator (/), der einen
Pfad festlegt. Einziger Unterschied: ! benötigt auf der rechten Seite einen XQL- Funktions- oder Methodenaufruf.
o text() – Text in einem Element, konkateniert den Text aller Nachfolger des Elements, ohne Tag-Namen oder Attributwerte, Kommentare etc.
o value() – Wert eines Elementes; falls keine Typinformation, liefert es das gleiche
wie text()
o nodeType() – Zahl, um den Knotentypen anzuzeigen:
Element = 1; Attribut = 2; Text = 3; PI = 7; Kommentar = 8; Dokument = 9
o nodeName() – Tag-Name des Knotens, inkl. Namespace-Prefix (String)
o index() – Index des Knotens innerhalb des Parents (beginnend bei 0):
referent[index() $lt$ 3]
o Shortcuts: value() gilt implizit, falls es nicht dasteht
o Indizierung: betreuer[0], referent[vorname] [2]
o end() – letztes Element einer Collection – relativ zum Parent
referat[end()]
2.3.3 XQL-Erweiterungen
Die obige Funktionalität beschreibt den Mindestsatz, der zwischen XQL-Clients benötigt
wird. Die XQL-Erweiterungen beschreiben zusätzlich implementierbare Funktionalität.
• Namespaces: waren zum Zeitpunkt der Definition von XQL selbst noch nicht genau definiert. Fest stand deshalb nur die Regelung, daß, falls kein Namespace für die Anfrage definiert ist, das Prefix verglichen wird.
book, my:book, my:book[my:author], my:*, *:book
•
baseName(), namespace(), prefix()
Menge von Attributen suchen:
@*, @*:style, @my:*
Seite 9
Annette Gutjahr
•
Vergleiche: case sensitive: $lt$, $le$, $gt$, $ge$, bzw. Shortcuts: <, <=, >, >=
case insensitive: $ieq$, $ine$, $ilt$, $ile$, $igt$, $ige$
author[last-name = 'bob' $and$ price $gt$ 50],
author[publications!count() $gt$ 10]
•
falls Datentyp-Information vorhanden ist, wird ggf. der linke auf den rechten Wert
gecastet. Derzeit nur Datumsformat: books[pub_date < date('1995-01-01']
Vereinigung und Schnittmenge $union$ bzw. |, $intersect$
first-name $union$ last-name, bookstore/(book|magazine)
•
Any- und All-Semantik: $any$, $all$ vor dem Ausdruck:
author[last-name = 'Bob'], author[$any$ last-name = 'Bob'], author[$all$
last-name != 'Bob']
•
Collection-Methoden
textNode(), comment(), pi(), element(['name']), attribute(['name']), node()
p/textNode()[1], //comment()[1]
•
•
•
•
Aggregationsmethoden
count() – Anzahl der Knoten einer Menge
nodeTypeString() – Art des Knotens als String
ancestor(query): nächster Vorfahre der Anfrage; ancestor(book)
Subscript-Operator [] für eine Bereich von Elementen
author[0, 2 $to$ 4, -1]
2.4 Diskussion
XQL hat anderen Vorschlägen gegenüber, die beim Workshop QL ´98 eingereicht wurden,
einige Vorteile:
• Durch die Kürze und seine Lesbarkeit kann XQL auch eingesetzt werden, wo XSL
selbst unangebracht wäre, z.B. um Anfragen in Attributen oder als einfache Strings in
Programmiersprachen unterzubringen.
• Um das Ziel der Skalierbarkeit zu erreichen, und dennoch möglichst einfach zu
bleiben, erweitert XQL lediglich die Muster von XSL, nicht die gesamte XSLSprache.
• Der wichtigste Unterschied gegenüber anderen, eher datenbankorientierten
Vorschlägen ist die Tatsache, daß XQL-Ergebnisse die Struktur und die Reihenfolge
des Originaldokuments so weit wie möglich erhalten, während der Inhalt gemäß der
Anfrage reduziert wird.
Bei dem Vorschlag von XQL gibt es allerdings auch einige grundsätzliche Probleme, die
bereits während des Workshops diskutiert wurden:
• Dazu gehört die Frage, wie weit eine Anfragesprache überhaupt gehen solle, und ob
XQL überhaupt eine komplette Anfragesprache sei, da man über die Pfadangaben von
XQL die Elemente zwar findet, aber nicht sagen kann, was damit geschehen soll.
Viele Funktionen, die eine Datenbankanfragsprache bietet, können deshalb von XQL
nicht abgedeckt werden, wie z.B. die Manipulation des Inhalts.
• Auch das Vorgehen, XSLs Musterbeschreibungssprache (XSL pattern language) als
Grundlage zu nehmen, wurde gegensätzlich diskutiert, da seine Möglichkeiten der
Selektion und der Mustersuche ungenügend seien. XSL wurde nur für den Zugriff und
das Arbeiten mit jeweils einem Dokument geschaffen; man kann also keine
Informationen aus mehreren Quelldokumenten kombinieren..
Außerdem gibt es einige konkrete Probleme:
• XQL kann keine Informationen unterscheiden. Da XQL mit den Knoten arbeitet und
nicht mit der eigentlichen Information, gibt es keine Möglichkeit, festzustellen, ob
zwei Knoten den gleichen Inhalt haben. Es gibt also keine Möglichkeit, eine Liste aller
Referenten von Seminaren zu erhalten, die Doppelnennungen ausschließt. DoppelSeite 10
Annette Gutjahr
nennungen treten immer dann auf, wenn Studenten in mehreren Seminaren Referate
halten.
• XQL kann keine Beziehungen umsortieren (pivot relationships) – eine Technik, die
bei der Arbeit mit relationalen Datenbanken üblich ist: Wir haben beispielsweise eine
Liste von Referaten mit deren Referenten. Aber wir möchten eine Liste mit Referenten
und deren Referatsthemen. Da XQL die Hierarchie der Knoten beibehält, ist eine
solche Anfrage mit XQL, wie es ursprünglich gedacht war, unmöglich.
• XQL ist kein Standard. Es ist lediglich ein Vorschlag, der beim W3C als
Diskussionsgrundlage für einen Workshop (1998) eingereicht wurde. Aber er dient als
Grundlage für Implementationen, die nicht bis zur Freigabe eines endgültigen
Anfrage-Standards warten können/wollen. XQL wurde u.a. von der GMD (GMDIPSI), von Microsoft (Internet Explorer 5.0, von der Software AG (Tamino) in ihren
Systemen implementiert.
Während XQL einen intuitiven Umgang mit hierarchisch strukturierten Daten in einem XMLDokument ermöglicht, kann es die Daten nicht so flexibel wie z.B. XML-QL manipulieren.
Eine ideale Anfragesprache sollte also beide Ansätze vereinen: die Flexiblität von XML-QL
und den hierarchischen Einstieg von XQL.
3 XPath Version 1.0
3.1 Einführung und Motivation
XPath ist der direkte Nachfolger des oben beschriebenen XQL-Vorschlags. XPath2 hat beim
W3C den Status einer "Recommendation". Diese "Empfehlungen" (Recommendations) des
W3C bilden inzwischen eine Art Quasi-Standard.
XPath ist eine Nicht-XML-Sprache, die dazu dient, mittels einer Pfadnotation auf einzelne
Knoten eines XML-Dokumentes zuzugreifen, während Reihenfolge und Struktur des
Originaldokumentes erhalten bleiben.
Man kann in XPath Ausdrücke schreiben, die auf den ersten titel eines kurses verweisen,
oder auf das zweite Kind-Element des zweiten referenten usw.. XPath identifiziert die
Knoten nach Position, relativer Position, Typ, Inhalt und einigen anderen Kriterien.
XSLT wird dann eingesetzt, um die Ergebnisse dieser Anfragen zu bearbeiten und die Daten
beliebig darzustellen: um neue Elemente einzufügen und Elemente neu zu sortieren (ähnlich
den Möglichkeiten von XML-QL). XPath Ausdrücke können auch Zahlen, Strings oder
Booleans repräsentieren. Dadurch können XSLT Stylesheets einfache Berechnungen für
Nummerierungen, Tabellen und Gleichungen auführen. String-Manipulationen in XPath ermöglichen XSLT z.B. den Namen eines Buchkapitels in einer Überschrift in Grossbuchstaben
und bei einem Verweis innerhalb des Textes in Kleinbuchstaben darzustellen.
XPointer-Erweiterungen zu XPath ermöglichen nicht ganze Knoten, sondern bestimmte
Stellen und Bereiche eines Dokumentes anzusprechen, Informationen durch String-Vergleiche
zu lokalisieren und Adressen in URI-Referenzen als Bereichs-Bezeicher zu verwenden.
Man versuchte, in XPath 1.0 die Syntax und Semantik zusammenzufassen, die für gemeinsame Funktionalität von XSL Transformations3 und XPointer4 benötigt wurde:
Damit stellt die Kombination von XPath, XSLT und XPointer ein mächtiges Werkzeug dar,
das den hierarchischen Einstieg in Dokumente wie XQL verwendet, aber auch flexible
Möglichkeiten für die Manipulation der Daten bietet.
Im weiteren konzentrieren wir uns nur auf XPath.
2
XML Path Language (XPath) Version 1.0, W3C Recommendation November 1999
XSL Transformations (XSLT) Version 1.0, W3C Recommendation November 1999
4
XPointer Language (XPointer) Version 1.0, W3C Candidate Recommendation September 2001
3
Seite 11
Annette Gutjahr
3.2 Das Datenmodell von XPath
Ein XML-Dokument ist für XPath im Gegensatz zu XQL nun explizit ein Baum mit Knoten,
von denen einige wiederum andere Knoten enthalten können. Dabei wird die
Metainformationen von XML ausgenutzt, um ein Dokument hierarchisch in verschiedene
Knoten zu gliedern.
Über alle Knoten eines Dokumentes ist eine Ordnung definiert (document order), die sich
nach der Reihenfolge des Knotenanfänge (d.h. der zugehörigen name tags) innerhalb des
Dokumentes richtet. Vor den Kindern eines Knotens werden Namespace-Knoten und danach
Attributknoten einsortiert. Auch die Kinder eines Knotens sind wiederum sortiert.
XPath navigiert nun mit einer Pfadnotation durch diese Baumstruktur und berechnet für die
einzelnen Knotentypen ein String-Wert. Manche Knotentypen besitzen zusätzlich einen
Namen. Da XPath die XML namespaces (bei der Formulierung des XQL-Proposals waren
diese noch nicht definiert) unterstützt, bildet der Name eines Knotens ein Paar, bestehend aus
einem lokalen Teil und einem - möglicherweise null-wertigem - namespace URI.
Die Baumstruktur eines XML-Dokumentes kennt sieben verschiedene Knotentypen5 (vgl.
Beispieldokument).
• Dokument (document entity) bzw. Wurzelknoten (root node)
Kinder des Wurzelknotens sind der Elementknoten für das Dokument, Instruktionen,
Kommentare zu den Instruktionen und Kommentare im Prolog und nach dem Ende
des Dokumenttextes.
• Instruktionen (processing instruction nodes)
Für jede Anweisung gibt es einen Knoten (bis auf die Anweisungen, die in der DTD
erscheinen).
• Kommentare (comments): 
Für jeden Kommentar gibt es einen Knoten (außer den Kommentaren in der DTD).
• Elemente (element nodes): kurs
Die Kinder von Elementen sind Elementknoten, Kommentare, Instruktionen und
Texte. Für Elemente gibt es die Möglichkeit eindeutiger Bezeichner.
• Attribute (attribut nodes): typ mit Wert seminar
Zu einem Element gehört eine Menge von Attributen. Default-Attribute werden wie
direkt gesetzte Attribute behandelt. Das Element ist der Vater der zugehörigen Attribute, diese werden jedoch nicht als Kinder des Elements betrachtet. Elemente teilen
sich auch keine Attributknoten, d.h. Attribute verschiedener Elemente sind immer verschiedene Attributknoten. Beim Test auf Gleichheit durch '=' wird auf Wertegleichheit, nicht auf Identität getestet.
• Text (text nodes; markup-begrenzter Textbereich): XML und Datenbanken
In einem Textknoten werden immer möglichst viele Zeichen zusammengefaßt.
• Namensraum-Knoten (namespace nodes): Jedes Element hat dazugehörige
Namespace Nodes - einen für jedes namespace-Prefix, das (u.U. implizit) gültig ist.
Und wieder gilt: das Element ist der Parent für die Namespace Nodes, diese werden
jedoch nicht als Kinder dieses Elementes geführt.
3.3 Beispiel
XPath erhielt seinen Namen von der Pfadnotation, die es für die Navigation durch die Hierarchie eines XML-Dokumentes verwendet, und die einer URL-Notation entspricht. Die Syntax
ist nicht XML-konform, so dass XPath u.a. auch in URIs und in XML-Attributen benutzt
werden kann.
5
XPath kennt keine CDATA-Bereiche, Bezüge auf Entitäten (entity references) und DTDs, da XPath auf XMLDokumenten arbeitet, nachdem diese Informationen bereits in das Dokument integriert wurden.
Seite 12
Annette Gutjahr
/, betreuer, child::betreuer, child::*, child::text(), child::node(),
attribute::typ, attribute::*,
descendant::para, ancestor::div, ancestor-or-self::div …
3.4 Syntax und Semantik
Das wichtigste Konstrukt in XPath ist ein Ausdruck (expression). Dieser liefert ein Objekt
vom Typ node-set, boolean, number (float) oder string. Die Auswertung eines Ausdrucks
bezieht sich immer auf einen bestimmten Kontext6.
XPath-Ausdrücke werden oft in XML-Attributen benützt. Die hier aufgeführte Grammatik
bezieht sich auf den Attribut-Wert nach einer XML 1.0 Normalisierung, d.h. ein < in der
Grammatik muß in der XML-Quelle quotiert werden, d.h. als < eingegeben werden. Anführungszeichen können als " oder als ' angegeben werden oder man verwendet "
anstelle von ' bzw. umgekehrt.
3.4.1 Ausdrücke
§
Pfadangaben (location paths)
Die wichtigste Art von Ausdrücken. Sie benützen mindestens einen Location Step zur
Auswahl einer Knotenmenge aus dem Dokument.
Es gibt absolute (beginnend mit '/') und relative Pfadangaben, bestehend aus den Location
Steps Achse, Knotentest und Prädikaten.
o Achse: definiert die im Baumgeflecht betrachtete Beziehung. Dabei unterscheidet
man vorwärts- oder rückwärts-Achsen (forward/reverse axis) beginnend mit Zählposition 1:
child | descendant | parent | ancestor | following-sibling | preceding-siblings |
following | preceding | attribute | namespace | self | decendant-or-self | ancestor-orself
child::titel, attribute::thema, /child::betreuer[position()=2],
descendant-or-self::literatur
o Knotentest (node test): wählt einen Knotentyp oder einen benannten Knoten oder
eine Funktion aus. Für jede Achse gibt es einen Haupt-Knotentyp (attribute-Achse:
Attribut; namespace-Achse: Namespace; andere Achsen: Element).
child::text(), child::node(), attribute::*, child::comment(),
child::processing-instruction(pi),
o Prädikate, die beliebige Ausdrücke zum Verfeinern der Auswahl benutzen. Sie
filtern eine Knotenmenge in bezug auf eine Achse und liefern eine neue Menge.
//betreuer[grad = "Dipl.Inf."]
XPath unterstützt neben = auch relationale Operatoren, wie <, >, <=, >=
boolean Operatoren and und or, sowie einen Mindestrepertoire an
und !=,
Kernfunktionalität zur Arbeit mit Zahlen, Strings etc., die in Prädikaten verwendet
werden können. Kommen XPath-Ausdrücke in XML-Dokumenten vor, müssen <
und <=-Operatoren gem. XML 1.0-Regeln quotiert werden (z.B. durch < und
<=).
<xsl:if test="@value < 10">...</xsl:if>
o Abkürzungen:
block, text(), @thema, @*, block[1], block[last()],
kurs//literatur, ../@thema, .., .//betreuer
Ø child:: kann als Default-Achse weggelassen werden.
betreuer/nachname = child::betreuer/child::nachname
6
Ein Kontext besteht aus einem Knoten (context node), zwei Integer-Werten > 0 (context position und context
size), einer Menge von Variablenbindungen, einer Funktionsbibliothek (XSLT und XPointer erweitern die
nachfolgend aufgeführte Funktionsbibliothek von XPath um eigene Funktionen) und einer Menge gültiger
namespace declarations (Prefixes werden auf namespace URIs gemappt).
Seite 13
Annette Gutjahr
Ø attribute:: wird abgekürzt zu @
kurs[@typ="seminar"] = child::kurs[attribute::typ="seminar"]
Ø // ist die Abkürzung für /decendent-or-self::node()/
aber: //betreuer[1] != /descendant-or-self::betreuer[1]
Ø . kurz für self::node()
Ø .. kurz für parent::node()
../titel = parent::node()/child::titel
Ø wildcards: * für Element-Knoten, node( ) für alle Knoten, @* für
Attributknoten
Ø | für Vereinigung von Knotenmengen //betreuer | //referent
Pfadangaben sind nicht die einzige Art von XPath-Ausdrücken. XPath-Ausdrücke können
auch Zahlen, Boolean-Werte und Strings als Ergebnis liefern. Gültige XPath-Ausdrücks sind
z.B. auch 3.141529, 2+2, 'Rosalind Franklin', true( ), 32.5 < 76.2E-21,
position()=last( )
§
§
§
§
Numbers: entspricht floating-point number (incl. NaN, +/- Unendlich, +/- 0)
+: Addition; -: Subtraktion (Whitespace vor Minus, um vom Bindestrich bei Wörtern zu
unterscheiden), *: Multiplikation, div: Division, mod: Rest (truncating division, wie % in
Java) (5 mod 2=1, 5 mod -2 = 1, -5 mod 2 = -1, -5 mod -2 = -1)
Strings: Sequenz von 0 oder mehr Zeichen (Achtung bei precomposed und decomposed
Formen von Zeichen (z.B. bei Akzent) -> vorher normalisieren zu kanonischer Form)
Booleans: and und or: nicht-strikte Auswertung.
Priorität: or; and; =, !=; <=, <, >=, >; (links-assoziativ, d.h. 3>2>1 = (3>2)>1
Funktionsaufrufe: XPath-Funktionen liefern einen der folgenden Typen als Ergebnis
zurück: Boolean, Zahl, Knotenmenge oder String. Über den Namen wird die Funktion aus
der zum Kontext gehörenden Funktionsbibliothek ausgewählt und anschließend die
einzelnen Argumente ausgewertet, nachdem sie, falls erforderlich, zum jeweiligen Typ
konvertiert wurden. Beispiele sind round( 3.14), starts-with(nachname, 'T'),
concat("a", "b", "c")
o Knotenmengen-Funktionen: Diese Funktionen arbeiten mit Knotenmengen, die
eine geordnete Sammlung von XPath-Knoten enthalten. Es sind Funktionen zur
Größe und Position des aktuellen Kontexts, Auswahl benannter Elemente,
Namensabfrage u.a. Beispiele sind position( ), last( ), count( ), id( ).
o String Funktionen
Funktionen zum Konvertieren von Objekten in Strings, Konkatenation von
Strings, Auswahl von Substrings, Bestimmen der Stringlänge und Umformung von
Strings u.a. string( ), starts-with('Richard', 'Ric' ),
contains('Richard', 'ard'), substring-before('12/05/1968', '/'),
string-length(//name[position( )=1])
o Boolean Funktionen
Funktionen zur Konvertierung von Objekten in Booleans, Umkehrung des Boolean
Wertes, Abfrage auf true oder false u.a.. true( ), false( ), not( ),
boolean( )
§
o Numerische Funktionen
Funktionen zur Konvertierung von Objekten in Zahlen, Summenberechnung,
Rundung u.a.. number( ), round( ), floor( ), ceiling( ), sum( )
Lexikalische Struktur: Zerlegen von Ausdrücken in Tokens liefert das jeweils längste
Token
3.5 Diskussion
Während XPath in Kombination mit XSLT den Entwicklern eine Menge an Möglichkeiten
zur Steuerung von Anfragen und der Darstellung der Daten einräumt, hat das W3C erkannt,
dass diese beiden Techniken keine endgültige Lösung sein können:
Seite 14
Annette Gutjahr
•
XPath 1.0 orientiert sich immer noch am Prinzip der Einfachheit, so werden z.B. nur
die vier Datentypen node-set, boolean, number und string unterstützt. Andererseits
verursacht genau dies Probleme, wenn es um das Arbeiten mit Werten mit zugehöriger
Typinformation wie z.B. Datumsangaben geht. (Die nächste XPath-Version verfügt
deshalb über wesentlich mehr Datentypen.)
• Einige Anfragen (wie z.B. die o.g. Liste von Referenten und deren Referaten) sind mit
XPath und XSLT recht schwierig.
• Zusätzliche Funktionen, die normale Anfragesysteme bieten (wie z.B. das Hinzufügen
oder Aktualisieren von Elementen) sind einfach nicht vorhanden.
Sucht man im Internet nach Einträgen zu XPath, kann man – je nach Suchmaschine – z.T.
sehr viele Einträge finden. XPath scheint bereits recht oft eingesetzt zu werden, allerdings
nicht als eigenständiges System, sondern eingebettet in anderer Parser-Software für XMLDokumente. Ähnlich wie SQL kommt XPath in vielen verschiedenen Situationen zur
Anwendung: Da gibt es spezielle Anfrage-Werkzeuge für XML-Dokumente, native XMLDatenbanken (z.B. XIndice vom Apache XML Projekt oder Tamino von der Software AG),
oder XPath wird als Teil einer umfangreicheren Sprache wie XSLT oder XQuery eingesetzt,
oder als Teil eines Java-Programmes für die Suche auf XML-Dokumenten
3.6 Weiterentwicklung von XPath:
Inzwischen hat das W3C eine XML Query Working Group gebildet, mit dem Ziel, flexible
Anfragemöglichkeiten zu liefern, um Daten aus realen und virtuellen Dokumenten im Web zu
erhalten.
Seit Dezember 2001 gibt es ein Working Draft für die XML Path Language (XPath) 2.0.
Diese ist das Ergebnis der Arbeiten der XSL und XML Query Working Groups. XPath 2.0 ist
eine Sprache, die sowohl auf dem oben beschriebenen XPath 1.0 als auch auf XQuery (siehe
eigenes Referat) aufbaut. XPath 2.0 und XQuery 1.0 sind eng verwandt, weitgehend mit
gemeinsamer Syntax und Semantik. XPath 2.0 ist nach wie vor dafür gedacht, in eine HostSprache (wie XSLT 2.0 oder XQuery) eingebettet zu sein. Und XQuery Version 1.0 enthält
XPath Version 2.0 als Subset.
Weitere Informationen zu XPath 2.0 enthalten die folgenden Dokumente:
• Das Datenmodell für XPath beschreibt die Information eines XML-Dokuments, die
für eine XPath-Prozessor zugänglich ist: XQuery 1.0 and XPath 2.0 Data Model
(http://www.w3.org/TR/xpath20/datamodel)
• Die statische und dynamische Semantik von XPath ist formal definiert in XQuery 1.0
Formal Semantics (http://www.w3.org/TR/xpath20/XqueryFormalSemantics)
• Die von XPath unterstützten Funktionen und Operatoren sind in XQuery 1.0 and
XPath 2.0 Functions and Operators definiert (http://www.w3.org/TR/xqueryoperators/)
4 Quellen, weitere Informationsmöglichkeiten
[1] J. Clark und S. DeRose. XML Path Language (XPath), Version 1.0. W3C
Recommendation 1999, http://www.w3.org/TR/xpath
[2] J. Robie, J. Lapp und D. Schach. XML Query Language (XQL). W3C Recommendation,
1998, http://www.w3.org/TandS/QL/QL98/pp/xql.html
[3] R. Anderson, M. Birbeck, et. al.. Professional XML.April 2000
[4] D. Chamberlin, D. Frankhauser, M. Marchiori, J. Robie: XML Query Requirements
W3C Working Draft, 2001, http://www.w3.org/TR/xmlquery-req
[5] E. R. Harold, W. S. Means: XML in a Nutshell - A Desktop Quick Reference,
January 2001, http://www.oreilly.com/catalog/xmlnut/chapter/ch09.html
Seite 15
Annette Gutjahr
[6] ML.com: Considering XSL Extensions, XQL and Other Proposals:
http://www.xml.com/lpt/a/1999/03/quest/index3.html: X
[7] E. R. Harold, Processing XML with Java, 2001,
http://www.cafeconleche.org/books/xmljava/chapters/ch16.html
[8] J. Robie: XQL FAQ, März 1999, http://www.ibiblio.org/xql/
Seite 16
Seminar 1912 – XML und Datenbanken
Einsetzen von YATL zur Optimierung von XML-Abfragen
über heterogene Datenquellen
Verfasser: Andreas Buschka
Datum: 17.06.2002
Basisliteratur:
„On Wrapping Query Languages and Efficient XML Integration“, Christophides, Cluet,
Siméon
„Your Mediators Need Data Conversion!“, Cluet, Delobel, Siméon, Smaga
Seminar 1912 – Thema: YATL – Autor: Andreas Buschka – Seite 1 von 15
Inhaltsverzeichnis
Teil 1: YAT..........................................................................................................................................3
Einleitung.........................................................................................................................................3
Aufbau von YAT.........................................................................................................................4
Komponenten..............................................................................................................................4
YAT Modell................................................................................................................................6
Instanziierung..............................................................................................................................7
Typisierung in YATL..................................................................................................................7
Architektur und Implementation......................................................................................................7
Teil 2: Techniken zur effizienten XML-Integration ............................................................................8
Einführung.......................................................................................................................................8
Probleme bei der Optimierung von XML-Abfragen...................................................................8
Lösungsvorschläge......................................................................................................................8
YAT Abfragen............................................................................................................................8
Umsetzung von Abfragen in Ausführungspläne.......................................................................10
Einbinden von Abfragefähigkeiten der Quellen............................................................................10
Exportieren der Abfragefähigkeiten zum Mediator..................................................................10
Ausnutzen der Abfragefähigkeiten zur Optimierung................................................................11
Verarbeitung von XML und Veränderung der BIND-Klauseln...............................................12
Neuschreiben auf Basis der Abfragefähigkeiten der Quellen...................................................13
Diskussion..........................................................................................................................................14
Literaturliste.......................................................................................................................................15
Teil 1: YAT
Einleitung
Will man Datenbankanwendungen schreiben, die Daten aus vielen verschiedenen Datenquellen
miteinander abgleichen, so steht man vor dem Problem, dass Daten von einem Format in ein
anderes übersetzt werden müssen, um in Abfragen verwendet werden zu können. Die bisherige Art,
„auf die Schnelle mal eben“ einen Übersetzer zu schreiben, führt zu schlecht dokumentierter und
kaum wiederverwendbarer Software.
YAT ist ein System zum Erstellen von Konvertierern. Es stellt eine Sprache (YATL, „Yet another
tree language“) zur Verfügung, die die Spezifikation von Daten auf hohem Abstraktionsniveau
erlaubt, und ermöglicht durch einen Mediator, die konvertierten Daten zusammenzuführen. Der
Import und Export von generierten Strukturen wird durch so genannte Wrapper durchgeführt.
RDBMS
Im
W port
rap -/E
pe xp
r
ort
DatensatzBaumstruktur
XML
Dokument
rt
-/Expo
Import
r
e
Wrapp
Baumstruktur
des XMLDokuments
Manipulation
der Baumstruktur
durch ein YAT-Programm
Neue
Baumstruktur mit
Knotennamen als
HTML Tags
HTML Import-/Export Wrapper
HTML
Dokument
Abbildung 1: YAT verändert den Aufbau von Strukturen aus mehreren Quellen
Aufbau von YAT
Komponenten
Middleware Modell
YAT benutzt Wrapper und Mediatoren, um die Konvertierung von Daten durchzuführen. Ein
Wrapper übersetzt Daten einer bestimmten Datenquelle, z.B. einer XML-Datei oder einer Tabelle
in einer relationalen oder objektorientierten Datenbank in eine interne Repräsentation, die von
Konvertierprogrammen genutzt wird.
Dies kann z.B. die ODMG-Repräsentation sein, in dem ein Objekt drei Bestandteile hat:
•
•
•
Identität: Jedes Objekt hat eine systemweit eindeutige Objektidentität, die sich während
seiner Lebenszeit nicht verändert.
Typ: Der Objekttyp, auch Klasse genannt, legt die Struktur und das Verhalten des Objekts
fest. Individuelle Objekte werden durch die Instanziierung eines Objekttyps erzeugt und
heißen Instanzen. Die Menge aller Objekte (Instanzen) eines Typs wird als (Typ-) Extension
(eng. extent) bezeichnet.
Wert bzw. Zustand: Ein Objekt hat zu jedem Zeitpunkt seiner Lebenszeit einen bestimmten
Zustand, auch Wert genannt, der sich aus der momentanen Ausprägung seiner Attribute
ergibt.
Basierend auf dieser Repräsentation führen die YAT-Muster (die eigentlichen
Übersetzungsprogramme) die eigentliche „Mediator-“ (Vermittler-)Rolle aus: Die in einen
gemeinsamen Speicher geladenen Objekte werden durch das YAT-Programm manipuliert.
Anschließend werden die neu erzeugten Objekten an einen Output-Wrapper gegeben, der die
gewünschten Ausgabeformen, wie z.B. eine relationale Tabelle oder ein HTML-Dokument erzeugt.
Deklarative Sprache
„Auto“-Objekt, eine Instanz eines „Auto“Musters, das vom „Fahrzeug“-Muster abgeleitet
wurde. Es stammt z.B. aus einem OODBMS
„Hersteller“-Objekt, z.B. aus einem XMLDokument
Hersteller
Auto
Standort
strBesitzer
strHersteller
Paris
Andreas
Citroen
Name
Citroen
„HTMLFahrzeug“Regel
Rumpf:
Fahrzeug (-> strHersteller -> Hersteller,
-> strBesitzer -> Besitzer)
Hersteller (-> Name -> Hname,
-> Standort -> Standort)
PLZ is PostleitzahlVon(Standort)
Hersteller = „Citroen“, Hersteller = Hname
Kopf:
HTMLFahrzeug( -> html -> head -> title -> Hersteller,
-> body -> h1 -> Besitzer
-> „Herkunft“
-> PLZ
-> Standort)
HtmlFahrzeug Objekt
HTML
HEAD
BODY
TITLE
H1
„Herkunft“ 78890 Paris
Andreas
Citroen AX
Abbildung 2: Ein beispielhaftes YAT-Programm
Die Sprache von YAT ist Regel-basiert, d.h. Ein YAT-Programm enthält einen Satz von Regeln,
die zu einer Veränderung von Daten führen, wenn die Regel auf ein Eingabeobjekt passt. Die
Veränderung besteht vor allem in der Restrukturierung der Eingabe, also in der Erzeugung von
neuen Objekten in der gewünschten Zielform. Diese muss übrigens nicht dem ODMG-Modell
entsprechen, sondern kann auch z.B. HTML sein.
YAT ist eine regelbasierte Sprache, bei der jede Regel aus Kopf und Rumpf besteht. Der Rumpf
enthält Muster und Prädikate, auf die ein Objekt passen muss, um bearbeitet zu werden. Externe
Funktionen (so genannte „Skolem-Funktionen“) können notwendige Zusatzwerte, z.B. die
Ermittlung der Postleitzahl zu einem Ort, berechnen. Der Kopf der Regel enthält Informationen,
wie die gefundenen Daten neu strukturiert werden müssen.
Im Verlauf des Konvertierungsprozesses werden als erstes über die Wrapper die zu verarbeitenden
Objekte beschafft. Danach werden die Eingabemuster mit den erwarteten Typen der YAT-Muster
verglichen. Falls mehrere Muster passen, wird das speziellste Muster ausgewählt und die
Verarbeitung gestartet, ansonsten geschieht nichts.
Jedes YAT-Modell kann in ein spezielleres Modell eingebaut werden. Das bedeutet zum Beispiel,
dass das vorliegende Programm eine Basis bieten könnte, um ein Programm zu schreiben, das aus
einer anderen Datenquelle spezielle Informationen zu Fahrzeugen des Herstellers Citroen beschafft.
Die Basisdaten werden dann mit der vorhandenen Regel HtmlFahrzeug ausgegeben, nur die
Anzeige der erweiterten Daten müsste implementiert werden. YAT-Programme können auf diese
Weise kombiniert (parallel ausgeführt) oder zusammengesetzt (sequentiell ausgeführt) werden.
YAT Modell
Ein YAT-Modell ist eine Sammlung von Mustern, die die ankommenden Daten und die Ergebnisse
der Konvertierung beschreiben.
Variablen werden in Großbuchstaben dargestellt. Es existieren Datenvariablen
Mustervariablen. Datenvariablen können grundsätzlich alle Datenkonstanten
Variablennamen enthalten.
und
und
Unter Datenkonstanten versteht man entweder die Symbole der Konstanten (z.B. Klasse, Name)
oder unteilbare Daten (z.B. „VW Golf“)
Der Wertebereich einer Mustervariablen ist die Gesamtheit aller Instanzen der Muster. So enthält
der Wertebereich des allgemeinsten Musters „YAT“ sowohl das speziellere „Fahrzeug“ wie auch
das noch speziellere „Auto“.
Ein Muster stellt eine Struktur dar. Es wird durch seinen Namen identifiziert und enthält eine
Menge von geordneten Bäumen. Die Knoten der Bäume sind Datenvariablen oder Konstanten, die
Blätter dürfen zusätzlich auch Mustervariablen oder Referenzen auf Mustervariablen sein.
Jede Verbindung enthält eine Angabe darüber, wie häufig sie bestehen kann. In YAT wird der Stern
(*) benutzt, um 0 oder mehr Verknüpfungen anzuzeigen. Fehlt er, so existiert genau eine
Verbindung.
Ein besonderer Baum, von dessen Wurzel nur ein Ast abgeht und diese Verbindung unmarkiert ist
(d.h. Es existiert genau eine Verbindung) wird „ground pattern“ genannt und kann nur von sich
selbst instanziiert werden. Es wird benutzt, um reale Daten darzustellen, z.B. in semistrukturierten
Datenmodellen.
Abbildung 3: Ein vollständiges YAT-Modell für Kunstwerke
Instanziierung
Jedes Muster des instanziierenden Modells muss eine Instanz eines übergeordneten Musters sein
(bis herauf zum YAT-Basismuster) und eine Variable kann entweder durch eine Konstante aus
ihrem Wertebereich, oder durch eine andere Variable, deren Wertebereich kleiner oder gleich ist,
instanziiert werden. Durch diese Regeln wird der Wertebereich, je öfter die Vererbung stattfindet,
immer kleiner und spezieller.
Im vorliegenden Beispiel ist „Auto“ eine Instanz des übergeordneten Musters „Fahrzeug“. YAT
kann sich daher darauf verlassen, dass die Knoten „strHersteller“ und „strBesitzer“ vorhanden sind.
Die Regel HtmlFahrzeug kann damit auch mit Objekten des Typs „Auto“ arbeiten.
Typisierung in YATL
Ein YAT-Programm nimmt ein Muster entgegen und gibt ein neues Muster heraus. Indem man sich
die verschiedenen Regeln anschaut, lässt sich eine Signatur zusammenstellen, deren Information
benutzt werden kann, um z.B. die Kombinierbarkeit von YAT-Programmen zu prüfen. Eine
Exception-Regel kann in ein YAT-Programm eingebaut werden, um ungültige oder unerwartete
Eingabeobjekte zu erkennen.
Architektur und Implementation
Der Prototyp des YATL Systems besteht aus einem Modul, um YAT-Programme zu bearbeiten,
einem Modul zur Typprüfung und Typvererbung und einem YATL-Interpreter. Zusätzlich können
Wrapper angebunden werden, die Objekte aus verschiedenen Datenquellen bereitstellen oder
zusätzliche Skolem-Funktionen berechnen können.
Für YAT steht eine grafische Oberfläche in Java zur Verfügung, mit der Muster (die eigentlichen
YAT-Programme) angelegt werden können.
Teil 2: Techniken zur effizienten XML-Integration
Einführung
XML wird zunehmend beliebter, wenn es darum geht, Anwendungen zur Datenintegration zu
schreiben. Die Gründe dafür sind unter anderem in der einfachen Umwandlung externer
Datenquellen in XML und zurück zu sehen. Leider sind XML-basierte Systeme noch in der
Effizienz gegenüber traditioneller Integrationssoftware unterlegen, da häufig große Datenmengen
bewegt werden müssen, bevor letztendlich eine Abfrage erfolgen kann.
Wenn es gelingen würde, die Eigenschaften und Fähigkeiten der Datenquellen auszunutzen,
könnten Abfragen effizienter ablaufen. In diesem Abschnitt werden häufige Probleme bei der
Optimierung von Abfragen über heterogene XML-Datenquellen beschrieben, und eine Lösung auf
Basis von YAT wird vorgestellt.
Probleme bei der Optimierung von XML-Abfragen
Einbinden von Typinformationen
Die Verwendung von Typinformationen erleichtert die Optimierung von Abfragen erheblich.
Leider sind Typinformationen für XML Dokumente noch nicht ausreichend verfügbar; DTDs bieten
nur eine schwache Typisierung gegenüber der Typenvielfalt moderner DBMS. XML-Schema oder
DCD versuchen, diese Situation zu verbessern, aber ein einheitlicher Standard steht zur Zeit nicht
zur Verfügung.
Einbinden von Abfragefähigkeiten der Quellen
Datenquellen im Internet exportieren selten komplette Datenbestände, sondern geben auf einzelne
Objekte über Abfragesprachen Auskunft. Wenn ein Computer die Abfragesprache „verstehen“
könnte, könnte er deren Eigenschaften zur Optimierung nutzen, um z.B. Einschränkungen der
Objekte direkt bei den Quellen ausführen zu lassen und damit die Masse an Daten, die bewegt
werden müssen, zu reduzieren.
XML Abfragen effizient auswerten
Es steht keine Algebra zur Verfügung, die die Eigenschaften der XML berücksichtigt. Außerdem
müssen Typinformationen ausgewertet und sehr heterogene Fähigkeiten der Abfragesprachen
ausgenutzt werden.
Lösungsvorschläge
Um die besprochenen Probleme zu lösen, wird als erstes eine Algebra für XML eingeführt.
Anschließend wird ein XML-Format zur Beschreibung der Fähigkeiten von Datenquellen
beschrieben. Basierend darauf werden Techniken zur Abfragebearbeitung besprochen und die
XML-Integration unter Anwendung von YAT demonstriert.
YAT Abfragen
Die Algebra wird auf der bereits besprochenen YATL aufbauen. Diese Sprache unterstützt
Operatoren, die in relationalen Datenbanken vorkommen, z.B. JOIN, SELECT, PROJECT, UNION
und INTERSECTION sowie Operationen aus Abfragesprachen für objektorientierte Datenbanken
wie MAP, GROUP, SORT und D-JOIN (dependency join). Zusätzlich werden noch zwei neue
Operatoren eingeführt, die für die Bearbeitung von XML-Daten besonders wichtig sind: BIND und
TREE.
BIND
BIND hat die Aufgabe, aus Eingabeobjekten die gewünschten Informationen zu kopieren und eine
Struktur aufzubauen, die „Tab“ genannt wird. In einem Tab sind die Werte der Datenkonstanten
unteilbar (1. Normalform). Der BIND-Operation kann ein Filter mitgegeben werden, der die zu
selektierenden Attribute festlegt. Es ist auch möglich, mit den nicht ausgewählten Attributen einen
Unterbaum aufbauen zu lassen, um so z.B. mit semistrukturierten Daten umgehen zu können.
Gegeben sei beispielsweise eine XML-Datei mit künstlerischen Werken der folgenden Form:
<work>
</work>
<artist>Claude Monet</artist>
<title>Nympeas</title>
<style>Impressionist</style>
<size>21x61</size>
<cplace>Giverny</cplace>
... (weitere Datensätze)
Dann liefert ein Aufruf von BIND ( $title: $t, $artist: $a, more: $fields) einen Objektbaum der
folgenden Art:
a
Claude
Monet
t
Nympheas
fields
style
size
cplace
Impressio- 21 x 61 Giverny
nist
Abbildung 4: Die durch BIND erzeugte Tab-Struktur
TREE
TREE bildet in der Regel den Abschluss einer Abfrage. Die Operation gibt eine Sammlung von
Bäumen zurück, die einem gegebenen Muster entsprechen. Dabei können die Daten neu gruppiert
werden, um z.B. alle Kunstwerke eines Autors unter einem Baum zu sammeln.
Umsetzung von Abfragen in Ausführungspläne
Die YAT-Regeln wurden bisher grafisch notiert, ohne dass die Namen der Operationen wie BIND,
TREE, SELECT etc. verwendet wurden. Diese Umsetzung erledigt der Abfrageprozessor nach
folgendem Schema:
1. Die Abfrage operiert auf allen Objekten, die durch die Wrapper importiert werden.
2. Jede Regel aus dem Rumpf passt auf einen oder mehrere Objekttypen. In dem Beispiel aus
Abbildung 2 sind dies „Fahrzeug“-Objekte (oder instanziierte) und „Hersteller“-Objekte. Diese
Anforderungen werden in BIND-Operationen umgesetzt.
3. Die Verbindungen zwischen den Objekten werden mit einer JOIN-Operation hergestellt. Im
Beispiel wäre dies die Verbindung Hersteller = HName.
4. Andere Einschränkungen werden in SELECT-Operationen umgewandelt.
5. Der Kopf der Regel, der die neu erzeugten Objekte und deren Gruppierung (in unserem Beispiel:
Die HtmlFahrzeug Objekte) herstellt, wird in eine TREE-Operation übersetzt.
Einbinden von Abfragefähigkeiten der Quellen
Nachdem nun eine Algebra für XML zur Verfügung steht, die der tiefen Verschachtelung und der
Eigenschaft von XML-Dokumenten, semistrukturiert sein zu können, gerecht wird, wird nun das
Verfahren betrachtet, mit dem der Abfrageoptimierer sich über die Fähigkeiten der Datenquellen
informieren kann. Dies ist wichtig, weil die Information über die Fähigkeiten die Möglichkeit
eröffnen, Teile der Abfrage zu den Datenquellen hin zu verschieben, und damit die Menge der zu
übertragenden Daten wesentlich zu reduzieren.
Beispielsweise kann eine Datenquelle die Möglichkeit haben, die übertragenen Daten nach Teilen
des Namens einzuschränken. Würde der Abfrageoptimierer davon nichts wissen, müsste er, um die
SELECT-Operation bearbeiten zu können, alle Daten der Quelle laden. Weiß er aber, dass die
Einschränkung nach Teilen des Namens schon bei der Quelle durchgeführt werden kann, so lässt
sich die Anzahl der übertragenen Entitäten reduzieren.
Die Spezifikation der Abfragefähigkeiten muss in einer Weise erfolgen, die sowohl mächtigen
Abfragesprachen wie SQL, aber auch einfachen Interfaces wie WAIS („Wide Area Information
Server“) gerecht werden. Auf die beschränkten Fähigkeiten von WAIS wird im folgenden noch
eingegangen.
Exportieren der Abfragefähigkeiten zum Mediator
Der Export der Abfragefähigkeiten von den Wrappern zum Mediator läuft in zwei Schritten ab. Als
erstes wird eine Signatur erstellt, und danach wird der Mediator über die Semantiken der
Operationen informiert.
Signaturen
Eine Signatur enthält den Namen einer Methode zusammen mit ihren Ein- und Ausgabeparametern.
Beispielsweise kann ein System eine Möglichkeit bieten, den aktuellen Preis eines Kunstwerks zu
ermitteln:
<operation name=“external“>
<operation name=“current_price“>
<input>
<value model=“Work_Schema“ pattern=“Work“/>
</input>
<output>
<leaf label=Float />
</output>
</operation>
</operation>
Diese Operation erhält als Eingabeparameter ein Kunstwerk und gibt den aktuellen Wert als
Gleitkommazahl (Float) zurück.
Semantiken
Durch die Angabe der Signaturen ist noch nicht viel erreicht. Der Mediator kennt jetzt zwar die
Signaturen der Operationen, weiß aber nicht, wie er diese Methoden zur Optimierung der Abfragen
nutzen kann. Dies muss durch Angabe von Semantiken erreicht werden.
Eine WAIS-Datenquelle hat beispielsweise die Fähigkeit, den Namen eines Kunstwerks nach einem
Teilstring zu durchsuchen. Die dazugehörige Operation sei in der Signatur unter dem Namen
„contains“ definiert. Nun wird ausgedrückt, dass die beiden Operationen
•
„Führe eine Teilstringsuche im WAIS Datenbestand aus“ und
•
„Lade alle Namen der Kunstwerke und suche innerhalb des Mediators“
gleichwertig sind:
Select($x=$y, Select(contains($w, $y), Bind(works, works*work($w),
[F($x)]))) =
Select($x=$y, Bind(works, works*work[F($x)]))
F($x) ist hier ein beliebiger Filter über die Variable x.
Ausnutzen der Abfragefähigkeiten zur Optimierung
Nun stehen eine Algebra für XML und eine Form, die die Fähigkeiten der Datenquellen beschreibt,
zur Verfügung. Dies soll nun ausgenutzt werden, um Abfragen zu Optimieren. Das Ziel ist dabei,
die Abfragen sowohl lokal zu optimieren, indem die Ausführungspläne verändert werden, als auch
die Abfragen soweit wie möglich zu den Datenquellen zu verschieben, um die Menge an
übertragenen Daten zu reduzieren.
Da die vorgestellte XML-Algebra eine Erweiterung einer objektorientierten Algebra ist, können die
dafür bekannten Optimierungen sofort angewendet werden. Deshalb werden nur
Optimierungstechniken für die neuen BIND und TREE Operationen behandelt.
Verarbeitung von XML und Veränderung der BIND-Klauseln
Die BIND Operation ist eine „teure“ Operation. Das Ziel ist daher, die BIND-Operationen so zu
verändern, dass die behandelten Bäume möglichst flach bleiben. Bei einfachen BIND-Operationen
ist die Wahrscheinlichkeit, dass sie sich zu den Datenquellen verschieben lassen, höher.
Bei der folgenden BIND-Operation (linke Seite) werden ausgegrabene Artefakte gebunden.
Außerdem werden Informationen über Ihre Besitzer geholt. Dies kostet viel Zeit. In einem ersten
Schritt wird diese Operation in zwei BINDs aufgeteilt, einen für die Artefakte und einen anderen
für jeden Besitzer. Danach werden beide Objektmengen über DJOIN verknüpft (mittlere Seite).
Eine derartige Veränderung ist bei jedem BIND möglich.
DJOIN kann optimiert werden, indem der rechte BIND so verändert wird, dass er nicht mehr viele
Objekte vom Typ Person erzeugt, sondern eine Sammlung, die Objekte vom Typ Person enthält.
Der Vorteil ist, dass nun ein JOIN zwischen zwei Klassen gleichen Typs durchgeführt werden kann
(rechte Seite). JOIN-Operationen sind grundsätzlich schneller als DJOIN-Operationen.
Abbildung 5: Optimierung einer komplizierten BIND-Operation
Neuschreiben auf Basis der Abfragefähigkeiten der Quellen
Die folgende Abfrage befasst sich damit, alle Kunstwerke von Impressionisten zu finden, die für
weniger als 200000 Franc verkauft wurden. Ausgangsbasis ist eine gemeinsame Struktur
„artworks“, deren Felder aus zwei Datenquellen gewonnen wurden:
•
title, artist, year, price, und owners stammen aus einer objektorientierten Datenbank, die OQL
(die objektorientierte Variante von SQL) versteht
•
style, size und „more“ stammen aus der WAIS Datenbank, deren Signatur und Semantik bereits
vorgestellt wurden.
Abbildung 6: Ausführungsplan für das "artworks" Muster
Problematisch ist nun, dass zuerst alle „artworks“ geholt werden müssen, obwohl nur diejenigen
benötigt werden, die für weniger als 200.000 Francs verkauft werden. Um diese Abfrage effizienter
ausführen zu können, können folgende Eigenschaften der Datenquellen genutzt werden:
•
WAIS kann die Suche auf alle Werke einschränken, die impressionistisch sind (Operation
contains)
•
Die artifacts-Datenbank versteht OQL und kann die Einschränkung auf 200.000 als maximalen
Preis ausführen.
Die optimierte Abfrage sieht nun so aus:
Abbildung 7: Optimierung der artworks-Abfrage
Man sieht nun, dass einfachere BINDs sich besser zur Optimierung nutzen lassen.
Diskussion
Das vorgestellte System aus der Abfragesprache YATL und dem System, dass die Fähigkeiten der
Datenquellen beschreibt, ermöglicht es, XML-Daten durch Vererbung sinnvoll zu typisieren und
XML-Abfragen über mehrere Datenquellen zu optimieren.
Der Vorteil der YATL liegt darin, das Abfragen nicht nur auf Objekten operieren können, die einen
bestimmten Typ haben, sondern auch mit Subtypen arbeiten können. Der Ansatz, YATL
Programme durch eine grafische Oberfläche „zusammenklicken“ zu können, ist intuitiv.
Nachteilig ist sicherlich, dass für jede Datenquelle ein besonderer Wrapper geschrieben werden
muss. Er wäre hilfreich, wenn z.B. ein Werkzeug existierten würde, dass aus einer XML Schema
Definition einen Wrapper herstellt, ohne dass extra programmiert werden muss. Einige Funktionen,
die z.B. aus SQL gut bekannt sind, wie z.B. die COUNT() Funktion, müssen durch Skolem
Funktionen neu geschrieben werden.
Die Ansätze zur Optimierung von XML Abfragen gehen in die richtige Richtung. Sie reduzieren
vor allem die Datenmenge, die zwischen den Datenquellen und dem Mediator bewegt werden muss,
und sie schont dort Hauptspeicherverbrauch und CPU, da der Mediator von der zeitaufwendigen
Bearbeitung vor allem von SELECT-Operationen, entlastet wird.
Nachteilig ist, dass trotzdem weiterhin bestimmte Operationen, wie z.B. JOINs über mehrere
Quellen, sehr aufwendig sind, weil die Objekte der rechten Seite entweder immer noch übertragen
werden müssen, oder für die rechte Seite des JOINs einzelne Abfragen geschickt werden müssen.
Es wäre sinnvoll, wenn auch diese Art der Abfragen sinnvoll optimiert werden könnte.
Literaturliste
[1] „On Wrapping Query Languages and Efficient XML Integration“, Christophides, Cluet, Siméon
[2] „Your Mediators Need Data Conversion!“, Cluet, Delobel, Siméon, Smaga
Abbildungsverzeichnis
Abbildung 1: YAT verändert den Aufbau von Strukturen aus mehreren Quellen
Abbildung 2: Ein beispielhaftes YAT-Programm 5
Abbildung 3: Ein vollständiges YAT-Modell für Kunstwerke
7
Abbildung 4: Die durch BIND erzeugte Tab-Struktur
9
Abbildung 5: Optimierung einer komplizierten BIND-Operation 12
Abbildung 6: Ausführungsplan für das "artworks" Muster
13
Abbildung 7: Optimierung der artworks-Abfrage 14
3
!
"
!"
#
% &
) *
$
"
'(
+
"
,% -. / 0 )
%
)
0
#
&
$
"
'(
:
;
")
0 )
7
5
)
"
0
<
" ))
?
$<=% / ,%
,% -.
"
: > )
2
"
7
"0
2
<$0
&
7
7
2
"
@
A
0
7
5
)
% "
B
"
7
0A
"
" 9!
<
;
<
C
6
'
'
))
<
":
D?
7
7
77
(
(
E9!
? !
9 F
0)
! :
9)
F
"
5
5
5
)
)
9
" ;
7
7
5
-
9
G
,% - 2 : )
% " ))
7
!)
:
6
'
5
9
5
,% -.
5
.
) * 12
2
))
"
34
4 5 6
*57
898
,% -. / 0 )
%
9!! )"
9!! )"
9!! )"
9!! )"
9!! )"
*
"
*
"
7* D2
5* % " ))
=
=
=
=
=
=
=
=
=
=
=
2
2
2
2
2
2
2
2
2
2
2
)
)
)
)
)
)
)
)
)
)
)
*
*
7*
5*
*
6*
'*
(*
*
.
.
.
.
.
.
.
.
.
*.
*.
@
@
@
@
@
@
@
@
@
,% -.
A
6
6
'
(
)
"
D
;!
;!
@D
@
"
'(
7
5
6
2 )
)
) 0A
$
:
2
2
H"
<$$0 I J
,% : ))
=
#
&
K E
":
,% -#
"" 0
! )
) A !) ,% -#
2
) ,% -#
)
9 " ;
K E
9
"
!
!
7
5
L!
L!
L!
L!
) * 12
*=
*=
7* =
"
34
2 )"
2 )"
2 )"
4 5 6
D
D
D
"
! )
! H
)) M M
*57
H
! H
8=8
,% -.
#
&
%
$
"
'(
")
0 )
<
:
!
"
"
" "
O
O
"
"
) %
:"
))
#"! "
9
?
,%
)
!
?
,% &
F "
"
B
%
>
"
$<=% / ,%
F " ;!
E <=%
:)
-
D)
!
7
0
0
F
"
""
"
" : ))
!
"
!: )
I
!
5
D
) * 12
"
))
)
<
:
2 ) F
E/
J
2 :
E
"0
% "") F
))
" B )
7
0 F "
<
" <
2) :
F
))
<
"
:
"
; ! ) !
!
))
"
! -
))
J; "
!
4
"
!
: ))
)
2
-#
* 0
T
=
!
; " P
")
J
)
)
< ))
:
2
2 )
,% -. -0
"
: )
22
"N "
)
!
F "
"
F
"
4:
"
2) A
P
#!
: > )
4F )
/
4F )
. ))
"" 0
!
;!
))
=
!
" "
5
=
" "
= ;
!
))
"
!
! "4:
"
) A !)
<#< / ) D<
E/ "
)
> )
% " ))
?
)
> )
<
)! F "
,% -<
; ,% -<
4 ) ! " 4,% -<
: ;
4
:
% P !)
D0
" E
)
D
J;
F "
4
"
" 4F )
,% -<
!
F "
) ,%
)@
:)
F
I0< Q
2
)
,% -.
F
,% -.
9!
2)
" )
<
;
)
:
"
7
)! !
A2) :
<
"
"
<
F
0
9
R
,% -.
) 2
!
4:
,% -
!)
I )
)
% " ))J " $ )
# ! )) I: ) J " O
)
"
"
);
)
F
)!
I: )
D& ))E- )" J
"
)
! )
!
)
2
2 " 4
I" F
;:
!
)
,% -<
"
)!
"
$
F
) #
"
" "
)
/
"
4 )
")
:
4"
:
)
" :
<
$<=%
$
I"
F 2
" #
)) "
) P
"
#
9
:
" F
)
F "
4
"
)
!
= -
:
:
F "
: F "
>
4
2 :
B F ,
" ,
/
4F )
" = A
!
D
E
O 7S
)
!
" ; "
9 :2
:
U
T'U
2*NNFFF F7
"
34
NS
4 5 6
N
*57
8 N '8
,% -.
#
&
%
$
"
'(
5
,% -.
" :
<
2
@
)
"
A
F )
F "
/ )
?
; : ,% -?
0 > )
":
"
9
P
!
F
?
"
;:
#9 -9
)
D
!
E
@
,% -<
"9
;:
F
"
;
)@
W
2
-%
,% -<
A
%
!
"
N )
"
#9
)
-
"R
)
4
22
4 -
"
2) A ,% -
; "
$
4
?
*
V.
)
)
&
F
<$0
)
!
#
4
)
" <#<J
J
" ))
?
B
: )
"
9!! )"
)F
2
" 9
)
)@
"
"
2
0 -
Q I 40J
R
0
R
9
! -O
0)
! "
,% -.
"
&
4"
= :
J
'(
!
!! IG <J
" 2
):
"
"
X S<9#9-
) ! )
,% -<
2
R
40)
"
R
40)
)
-
=)
!
I
%
-0)
I#9 -&
4
"
"
$
! :
-
)) =)
!
! "
F
"
9
2
" 9
*
Q
6
!
J
2
F
!
)
)
2
<
<
O
# A
<
!
<
!
''!
B
:)
)
"
:F
"
6
)
)
:
A
G< F
) * 12
T
:F
U
; !
)
%
&
*
% " ))*
R
!
>
@2
R
)) "
G2
!
= :
!
"
"
34
4 5 6
*57
8 N '8
,% -.
R
<
!
)
:
$
G "
0
)
=)
)
"
0)
)
F "!
= :
"
)
"
"
#
&
%
!
%
! )"
"
-N )
-
$
"
'(
)
)
! ;
-
2
"
-!
F
"
!
; " 9 )@
"9 !
" <
,% 2
4 ! )"
.
@
)
))4"
"
D ))!
E
)
)
"
,% -.
" A
)
G "
;: "
IR 2 )
!)
"
,% =
J
;
" F "
IJ
!
!
T U
T U
T U
IJ
I
Q
6
I'J
I J
J
)T U
:
U IJ
2
<
"
0)
) %> )
9 ;
7
"
@-G2
" .
F "
&
B
9 )
"
I J
<
# A
!
I 7J
<
:
F "
+
" -<
4F
%
)
&
,
"
!
P
F
<
! 4 )
:F
:
)
))
!
"
);
)
)
:
<$0
"
" "
<
$<=% -R : 2
0 0)
F
);
) ) $
; : ,%
R :2
!
)
: - ./ !:F - ./
!
"
"
0)
"
"
#@2 !
"
(
2 )*
1Y9##
#!
1Y9##
#
!
))
;
E
<
%
) * 12
"
R
$
"
<
" < X$0.? $0<3
!
<$0
X$0.? $0<3
>
!
R
,% -.
K : "
!
(
<
I J
!
''!
'
IJ
O
<
=
I(J
T U
T
I6J
T U
I5J
T U
I7J
)
T U
U
T7
)
)T
U
F
T
!
A
U
2
:
"
;: "
))4"
)
"
#9
.
9
12
<
)
" "
D
-
F "
:
F
!
,% )
2
2
)
3
4
" <#< !
F " 9 P "
"1 F 3F
"
&
I<#<J4
) :- !:F <
))
"
0
<" G<"
; "
4"
&
)
: !
"
34
"
4 5 6
#
#
*57
! !!
0
;
"
!
2 ) F
T
U
8 7N ' 8
,% -.
0
#
&
%
: )
&
1
4F
,% -
31!
"
31
2
I ""
.
))"
)
*
$
"
'(
J)
3
,% -<
)) !
!
!
!
Q
6
J
!
2
)
:
F
!
A
)
)
2
<
<
O
# A
<
!
<
!
''!
) * 12
)
I
"
34
4 5 6
0 1& !
*57
! 2
- ../
"
8 5N ' 8
,% -.
#
&
%
$
"
'(
! "
"
@
A
,% -.
@
"
?
W " 9!
)
9 !
4"
;
)) : ,%
"
9 )
-
. -NG. -9!
F
: 2 ))J"
<
I2
"
2
) $
*
4
= ;
-
! "
O 0$0
&
SG& #$?S# S
< !
!)
:
"
"
. ))"
:
! "
F "
<
F "
>
3
F "
0 F " )
!)
)
4"
; #
:)
D#
)) W " DR
E
2
"
)
9!
0
) -R)
)
F )
)
"S
" ;!)
F
F
))"
;
. -!
R)
)
.
9) 9
F
!
<
" !
"
" O
,% -. -0
1,% 3
:) )
"
2
0)
-O
9
0)
!
3Z 1N
)) .
)
IT
"
9
<
"
"
,% -.
1N3 !
!
))
)
;:
"
@
; : F "
";
9 "
F
I )
7 7J @
" 0!
"
)
!
9!
)
) * 12
-#9
F
4
: "
)
!
)
) : )
!)
1N)
)QZ
"
>
A3
3 1N" 2)
!
3
:
; "
"
UJ
F
0 )
2 )
=
D5
=
2 )"
"
"
2
)
"
!
E:
;
)))
E
5
F
* ,% -. -9!
>
2
Y& ; )
1N3 : 2
"
34
4 5 6
4 )
"@
O
"
)
4"
7
4"
)
"
9
,% -0
) P " 0)
" ;
;!
: ! "
! :
0)
9
!
-
7
= :
D,% -S
<
B 0
2 :
)
4F !
:
0A
7
)
3
Z "
F
0
)
!
S
I#9 J* 1Z 3
< ! ! :
,% -<
Z
))
A 3Z! :
IXS<9#9J* 1" 2)
IG <J* 1
" F "
"
G
"
R
F "
!
IX S<9#9J* 1)
! "
F "
F "
9 )
)
9
"
,% -
-O
R
F " "
" %
#
4 F )
)
$!
!S
:
"N " F
)
!)
IA 4 4A J ;!
"
E! )
"
R
) S :
D#
E <
!
! ))
"
4 )
I2
)J "
&,% -#9
N? !
:
"
4"
O
:)F "
<
T
,% -<
!
))
*57
F
4"
F "
F "
U
"T
U
" ;
,% -
"
"
: ": ! ;
"
-
)! " ,% " 9!-
8 N '8
,% -.
)
"
F "
31!
F
1
#
&
%
=
2 ) F "
!
<
31
3
"
$
X S<9#9
&
"
!)
%% & ! %'( )
;!
Z)
" Z
<$0 F "
*
)+
! "
R 2 )
T 9!
O
1[A )
1,% <QH
1
1)
! 3
3
1)
1
1!
1N3
1N3
H
" "
7
"
!
A 3Z)1N3
3
1N3
31
3Z 1N31N3
QH
1
"
N" F )
"N
N
!
A )H
!
3<
1N!
3
3
A3
2
<
!
3# A1N!
3
1)
3
A 3Z)1N3
3Z 31N3
1)
1!
2 )-
1!
1N
1N,% 3
!
U
H[3
"M H3
3
A3
2
<
1!
1N
1
2*NNFFF
"
'(
,-
T ,% -. U
1
1
$
1N)
3
A3
1N)
3
A3
1N3
4 !&! )
))
: !
"
"
)
4"
0)
))
1)
,% -.
!
-
0)
"
A 3 F; "
"
)
!
5
$!
%
)"
"
"
"
2
:F
O
;
"
!)
2 ; )
<
! IT UJ!:F
"
D ))
) 2) :
4" 9
! ;!
7
!
!
E<
2
)
"
,% R 6
"
! )
)
=
!) !
"
IT 7 UJ4"
0
9
2 ;
*"
. /
*
"
9!
)
%
)
22
,% "
)
:
T ) T 7 UR 2
UY
)
2
F ") -
" 9!
"
!
*0
$0
2 )
>
!!
))
4
%%
"
22
)
"
"
1
!)
#2
%
=
!
F
:
( )
KF )
*
1[A )
1,% <QH
1
1)
! 3
3
1)
A 3Z)1N3
1
!
3
1N3
1N3 0 0% 0&#M9 Z
1N3
H 2*NNFFF
" N" F ) "N
1
QH
<
1!
1!
N
!
A )H
1N
1N,% 3
-
)T 9!
O
R
2
T ,% -. U
1
1
/
-
<
9 !
#
!
U
H[3
"M H3
3
A3
2
!
3<
1N!
3# A1N!
3
1N)
3
3
A3
3
A 3Z)1N3
1)
3
2
4
*54
54
56 475475475
6
"
") *
4
56 475
8
1N3
4 !&! +
) * 12
"
34
4 5 6
*57
/5
$!
#!
$
8 6N ' 8
,% -.
%
"
);
)F
5
!) : ! "
R)
)
:
<
:F
B
/ / /678
":
:)
A
<
O 0$0-SG& #$?S#
" 9 F
!) Z ! :
"
9)
:F
%> )
D
4
"
!
)
;!
:
"
)
;
.
!
)
"
4 0)
@-=)
)) "
!
"
))
9!
""
)
E
:
4
"
)
""
<
&! "
R 2
@-
.
)
5
"
! " 0)
))
!
9
$
;
)! <
:F
)) )
C
"
: 0)
;2
4 )
#
"
O
"
!!
%%
*
#2
%
9
$!
;2
F DK E-
-
T ,% -. U
T 9!
F
1[A )
QH
H[3
1,% <QH
"M H3
1!
3
1
3<
!1N
1
3?
1N!
3
1!
3
1
3<
1N
3
1
3
2
<
!
1N!
3
1!
3
1
3# A1N
3
1
3
2
<
!
1N!
3
1N,% 3
! 3
<QZ!3
3Z 1N3
1
1N3
1N3
H
:
!)
*
$0
1
1!
2*NNFFF
1!
"
N" F )
"N
N
!
A )H
3
1
3
2
"
'(
)
2
"
$
<
))
F
"
22
4K "
% "
4
! "
F "
F ""
C ))
F "" =
:F
O 0$0-SG& #$?S#
"
F "
5
=
"
#
&
%
3Z 1N3
4
4
*
*
4%
)5
:6 5
; 56 475
475
475
< ! 772 2 2 =)) =
""7 )2 %)
") * "
4
*56 475
8
7
7
*
!
U
3
1N
1N
3
1N
3
3
)=
; %<
1N3
4 !&! 0
&
F ""
=
:
F4
0
<
:
5
<
<
>
) * 12
))
) R
"
;
"
C
"
,% -. -0
"
4
#
G2
))
"
F
) !
"
34
2)
.
"
#
!!$ !
E9
";
* 9
);
T7U
2
)
)F
"T
: )"
" 0 :
@2
9 F
))
<
"
%> )
: "
D
$
"
B
"
3
4
3
,% -.
>))
B
9
? 2
#!
C
))
"4 ! "
I
!
!)
)-
))
*>
,% -<
*"
?
"
SG&#0&#M9 :
U F
,% -. -0
2
"
";
!
: ;
4F "
!
A2) :
F
;
22
W
"
;!
"
)! < -
*"
"
"
)
9
.
!
-
@-=)>
-
4 5 6
*57
8 'N ' 8
,% -.
"
4: =
"
)
-G2
9
4
4
J4
"
D
*
%
E
-K
T 9!
F
1
1
! 772 2 2 =)) =
""7 )2 %)
3
1
\
F
7
7
*
)=
; %<
3Z)1N3
1
1
"
1
1
1N3
1N3
<
1
! )
3
3
3Z 1N3
3Z 1N3
! 772 2 2 =)) =
""7 )2 %)
7*
"
!
U
1[A )
QH
H[3
1,% <QH
"M H3
1
3
1
3?
1N
3
1
"
3#
$ "1N "
3
1
"
3< @ <
1N "
3
1N
3
1
3
1
3
2
<
!
1N
3
1
"
3#
$ "1N "
3
1
"
3
:%
1N
"
3
1N
3
1N,% 3
! 3
QZ 3
A 3Z)1N3
1)
"
'(
*%* -
T ,% -. U
1N3
1N3
<
$
!)
$
1
#
&
%
7
%
=
; %<
3Z 1N3
]
1N3
4 !&! 9
0
> )
" # ) "
R
"
! F "
4"
O 0$0-
!)
: 2
#
$!
$
"
1!
(!:
"
6
! :; )
)
"
1
?
"
9!
D
0
!
: :
! :
F "
"
3-0)
E
"
"! 4F
<
":
=
"
9
)
F
<
!
)
0)
"
? B
!) ! "
)
9! )
"
4F
)
G "
"
(
9!! )"
!
:
)
D
)
:
)
4
" )) I )
J
)@
" ,% -
<
" :
4"
"
F
,% -
"
4"
2 E
%% 0)
::
F " 4
" $
! :
9
;!
" K
)
"
'
; : ,% -. :
:)
F " $ )
F " "
D
) ! EF "
:
$ #9 4
" :
<G% -0!
9
*
"
4"
"
"
:
)
7
'
(
F
<
#9
)
!)
< B )F
0
:!
F "
6
:
"
<
<
F
:
)
0
:
:
"
N
))
)"
F "
F ""
)
) * 12
"
T
U4T 7 U
C )) T U " T 7 U4 "
4F
) " :
"
,% -. -0
IT
UJ " A
!
4F
2)
"
"
":
34
" T 5 U"
"
P
"
!)
*57
; ,% -.
2)
@
;!
2 : : 4 !
"F
" : I
J
"
,% -<
"
D2
:
4 5 6
))
!)
F
)
9
9)
B "
<
! "
;: " >
))
)
2
F
-
) #9 4 )
)
EI )
9
))
7J
!
2
"
D : ) EF "
> ,% -. -0
= 2 )"
-
8 (N ' 8
,% -.
%
$0
!!
1
?
*! *)
#2
%
( )
*
T ,% -. U
$
1[A )
1,% <QH
1
1)
! 3
3
1)
A 3Z)1N3
1
!
3
1N3
1N3 0 0% 0&#M9 Z
1N3
H 2*NNFFF
" N" F ) "N
1
QH
<
1!
1
N
!
A )H
1N
1N,% 3
"
'(
)T 9!
O
1
1
#
&
!
U
H[3
"M H3
3
A3
2
!
3<
1N!
3# A1N
3
1N)
3
A3
3
3
A 3Z)1N3
1)
\
F
1
31!
TZ U31
3Z 1N31N31N3
Z
3
2
8
3
2
8
6 : ") *
" 4
6 5 ") *
" 4@
56 475
56 475
]
1N3
4 !&! ;
4"
) ) 9!
" :2
!)
DZ E
) * 12
> )
"
34
# ! - !!
" .
@-=)
;!
" < 0
!
"
"
,G$)
4 5 6
*57
7
0!
=)>
"
)
!'
) F "
F "
4"
! :; )
"
"2
)F " " A
-
8 N '8
,% -.
"
!
#
&
%
!
&
<
4"
9
$
!
)
"
'(
:
)
B "
BF
"
"
"
"
"
O 0$0-SG& #$?S#
!)
)
:
"
$2
==
"
);
)F
F "
*)
"
G$<0$0<-=^
))
>
*
. "
: F "
!)
-
T ,% -. U
T 9!
O
1
1
1[A )
1,% <QH
1
1)
! 3
3
1)
A 3Z)1N3
1
!
3
1N3
1N3 0 0% 0&#M9 Z
1N3
H 2*NNFFF
" N" F ) "N
> 6%
)
1
QH
<
!
A )H
!
U
H[3
"M H3
3
A3
2
!
3<
1N!
3# A1N
3
1!
1
N
4
1N
1N,% 3
1N)
3
A3
3
3
; 56%475
4%
\
F
1
31!
TZ U31
3Z 1N31N31N3
Z
\
F
]
\
F
]
ZQ
1!
Z3
1
3Z 1N3
3Z 1N3
]
1N3
4 !&! *
7
D?
E9!
7
? !
0)
<
"
)@
4"
P
)
<
)
)
:
4K"
F
) "
<G% -0!
"* 1
3
!
F
! "
)2
";
)
B
: <0 S0&< &
"
) * 12
)
"
: 4" "
"
34
/
4 5 6
"
" K
"1
0)
!
9) 9 F
!
,% -. " % > )
"
D&E-BF
" O 0$0-SG& #$?S#
= )
" #9 ) P
F " 4K "
!
) D
E
<
!
' !!
! :
.
)
9
#!
)
!
)*
F "
4F )
K"
)
;!
4
!)
2
D
-K
EI )
" 0)
& ! ! "
):
F "
" 9
R
-
"
:
>
0
F
<
)
5 JF
:F
> -
)
! :
: F
"
> )
*57
&
!
"
4F "
!
#9
3
;
:
"
!
K"
)) !
! )"
)!
0)
"
<
"
-
)
" ;
F "
)
F
>
8
N '8
,% -.
$*)
*( )
)
.
/
1
$
T 9!
O
1
1Z 3
1[A )
1,% <QH
1
1)
! 3
1)
A 3Z)1N3
1
!
3
1N3
1N3 0 0% 0&#M9 Z
1N3
H 2*NNFFF
" N" F ) "N
6
3
*+*
8
"
"-!@ Z)
N
A )H4
1N
1N,% 3
!
U
H[3
"M H3
)
)
A3
3
2
<
1 @23
1!
1
1N
1
% @
* %
3
1)
A 3Z)1N3
1 @236 475
\
F
46 51!
TZ U31
Z
\
F
]
\
F
]
!
QH
"
'(
-
T ,% -. U
1
#
&
%
!
1N)
1N @23
3<
1N!
3
3# A1N
3
)
)
3
)
)
3
1)
A 3,%
"<
!
1 @23
1N @23
1!
3# A1N!
3
)
)
3
A3
1N)
A3
3Z 1N31N31N3
ZQ
1!
Z3
1
3Z 1N3
3Z 1N3
]
1N3
4 !&! ,
7
9
"
F
F
<'
5!'
7
9)
;
"
;
;!
? F
!)
! "
"# )
% "
"
< ,% -.
""
)
!
=
2 )
F
" "
)) 4"
#9
2
)
"
)
F " 4 "
"
2
) 9!
"
F " " 9
!
: ;
"
:!
F " 0
"
":
-# 0&-0 0-
F
" !
"
; :4
%> )
"
!)
2
"
:F
9
D
"
"
"
O 0$0#9
,% -
" @)
F -
E
"
))
-
)) )
.
@-=)>
2
)) )
.
@-=)>
:
-
7
)
)
7
0 F "
:!
2
)) ) 9! !
) * 12
"
! 4
F ""
34
"
" 22 )
4 5 6
:
9
*57
"
!
" K
"
& !
)
! "
.
@-=)>
)
F "
>
<
)
8
N '8
,% -.
$2
=
A=
1 . B * .
)
)
+2
@)
T 9!
O
1
1Z 3
$
1[A )
1,% <QH
1
1)
! 3
1)
A 3Z)1N3
1
!
3
1N3
1N3 0 0% 0&#M9 Z
1N3
H 2*NNFFF
" N" F ) "N
Z
\
4
]
"
"-!@ Z)
!
ZQ
1!
Z3
1
!
)
)
A3
3
2
1N)
A3
!
)
:
!
)
Y O
IA% - J
G
6
- '
1N
F 3
1!
3<
1N!
3
1
3# A1N
3
)
)
3
)
)
3
1)
A 3,%
"<
!
1N)
1 @23
1N @23
1
F 3<
! !
)
:
)
Y
G
( 66
1N
F 3
1!
3# A1N!
3
)
)
3
1N
1
1N
1N,% 3
U
H[3
"M H3
A )H4
)
)
3
1)
A 3Z)1N3
1 @23Z 1N3
3
2
46 54!
* .@
* %
56!475475
6
") * "
4
2 *5
**
)
%
C * .@
* %
D6!475
8
\
F
1Z 31!
TZ U31
3Z 1N31N31N3
Z
\
F
]
\
F
]
QH
<
!
1 @23
1N @23
1
F 3<
N
"
'(
-
T ,% -. U
1
#
&
%
A3
3Z 1N3
3Z 1N3
]
1N3
4 !&! =
77
F
,% -. !
!
:
#9
: "
2) A
)
"
)
%> )
9 F
4
"
1 A2
A2
3
A2 `
31 A2
R)
-
A2 a
0
) * 12
"
))
A2 )
) : )
-
"
"
: ;
!
-
)
&
"
5&
!
!)
4"
)
"
:
G2
4
5
4 >
Z` "
"
O "
)
O "
! ) !
`
R !
" !!
34
2 )
!
:
4 5 6
"
A2 -#9
#9
"
3
D;!)
"
4
"
F "
)
= :
;
,% -
)
A2 -#9
G2
=
"
" ;
)
" ;
3
4 )
IJ
5
" ;
!
1 A2
O
"
* <
F
9
7
= "
_!
::F
:
9
)
&!
9
)
2
"
)
G2
0
<'
!
"
4F
E
)
"
2
)
#9
" -
T5U
*57
8
N '8
,% -.
.
))
))
I!
2 ) F
)
@
=
))
<
$2
0< J
=
A= +*>
*"
))!
"
$
"
)
F
T 9!
O
1
1`3
1[A )
1,% <QH
1
1)
! 3
1)
A 3Z)1N3
1
!
3
1N3
1N3 0 0% 0&#M9 Z
1N3
H 2*NNFFF
" N" F ) "N
"
"-!@ Z)
)
)
1)
A 3Z)1N3
1 @23Z 1N3
\
F
1` 2
:
Z
1
F
!
!
!
:
)
)
YZ21N3
]
\
F
1N
1N,% 3
\
F
]
\
F
]
)
A3
U
3
2
1N)
A3
!
)
!
)
Y O
IA% - J
G
6
- '
1N
F 3
1!
3<
1N!
3
1
3# A1N
3
)
)
3
)
)
3
1)
A 3,%
"<
!
1N)
1 @23
1N @23
1
F 3<
! !
)
:
)
Y
G
( 66
1N
F 3
1!
3# A1N!
3
)
)
3
3Z21N3
TZ U31
)
:
1N
1
)
!
H[3
"M H3
A )H
3
3<
1` !
Z
QH
<
!
1 @23
1N @23
1
F 3<
N
"
'(
-
T ,% -. U
1
#
&
%
A3
3Z 1N31N3
ZQ
1!
Z3
1
3Z 1N3
3Z 1N3
]
1N3
4 !&! >
<
"
<
F ""
! :
0)
)
:
!
"
" "
2
A2
<
:
))
"
2
2
?
A2
F
" )
!
#!
!
0!
F "
! ;
<$
!
4
= :
"
"
))
)4"
))
!
:
!
;)
9!
" %> )
:
0 ;
!) !
F
4
#9
"
"
5
5
<
D
)
B
;
-K
9
-
E
!
!
.
"
))
<
))
:F
!
,% -<
"
4"
.
)
:
9 !
"
!
,% -. !
:
$ #
$!
<
)
) * 12
"
4 )
F "
F "
& ; )
22
<
-
34
4 5 6
# 2 )
; "
))
!
F
) @ "AB
+@ "<
@
4! 2 ) F
@ "AB
"
"
))
)
*57
" ;
)
)
@ )" <
4"
"
; 9
@
! )"
)
;!
<$0 -O
-
"
!
;!
<
9
C
"
")
))
"
"
9 : )
8 7N ' 8
,% -.
#
&
%
"
$
:
"
9
"
)
!
O
:
"
F "
)
9
!
< 2)
"
#9
" !
6
)
!!
?
* %
*
*
%%
#2
%
9
T 9!
\
F
! 31!
<QZ!31
! 772 2 2 =)) =
""7 )2 %) 7
1!
3Z 1N31N31N3
7
*
)=
; %<
<Q
IZ J3
3Z 1N3
1
\
F
1
! 31Z !
QZ!31)
1N31N3
< ! 772 2 2 =)) =
""7 )2 %) 7
7
*
)=
; %<+
Z
\
4
]
1Z
<Q
IZ 4Z J
QH )
A 3Z 1N3
H3Z 1N3
]
1N3
]
\
F
1
! 31!
<QZ!31
! 772 2 2 =)) =
""7 )2 %) 7
<
<$0 ,% -
-
T ,% -. U
<
1!
3Z 1N31N31N3
7
*
) =
; %<
<Q
IZ J3
3Z 1N3
1
\
F
"
'(
;
$0
1
$
1
! 31Z !
QZ!31)
1N31N3
< ! 772 2 2 =)) =
""7 )2 %) 7
7
*
) =
; %<+
Z
\
4
]
1Z
<Q
IZ 4Z J
QH
!
U
1[A )
QH
H[3
1,% <QH
"M H3
1!
<QH "
H3
1
3<
!1N
3
1
<QH "
H
QH )
H3
?
1N
3
1N!
3
1!
<QH "
H3
1
3<
1N
3
1
<QH "
6H
QH )
H3
2
<
!
1N
3
1N!
3
1!
<QH "
7H3
1
3# A1N
3
1
<QH "
'H
QH )
H3,%
"<
!
1N
3
1
<QH "
(H
QH )
))H3
2
<
!
1N
3
1N!
3
1!
<QH "
5H3
1
3O : 1N
3
1
<QH "
H
QH
))H3%
"
"
1N
3
1N!
3
1N,% 3
A 3Z 1N3
))H3Z 1N3
]
1N3
]
4 !&! )C
5
<
)
!
)
'
))
:
) P)
A
) / "$
"
!
)
:)
O 7S IT UJ )
/F "
2
22
/
#9 2
> )
K:
"
0)
I ?% 49
"
F "
X S<9#9) :
4% &4% 9,4
J'
SG& #$?S#-%
/ K
@
: <
#9
=
B
4
R
C
:
4;!
2 )
"
:
!
"
)
"
4
4
/
9
%
!
-
2)
O )
) * 12
(!:
9
; "
))4 "
F "4 "
!
;
" ,% -. @) "
0
!
" 9
! ) !
6
1
"
"
34
4 5 6
,% -. -0
*57
!
)) F "
;
4
"
2 :
)-
8 5N ' 8
,% -.
$B
E .
%
*
2 )"
*
#
T 9!
O
! )
"
1
1I
1N3
1N3
H
1
$
1[A )
QH
H[3
1,% <QH
"M H3
1
"
<QH "
H3
1
3#
$ "1N
1 F 3
1 )
<QH "
H3
1
)) <QH "
6H3
1N F 3
1N
"
3
1
"
<QH "
H3
1
3
:%
1N
1 F 3
1 )
<QH "
'H3
1
)) <QH "
(H3
1N F 3
1N
"
3
1
"
<QH "
7H3
1
3< @ <
1N
3
1 F 3
1 )
<QH "
H3
1
)) <QH "
H3
1N F 3
1N
"
3
1
"
<QH "
5H3
1
3W
"1N
1 F 3
1 )
<QH "
H3
1
)) <QH "
H3
1N F 3
1N
"
3
1N,% 3
3
)QZ 3
3Z 1N3
_
J3Z 1N3
2*NNFFF
"
N" F )
"N
N
"
! )
A )H
"
<Q
IZ J3
1
3Z 1N3
1 F 3
\
F
1
! 31`
QZ 34*2 *56*4751N31N3
H 2*NNFFF
" N" F ) "N
N
! A )H
1 )
<Q
'6*,1N3
IZ 4 J36*
]
\
F
! 31`
QZ 34*2 *56*4751N31N3
2*NNFFF
" N" F ) "N
N
)) M M
! A )H
1
H
1
]
1N F 3
)) <Q
'6*,1N3
IZ 4 J36*
1N3
4 !&! ))
#!
!
!
"
'(
-
T ,% -. U
1
1
#
&
%
'
!
U
3
51N )
1N
3
))3
3
1N )
1N
3
))3
1N )
1N
3
))3
3
1N )
1N
3
))3
$!
G
,% - 2 : )
0
<
9 F
<
!
.
0
<
1Y0&# #^ b
D
4F )
&
4"
F
"
# A
!
"
))
4
<#< "
F
"
4
" :
)
-
)
E3
"
)@
I
J
- 2
F
!
F "
&
2 ) F
1
3
; ,% -= :
2
<
!
; : 4"
1N
=
")
3
"
1
*
3
F
) * 12
"
2
<
2 : :
34
4 5 6
F
!
1N
*
3
"
*57
8
N '8
,% -.
% " ))
# :0
)
F "
>
2
"
;)
"
)
)
;
4"
0
<
"
"
,% -. -<
F
"
"
)"
" ))
)
F
<
" F
))
"
. 1%%
)
1
A 3<
F 3
1N)
;!
!
1)
1N
F
3
A3
2 -
%%
TD
:2
"
'(
<#<
! )"
" 4
"
2)
!)
EU
1)
$
!)
O
#9
"
) F " 4
X S<9#9-S
4" : "
:
! )
&
)
"
= 2 ) :
4"
F "
>
*
TD
#
&
%
A 31S<9#93<
1NS<9#931
F 31S<9#93
1NS<9#931N)
A3
:2
1NS<9#931N
F
EU
31S<9#93
)
F
S<
9#
9
A
S<
9#
9
<
S<9#9
:2
''!
G
!) !
O 0$0!)
) * 12
!
"
!
"
34
4 F
F "4F )
4 5 6
9
F
"
*57
!
)
)
%
R
?
2
)@
!)
>
)) 4"
8 6N ' 8
,% -.
#
&
%
A
$
"
'(
.
,% -.
=
0A2
/ "
F
2
:F
<
))
"
F
!) #
2
9 :2
R :2 :
22 K "
)
@
:
A) P
P
:
G
9!F
4,% -<
) 9 F
" :
%
"
))
!
)
" )
: !
0 )
" )
" )) !
"
)
;))
)
F
"
:
<
(
"
/"
D0
9
F
"
E)
;!
B "
" %
" : "
#
" " B ) >
)
:
)
2)
7
@2
9) <
/ )! "
7
))
" :
)
<
"
2
)) ) 0 F )
:F
%> )
F
,% -<
>P
: ))
#-?
(
)!
7
2
)
:
4
"
/ > )
F
F "
O 7S-<
IT
:
T
?
)" /
)! "
9
7
7
"
7
;!
4" "
9 !
!
K"
"
D
"E-0 "
4F )
" D 7 4:
)
"
) :
B
F )
"
)" [
O
"
"= "
UJF " "
<
"
2
4"
B
(N
:
!
=
; "
"
@
)
:F
)
"
2 )
! "
4F
%
) "
C
"
"
-
)
" 9 !
U
2
I# )J
@2
2
!)
:
4F
)
!)
"
!)
"
=
2 )"
C
! -B
"
:
"
? )
,% -R 2 : )
:
-
Y
, 4,
) * 12
"
34
4 5 6
*57
8 'N ' 8
,% -. / 9
%
F
E
5
,% -.
,% -.
**Q I
_.
#
&
$
"
'(
@J10G 3
**Q c?&S# G&c1 ?&- <3 c
IcI1 9$3Ic
*c1<#<3J[J̀ c
JcIc
*c1<#<3J[
.
@
c
0&<c
.
@
**Q 0)
0)
**Q
#
<
!
<[9
**Q O
S
**Q c
O 0$0cS
S
**Q G "
"
Ic
\c.
"
@=)
Ic
4cS
"
`c
3c
= "
c
]c
J̀
J̀
"=@[c
SG& #$?S#c .
**Q
**Q
@
9 ` c&c<
#
_
"
` 0 "#
#
**Q c
1c$
) 0A2
**Q $
) 0A2
c̀c_$
$
) 0A2
cc$
) 0A2
_
$
) 0A2
c
_c$
) 0A2
_1 9$3 _1 <3
= "
9
) 0A2
9
!
`c
3c
) 0A2
**Q 0A2
G2$ ) 0A2
0A2
**Q 1 9$3 _1SG& #9&#3
G2$ )
**Q c
1c_c
1Qc_c
3c_c
3Qc_c
Qc_c
YQc
"=@
<
**Q c
G$<0$0<-=^c1 9$3a
**Q 1 9$3 _1?$ 3 _1 ?&- <3I<
"
c
ac_
**Q c
0 0% 0&#M9 c1 9$3 _c
SG&#0&#M9 c1 9$3
"
G "
!
**Q 1 <3 c
Ic1 9$3 Ic
4c1 9$3J̀ c
Jc
O
$
)
**Q 1 #$ & 3
@=)
S
@ 0 "#
**Q c
1cN 1 <3[c
3c
)
) * 12
.
@=)
**Q 1 <3 c
Qc Ic
Hc1 #$ & 3 c
Hc _ 1 9$3 J
0 "#
.
#
) _ 1 9$3 _.
**Q c
1c
I1 <3_1 9$3J
)
9
_
34
4 5 6
*57
Ic
4c<
J̀J
8 8
,% -. / 9
5
%
.
#
&
$
"
'(
))
:
T
U
9 <
4%
" :4<
2*NNFFF F7
T
U
9 <
4%
%
" :4<
2
" :4W
e
2*NNFFF-"!
T5U
W% @ 4
U
G)"
)
! #
" Nd "
49
!! !
N2 2
4 O ") *
5& !
! ))-) !
N
<
!
4
!
'
!'
K!
!
% @ *
&
T
T
T
T
) * 12
-
% S @4W R
M/. 67N
#!
#
2*NNFFF
T(U
9 % f)) 4%
7
2*NNFFF K
U
<
U
U
F
"
*
/ !!
2*NNFFF
!
!
*
#
2*NN! )!
@
:!
!? .
N
)
&
!
-
$
)
##
N
#
-A )
)
#!
N
N " A
"
& '! !
)) " N
40
'(
2) NK N2 2
4
)
!
*
!
N,2
<
2"
*
!
N
" N
F
J !
" N
!
+CCC
N "
4W
E
F
!
*
!
2*NNFFF
NAC
#!
1# !
#
)>>>F+CCCL
" Nd"! N)
N
<
;)) *
E '
#
7J K !
##
#
2*NNFFF "!
F
T'U
5 #&
N
)
+CCC
2*NNFFF"!
T6U
@4<
*
G !
H) I
NA )-C)-FFF( 2
*
E ': J !
!?
2*NNFFF
F
N @
T
49
@4<
*
'# ! !
E0 )>FC=F)>>=
N#$N&G#0-A )-C)
2*NNFFF
T7U
)
" N
!
"N
E ' J !
)NA )N " A
)
!?
N
6
N )
#
N
NM 77'7
22
)9FC*F+CCC
-A ) 2"
9 <
U
!
2
" Nd "
4& R)
*
$
O
Gg$ ))@ #
! !)
NA )C)-"
N
)N " A
)
$ 0
"
34
4 5 6
*57
4
9 )
4 =& 7-( '
-
-6
8
8
,% -. / 9
%
=
$
"
'(
2 )"
! 772 2 2 =)) =
""7 )2 %)
7
7*
%
T ,% U
=
G
T <#< U
1[A )
QH
H[3
1Y<GS#^ 0
! )
^ #0%
H 2*NNFFF
" N" F ) "N
N
1
! )
3
1
"
)QH
'(H3
1
3#
$ "1N
3
1
3
'1N
3
1
3 6 1N
3
1
3
1N
3
1N
"
3
1
"
)QH5'
H3
1
3
:%
1N
3
1
3 6 1N
3
1
3
1N
3
1
3
1N
3
1" 2)
!
)QH
)
<
1
!
3
1N
1!
3
< # A1N!
1N" 2)
! 3
1N
"
3
1
"
)QH (
H3
1
3< @ <
1N
3
1
3
'1N
3
1" 2)
!
)QHR
2
=
))F
H3
1
!
3O F 1N
!
1!
3
<
!
<
1N" 2)
! 3
1N
"
3
1
"
)QH7777777H3
1
3W
"1N
3
1" 2)
!
)QH
)
)
1
!
3
1N
1!
3
< <
)<
1N" 2)
! 3
1N
"
3
1N
! )
3
P'
) * 12
#
&
"
34
4 5 6
"
! )
!
!
" "H3
:
W
1Y0 0% 0&#
! )
I "
`J3
1Y0 0% 0&#
"
I
4I
_
_" 2)
! J̀J3
1Y9## #
"
) < X$0.? $0<3
1Y0 0% 0&#
IX S<9#9J3
1Y0 0% 0&#
IX S<9#9J3
1Y0 0% 0&#
IX S<9#9J3
1Y0 0% 0&# " 2)
!
I
!
4!
J3
1Y9## # " 2)
!
) S<9#9 X$0.? $0<3
1Y0 0% 0&#
!
IX S<9#9J3
1Y0 0% 0&# !
IX S<9#9J3
H3
3
3
3
1N!
O
!
!
*57
3
2-
H3
3
!1N!
) 4 !&!
3
1
'
2
8
8
,% -. / 9
%
! 772 2 2 =)) =
""7 )2 %)
7
7
*
$
"
'(
)=
G
T ,% U
T <#< U
1[A )
QH
H[3
1Y<GS#^ 0
!
^ #0%
H 2*NNFFF
" N" F ) "N
N
! " "H3
1
! 3
1
QH
'H !
QH"
!H3
1)
A 3?
1N)
A3
1
!
3O F 1N
!
3
1 F 3 1N F 3
1N
3
1
QH
H!
QH AH3
1)
A 3,%
"<
!
1N)
A3
1
!
3
1N
!
3
12
:
)
3
G
( 66
1N2
:
)
3
1 F 3 1N F 3
1N
3
1
QH 6 H !
QH"
AH3
1)
A3
2
<
!
1N)
A3
1
!
3
1N
!
3
12
:
)
3 O
IA% - J
G
6
- '
1N2
:
)
3
1 F 3 1N F 3
1N
3
1!
<QH AH3
1
)3
< 1N
)31
3# A1N
3
1N!
3
1!
<QH"
H3
1
)3
1N
)3
1
3<
! 1N
31
3<
1N
3
1N!
3
1!
<QH"
!H3
1
)3
< 1N
)3
1
3<
)1N
31
3<
!1N
1N!
3
1N
! 3
P'
!
+ 4 !&!
! 772 2 2 =)) =
""7 )2 %)
1Y0 0% 0&#
1Y0 0% 0&#
2
:
1Y9## #
1Y9## #
1Y0 0% 0&#
2
:
1Y9## #
1Y0 0% 0&# !
1Y9## # !
1Y0 0% 0&# )
1Y0 0% 0&#
1Y0 0% 0&# 2
1Y0 0% 0&# F
1Y0 0% 0&#
1Y0 0% 0&#
1Y0 0% 0&#
II
_
_!
J̀J3
A4
!
4
)
[4 F J3
!
<$0 X$0.? $0<3
S<9#9 X$0.? $0<3
I)
A4
!
4
)
[4 F J3
S<9#9 X$0.? $0<3
I )[4
[4
J3
" < X$0.? $0<3
A IX S<9#9J3
!
IX S<9#9J3
:
)
IX S<9#9J3
IX S<9#9J3
) IX S<9#9J3
IX S<9#9J3
IX S<9#9J3
3
1$
7
!
I)
7@
' 2
%% H
H
*
)=
G
T ,% U
T <#< U
1[A )
QH
H[3
1Y<GS#^ 0
!
^ #0%
H 2*NNFFF
" N" F ) "N
N
1
! 3
1
QH
H!
QHF : H3
1)
A 3%
"
"
1
!
3 !
"1N
!
1 F 3 1N F 3
1N
3
1
QH 6 H !
QH AH3
1)
A3
2
<
!
1
!
3
1N
!
3
12
:
)
35 O
"
W)
1N2
:
)
3
1 F 3 1N F 3
1N
3
1!
<QH AH3
1
)3
< 1N
)31
3# A1N
1N!
3
1!
<QHF : H3
1
)3< 1N
)31
3O : 1N
3
1N!
3
1N
! 3
P'
) * 12
#
&
"
34
4 5 6
!
!
1N)
3
A3
1N)
A3
!
II
_
_!
J̀J3
A4
!
4
)
[4 F J3
!
<$0 X$0.? $0<3
S<9#9 X$0.? $0<3
I)
A4
!
4
)
[4 F J3
S<9#9 X$0.? $0<3
I )[4
[4
J3
" < X$0.? $0<3
A IX S<9#9J3
!
IX S<9#9J3
:
)
IX S<9#9J3
IX S<9#9J3
) IX S<9#9J3
IX S<9#9J3
IX S<9#9J3
8 !8$
' 2
I)
3
0 4 !&!
*57
" "H3
1Y0 0% 0&#
1Y0 0% 0&#
2
:
1Y9## #
1Y9## #
1Y0 0% 0&#
2
:
1Y9## #
1Y0 0% 0&# !
1Y9## # !
1Y0 0% 0&# )
1Y0 0% 0&#
1Y0 0% 0&# 2
1Y0 0% 0&# F
1Y0 0% 0&#
1Y0 0% 0&#
1Y0 0% 0&#
1!
8
8
Seminar 1912
XML und Datenbanken
Thema 7:
Anfragesprachen für XML - Quilt, XQuery
Quilt
D. D. Chamberlin, J. Robie und D. Florescu.
Quilt: An XML Query Language for Heterogeneous Data Sources.
WebDB (Informal Proceedings), 53 - 62, 2000, http://www-rodin.inria.fr/Fmbrepubs_dana.html
XQuery
S. Boag, D. Chamberlin, M. F. Fernandez, D. Florescu, J. Robie, J. Siméon und M. Stefanescu.
XQuery 1.0: An XML Query Language.
W3C Working Draft, 2001, http://www.w3.org/TR/xquery/
Martina Welt
Acherstr. 9
76337 Waldbronn
e-mail: martina_welt@web.de
Matrikelnummer: 3727750
Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery
Martina Welt, Matrikelnr. 3727750
Seite 2
Inhaltsverzeichnis
1.
ÜBERBLICK
3
2.
EINFÜHRUNG
5
3.
DIE ANFRAGESPRACHE QUILT
6
3.1
Anforderungen und Ziele beim Entwurf
6
3.2
Die Vorgehensweise beim Entwurf
6
3.3
Die Ein-/Ausgabestruktur in Quilt
7
3.4
Ausdrücke in Quilt
7
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.5
3.5.1
3.5.2
3.5.3
3.6
7
8
9
11
13
13
14
14
Datenbankanfragen
15
Grouping
Joins
Views
15
15
15
Zusammenfassung und Bewertung
3.6.1
3.6.2
4.
Pfad-Ausdrücke
Elementkonstruktoren
FLWR-Ausdrücke
Ausdrücke, die Operatoren und Funktionen beinhalten
Bedingte Ausdrücke
Funktionen
Quantoren
Ausdrücke zum Binden von Variablen
Zusammenfassung
Bewertung
DIE ANFRAGESPRACHE XQUERY
16
16
17
18
4.1
18
4.2
18
4.3
Die Ein-/Ausgabestruktur von XQuery 1.0
19
4.4
Ausdrücke in XQuery 1.0
19
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
4.4.8
4.4.9
Primäre Ausdrücke
Pfad-Ausdrücke
Konstruktoren
FLWR-Ausdrücke
Sortierungsausdrücke
Bedingte Ausdrücke
Funktionen
Quantoren
20
20
21
22
22
22
23
23
24
4.5
Datenbankanfragen
24
4.6
Query Prolog
24
4.7
24
4.7.1
4.7.2
5.
Zusammenfassung
Bewertung
QUELLENANGABEN
24
25
26
Seite 3
1. Überblick
Im folgenden Beitrag geht es um die Bearbeitung von XML-Dokumenten mit den Anfragesprachen Quilt und XQuery.
Für beide Sprachen werden jeweils nach einer kurzen Einführung die Anforderungen und Ziele
vorgestellt, die beim Entwurf gesetzt wurden. Anschließend wird als Schwerpunkt des Beitrags
die jeweilige Sprache vorgestellt und ihre Besonderheiten hervorgehoben. Danach folgt eine
kurze Zusammenfassung und Bewertung. Den Abschluss bildet ein Vergleich der beiden Anfragesprachen.
Die nachfolgende Graphik verdeutlicht die Entstehung der beiden Anfragesprachen und die
Zusammenhänge mit anderen Anfragesprachen, die teilweise in vorhergegangenen Beitragen
vorgestellt wurden. Die Gemeinsamkeiten der Sprachen werden später bei der Vorstellung von
Quilt und XQuery genauer beschrieben.
Seite 4
Die Entstehung von Quilt und XQuery 1.0
XML-QL
XQL
SQL
XPATH
1.0
OQL
QUILT
Lorel
XQuery 1.0
XPath 2.0
(Untermenge)
Einfluss
Übernahme von Features
YATL
Seite 5
2. Einführung
Das World Wide Web ermöglicht die sofortige, weltweite Bereitstellung aller Arten von Informationen. Dafür müssen jedoch zwei Kommunikationsmechanismen vorhanden sein:
1. Eine universelle Darstellungsprache.
2. Eine universelle Anfragesprache.
Der erste Mechanismus wird von XML erfüllt. XML arbeitet mit strukturierten und semi-strukturierten Dokumenten, relationalen Datenbanken und Objektbehältern.
Der zweite Mechanismus wird beispielsweise durch die Anfragesprache Quilt erfüllt. Dies erreicht man zum einen dadurch, dass Quilt die Stärken kombiniert, die andere Anfragesprachen
in unterschiedlichen Bereichen haben. Zum anderen wurde Quilt so konzipiert, dass Informationen aus verschiedenen Datenquellen zu einem Anfrageergebnis mit einer eigenen Struktur zusammengefügt werden können.
Ein weiterer Ansatz für den zweiten Mechanismus ist die Anfragesprache XQuery 1.0. Sie baut
auf der Anfragesprache Quilt auf und schließt die Sprache XPath 2.0 als Untermenge ein.
Seite 6
3. Die Anfragesprache Quilt
3.1
Die W3C XML Query Working Group ist eine Arbeitsgruppe, die sich damit befasst hat, welche
Anforderungen denn nun an eine solche universelle Anfragesprache zu stellen sind.
Für eine universelle Anfragesprache hat diese Arbeitsgruppe folgende Anforderungen formuliert:
•
•
•
•
•
Sie muss so flexibel sein wie XML.
Sie muss in der Lage sein, eine gegebene Ordnung und Hierarchie zu erhalten.
Für Datenbankanfragen muss sie bekannte Datenbankoperationen wie z. B. JOINS und
GROUPING zur Verfügung stellen.
Sie muss alle in XML vorhandenen Strukturen von Informationen behandeln können.
Und sie muss in der Lage, sein die Informationen von einer Struktur in eine andere zu
transformieren.
Don Chamberlin von IBM, Jonathan Robie von der Software AG und Daniela Florescu von
INRIA haben die Aufgabe angenommen, die Anfragesprache Quilt zu entwerfen.
Folgende Ziele wurden von der Gruppe festgelegt:
•
•
•
Quilt soll eine kleine Sprache sein, die den Anforderungen der W3C XML Query Working
Group gerecht wird. Vorerst soll sie entworfen werden und kann dann später basierend auf
dem Entwurf implementiert werden.
Die Anfragen sollen kurz, aber lesbar sein.
Quilt soll flexibel genug sein, um ein breites Spektrum von XML-Informationsquellen bearbeiten zu können.
3.2
Beim Entwurf der Anfragesprache Quilt wurden folgende Features verschiedener anderer Sprachen, die ihre Stärken in unterschiedlichen Bereichen haben, übernommen:
Anfragesprache
XPath 1.0, XQL
XML-QL
SQL
OQL, SQL
Feature
Syntax zum Navigieren in hierarchischen Dokumenten
Binden von Variablen und das Nutzen der gebundenen Variablen,
um neue Strukturen zu erstellen
Syntax die ein Muster für neu strukturierte Daten bereitstellt
(Das SELECT-FROM-WHERE-Muster in SQL)
Funktionale Sprache, die aus verschiedenen Arten von Ausdrücken
zusammengesetzt ist, die beliebig geschachtelt werden können.
(Subqueries)
Des weiteren hatten die Anfragesprachen Lorel und YATL einen gewissen Einfluß bei der Entstehung von Quilt.
Der Name Quilt spielt dabei auf die Eigenschaft an, wie bei einem Patchwork Features verschiedener anderer Sprachen zusammenzufügen. Daneben verdeutlicht er auch das Ziel, Informationen aus mehreren verschiedenartigen Quellen zusammenzusetzen.
3.3
Seite 7
Die Ein-/Ausgabestruktur in Quilt
Quilt ist in der Lage, eigenständige XML-Dokumente, Fragmente von XML-Dokumenten oder
Ansammlungen von XML-Dokumenten als Ein- und Ausgabe zu behandeln.
Quilt basiert auf dem XML-Query-Datenmodell, das in [3] beschrieben wird. Dort wird ein Dokument als ein Baum aus Knoten dargestellt. Ein Fragment eines Dokuments oder eine Ansammlung von Dokumenten besitzt keine gemeinsame Wurzel und kann als geordneter Wald
von Knoten verschiedener Typen (Elementknoten, Attributknoten, Textknoten) dargestellt werden.
3.4
Ausdrücke in Quilt
Quilt definiert folgende Arten von Ausdrücken:
•
•
•
•
•
•
•
•
Pfad-Ausdrücke
FLWR-Ausdrücke
Bedingte Ausdrücke
Funktionen
Quantoren
Nachfolgend wird mehr oder weniger detailliert auf die verschiedenen Ausdrücke eingegangen.
3.4.1
Pfad-Ausdrücke
Die Pfad-Ausdrücke in Quilt basieren auf einer abgekürzten Syntax von XPath. Wie bei XPath
besteht ein Pfad-Ausdruck aus mehreren "Schritten". Jeder Schritt stellt eine Bewegung durch
das Dokument in eine bestimmte Richtung dar. In jedem Schritt kann eine Bedingung Knoten
ausfiltern. Jeder Schritt hat als Ergebnis eine Menge von Knoten, die als Eingabe für den
nächsten Schritt dienen. Nach dem letzten Schritt erhält man als Ergebnis einen geordneten
Wald aller Knoten, die den Pfad-Ausdruck erfüllen sowie deren Nachfolger.
Ein Pfad-Ausdruck kann entweder mit einem Ausdruck beginnen, der einen bestimmten Knoten
spezifiziert, so liefert beispielsweise die Funktion document(string) den Wurzelknoten des im
Eingabeparameter spezifizierten Dokuments. Oder der Pfad-Ausdruck kann mit den Zeichen "/"
oder "//" beginnen, was einen durch die Umgebung festgelegten Wurzelknoten darstellt.
Hier sind einige der Symbole der abgekürzten Syntax:
.
..
/
//
@
*
[]
[n]
aktueller Knoten
Vorgänger des aktuellen Knotens
Wurzelknoten (z. B. /C) oder
Kinder des aktuellen Knotens (z. B. document("schloesser.xml")/Kapitel)
Nachfolger des aktuellen Knotens (Abschluss von /); // ist eine Abkürzung für
/aktueller Knoten oder beliebig geschachtelter Nachfolger davon/
(z. B. document("schloesser.xml")/Kapitel[5]//Abbildung)
Attribut des aktuellen Knotens
"any" (Knoten mit beliebigem Namen)
schließen einen logischen Ausdruck ein, der als Bedingung für einen gegebenen
Schritt dient
wählt das n-te Element einer Liste aus
Seite 8
Beispiel:
Finde die Abbildung mit der Unterschrift "Heidelberger Schloss" im 5. Kapitel des Dokuments
"schloesser.xml":
document("schloesser.xml")/Kapitel[5]//Abbildung[Unterschrift = "Heidelberger Schloss"]
Zur Auswahl einer Menge von Elementen, deren Ordinalzahlen in einem gewissen Bereich liegen, hat Quilt von XQL das RANGE-Prädikat übernommen.
Beispiel:
Finde alle Abbildungen in den Kapiteln 2 bis 5 des Dokuments "schloesser.xml":
document("schloesser.xml")/Kapitel[RANGE 2 TO 5]//Abbildung
Quilt erweitert die Operatoren von XPath um einen Dereferenzierungsoperator, der durch die
Zeichen "->" dargestellt wird. Dieser Operator kann in den verschiedenen Schritten eines PfadAusdrucks vorkommen. Folgt ein Dereferenzierungsoperator einem Attribut vom Typ IDREF
oder einem Schlüssel, so gibt er das oder die Elemente wieder, die durch das Attribut oder den
Schlüssel referenziert werden.
Der Dereferenzierungsoperator ist in seiner Wirkung der id-Funktion von XPath recht ähnlich
(siehe dazu den Seminarbeitrag zum Thema XPath). Die Schreibweise ist allerdings leichter zu
lesen, insbesondere bei Ausdrücken mit mehreren derartigen Operatoren.
Beispiel:
Finde Unterschriften von Abbildungen, die durch <figref>-Elemente im Kapitel mit dem Titel "BadenWürttemberg" des Dokuments "schloesser.xml" referenziert werden:
document("schloesser.xml")/Kapitel[Titel = "Baden-Württemberg"]//figref/@refid->/Unterschrift
Wie bei XPath können die bei Quilt verwendeten Bezeichner in Ausdrücken durch Namensraum-Präfixe qualifiziert werden. Quilt stellt dafür eine Syntax zum Deklarieren des Universal
Resource Identifiers (URI) zur Verfügung.
Beispiel:
Finde alle <Museum>-Elemente im abc-Namensraum, die jedes beliebige Subelement des xyz-Namensraums enthalten:
NAMESPACE b1 = "www.abc.com/namen"
NAMESPACE b2 = "www.xyz.com/namen"
document("schloesser.xml")//abc:Museum[xyz:*]
3.4.2
Ein Elementkonstruktor erzeugt einen Knoten vom Typ Element. Ähnliche Konstruktoren gibt es
für andere Knotentypen wie Kommentare oder Abarbeitungsanweisungen ("processing
instructions"). Ein Elementkonstruktor besteht aus einem Start- und einem End-Tag, die denselben Namen haben müssen. Dieser Name wird entweder durch eine Konstante oder eine
Variable festgelegt. Der Start-Tag kann Werte für ein oder mehrere Attribute festlegen. Zwischen Start- und End-Tag legt eine Liste von Ausdrücken den Inhalt des Elements fest.
Obwohl ein Elementkonstruktor ein eigenständiger Ausdruck ist, wird er typischerweise in anderen Ausdrücken verwendet. Beispielsweise in einem FLWR-Ausdruck, in dem eine oder mehrere Variablen gebunden werden, die dann im Elementkonstruktor verwendet werden.
Seite 9
Beispiel:
<Mitarbeiter Personalnummer = $pid>
<Name> $name </Name>
<Gehaltsgruppe> $gg </Gehaltsgruppe>
</Mitarbeiter>
3.4.3
FLWR-Ausdrücke
Ein FLWR-Ausdruck setzt sich aus FOR-, LET-, WHERE- und RETURN-Anweisungen zusammen, die in einer bestimmten Reihenfolge vorkommen müssen. Die Idee wurde vom SELECTFROM-WHERE-Ausdruck in SQL übernommen. Ein FLWR-Ausdruck wird für Iterationen über
Mengen von Elementen verwendet. Ein FLWR-Ausdruck bindet anfangs Werte an eine oder
mehrere Variablen. Diese werden anschließend zur Ermittlung des Ergebnisses verwendet. Das
Ergebnis eines FLWR-Ausdrucks kann ein Knoten, ein geordneter Wald von Knoten oder ein
primitiver Wert sein.
Ein FLWR-Ausdruck bindet zunächst mit einem FOR-Satz Werte an eine oder mehrere Variablen. Der FOR-Satz kann von einem oder mehreren LET-Sätzen und zusätzlichen FOR-Sätzen
gefolgt werden, die weitere Variablen binden. Der WHERE-Satz enthält Bedingungen, die durch
AND, OR und NOT verknüpft sind und oftmals Referenzen auf gebundene Variablen enthalten.
Der RETURN-Satz erstellt die Ausgabe des FLWR-Ausdrucks.
Jede in einem FOR-Satz eingeführte Variable tritt in Verbindung mit einem Ausdruck auf. Im
allgemeinen liefert jeder dieser Ausdrücke eine Knotenliste. Das Ergebnis eines FOR-Satzes ist
jedoch eine Tupelliste, bei der jedes Tupel an alle Variablen gebunden ist. Die Tupelliste ist das
kartesische Produkt der Knotenlisten, die man als Ergebnis der Ausdrücke des FOR-Satzes
erhält. Ist nur ein FOR-Satz mit einer in einem Ausdruck gebundenen Variablen vorhanden,
dann ist das kartesische Produkt gleich der Knotenliste des Ausdrucks.
Beispiel:
FOR-Satz mit nur einer gebundenen Variablen:
for $x in (<eins/>, <zwei/>, <drei/>)
return <Ausgabe> $x </Ausgabe>
In diesem Beispiel wird die Variable $x dreimal gebunden, zuerst an den Wert <eins/>, dann an den Wert
<zwei/> und zuletzt an den Wert <drei/>. Für jede Bindung der Variablen wird ein Tupel erzeugt und für
jedes erzeugte Tupel wird der RETURN-Satz aufgerufen, so dass die Ausgabe folgendermaßen aussieht:
<Ausgabe>
<eins/>
</Ausgabe>
<Ausgabe>
<zwei/>
</Ausgabe>
<Ausgabe>
<drei/>
</Ausgabe>
Beispiel:
FOR-Satz mit mehreren gebundenen Variablen:
for $i in (1, 2),
$j in (3, 4)
return
<Tupel>
 $i 
<j> $j </j>
Seite 10
</Tupel>
Dieses Beispiel zeigt wie die Tupel als Kartesisches Produkt der Knotenlisten gebildet werden, die wiederum als Ergebnisse aus den ausgewerteten Ausdrücken hervorgehen:
<Tupel>
1
<j>3</j>
</Tupel>
<Tupel>
1
<j>4</j>
</Tupel>
<Tupel>
2
<j>3</j>
</Tupel>
<Tupel>
2
<j>4</j>
</Tupel>
LET-Sätze binden Variablen anders als FOR-Sätze. Ein LET-Satz bindet einfach eine oder
mehrere Variablen an des Ergebnis von einem oder mehreren Ausdrücken. Prinzipiell gibt es
folgende Unterschiede zwischen FOR- und LET-Sätzen:
FOR-Satz
Erzeugt aufgrund der Iteration über Knotenlisten viele Bindungen für eine Variable.
Jede Variable wird an einen einzelnen Knoten
(mit seinen Nachfolgern) gebunden.
LET-Satz
Erzeugt genau eine Bindung für jede Variable.
Jede Variable wird an einen Wald von Knoten
gebunden.
Beispiel:
LET-Satz mit einer gebundenen Variablen:
let $x := (<eins/>, <zwei/>, <drei/>)
return <Ausgabe> $x </Ausgabe>
Die Variable $x wird direkt an den Ausdruck (<eins/>, <zwei/>, <drei/>) gebunden und der RETURN-Satz
aufgerufen, so dass die Ausgabe folgendermaßen aussieht:
<Ausgabe>
<eins/>
<zwei/>
<drei/>
</Ausgabe>
Ein FLWR-Ausdruck kann mehrere FOR- und LET-Sätze enthalten und jeder von diesen Sätzen kann Referenzen auf Variablen enthalten, die in früheren Sätzen entstanden sind. Das Ergebnis einer Folge von FOR- und LET-Sätzen ist eine geordnete Liste von Tupeln gebundener
Variablen. Die Anzahl dieser Tupel ist gleich dem Produkt der Kardinalität der Knotenlisten, die
Ergebnis der Ausdrücke in den FOR-Sätzen sind. Diese Tupel sind wie die gebundenen Variablen geordnet, es sei denn es wurde ein ungeordneter Ausdruck verwendet wie beispielsweise ein Ausdruck der die distinct-Funktion enthält.
Jedes der erhaltenen Tupel kann durch einen optionalen WHERE-Satz ausgefiltert werden. Nur
für die Tupel, für die der WHERE-Satz wahr ist, wird ein RETURN-Satz erzeugt. Ein WHERESatz kann mehrere Bedingungen enthalten, die durch AND, OR und NOT verknüpft sind und
oftmals Referenzen auf gebundene Variablen beinhalten. Variablen, die von einem FOR-Satz
gebunden wurden, stellen einzelne Knoten mit ihren Nachfolgern dar und werden deshalb typi-
Seite 11
scherweise in skalaren Bedingungen wie $x/Farbe = "rot" verwendet. Variablen, die von einem
LET-Satz gebunden wurden, liefern hingegen eine Menge von Knoten und können in mengenorientierten Bedingungen wie z. B. avg($x/Preis) > 100 verwendet werden. Die Reihenfolge
der Tupel wird beim WHERE-Satz erhalten.
Für jedes von einem FOR- oder LET-Satz erzeugte Tupel, das die Bedingungen des WHERESatzes erfüllt, wird auch genau ein RETURN-Satz erzeugt. Die Reihenfolge der Tupel wird im
Ausgabedokument festgehalten. Der RETURN-Satz enthält einen Ausdruck, der aus Elementkonstruktoren, Referenzen auf gebundene Variablen und verschachtelten Unterausdrücken
besteht.
FLWR-Ausdrücke können für strukturelle Änderungen an Dokumenten verwendet werden beispielsweise um eine Hierarchie zu invertieren (Autor-Buch-Liste -> Buch-Autor-Liste). Ein ergänzender SORTBY-Befehl kann die Ergebniselemente sortieren. Hierbei ist die Angabe
ASCENDING (aufsteigend) und DESCENDING (absteigend) möglich. Als default-Wert wird
ASCENDING angenommen. FLWR-Ausdrücke werden bei Datenbankanfragen für das Zusammenführen von Werten aus mehreren Dokumenten verwendet. Datenbankanfragen werden
weiter hinten beschrieben.
3.4.4
Auch bei Quilt gibt es Infix- und Präfix-Operatoren, Schachtelungen von geklammerten Ausdrücken, die üblichen arithmetischen und logischen Operatoren sowie die Mengenoperatoren
UNION (Vereinigungsmenge), INTERSECT (Schnittmenge) und EXCEPT (Differenzmenge).
Von XQL hat Quilt die Infix-Operatoren BEFORE und AFTER geerbt. Sie unterstützen die Suche von Informationen nach ihrer Position in der Ordnung des Dokuments. BEFORE arbeitet
mit zwei Mengen von Elementen und liefert die Elemente der ersten Menge, die vor mindestens
einem Element der zweiten Menge vorkommen. AFTER arbeitet ebenfalls mit zwei Mengen von
Elementen und liefert die Elemente der ersten Menge, die nach mindestens einem Element der
zweiten Menge vorkommen. Der Vergleich ist in beiden Fällen nur möglich, wenn beide Mengen
Untermengen derselben Instanz des Datenmodells sind. BEFORE und AFTER basieren auf der
globalen Ordnung des Dokuments, deshalb können sie die Position von Elementen vergleichen,
die nicht dieselben Eltern haben.
Beispiel:
Es wird ein Auszug aus einem Buch erstellt, der aus allen Elementen mit beliebigem Namen (deshalb //*)
besteht, die zwischen dem dritten und dem sechsten Abschnitt im siebten Kaptiel erscheinen. Dabei sind
die Elemente Nachfolger des Knotens Kapitel[7] und können an beliebiger Stelle unter dem Knoten
Kapitel[7] stehen, müssen also nicht direkte Nachfolger (Kinder) sein.
Die shallow-Funktion liefert ein Element ohne seine Unterelemente.
<Auszug>
FOR $k in //Kapitel[7]
$e in //*
AFTER ($k//Abchnitt) [3]
BEFORE ($k//Abchnitt) [6]
RETURN shallow ($e)
</Auszug>
Ein weiterer wichtiger Operator in Quilt ist der FILTER-Operator. FILTER verwendet zwei Operanden, wobei jeder von ihnen ein Ausdruck ist, der in der Regel zu einem geordneten Knotenwald ausgewertet wird. Der erste Ausdruck liefert also einen geordneten Knotenwald. Der
zweite Ausdruck filtert die gewünschten Teilstücke aus diesem Knotenwald aus. Ausgefiltert
werden Knoten, die in einer beliebigen Ebene des ersten Operanden auftreten und gleichzeitig
"top-level"-Knoten des zweiten Operanden sind.
Seite 12
Die nachfolgenden Bilder verdeutlichen die Wirkung des FILTER-Ausdrucks. Das erste Bild ist
das Ergebnis des Pfad-Ausdrucks /C. Das zweite Bild ist Ergebnis des FILTER-Ausdrucks /C
FILTER //A | //B.
Ergebnis von /C:
Es werden alle Wurzelknoten C einschließlich Nachfolgern ausgewählt.
C
B
C
C
B
A
B
A
C
C
A
A
B
B
Ergebnis von /C FILTER //A | //B:
Aus dem geordneten Knotenwald des Pfad-Ausdrucks /C werden nun die "top-level"-Knoten A
und B ausgewählt. Der grau unterlegte Knoten C ist zwar "top-level"-Knoten, entspricht aber
nicht dem Filterkriterium des zweiten Operanden und wird somit gestrichen.
B
A
A
B
B
B
A
A
B
Es kann passieren, dass der FILTER-Operator eine Knotenhierarchie in mehrere Knotenhierarchien aufteilt. Der hierarchische und sequentielle Zusammenhang der Knoten wird jedoch stets
erhalten. Der Filterprozess basiert auf der Knotenidentität, d. h. beide Operanden sind erforderlich, um denselben Knoten zu erhalten und nicht nur zwei Knoten mit demselben Wert. Folglich
ist die Ergebnismenge des FILTER-Ausdrucks leer, wenn die beiden Operanden keine gemeinsame Wurzel haben.
Der FILTER-Operator eignet sich also sehr gut dafür, bei einem Dokument bestimmte gewünschte Teile zu extrahieren und die ungewünschten Teile zu streichen, wobei die Dokumentstruktur erhalten bleibt. Beispielsweise kann mit Hilfe des FILTER-Operators ein Inhaltsverzeichnis zu einem Buch erstellt werden.
Beispiel:
Es wird ein Inhaltsverzeichnis zum Dokument "seminararbeit.xml" erzeugt, das mehrere Ebenen geschachtelter Abschnitte beinhaltet. Die Anfrage filtert das Dokument so, dass nur Abschnitt-Element und
Überschrift-Element, die sich direkt unter Abschnitt-Elementen befinden, aufgelistet werden. Andere Elemente wie Absätze oder Unterschriften von Bildern werden weggelassen.
<Inhaltsverzeichnis>
document("seminararbeit.xml") FILTER //Abschnitt | //Abschnitt/Überschrift
</Inhaltsverzeichnis>
3.4.5
Seite 13
Bedingte Ausdrücke
Quilt verfügt über den üblichen bedingten Ausdruck IF-THEN-ELSE. Bedingte Ausdrücke sind
dann hilfreich, wenn die Struktur der zurückzugebenden Information von einigen Bedingungen
abhängt. Wie alle Ausdrücke in Quilt, können auch bedingte Ausdrücke geschachtelt werden.
Beispiel:
FOR $b in //Beiträge
RETURN
<Beitrag>
$b/Titel,
IF $b/@Typ = "Zeitung"
THEN $b/Verfasser
ELSE $b/Autor
</Beitrag> SORTBY (Titel)
3.4.6
Funktionen
Quilt stellt eine Bibliothek mit Funktionen zur Verfügung. Diese enthält alle Funktionen der
Funktionenbibliothek des XPath-Kerns, alle Aggregationsfunktionen von SQL (wie avg, sum,
count, max und min) sowie zahlreiche andere hilfreiche Funktionen (wie distinct(collection),
empty(collection) und name(element)). Zusätzlich zu diesen Funktionen kann der Benutzer von
Quilt eigene Funktionen definieren. Eine Funktion kann rekursiv definiert sein, jedoch muss der
Benutzer selbst dafür sorgen, dass die Funktion terminiert.
Beispiel:
Diese rekursive Funktion berechnet die maximale Tiefe des Dokuments "wegenetz.xml":
FUNCTION depth ($e ELEMENT) RETURNS integer
{
-- Ein leeres Element hat die Tiefe 1,
-- ansonsten addiere 1 zur max. Tiefe der Nachfolger
IF empty($e/*) THEN 1
ELSE max(depth($e/*)) + 1
}
depth(document("wegenetz.xml"))
Eine Quilt-Anfrage besteht meistens aus einer Menge von Funktionsdefinitionen gefolgt von
einem Ausdruck, der diese Funktionen verwendet. Die Sichtbarkeit einer selbstdefinierten
Funktion ist eingeschränkt auf die Anfrage, in der sie definiert wurde. Jede Funktionsdefinition
muss die Typen ihrer Parameter und Ergebnisse deklarieren. Erwartet eine Funktion ein skalares Argument und bekommt statt dessen eine Menge, so liefert sie eine Menge zurück, bei der
jedes Element das Ergebnis der Anwendung der Funktion auf eines der Elemente der Eingabemenge ist.
Gegenstand weiterer Untersuchungen sind
•
zum einen ein Erweiterungsmechanismus, durch den Funktionsdefinitionen mit globaler
Sichtbarkeit - geschrieben in unterschiedlichen Programmiersprachen - zur Quilt-Funktionenbibliothek hinzugefügt werden können;
•
zum anderen ein Mechanismus, der den Benutzer beim Verhindern von Endlosschleifen bei
rekursiven Funktionen unterstützt Quantoren.
3.4.7
Seite 14
Quantoren
Für manche Anwendungen sind Ausdrücke nötig, die feststellen, ob ein Element existiert oder
ob alle Elemente einer bestimmten Kategorie einer Bedingung genügen. Hierfür stellt QUILT
den existentiellen Quantor SOME sowie den universellen Quantor EVERY zur Verfügung. Die
nachfolgenden Beispiele illustrieren die Wirkungsweise dieser Operatoren:
Beispiel:
Finde alle Buchtitel, bei denen im gleichen Absatz "Segeln" oder "Windsurfen" vorkommt:
FOR $b in //Buch
WHERE SOME $p in $b/Absatz SATISFIES
contains ($p, "Segeln") AND
contains ($p, "Windsurfen")
RETURN $b/Titel
Beispiel:
Finde alle Buchtitel, bei denen in jedem Absatz "Segeln" vorkommt:
FOR $b in //Buch
WHERE EVERY $p in $b/Absatz SATISFIES
contains ($p, "Segeln")
RETURN $b/Titel
3.4.8
Zur Vereinfachung von Anfragen, die dieselben Ausdrücke an mehreren Stellen nutzen, bietet
Quilt die Bindung eines Ausdrucks an eine Variable an. Das Binden ähnelt dem LET-Satz eines
FLWR-Ausdrucks. Eine gebundene Variable kann außerhalb eines FLWR-Ausdrucks benutzt
werden, wenn sie von dem Wort EVAL gefolgt wird.
Eine gebundene Variable kann beispielsweise in Verbindung mit einem Elementkonstruktor
eingesetzt werden, um Teile eines existierenden Elements zu kopieren.
Beispiel:
Zuvor wurde die Variable $e an ein Element mit numerischem Inhalt gebunden. Es wird ein neues Element konstruiert mit demselben Namen und denselben Attributen wie das Element $e und mit dem doppelten numerischen Inhalt wie beim Element $e. Im Beispiel sind name(element) und number(element)
Funktionen der Quilt-Kernbibliothek. name(element) liefert den Namen des Elements und
number(element) den numerischen Inhalt des Elements.
LET $tagname := name($e)
EVAL
<$tagname>
$e/@*, -- Übernahme der Attribute vom Element $e
2 * number($e)
</$tagname>
3.5
Seite 15
Datenbankanfragen
In vielen Fällen können SQL-Anfragen direkt in Quilt-Anfragen übersetzt werden, indem SQLAnfrageblöcke auf FLWR-Ausdrücke abgebildet werden.
Beispiel:
Eine Tabelle Produkt mit Produktnummer und Beschreibung einer relationalen Datenbank kann beispielsweise in XML durch
<Produkt>
<Produkttupel>
<Produktnummer>
<Beschreibung>
dargestellt werden.
Alle Produktnummern von Zylindern werden dann mit folgender Anfrage gefunden:
SQL:
Quilt:
SELECT Produktnummer
FROM Produkt
WHERE Beschreibung LIKE 'Zylinder'
ORDER BY Produktnummer;
FOR $p IN document("Produkt.xml")//Produkttupel
WHERE contains ($p/Beschreibung, "Zylinder")
RETURN $p/Produktnummer SORTBY (.)
-- Sortierung nach dem aktuellen Knoten
3.5.1
Grouping
Viele relationale Datenbankanfragen gruppieren Daten und wenden Aggregationsfunktionen auf
diese Gruppen an. In SQL wird das durch die Verwendung von GROUP-BY- und HAVING-Zusätzen erreicht. Die Aufgabe des HAVING-Satzes in SQL wird in Quilt durch einen geeigneten
WHERE-Satz übernommen. Das Gruppieren wird in Quilt durch einen Elementkonstruktor im
RETURN-Satz des FLWR-Ausdrucks erreicht. Der Wert des so erzeugten Elements definiert die
Gruppierung.
3.5.2
Joins
Bei Joins unterscheidet man zwischen "inner join" und "outer join". Ein "inner join" liefert nur
Informationen, die in allen Tabellen vorkommen, die beim Join beteiligt sind.
Ein "outer join" hingegen liefert Informationen von einer oder mehreren der beteiligten Tabellen,
einschließlich der Zeilen, die keine entsprechende Zeile in der verknüpften Tabelle haben. Anstelle der fehlenden Teile werden vom relationalen Datenbanksystem Werte zurückgegeben,
die in XML durch leere Elemente oder das Fehlen der Elemente dargestellt werden können.
Quilt kennt auch einen UNION-Operator, der dem UNION-Operator in SQL entspricht.
3.5.3
Views
Mit Quilt können strukturierte XML-Views auf die Tabellen der relationalen Datenbank erstellt
werden.
3.6
3.6.1
Seite 16
Zusammenfassung
Binden von
Variablen und
Verwenden der
gebundenen
Variablen beim
Erstellen neuer
Strukturen
RANGEPrädikat
und InfixOperatoren
BEFORE
und AFTER
Idee für FLWRAusdruck und
der Subqueries,
Aggregationsfunktionen und
distinct-Funktion
XML-QL
PfadAusdrücke
und
Funktionenbibliothek
XQL
SQL
Idee der
Subqueries
XPATH
1.0
OQL
QUILT
Lorel
YATL
NEU:
Dereferenzierungsoperator
FILTER-Operator
Einfluss
Übernahme von Features
Für die Anfragesprache Quilt existiert eine formlose Syntax. Die formale Definition der
Syntax und der Semantik von Quilt ist noch in Arbeit.
3.6.2
Seite 17
Bewertung
Die W3C XML Query Working Group hat Forderungen nach einer Anfragesyntax gestellt, die
vom Menschen lesbar ist und gleichzeitig auf einer XML-Anfragesyntax basiert. Quilt wird der
ersten dieser Forderungen gerecht. Es hat sich gezeigt, dass es für einige Anwendungen hilfreich wäre, wenn eine alternative, XML-basierte Syntax für Quilt zur Verfügung stehen würde,
ohne dass die Grundkonzepte von Quilt dafür geändert würden.
Meiner Meinung nach erfüllt Quilt die Anforderungen an eine universelle Anfragesprache, denn
è
è
è
è
è
Quilt ist so flexibel wie XML
erhält eine gegebene Ordnung und Hierarchie
verfügt über die üblichen Datenbankanfragen
kann alle in XML vorhandenen Strukturen von Informationen behandeln
kann mit Hilfe des FLWR-Ausdrucks Informationen umstrukturieren
Auch die Ziele, die sich die Arbeitsgruppe gesetzt hat, wurden erreicht, denn
è Quilt ist eine kleine Sprache
è die Anfragen sind kurz, aber lesbar
è Quilt kann eigenständige XML-Dokumente, Fragmente von XML-Dokumenten oder Ansammlungen von XML-Dokumenten behandeln und ist somit flexibel genug, um ein breites
Spektrum vom XML-Informationsquellen bearbeiten zu können
Bei Quilt gibt es allerdings noch offene Punkte wie
•
•
einen Erweiterungsmechanismus, durch den Funktionsdefinitonen mit globaler Sichtbarkeit geschrieben in unterschiedlichen Programmiersprachen - zur Quilt-Funktionenbibliothek hinzugefügt werden können.
einen Mechanismus, der dem Benutzer beim Verhindern von Endlosschleifen bei rekursiven
Funktionen unterstützt.
Folglich ist Quilt ein guter Ansatz, aber noch nicht die optimale Lösung für eine Anfragesprache.
Dennoch kann sie dazu beitragen, das Potential von XML als universelles Medium für den
Datenaustausch auszuschöpfen.
Seite 18
4. Die Anfragesprache XQuery
4.1
Auch für XQuery 1.0 gelten die bereits bei Quilt beschriebenen Anforderungen der W3C XML
Query Working Group an eine universelle Anfragesprache.
Die W3C XML Query Working Group fordert zum einen, dass die Syntax der Anfragesprache
vom Menschen lesbar und zum anderen, dass die Anfragesyntax auf XML basiert. XQuery 1.0
soll ebenfalls die erste Forderung erfüllen.
Eine Arbeitsgruppe aus Mitgliedern der W3C XML Query Working Group und der XSL Working
Group hat sich der Aufgabe angenommen, die Sprache XQuery 1.0 zu entwerfen. Die Arbeitsgruppe besteht aus Scott Boag und Don Chamberlin von IBM, Mary Fernandez von AT&T,
Daniela Florescu, Jonathan Robie von Software AG, Jérôme Siméon von Bell Labs und Mugur
Stefanescu von Concentric Visions.
Von der Arbeitsgruppe wurden folgende Ziele gesteckt:
•
•
•
XQuery soll eine kleine, flexible und leicht implementierbare Sprache sein.
Die Anfragen von XQuery sollen knapp und dennoch gut verständlich sein.
XQuery soll sowohl für Anfragen an Datenbanken als auch an Dokumente geeignet sein.
Da die Sprache noch nicht vollständig definiert ist, sind immer noch Änderungen an ihrem Aufbau möglich. Bei [2] handelt es sich um ein Arbeitspapier der Arbeitsgruppe.
4.2
XQuery 1.0 stammt von der Anfragesprache Quilt ab, die wie bereits gezeigt auf Features von
XPath 1.0, XQL, XML-QL, SQL und OQL zurückgreift. Die Arbeitsgruppe, die sich mit XQuery
befasst hat, ist auch verantwortlich für XPath 2.0. XPath 2.0 stammt ab von XPath 1.0 und
XQuery 1.0. Deshalb findet man sehr viele Übereinstimmungen zwischen XPath 2.0 und
XQuery 1.0. Man kann sagen, dass XQuery 1.0 die Anfragesprache XPath 2.0 als Untermenge
enthält.
XQuery ist eine stark typisierte Sprache. Beim Abarbeiten durchläuft eine Anfrage eine statische Typisierungsphase und eine dynamische Auswertungsphase. Der Typ, der bei dynamischen Auswertung zustande kommt, ist garantiert eine Instanz des Typs, der bei der statischen
Typisierung festgelegt wurde. Der Benutzer kann auf Wunsch die statische Typisierung überspringen.
XQuery ist eine funktionale Sprache, die es erlaubt, Ausdrücke beliebig zu schachteln.
XQuery unterscheidet Groß-/Kleinschreibung. Alle Schlüsselwörter in XQuery benutzen Kleinbuchstaben.
Grundbaustein von XQuery ist der Ausdruck. Der Wert eines Ausdrucks ist immer eine Sequenz. Eine Sequenz ist eine geordnete Menge von null oder mehr Elementen. Ein Element ist
entweder ein einfacher Wert oder ein Knoten. Ein einfacher Wert besteht aus einem Wert, aus
dem Wertebereich der primitiven Datentypen, die im XML-Schema beschrieben sind. Zusätzlich
enthält er eine Referenz auf eine Schema-Komponente, die den Typ beschreibt. Ein Knoten
entspricht einem der sieben Knotentypen, die im XQuery-1.0- und XPath-2.0-Datenmodell ([3])
beschrieben sind.
4.3
Seite 19
Die Ein-/Ausgabestruktur von XQuery 1.0
XQuery 1.0 kann diesselben Quellen wie Quilt bearbeiten.
4.4
Ausdrücke in XQuery 1.0
Bei der Anfragesprache XQuery 1.0 gibt es folgende Arten von Ausdrücken:
•
•
•
•
•
•
•
•
•
Primäre Ausdrücke
Pfad-Ausdrücke
Konstruktoren
FLWR-Ausdrücke
Bedingte Ausdrücke
Funktionen
Quantoren
In XQuery ist der Kontext eines Ausdrucks wichtig. Dieser besteht aus allen Informationen, die
dessen Ergebnis beeinflussen können. Diese Informationen sind aufgeteilt in zwei Kategorien:
-
Statischer Kontext
Auswertungskontext
Der statische Kontext umfasst alle Informationen, die während der statischen Analyse des Ausdrucks verfügbar sind. Diese Informationen dienen der Entscheidung, ob der Ausdruck einen
statischen Fehler enthält. In XQuery werden die Informationen des statischen Kontext durch
Deklarationen im Query Prolog - wird später beschrieben - bereitgestellt.
Der Auswertungskontext umfasst alle Informationen, die zum Auswertungszeitpunkt zur Verfügung stehen. Der Auswertungskontext besteht somit aus allen Teilen des statischen Kontexts
sowie folgenden zusätzlichen Teilen:
-
Fokus: Kontexteinheit, Kontextgröße, Kontextposition und Kontextdokument
Dynamische Variablen (stehen in Bezug zu den gleichnamigen in-scope-Variablen)
Aktuelles Datum und aktuelle Zeit (behält ihren Wert während der Ausführung einer Abfrage
bei)
Die Kontexteinheit ist die Einheit, die momentan bearbeitet wird. Das ist entweder ein einfacher
Wert oder ein Knoten - auch Kontextknoten genannt. Die Kontexteinheit wird durch den Ausdruck "." zurückgegeben.
Die Kontextgröße ist die Anzahl der Einheiten einer Sequenz, die aktuell bearbeitet wird. Ihr
Wert ist immer eine ganze Zahl größer als null und wird vom Ausdruck last() zurückgegeben.
Die Kontextposition ist die Position der Kontexteinheit innerhalb der Sequenz von Einheiten, die
momentan abgearbeitet werden. Ihr Wert ist eine ganze Zahl größer als null und wird vom Ausdruck position() zurückgeliefert. Die Kontextposition ist immer kleiner oder gleich der Kontextgröße.
Das Kontextdokument ist das Dokument das momentan bearbeitet wird. Sein Wert ist ein Knoten, der immer ein Dokumentknoten ist. Das Kontextdokument erhält man mittels des Ausdrucks "/" und es wird implizit als Basis für jeden absoluten Pfad-Ausdruck sowie als Eingabe
für bestimmte Funktionen wie xf:id verwendet.
4.4.1
Seite 20
Primäre Ausdrücke
Primäre Ausdrücke sind die Grundbestandteile von XQuery. Zu ihnen zählen:
•
•
•
•
•
Literale: XQuery kennt Stringliterale und numerische Literale
Variablen
Geklammerte Ausdrücke
Funktionsaufrufe
Kommentare
4.4.2
Pfad-Ausdrücke
Ein Pfad-Ausdruck lokalisiert Knoten innerhalb eines Baumes und liefert eine Sequenz unterschiedlicher Knoten in der Dokumentreihenfolge zurück. Ein Pfad-Ausdruck wird immer unter
Berücksichtigung des Auswertungskontexts ausgewertet.
Es gibt relative und absolute Pfad-Ausdrücke. Ein relativer Pfad-Ausdruck besteht aus einem
oder mehreren Schritten getrennt durch "/" oder "//". Ein absoluter Pfad-Ausdruck beginnt mit "/"
oder "//" gefolgt von einem relativen Pfad-Ausdruck. Beginnt der Pfad mit "/", dann ist der relative Pfad-Ausdruck optional.
Ein Achsenschritt fängt beim Kontextknoten an und verläuft entlang der Knoten, die vom Kontextknoten aus über eine vordefinierte Achse erreichbar sind und wählt dabei einige Untermengen der erreichbaren Knoten aus. Ein Achsenschritt besteht aus
-
Knotentest
Schrittvermerk
Achse ("Bewegungsrichtung")
Ein Knotentest ist ein Test des Knotens entweder auf seinen Namen oder seine Knotenart. Beispielsweise ist der Test text() wahr für jeden Textknoten.
Schrittvermerke sind entweder Eigenschaften, die zum Ausfiltern von Knoten einer Sequenz
verwendet werden oder Dereferenzen, die Attributknoten mit Typ "Referenz" auf die Knoten
abbilden, die sie referenzieren.
Es gibt Vorwärts- und Rückwärtsachsen. Bei XQuery existieren folgende Vorwärtsachsen:
-
child
descendant
attribute
self
descendent-or-self
sowie die Rückwärtsachse parent.
Ein Schritt kann auch nur ein allgemeiner Schritt sein, das ist ein primärer Ausdruck gefolgt von
einem oder mehreren Schrittvermerken. Das Ergebnis eines allgemeinen Schritts ist eine Knotensequenz, geändert durch jeden Schrittvermerk. Liefert der primäre Ausdruck einen Wert, der
kein Knoten ist, tritt ein Fehler auf.
Beispiel:
Ausgehend davon, dass der Wurzelknoten des Dokuments "schloesser.xml" der Kontextknoten ist, finde
die Abbildung mit der Unterschrift "Heidelberger Schloss" im 5. Kapitel des Dokuments.
child::Kapitel[5]//child::Abbildung[Unterschrift = "Heidelberger Schloss"]
Seite 21
Beispiel:
Ausgehend davon, dass der Wurzelknoten des Dokuments "schloesser.xml" der Kontextknoten ist, finde
alle Abbildung in den Kapiteln 2 bis 5 des Dokuments.
child::Kapitel[2 to 5]//child::Abbildung
Auch bei XQuery gibt es einen Dereferenzierungsoperator, hier dargestellt durch die Zeichen
"=>". Dieser Operator wird auf Knotensequenzen angewandt, indem er Element- und/oder Attributknoten abbildet auf die Knoten, die sie referenzieren. Aus einer Knotensequenz können nur
Element- oder Attributknoten dereferenziert werden, deren Inhalt vom Typ IDREF oder IDREFS
ist.
Beispiel:
Finde alle Unterschriften von Abbildungen, die durch <figref>-Elemente im Kapitel mit dem Titel =
"Baden-Württemberg" des Dokuments "schloesser.xml" referenziert werden. Sei der Wurzelknoten des
Dokuments wiederum der Kontextknoten:
child::Kapitel[Titel = "Baden-Württemberg"]//child::figref/attribute::refid=>Unterschrift
4.4.3
Konstruktoren
XQuery stellt Konstruktoren für Elemente, Attribute, CDATA-Sektionen, Abarbeitungsanweisungen und Kommentare zur Verfügung. Eine Spezialform eines Konstruktors - berechnender Element- oder Attributkonstruktor genannt - wird verwendet, um ein Element oder ein Attribut mit
einem berechneten Namen zu erstellen.
Die Wirkung des Elementkonstruktors soll nun ein Beispiel veranschaulichen. Der Name von
Start- und Endtag muss übereinstimmen. Sind Name, Attribute und Inhalt des Elements durchweg Konstanten, erscheint der Elementkonstruktor in XML-Standard-Notation. Werden hingegen Ausdrücke verwendet, so müssen diese in geschwungene Klammern gesetzt werden, um
sie von Textliteralen zu unterscheiden. Eine geschwungene Klammer im Text selbst wird durch
Verdoppelung erzeugt.
Beispiel:
<Mitarbeiter Personalnummer = {$pid}>
<Name> { $name } </Name>
<Gehaltsgruppe> { $gg } </Gehaltsgruppe>
</Mitarbeiter>
Beim berechnenden Element- oder Attributkonstruktor wird dem Namen des Knotens das
Schlüsselwort element oder attribut vorangestellt. Dieses Feature kann beispielsweise dazu
eingesetzt werden, Element- und Attributnamen in verschiedene Sprachen zu übersetzen.
Beispiel:
element Mitarbeiter
{
attribute Personalnummer {178713},
element Name
{
element Vorname { "Martina" },
element Nachname { "Welt" }
}
}
4.4.4
Seite 22
FLWR-Ausdrücke
Bei XQuery gelten für die FLWR-Ausdrücke ähnliche Regeln wie bei Quilt. Einziger Unterschied
ist, dass die verwendeten Ausdrücke in geschwungene Klammern gesetzt werden müssen.
4.4.5
Der Sortierungsausdruck sortby(...) ermöglicht es, die Reihenfolge der Einheiten einer Sequenz
zu bestimmen. Es können auch mehrere Ordnungskriterien - getrennt durch Komma - angegeben werden, die dann von links nach rechts bearbeitet werden. Bei jedem Kriterium kann aufsteigend (Voreinstellung) und absteigend sortiert werden.
Sortierungsausdrücke können auf die Ergebnisse von FLWR-Ausdrücken oder Pfad-Ausdrücken angewendet werden. Bei Pfad-Ausdrücken ist allerdings Vorsicht angebracht. Es kann
passieren, dass der Sortierungsausdruck zu einem unerwarteten Ergebnis führt, weil Pfad-Ausdrücke immer eine Knotensequenz in Dokumentreihenfolge zurückliefern.
4.4.6
Auch bei XQuery gibt es Schachtelungen von geklammerten Ausdrücken, die üblichen arithmetischen und logischen Operatoren sowie die Mengenoperatoren UNION, INTERSECT und
EXCEPT.
XQuery verfügt über vier verschiedene Vergleichsausdrücke:
-
Wertvergleich (eq, ne, lt, le gt, ge)
allgemeiner Vergleich (=, !=, <, <=, > >=)
Knotenvergleich (==, !==)
Ordnungsvergleich (<<, >>, precedes, follows)
Der Wertvergleich dient dem Vergleich von einzelnen Werten.
Beispiel:
$book1/author eq "Güting"
Der Vergleich ergibt nur dann wahr, wenn $book1 ein einziges author-Subelement hat und dessen Wert
"Güting" ist.
Beim allgemeinen Vergleich können die Operanden Sequenzen beliebiger Länge sein.
Beispiel:
$book1/author = "Güting"
Der Vergleich ergibt wahr, wenn der Wert irgendeines author-Subelement von $book1 gleich "Güting" ist.
Der Knotenvergleich ist nur dann wahr, wenn beide Seiten genau zum selben Knoten ausgewertet werden.
Der Ordnungsvergleich in XQuery ersetzt die Infix-Operatoren BEFORE und AFTER von Quilt.
Der Vergleich ist nur dann wahr, wenn der Knoten auf der linken Seite in der Dokumentreihenfolge vor bzw. nach dem Knoten auf der rechten Seite auftritt.
Bei XQuery existiert ebenfalls ein FILTER-Operator. Er hat jedoch im Gegensatz zu Quilt keine
zwei sondern nur einen Parameter, der ein beliebiger Ausdruck sein kann. Die FILTER-Funktion
ist Bestandteil der XQuery-Kernbibliothek.
Seite 23
Sie wertet ihr Argument aus und liefert eine Kopie der ausgewählten Knoten. Dabei werden die
Beziehungen zwischen den Knoten erhalten.
Ergebnis von $doc (vor dem Filtern):
C
B
C
C
B
A
B
A
C
C
A
A
B
B
Ergebnis von filter($doc//(A | B)):
B
A
A
4.4.7
B
B
B
A
A
B
Bedingte Ausdrücke
XQuery unterstützt den bekannten bedingten Ausdruck basierend auf den Schlüsselwörtern if,
then und else. Der Testausdruck, der dem Schlüsselwort if folgt, muss allerdings in runden
Klammern angegeben werden.
4.4.8
Funktionen
Zusätzlich zu den eingebauten Funktionen kann der Benutzer von XQuery eigene Funktionen
definieren. Eine Funktion darf rekursiv sein - sogar wechselseitig rekursiv. Zur Definition einer
Funktion werden deren Namen, Namen und Datentypen der Parameter sowie der Datentyp des
Ergebnisses festgelegt. Der Name einer Funktion kann mit einem Namensraum angegeben
werden. Mit dem Befehl
default function namespace = ...
wird ein Standard-Namensraum festgelegt und der Namensraum kann dann bei der Funktion
weggelassen werden. Wenn ein Parameter nur mit Namen und ohne Typ deklariert wurde, akzeptiert er Argumente jeden beliebigen Typs. Wird der RETURN-Satz weggelassen, kann ein
Wert von beliebigem Typ zurückgegeben werden.
Seite 24
Beispiel:
Die Funktion berechnet die maximale Tiefe des Dokuments "wegenetz.xml":
define function depth (element $e) returns xs:integer
{
{-- Ein leeres Element hat die Tiefe 1, --}
{-- ansonsten addiere 1 zur max. Tiefe der Nachfolger --}
if (empty($e/*)) then 1
else max (for $C in $e/* return depth($c)) + 1
}
depth(document("wegenetz.xml"))
Das Überladen benutzerdefinierter Funktionen ist in XQuery momentan nicht möglich. Die Arbeitsgruppe ist jedoch der Auffassung, dass dieses Feature bei zukünftigen Versionen von
XQuery berücksichtigt werden sollte. Einige der built-in-Funktionen sind hingegen überladen
wie beispielsweise die string-Funktion von XPath.
4.4.9
Quantoren
XQuery kennt die Quantoren SOME und EVERY, für die das bei Quilt Beschriebene gilt.
4.5
Datenbankanfragen
Die Umsetzung von Datenbankanfragen funktioniert wie bereits bei Quilt gezeigt.
4.6
Query Prolog
Der Query Prolog umfasst eine Reihe von Deklarationen und Definitionen, die die Abarbeitung
der Anfragen festlegen. Im Query Prolog können Namensräume definiert, Definitonen von
Schemata importiert und Funktionen definiert werden.
Die Namensraumdeklaration definiert einen Namensraum-Präfix und verbindet ihn mit einem
Namensraum-URI, indem das (Präfix, URI)-Paar zur Menge der in-scope-Namensräume hinzugefügt wird. Die Namensraumdeklaration ist gültig für den Rest der Anfrage, in der sie gemacht
wurde.
4.7
4.7.1
Zusammenfassung
Durch die Abstammung von Quilt verfügt XQuery 1.0 über alle Features von Quilt. Viele Ausdrücke lauten und funktionieren gleich, andere sind vorhanden, tragen aber eine andere Bezeichnung und funktionieren nur ähnlich wie beispielsweise die Infix-Operatoren BEFORE und
AFTER bei Quilt und der Ordnungsvergleich mittels "precedes" und "follows" bei XQuery 1.0.
Dadurch, dass XPath 2.0 als Untermenge in XQuery 1.0 enthalten ist, verfügt XQuery 1.0 auch
über alle Features von XPath 2.0.
Unterschiede zu Quilt sind, dass
•
•
XQuery eine stark typisierte Sprache ist, bei der alle Anfragen eine statische Typisierungsphase und eine dynamische Auswertungsphase durchlaufen
XQuery zwischen Groß-/Kleinschreibung unterscheidet
•
•
•
•
•
•
•
•
•
Seite 25
die Syntax von XQuery etwas anders aussieht
XQuery von Sequenzen spricht, wo bei Quilt von Tupellisten die Rede ist
bei XQuery Ausdrücke in geschwungene Klammern gesetzt werden müssen, damit man sie
von Textliteralen unterscheiden kann
es bei XQuery zusätzlich einen berechnenden Element- und Attributkonstruktor gibt
der FILTER-Operator bei XQuery nur einen anstatt zwei Parameter hat
der Ordnungsvergleich bei XQuery mittels "precedes" und "follows" erfolgt anstelle der InfixOperatoren BEFORE und AFTER von Quilt
bei XQuery der Testausdruck beim bedingten Ausdruck in runde Klammern gesetzt werden
muss
XQuery über einen Query Prolog verfügt, in dem beispielsweise Namensraumdeklarationen
zu finden sind
in XQuery der Standard-Namensraum für Funktionen geändert werden kann
Dieser Beitrag basiert auf dem Stand Dezember 2001 von [2]. Zwischenzeitlich gibt es einen
Stand April 2002, der neue Details beim Typsystem enthält und zudem die Element- und
Attributkonstruktoren etwas detaillierter beschreibt.
4.7.2
Bewertung
Die W3C XML Query Working Group hat eine Forderung nach einer Anfragesyntax gestellt, die
vom Menschen lesbar ist. Dieser Forderung wird XQuery 1.0 gerecht.
Meiner Meinung nach erfüllt auch XQuery 1.0 die Anforderungen an eine universelle Anfragesprache, denn
è
è
è
è
è
XQuery 1.0 ist so flexibel wie XML
erhält eine gegebene Ordnung und Hierarchie
verfügt über die üblichen Datenbankanfragen
kann alle in XML vorhandenen Strukturen von Informationen behandeln
kann mit Hilfe des FLWR-Ausdrucks Informationen umstrukturieren
Auch die Ziele, die sich die Arbeitsgruppe gesetzt hat, wurden erreicht, denn
è XQuery ist eine kleine, flexible und leicht implementierbare Sprache
è die Anfragen sind knapp und trotzdem gut verständlich
è XQuery 1.0 ist sowohl für Anfragen an Datenbanken als auch an Dokumente geeignet
Meines Erachtens wurde mit dem Entwurf von XQuery 1.0 ein weiterer Fortschritt hinsichtlich
einer universellen Anfragesprache erzielt. Aber XQuery 1.0 ist noch in Arbeit und es sind noch
etliche Punkte offen. Sicherlich wird XQuery noch vervollständigt und verbessert werden oder
vielleicht sogar durch einen weiteren neuen Ansatz überholt werden.
Seite 26
5. Quellenangaben
[1]
D. D. Chamberlin, J. Robie und D. Florescu. Quilt: An XML Query Language for
Heterogeneous Data Sources. WebDB (Informal Proceedings), 53 - 62, 2000, http://wwwrodin.inria.fr/Fmbrepubs_dana.html
[2]
S. Boag, D. Chamberlin, M. F. Fernandez, D. Florescu, J. Robie, J. Siméon und M.
Stefanescu. XQuery 1.0: An XML Query Language. W3C Working Draft, 2001,
http://www.w3.org/TR/xquery/
=> Hier handelt es sich um ein Arbeitspapier, das jederzeit aktualisiert, ergänzt oder
überholt werden kann, da noch eine Menge offener Fragen zu klären sind.
[3]
World Wide Web Consortium. XML Query Data Model. W3C Working Draft, May 11,
2000, http://www.w3.org/TR/query-datamodel/
[4]
J. Clark und S. DeRose. XML Path Language (XPath), Version 1.0. W3C Recommendation 1999, http://www.w3.org/TR/xpath
LG Praktische Informatik IV
Seminar zum Thema
XML und Datenbanken
Sommersemester 2002
Speicherung von
XML-Dokumenten in
relationalen Datenbanksystemen I
Basierend auf:
Meike Klettke und Holger Meyer,
XML and Object-Relational Database Systems – Enhancing Structural Mappings Based On Statistics
Albrecht Schmidt, Martin Kersten, Menzo Windhouwer und Florian Waas,
Efficient Relational Storage and Retrieval of XML Documents
Elke Pillis
Matrikelnummer 4798449
elke.pillis@fernuni-hagen.de
Elke Pillis
Seite:
1
Inhaltsverzeichnis
1
Einleitung und Grundbegriffe _________________________________________2
2
Das XML-Modell MONET _____________________________________________3
3
2.1
Ein Beispiel __________________________________________________________ 3
2.2
Datenstruktur und Algebra ______________________________________________ 3
2.3
Das XML-Modell MONET ________________________________________________ 4
2.4
Anfragen an das XML-Modell MONET _____________________________________ 6
Hybride Datenbanken________________________________________________7
3.1
Objekt-Relationale Abbildungsverfahren __________________________________ 7
3.2
Hybride Datenbanken definieren ________________________________________ 10
4
Zusammenfassung_________________________________________________13
5
Thesen___________________________________________________________13
Anhang A: Abbildungsverzeichnis _______________________________________14
Anhang B: Literatur und Links __________________________________________14
B 1 Basisliteratur __________________________________________________________ 14
B 2 Links im Internet _______________________________________________________ 14
B 3 Weiterführende Literatur ________________________________________________ 14
Anhang C: Vortragsfolien ______________________________________________15
Seminar 01912 XML und Datenbanken
Thema: Relationale DBMS I
Elke Pillis
Seite:
2
1 Einleitung und Grundbegriffe
XML ist zu dem Standard Format des World Wide Web avanciert. Allerdings gibt es wenige Werkzeuge,
die XML verarbeiten können. Es wäre von Vorteil, die XML-Daten in relationale Datenbanken zu speichern.
Da es sich bei XML um semi-strukturierte Daten handelt, können diese nicht ohne Weiteres in eine
Datenbank gespeichert werden.
Abbildung 1.1 zeigt, wo genau das Problem liegt, wenn ein XML Dokument in eine Datenbank gespeichert
werden soll.
?
Abbildung 1-1 Problem bei der Speicherung eines Baumes in eine Datenbank
Das wohl größte Problem bei der Speicherung eines XML-Dokumentes in einer Datenbank ist die Struktur
des XML Dokumentes. Wie in der Abbildung 1-1 zu sehen ist, weist das XML Dokument eine Baumstruktur
auf, die sich sehr schwer auf das relationale Modell übertragen lässt. In der folgenden Tabelle sind die
wesentlichen Unterschiede der beiden Konzepte, Baumstruktur und RDBMS zusammengefasst:
XML
Daten in hierarchischer Struktur
Knoten haben Elemente oder Attributwerte
Elemente können verschachtelt werden
Elemente sind geordnet
Elemente können rekursiv sein
Schema optional
Direkte Speicherung von XML-Dokumenten
Abfrage mit XML-Standards
RDBMS
Daten in vielen Tabellen
Zellen haben einen Wert
Atomare Zellenwerte
Zeilen/Spalten Ordnung definiert
Wenig Unterstützung für rekursive Elemente
Schema wird benötigt
Häufig Joins zum Finden nötig
Abfragen mit XML-erweitertem SQL
Abbildung 1-2 Vergleich XML und RDBMS (Software AG)
Folgendes Statement unterstreicht das Problem der Abbildung von XML-Dokumenten auf RDBMS ziemlich
deutlich.
Using RDBMS for storing hierarchically structured XML documents is as efficient as disassembling
car for parking it in the garage in the evening and then reassembling it every morning before
leaving for work.
Diese Aussage stammt von der Firma Software AG. Diese vertreibt den TAMINO XML-Server. Sicherlich
ist die Software AG interessiert, ihren TAMINO XML-Server zu verkaufen. Trotzdem findet man diese
AUSSAGE in der TAMINO Werbebroschüre.
Im Folgenden werden zwei Ansätze vorgestellt, wie man trotzdem XML-Dokumente in RDBMS speichern
kann. Will man also XML-Daten in RDBMS speichern, müssen diese erst normalisiert werden. Dies macht
bei datenorientierten XML-Dokumenten noch Sinn, bei dokumentorientierten XML-Dokumenten wird es
jedoch zum Problem. Im Folgenden stelle ich den MONET Ansatz vor zur Speicherung von
datenorientierten XML-Dokumenten und den hybriden Ansatz zur Speicherung von dokumentorientierten
XML-Dokumenten. Bei beiden Ansätzen wird eine DTD vorausgesetzt. Natürlich ist es möglich, auch ohne
DTD zu arbeiten, denn aus den Dokumenten kann auch eine Struktur ermittelt werden. Jedoch ist es sehr
schwierig gleich strukturierte XML Dokumente zu identifizieren, das optimale gemeinsame Schema
herauszukristallisieren, und ev. Änderungen am Schema sind sehr schwer zu verarbeiten.
Elke Pillis
Seite:
2 Das XML-Modell MONET
2.1 Ein Beispiel
Zunächst einmal ein Beispiel
<Hotelverzeichnis>
<Hotel LfdNr = „1“>
<Name>Hotel Sonnenschein</Name>
<Adresse>Zum Sonnenberg 7</Adresse>
<Gastronomie>Restaurant</Gastronomie>
</Hotel>
<Name>Hotel Zum Berg</Name>
<Adresse>Am Bergrand 30</Adresse>
<Gastronomie>Cafe</Gastronomie>
</Hotel>
</Hotelverzeichnis>
XML Dokumente werden üblicherweise durch einen Syntaxbaum dargestellt. Der passende Syntaxbaum
zu dem o.a. Beispiel sieht dann folgendermaßen aus, wobei hier bereits jedem Element ein eindeutiger
Object Identifier oi zugewiesen wird.
Hotelverzeichnis, o1
„1“
LfdNr
Name, o3
Hotel, o2
Adresse, o5
CDATA, o4 CDATA, o6
string
„Hotel
Sonnenschein“
string
Hotel, o9
Gastronomie, o7
CDATA, o8
string
„Zum
„Restaurant“
Sonnenberg 7“
Name, o10
LfdNr
„2“
Adresse, o12 Gastronomie,
o14
CDATA, o11 CDATA, o13
string
„Hotel Zum Berg“
string
„Am
Bergrand 30“
CDATA, o15
string
„Cafe“
Abbildung 2-1 Syntaxbaum
2.2 Datenstruktur und Algebra
Ein XML Dokument wird formal folgendermaßen definiert:
Definition: Ein XML Dokument d = (V,E,r,labelE,labelA,rank) ist ein Wurzelbaum mit Knoten V und Kanten
E ⊆ VxV und dem Wurzelknoten r ∈ V. Die Funktion labelE : V → string weist Knoten Labels zu, z.B.
Elemente. labelA : V → string x string weist Knoten ein Paar von zwei Strings zu, nämlich Attribute und
deren Werte. Analog für integer Attribute. In diesem Fall wird dem Knoten ein Paar string x integer
zugewiesen.
3
Elke Pillis
Seite:
Die Basis des XML-Modells MONET sind Assoziationen und Pfadsummen. Daher erst die Definition der
beiden Begriffe:
Definition: Ein Paar (o,x) ∈ oid x (oid ∪ string ∪ int) nennt man Assoziation
Die verschiedenen Arten von Assoziationen beschreiben die unterschiedlichen Bereiche im Syntaxbaum.
Assoziationen vom Typ oid x oid beschreiben Kanten, Attribute sind als Assoziation oid x string modelliert.
oid ist hierbei die Menge der Object Identifier.
Definition: Für einen Knoten o im Syntaxbaum wird die Sequenz der Label entlang des Pfades (Knoten
und Kanten Labels) vom Wurzelknoten r zum Knoten o als path(o) bezeichnet.
Nehmen wir den Knoten o7. Der Pfad ist dann
e
Hotelverzeichnis
Hotel e Gastronomie,
der zugehörige Wert „Restaurant“ hat den Pfad
Hotelverzeichnis e Hotel e
Gastronomie e cdata a
string
e
a
wobei
Kanten zu einem Element bezeichnen und
Kanten zu einem Attribut.
Pfade beschreiben die relative Lage des Knotens im Graphen zum Wurzelknoten und path(o) beschreibt
den Typen der Assoziation (r, o). Die Menge aller Pfade in einem Dokument ist dann die Pfadsumme.
2.3 Das XML-Modell MONET
Zur Erinnerung: Ziel ist es, das XML-Dokument in ein relationales Schema zu packen. Das XML-Modell
MONET geht dabei von dem Syntaxbaum aus und generiert für jede Eltern-Kind Beziehung eine Tabelle,
eine weitere für alle Element labels, usw. Die Anzahl der Tabellen wird natürlich sehr groß. Zur
Rekonstruktion muss das DBMS mit sehr vielen Joins umgehen können. Jedoch ist die Abfrage auf solch
große Datenmengen sehr ineffektiv. Deshalb werden Relationen, die der gleichen syntaktischen Definition
gehorchen, in dieselbe binäre Relation gepackt.
Formal lässt sich das MONET Modell folgendermaßen definieren:
Gegeben ist ein XML Dokument d. Die MONET Transformation ist ein 4-er Tupel Mt(d) = (r, R, A, T)
R = Menge aller binären Relationen, die alle Assoziationen zwischen Knoten beinhalten
A = Menge aller binären Relationen, die alle Assoziationen zwischen Knoten und deren Attributwerte
beinhalten, einschließlich Werte
T = Menge der binären Relationen mit allen Paaren von Knoten und deren Rang
Hier wird path genutzt, um die Assoziationen zu gruppieren.
4
Elke Pillis
Unser Beispiel:
HotelVZ
HotelVZ
HotelVZ
e
e
e
HotelVZ
Hotel
HotelVZ
Hotel
HotelVZ
Hotel
e
e
e
e
e
e
HotelVZ
Hotel
Name
HotelVZ
Hotel
Adresse
HotelVZ
Hotel
Gastronomie
HotelVZ
e
e
e
e
e
e
e
e
e
e
HotelVZ
Hotel
Name
CDATA
Hotel
Adresse
CDATA
Hotel
Gastronomie
CDATA
Hotel
e
Hotel
Name
CDATA
String
Adresse
CDATA
String
Gastronomie
CDATA
String
LfdNr
e
e
e
a
e
e
e
e
a
a
Seite: 5
= {<o1,o2>,<o1,o9>}
= {<o2,o3>,<o9,o10>}
= {<o3,o4>,<o10,o11>}
= {<o4,“Hotel Sonnenschein“>,o11,“Hotel zum Berg“>}
= {o2,o5>,<o9,o12>}
= {<o5,o6>,o12,o13>}
= {<o6,“Zum Sonnenberg 7“>,<o13,“Am Bergrand 30“>}
= {<o2,o7>,<o9,o14>}
= {<o7,o8>,<o14,o15>}
= {<o8,“Restaurant“>,<o15,“Cafe“>}
= {<o2,“1“>,<o9,“2“>}
Exemplarisch wird im Folgenden der Aufbau der Tabellen für die Gastronomie dargestellt:
Hotel ve rz eic hnis -> Hotel
o1
o1
o2
o9
Hotel ve rz eic hnis -> Hotel -> Gas tronom ie
o2
o9
o3
o10
Hotel ve rz eic hnis -> Hotel -> Gas tronom ie -> CDA TA
o3
o10
o4
o11
Hotel ve rz eic hnis -> Hotel -> G as tronom ie -> CDA TA -> S tring
Insgesamt entstehen bei der Transformation unseres Beispiels 11 Tabellen.
Abbildung 2-2 Tabellenaufbau
o4
o11
„Res taurant“
„Ca fe“
Elke Pillis
Seite: 6
2.4 Anfragen an das XML-Modell MONET
Nicht nur das Speichern der XML-Daten verdient Aufmerksamkeit, sondern auch das Wiederfinden der
Daten. Anhand des folgenden Beispiels soll die Vorgehensweise erläutert werden:
Gesucht werden alle Hotels, die als Gastronomie ein Restaurant haben:
select p
e
from Hotelverzeichnis
Hotel p
e
e
p
Gastronomie
CDATA a
where a = „Restaurant“
Die Anfrage ist in 2 Blöcke unterteilt, im Spezifikationsblock werden die benutzten Relationen deklariert und
im sog. Constraint-Block werden die Bedingungen angegeben. Um Pfadausdrücke auswerten zu können,
benötigt man zwei Variablentypen: zum einen die Mengendefinitionen, in unserem Falle p, zum anderen
die Assoziationen, in unserem Falle a.
Intern erhalten wir in unserem Beispiel:
p = {o2,o9}
assoc(p → a) = {(o2,“Restaurant), (o9,“Cafe“)}
Aus dieser Menge werden dann die Elemente selektiert, die den Bedingungen entsprechen, also o2.
Elke Pillis
Seite:
7
3 Hybride Datenbanken
Im vorigen Kapitel haben wir gesehen, wie ein XML Dokument offensichtlich auf eine Datenbankstruktur
abgebildet wurde. Allerdings gibt es XML Dokumente, bei denen das zu einem sehr großen
Datenbankschema führen würde, und die Tabellen hätten nur wenige Einträge. Bei solchen Dokumenten
macht es Sinn, Teile des XML Dokumentes als solches in die Datenbank zu speichern. Der Datenbank Typ
XML sollte dann Pfadauswertungen erlauben und vor allen Dingen Volltextrecherche. Im Folgenden wird
ein Abbildungsverfahren vorgestellt, basierend auf die DTD und auf Statistiken.
Die Statistiken werden ermittelt anhand einer Auswahl von Beispiel XML Dokumenten und Vorkenntnisse
über die Anfragen an die XML Dokumente.
Im Folgenden wird beschrieben, wie ein XML Dokument in eine objekt-relationale Datenbank gespeichert
werden kann, welche den Datentyp XML unterstützt. Der erste Schritt wird das bereits bekannte Abbilden
eines XML-Dokumentes basierend auf einer DTD sein, dann wird der Datentyp XML in die objektrelationale Datenbank mit eingebracht und der letzte Schritt ist ein Algorithmus, mit Hilfe dessen man
bestimmen kann, welches Attribut oder Element als Datenbankattribute abgelegt wird oder als Attribute
vom Typ XML. Der Datentyp XML fügt dem RDBMS folgende Funktionalität hinzu:
XML Fragmente speichern
Auswertung von Pfad Ausdrücken
Volltext Recherche
3.1 Objekt-Relationale Abbildungsverfahren
Die in der DTD definierte Struktur eines XML-Dokuments wird für die Schemabildung herangezogen. Auf
diese Weise ist eine natürliche Abbildung eines XML-Dokuments in eine Datenbank gewährleistet.
In der DTD werden das Hauptelement und seine Subelemente definiert. Besitzen die
Subelemente keine Struktur, so werden sie im folgenden als einfache Elemente bezeichnet. Abgespeichert
werden diese als einfache Relation.
</Hotel>
Dieses Beispiel sieht dann in der Datenbank so aus:
OID
Name
Adresse
Gastronomie
1
2
Hotel Sonnenschein
...
Zum Sonnenberg 7
Restaurant
Abbildung 3-1 Relation Hotel
Elemente in XML-Dokumenten können in verschiedenen Anordnungen auftreten. Folgen, Gruppierungen,
Alternativen und Quantifizierungen sind möglich.
Wie bildet man Alternativen ab?
DTD
<!ELEMENT Hotel (Name, (Adresse | (Stadt, Straße)), Gastronomie)>
<!ELEMENT Name (#PCDATA)>
<!ELEMENT Adresse (#PCDATA)>
<!ELEMENT Stadt (#PCDATA)>
<!ELEMENT Straße (#PCDATA)>
<!ELEMENT Gastronomie (#PCDATA)>
Die Elemente Stadt und Straße treten immer zusammen auf. Außerdem kann entweder das Element
Adresse oder das Elementenpaar (Stadt, Straße) in einem Dokument auftreten.
Elke Pillis
Seite:
</Hotel>
<Name>Hotel Am Hang</Name>
<Stadt>Skigaudi</Stadt>
<Straße>Skihaserl 5</Straße>
<Gastronomie>Apres Ski Bar</Gastronomie>
</Hotel>
OID
Name
Adresse
Stadt
Straße
Gastronomie
1
3
Hotel Sonnenschein
Hotel Am Hang
Zum Sonnenberg 7
NULL
NULL
Skigaudi
NULL
Skihaserl 5
Restaurant
Apres Ski Bar
Abbildung 3-2 Relation Hotel mit Alternativen
Die Abbildung der Relation führt zu NULL-Werten. Jedoch kann auch eine andere Art der Speicherung
gewählt werden, indem Attribute, die NULL-Werte enthalten, in eine eigene Relation ausgelagert werden:
OID
Name
Gastronomie
1
3
Hotel Sonnenschein
Hotel Am Hang
Restaurant
Apres Ski Bar
F_OID
Adresse
1
Zum Sonnenberg 7
Abbildung 3-4 Relation Hotel.Adresse
F_OID
Stadt
Straße
3
Skigaudi
Skihaserl 5
Abbildung 3-5 Relation Hotel.Stadt.Straße
Eine Anfrage nach dem Attribut Adresse wird nun nicht mehr ganz einfach, da es nicht mehr in der
Relation Hotel enthalten ist. Hier muss der ‚Umweg’ über die Systemtabellen des DBMS gegangen
werden.
Alternativ könnte man noch eine Spalte in die Relation Hotel einführen, die den Verweis auf die Relation
Hotel.Adresse oder Hotel.Stadt.Straße beinhaltet. Ebenso könnte man die Alternativen als Typ XML
abspeichern.
Set-of und list-of bieten die Möglichkeit XML-Elemente mit Quantifizierer ’*’ und ’+’abzubilden. Set-of wird
benutzt, wenn einfach nur eine Menge dargestellt werden muss, list-of wird benutzt, wenn die Reihenfolge
relevant ist.
Einige Elemente können komplexe Strukturen aufweisen. OR Datenbanken bieten mit Hilfe des
Konstruktors type-of die Möglichkeit, diese Struktur zu definieren und als Attribut darzustellen.
In unserem Beispiel Hotel kann die Adresse eine komplexe Struktur enthalten:
8
Elke Pillis
Seite:
<Adresse>
<Straße>Zum Sonnenberg 7</Straße>
<PLZ>99999</PLZ>
<Ort>Sonnentaldorf</Ort>
</Adresse>
</Hotel>
OID
1
Name
Straße
Hotel Sonnenschein Zum Sonnenberg 7
Adresse
PLZ
99999
Gastronomie
Ort
Sonnentaldorf
Restaurant
Zusätzlich gibt es noch einen mixed-content type, der es erlaubt, mehrere Elemente als Text
zusammenzufassen, oder Elemente und Volltext zu mischen oder Elemente einzubetten. Ein praktisches
Beispiel:
Die Produktbeschreibung eines IKEA-Stuhls:

NICK Klappstuhl
aus lackiertem Metall/Kunststoff. 44x46 cm, 77 cm hoch. Sitzhöhe 43
cm.
DM 15.65

Solche Elemente werden als XML-Typ in der OR-Datenbank abgelegt.
9
Elke Pillis
Seite:
10
3.2 Hybride Datenbanken definieren
Um eine optimale hybride Datenbank zu definieren, wird folgender Algorithmus herangezogen:
1. Schritt: Syntaxgraphen des XML Dokumentes aufbauen
2. Schritt: Für jedes Element/Attribut des Graphen wird die Gewichtung w ermittelt.
3. Schritt: Damit wird aus dem Graphen die Struktur der HYBRID Datenbank abgeleitet
1. Schritt: hier wird der Graph anhand der DTD aufgebaut, hauptsächlich um die hierarchische Struktur
des Dokumentes darzustellen
Wir erweitern unser Beispiel:
<!ELEMENT Zimmerverzeichnis> (Hotel | Pension | Privatzimmer)*>
<! – Hotel -- >
<!ELEMENT Hotel (Name, Adresse, Gastronomie, Abendessen_fuer)>
<!ATTLIST LfdNr id ID #REQUIRED>
<!ELEMENT Name (#PCDATA)>
<!ELEMENT Adresse (#PCDATA)>
<!ELEMENT Gastronomie (#PCDATA)>
<! – Pension -- >
<!ELEMENT Pension (Name, Adresse, Fruehstueck, Anzahl_Zimmer)>
<!ELEMENT Anzahl_Zimmer (#PCDATA)>
<! – Privatzimmer -- >
<!ELEMENT Privatzimmer (Name, Adresse, Fruehstueck)>
<!ELEMENT Fruehstueck (#PCDATA)>
</Zimmerverzeichnis>
Zimmerverzeichnis
Pension
Hotel
Name
Adresse
Gastronomie
Abendessen_fuer
Name
Adresse
Privatzimmer
Anzahl
Zimmer
Name
Adresse
Frühstück
Abbildung 3-8 Graph zum Zimmerverzeichnis
Gemeinsame Ausdrücke aus der DTD (Name; Adresse) werden dupliziert.
2. Schritt: In diesem Schritt werden die Gewichte bestimmt, die die Wichtigkeit der Elemente für jeden
Knoten im Graphen widerspiegeln. Dafür werden drei Arten von Informationen benötigt.
Zum Einen wird die DTD Struktur benötigt. Jedoch liefert diese nicht alle Informationen für eine optimale
Datenbankstruktur. Dieselbe DTD kann für mehrere Dokumente in unterschiedlichen Applikationen auf
unterschiedliche Weise benutzt werden. Deshalb wird der Inhalt des DTD Dokumentes auch in Betracht
gezogen. Jedoch kommt noch das Verhalten des Benutzers dazu. Es muss berücksichtigt werden, wonach
der Benutzer „für gewöhnlich“ sucht. Also werden als drittes Informationen über Abfragen in die
Berechnung mit einbezogen.
Elke Pillis
wD
wQ
Seite:
11
wD - das abgeleitete Gewicht aus den XML Daten
wQ - das abgeleitete Gewicht aus den Abfragen
wS - das abgeleitete Gewicht aus der DTD
wS
Abbildung 3-9 Knoten Gewichte
Diese drei Gewichte haben dann aber noch unterschiedliche Gewichtung pro Knoten:
1
1
1
w =  * wS +  * wD +  * wQ
2
4
4
Wie werden nun die einzelnen Gewichte ermittelt?
wS wird folgendermaßen ermittelt:
WS =
SH + SA + SQ

3
wobei SH die Position in der Hierarchie ist
Anzahl Vorgänger
SH = 1 - 
Höhe des Baumes
SA stellt die Ausnutzung der Alternativen in der DTD dar. Und zwar wird ermittelt, wie viele Elemente in der
DTD als Alternativen definiert sind. SQ stellt die Ausnutzung der Quantifizierer (?, +, *) dar.
Manche Informationen können jedoch nicht der DTD entnommen werden. Z.B. wie oft letztendlich
Quantifizierer, wie ‚?’ oder ‚*’ im XML-Dokument auftauchen. Aus diesem Grunde wird das Gewicht W D
folgendermaßen berechnet:
DA
WD =  =
DT
Anzahl der Dokumente, die dieses Element enthalten

Gesamtanzahl der Dokumente
Des Weiteren können wir aus der DTD nicht ermitteln, welche Daten oft abgefragt werden und welche nicht
so interessant sind. Dies kann nur aus Erfahrungswerten gewonnen werden. Diese müssen im Vorfeld
ermittelt werden. Wie man an diese Informationen kommt? Entweder es existieren bereits Systeme mit
ähnlichem Inhalt, so dass diese herangezogen werden können oder es wird eine Benutzerumfrage
gestartet, wonach demnächst gesucht werden soll. Daraus kann dann die Information ermittelt werden, wie
oft ein Element in einer Abfrage herangezogen wird in Relation zur Häufigkeit des Auftretens des
Elementes im XML Dokument.
Elke Pillis
QA
WQ =  =
QT
Seite:
12
Anzahl der Abfragen, die dieses Element enthalten

Gesamtanzahl der Abfragen
Zusammenfassend kann dann die Gesamtgewichtung eines Knotens ermittelt werden:
DA
1 QA
 (SH + SA + SQ) +   +  
6
4 DT
4 QT
1
W=
1
Im 3. Schritt wird nun die Struktur der Datenbank definiert. Als Erstes muss ein Limit bestimmt werden, ab
dem die Elemente nicht mehr als Attribute dargestellt werden, sondern als XML Attribute. Dieser Grenzwert
kann die Detaillierung der Datenbank deutlich beeinflussen. Er wird natürlich deutlich von der Antwortzeit
der Abfragesprache der Datenbank beeinflusst. Als XML Attribute werden dann alle Knoten und deren
Unterknoten dargestellt, die unter dem Grenzwert liegen. Der Rest wird als ganz normales
Datenbankattribut dargestellt.
Elke Pillis
Seite:
13
4 Zusammenfassung
Semistrukturierte Daten gewinnen in Applikationen immer mehr an Bedeutung. XML wird hierbei
insbesondere zum Datenaustausch verwendet. Daher spielt die Speicherung von XML Dokumenten in
Datenbanken eine große Rolle. Es stellte sich heraus, dass relationale Datenbanken nur eine
unbefriedigende Möglichkeit zur Darstellung von XML Dokumenten bieten.
Objekt-Relationale Datenbanken erlauben eine größere Flexibilität, die dem Entwickler größeren
Wirkungsraum einräumen. OR Datenbanken erlauben eine natürlichere Abbildung von XML Dokumenten
als relationale Datenbanken das zulassen.
Wir haben nun zwei Abbildungsmethoden gesehen: einmal um ein XML-Dokument in eine relationale und
einmal in eine objekt-relationale Datenbank abzubilden.
Die Darstellung eines XML-Dokumentes in einer relationalen Datenbank anhand des MONET Modells als
binäre Relationen führt jedoch zu einer Menge Tabellen, langen Ladezeiten und hohen Abfragekosten.
Um die Struktur einer objekt-relationalen Datenbank zu definieren wurde ein einfacher Algorithmus
vorgestellt. Datenbanken wie DB2 mit XML-Erweiterung sind in der Lage die XML-Daten aus dem
Dokument in die Datenbank abzubilden, wobei der Benutzer die Abbildung der XML-Elemente in die
Datenbankattribute definieren muss. Andererseits sind diese Datenbanken auch in der Lage das XMLDokument ohne Änderung als XML-Attribut zu speichern. Der vorgestellte Algorithmus könnte hierbei
helfen, eine Alternative zu wählen.
5 Thesen
Zum Abschluss noch ein paar Thesen:
1. Applikationen werden zunehmend mit semistrukturierten Daten umgehen müssen.
2. XML wird sich als Format für den Datenaustausch etablieren.
3. Einige Bestandteile semistrukturierter Daten lassen sich nur schwierig oder gar nicht auf
Relationenattribute ausrichten.
4. Ein kleines Datenbankschema mit der geringsten möglichen Anzahl Relationen führt zu schwach
gefüllten Relationen.
5. Die Vermeidung schwach gefüllter Relationen bedeutet ein großes Datenbankschema mit vielen
Relationen und damit eine Streuung der Daten.
6. Durch die Natur semistrukturierter Daten entstehen zwangsläufig NULL-Werte in der Datenbank.
7. Objekt-relationale Datenbankmanagementsysteme sind dafür besser geeignet als relationale
Datenbankmanagementsysteme.
8. Ein hybrider Ansatz zur Speicherung von semistrukturierten Daten stellt den besten Kompromiss
dar.
Elke Pillis
Seite:
14
Anhang A: Abbildungsverzeichnis
Abbildung 1-1 Problem bei der Speicherung eines Baumes in eine Datenbank .....................................................................2
Abbildung 1-2 Vergleich XML und RDBMS (Software AG) ...............................................................................................2
Abbildung 2-1 Syntaxbaum ......................................................................................................................................3
Abbildung 2-2 Tabellenaufbau ..................................................................................................................................5
Abbildung 3-1 Relation Hotel ....................................................................................................................................7
Abbildung 3-2 Relation Hotel mit Alternativen ...............................................................................................................8
Abbildung 3-4 Relation Hotel.Adresse .........................................................................................................................8
Abbildung 3-5 Relation Hotel.Stadt.Straße ...................................................................................................................8
Abbildung 3-6 Relation Hotel....................................................................................................................................9
Abbildung 3-8 Graph zum Zimmerverzeichnis .............................................................................................................10
Abbildung 3-9 Knoten Gewichte ..............................................................................................................................11
Anhang B: Literatur und Links
B 1 Basisliteratur
[1] Albrecht Schmidt, Martin Kersten, Menzo Windhouwer und Florian Waas, Efficient Relational Storage
and Retrieval of XML Documents
[2] Meike Klettke und Holger Meyer, XML and Object-Relational Database Systems – Enhancing Structural
Mappings Based On Statistics
B 2 Links im Internet
[3] www.b-es.de/uni/seminar/xml-abbildungen/ Stefan Huber, XML Abbildungen in relationale Datenbanken
B 3 Weiterführende Literatur
[4] Timm, Jens, Speicherung von XML-Dateien in Objekt-relationalen Datenbanken, Diplomarbeit
[5] Michaela Wenger, Stefan Vielgut, Speicherung von semistrukturierten Daten
Elke Pillis
Seite:
Anhang C: Vortragsfolien
15
Seminar 1912 "XML und Datenbanken"
Fernuniversität Hagen
Sommersemester 2002
Thema 9:
Speicherung von XML-Dokumenten in relationalen
Datenbanksystemen II
Name: Oliver Schmidt
Verwendete Artikel:
•
D. Florescu und D. Kossmann. A Performance Evaluation of Alternative Mapping Schemes for Storing XML Data in a Relational Database.
•
J. Shanmugasundaram, K. Tufte, C. Zhang, G. He, D. J. DeWitt und J. F.
Naughton. Relational Databases for Querying XML Documents: Limitations
and Opportunities.
Seite 1
Inhaltsverzeichnis:
1
Einleitung und Abgrenzung............................................................................ 3
2
Der Ansatz von Florescu/Kossmann ............................................................... 4
2.1
Der Kantenansatz („Edge Approach“)..................................................... 5
2.1.1
Der Kantenansatz mit Separaten Datenwert-Tabellen...................... 6
2.1.2
Der Kantenansatz mit Inlining......................................................... 7
2.2
Der Attributansatz („Attribute Approach“) ............................................. 7
2.3
Der Universelle-Tabelle-Ansatz („Universal Table Approach“) .............. 8
2.4
Der Normalisierte-Universelle-Tabelle-Ansatz („Normalized Universal
Table Approach“)............................................................................................... 8
2.5
3
Performance ........................................................................................... 9
Der Ansatz von Shanmugasundaram et al....................................................... 9
3.1
Die Basic Inlining Technik ..................................................................... 9
3.2
Die Shared Inlining Technik ..................................................................10
3.3
Die Hybrid Inlining Technik..................................................................10
4
Transformation der semistrukturierten Abfragen in SQL ...............................10
5
Vorteile und Vergleich der Ansätze...............................................................11
6
5.1
Vorteile und Probleme der vorgestellten Ansätze...................................11
5.2
Vorteile im Vergleich zu anderen Datenbanksystemen...........................11
Zusammenfassung.........................................................................................12
Abkürzungsverzeichnis
13
Literaturverzeichnis
14
Seite 2
1 Einleitung und Abgrenzung
Das XML-Format [BPSM00] wird als eines der heutigen und zukünftigen Standardformate für die Verarbeitung und den Austausch von Daten im Internet gesehen.
Bei diesem Format handelt es sich um semistrukturierte Daten, welche sich von
strukturierten Daten, wie man sie etwa in relationalen Datenbankschemata findet,
unterscheidet. Relationale bzw. objektrelationale Datenbanksysteme stellen heute
den Standardanwendungsfall für den Großteil der Datenspeicherung in der Praxis
dar. Daraus ergibt sich die Notwendigkeit nach Ansätzen zu suchen, wie XMLDaten in relationalen Systemen gespeichert werden können, um die in der Praxis
bestehenden hochperformanten relationalen Datenbanksysteme auch weiterhin nutzen zu können.
Die nachfolgenden Ausführungen behandeln die Speicherung von XMLDokumenten in relationalen Datenbanksystemen (im folgenden abgekürzt: RDBS).
Nicht dargestellt werden somit die Speicherung von XML-Dokumenten in objektrelationalen
Datenbanksystemen
unter
Verwendung
der
zusätzlichen
nicht-
relationalen Eigenschaften [Timm99], die Speicherung in objektorientierten Datenbanksystemen [ABK+00:427] [ScEC01:45] [CACS94], in Datenbanksystemen speziell für XML-Dokumente [FiKM01] [Schö01] [ScBi01:157] bzw. Datenbanksystemen für semistrukturierte Daten im allgemeinen [McAG+97] [LOTU02] sowie
ebenfalls nicht die Speicherung von XML-Dokumenten in sonstigen (teils historisch
veralteten) Datenspeicherungsansätzen.
Die vorliegende Darstellung umfasst dabei die Speicherung von XML-Dokumenten
und die Wiederherstellung des Original-XML-Dokuments aus dem relationalen
Datenbanksystem sowie die dabei auftretende Performance. Ebenfalls nicht dargestellt werden somit die Erstellung und Extrahierung von vorher nicht existenten
XML-Dokumenten aus einem relationalen bzw. objektrelationalen Datenbanksystem bzw. -schema [FeTS00] [CFI+00] [SSC+01].
Es existieren verschiedene theoretische Ansätze zur Speicherung von XMLDokumenten in relationalen Datenbanksystemen. Hier dargestellt werden die Speicherung nach Florescu/Kossmann [FlKo99a] und kurz die Speicherung nach ShanSeite 3
mugasundaram et al. [STZ+99], die ihrerseits jeweils mehrere verschiedene Ansätze
vorschlagen. Weitere Ansätze sind in [SYU99] [KlMe01] [SKWW01] zu finden.
2 Der Ansatz von Florescu/Kossmann
Der Ansatz von Florescu/Kossmann beruht auf Graphen. Dabei ist jedes XMLElement (Objekt) ein Knoten im Graphen. Die Kanten sind die Attribute, die Blätter
des Graphen die Datenwerte. Die Kanten unmittelbar vor den Blättern werden von
Florescu/Kossmann als Datenattribute bezeichnet.
Das folgende Beispiel aus Florescu/Kossmann [FlKo99a:5,7] soll dies verdeutlichen:
Seite 4
Die Abbildung in Relationen lässt sich nun anhand von zwei Dimensionen durchführen:
(1) Darstellung der Attribute und
(2) Darstellung der Datenwerte.
Florescu/Kossmann schlagen vier Ansätze für die erste Dimension vor und zwei
Ansätze für die zweite Dimension. Dabei lassen sich jeweils die vier Ansätze der
ersten Dimension mit jeweils beiden Ansätzen der zweiten Dimension kombinieren.
2.1 Der Kantenansatz („Edge Approach“)
Dieser Ansatz basiert auf der ersten Dimension, d.h. wie die Attribute dargestellt
werden. Dabei werden alle Attribute in einer einzigen Tabelle gespeichert. Diese
Tabelle enthält die Oids der XML-Quelle, die Oids des Zielelements, den Namen
des Attributs, ein Flag das darüber Auskunft gibt ob es sich um eine Inter-ElementReferenz handelt oder um den Verweis auf einen Datenwert, und eine ordinale
Nummer um ggf. wieder die richtige Reihenfolge der XML-Elemente herstellen zu
können. Die Tabelle hat damit die folgende Struktur, im folgenden dargestellt anhand eines Beispiels [FlKo99a:10]:
Edge(source, ordinal, name, flag, target)
Seite 5
Der Kantenansatz lässt sich nun mit den beiden Ansätzen der zweiten Dimension
kombinieren. Die zwei Ansätze der zweiten Dimension sind:
(1) Separate Datenwert-Tabellen und
(2) Inlining.
2.1.1 Der Kantenansatz mit Separaten Datenwert-Tabellen
Bei diesem Ansatz wird für jeden Datentyp der Datenwerte des XML-Dokuments
eine eigene Tabelle angelegt. Das folgende Beispiel aus [FlKo99a:13] verdeutlicht
dies:
Seite 6
Dabei ist die Struktur der Relationen die folgende:
Vtype(vid, value)
2.1.2 Der Kantenansatz mit Inlining
Bei diesem Ansatz werden alle Datenwerte und Attribute in den gleichen Tabellen
gespeichert. Demzufolge wird für jeden Datentyp eine eigene Spalte benötigt und
eine große Anzahl an NULL-Werten tritt auf. Das Flag wird nicht mehr benötigt.
2.2 Der Attributansatz („Attribute Approach“)
Bei diesem Ansatz der ersten Dimension werden alle Attribute mit dem selben Namen in jeweils eine Tabelle gespeichert. Demzufolge entstehen so viele AttributTabellen wie es Attributnamen im Original-XML-Dokument gibt. Jede AttributTabelle hat die folgende Struktur:
Aname(source, ordinal, flag, target)
Auch hier gilt, dass dieser Ansatz mit beiden Ansätzen der zweiten Dimension (Separate Datenwert-Tabellen, Inlining) kombiniert werden kann.
Seite 7
2.3 Der Universelle-Tabelle-Ansatz („Universal Table Approach“)
Bei diesem Ansatz werden alle Attribute des Original-XML-Dokuments in einer
einzigen universellen Tabelle gespeichert. Die Struktur der Tabelle sieht folgendermaßen aus:
Universal(source, ordinaln1, flagn1, targetn1, ordinaln2, flagn2, targetn2,
…, ordinalnk, flagnk, targetnk)
Auch hier gilt dass dieser Ansatz mit beiden Ansätzen der zweiten Dimension (Separate Datenwert-Tabellen, Inlining) kombiniert werden kann.
2.4 Der
Normalisierte-Universelle-Tabelle-Ansatz
(„Normalized
Universal Table Approach“)
Dieser Ansatz ist eine Variante des Universelle-Tabelle-Ansatzes, wobei MultiwertAttribute in separaten Overflow-Tabellen gespeichert werden. Für jeden AttributNamen des Original-XML-Dokuments wird somit eine separate Overflow-Tabelle
geschaffen. Dadurch ist in der Universellen Tabelle nur noch ein Datensatz pro
XML-Element vorhanden und die Tabelle ist normalisiert. Die Struktur der Tabellen sieht folgendermaßen aus:
UnivNorm(source, ordinaln1, flagn1, targetn1, ordinaln2, flagn2, targetn2,
…, ordinalnk, flagnk, targetnk)
Overflown1(source, ordinal, flag, target),
…
Overflownk(source, ordinal, flag, target).
Auch hier gilt dass dieser Ansatz mit beiden Ansätzen der zweiten Dimension (Separate Datenwert-Tabellen, Inlining) kombiniert werden kann.
Seite 8
2.5 Performance
Florescu/Kossmann untersuchen auch die Performance ihrer Vorschläge. Sie untersuchen dabei welchen Speicherplatz die Tabellen benötigen, die Transformationsund Speicherzeit vom XML-Dokument bis zu den fertigen Relationen, die Zeit um
das Original-XML-Dokument wiederherzustellen sowie die Laufzeiten von Abfragen und Update-Funktionen für die jeweils verschiedenen Ansätze. Die beste Performance weist dabei der Attributansatz mit Inlining auf.
3 Der Ansatz von Shanmugasundaram et al.
Shanmugasundaram et al. [STZ+99] untersuchen drei verschiedene Varianten:
-
(1) Basic Inlining Technik
-
(2) Shared Inlining Technik
-
(3) Hybrid Inlining Technik.
Dabei betrachten Sie die DTD. Problem ist dabei, dass die DTDs vereinfacht werden müssen, z.B. um komplexe Verschachtelungen und Fragmentierungen innerhalb der DTD zu umgehen.
3.1 Die Basic Inlining Technik
Die Basic Inlining Technik versucht das Problem zu lösen, indem sie möglichst
viele Subelemente in eine einzige Relation hereinnimmt („inlining“). Dabei wird für
jedes Element eine eigene Relation angelegt. Problem ist dabei, dass es trotzdem
vorkommen kann, dass für gleiche Elemente mehrere Relationen angelegt werden.
Seite 9
3.2 Die Shared Inlining Technik
Die Shared Inlining Technik versucht die Nachteile der Basic Inlining Technik zu
umgehen. Dabei werden die Elemente identifiziert, die bei der Basic Inlining Technik in verschiedenen Relationen angelegt sind und sie anschließend zu teilen indem
separate Relationen für diese Elemente angelegt werden.
3.3 Die Hybrid Inlining Technik
Die Hybrid Inlining Technik ist ähnlich zur Shared Inlining Technik nur mit dem
Unterschied, dass zusätzlich Elemente in die jeweilige Relation hereingenommen
werden.
4 Transformation der semistrukturierten Abfragen in
SQL
Für die Speicherung von XML-Dokumenten in relationalen Datenbanken ist es
notwendig die semistrukturierten Abfragesprachen in SQL zu transformieren, um
Tabellen anzulegen, mit Datenwerten zu füllen, upzudaten, zu löschen sowie auch
abzufragen um ggf. das Original-XML-Dokument wieder herstellen zu können.
Geeignet hierfür ist zum Beispiel XML-QL, welche es im Vergleich zu anderen
Sprachen auch ermöglicht Abfragen nach bestimmten Mustern zu erstellen
[FlKo99a:16]. Ein Beispiel für XML-QL ist das folgende [FlKo99a:8]:
Seite 10
5 Vorteile und Vergleich der Ansätze
5.1 Vorteile und Probleme der vorgestellten Ansätze
Der Ansatz von Florescu/Kossmann hat den Vorteil, dass er einfach ist. Es wird
ausschließlich das XML-Dokument betrachtet.
Nachteile hingegen sind, dass beim Ansatz von Florescu/Kossmann die Unterscheidung von Attributen und Subelementen verloren geht. Außerdem geht die Information über XML-Referenzen verloren. Die Autoren merken jedoch an, dass sich beides über zusätzlichen Aufwand lösen ließe. Ebenfalls nicht betrachtet wird die
DTD, womit diese Informationen nicht gespeichert werden können. Mit der Weiterentwicklung der XML-Schema in nächster Zeit und der möglichen Ablösung der
DTD durch andere Möglichkeiten wird dieser Nachteil jedoch ggf. wieder abgeschwächt. Shanmugasundaram et al. hingegen beziehen ihre Ansätze auf die DTD
womit dieser Ansatz umfassender ist.
5.2 Vorteile im Vergleich zu anderen Datenbanksystemen
Die RDBS sind ausgereift und skalierfähig, wohingegen spezielle XMLDatenbanksysteme insbesondere für die Speicherung großer Datenmengen noch
einige Zeit benötigen um ausgereifter zu werden. OODB hingegen sind insbesondere bei Abfragen aus großen Datenmengen noch verbesserungswürdig. Außerdem ist
zu beachten, dass sich in der betrieblichen Praxis viele IT-Experten mit RDBS auskennen und auf bestehende Systeme zurückgegriffen werden kann. Strukturierte
und unstrukturierte Daten können in RDBS koexistieren. Nachteil hingegen ist, dass
die RDBS gebaut wurden, um strukturierte Daten zu verwalten und nicht für semistrukturierte Daten. Im Vergleich zu anderen, speziellen XML-Datenbanken können
sich somit je nach verwendetem Ansatz und dem zu speichernden XML-Dokument
mehr oder weniger große Performance-Probleme ergeben wie sie in Florescu/Kossmann und Shanmugasundaram et al. beschrieben sind.
Seite 11
6 Zusammenfassung
Die vorliegende Ausarbeitung hat den Ansatz von Florescu/Kossmann zur Speicherung von XML-Dokumenten in relationalen Datenbanken vorgestellt. Ebenfalls
kurz betrachtet wurde ein zweiter Ansatz von Shanmugasundaram et al. Die Ansätze zeigen, dass relationale Systeme eine mögliche Speicherform zur Speicherung
von XML-Dokumenten sind. Dies ist insbesondere wichtig, um bestehende relationale Systeme und Kapazitäten nutzen zu können.
Seite 12
Abkürzungsverzeichnis:
DTD
Document Type Descriptors/Document Type Definition
Oid
Object ID
OODBS
Objektorientiertes Datenbanksystem
ORDBS
Objektrelationales Datenbanksystem
RDBS
Relationales Datenbanksystem
SQL
Structured Query Language
Vid
Value ID
XML
Extensible Markup Language
XML-QL
XML Query Language
Seite 13
Literaturverzeichnis:
[ABK+00]
R. Anderson, M. Birbeck, M. Kay, u.a. XML professionell. Bonn,
2000
[BPSM00]
T. Bray, J. Paoli, C. M. Sperberg-McQueen und E. Maler. Extensible
Markup Language (XML). Second Edition, W3C Recommendation,
2000
http://www.w3.org/TR/REC-xml
[CFI+00]
M. J. Carey, D. Florescu, Z. G. Ives, Y. Lu, J. Shanmugasundaram,
E. J. Shekita und S. N. Subramanian. XPERANTO: Publishing Object-Relational Data as XML. WebDB (Informal Proceedings), 105110, 2000
http://www.cs.cornell.edu/People/jai/pubs.html
[CACS94]
V. Christophides, S. Abiteboul, S. Cluet und M. Scholl. From structured documents to novel query facilities. Proc. of ACM SIGMOD
Conf. on Management of Data, 1994
[Ende01]
J. Enderle: XML in relationalen Datenbanken. Informatik Spektrum
24(6), 357-368, 2001
[FeTS00]
M. F. Fernandez, W. C. Tan und D. Suciu. SilkRoute: Trading Between Relations and XML. WWW9 / Computer Networks 33(1-6),
723-745, 2000
http://www.cs.washington.edu/homes/suciu/NodeInternal,sitegraph.g
enoid_2.html
[FiKM01]
T. Fiebig, C.-C. Kanne und G. Moerkotte. Natix - ein natives XMLDBMS. Datenbank-Spektrum 1 (2001), 5-13, 2001
[FlKo99a]
D. Florescu und D. Kossmann. A Performance Evaluation of Alternative Mapping Schemes for Storing XML Data in a Relational Database. INRIA Technical Report No. 3680, 1999,
http://www-rodin.inria.fr/Fmbrepubs_dana.html
[FlKo99b]
D. Florescu und D. Kossmann. Storing and Quering XML Data using
an RDMBS. IEEE Date Engineering Bulletin 22(3), 27-34, 1999
http://www.cs.washington.edu/homes/suciu/PAPERS/florescukossman.pdf
Seite 14
[KlMe01]
M. Klettke und H. Meyer. XML and Object-Relational Database
Systems - Enhancing Structural Mappings Based on Statictics. In: D.
Suciu und G. Vossen (Hrsg.): The World Wide Web and Databases:
selected Papers / Third International Workshop WebDB 2000, Dallas, TX, USA, May 18-19, 2000. S. 151-170, Berlin, 2001
http://wwwdb.informatik.uni-rostock.de/xml/
[LOTU02]
Lotus Notes.
http://www.lotusnotes.com/, 2002
[McAG+97] J. McHugh, S. Abiteboul, R. Goldmann, D. Quass und J. Widom.
Lore: A database management system for semistructured data. SIGMOD Record 26(3), 54-66, 1997
[ScBi01]
H. Schinzer und N. Bieber. Virtuell Integrierte Netzwerke und XML.
In: K. Turowski und K. J. Fellner (Hrsg.): XML in der betrieblichen
Praxis: Standards, Möglichkeiten, Praxisbeispiele. S. 151-167, Heidelberg, 2001
[ScEC01]
C. Schmauch, C. Ey und S. Closs. Content-Management: Speichertechniken und der Einsatz von Directory-Servern. In: K. Turowski
und K. J. Fellner (Hrsg.): XML in der betrieblichen Praxis: Standards, Möglichkeiten, Praxisbeispiele. S. 29-54, Heidelberg, 2001
[SKWW01] A. Schmidt, M. L. Kersten, M. Windhouwer und F. Waas. Efficient
Relational Storage and Retrieval of XML Documents. In: D. Suciu
und G. Vossen (Hrsg.): The World Wide Web and Databases: selected Papers / Third International Workshop WebDB 2000, Dallas,
TX, USA, May 18-19, 2000. S. 137-150, Berlin, 2001
http://www.cwi.nl/htbin/ins1/publications?request=papers
[Schö01]
H. Schöning. Tamino - A DBMS designed for XML. ICDE 2001,
149-154, 2001
[SSC+01]
J. Shanmugasundaram, E. J. Shekita, R. Barr, M. J. Carey, B. G.
Lindsay, H. Pirahesh und B. Reinwald: Efficiently Publishing Relational Data as XML documents. VLDB Journal 10(2-3), 133-154,
2001
http://www.cs.cornell.edu/People/jai/pubs.html
[STZ+99]
J. Shanmugasundaram, K. Tufte, C. Zhang, G. He, D. J. DeWitt und
Seite 15
J. F. Naughton. Relational Databases for Quering XML Documents:
Limitations and Opportunities. VLDB 1999, 302-314, 1999
http://www.cs.cornell.edu/People/jai/papers/RdbmsForXML.pdf
[SYU99]
T. Shimura, M. Yoshikawa und S. Uemura. Storage and Retrieval of
XML Documents using Object-Relational Databases.
http://citeseer.nj.nec.com/shimura99storage.html
[Timm99]
J. Timm. Speicherung von XML-Dateien in Objekt-relationalen Datenbanken. Diplomarbeit Universität Rostock, Fachbereich Informatik, 1999
http://wwwdb.informatik.uni-rostock.de/xml/sada/da-timm.html
Seite 16
Fachbereich Informatik
Prof. Güting
XML-Sichten auf relationale Datenbanken
Helmut Hüsges
basierend auf:
M. F. Fernandez, W. C. Tan und D. Suciu. SilkRoute: Trading Between Relations and
XML
M. J. Carey, D. Florescu, Z. G. Ives, Y. Lu, J. Shanmugasundaram, E. J. Shekita und S.
N. Subramanian: XPERANTO: Publishing Object-Relational Data as XML
J. Shanmugasundaram, E. J. Shekita, R. Barr, M. J. Carey, B. G. Lindsay, H. Pirahesh
und B. Reinwald: Efficiently Publishing Relational Data as XML documents
-2-
1 Motivation
Fast alle Datenbestände sind heutzutage in relationalen oder objekt-relationalen Datenbanken gespeichert. Andererseits setzt sich XML als universelles Datenaustauschformat
immer mehr durch.
Eine Möglichkeit, Datenbestände aus relationalen oder objekt-relationalen Datenbanken
für XML-basierte Anwendungen zugänglich zu machen, sind XML-Sichten. XML-Sichten
definieren auf den Daten einer Datenbank ein virtuelles XML-Dokument.
Die Daten können so dem Zugriff mit XML-Abfragesprachen zugänglich gemacht
und/oder einer von außen vorgegebenen DTD angepasst werden.
Zwei Punkte sind dabei besonders hervorzuheben:
XML-Sichten sind virtuelle XML-Dokumente und können mit XML-Abfragesprachen (bei
beiden im folgenden vorgestellten Systemen mit XML-QL) abgefragt werden
XML-Sichten sind virtuelle XML-Dokumente. Abfragen auf XML-Sichten werden von
den hier vorgestellten Systemen mit der Abfrage zur Sichtdefinition kombiniert. Diese
kombinierten Abfragen werden vom Datenbanksystem ausgewertet, was gegenüber
der Auswertung von Abfragen auf echten (materialisierten) XML-Dokumenten einen
erheblichen Performancevorsprung bedeutet.
Als Beispiel soll die in Abb. 1 dargestellte Datenbank mit Informationen über Klettergebiete dienen. Sie enthält neben Teilen, die veröffentlicht werden sollen in der Tabelle
"Begehung" auch Daten, die vor externen Benutzern verborgen bleiben sollen.Im folgenden wird gezeigt, wie Informationen aus dieser Datenbank mit den Middleware-Systemen
SilkRoute[1] und XPERANTO[2] als XML-Sicht (s. Abb. 2) entsprechend der in Abb. 3
gezeigten DTD zur Verfügung gestellt werden können. Die Abschnitte 2 und 3 erläutern
die Philosophie und die Architektur der beiden Systeme, Abschnitt 4 zeigt, wie jeweils
Sichten definiert werden. Abschnitt 5 behandelt den komplexesten Teil dieser
Programme, die effektive Zusammensetzung von Abfragen. Bevor in Abschnitt 7 die
Übersetzung in SQL-behandelt wird, erörtert Abschnitt 6 grundlegende Möglichkeiten
dieser Umsetzung und stellt kurz einen anderen Ansatz, nämlich die Definition von XMLSichten innerhalb einer Datenbank mit entsprechender Erweiterung von SQL dar. In
Abschnitt 8 wird kurz die Erzeugung des XML-Dokuments dargestellt, in Abschnitt 9 folgt
ein Vergleich der vorgestellten Systeme.
GebietID*
G1
Name
Gestein
Frankenjura Kalk
G2
Pfalz
Tabelle Gebiet
FelsID* GebietID
Sandstein
Name
kinderfreundlich
F1
G1
Student
nein
F2
G2
Heufels
ja
F3
G1
Tabelle Fels
Ankatalwand ja
-3RoutenID* FelsID
Name
Laenge Schwierigkeit Ausrichtung
R1
F3
Computerspiele 18
8
SW
R2
F3
Internet
18
9
SW
Simon
15
10
S
R3
F1
Tabelle Route
RoutenID*
R1
Datum
24.05.1998
R2
03.05.2001
Tabelle Begehung
Abb. 1: Tabellen der Datenbank Klettern
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE KLETTERGEBIET SYSTEM "klettergebiet.dtd">
<GEBIETE>
<Gebiet Name = "Frankenjura" Gestein= "Kalk">
<Fels Name="Student" kinderfreundlich = "nein">
<Route Name="Simon">
<Länge>15</ Länge>
<Schwierigkeit>10</ Schwierigkeit>
<Ausrichtung>S</Ausrichtung>
</Route>
</Fels>
<Fels Name="Ankatalwand" kinderfreundlich = "ja">
<Route Name="Computerspiele">
<Ausrichtung>SW</Ausrichtung>
</Route>
<Route Name="Internet">
<Ausrichtung>SW</Ausrichtung>
</Route>
</Fels>
</Gebiet>
<Gebiet Name = "Pfalz" Gestein= "Sandstein">
<Fels Name="Heufels" kinderfreundlich = "ja"/>
</Gebiet>
<GEBIETE>
Abb. 2: Klettergebiete : XML-Sicht auf die Daten der Datenbank Klettern
-4
<!ELEMENT GEBIETE (Gebiet*)>
<!ELEMENT Gebiet (Fels*)>
<!ATTLIST Gebiet Name CDATA #REQUIRED Gestein CDATA #REQUIRED>
<!ELEMENT Fels (Route*,Info?)>
<!ATTLIST Fels Name CDATA #REQUIRED kinderfreundlich (ja|nein)
#IMPLIED>
<!ELEMENT
<!ATTLIST
<!ELEMENT
<!ELEMENT
<!ELEMENT
Route (Länge, Schwierigkeit, Ausrichtung?, Info?)>
Route Name CDATA #REQUIRED>
Länge (#PCDATA)>
Schwierigkeit (#PCDATA)>
Ausrichtung (N|NO|O|SO|SW|W|NW) >
<!ELEMENT Info (#PCDATA)>
Abb.3: Eine mögliche DTD für die XML-Sicht auf die Daten der Datenbank Klettern
2 Philosophie
2.1 SilkRoute
SilkRoute ist in erster Linie dafür gedacht, Daten aus einer relationalen Datenbank auf
eine (möglicherweise von außen vorgegebene) DTD abzubilden und als XML-Sicht zur
Verfügung zu stellen. Als wesentliche Vorteile von SilkRoute gegenüber existierenden
Systemen werden in [1] hervorgehoben:
SilkRoute ist allgemein: die Daten aus einer relationalen Datenbank können auf eine
beliebige DTD abgebildet werden
SilkRoute ist dynamisch: die erzeugte XML-Sicht ist, wie oben bereits erwähnt, virtuell
und wird erst im Zusammenhang mit Benutzerabfragen materialisiert
SilkRoute ist effizient: für die Beantwortung der Benutzerabfragen wird das (schnelle)
zugrunde liegende Datenbanksystem genutzt
2.2 XPERANTO
Der Ansatz von XPERANTO ist ähnlich, aber umfassender. Zusätzlich zu den bei
SilkRoute genannten Punkten wird in [2] folgendes hervorgehoben
XPERANTO macht die Datenbestände auch ohne vorherige Abbildung auf eine DTD in
einer Standardsicht zugänglich.
XPERANTO ist rein XML-basiert, Sichtdefinition und Benutzerabfragen erfolgen in
einer XML-Abfragesprache
XPERANTO erlaubt nicht nur den Zugriff auf die Datenbestände der Datenbank, sondern auch auf Meta-Daten (Katalog-Information)
XPERANTO unterstützt auch den Zugriff auf objekt-relationale Datenbanken (SQL 99)
3 Architektur
Beide hier vorgestellten Systeme haben einen prinzipiell sehr ähnlichen Aufbau. Benutzeranfragen, die von außen (z.B. über's Internet) eingehen, werden zunächst im XML-QLParser geparst. Der Abfrage-Zusammensetzer (s. Kap. 5) erzeugt aus der Benutzeranfrage und einer vorgegebenen Sichtdefinition (s. Kap. 4) eine zusammengesetzte Anfrage
-5in einer systemspezifischen internen Sprache. Die zusammengesetzte Anfrage wird vom
Anfrage-Übersetzer (s. Kap. 7) in eine SQL-Anfrage übersetzt. Aus dem vom
Datenbanksystem gelieferten Ergebnis erzeugt der XML-Erzeuger (s. Kap. 8) ein XMLDokument, das an den Benutzer weitergegeben wird.
Anwendung
Sichtdefinition (RXL)
XML-Dokument
Abfrage(XML-QL)
XML-Schema
XML-QL Parser
Sicht-Definition
Sicht-Verwaltung
AbfrageZusammensetzer
KatalogInformation
AbfrageÜbersetzer
Abfrage(SQL)
beide Systeme
XMLErzeuger
XML-Schema
Erzeuger
XML/DB
Vermittler
XML-Template
Ergebnis (Tupel)
Datenbank
XPERANTO
SilkRoute
Abb. 4: Aufbau der Systeme zur Vermittlung zwischen XML und Datenbanken
Im Detail gibt es im Aufbau der beiden hier vorgestellten System einige Unterschiede:
Bei SilkRoute muss zunächst eine Sicht auf die Daten definiert werden, die festlegt,
welche Daten aus der Datenbank nach außen (d.h. für die Anwendung) sichtbar sind.
Diese wird zusammen mit der Benutzeranfrage in den Abfrage-Zusammensetzer eingespeist.
XPERANTO generiert automatisch eine Standard-XML-Sicht in Form eines XMLSchemas auf die Datenbank. Zusätzlich können weitere Sichten definiert werden, die in
einer Sicht-Verwaltung gespeichert werden. Diese Sichten werden auf der Grundlage
der Standard-XML-Sicht mit einer XML-Abfragesprache (zur Zeit XML-QL) definiert.
XPERANTO verwendet in mehreren Teilsystemen Katalog-Information aus der Datenbank: für die Definition der Standard-XML-Sicht, bei der Auswertung von Anfragen,
wenn sich diese (was bei SilkRoute nicht vorgesehen ist) auf Metadaten beziehen,
sowie für die Erzeugung des XML-Schemas.
-6XPERANTO erzeugt zusätzlich zum XML-Dokument ein XML-Schema. Hierzu dient das
Teilsystem XML-Schema-Erzeuger.
Der Anfrage-Übersetzer von SilkRoute erzeugt ein XML-Template für den XML-Erzeuger. Bei der Beschreibung von XPERANTO ist ein solches Template nicht erwähnt, in
irgendeiner ähnlichen Form muss der XML-Erzeuger aber auch dort erfahren, welche
Tags in welcher Reihenfolge eingefügt werden müssen.
4 Definition von Sichten
4.1 SilkRoute
Bei SilkRoute muss zunächst eine Sicht auf die Datenbank definiert werden, bevor Abfragen möglich sind. Für die Sichtdefinition wird eine eigene Sprache benutzt, RXL (Relational to XML transformation Language), die sich im wesentlichen aus der constructAnweisung von XML-QL und from ,where, sort by und/oder group by -Anweisungen
aus SQL zusammensetzt. Die Sichtdefinition für Klettergebiete aus Abb. 1 auf der Grundlage der DTD aus Abb 3. lautet dann:
from Gebiet $g
construct
<GEBIETE>
<Gebiet Name=$g.Name Gestein=$g.Gestein>
{
from Fels $f
where $f.GebietId = $g.GebietID
construct
<Fels Name = $f.Name kinderfreundlich=$f.kinderfreundlich>
{
from Route $r
where $r.FelsID = $f.FelsID
construct
<Route Name=$r.Name>
<Länge>$r.Laenge</>
<Ausrichtung>$r.Ausrichtung</>
<Schwierigkeit>$r.Schwierigkeit</>
</>
}
</>
}
</>
</>
Abb. 5: RXL-Sichtdefinition für die XML-Sicht aus Abb. 2
4.2 XPERANTO
XPERANTO stellt eine Standard-Sicht auf die Datenbank zur Verfügung. Deren Aufbau
wird mit Hilfe eines XML-Schemas beschreiben, das für das hier vorgestellte Beispiel so
aussieht:
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name ="gebietTupelType">
<element name= "GebietID" type="string"/>
<element name= "Name" type="string"/>
<element name= "Gestein" type="string"/>
</complexType>
-7-
<complexType name ="gebietSetType">
<element name= "gebietTupel" type="gebietTupelType"
maxOccurs="*"/>
</complexType>
<element name="gebiet" type="gebietSetType"/>
<complexType name ="felsTupelType">
<element name= "FelsID" type="string"/>
<element name= "GebietID" type="string"/>
<element name= "kinderfreundlich" type="bool"/>
</complexType>
<complexType name ="felsSetType">
<element name= "felsTupel" type="felsTupelType"
maxOccurs="*"/>
</complexType>
<element name="fels" type="felsSetType"/>
<complexType name ="routeTupelType">
<element name= "RoutenID" type="string"/>
<element name= "FelsID" type="string"/>
<element name= "Laenge" type="integer"/>
<element name= "Schwierigkeit" type="integer"/>
<element name= "Ausrichtung" type="string"/>
</complexType>
<complexType name ="routeSetType">
<element name= "routeTupel" type="routeTupelType"
maxOccurs="*"/>
</complexType>
<element name="route" type="routeSetType"/>
<complexType name ="begehungTupelType">
<element name= "RoutenID" type="string"/>
<element name= "Datum" type="date"/>
</complexType>
<complexType name ="begehungSetType"/>
<element name= "begehung" type="begehungTupelType"
maxOccurs="*"/>
</complexType>
<element name="begehung" type="begehungSetType"/>
</schema>
Abb. 5: Schema der von XPERANTO produzierten Standard-Sicht auf die Datenbank
-8Ausgehend von diesem Schema können nun direkt Anfragen in XML-QL formuliert werden. Die diesem Schema entsprechende XML-Sicht entspricht aber nicht der in Abb. 3
dargestellten DTD. Um Anfragen entsprechend dieser DTD zu ermöglichen, kann aufbauend auf die Standardsicht eine neue Sicht mit Hilfe von XML-QL definiert werden.
5 Zusammensetzung von Anfragen aus der Sichtdefinition und Benutzeranfragen
Beide Systeme führen aus Performancegründen nicht die Anfragen zur Sichtdefinition und
darauf aufbauende Benutzeranfragen getrennt aus, sondern verfügen über Algorithmen,
die hieraus neue (schneller zu beantwortende) Abfragen generieren. Performancevorteile
gegenüber der Nacheinanderausführung der Abfragen können sich z.B. ergeben aus:
dem Weglassen von Elementen, die in der Sichtdefinition, nicht aber in der Benutzeranfrage enthalten sind
der Ausnutzung von Indizes der zugrunde liegenden Datenbank, wenn in einer Benutzeranfrage nach einem eingeschränkten Wertebereich gefragt wird.
SilkRoute konstruiert aus einer Benutzeranfrage (in XML-QL) und der Sichtdefinition (in
RXL) mit Hilfe eines recht komplexen Algorithmus (Details in [1]) eine neue RXL-Abfrage.
Der Abfrage-Zusammensetzer von XPERANTO verfolgt das Ziel, komplexen Benutzeranfragen auf ebenfalls (möglicherweise) komplexen benutzerdefinierten Sichten eine möglichst einfache Anfrage auf der Standard-Sicht zurückzuführen.
Alle Abfragen werden zunächst in eine interne Repräsentation (XQGM XML Query Graph
Model) überführt. Diese interne Repräsentation ist eng angelehnt an QGM, die intere Repräsentation von SQL-Abfragen in IBM's DB2 Datenbanksystem.
6 Implementierungsalternativen für das Erzeugen von XML-Dokumenten
aus Daten in relationalen Datenbanken
In den folgenden Abschnitten werden verschiedene Strategien zur Erzeugung von XMLDokumenten aus dem Inhalt von relationalen Datenbanken betrachtet. Abschnitt 6.1 beschäftigt sich mit der Frage, welches Programm (das Datenbanksystem oder ein externes
System) diese Umsetzung vornimmt. Die folgenden Abschnitte diskutieren die Reihenfolge der bei der Umsetzung erforderlichen Schritte
Gewinnung der Daten
Strukturierung der Daten
Einfügen der Tags
Hierbei werden nur die Ansätze näher erläutert, bei denen ein Teil der Arbeit außerhalb
des Datenbanksystems stattfindet. Diese Ansätze erfordern keine Erweiterung von SQL
und können somit von Middleware wie SilkRoute oder XPERANTO in Zusammenarbeit mit
einer beliebigen relationalen Datenbank genutzt werden.
6.1 Komplett innerhalb oder teilweise außerhalb der Datenbank
Mit einigen Erweiterungen von SQL könnten relationale Datenbanken direkt XML-Dokumente erzeugen.
Die Abfrage entsprechend der in Abb. 3 gezeigten DTD hätte dabei folgende Form:
Select GEBIET(Gebiet.Name,Gebiet.Gestein
(Select XMLAGG(FELS(Fels.Name,Fels.kinderfreundlich)
(Select XMLAGG(ROUTE(Route.Name, Route.Länge,
-9Route.Schwierigkeit, Route.Ausrichtung))
From Route
Where Route.FelsID = Fels.FelsID
)
From Fels
Where Fels.GebietID = Gebiet.GebietID)
From Gebiet
Abb.7: Abfrage mit SQL-Erweiterung für die Sichtdefinition innerhalb der Datenbank
Dies ist eine geschachtelte SQL-Abfrage, die die XML-Konstruktoren GEBIET(), FELS()
und ROUTE() benutzt und die XMLAGG-Funktion benutzt, um als Ergebnis ein XML-Dokument zu erhalten. XML-Konstruktoren sind Funktionen, die aus den übergebenen
Parametern (Daten der Datenbank und XML-Fragmente) XML-Fragmente erzeugen. Die
XMLAGG-Funktion reiht die von einem XML-Konstruktor für ein Tupel einer Tabelle
gelieferten XML-Fragmente aneinander. Als Beispiel für einen XML-Konstruktor zeigt
Abb. 8 den Konstruktor GEBIET(). Dieser erfordert als Parameter Name und Gestein
eines Klettergebiets sowie eine XML-Liste von (zugehörigen) Felsen. Diese wird vom
Konstruktor FELS(), der die Daten für einen einzelnen Felsen erzeugt, zusammen mit der
XMLAGG-Funktion, die XML-Fragmente der einzelnen Felsen aggregiert, geliefert.
Analog liefert der XML-Konstruktor ROUTE() ein XML-Fragment für eine einzelne Route
und XMLAGG(ROUTE(...)) die aneinander gereihten XML-Fragmente für alle Routen an
einem Felsen.
create function GEBIET(gebName: varchar(20), gebGestein:
varChar(20), felsList: xml)
returns xml language xml return
<Gebiet Name={gebName} Gestein= {gebGestein}>
<fels>{felsList}</fels>
</Gebiet>
Abb. 8: Definition des XML-Konstruktors GEBIET() mit Hilfe der SQL-Erweiterung
Dies hätte, wie die Autoren von [3] zeigen, unabhängig vom sonstigen Implementierungsansatz erhebliche Performancevorteile gegenüber allen Lösungen, bei denen die
Erzeugung des XML-Dokuments (aus den von der Datenbank gelieferten Daten) außerhalb der Datenbank geschieht. Grund hierfür ist die für die Übergabe der Ergebnisse an
ein Programm außerhalb der Datenbank benötigte Zeit.
6.2 Frühe Strukturierung der Daten und frühes Einfügen der XML-Tags
Hierbei wird sowohl die Strukturierung der Daten als auch das Einfügen der Tags in
einem Programm außerhalb des Datenbanksystems erledigt. Für die als Beispiel
verwendete Datenbank wären dabei folgende Schritte erforderlich:
Schreiben des Root-Elements ("<GEBIETE>")
SQL-Abfrage: select Name, GebietID, Gestein from Gebiete
für jedes Gebiet:
Schreiben des Gebiet-Elements
SQL-Abfrage: select * from Fels where Fels.GebietID = {GebietID}
für jeden Fels:
Schreiben des Fels-Elements
SQL-Abfrage: select * from Route where Route.FelsID =
{FelsID}
für jede Route:
Schreiben des Route-Elements und der inneren Elemente
Abb. 9: frühe Strukturierung der Daten und frühes Einfügen der XML-Tags
- 10 Dieser Ansatz ist relativ einfach zu implementieren, bei größeren Datenmengen aufgrund
der Vielzahl von Abfragen und der vorgegebenen Struktur (keine Optimierungsmöglichkeit
für das Datenbanksystem) aus Performancegründen aber nicht praktikabel.
6.3 Späte Strukturierung der Daten und spätes Einfügen der XML-Tags
In [3] werden drei verschieden Methoden diskutiert, die auf diesem Ansatz basieren. Die
von den Autoren favorisierte dieser drei Methoden wird als (unsorted) node outer union
bezeichnet.
with
gebRoot(gebID varChar(20), gebName varChar(20), Gestein)
as
select GebietID, Name, Gestein
from Gebiet geb
),
gebFels(gebID varChar(20), flsID varChar(20), felsName
varChar(20), kinderfreundlich boolean)
as
select geb.GebietID, fls.felsID, fls.Name, fls.kinderfreundlich
from geb, Fels fls
),
felsRoute(gebID varChar(20), flsID varChar(20), rtName
varChar(20), Laenge integer, Schwierigkeit integer, Ausrichtung
char(2))
as
select fls.GebietID, fls.felsID, rt.Name, rt.Laenge,
rt.Schwierigkeit, rt.Ausrichtung
from fls, Route rt
),
select 0, gebID, gebName, Gestein, null, null, null, null, null,
null, null
from gebRoot
union all
select 1, gebID, null, null, flsID, felsName, kinderfreundlich,
null, null, null, null
from gebFels
union all
select 2, gebID, null, null, flsID, null, null, rtName, Laenge,
Schwierigkeit, Ausrichtung
from felsRoute
Abb. 10: SQL-Abfrage für node outer union
Das Ergebnis ist eine Tabelle, die drei Typen von Tupeln enthält:
Typ 0 enthält Informationen über Gebiete
Typ 1 enthält Informationen über Felsen
Typ 2 enthält Informationen über Routen
- 11 typ gebI gebName Gestein fls felsName
D
ID
kinde rtNam Laeng Schwi Ausric
rfreun
e
e
erigke htung
dlich
it
1
G2
F2 Heufels
ja
2
G1
F3
1
G1
F3 Ankatalwand
2
G1
2
Comput 18
erspiele
8
SW
F3
Internet 18
9
SW
G1
F1
Simon
10
S
1
G1
F1 Student
0
G2
Pfalz
0
G1
Frankenjura Kalk
ja
15
nein
Sandstein
Abb. 11: mögliches Abfrageergebnis nach dem (unsorted) node outer union-Ansatz
Die Ergebnistabelle ist unsortiert und enthält eine Vielzahl von null-Werten, aber im
Gegensatz zu anderen in [3] diskutierten, hier nicht vorgestellten Vorgehensweisen keine
redundanten Daten.
Im Anschluss an die Abfrage müssen die Daten strukturiert und mit Tags versehen werden. Da die Reihenfolge der Daten nicht vorhersehbar ist, muss die Zusammensetzung
des XML-Dokuments im Speicher geschehen und das Dokument kann erst geschrieben
werden, wenn alle Daten vorliegen und eingebaut sind.
6.4 Frühe Strukturierung der Daten und spätes Einfügen der XML-Tags
Der Speicheraufwand für das Einfügen der Tags entfällt, wenn die Daten innerhalb des
Datenbanksystems entsprechend sortiert werden. Hierzu ist ein abschließende Sortierung
der Daten ausreichend (sorted node outer union).
Im Beispiel muss eine Sortierung nach gebID, felsID und rtName erfolgen, um die richtige
Reihenfolge der Tupel sicherzustellen:
typ gebI gebName Gestein fls felsName
D
ID
0
G1
1
G1
F1 Student
2
G1
F1
1
G1
F3 Ankatalwand
2
G1
F3
2
G1
F3
0
G2
1
G2
kinde rtNam Laeng Schwi Ausric
rfreun
e
e
erigke htung
dlich
it
Frankenjura Kalk
Pfalz
nein
Simon
15
10
S
Comput 18
erspiele
8
SW
Internet 18
9
SW
ja
Sandstein
F2 Heufels
ja
Abb. 12: Abfrageergebnis nach dem sorted node outer union-Ansatz
Dadurch, dass null-Werte in der Sortierreihenfolge vor allen echten Werten einsortiert
werden, ergibt sich die richtige Reihenfolge der Daten-Tupel. Das Einfügen der Tags wird
dadurch sehr einfach, alle Daten können sofort geschrieben werden. Der Tagger braucht
nur noch so viel Speicherplatz wie nötig ist, um sich die IDs der Vorgänger des aktuellen
Datensatzes (im Beispiel (gebID und flsID) zu merken, um festzustellen, ob ein neuer
- 12 Datensatz zum gleichen oder zu einem anderen Felsen oder Gebiet gehört und das entsprechende Tag zu schließen ist. Dieser Speicherplatz ist nur von der Verschachtelungstiefe des XML-Dokuments, aber nicht mehr vom Umfang der auszugebenden Daten abhängig.
6.5 Schlussfolgerungen
Die in 6.1 vorgestellte Umsetzung der Inhalte einer Datenbank in XML innerhalb des
Datenbanksystems bietet erhebliche Performancevorteile.
In [3] wird nicht explizit die Möglichkeit erwähnt, die SQL-Abfrage als Sichtdefinition
(CREATE VIEW "Klettergebiet" AS...) virtuell zu halten, jedoch sollte dies durchaus möglich sein. Aber auch dann gibt es im Gegensatz zu SilkRoute und XPERANTO keine Möglichkeit, hierauf aufbauende Benutzeranfragen in einer XML-Abfragesprache effektiv mit
der Sichtdefinition zu verknüpfen. Ein weiterer Nachteil besteht darin, dass diese Lösung
vom Datenbanksystem bereitgestellt werden muss. Im Gegensatz hierzu können
SilkRoute und XPERANTO prinzipiell mit jeder SQL-Datenbank verwendet werden. Sehr
vorteilhaft ist die Lösung innerhalb des Datenbanksystems, wenn die vorgeschlagene
SQL-Erweiterung von der vorhandenen Datenbank unterstützt wird und der Inhalt der
Datenbank im allgemeinen nicht für wechselnde Benutzeranfragen, sondern
entsprechend einer oder mehrerer vorgegebener DTD zur Verfügung gestellt werden soll.
Für externe Programme wie SilkRoute oder XPERANTO bietet sich der in Abschnitt 6.4
vorgestellte sorted node outer union-Ansatz an, der bei guter Performance auch bei größeren Datenmengen keine Probleme mit dem Speicherplatz beim Einfügen der XML-Tags
mit sich bringt. Ungünstig wird dieser Ansatz allerdings dann, wenn das Datenbanksystem
keine geeignete Verwaltung von null-Werten bietet.
7 Übersetzung der zusammengesetzten Anfragen in SQL
7.1 SilkRoute
Die Umsetzung der (zusammengesetzten) RXL-Anfrage in SQL wird in der Literatur nicht
detailliert beschrieben. Komplexere RXL-Anfrage mit mehreren Unter-Anfragen werden in
mehrere SQL-Abfragen (eine pro Unter-Abfrage) übersetzt. Alle erzeugten SQL-Abfragen
enthalten eine sort by-Anweisung, um aus den aus der SQL-Abfrage resultierenden
Tupeln anschließend einfach das XML-Dokument erzeugen zu können. Für das Beispiel
sähen die SQL-Anfragen in etwa so aus:
1.Select * from Gebiet sort by GebietID
2.Select * from Fels sort by GebietID
3.Select Fels.GebietID, Fels.FelsID, Route.Name, Route.Laenge,
Route.Schwierigkeit, Route.Ausrichtung, from Route, Fels where
Route.FelsId = Gebiet.FelsID sort by GebietId, FelsID
Abb. 13: SQL-Abfragen für SilkRoute
Als Ergebnis erhält man dann die folgenden Tabellen:
- 13 -
GebietID
Name
Gestein
G1
Frankenjura Kalk
G2
Pfalz
FelsID GebietID
Sandstein
Name
kinderfreundlich
F1
G1
Student
F3
G1
Ankatalwand ja
F2
G2
Heufels
GebietID FelsID
nein
ja
Name
G1
F1
Simon
G1
F3
G1
F3
Laenge Schwierigkeit Ausrichtung
15
10
S
Computerspiele 18
8
SW
Internet
9
SW
18
Abb. 14: Abfrageergebnis SilkRoute
Bei der Entwicklung von SilkRoute wurde nach Angaben in [3] ein Datenbanksystem ohne
Kompression von null-Werten benutzt. Hierdurch würde sich die Ergebnistabelle nach
dem sorted node outer union -Ansatz erheblich aufblähen und dieser Ansatz aufgrund der
verlängerten Sortierzeit weniger effizient. Nach [3] ist unter dieser Voraussetzung der von
SilkRoute benutzte Ansatz nahezu optimal.
7.2 XPERANTO
XPERANTO benutzt den in Abschnitt 6.4 beschriebenen "sorted node outer union" Ansatz
zur Umsetzung der Anfragen in SQL. Pro Anfrage wird dabei eine einzelne SQL-Abfrage
erzeugt. Das Ergebnis der Abfrage entspricht Abb. 11.
8 Erzeugung des XML-Dokuments
Bei beiden Systemen werden die Daten von der Datenbank sortiert und können daher
sofort (d.h. ohne nochmaliges Speichern) mit Tags versehen und ausgegeben werden.
8.1 SilkRoute
Neben der SQL-Abfrage wird bei Übersetzung der Anfrage auch ein XML-Template
erzeugt, das dem XML-Generator das Zusammensetzen des XML-Dokuments aus den
hierin enthaltenen Tags und den von der Datenbank gelieferten Tupeln ermöglicht.
8.2 XPERANTO
Zu jeder Benutzerabfrage wird neben der SQL-Abfrage auch ein XML-Schema erzeugt.
Die von der Datenbank gelieferten Tupel werden vom XML-Tagger (der als weitere Quelle
vermutlich das XML-Schema nutzt) mit Tags versehen.
- 14 9 Vergleich von SilkRoute und XPERANTO
9.1 Funktionsumfang
Beide Programme erfüllen den Zweck, relationale Datenbanken auf eine XML-Sicht
abzubilden.
XPERANTO bietet einen deutlich größeren Funktionsumfang:
Abbildung objektrelationaler Datenbanken (SQL 99)
Die Erzeugung eines XML-Schemas für die Standard-Sicht und benutzerdefinierte
Sichten gibt dem Benutzer detaillierte Informationen insbesondere über die Wertebereiche der Daten in der Datenbank.
Meta-Daten können in Abfragen einbezogen werden.
Vorhandene, benutzerdefinierte Sichten werden gespeichert und stehen für weitere
Abfragen zur Verfügung
9.2 Benutzerfreundlichkeit
Im Gegensatz zu SilkRoute stellt XPERANTO eine Standard-Sicht zur Verfügung.
Dadurch ist es möglich, Benutzern den Inhalt einer Datenbank ohne weitern Aufwand als
XML-Sicht zugänglich zu machen. Da Datenbanken oft aber auch Daten enthalten, die
nicht extern zugänglich sein sollen, muss in der Regel auch bei der Verwendung von
XPERANTO eine XML-Sicht definiert werden. Vorteil von XPERANTO ist hier, dass für
die Sichtdefinition keine eigene Sprache verwendet, sondern XML-QL benutzt wird.
Allerdings scheint der Aufwand für das Erlernen von RXL für einen
Datenbankadministrator, der ohnehin SQL und evtl. XML-QL beherrscht, eher gering.
10 Zusammenfassung
Es wurde gezeigt, wie zwei Middleware-Systeme Daten aus relationalen Datenbanken als
XML-Sichten zur Verfügung stellen. Beide Systeme scheinen für diesen Zweck geeignet,
wobei XPERANTO vor allem durch seinen erheblich größeren Funktionsumfang und
seine daraus resultierende Flexibilität bei der Anwendung überzeugt. Als weiterer Ansatz
wurde eine Erweiterung von SQL vorgestellt, die - bei reduzierter Benutzerfreundlichkeit
und Flexibilität – die schellste Möglichkeit für die Präsentation von Datenbankinhalten als
XML-Sicht darstellt.
Literatur:
[1] M. F. Fernandez, W. C. Tan und D. Suciu. SilkRoute: Trading Between Relations and
XML. WWW9 / Computer Networks 33(1-6), 723-745, 2000, http://www.cs.washington.
edu/homes/suciu/NodeInternal/sitegraph.genoid_2.html
[2] M. J. Carey, D. Florescu, Z. G. Ives, Y. Lu, J. Shanmugasundaram, E. J. Shekita und
S. N. Subramanian: XPERANTO: Publishing Object-Relational Data as XML. WebDB
(Informal Proceedings), 105-110, 2000, http://www.cs.cornell.edu/People/jai/pubs.html
[3] J. Shanmugasundaram, E. J. Shekita, R. Barr, M. J. Carey, B. G. Lindsay, H. Pirahesh
und B. Reinwald: Efficiently Publishing Relational Data as XML documents. VLDB Journal
10(2-3), 133-154, 2001, http://www.cs.cornell.edu/People/jai/pubs.html
[4] Eric van der Vlist: Using W3C XML Schema,
http://www.xml.com/pub/a/2000/11/29/schemas/part1.html
[5] XML-QL Users's Guide: Basics,
http://www.research.att.com/~mff/xmlql/doc/sitegraph.genoid_5.html
Native XML-Datenbanken: Natix und Tamino
Seminararbeit zum Kurs 1912
im Sommersemester 2002
Dozent: Prof. Ralf H. Güting
an der FernUniversität Hagen
Von Monika Wienbeck, Matr.-Nr. 5360242
Inhaltsverzeichnis
1.
Natix und Tamino: Wer hat es entwickelt und warum?.................................................... 3
1.1. Daten- vs dokumentenzentrierte Dokumente........................................................... 3
1.2. Speicherung von XML-Dokumenten in relationalen Datenbanken ........................... 8
1.3. Kernthemen in der Diskussion um native XML-Datenbanken ................................ 10
2. Globale Vorgaben für Progammierschnittstellen (APIs) ................................................ 10
2.1. DOM (W3C)........................................................................................................... 10
2.2. SAX ....................................................................................................................... 11
2.3. Relevante ‚Open issues‘, z.B. Views...................................................................... 11
3. Natix ............................................................................................................................. 11
3.1. Architektur ............................................................................................................. 11
3.2. Organisation der Speicherung von XML-Baumstrukturen ...................................... 12
3.3. Transaktionsverwaltung und Speicherebene in Natix ............................................ 15
3.4. Abfragen und Views .............................................................................................. 16
3.5. Performance.......................................................................................................... 17
3.6. Diskussion ............................................................................................................. 19
4. Tamino ......................................................................................................................... 20
5. Ausblick ........................................................................................................................ 21
6. Literatur ........................................................................................................................ 21
Seminar 1912, Ausarbeitung zum Vortrag „Native XML-Datenbanken: Natix und Tamino“
von Monika Wienbeck
Seite 2 von 22
1. Natix und Tamino: Wer hat es entwickelt und warum?
Natix wurde von einem Projektteam an der Universität Mannheim entwickelt. Der
Gesamtkontext war ein vom Bundesministerium für Bildung und Forschung (BMBF)
gefördertes Vorhaben, die Biochemical Pathways des Spektrum Verlages zu digitalisieren.
Dieses Nachschlagewerk bietet Informationen über chemische Reaktionen, es enthält
Informationstexte und graphische Darstellungen, die die NutzerInnen sich sowohl im Detail
als auch im Kontext ansehen möchten. Das Mannheimer Projektteam erhielt 1998 die
Zuständigkeit für die Datenhaltung und entschied sich, dafür eine „native XML-Datenbank“
zu entwickeln. [13]
Eine native XML-Datenbank: Was ist das überhaupt? Offenbar wurde dieser Begriff bei einer
Vermarktungskampagne von Software AG für das Produkt Tamino in die breite Diskussion
gebracht und dann in Internet-Diskussionsforen im nachhinein theoretisch definiert [1]. Eine
brauchbare Definition findet sich beispielsweise im Internet auf der Webpage von Ronald
Bourret. Demnach
-
hat eine native XML-Datenbank ein logisches Modell für XML-Dokumente – bspw. DOM
oder das XPath-Datenmodell –, und die Speicherung von bzw. Anfragen an Dokumente
ist entsprechend gestaltet. XML-Elemente, -Attribute, -PCDATA, und die Reihenfolge des
Dokuments müssen in dem Modell berücksichtigt sein.
-
ist die grundlegende Einheit der logischen Speicherung bei einer nativen XML-Datenbank
das Dokument
Der Begriff „native XML-Datenbank“ kann nach dieser Definition unabhängig von der
physikalischen Speicherung der Dokumente angewandt werden [2]. Die in dieser Arbeit
vorgestellten Datenbanken Natix und Tamino entsprechen dieser Definition. Sie haben beide
ein proprietäres Speicherformat, das XML-Dokumenten entsprechend ihrer logischen
Struktur auf Speicherseiten aufteilt.
Die Motivationen für die Entwicklung einer nativen XML-Datenbank für die digitale Version
der Biochemical Pathways waren weit gestreut. Zu einen gab es wirtschaftliche Gründe: Bei
Verwendung einer etablierten relationalen Datenbank wie Oracle 8i wären erhebliche
Lizenzgebühren angefallen, die den Preis bei einem Vertrieb des Projektergebnisses auf CD
erheblich in die Höhe getrieben hätten. Zum anderen handelt es sich bei den Texten des
Nachschlagewerks um dokumentenzentrierte Dokumente – und somit um ein Format, das
nach heutigem Stand der Diskussion besser in nativen XML-Datenbanken als in relationalen
Datenbanken abgelegt wird.
1.1. Daten- vs dokumentenzentrierte Dokumente
Der Dichotomie von datenzentrierten und dokumentenzentrierten Dokumenten ist eine
theoretische Begrifflichkeit zur Unterscheidung von Dokumentenstrukturen. Sie gehört zum
Standardrepertoire einer Argumentation, die die Überlegenheit von nativen XMLDatenbanken mit den Eigenheiten der zu verwaltenden Dokumente begründet. In der Praxis
kommen jedoch häufig Zwischenformen vor.
von Monika Wienbeck
Seite 3 von 22
„Datenzentriert“ sind Dokumente, in denen die Reihenfolge der Datensätze irrelevant ist,
deren Struktur regelmäßig ist, und in denen kein gemischter Inhalt vorkommt – wie zum
Beispiel im folgenden Datenblatt über eine Abteilung und ihre Angestellten:
<department>
<deptno>15</deptno>
<name>Marketing</name>
<employee>
<empno>815</empno>
<firstname>Maria</firstname>
<lastname>Weber</lastname>
</employee>
<employee>
<empno>216</empno>
<firstname>Karl</firstname>
<lastname>Kunger</lastname>
</employee>
</department>
Bei einer Anfrage über dieses Dokument wäre es nicht relevant, in welcher Reihenfolge die
beiden employee-Elemente zurückgeliefert würden. Der Inhalt könnte im relationalen Modell
in zwei Tabellen übertragen werden, ohne dass Namenskonflikte oder Probleme mit
nullvalues vorkämen.
„Dokumentenzentriert“ sind dagegen Bücher, e-mails, Werbung und andere Dokumente, die
eine eher unregelmäßige Struktur haben, die Daten mit relativ hoher Granularität enthalten,
ausserdem gemischten Inhalt, und in denen nicht zuletzt die Reihenfolge der Elemente zählt
(s. [2] und [14]).
Wir im stellen im folgenden eine XML-Verson von William Shakespeares Theaterstück „The
Tempest“ (Der Sturm) als Beispiel für ein dokumentenzentriertes Dokument vor,
tempest.xml. Diese Datei ist im Internet zur freien Verfügung eingestellt [16], und sie ist Teil
des Materials, das Kanne und Moerkotte bei der in Abschnitt 3.5 dieser Arbeit diskutierten
Performance-Studie für Natix verwendet wurde. Die hier vorgestellte Version von
tempest.xml enthält weder Attribute noch Ausführungsanweisungen. Trotz dieser reduzierten
strukturellen Komplexität ist sie zur Darstellung der wesentlichen Aspekte von
dokumentenzentrierten Dokumenten ebenso geeignet wie als Beispiel zur Darstellung der
wesentlichen Funktionalitäten von Natix.
Beispiel: tempest.xml
Das Dokument tempest.xml ist eins von insgesamt 38 Dokumenten in der XML-Version von
Shakespeares gesammelten Werken. Die hier verwendete Version wurde 1992-1994 von
John Bosak in SGML Markup erstellt und 1996-1997 auf XML umformatiert.
von Monika Wienbeck
Seite 4 von 22
Die data type definition (DTD) ist für alle im Korpus enthaltenen Dokumente einheitlich
deklariert:

<!ENTITY amp "&">
<!ELEMENT play
- - (title, fm, personae, scndescr, playsubt, induct?,
prologue?, act+, epilogue?)>
<!ELEMENT title
- - (#PCDATA)>
<!ELEMENT fm
- - (p+)>
<!ELEMENT p
- - (#PCDATA)>
<!ELEMENT personae - - (title, (persona | pgroup)+)>
<!ELEMENT pgroup
- - (persona+, grpdescr)>
<!ELEMENT persona - - (#PCDATA)>
<!ELEMENT grpdescr - - (#PCDATA)>
<!ELEMENT scndescr - - (#PCDATA)>
<!ELEMENT playsubt - - (#PCDATA)>
<!ELEMENT induct
- - (title, subtitle*,
(scene+|(speech|stagedir|subhead)+))>
<!ELEMENT act
- - (title, subtitle*, prologue?, scene+, epilogue?)>
<!ELEMENT scene
- - (title, subtitle*, (speech | stagedir |
subhead)+)>
<!ELEMENT prologue - - (title, subtitle*, (stagedir | speech)+)>
<!ELEMENT epilogue - - (title, subtitle*, (stagedir | speech)+)>
<!ELEMENT speech
- - (speaker+, (line | stagedir | subhead)+)>
<!ELEMENT speaker - - (#PCDATA)>
<!ELEMENT line
- - (stagedir | #PCDATA)+>
<!ELEMENT stagedir - - (#PCDATA)>
<!ELEMENT subtitle - - (#PCDATA)>
<!ELEMENT subhead - - (#PCDATA)>
Abbildung 1: DTD für Shakespeares gesammelte Werke
In der DTD lassen sich entsprechend der DOM-Vorgaben zwei Typen unterscheiden:
1. Elemente, in die weitere Elemente eingebettet sind. Wir bezeichnen dieses Verhältnis im
folgenden als „Elternknoten“ (das Element selber) und „Kindknoten“ (die eingebetteten
Knoten). Selbstverständlich können in ein Kindknoten weitere Elemente eingebettet sein,
so dass der Kindknoten Elternknoten weiterer Kindknoten ist. Elternknoten haben in
tempest.xml lediglich die Kindknoten zum Inhalt. Der Elternknoten, der selbst keinen
Elternknoten hat, nennen wir Wurzelknoten. Der Wurzelknoten in der DTD ist play.
Weiter Elternknoten sind fm, personae, pgroup, induct, act, scene, prologue,
epilogue, speech und line.
2. Textfelder. Dies sind Elemente mit Inhalt, die immer einen (Element-)Elternknoten haben
und niemals einen Kindknoten. Inhalt ist in tempest.txt ein einfacher Textstring, in der
DTD deklariert als PCDATA. Hierzu gehören title, p, persona, grpdescr, scndescr,
playsubt, speaker, stagedir, subtitle und subhead.
Die Struktur des hier im Detail betrachteten Abschnitts von tempest.xml – also bis zum Ende
der ersten Szene – ist in der DTD vollständig beschrieben. Es beginnt mit dem XML-header
und einem nachfolgenden Kommentar. Dann folgt der PLAY-Wurzelknoten für das gesamte
nachfolgende Dokument mit zehn Kindknoten: TITLE, fm, PERSONAE, SCNDESCR, PLAYSUBT
und – entsprechend der klassischen Drama-Lehre – fünf ACT-Elementen. Inhalt von TITLE ist
der Title des gesamten Stücks, „The Tempest“. Das fm-Element enthält vier p-Kindknoten,
von Monika Wienbeck
Seite 5 von 22
die jeweils eine Zeile der Dokumentgeschichte bzw. der Erklärung zum Copyright zum Inhalt
haben:
<?XML version="1.0"?>
<!DOCTYPE play PUBLIC "-//Free Text Project//DTD Play//EN">
<PLAY>
<TITLE>The Tempest</TITLE>
<fm>
Text placed in the public domain by Moby Lexical Tools, 1992.
SGML markup by Jon Bosak, 1992-1994.
XML version by Jon Bosak, 1996-1997.
This work may be freely copied and distributed worldwide.
</fm>
<PERSONAE>...</PERSONAE>
<SCNDESCR>...</SCNDESCR>
<PLAYSUBT>...</PLAYSUBT>
<ACT>...</ACT>
<ACT>...</ACT>
<ACT>...</ACT>
<ACT>...</ACT>
<ACT>...</ACT>
</PLAY>
Abbildung 2: Grobstruktur von tempest.xml
Das PERSONAE-Element enthält 17 Kindknoten, von links nach rechts: ein TITLE-Element,
fünf PERSONA-Textfeld, ein PGROUP-Element, acht weitere PERSONA-Textfelder, ein weiteres
PGROUP-Element und ein letztes PERSONA-Textfeld. Inhalt des TITLE-Textfelds ist der Titel
des Abschnitts: „Dramatis Personae“; Inhalt der PERSONA-Textfelder sind jeweils Name und
ggf. Eigenschaft einer im Stück vorkommenden Person, z.B. „MIRANDA, daughter to
Prospero.“ Die PGROUP-Elemente haben Kindknoten, nämlich zwei bzw. fünf bzw. PERSONATextfelder (Inhalt ist diesmal nur der Name der Person) und ein GRPDESCR-Textfeld. Inhalt
des GRPDESCR-Textfeld ist „Lords.“ bzw. „presented by Spirits.“ Das sind text-semantisch
gesehen Eigenschaften der in den Nachbarknoten definierten Personen, analog zu dem
Substring „daughter to Prospero“ bei Miranda:
<PERSONAE>
...
<PGROUP>
<PERSONA>ADRIAN</PERSONA>
<PERSONA>FRANCISCO</PERSONA>
<GRPDESCR>Lords.</GRPDESCR>
</PGROUP>
...
<PERSONA>MIRANDA, daughter to Prospero.</PERSONA>
...
</PERSONAE>
Abbildung 3: Semantik von GRPDESCR als Gruppenattribut
Das SCNDESCR-Textfeld hat den Inhalt „SCENE A ship at Sea: an island.“, also der Ort, an
dem die Handlung des gesamten Stücks beginnt.
Das PLAYSUBT-Textfeld hat den Inhalt „THE TEMPEST“ und wiederholt damit in
Grossbuchstaben den Titel, den wir schon im TITLE-Kindknoten von PLAY gefunden hatten.
Das erste ACT-Element hat die Kindknoten TITLE und SCENE. SCENE wiederum hat den
Kindknoten TITLE sowie insgesamt 10 STAGEDIR- und 28 SPEECH-Kindknoten in
unsystematischer Folge. Die Sequenz: 1 x STAGEDIR, 3 x SPEECH, 2 x STAGEDIR, 1 x SPEECH,
1 x STAGEDIR, 8 x SPEECH, 1 x STAGEDIR, 1 x SPEECH, 2 x STAGEDIR, 6 x SPEECH,
1 x STAGEDIR, 6 x SPEECH, 1 x STAGEDIR, 2 x SPEECH, 1 x STAGEDIR, 1 x SPEECH. Jeder
von Monika Wienbeck
Seite 6 von 22
SPEECH-Knoten hat ein SPEAKER-Kindknoten und ein oder mehrere LINE-Kindknoten. Der
TITLE-Kindknoten von ACT hat „ACT I“ zum Inhalt, der TITLE-Kindknotens von SCENE
„SCENE I. On a ship at sea: a tempestuous noise of thunder and lightning heard.“ Mit dem
STAGEDIR-Element mit dem Inhalt „Enter a Master and a Boatswain“ beginnt dann die
eigentliche Handlung des Stücks, nämlich dem Untergang des Schiffes, auf dem sich
Ferdinand befindet.
Obwohl in dem betrachteten Ausschnitt aus tempest.txt keine XML-Attribute und keine XMLAusführungsanweisungen vorkommen, illustriert es hervorragend die typischen
Charakteristika von dokumentenzentrierten Dokumenten. So ist für die Semantik des
Dokuments beispielsweise die Reihenfolge der Kindsknoten des ersten SCENE-Elements
konstitutiv:
<SPEECH>
<SPEAKER>Boatswain</SPEAKER>
<LINE>Here, master: what cheer?</LINE>
</SPEECH>
<SPEECH>
<SPEAKER>Master</SPEAKER>
<LINE>Good, speak to the mariners: fall to't, yarely,</LINE>
<LINE>or we run ourselves aground: bestir, bestir.</LINE>
</SPEECH>
<STAGEDIR>Exit</STAGEDIR>
Abbildung 4: Inhalt des ersten ACT-Elements in tempest.xml (Auszug)
Würden in dieser Sequenz das erste SPEECH-Element (Boatswain-SPEAKER) und das
STAGEDIR-Textfeld in der Reihenfolge vertauscht, dann müssten Schauspieler agieren, die
bereits die Bühne verlassen haben. Ausserdem würde der Master-SPEAKER auf eine nicht
gestellte Frage antworten, und die Frage des Boatswain-SPEAKERs würde gar nicht oder in
einer hier nicht mehr abgebildeten, nachfolgenden Sequenz auf sinnverfälschte Weise
beantwortet.
Am Beipiel des des PGROUP-Elements haben wir bereits gesehen, dass aufgrund der
Dokumentenstruktur ein Knoten semantisch gesehen ein Attribut zu seinen Nachbarknoten
enthalten kann. Die Verwendung des TITLE-Elements illustriert, dass zusätzlich die
Semantik ein- und desselben Feldes im Dokument durchaus variieren kann:
<PLAY>
<TITLE>The Tempest</TITLE>...
</PLAY>
...
<PERSONAE>
<TITLE>Dramatis Personae</TITLE>...
</PERSONAE>
...
<ACT><TITLE>ACT I</TITLE>...
</ACT>
...
</PLAY>
Abbildung 5: Semantik der TITLE-Elemente variiert mit dem Kontext
Einmal handelt es sich um den Titel des Stücks, einmal um den Titel der Personenliste, und
einmal um den Titel des Akts. In der DTD ist nur ein TITLE-Textfeld deklariert, allerdings als
Kind mehrerer Knoten, die selbst in einer hierarchischen Beziehung zueinander stehen. Es
handelt sich hier um ein typisches Beispiel von gemischtem Inhalt.
von Monika Wienbeck
Seite 7 von 22
1.2. Speicherung von XML-Dokumenten in relationalen Datenbanken
Für das Problem der variierenden Semantik des TITLE-Textfeldes gäbe es in einer
relationalen Datenbank eine klassische Lösung, nämlich die Verdreifachung des Feldes:
play.title, personae.title und act.title. Tempest.xml wird mit diesem Ansatz durch eine Menge
von Tabellen modelliert. Wir erhalten damit eine tabellenbasierte Abbildung des
Dokumentenschemas auf ein relationales Datenbankschema (vgl. [1], Abschnitt 5.1.1), die
für die drei Strukturebenen play, personae und act jeweils eine eigene Tabelle anlegt:
Abbildung 6: Lösung des title-Problems bei tabellenbasierter Abbildung des
Dokumentenschemas in ein relationales Datenbankschema
Eine solche Abbildung in relationale Tabellen verbietet sich für die Verwaltung
veränderlicher, dokumentenzentrierter Dokumente jedoch schon nach kurzer Überlegung
von selbst:
-
Die Tabellenstruktur müsste induktiv aus den vorliegenden Dokumenten erschlossen und
mit jedem neuen Dokument neu überprüft werden, da die schematische Information
eines XML-Dokuments nicht in einer DTD deklariert werden muss.
-
Die Tabellenstruktur wäre auch deshalb nie mit Sicherheit abgeschlossen, weil bei jeder
Operation auf bestehenden Dokumenten bislang undefinierte Knoten hinzukommen
könnten. Ausserdem könnten jederzeit Operationen eine Modifikation der Struktur zum
Gegenstand haben. Der Aufwand für diese permanenten Reorganisationen der Tabellen
zum Zweck der Ausführung einfacher Operationen ist jedoch nicht vertretbar.
-
Die mögliche Variationsbreite der möglichen Kombinationen und Einbettungen von
Knoten würde regelmäßig eine Tabellenstruktur hervorbringen, die sich nicht mehr
sinnvoll verwalten lässt.
-
In XML-Dokumenten können grundsätzlich Kommentare und Ausführungsanweisungen
unsystematisch über die Dokumente verteilt sein. Hier liegt ein großes Potential für eine
Komplexität, die sich nicht mehr sinnvoll in Tabellenstrukturen verwalten lässt [14].
Eine logisch unkomplizierte Möglichkeit ist dahingegen die Speicherung von
dokumentenzentrierten XML-Dokumenten als binary large objects (BLOBs) oder character
large objects (CLOBs). Diese Lösung ist jedoch für viele Anwendungsbereiche nicht
von Monika Wienbeck
Seite 8 von 22
geeignet. Ist zum Beispiel ein Dokument größer als eine Speicherseite, dann würde es bei
den relationalen BLOB- bzw. CLOB-Lösungen unbeachtet seiner XML-Struktur auf
Speicherseiten aufgeteilt. Eine solche Aufteilung wäre beispielsweise bei tempest.xml bei
einer Gesamtlänge von 149.472 Zeichen und einem Speicherplatzbedarf von 152 KB bei
Abspeicherung als Textdatei höchstwahrscheinlich erforderlich. Um bei Anfragen relevante
Kontextinformation – wie im Beispiel des PGROUP-Elements in tempest.xml – zu erhalten
müsste das Dokument bei jeder Abfrage erneut zusammengesetzt und geparst werden. Dies
wird jedoch in den meisten Fällen zu völlig unakzeptablen Wartezeiten für die Benutzerin /
den Benutzer führen.
Eine weitere Lösung wäre die Repräsentation der Baumstruktur in einer einfachen Tabelle,
die alle Elemente aus allen Dokumenten auflistet und durch Identifikationsnummern (IDs)
und Verweise in Beziehung stellt, analog einer Array-Implementierung von Bäumen:
Abbildung 7: Repräsentation der Baumstruktur von tempest.xml in einer einzelnen Tabelle
einer relationalen Datenbank
Eine solche Lösung diskutieren Fiebig, Kanne und Moerkotte, kommen jedoch zu einem
negativen Ergebnis: Nachbildungen von DOM-Funktionen – bspw. nach dem
Geschwisterknoten – in SQL würden zu komplex. Ausserdem sei die Übersetzung von
XPath- und XQuery-Ausdrücken in SQL gleich aus mehreren Gründen kritisch: Zum einen
gebe es einen Leistungsverlust durch zusätzliche Abbildungsschichten; weiterhin sei SQL
nicht mächtig genug, um alle XPath- und XQuery-Ausdrücke wiederzugeben; und nicht
zuletzt müsse bereits beim Einfügen eines einzigen Knotens zur Vermeidung von
Phantomproblemen immer die Relation als Ganzes gesperrt und somit ggf. mehrere
Dokumente gesperrt werden. ([4], S. 7)
Letztlich ist also – so die Argumentation von Fiebig, Kanne und Moerkotte als Vertreter des
Natix-Anbieters data ex machina und Schöning als Vertreter des Tamino-Anbieters SoftwareAG – bietet die Verwaltung von dokumentenzentrierten Dokumenten in nativen XMLDatenbanken gegenüber der Verwaltung solcher Dokumente in relationalen Datenbanken
erhebliche Vorzüge in Bezug auf Mehrbenutzerbetrieb, Abfragemöglichkeiten und –
performance sowie wesentlich bessere Eigenschaften für den Mehrbenutzerbetrieb.
von Monika Wienbeck
Seite 9 von 22
1.3. Kernthemen in der Diskussion um native XML-Datenbanken
Für die heutigen nativen XML-Datenbanken listet Bourret ([1]) einige typische
Leistungsmerkmale auf, die sich auch bei Natix und bei Tamino im wesentlichen
wiederfinden lassen1:
Document Collections – Dokumente werden in der Datenbank zu Collections gruppiert, so
dass bei Abfragen der abzusuchende Bereich von vorneherein auf bestimmte Collections
eingegrenzt werden kann. Das Collections-Konzept ist bei Tamino implementiert.
Anfragesprachen – Die vom W3C empfohlenen Anfragesprachen werden unterstützt. Bei
Natix ist das XPath und NQL, bei Tamino XQL.
Änderungs- und Löschoperationen – Die Datenbank unterstützt Änderungs- und
Löschoperationen auf Dokumenten. Natix und Tamino haben beide dieses
Leistungsmerkmal, jedoch gibt es bemerkenswerte Unterschiede in der Realisierung von
Dokumentenspeicherung und –indizierung.
Transaktionen, Sperren und gleichzeitige Zugriffe – Transaktionen müssen unterstützt
werden, Sperren sollten möglichst so organisiert sein, dass sie ein Höchstmaß an Freiheiten
für gleichzeitige Zugriffe zu gewährleisten. Hier gibt es insbesondere Unterschiede in der
Verfügbarkeit von Protokollen für Transaktionen.
Application Programming Interfaces und Zugriff auf externe Datenquellen - zum Umfang der
hier
vorgestellten
XML-Datenbanken
gehören
auch
standardisierte
Programmierschnittstellen (APIs) wie in Kapitel 2 dieser Arbeit vorgestellt. Diese
Schnittstellen gehören ebenso zur Architektur der Datenbank wie der Zugriff auf externe
Datenquellen.
Möglichkeit zur identischen Rückgabe des eingegebenen Dokuments – Es sollte möglich
sein, Dokumente in genau der Form abzurufen, in der sie in eine native XML-Datenbank
eingegeben wurden. Dies ist sowohl in Natix als auch in Tamino möglich.
Indizes – Im Interesse einer schnelleren Ausführung von Anfragen sollte auch eine native
XML-Datenbank Indizes führen. Dies ist sowohl bei Natix als auch bei Tamino der Fall.
Bevor wir uns der Realisierung dieser Merkmale im Detail zuwenden werfen wir noch einen
kurzen Blick auf relevante und systemunabhängige Konventionen aus dem W3C-Kontext.
2. Globale Vorgaben für Progammierschnittstellen (APIs)
2.1. DOM (W3C)
Das Document Object Model (DOM) ist die objektorientierte Spezifikation einer
Programmierschnittstelle zum Zugriff auf HTML-Dokumente (DOM HTML) und XMLDokumente (DOM Core). Das DOM liegt zur Zeit (Juni 2002) im Entwurf vor und ist auf der
Webpage von W3C veröffentlicht [3]. Historisch enstand es als Spezifikation for JavaProgramme und JavaScript Scripte, die portabel zwischen den Web-Browsern sein sollten.
Die heute vorliegende Version ist das Ergebnis einer Arbeitsgruppe bei W3C, an der auch
VertreterInnen von kommerziellen Anbietern für HTML- und XML-Editoren sowie für
Dokumentrepositorien teilnahmen. Erkennbar ist auch die Handschrift von Charles Goldfarb,
einen der Urheber der ersten Markup Language, in der Berücksichtigung von SGML-Groves2
sowie des HyTime-Standards3. Hinzu kommen Einflüsse aus firmenspezifischen
1
die von Bourret in diesem Kontext diskutierte Speicherung externer Entitäten ist nicht Gegenstand
der vorliegenden Arbeit.
2
Ein SGML-Grove ist ein geparstes SGML-Dokument [6]
3
HyTime ist ein älterer Standard für die Architektur von Adressierung und Verknüpfung (linking),
scheduling, und renditions [7]
von Monika Wienbeck
Seite 10 von 22
Objektmodellen aus APIs für XML- und SGML-Editoren und Repositorien. ([3] Abschnitt
„What is the DOM?“).
Das DOM enthält
-
Interfaces und Objekte, die zur Repräsentation und Manipulation eines Objekts
verwendet werden
-
die Semantik dieser Interfaces und Objekte – einschließlich des Verhaltens und der
Attribute
-
die Beziehung zwischen und Zusammenarbeit von diesen Interfaces und Objekten.
Insbesondere enthält es Funktionen, die festlegen, wie Objekte manipuliert werden können.
DOM entspricht damit der Konzeption von objektorientierten Programmiersprachen, wonach
Daten in Objekten gekapselt sind. In den Interfaces bleibt sogar die Umsetzung in konkrete
Objekte offen. So gilt im wesentlichen: createX()-Methoden ersetzen Konstruktorenaufrufe;
get()/set()-Methoden ersetzen den Zugriff auf Attribute; DOM-Applikationen können
zusätzliche Methoden zur Verfügung stellen.
DOM macht keine Vorgaben in Bezug auf die Implementierung. Es geht um die Herstellung
eines strukturellen Isomorphismus, d.h. wenn zwei DOM-Implementierungen verwendet
werden, um eine Repräsentation desselben Dokuments zu erzeugen, dann sollen sie
dasselbe Strukturmodell entsprechend dem XML Information Set erzeugen. Variationen
sollen nur bei den whitespaces entstehen, da sich das bei der Verwendung unterschiedlicher
Parser nicht ausschließen lässt.
In den Appendices von DOM sind u.a. die entsprechenden IDL-Definitionen sowie die
Bindungen an Java und an ECMA Script angegeben.
2.2. SAX
SAX ist eine eventbasierte Standard-API für XML (Simple API for XML). Der Java-Code und
die Spezifikation sind unter http://www.saxproject.org publiziert und können dort frei
heruntergeladen werden.
2.3. Relevante ‚Open issues‘, z.B. Views
In den Publikationen des W3C gibt es keine Vorgaben für Views auf XML-Dokumente.
Als Abfragesprache wird bei W3C zur Zeit XQuery etabliert. Die Gestaltung von Anfragen
über Menge von XML-Dokumenten ist jedoch nicht Gegenstand der XML-Empfehlung.
Insbesondere gibt es keine Vorgaben oder Vorschläge für die Indizierung von Dokumenten
oder den Aufbau von Suchpfaden.
3. Natix
Natix wurde in C++ auf UNIX-Plattformen entwickelt. Auf der data ex machina Webpage [18]
liegt zur Zeit eine Natix-Demoversion für Linux ab Kernel 2.2.16 bereit, diese Demoversion
verlangt, dass das Betriebssystem CODA unterstützt. Geplant war bereits im Jahr 2001 eine
Windows-Version und Java-Anbindungen ([4], S. 8). Die Windows-Version wird von der
Herstellerfirma data ex machina derzeit aufgrund mangelnder Nachfrage nicht weiterverfolgt
(mdl. Auskunft G. Moerkotte am 17. Juni 2002, mwi).
3.1. Architektur
Die Architektur von Natix besteht aus drei Ebenen:
Anbindungsebene: Anwendungen greifen auf Natix über die Anbindungsebene zu. Hier
liegen die Treiber, die unter anderem erforderlich sind, um auf externe XML-Quellen bspw.
von Monika Wienbeck
Seite 11 von 22
durch einen SAX-Import zuzugreifen, ausserdem ein ODBC-Apparat zum Zugriff auf
relationale Datenquellen. Schnittstellen gibt es für den Java DOM-Treiber, den C++-DOMTreiber, den SAX-Treiber sowie für Dateisystemtreiber. ([4], S. 8)
Natix Engine Interface: Hier koordiniert Natix die Datenbankdienste, erhält Aufträge wie
Compiliation (Prepare), den Auftrag zur Auswertung einer Anfrage sowie zum Import bzw.
Export von Dokumenten und reicht sie an die beteiligten Datenbankdienste weiter.
Datenbankdienste: Query Compiler, Natix Virtual Machine, Transaktionsverwaltung und
Objekmanager. Der Query Compiler übersetzt Anfragen für die Natix Virtual Machine. Zur
Zeit (Juni 2002) sind Query Compiler für XPath und für die XQuery-Variante NQL verfügbar.
Die Natix Virtual Machine dient der Auswertung von Anfragen. Sie simuliert einen Prozessor
und stellt dafür einen Befehlssatz, bestehend aus Operationen auf Basistypen und Befehlen
zum Zugriff auf Dokumente, zur Verfügung. Die Natix Virtual Machine hat die Möglichkeit,
direkt auf die Hintergrundspeicherrepräsentation der XML-Dokumente zuzugreifen. Die
Transaktionsverwaltung in Natix stellt die Infrastruktur für den Mehrbenutzerbetrieb zur
Verfügung. Nähres dazu Abschnitt 3.3.
Speicherebene: Aufgabe ist die Verwaltung der persistenten Daten. Die NatixSpeicherebene unterstützt Standard-Indexstrukturen wie B-Bäume und invertierte Listen.
Noch in Planung ist ein Index, der neben absoluten Positionen auch Zusatzinformationen
über den Kontext liefert. ([4] S. 8) Wir gehen darauf in den Abschnitten 3.3 und 3.4 näher ein.
Abbildung 8: Architektur von Natix. Quelle: [4]
3.2. Organisation der Speicherung von XML-Baumstrukturen
Natix verwendet ein proprietäres, modellbasiertes sog. hybrides Speicherungsformat4. Ein
Dokument wird so lange wie möglich als Datensatz auf eine Speicherseite geschrieben.
Natix erlaubt es auch, mehrere Datensätze auf eine Hintergrundseite zu schreiben ([4], S. 9).
Daher ist der erste Schritt bei Überschreitung der Seitengröße, nach einer ausreichend
4
Die Bezeichnung „hybrides Speicherungsformat“ ist in der Literatur nicht eindeutig, so verwendeten
bspw. Ingo Macherius, Peter Fankhauser und Thomas Tesch bei ihrer Präsentation vor der GMD im
September 2000 den Begriff „Hybride Speicherung“ für eine kombinierte Lösung, bei der strukturierte
Daten in einem RDBMS abgelegt werden und die semistrukturierten Daten in XML-BLOBs. [11]. Wir
verwenden im folgenden den Begriff „hybrides Speicherungsformat“ im Sinne von Fiebig und
Moerkotte.
von Monika Wienbeck
Seite 12 von 22
großen freien Seite zu suchen. Wenn dieser Versuch scheitert, dann wird der Baum in
mehrere Datensätze gesplittet.
Ein Natix-Datensatz ist eine serielle Repräsentationen einer DOM-Baumstruktur, also ein flat
stream. Erst mit dem Datensatzsplit erfolgt ein metamodeling, d.h. eine Abbildung der
Struktur des Dokuments in strukturierte Teile der Datenbank[9].
Die Vorgaben für den Split-Prozess sind teilweise konfigurierbar: Seitengröße (max. 64 KB)
als Schwellenwert für die Größe eines Datensatzes; das Verhältnis der Größe von rechtem
und linkem Teilbaum (split target), die Abweichungstoleranz für dieses Verhältnis (split
tolerance). Natix sucht einen Pfad (separator) durch den Dokumentenbaum bis es den
Teilungsknoten erreicht. Das split target gibt dabei anschaulich gesprochen die Schräglage
des Teilungspfades gegenüber der Vertikalen vor, d.h. der konfigurierte Wert bestimmt, ob
Natix immer den mittleren Knoten wählt oder bspw. immer den linken Knoten im rechten
Drittel aller Kindknoten. Die Abweichungstoleranz gibt insbesondere eine Minimalgröße für
die abteilbaren Teilbäume vor: Solange der Teilbaum unterhalb des zunächst ermittelten
Teilungspunktes kleiner ist, als die Konfiguration der split tolerance erlaubt, dann wird der
Teilungspfad um einen Knoten verkürzt.
Nachdem der Teilungspfad bestimmt ist, überträgt Natix für jeden Knoten des
Teilungspfades jeweils die rechten und die linken Teilbäume auf jeweils eine neue Seite als
sog. Partitions-Datensatz (partition record). Bei nicht-binären Bäumen besteht grundsätzlich
das Problem, dass es einen Wald rechts bzw. links von Knoten des Teilungspfades geben
kann. In solchen Fällen setzt Natix ein sog. Gerüst-Aggegat (scaffolding aggregate) als
künstliche Wurzel dieses Waldes ein. An der ursprünglichen Position der umkopierten
Teilbäume werden sog. Platzhalter (proxies) eingerichtet, die den abgetrennten Teilbaum
durch seine RID repräsentieren [9]. Platzhalter fallen ebenfalls unter die Kategorie der
Gerüst-Objekte
Um die Gerüst-Metapher zu vervollständigen nennen Kanne und Moerkotte die Objekte, die
XML-Dokumentenknoten repräsentieren, „Fassadenobjekte“. Natix dekonstruiert sozusagen
Häuser (= Dokumente), und setzt ein Gerüst aus inhaltsleeren Aggregaten und Platzhaltern
und ein, um die Fassade an den Bruchstellen zusammenzuhalten.
Nehmen wir zum Beispiel an, die Elemente des Dokuments tempest.xml würden
chronologisch eingegeben. Nehmen wir weiterhin an, die Seitengröße wäre so eingestellt,
dass bei Eingabe des ersten PERSONA-Elements der Schwellenwert überschritten wäre.
Nehmen wir weiterhin an, das split target sei so konfiguriert, dass für den Teilungspfad
immer der mittlere Knoten gewählt wird, und dass kein einzelner Knoten von einem Baum
abgespalten wird. (Letzteres ist eigentlich eine Redundanz gegenüber den
Grundeinstellungen: Um einer zu starke Fragmentierung entgegenzuwirken lässt Natix die
Abspaltung einzelner Knoten grundsätzlich nicht zu.)
von Monika Wienbeck
Seite 13 von 22
Abbildung 9: Bestimmung des Teilungspfades für tempest.xml. r1 steht für eine
Speicherseite
Aufgrund der Konfigurationsparameter endet der Teilungspfad bei dem fm-Knoten. Um die
Kindsknoten als Ganzes adressierbar zu machen, werden die p-Knoten unter einem GerüstAggregat zusammengefasst:
Abbildung 10: Die Anfangssequenz von tempest.xlm nach dem Datensatzsplit
In Natix hat die Wurzel eines Datensatzes hat die Funktionalität eines standalone-Objekts.
Sie enthält alle Knoten des Teilbaums als eingebettete Objekte (embedded objects) sowie
einen header. Dieser header enthält den Inhaltstyp (aggregate / literal / proxy), die Größe
von Monika Wienbeck
Seite 14 von 22
des Objekts5 sowie den Zeiger auf den Elternknoten. Bei Fassadenobjekten kommt die
Information über den logischen Typ hinzu. Tag- und Attributnamen von Elementen werden in
Natix in eine Symboltabelle usgelagert. Dadurch werden für die Information über
Objektgröße und Position des Elternknotens insgesamt weniger als 2 Byte benötigt, die
gesamte Strukturinformation eines Datensatzes kann platzsparend in einem 8-Byte-header
untergebracht werden. ([4] S. 9 und [9] S. 20)
Jedes der eingebetteten Objekte enthält selbst einen header und einen Inhalt. Als Inhalt
kommen weitere eingebettete Objekte (ggf. repräsentiert durch einen Platzhalter) oder
Literale in Frage. Die zulässige Formate für Literale waren 1999 String, 8/16/32/64-Bit
Integer, Float und Uniform Resource Identifier (URI). Alle Knoten, die noch weitere Knoten
enthalten, heissen bei Kanne und Moerkotte aggregate node (etwa: umfassender Knoten).
(Appendix A in [9]).
Die Speicherung der ersten vier Zeilen aus tempest.xml liesse sich demnach schematisch
wie folgt darstellen:
Byte-Repräsentation
10 Byte
6 Byte
6 Byte
The Tempest
Header
Inhalt
String-Literalknoten
Header
Inhalt
TITLE-Knoten
Header
Strukturinformation
Inhalt
PLAY-Knoten
Abbildung 11: Schematische Darstellung eines Datensatzes in Natix
Der Aufbau von Datensätzen wird in Natix nicht zuletzt durch die sog. split matrix gesteuert.
Hier kann festgelegt werden, welche Elementtypen niemals und welche möglichst oft
gemeinsam in einem Datensatz stehen sollten, und für welche Kombinationen von
Elementtypen der Natix-Teilungsalgorithmus entscheiden soll ([9], S. 10)
3.3. Transaktionsverwaltung und Speicherebene in Natix
Die Transaktionsverwaltung gewährleistet in Natix die ACID-Eigenschaften Atomicity,
Consistency, Isolation und Durability. Sie enthält u.a. Komponenten zur Isolation der
Transaktionen durch Verwaltung der Sperren auf Objekten sowie die Recovery, die eine
Logdatei führt und damit zuständig für die Wiederherstellung der Daten bei Systemausfall
oder Abbruch einer Transaktion ist.
In Natix können grundsätzlich mehrere NutzerInnen – wenn auch mit Einschränkung –
gleichzeitig an einem Dokument arbeiten ([4] S. 10). Zum einen ermöglicht es das hybride
Speicherungsformat, Sperren auf der Datensatzebene anzulegen und somit auf Teilbäume
zu beschränken. Zudem stehen mehrer Protokolle zur Auswahl: Vier 2PL-basierte Protokolle
(Doc2PL, Node2PL, NO2PL und OOPL), die mit unterschiedlicher Granularität Sperren auf
Knoten bzw. Zeigern anlegen; zusätzlich das zeitstempel-basierte Protokoll XTO und ein
neues Protokoll, die sog. dynamische Commit-Anordnung, XCO. Grob gesagt stehen
Aufwand und erreichbare Flexibilität bei diesen Protokollen im umgekehrten Verhältnis. XCO
setzt am wenigsten Hindernisse für Operationen auf angrenzenden Knoten, Doc2PL setzt
demgegenüber Sperren auf Dokumentenebene an und ist damit das aufwandsärmste
Protokoll [9]. Die Implementierung der Protokolle erfolgt in Natix generisch auf API-Ebene,
d.h. bei jedem Zugriff auf Daten über die Anbindungsebene kann spezifiziert werden,
welches Protokoll für die entsprechenden Transaktionen zu verwenden ist.
5
als Objekt gilt hier die Einheit aus Knotenrepräsentation und Inhalt
von Monika Wienbeck
Seite 15 von 22
Zur Verbesserung der Performance hat Natix einen Objekt-Cache in der
Transaktionsverwaltung ([4], S. 9) sowie einen Cache-Mechanismus auf der
Speicherungsebene. Letztere enthält ausserdem eine Abstraktionsschicht für
Massenspeichergeräte
wie
Dateien
und
Festplattenpartitionen.
In
solchen
Festplattenpartitionen sind in Natix die verschiedenen Typen von Segmenten organisiert. So
gibt es ein XML-Segment, ein B-Baum-Segment sowie jeweils ein Segment für die im
nachfolgenden Abschnitt vorgestellten Indizes und Relationen. Die Speicherungsebene ist in
der Lage, auf Massenspeichergeräte wahlfrei, d.h. mit Random Access, zuzugreifen ([4],
S. 8).
3.4. Abfragen und Views
Die Effizienz von Abfragen über große Datenmengen lässt sich durch Indizierung der Daten
verbessern. Ein reiner Wortindex reicht jedoch nicht aus, wenn die hierarchische Struktur der
XML-Dokumente in Abfragen berücksichtigt werden soll. In Natix ist daher ein Segmenttyp
im Speicher für Relationen vorgesehen, auf dem die eXtended Access Support Relations
(XASR) abgelegt werden kann. XASR funktioniert in Kooperation mit vier weiteren
Komponenten, nämlich
1. dem DocDescriptor, der u.a. eine ID und den Uniform Resource Identifier (URI) für die
indizierten Dokumente enthält
2. dem Lexikon, in dem alle suchbaren Wörter indiziert sind, und zwar inklusive der Namen
der Elemente und der Textfelder
3. dem FTI-Index, der Zeilen in der DocDescriptor-Relation mit eine Strukturinformation aus
diesem im XASR verknüpft
4. der FNI-Index, der Einträge aus dem FTI-Index übernimmt und durch die Referenz auf
einen Lexikoneintrag ergänzt
Die in XASR enthaltene Strukturinformation umfasst den Namen des Knotens (ename), die
Nummerierung des Knotens bei schrittweisem Durchlaufen des Baums mit dem Algorithmus
für depth-first traversal (dMin und dMax) sowie die dMin des Elternknotens (parent_dMin).
Die Anfrage erfolgt dann in SQL. So würde beispielsweise die folgende Anfrage die URI aller
indizierter Dokumente liefern, die im Titel das Wort „Tempest“ enthalten.
SELECT DISTINCT dd.uri
FROM DocDesc dd
WHERE EXISTS( SELECT *
FROM
XASR p, XASR n,
Lexicon lp, Lexicon ln,
FTI fti, Lexicon lf
WHERE p.docID = n.docID
AND
p.dMIN = n.parent_dMIN
AND
p.eTYPE = lp.number
AND
lp.word = „PLAY“
AND
n.eTYPE = ln.number
AND
ln.word = „TITLE“
AND
fti.docID = p.docID
AND
fti.dMIN = n.dMIN
AND
fti.number = lf.number
AND
lf.word = „Tempest“
AND
dd.docID = p.docID)
In der WHERE-Phrase stehen alle docID-Variablen in einer Identitätsbeziehung, mit den
Teilausdrücken p.dMIN = n.parent_dMIN und fti.dMIN = n.dMIN werden dahingegen die
Hierarchiebeziehung simuliert.
von Monika Wienbeck
Seite 16 von 22
Eine Reindizierung von Dokumenten erfolgt in Natix nicht automatisch. Vielmehr ist der
Auftrag zur Reindizierung der Datenbank über die Anbindungsebene mitzuteilen. Es ist
allerdings möglich, Reindizierungs-Aufträge auf einzelne Dokumente zu beschränken, bspw.
auf das zuvor modifizierte Dokument.
3.5. Performance
Kanne und Moerkotte haben in Natix Performance-Vergleiche mit zwei unterschiedlichen
Belegungen der split matrix durchgeführt:
-
Die Belegung „Record:Node 1:1“ gibt vor, dass jedes Objekt ein standalone ist.
-
Die Belegung „Record:Node 1:n“ lässt dem Natix-Teilungsalgorithmus freie Hand bei der
Einrichtung von Datensätzen.
Ein zusätzlicher Parameter ist die Repräsentation der Baumstruktur im Speicher. Im Beispiel
für die Arbeitsweise des Teilungsalgorithmus in Abschnitt 3.2. hatten wir implizit
vorausgesetzt, dass der Baum in pre-order repräsentiert ist.
Jeder nicht-binäre Baum lässt sich aber auch in eine binäre Repräsentation umwandeln, den
sog. threaded binary tree [10]. Der Elternknoten erhält dabei nur die Verbindung zum linken
Kind, die übrigen Kinder werden als rechtes Kind des vorher linken Nachbarn eingesetzt.
Eine solche „Breite-zuerst“-Baumstruktur würde sowohl für den Datensatz als auch für den
Split ein anderes Ergebnis liefern:
Abbildung 12: Ermittlung des Teilungspfades in der binären Repräsentation von
tempest.xml
von Monika Wienbeck
Seite 17 von 22
Der Split kommt ohne Gerüst-Aggretate aus und verfestigt insbes. die Nachbarschaftsbeziehungen der Knoten:
Abbildung 13: Split der binären Repräsentation von tempest.xml
Ausgehend davon, dass ein solcher struktureller Unterschied Auswirkungen auf die
Performance haben muss, definierten Kanne und Moerkotte einen zweiten Parameter:
-
„Append“: Repräsentation in pre-order
-
„Incremental Update“: binäre Repräsentation als threaded binary tree
Dritter Parameter in der Untersuchung ist die konfigurierte Seitengröße von 2K bis 32K.
Ziel von Kanne und Moerkotte war es zu überprüfen, ob der Teilungsalgorithmus in Natix
tatsächlich nennenswerte Vorteile bringt. Als Material dient die komplette XML-Version von
Shakespeares gesammelten Werken. Über die verwendete Dokumentenversion gibt die
Kannes und Moerkottes Publikation der Ergebnisse keine Auskunft.
Es sei hier nur exemplarisch das Ergebnis für Einfügeoperationen vorgestellt. Bei beiden
Konfigurationen der Matrix bringt hier die pre-order-Repräsentation eine klaren Vorteil. Die
Konfiguration Record:Node 1:1 mit pre-order-Repräsentation ist bei kleinen Seitengrößen der
Konfiguration Record:Node 1:n bei binärer Repräsentation überlegen. Das beste Ergebnis
liefert allerdings die 1:n-Konfiguration bei Seitengrößen ab ca. 7K.
von Monika Wienbeck
Seite 18 von 22
Abbildung 14: Performancemessung für Einfügeoperatinen in Natix. Quelle: [9]
Bei den Ergebnissen zeichnet sich bei allen Anfrage-Operationen sowie bei der einfachen
Durchquerung der Dokumente ein signifikanter Vorteil für die binäre Repräsentation in
Kombination mit einer Konfiguration, die die volle Ausnutzung des hybriden
Speicherungsformat zulässt. Bei der einfachen Durchquerung ist bei Seitengrößen unter 10K
eine Konfiguration mit Record:Node 1:1 günstiger, jedoch lässt sich mit Seitengrößen >10K
für alle Konfigurationen eine kürzere Bearbeitungszeit erzielen. Unabhängig von der
Seitengröße ist dagegen die Performance für die exemplarische Anfrage mit kleinteiligem
Ergebnis bei Konfiguration Record:Node 1:n und binärer Repräsentation für alle der
getesteten Seitengrößen-Einstellungen um 30 bis 50% besser als die Alternativen.
(Gegenstand dieser kleinteiligen Anfrage war hier die Wiederherstellung der textuellen
Repräsentation des ersten SPEECH-Elementes in jeder Szene.) Auch der Speicherplatzbedarf
wurde verglichen. Er ist bei Seitengrößen um die 17K für das verwendete Material für alle
Konfigurationen relativ niedrig, bei pre-order-Repräsentation und 1:n-Konfiguration wächst er
allerdings mit Seitengrößen >17K wieder leicht an.
3.6. Diskussion
Obwohl bei Natix noch – beispielsweise bei den Query Compilern – Entwicklungsbedarf
besteht ist es bemerkenswert, dass ein kleines akademisches Team und ein daraus
ausgegründetes Unternehmen ausreichte, um diese Entwicklung bereits nach wenigen
Jahren zur Produktionsreife zu bringen. Die API-Treiber ermöglichen es, bereits mit
Kentnissen der offen zugänglichen und in dem W3C-Umfeld weithin akzeptierten Standards
DOM und SAX Anwendungen auf dieser Datenbank zu programmieren. Ein tieferes
Verständnis von Natix ist daher bei der Optimierung der anwendungsbezogenen
Konfiguration, dem Einsatz von Protokollen für Transaktionen, der Reindizierung sowie für
die Programmierung von Oberflächen für Anfragen an die Indextabellen erforderlich. Die
Indexstruktur mit Lexikon, XASR, FNI und FTI bietet sehr flexible Suchmöglichkeiten, muss
von Monika Wienbeck
Seite 19 von 22
allerdings auch die bisher offenbar fehlende Strukturierung der Daten in Collections
ersetzen. Konzeptionell wirken die bisherigen Publikationen über Natix sehr kohärent,
insbes. das Speicherungsmodell ist überzeugend. Jedoch gibt es in der uns bekannten
Literatur keine statistische Grundlage, um die tatsächlichen Performance-Vorteile zu
beurteilen. Insbesondere fehlt es an einer vergleichenden Untersuchung mit einer
konkurrierenden Datenbank.
4. Tamino
Zielsetzung bei Tamino ist eine integrierte XML-Sicht auf strukturierte, semi- und
unstrukturierte Daten. Tamino ist darüber hinaus ein Instrument, um Daten aus externen
Quellen (z.B. aus relationalen Datenbanken) in Views zu integrieren oder als Bausteine für
neu zu erstellende XML-Dokumente zu verwenden.
Der Zugriff auf Tamino erfolgt im Gegensatz zu Natix in der Regel nicht über APIs, sondern
über HTTP. Das Dokument oder das Kommando erreicht den Tamino Web Server über die
Schnittstelle XPort. Anschließend wird es von der XML-Maschine akzeptiert. Letzere wertet
die Kommandos auf Grundlage der Meta-Daten im Tamino-Repositorium aus. Die
eigentliche Bearbeitung findet in der XML-Engine statt.
Für die Kommunikation mit auf externen Quellen hat Tamino zwei zusätzliche Schnittstellen,
die direkt mit der XML-Engine in Verbindung stehen: Die bidirektionale Übertragung von
XML-Dokumenten oder -befehlen zwischen externen Applikationen und Tamino kann über
die sog. X-Tension erfolgen, die direkt aus einer Server Extension Daten austauscht.
Daneben stehen APIs für den bidirektionalen Austausch mit externen Datenbanken zur
Verfügung. Hier ist die Kommunikation über eine Komponente namens X-Node realisiert.
Tamino unterstützt DOM, JDOM und SAX.
In den nachfolgenden, derzeit (Juni 2002) auf der Webpage von Software-AG publizierten
Schema der Architektur von Tamino sticht die Komponente Object Processor & Object
Composer als das zentrales Element heraus. Hier findet die Vermittlung zwischen Query
Interpreter und Daten statt.
Abbildung 15: Architektur von Tamino. Quelle: [17]. Beschriftung „XML-Machine“ und
„XML-Engine“ von mwi.
Zu den Aufgaben des Document Composers gehört es, zur Laufzeit die
Dokumentenschemata (document schemas) zu erstellen. Diese Schemata werden als „Data
Maps“ verwaltet. Dokumentenschemata sind im Data Map hierarchisch einer weiteren
von Monika Wienbeck
Seite 20 von 22
Gruppierungsebene untergeordnet, den Collections. Beim Übertragen von Dokumenten prüft
Tamino, ob das Dokument als Mitglied einer Collection deklariert wurde. Wenn ja, dann
sucht Tamino innerhalb der Collection aufgrund des Typs des Dokumenten-Wurzelelements
nach einem passenden Schema. Kann die Dokumentenstruktur gegen ein Schema verifiziert
werden, dann bleibt diese Information im Data Map erhalten.
Über die im Data Map gespeicherte Strukturinformation hinaus stellt Tamino drei Typen von
Indizes zur Verfügung:
-
wertbasierte Indizes zur Unterstützung von datenzentrierten Anfragen
-
Textindizierung zur Unterstützung von dokumentenzentrierten Anfragen
-
Strukturindizes zur Spezifikation von Suchbereichen
Grundsätzlich sind in Tamino auch Volltextsuchen möglich, die das Markup ignorieren.
Die Speicherung in Tamino ist modellbasiert, es ist kein Konzept für eine Abbildung von
Dokumentenstrukturen in flat streams publiziert.
5. Ausblick
Natix und Tamino sind Teil einer relativ jungen Entwicklung, Robert Bourret stellt sie in
einem Überblicksartikel zum status quo der nativen XML-Datenbanken zusammen mit
28 mehr oder weniger vergleichbaren Produkten vor [2]. Aber bereits im Vergleich dieser
beiden Datenbanken zeichnen sich unterschiedliche Richtungsentscheidungen ab: Natix ist
auf AnwendungsprogramiererInnen zugeschnitten, es sind vor allem Informationen publiziert,
die ein analytisches Verständnis der Datenbank ermöglichen und bspw. technische
Entscheidungen bei den veränderlichen Parametern unterstützen. Diese Strategie veranlasst
Fiebig, Kanne und Moerkotte (data ex machina), zu schreiben, dass die Dateisystemtreiber
bereitgestellt werden, damit „die eventuell bestehende Hürde beim Einsatz eines neuen
DBMS leichter geommen werden kann“ ([4] S. 9). Dahingegen wird Software AG bei der
Vermarktung von Tamino recht konkret, wenn es um externe, zu integrierender Geräte und
Systeme geht. Vielleicht ist hier auch eine Ursache für den höheren Bekanntheitsgrad und
den größeren kommerziellen Erfolg von Tamino. Gleichwohl fehlt es zu einem tatsächlichen
Leistungsvergleich an Daten.
Native XML-Datenbanken werden zur Zeit werden zur Zeit auf einem Markt angeboten, der
im wesentlichen bereits Lösungen zur Bereitstellung und Organisation von Daten in
relationalen
Datenbanken
oder
in
Dateisystemen
einerseits
und
in
Dokumentenverwaltungssystemen andererseits gefunden hat. Niedrigere Kosten und ein
erheblich geringerer Aufwand für die Datenbankadministration und –programmierung
könnten den nativen XML-Datenbanken in der näheren Zukunft ebenso Aufwind geben wie
die ungleich viel höhere Flexibilität bei der Definition von Schemata. Letzteres macht native
XML-Datenbanken auch interessant für die Datenbankintegration – eine Chance, die wohl in
der schematischen Darstellung der Architektur von Tamino bewusst hervorgehoben ist.
Eines der interessantesten Potentiale von nativen XML-Datenbanken möglicherweise in der
Konkurrenz zu Dokumentenverwaltungssystemen. Längerfristig könnten gerade hier das
Problem der Verfügbarkeit vorhandenen Wissens ebenso den Wunsch nach effizient
abfragbaren Repositorien führen wie der Wunsch nach möglichst fokussierter Präsentation
der gesuchten Information in den Ergebnissen von Anfragen.
6. Literatur
[1] Ronald Bourret. XML and Databases. Stand von Februar 2002. Erhältlich unter
http://www.rpbourret.com/xml/XMLAndDatabases.htm
[2] Ronald Bourret. XML Database Products: Native XML Databases. Stand vom Februar
2002. Erhältlich unter http://www.rpbourret.com/xml/ProdsNative.htm
von Monika Wienbeck
Seite 21 von 22
[3] Lauren Wood et al. (Hrsg.). W3C Document Object Model (DOM) Level 1 Specification,
Version 1.0, W3C Working Draft 29 September 2000. W3C Recommendation, erhältlich
unter: http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929
[4] Thorsten Fiebig, Carl-Christian Kanne, Guido Moerkotte. Natix – ein natives XML-DBMS.
Datenbankspektrum 1 (2001), 5-13, 2001
[5] Thorsten Fiebig, Guido Moerkotte. Evaluating Queries on Structure with eXtended Access
Support Relations
[6] Charles F. Goldfarb’s SGML Source: InFrequently Asked Questions (InFAQs),
Überarbeitung
vom
26.
Dezember
2001,
erhältlich
unter
http://www.sgmlsource.com/infaqs.htm
[7] Charles F. Goldfarb et al. A Reader’s Guide to the HyTime Standard. Überarbeitung vom
25. Juni 1997, erhältlich unter http://www.hytime.org/papers/htguide.htm
[8] S. Helmer, Carl-Christian Kanne, Guido Moerkotte. Isolation in XML Bases. Technical
Report of the University of Mannheim 15, 2001
[9] Carl-Christian Kanne, Guido Moerkotte. Efficient storage of XML data. Technical Report
of the University of Mannheim 16, 2001
[10] Donald E. Knuth. The Art of Computer Programming, Band 1, Kapitel 2.3.2. Addison
Wesley, 3. Auflage, 2000
[11] Ingo Macherius, Peter Fankhäuser, Thomas Tesch. Modul 3: XML Datenmanagement.
Folien zum Vortrag auf der 30. Jahrestagung des GI e.V. in Berlin, 19. September 2000,
erhältlich unter http://swt.cs.tu-berlin.de/informatik2000/skripte/xml-datenbank.pdf
[12] Gerhard Michal (ed.). Biochemical Pathways. Spektrum Akademischer Verlag,
Heidelberg, 1999.
[13] Natix: Ein natives Datenbanksystem für XML, erhältlich unter http://pi3.informatik.unimannheim.de/staff/mitarbeiter/moer/natix.html
[14] Harald Schöning. Tamino – a DBMS Designed for XML. IEEE 2001
[15] Harald Schöning, Jürgen Wäsch. Tamino – An Internet Database System. In: C. Zaniolo
et al. (Hrsg.): EDBT 2000, LNCS 1777, pp. 383-387, 2000
[16] UNC Sunsite. XML Sample Documents. Erhältlich unter: http://metalab.unc.edu/pub/suninfo/standards/xml/eg/
[17]
Software-AG:
Architecture
of
http://www.xmlstarterkit.com/tamino/architecture.htm
Tamino.
Erhältlich
[18] data ex machina-Webpage: http://www.dataexmachina.de/natix.html
von Monika Wienbeck
Seite 22 von 22
unter:

Seminar 1912: XML und Datenbanken

Transcription

Similar documents

s/w-Version