Seminar 1912 im Sommersemester XML und Datenbanken. Präsenzphase: 28. und 29. Juni Praktische Informatik IV

Transkript

1 Seminar 1912 im Sommersemester 2002 XML und Datenbanken Präsenzphase: 28. und 29. Juni 2002 Praktische Informatik IV

2 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

3 Übersicht XML Seminar XML und Datenbanken Lehrgebiet Praktische Informatik IV, Prof. Dr. Güting Seminararbeit im SS 2002 Autor: Edmund Buchbinder

4 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr Inhaltsverzeichnis 1. EINLEITUNG 4 2. GESCHICHTE UND ABGRENZUNG VON XML Geschichte von XML Abgrenzung und Gemeinsamkeiten mit SGML Abgrenzung und Gemeinsamkeiten mit HTML Abgrenzung und Gemeinsamkeiten mit XHTML 5 3. XML Grundkonzept Auszeichnungen im XML Aufbau eines XML-Dokuments XML-Körper wichtige Begriffe und Hinweise für XML wichtige Begrifflichkeiten Well-formed Dokumente vs. Valide Dokumente well-formed Dokument Valide Dokumente DTD Was ist eine DTD Vor- und Nachteile einer DTD Aufbau einer DTD 11 REFERENZ IM INHALT 11 REFERENZ IM ATTRIBUT-WERT 11 AUFTRETEN ALS ATTRIBUT-WERT 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 XLink und XPointer XML Konvertierungen CSS1 und CSS XSL 23 Edmund Buchbinder Seite 2/33

5 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr XML-TOOLS Darstellung von XML in Browsern XML-Editoren XML-Prozessoren EINSATZMÖGLICHKEITEN IN DER PRAXIS VORSTELLUNG PROJEKT XML ALS FORMAT FÜR INSTANDHALTUNGSANWEISUNGEN DER DB AG Anforderungen Lösung Aktueller Projektstand Erfahrungen aus dem Projekt ZUSAMMENFASSUNG UND AUSBLICK VERZEICHNISSE Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis ANHANG Anhang:vollständige XML-Grammatik in Extended-Backus- Nauer-Form 30 Edmund Buchbinder Seite 3/33

6 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 abgerufen werden. Im folgenden werden die Vorläufer von XML sowie ähnliche Konzepte wie z.b. HTML kurz vorgestellt 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 Seite 4/33

7 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 SGML- DTDs), 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 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 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 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 Seite 5/33

8 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr Tabelle 1: Auszeichnungen im XML Auszeichnungstyp Starttags Schlusstags Auszeichnungssyntax <elementname [attributes]...</elementname> Leere-Element-Tags <elementname [attributes] /> Entity-Referenzen &entityname; oder %parameterentityname; Zeichenreferenzen Kommentare <! comment --> &#decimalnumber; oder &#hexnumber Delimitierer des CDATA-Abschnitts <![CDATA[ cdata stuff ]]> Dokumenttyp-Deklaration <!DOCTYPE name externel ID? [DTD Stuff]> Verarbeitungsanweisungen <?processorid data?> XML-Deklaration <?xml version encoding standalone?> 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 Backus- Nauer-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 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 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 XML- Datei 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 Seite 6/33

9 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr <?xml version="1.0" encoding="utf-8"?> 2. <!DOCTYPE addressbook SYSTEM "addressbook.dtd" > 3. <?xml:stylesheet type="text/xsl" href="demo.xsl"?> 4. <addressbook> 5. <person employee-number="a0000" family-name="gates" first-name="bob"> 6. <contact-info> 7. <!--Confidential--> 8. </contact-info> 9. <address city="los Angeles" street="pine Rd." number="1239" state="ca"/> 10. <job-info is-manager="no" job-description="manager" employee-type="full-time"/> 11. <manager employee-number="a0000"/> 12. </person> 13. <person employee-number="a7000" family-name="brown" first-name="robert" middleinitial="l."> 14. <contact-info> 15. < 16. <home-phone number=" "/> 17. </contact-info> 18. <address city="new York" street="118 St." number="344" state="ny"/> 19. <job-info is-manager="yes" job-description="group Leader" employee-type="full-time"/> 20. <manager employee-number="a0000"/> 21. </person> 22. <person employee-number="a7890" family-name="depaiva" first-name="kassie" middleinitial="w."> 23. <contact-info> 24. <!-- Kassie's agent phone: > 25. </contact-info> 26. <address city="los Angeles" street="pine Rd." number="1234" state="ca"/> 27. <job-info is-manager="no" job-description="actor" employee-type="full-time"/> 28. <manager employee-number="a0000"/> 29. <misc-info>one of the most talented actresses on Daytime. 30. Kassie plays the devious and beautiful Blair 31. Cramer on ABC's "One Life To Live."</misc-info> 32. </person> 33. <person employee-number="a7987" family-name="smith" first-name="joe"> 34. <contact-info> 35. < 36. <mobile-phone number=" "/> 37. <home-phone number=" "/> 38. <home-phone number=" "/> 39. </contact-info> 40. <address city="new York" street="w. 15th Ave." number="12789" state="ny"/> 41. <job-info is-manager="no" job-description="hacker" employee-type="part-time"/> 42. <manager employee-number="a7000"/> 43. </person> 44. </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 Seite 7/33

10 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 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 wichtige Begrifflichkeiten Im folgenden stelle ich die wichtigsten Begrifflichkeiten dar, die zum Verständnis eines XML-Dokuments benötigt werden 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 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 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 > 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 Seite 8/33

11 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr Ein Tagname muß mit einem Buchstaben anfangen Kommentare Kommentare dürfen an jeder beliebigen Stelle außerhalb der Markups stehen. Ein Kommentar darf dabei nicht mit einem Zeichen enden Prozessor Anweisungen Durch Prozessor Anweisungen können einzelne Dokument Anweisungen für externe Programme wie z.b. einen Java-Skript Interpreter enthalten 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 Well-formed Dokumente vs. Valide Dokumente XML unterscheidet zwischen wohlgeformten Dokumenten (well-formed documents) und validen Dokumenten (valid documents) 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 XML- 1.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 DTD- Teilmenge 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 Seite 9/33

12 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 XML- Prozessor 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 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 DTD 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 XML- Dokument und einer XML-DTD. Eine DTD muß in Ihrem Namen den Namen des Wurzel-Elements enthalten Vor- und Nachteile einer DTD 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 Nachteile einer DTD Den Vorteilen stehenden die folgenden Nachteile entgegen, die beim Einsatz einer DTD mit abgewogen werden müssen: Edmund Buchbinder Seite 10/33

13 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 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 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 Seite 11/33

14 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 Entity-Typ Parameter intern, extern-analysiert, nichtanalysiert Zeichen allgemein allgemein Referenz im Inhalt Nicht erkannt Inkludiert Inkludiert, falls Verboten validierend Inkludiert Referenz im in Literal Nicht erkannt Verboten Attribut-Wert inkludiert Verboten Inkludiert Auftreten als Nicht erkannt Verboten Verboten Informieren Nicht Attribut-Wert erkannt Referenz im Entity- in Literal Durchgereicht Wert inkludiert Durchgereicht Verboten Inkludiert Als Parameter- Referenz in der DTD Entity (PE) Verboten Verboten Verboten Verboten inkludiert 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 Seite 12/33

15 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 Parameter- Entity-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 Entity- Deklaration 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-Entity- Referenz 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 , Übersetzung durch Behme und Wintert) Elemente und Attribute Grundsätzlich sieht eine ELEMENT-Deklaration in einer DTD wie folgt aus: <!Element name content-model> Edmund Buchbinder Seite 13/33

16 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 CDATA ID Beschreibung Zeichendaten, die einen String bilden. Eine benannte einzigartige ID innerhalb eines Dokuments. IDREF Eine benannte Referenz auf eine einzigartige ID IDREFS ENTITY ENTITIES NMTOKEN NMTOKENS NOTATION Eine benannte Liste von Referenzen auf einzigartige IDs innerhalb eines Dokuments. Eine benannte Referenz auf eine Entity, die sich auf eine Notation bezieht. Eine benannte Liste von Referenzen auf Entities, die sich auf Notationen bezieht. Eine benannte Referenz auf ein NAME- Token. Eine benannte Referenz auf eine Liste von NAME-Token. 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. Wie oben bereits beschrieben, bieten Attribute zusätzlich die Möglichkeit, Standarddaten für das Attribut vorzugeben. Edmund Buchbinder Seite 14/33

17 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr Tabelle 4: Standarddaten für Attribute Standarddatum #REQUIRED Bedeutung Es wird kein Standardwert vorgegeben. In einem validen XML-Dokument muß hier ein Wert eingegeben werden. #IMPLIED Das Attribut muß nicht unbedingt vorhanden sein. "default-value" #FIXED "constant-value" Es gibt einen Standardwert. Dieser kann überschrieben werden. Es gibt einen Standardwert, dieser kann nicht überschrieben werden 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 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 XML- Prozessor 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"> 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 Seite 15/33

18 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr <?xml encoding="utf-8"?> 2. <!-- Element names --> 3. <!ENTITY % Doctype "addressbook" > 4. <!ENTITY % Person "person"> 5. <!ENTITY % Contact-info "contact-info"> 6. <!ENTITY % Address "adress"> 7. <!ENTITY % Job-info "job-info"> 8. <!ENTITY % Manager "manager"> 9. <!ENTITY % Misc-info "misc-info"> 10. <!ENTITY % First-name "first-name"> 11. <!ENTITY % Family-name "family-name"> 12. <!-- Content Substitution --> 13. <!ELEMENT %Doctype; ( %Person;)+> 14. <!ELEMENT %Person; (%Contact-info;, %Address;,%Job-info;,%Manager;,(%Miscinfo;)?)> 15. <!ATTLIST %Person; 16. %First-name; CDATA #REQUIRED 17. %Family-name; CDATA #REQUIRED 18. middle-initial CDATA #IMPLIED 19. employee-number ID #REQUIRED> 20. <!ELEMENT %Contact-info; (home-phone mobile-phone )*> 21. <!ELEMENT home-phone EMPTY> 22. <!ATTLIST home-phone 23. number CDATA #REQUIRED> 24. <!ELEMENT mobile-phone EMPTY> 25. <!ATTLIST mobile-phone 26. number CDATA #REQUIRED> 27. <!ELEMENT EMPTY> 28. <!ATTLIST 29. address CDATA #REQUIRED> 30. <!ELEMENT %Address; EMPTY> 31. <!ATTLIST %Address; 32. state NMTOKEN #REQUIRED 33. city CDATA #REQUIRED 34. street CDATA #REQUIRED 35. number CDATA #REQUIRED> 36. <!ELEMENT %Job-info; EMPTY> 37. <!ATTLIST %Job-info; 38. is-manager (yes no) 'no' 39. job-description CDATA #REQUIRED 40. employee-type (Full-Time Part-Time Intern) 'Full-Time'> 41. <!ELEMENT %Manager; EMPTY> 42. <!ATTLIST %Manager; 43. employee-number IDREF #REQUIRED> 44. <!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 Wurzel- Element 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 Seite 16/33

19 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 . 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 XML-Schema 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 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 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 Aufbau eines XML-Schemas Im folgenden werden die wichtigsten Bestandteile eines XML-Schemas vorgestellt. Es wird empfohlen, zu diesem Abschnitt parallel den Abschnitt zu beachten. Edmund Buchbinder Seite 17/33

20 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 Examples (delimited by commas) string Confirm this is electric normalizedstring Confirm this is electric see (3) token Confirm this is electric see (4) byte -1, 126 see (2) unsignedbyte 0, 126 see (2) base64binary GpM7 hexbinary 0FB7 integer , -1, 0, 1, see (2) positiveinteger 1, see (2) negativeinteger , -1 see (2) nonnegativeinteger 0, 1, see (2) nonpositiveinteger , -1, 0 see (2) int -1, see (2) unsignedint 0, see (2) long -1, see (2) unsignedlong 0, see (2) short -1, see (2) unsignedshort 0, see (2) decimal -1.23, 0, 123.4, see (2) float double boolean time datetime duration -INF, -1E4, -0, 0, 12.78E- 2, 12, INF, NaN -INF, -1E4, -0, 0, 12.78E- 2, 12, INF, NaN true, false 1, 0 13:20:00.000, 13:20: : T13:20: :00 P1Y2M3DT10H30M12.3 S Notes 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 date see (2) gmonth May, see (2) (5) gyear , see (2) (5) gyearmonth the month of February 1999, Edmund Buchbinder Seite 18/33

21 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr Simple Type Examples (delimited by commas) Notes regardless of the number of days, see (2) (5) gday the 31st day, see (2) (5) gmonthday every May 31st, see (2) (5) Name shipto XML 1.0 Name type QName po:usaddress XML Namespace QName NCName USAddress XML Namespace NCName, i.e. a QName without the prefix and colon anyuri language ID IDREF IDREFS ENTITY ENTITIES NOTATION NMTOKEN NMTOKENS doc.html#id5 en-gb, en-us, fr US, Brésil US UK, Brésil Canada Mexique valid values for xml:lang as defined in XML 1.0 XML 1.0 ID attribute type, see (1) XML 1.0 IDREF attribute type, see (1) XML 1.0 IDREFS attribute type, see (1) XML 1.0 ENTITY attribute type, see (1) XML 1.0 ENTITIES attribute type, see (1) XML 1.0 NOTATION attribute type, see (1) XML 1.0 NMTOKEN attribute type, see (1) XML 1.0 NMTOKENS attribute type, i.e. a whitespace 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. 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 List- Datentypen. Edmund Buchbinder Seite 19/33

22 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 Annotations- Element 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 Erweiterte Konzepte Im folgenden noch einige erweiterte Konzepte, diese werden aber nicht intensiver behandelt. Weitere erweiterte Konzepte werden bei Fallside (2001) dargestellt 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 Ableitung von Typen durch Erweiterung Neue komplexe Typen können auch durch Erweiterung von bestehenden komplexen Typen entstehen 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 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 Seite 20/33

23 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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. <xsd:schema xmlns:xsd=" 2. <xsd:annotation> 3. <xsd:documentation xml:lang="en"> 4. Purchase order schema for Example.com. 5. Copyright 2000 Example.com. All rights reserved. 6. </xsd:documentation> 7. </xsd:annotation> 8. <xsd:element name="purchaseorder" type="purchaseordertype"/> 9. <xsd:element name="comment" type="xsd:string"/> 10. <xsd:complextype name="purchaseordertype"> 11. <xsd:sequence> 12. <xsd:element name="shipto" type="usaddress"/> 13. <xsd:element name="billto" type="usaddress"/> 14. <xsd:element ref="comment" minoccurs="0"/> 15. <xsd:element name="items" type="items"/> 16. </xsd:sequence> 17. <xsd:attribute name="orderdate" type="xsd:date"/> 18. </xsd:complextype> 19. <xsd:complextype name="usaddress"> 20. <xsd:sequence> 21. <xsd:element name="name" type="xsd:string"/> 22. <xsd:element name="street" type="xsd:string"/> Edmund Buchbinder Seite 21/33

24 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr <xsd:element name="state" type="xsd:string"/> 25. <xsd:element name="zip" type="xsd:decimal"/> <xsd:element </xsd:sequence> name="city" type="xsd:string"/> 27. <xsd:attribute name="country" type="xsd:nmtoken" 28. fixed="us"/> 29. </xsd:complextype> 30. <xsd:complextype name="items"> 31. <xsd:sequence> 32. <xsd:element name="item" minoccurs="0" maxoccurs="unbounded"> 33. <xsd:complextype> 34. <xsd:sequence> 35. <xsd:element name="productname" type="xsd:string"/> 36. <xsd:element name="quantity"> 37. <xsd:simpletype> 38. <xsd:restriction base="xsd:positiveinteger"> 39. <xsd:maxexclusive value="100"/> 40. </xsd:restriction> 41. </xsd:simpletype> 42. </xsd:element> 43. <xsd:element name="usprice" type="xsd:decimal"/> 44. <xsd:element ref="comment" minoccurs="0"/> 45. <xsd:element name="shipdate" type="xsd:date" minoccurs="0"/> 46. </xsd:sequence> 47. <xsd:attribute name="partnum" type="sku" use="required"/> 48. </xsd:complextype> 49. </xsd:element> 50. </xsd:sequence> 51. </xsd:complextype> 52. <!-- Stock Keeping Unit, a code for identifying products --> 53. <xsd:simpletype name="sku"> 54. <xsd:restriction base="xsd:string"> 55. <xsd:pattern value="\d{3}-[a-z]{2}"/> 56. </xsd:restriction> 57. </xsd:simpletype> 58. </xsd:schema> Abbildung 3: Listing 3, ein Beispiel für ein XML-Schema 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 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 Seite 22/33

25 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 XML Konvertierungen 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 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 Seite 23/33

26 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 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 für Instandhaltungsanweisungen der DB AG 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 Seite 24/33

27 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 Software- Lösung und Technologie gestellt: Durchgängigkeit der Informationskette von den Autoren der Instandhaltungsregelwerke bis zu den Arbeitsscheinen für die Handwerkern Langfristig lesbares Dokumentformat ohne Abhängigkeit von einzelnen 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 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 Seite 25/33

28 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr XML PDF PDTec Layout Engine (PLE) Throughout the whole transformation process, PLE enables keeping control over every layouting and rendering step. 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. 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 Intermediate 2 XML Document XSLT Rendering Engine PLE (PDTec Layout Engine) PDF Driver PDF Document Business Semantics Logical Layout Graphical Layout 2002 PDTec GmbH ProSTEP Symposium 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 Seite 26/33

29 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr PDM/ERP Integration Example: SAP R/3 PLM HTML PDF XML GIF PDF TIFF SAP GUI Local Filesystem Frontend RFC Server SAP PLM Application profiles Profiles Custom Layout SAP PLM Rendering Service (ABAP API) profiles XSLT Rendering Engine PDTec Layout Engine PDF Driver SAP R/3 Rendering Server 2002 PDTec GmbH ProSTEP Symposium 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 Erfahrungen aus dem Projekt Die erste Erfahrung, die im Rahmen diese Projektes gemacht wurde, war, daß die XML- Unterstützung, die die einzelnen Tools bieten, häufig nicht den Marketing- Versprechungen 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 Seite 27/33

30 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr 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 Seite 28/33

31 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr Verzeichnisse 8.1. Literaturverzeichnis T. Bray, J. Paoli, C. M. Sperberg-McQueen und E. Maler. Extensible Markup Language (XML). Second Edition, W3C Recommendation, 2000, D. C. Fallside. XML Schema Part 0: Primer, W3C Recommendation, 2001, S. Adler et al. Extensible Stylesheet Language (XSL), Version 1.0. W3C Recommendation,2001, J. Clark. XSL Transformations (XSLT), Version 1.0. W3C Recommendation, 2001, 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 Abbildung 3: Listing 3, ein Beispiel für ein XML-Schema Abbildung 4: Konvertierung XML in ein PDF-Dokument Abbildung 5: Architektur zur Konvertierung der XML-Dokumente Tabellenverzeichnis Tabelle 1: Auszeichnungen im XML... 6 Tabelle 2: Entity-Typen und ihre Auswirkung Tabelle 3: Attributs-Datentypen in einer DTD Tabelle 4: Standarddaten für Attribute Tabelle 5: Frequenzindikatoren, die in XML-DTDs verwendet werden Tabelle 6 : Simple Typen (Tabelle aus Fallside, 2001) Edmund Buchbinder Seite 29/33

32 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr Anhang 9.1. Anhang:vollständige XML-Grammatik in Extended-Backus- Nauer-Form [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 ::= <!-- ((Char - - ) ( - (Char - - )))* --> [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 Seite 30/33

33 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr [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 Seite 31/33

34 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr [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 Seite 32/33

35 Seminar XML und Datenbanken Thema: Übersicht XML Matrikel Nr #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 Seite 33/33

36 /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, Inga Overkamp Matrikel-Nr: q Studiengang Informatik (Bachelor) München, den

37 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335,QKDOWVYHU]HLFKQLV 4 (,1/(,781* =8*581'(/,(*(1'(#'$7(102'(//( %-(&7#(;&+$1*(#02'(/#+2(0, %-(&7#'$7$%$6(#0$1$*(0(17#*5283#+2'0*, /25(/#$/6#$1)5$*(0635$&+( &2(5&, (5:(1'81*#921#(,1)$&+(1#3)$'$86'5h&.( : 616 9(5:(1'81*#921#$//*(0(,1(1#3)$'$86'5h&.( ; 617 5(68/7$7(#921#/25(/0$1)5$*( /25(/#$/6#83'$7(0635$&+( %-(.7(567(//81* $0(16=8:(,681*( %-(.783'$7( %8/.#/2$',1* /25(/#,03/(0(17,(581*#,0#/25(#6<67( =86$00(1)$6681*#81'#6&+/ : /,7(5$7859(5=(,&+1,

38 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66# (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 Daten abgelegt sein 1 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. Mit dem Lightweight Object Repository (Lore) 2 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 können 3. 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 dieser schriftlichen Ausarbeitung allerdings nicht behandelt werden 4. 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: 2 Weiterführende Informationen zu LORE finden sich auf der Projekt-Hompage: 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

39 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66# =XJUXQGHOLHJHQGH#'DWHQPRGHOOH Dieses Kapitel gibt einen Überblick über die Datenmodelle, die bei der Entwicklung des Lore-DBMS berücksichtigt wurden EMHFW#([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 zum Beispiel Lore und C 3 zugrunde gelegt 5. 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 &2 Nachbarhaus &12 Nachbarhaus PLZ Straße Ort Wohnung Wohnung Wohnung Adresse &3 &4 &5 &6 &13 &15 & Hagener München Str. 14 Zimmerzahl Miete Mieter Besitzer Mieter qm qm qm Besitzer Ort PLZ Strasse &7 &8 &44 &21 &14 &16 &31 &39 &26 &27 3 Name KontoNr Name Vorname Nachname Ort München Postleitzahl Hagener Str. 12 &45 &49 &22 &32 &33 &34 &35 I. Overkamp Knut Frick Meike Schmidt Hagen Eine vollständige Beschreibung des Object Exchange Model findet sich bei (Goldman et al, 1996). 4

40 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 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: ist vom Typ integer, während Hagener Str. 14 und als Zeichenketten (Strings) abgelegt sind. Eine textuelle Darstellung obiger OEM-Datenbank könnte wie folgt aussehen: Hausverwaltung &1 Haus &2 PLZ & 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 & Nachbarhaus &12 Haus &12 Nachbarhaus &2 Wohnung &13 qm &14 78 qm & Besitzer &44 Mieter &21 Name &22 "Knut Frick" Wohnung &15 qm &16 Besitzer &31 Vorname &32 "Meike" Nachname &33 "Schmidt" Ort &34 "Hagen" Postleitzahl & 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 objektorientierte Datenbanken definiert 6. 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: 5

41 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 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 7, 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). 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 Hausverwaltungs- Datenbank aus Kap. 2.1 nicht erfolgreich abgearbeitet werden: Beispiel 1: select H.Wohnung from Hausverwaltung.Haus H where H.PLZ = "81541" Beispiel 2: select W.Besitzer from Hausverwaltung.Haus H, H.Wohnung W where W.qm = 78 Fehlermeldung, da unterschiedliche Datentypen (string <#LQWHJHU,#PLWHLQDQGHU#YHUJOLFKHQ#ZHUGHQ sollen 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 Typanpassungs- Regeln, 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 könnten z.b. folgende Regeln gelten 8 : = Zwei integer Werte können ohne Umformung miteinander verglichen werden. Rückgabewert: true = "test" Der String kann nicht in einen integer Wert umgeformt werden. Rückgabewert: false = "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 8 Obwohl in dem Beispiel lediglich der Gleichheitsoperator angewendet wird, gelten die Regel auch für die restlichen arithmetischen Vergleichsoperationen, z.b.: <, >, 6

42 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 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 von OEM-Objekten interpretiert 9. 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 HUZHQGXQJ#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) from Hausverwaltung.Haus H, H.Wohnung W, W.Mieter M where M.Name = "Knut Frick" OQL-Anfrage mit verschachtelter Select-Anweisung 9 Auf die genaue Struktur der Ergebnis-Mengen in Lorel wird in Kap. 3.4 eingegangen 7

43 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 WHERE-Anweisung - Auch hier werden zunächst die entsprechenden Variablen aus der FROM- Anweisung 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 = select H from Hausverwaltung.Haus H where exists A in H.Adresse: exists P in A.PLZ : P = OQL-Anfrage mit Existenzquantoren 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 = or (Hausverwaltung.Haus.Adresse.Ort = "München" and Hausverwaltung.Haus.Adresse.Strasse = "Hagener Str.") select H from Hausverwaltung.Haus H where exists A in H.Adresse: exists P in A.PLZ : exists O in A.Ort : exists S in A.Strasse : (P = or (O = "München" and S = "Hagener Str.")) Die Auswertung der Bedingung in der WHERE-Anweisung liefert false zurück, falls das Adressen- Objekt nicht alle Attribute (PLZ, Ort 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 from Hausverwaltung.Haus H where exists A in H.Adresse: ((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."))) OQL-Anfrage mit geklammerten Existenz-Operatoren 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 from Hausverwaltung.Haus H where exists A in (H.Adresse union set (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 = or (O = "München" and S = "Hagener Str.")) OQL-Anfrage unter Verwendung von oemnil 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

44 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 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) (Teilpfad)? z.b.:.haus(.adresse)?.plz (Teilpfad)+ z.b.:.haus(.nachbarhaus)+ (Teilpfad)* z.b.:.haus(.nachbarhaus)* Platzhalter für Kanten % z.b.: Besitzer.%name # z.b.: Hausverwaltung.# Disjunktion der Teilpfade, d.h. nach Adresse muss im Pfad eine Kante Strasse oder eine Kante Straße folgen Optionaler Teilpfad, d.h. der Pfad nach Haus kann eine oder keine Kante mit der Beschriftung Adresse beinhalten Wiederholter Teilpfad, d.h. die Kante Nachbarhaus ist mindestens einmal im Pfad vorhanden oder kann beliebig häufig wiederholt werden Wiederholter Teilpfad, wobei die Kante Nachbarhaus auch nullmal im Pfad vorkommen kann Null oder beliebig viele Zeichen, d.h. es wird sowohl das Objekt Besitzer.Vorname als auch Besitzer.Nachname referenziert 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 obigen Beispiel lediglich die ersten drei Datenpfade 10. Eine weitere Besonderheit stellt Lorel mit dem Konzept der Pfadvariablen zur Verfügung. Diese werden unter Verwendung des 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 select distinct path-of(b) from Hausverwaltung.#@B X where X grep "Str." select distinct path-of(b) from Hausverwaltung.#.%@B X where X grep "Str." Ergebnismenge a) Pfade Haus.Straße Haus.Adresse.Strasse Haus.Nachbarhaus.Straße Haus.Nachbarhaus.Adresse.Strasse 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

45 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 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 select W from Hausverwaltung.Haus.Wohnung W select W.Mieter, W.Besitzer from Hausverwaltung.Haus.Wohnung W Ergebnis als OEM-Objekt Answer &111 Wohnung &6 Wohnung &13 Wohnung &15 Answer &112 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

46 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66# EMHNWHUVWHOOXQJ 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) new_oem (complex, struct(name:{new_oem(string,"hohl")}, Konto:{new_oem(int, )})) erstellt ein atomares OEM-Objekt vom Typ integer mit dem Wert 5 erstellt zunächst ein komplexes OEM- Objekt und anschließend zwei atomare Subobjekte, die über die Kanten Name 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 DPHQV]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 := element 11 (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 update meineqm -= 10 fügt dem komplexen OEM-Objekt über eine neue Kante qm eine zusätzliche Referenz auf ein Objekt mit dem Wert 64 hinzu 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

47 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 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 <= 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 Lorel wurde speziell für die Formulierung von Abfragen an das Lore Datenbank Management System 12 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. 2. Im Preprocessor wird die Lorel-Anfrage in eine OQL-ähnliche Syntax umgeformt 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 Die Lore-Architektur ist in (McHugh et al, 1997) beschrieben 13 z.b. durch das Auflösen der einfachen Pfadausdrücke, vgl. Kap

48 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66# FKOX 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 Datentyp- Umsetzungen (Type Coercion) vermutlich vom technischen Standpunkt noch am einfachsten zu lösen sind 14. 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 from Hausverwaltung.Haus H where H.#.(postleitzahl plz)!= das Objekt mit der oid &12 zurück, obwohl das Haus dem Postleitzahlenbereich 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 Benutzeroberflächen zur Selektion semistrukturierter Daten anhand dynamisch erstellter Data Guides 15 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 vgl vgl. (McHugh et al,.1997, S. 62f) 13

49 ,QJD#2YHUNDPS=#/RUHO#±#HLQH#$QIUDJHVSUDFKH#I U#VHPLVWUXNWXULHUWH#'DWHQ/#6HPLQDU#Ä;0/#XQG#'DWHQEDQNHQ³/#66#5335 : /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, Gesellschaft für Informatik. Informatik-Lexikon. R. Goldman, S. Chawathe, A. Crespo, J. McHugh. A Standard Textual Interchange Format for the Object Exchange Model (OEM). Technical Report, October, ftp://db.stanford.edu/pub/papers/oemsyntax.ps R. Goldman, J. McHugh, J. Widom. From semistructured data to XML: Migrating the Lore data model and query language. Markup Languages 2 (2), , U. Greiner. Semistrukturierte Daten 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 ftp://db.stanford.edu/pub/papers/lore97.ps 14

50 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

51 Lore - ein DBMS für semistrukturierte Daten Seite 2 von 17 1 Übersicht Repräsentation semistrukturierter Daten Das OEM-Datenmodell von Lore (Object Exchange Model) Das XML-Datenmodell von Lore Systemarchitektur Überblick Top-Down-Ansatz der Abfrageverarbeitung Abfrageoperatoren (Query operators) Bottom-Up Ansatz der Abfrageverarbeitung Lindex (Label Index) Vindex (Value Index) Abfrageplan mit Indexierung DataGuides Definition und Eigenschaften von DataGuides Unterstützung des Benutzers durch DataGuides Unterstützung bei der Erfassung von Struktureigenschaften Unterstützung bei der Formulierung von Abfragen Unterstützung des Systems durch DataGuides bei der Auswertung von Abfragen Zusammenfassende Bewertung von Lore Literatur... 17

52 Lore - ein DBMS für semistrukturierte Daten 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 XML- Format 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.

53 Lore - ein DBMS für semistrukturierte Daten 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.

54 Lore - ein DBMS für semistrukturierte Daten Seite 5 von 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)

55 Lore - ein DBMS für semistrukturierte Daten Seite 6 von 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 Symbol Beispiel Ergebnis nur Subelemente > Krankheiten.Krankheit.>Name &7 nur Krankheiten.Krankheit.@Name "Mandelentzündung" beides Krankheiten.Krankheit.Name {&7, "Mandelentzündung"}

56 Lore - ein DBMS für semistrukturierte Daten 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

57 Lore - ein DBMS für semistrukturierte Daten Seite 8 von 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.

58 Lore - ein DBMS für semistrukturierte Daten Seite 9 von 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) 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 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-zu- Real-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.

59 Lore - ein DBMS für semistrukturierte Daten Seite 10 von 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.

60 Lore - ein DBMS für semistrukturierte Daten 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.

61 Lore - ein DBMS für semistrukturierte Daten Seite 12 von 17 Aus einem NEA mit einer Knotenmenge V kann man einfach einen DEA mit der Knotenmenge 2 V 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 ( mit Knoten und 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.

62 Lore - ein DBMS für semistrukturierte Daten Seite 13 von 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.

63 Lore - ein DBMS für semistrukturierte Daten Seite 14 von 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.

64 Lore - ein DBMS für semistrukturierte Daten 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 Objekte, von denen 5000 je ein Subobjekt in der Year-Rolle besitzen, von denen wiederum der Bedingung genügen. Weiterhin gebe es noch andere Objekte in einer Year-Rolle, deren Väter aber keine Publication sind, von denen der Bedingung genügen. Die Zahl der Group_Member sei 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 Elemente, V Elemente. Der Durchschnitt kann durch Iteration über die 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 Group-Member mit 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 Objekte iteriert).

65 Lore - ein DBMS für semistrukturierte Daten 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.

66 Lore - ein DBMS für semistrukturierte Daten 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 Goldman R, McHugh J, Widom J (1999): From Semistructured Data to XML: Migrating the Lore Data Model and Query Language Goldman R, Widom J (1997): DataGuides: Enabling query formulation and optimization in semistrucutred databases Goldman R, Widom J (1999): Approximate DataGuides.

67 Seminar: Thema: Referentin: Semester: XML und Datenbanken XQL, XPath Annette Gutjahr Sommersemester 2002 FernUniversität Hagen Lehrgebiet Praktische Informatik IV Prof. Dr. Ralf Hartmut Güting, Dipl.-Inf. Dirk Ansorge Annette Gutjahr Matr. Nr Sonnenbergstr. 32/ Ostelsheim

68 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 1 Einführung Szenarien für XML-Anfragen Allgemeine Anforderungen an eine XML-Anfragesprache Datenbankanfragen als Messlatte Ein XML-Dokument (Beispiel) Worin bestehen die Unterschiede zwischen relationalen Datenbanken und XML- Dokumenten? XQL (W3C Proposal, September 1998) Einführung und Motivation Beispiel Syntax und Semantik Terminologie XML Patterns (Kernfunktionalität) XQL-Erweiterungen Diskussion XPath Version Einführung und Motivation Das Datenmodell von XPath Beispiel Syntax und Semantik Ausdrücke Diskussion Weiterentwicklung von XPath: Quellen, weitere Informationsmöglichkeiten Seite 2

69 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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 -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

70 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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 QL 1 `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 Output- Formats 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 SS referate-tabelle teilnehmerid kursnummer referatthema Überblick XML 1 QL 98 war der Workshop für Query Languages, der 1998 vom W3C organisiert wurde Seite 4

71 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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

72 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath <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> <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> <referent>nn</referent> </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

73 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath zugehörigen Kurs der anderen Tabelle verweisen. So erhält man 1 zu 1- und 1 zu n- Beziehungen, 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> <referatthema>lorel</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

74 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath <referatthema>lorel</referatthema> <referent>nn</referent> </referat> <referat> <referatthema>lore</referatthema> <referent>nn</referent> </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 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 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, */*, 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 Seite 8

75 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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[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()] 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 @my:* Seite 9

76 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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(' '] 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 XSL- Sprache. 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. Doppel- Seite 10

77 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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 (GMD- IPSI), 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 XML- Dokument 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 Einführung und Motivation XPath ist der direkte Nachfolger des oben beschriebenen XQL-Vorschlags. XPath 2 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 Transformations 3 und XPointer 4 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 XSL Transformations (XSLT) Version 1.0, W3C Recommendation November XPointer Language (XPointer) Version 1.0, W3C Candidate Recommendation September 2001 Seite 11

78 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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 Knotentypen 5 (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 XML- Dokumenten arbeitet, nachdem diese Informationen bereits in das Dokument integriert wurden. Seite 12

79 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath /, 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 Kontext 6. 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 &apos; angegeben werden oder man verwendet " anstelle von ' bzw. umgekehrt 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 <, >, <=, >= und!=, boolean Operatoren and und or, sowie einen Mindestrepertoire an 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[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

80 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath attribute:: wird abgekürzt 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 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 , 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

81 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath 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 XML- Dokumente. Ähnlich wie SQL kommt XPath in vielen verschiedenen Situationen zur Anwendung: Da gibt es spezielle Anfrage-Werkzeuge für XML-Dokumente, native XML- Datenbanken (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 Host- Sprache (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 ( Die statische und dynamische Semantik von XPath ist formal definiert in XQuery 1.0 Formal Semantics ( Die von XPath unterstützten Funktionen und Operatoren sind in XQuery 1.0 and XPath 2.0 Functions and Operators definiert ( 4 Quellen, weitere Informationsmöglichkeiten [1] J. Clark und S. DeRose. XML Path Language (XPath), Version 1.0. W3C Recommendation 1999, [2] J. Robie, J. Lapp und D. Schach. XML Query Language (XQL). W3C Recommendation, 1998, [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, [5] E. R. Harold, W. S. Means: XML in a Nutshell - A Desktop Quick Reference, January 2001, Seite 15

82 Annette Gutjahr Seminar: XML und Datenbanken: XQL, XPath [6] ML.com: Considering XSL Extensions, XQL and Other Proposals: X [7] E. R. Harold, Processing XML with Java, 2001, [8] J. Robie: XQL FAQ, März 1999, Seite 16

83 Seminar 1912 XML und Datenbanken Einsetzen von YATL zur Optimierung von XML-Abfragen über heterogene Datenquellen Verfasser: Andreas Buschka Datum: 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

84 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 Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 2 von 15

85 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 Import-/Export Wrapper Datensatz- Baumstruktur Manipulation der Baumstruktur durch ein YAT-Programm Neue Baumstruktur mit Knotennamen als HTML Tags XML Dokument Import-/Export Wrapper Baumstruktur des XML- Dokuments HTML Import-/Export Wrapper HTML Dokument Abbildung 1: YAT verändert den Aufbau von Strukturen aus mehreren Quellen Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 3 von 15

86 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. Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 4 von 15

87 Deklarative Sprache Auto -Objekt, eine Instanz eines Auto - Musters, das vom Fahrzeug -Muster abgeleitet wurde. Es stammt z.b. aus einem OODBMS Auto Hersteller -Objekt, z.b. aus einem XML- Dokument Hersteller strhersteller strbesitzer Standort Name Citroen Andreas Paris 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 Andreas H1 Herkunft Citroen AX Paris 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 Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 5 von 15

88 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 und Mustervariablen. Datenvariablen können grundsätzlich alle Datenkonstanten und Variablennamen enthalten. 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. Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 6 von 15

89 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. Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 7 von 15

90 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. Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 8 von 15

91 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>... (weitere Datensätze) <artist>claude Monet</artist> <title>nympeas</title> <style>impressionist</style> <size>21x61</size> <cplace>giverny</cplace> Dann liefert ein Aufruf von BIND ( $title: $t, $artist: $a, more: $fields) einen Objektbaum der folgenden Art: a t fields Claude Monet Nympheas style size cplace Impressionist 21 x 61 Giverny Abbildung 4: Die durch BIND erzeugte Tab-Struktur Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 9 von 15

92 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. Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 10 von 15

93 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. Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 11 von 15

94 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 Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 12 von 15

95 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 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 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 als maximalen Preis ausführen. Die optimierte Abfrage sieht nun so aus: Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 13 von 15

96 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. Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 14 von 15

97 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 3 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 Seminar 1912 Thema: YATL Autor: Andreas Buschka Seite 15 von 15

98 !"!" #$" %& '( )*+ "

99 ,% -./0) #$" %& '( ): 0; ") 0) )$<=% /,% 7 0",% -."0:>) 5 <"))?"2 "2 7 7 &<$ A 7 )"9! 6 5 % ""< ' B;<C)) ' "<( ":( 7 D?E9! 7?!0)!: 7 9F9) 77 F")9"; ) G,% -2:) % "))2!) 6 7 : ' 5 9 5,% -. 5.)) )*12" *57 898

100 ,% -./0) #$" %& '( 9!!)": 9!!)"*"2 9!!)"*"2 7 9!!)"7*D2-H"<$$0IJ 5 9!!)"5*% ")),% -:)) 6 =2),% -. =2)*.@)A 6 =2)*.@)0A) 6 =2)7*.@" ' =2)5*.@DKE( =2) *.@":,% -#"-! =2)6*.@"0!) =2)'*.@;!)A!),% -# =2)(*.@;!2),% -# =2)*.@)9"; 7 =2) *.@DKE5 =2)*.@9"! L! L!*=2)"D"!)H L!*=2)"D!H L!7*=2)"D))MM!H )*12" *57 8=8

101 ,%-. #$" %& '( ") 0) <:" :" I":" )J ;: -!"))#-F24"$2!)4F"" O """!""#F" O ""9,% )#2-";!)!- )% "4! )) )) "?)!?;:I"FJ;"!-,% -: &F")% "F"4F),% -<!4:;- " ":>/""0!F"),%!))"- B")9)@:)4""=")P <4)"!FI0<Q!!J )$<=%/,% ") D)E <=% I))% "))J " $) = ) <-! :)#!))I:)J " O ) "") :- F";!-"");)F)!=;2))!) I:) D&))E-)"J " ) 2),%-<"")!!!"4:")A!) " " )!! " A2): <#</ ) D<E/") 2)A " ":)) < >)% "))?)P $<=% R >) <)! F",% -< #! $! 7 0",%-."0:>),% -. 9!2 ;,% -<* 0,% F)" =- )2 2)4 )!"4,% -< ".)) ):: -!4::;4:"N":)""0!F",% -!:)% P!)D0"E22! 0 ") ) % "")F-#)4 F);!))" : F" >4 F" <) ))! )) )P " F 2: B- ;" < " B)F"/ = "# F, ",/ "):2):F 7 0F""!9:)4F)"=- "-<,% -.IJ):))""F"4A!DE ))2:) 5!O7S <DE"<2F)!";"9:2: F<)):"T U 7!2)FT'U 5 DE/2*NNFFFF7NSN )*12" *57 8N'8

102 ,%-. 5 #$" %& '(,% -.":)":) * <@AF)V.>)DE,% -<!"- 2F"/));"9!?;:,% -?)P!F@A% N)"R 0>)"$,% -<")4224- ":4"9F2)#9?;:"W-% "?;:;2)A,% -<I)!#4)"<#<J "#9-9)@")9"; &I9F<$0J <"))?"2 B 9!!)" " 9)@" 0- " 9!"!",% -. %&4" )F)"* 2QI40JF$-0) R00)!:I#9-&J R"=:'(!!!IG<J"2):" 9!-O -4" ))=)"XS<9#9-)!) 9!",% -<2R40)"R40))- 2"=)!! IQ 6J )A ) )! 2:) F 2 <! O < #A <! < ''!)%& * B:))"% "))* :F:FR!>R!=: "TU;!@2))"G2! 6 G<F" )*12" *57 8N'8

103 ,%-. R!:)=)")=:") #$" %& '( <)$)0)F"!"% -N)-)!;- 0G")!!)" "2 ""-!F"!)") G"",% - );"9)@"9!"<,% -.;:"="-,% -24!)".@)"A!)IR2)J;F" ))4""D))!E IJ!TU T U!TU IQ 6J IJ I'J I J )AT U!TU 2:)TU FT7U I7J I5J I6J I J )T U TU I(J IJ )T U TU TU IJ IJ I7J 2 <! O < #A <! < ''!+%&, <"0)""-<)"F!4):))! )% >)".@-G2:4F!P<:F):" 9;F"F" 7 &<$0 B " "" < ;:,% R:2 - " ");) 9)$<=% -R:200)!)!"#@2-)" "F);))$:-./!:F-./ "0)! ( =2)* 1Y9###!"<X$0.?$0<3 1Y9###!<$0X$0.?$0<3! )) >! < ) "" D- ;ER:"F",% -.;:".F,% -24"<#<!0 K:""))4"9!) 2F"9P""<"G<"!R ' <$)"#912:)3"1F3F"):-!:F<));"4" "& ( %<):!"##&!!!I<#<J40;"!2)FTU )*12" *57 87N'8

104 ,%-. 0:)&,% -2I"".))"J) 131!313 4F",% -<))!)* #$" %& '(!! IQ 6J!! )A ) )! 2:) F 2 <! O < #A <! < ''!01&!!2-../ " )*12" *57 85N'8

105 ,%-.! " #$" %& '( 9! 9).-NG.-9!24 =;- "?"4" ; - < F ) $!" )W"9!)):,% "I2:2))J"* O0$0 & SG&#$?S#S <!:"".))":"%# 4F))-!)!" F" < F">3$!! S:"N" F F F"0F")!))!)IA 44A J;!".))" )4" ;# :) D#E!) " R) S: ;))W"DRE2")D#E<!!)).-! 9! 0 )-R)) F) "4 ) I2)J " &- R)))"S";!)F,% -#9 9) 9F",% -.-0 F""" R )) S )4 F!"!"O:))1,%3F" < " 2,% -! ):)!) > "! -O 0)IXS<9#9J*1)A3Z!:1N)A3 -O 9!IXS<9#9J*1"2)!)QZ31N"2)!3 RIG<J*13Z1N3 0)I#9J*1Z3!"F""F"Z": ;"F0)") F" 9) " G)F IT UJ " =2)" 2!")- ) <!!:))."9D5=2)"E:;)),% -<: 00A <""F)4)"@),% -. ;: 4" )P" 0)!: 1N3!;: F""; 9" O " ) 9";;! 0)-!FI)77J@ 7 4"",%-0:!"9!- )))"0!" )9!4)!7 9"!:"=:N?!"O:)F"F Z))D,%-SE <5F:4"<TU"TU":":!;- 7 B0*,%-.-9!>,%-<!F"";")!",%- 2:2Y&;)))4"F",% -""9!- )-#91N3:2 )*12" *57 8 N'8

106 ,%-. #$" %& '( )"=2)F""XS<9#9"!)Z)" Z!"""2)- FF"!<&;!<$0F"R2)7" 131!313 $ %%&!%'() * )+,- T,%-.U O 1!3 13 1)A3Z)1N3 1!31N3 1!313Z1N31N3 1N3 1N3 H2*NNFFF"N"F)"N N!A)H 13 1)A3Z)1N3 1!3Z31N3 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 13 1)A32 <!1N)A3 1!3<1N!3 1N3 13 1)A32 <!1N)A3 1!3#A1N!3 1N3 1N,%3 4!&!)!-#!5$! )) :!4" )) 0)" " % ;/,% - " 0) 1)A3 F;" ) 2 )" " " R-,% -. " " O :F"!)!) 6 ")- < 2;) <!" 9" 9! )% 2!ITUJ!:F!IT7UJ4"2;))22,% -F- "D)))2):E<0 *""):")- 4"9!;!2*./T)T7UR2UY 7 )"9! 9!""=2)))"22"=!KF)R-!)!)!*0>4)"!)F:2 $0!! %%1 #2%() * )- T,%-.U O 1!3 13 1)A3Z)1N3 1!31N3 1N300% 0&#M9Z 1N3 H2*NNFFF"N"F)"N N!A)H 13 1)A3Z)1N * ")*" N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 13 1)A32 <!1N)A3 1!3<1N!3 1!3#A1N!3 1N3 1N,%3 4!&!+/5$!#! $ )*12" *57 86N'8

107 ,%-. #$" %& '( % " );)F///678 F" F% >) ;4 0))!):!" 5 "::)F""D).@-=)E:<&- R))A<C))!4""!))"!)!" : <:FO 0$0-SG&#$?S#")!) B"9FF""=:4"!"0) "!)Z!::FO 0$0-SG&#$?S#"") 9) " 22 ;!" 2 R2) 5 )) $# $! :FF"4K":")).@-"9! 5 %""< =)9!;:F":0)";2F- "4-"")!<C)));24)"O DKE-!"))* $0!! %% * #2%9- T,%-.U F 1!3 1!<QZ!3 13Z1N3 1N3 1N3 H2*NNFFF"N"F)"N N!A)H 1!3 13Z1N * )5 4*:65 4% ; <!77222=))=""7)2%) 77* )=;%< ")*" 4* N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 1!3 13<!1N3 13?1N3 1N!3 1!3 13<1N3 132 <!1N3 1N!3 1!3 13#A1N3 132 <!1N3 1N!3 1N,%3 4!&!0#! $#!!$! & :?2" D"E 9* 9" B" 3 4 F""F43 =0:,% -.)R2)";"0:2!))- <>))".))@29F")) B;<C)) 9",% -.-0*> *"?"4!"!W")!<- C)) " ",% -<":; I "*" 5 <%>)4");)FSG&#0&#M9:!4F"F;""9!- :"#FT7U"T UF <G22:)",% -.-0";!A2):22;!).@-=)> >)))!)- )*12" *57 8'N'8

108 ,%-. #$" %& '( "4:=-G244J4"DE-K ")9!) $ *%*%*- T,%-.U F 1!3 1QZ3 1)A3Z)1N3 1N3 1N3 <!77222=))=""7)2%) 77* )=;%< 13 13Z)1N3 \ F 1!)3 1"3 13Z1N3 13Z1N3 1N3 1N3 <!77222=))=""7)2%) 7 7*%=;%< 1"3Z1N3 ] 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H ?1N3 1"3#$"1N"3 1"3<@<1N"3 1N <!1N3 1"3#$"1N"3 1"3:% 1N"3 1N3 1N,%3 4!&!91!(!: 0>)4"O 0$0-!)")9!D!::E"!- "#)"R:2 6?"0"!:"4F "!F" $# $!!:;)"13-0)F" "< ": =" 9F < F" F"4 9;!" $- )!0):<F)"$)"K#94 )"9!))#9,%-!: '? B " G": )4 ;:,% -.::) -!)!"4F"<"))I)J:F"$)F""" )!) ( 4"":)@",%- D)!EF" < B)F 9!!)" D" 2E :: ": 94"" 0:!)!:4" %%0)<G%-0! * ":) F" 6 )7 ' "::"TU4T7U"T5U")) ( <<C))TU"T7U4""P!);,%-.F)99)<!")) F4F)":""@2)B";:">) :),% -.-0ITUJ"A!);!2 0"2::4!"FF)#94)9!D:)EF">- N))!"":IJ")))2,% )"F"4F":,% -<"D2-EI)7J"=2)" F"")2): )*12" *57 8(N'8

109 ,%-. #$" %& '( $0!!1?*!*) #2%() * )- T,%-.U O 1!3 13 1)A3Z)1N3 1!31N3 1N300% 0&#M9Z 1N3 H2*NNFFF"N"F)"N N!A)H 13 1)A3Z)1N3 \ F 131!TZU313Z1N31N31N3 Z 3 26:")*" ")*"4@ ] 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 13 1)A32 <!1N)A3 1!3<1N!3 13#A1N3 1N3 1N,%3 4!&!;#!-!!7!' 4"".@-=);!0!)F""2)- )) 9! >) " < 0!" =)> F" 4" F"- "-:2",G$-)")!:;)""A-!)DZE )*12" *57 8N'8

110 ,%-. #$" %& '( "!& < 4" 9!):!) B"BF"O0$0-SG&#$?S#");)FG$<0$0<-=^:F" 4 "" "!) ) F" > ))!) "": $2==*) " *."- T,%-.U O 1!3 13 1)A3Z)1N3 1!31N3 1N300% 0&#M9Z 1N3 H2*NNFFF"N"F)"N N!A)H )>6% 13 4% ;56%475 \ F 131!TZU313Z1N31N31N3 Z \ FZQ 1!3Z1N3 ] \ FZ3 13Z1N3 ] ] 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 13 1)A32 <!1N)A3 1!3<1N!3 13#A1N3 1N3 1N,%3 4!&!*#!!/'!! 7 D?E9! 7?!0)!: <".)""&)*F"< )@4" ) <G%-0!"K#9!)4 F) K" ) )P!"*13"13 < ): 9F!" 0));! D-KE I) 5J F:F >- ) 4K"";)2!") F) 9)9F!,% -."% >)4!)"0)!::F"" "D&E-BF"O 0$0-SG&#$?S#2"&!!":<- =)"#9)PR):")!0)- F"4K"!)DE-F""9!) <B:<0S0&<&)"4F"":>0;K"";)F ":4""!!>)F))!!)"F"> )*12" *57 8 N'8

111 ,%-. #$" %& '( $*)*() )./1- T,%-.U O 1!3 1Z3 1)A3Z)1N3 1!31N3 1N300% 0&#M9Z 1N3 H2*NNFFF"N"F)"N N!A)H4 6 3*+* 8 ""-!@Z) 1%@ * %3 1)A3Z)1N3 1@ \ F 46 51!TZU313Z1N31N31N3 Z \ FZQ 1!3Z1N3 ] \ FZ3 13Z1N3 ] ] 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 1))3 1)A32 <!1N)A3 1@231N@23 1!3<1N!3 13#A1N3 1N))3 1))3 1)A3,% "<!1N)A3 1@231N@23 1!3#A1N!3 1N))3 1N,%3 4!&!,<'5!'7 7 9F9) ";"=2) F""))4"#9"O0$0-!):F"@) ;:!2)")#99F- ;!?F F"4 "" 2",% - DE!)!" F"0)9!"""))- F"#)F""9!:; % ""!"":F"!"% >)"2))).@-=)>: <,% -.-#0&-00-;:4""2))).@-=)>- "")) 7 ) 7 0F":!!4":""K&!!")F">< 2)))9!!F"""22)9!").@-=)>) )*12" *57 8N'8

112 ,%-. #$" %& '( $2=A=1.B*.) - T,%-.U O 1!3 1Z3 1)A3Z)1N3 1!31N3 1N300% 0&#M9Z 1N3 H2*NNFFF"N"F)"N N!A)H4 Z\4] ""-!@Z) 1))3 1)A3Z)1N3 1@23Z1N ! *.@ * %56! ")*" 42*5** ) % C *.@ * %D6!475 8 \ F 1Z31!TZU313Z1N31N31N3 Z \ FZQ 1!3Z1N3 ] \ FZ3 13Z1N3 ] ] 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 1))3 1)A32 <!1N)A3 1@231N@23 1F3<!!) :)YO IA% -JG 6 -' 1NF3 1!3<1N!3 13#A1N3 1N))3 1))3 1)A3,% "<!1N)A3 1@231N@23 1F3<!!) :)Y G ( 6-6 1NF3 1!3#A1N!3 1N))3 1N,%3 4!&!=<'&!7 77 F")9";,% -.! :"% >)4 ) 9"; " ) "!)):!: 2)A 9F"2) "& 5&!4"" G24 #9)))9";:; 5 G2 _! =" "! 1A2A23 1A231A23 A2` A2a IJ R)-4)!-O")A2-#9 O A2)4>!)!#9"" "):)Z`""`F" -O")A2-#93 G2)D;!)E 0::F* < R!! =: " ) 2)#9 : F "!!,% - ;4!"4 F" "- 5 0"))=2):"T5U )*12" *57 8N'8

113 ,%-. #$" %& $2=A=+*> *" "- T,%-.U O 1!3 1`3 1)A3Z)1N3 1!31N3 1N300% 0&#M9Z 1N3 H2*NNFFF"N"F)"N N!A)H ""-!@Z) 1))3 1)A3Z)1N3 1@23Z1N3 \ F 1`2:)3Z21N3 Z 1F3<!!) :)YZ21N3 ] \ F 1`!TZU313Z1N31N3 Z \ FZQ 1!3Z1N3 ] \ FZ3 13Z1N3 ] ] 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 1))3 1)A32 <!1N)A3 1@231N@23 1F3<!!) :)YO IA% -JG 6 -' 1NF3 1!3<1N!3 13#A1N3 1N))3 1))3 1)A3,% "<!1N)A3 1@231N@23 1F3<!!) :)Y G ( 6-6 1NF3 1!3#A1N!3 1N))3 1N,%3 4!&!>#!?<$ <<F""2A2!4))!"% >)F4 "0)!:2=::: ):!" F! " )4"! 0; #9 ""2A2!")0!"))9!;)!)!"" <:))"!;F" 5 5 )- <B;".))<))!4".) D-KE! F"4 )" :F ",% -<: &;) F" 9!" 9!!,% -.!: 22 "#2) " <C))" $#$!<-)) ;";!!9 < ))!F)";4""!)"<$0-O;!"" )*12" *57 87N'8

114 ,%-. #$" %& '( " $: " )! " ) 9! " #9 <$0-9 " O F" <2) ) 6 "!,%- :; $0!!? * % * *%% #2%9- T,%-.U \ F 1!31!<QZ!313Z1N31N31N3 <!77222=))=""7)2%) 77* )=;%< 1!<QIZJ3 13Z1N3 \ F 1!31Z!QZ!31)A3Z1N3 1N31N3 <!77222=))=""7)2%) 7 7* )=;%<+ Z\4] 1Z<QIZ4ZJQH)H3Z1N3 ] 1N3 ] \ F 1!31!<QZ!313Z1N31N31N3 <!77222=))=""7)2%) 77* )=;%< 1!<QIZJ3 13Z1N3 \ F 1!31Z!QZ!31)A3Z1N3 1N31N3 <!77222=))=""7)2%) 7 7* )=;%<+ Z\4] 1Z<QIZ4ZJQH))H3Z1N3 ] 1N3 ] 1[A)QH H[3 1,% <QH"M H3 1!<QH" H3 13<!1N3 1<QH" HQH)H3 T9!!U?1N3 1N!3 1!<QH" H3 13<1N3 1<QH" 6HQH)H32 <!1N3 1N!3 1!<QH" 7H3 13#A1N3 1<QH" 'HQH)H3,% "<!1N3 1<QH" (HQH)))H3 2<!1N3 1N!3 1!<QH" 5H3 13O:1N3 1<QH" HQH))H3% 1N!3 1N,%3 ""1N3 4!&!)C1(!: 5 9 ;" ))4" )- 22 0) XS<9#9-):" F"4"!))/"$/I?%494%&4%9,4J ' 4 ;",% -.-:"!"SG&#$?S#-% 0! )P) ) :)#9 2K: F" / "9!)!A>) 6 <)!O7SITUJ)"B#94;!"!"9! /F"24RC:<:=2):)% - )2) ' O)",%-.-0!))F";4"2:)- )*12" *57 85N'8

115 ,%-. #$" %& '( $BE. % *2)"*#- T,%-.U O 1!)3 1")QZ3 13Z1N3 1I_J3Z1N3 1N3 1N3 H2*NNFFF"N"F)"N N"!)A)H 1"<QIZJ3 13Z1N3 1F3 \ F 1!31`QZ34*2*56*4751N31N3 H2*NNFFF"N"F)"N N!A)H 1)<QIZ4J36*'6*,1N3 ] \ F 1!31`QZ34*2*56*4751N31N3 H2*NNFFF"N"F)"N N))MM!A)H 1))<QIZ4J36*'6*,1N3 ] 1NF3 1N3 T9!!U 1[A)QH H[3 1,% <QH"M H3 1"<QH" H3 13#$"1N3 1F3 1)<QH" H351N)3 1))<QH" 6H3 1N))3 1NF3 1N"3 1"<QH" H3 13:% 1N3 1F3 1)<QH" 'H31N)3 1))<QH" (H31N))3 1NF3 1N"3 1"<QH" 7H3 13<@<1N3 1F3 1)<QH" H31N)3 1))<QH" H3 1N))3 1NF3 1N"3 1"<QH" 5H3 13W"1N3 1F3 1)<QH" H3 1N)3 1))<QH" H3 1N))3 1NF3 1N"3 1N,%3 4!&!))#!!!'$! G,%-2:) 0 <9F04"!"<#<"F"4":)- <!F<) 1Y0&##^bDE3.4F)"#A")@))4IJ &-2 F"& ;,% -=: ;:4" =") F!2)F " 132<!1N3 1*32<!1N*3 F2::F" )*12" *57 8 N'8

116 ,%-. %"))2!) #$" %& '( #:0"";<"")";!<#< ) ;) ) )4" F,% -.-<"))!!)" F"> O #9")F"4"")F"4 XS<9#9-S4":":<))"2-!) &)" =2):4" " F" 2)!) F">* 0.1%% )%% TDEU 1)A3< 1F3:21NF3 1N)A3 TDEU 1)A31S<9#93< 1NS<9#931F31S<9#93:21NS<9#931NF31S<9#93 1NS<9#931N)A3 )A S<9#9 F S<9#9 < S<9#9 :2 ''!9!%? G!)!!"4FF)R2!)))4" O 0$0-!)!F"4F)"))@> )*12" *57 86N'8

117 ,%-. A. #$" %& '(,% -.2!)#):4,% -<%!:!") /" P ": ") 0)! F:FF9:2:;)) < )) R:2: G)F " < 9 " ) 22K"9!F:" ( /"D0F"E) ;! B""%":"#9!"B(N "" B) >):) 2)! 2 7 /)!"K""4":=2) ))":) 7 <D"E-0"4F)!;"!" "2)))0F):F"D74:) % >)F " 2) "): B 7 :4"OF))4F >P / >)F " ":F% )" " - :))#-?)"/F""=")"[ ( )!)!"O7S-<ITUJF""<)C") 9:"9! 7 TU 7?;!2I#)J2!):4F""=2)"C"?):- 4""@2)!)!)!-B:",% -R2:)Y 7,4, )*12" *57 8'N'8

118 ,% -./9 F E #$" %& '( 5,% -.,% -. **Q I_.@J10G3 **Q c?&s#g&c1?&-<3cici19$3ic*c1<#<3j[j`cjcic*c1<#<3j[.@ c0&<c.@ **Q 0)_)_19$3_.@=) 0) **Q #.@0"# # **Q c1ci1<3_19$3j)<[9!`c3c )< **Q 1<3cIc19$3Ic4c19$3J`cJc 9! **Q 1<3cQcIcHc1#$&3cHc_19$3J 0"# **Q c1cn1<3[c3c ) **Q 1#$&3.@=) **Q O SIc\c.@=)c]cJ` O **Q co 0$0cS"Ic4cS"J` S **Q G""=@[cSG&#$?S#c.@ S" **Q ="9`c&c<_" **Q #`0"# # **Q c1c$)0a29!`c3c $)0A2 **Q $)0A2c`c_$)0A2cac_ $)0A2cc$)0A2_ $)0A2c_c$)0A2_19$3_1<3 ="9 **Q c00% 0&#M9c19$3_cSG&#0&#M9c19$3 " **Q 0A2G2$)0A2 0A2 **Q 19$3_1SG&#9&#3 G2$) **Q c1c_c1qc_c3c_c3qc_cqc_cyqc G""=@ **Q cg$<0$0<-=^c19$3a < **Q 19$3_1?$3_1?&-<3I<Ic4c<J`J )*12" *57 88

119 ,% -./9 5.)) #$" %& '( : TU TU T7U T5U T U T6U T'U T(U TU 9<4% ":4<)49@4<* '#!!E0)>FC=F)>>= 2*NNFFFF7N#$N&G#0-A)-C) 9<4% ":4<)49@4<*!#!!!G!H)I 2*NNFFF2"Nd"N22NA)-C)-FFF(2 % ":4We4O ")* 5&!5#& 2*NNFFF-"!!))-)!NNNAC@) #!1-#!&! E':J!!?!'K!# )>>>F+CCCL 2*NNFFF-!"Nd"!N)N- F N@) G)"!4%@*!'&<J!!?.$ ## # +CCC 2*NNFFF"!-"NN)N-A)) ;))* E'#!#! 7JK! ## # +CCC 2*NNFFF"!FN"NN"A) % S@4WR4W"404!* M/.67N#!E&'!!'(! # 2*NNFFF))"N2)NKN22N,2<2" 9% f))4% F:!* 7!!E'J!!? 2*NNFFFKN)NA)N"A) <*! 2*NNFFFF"NNN)NM77'76 22 T U "* /!!!!# )9FC*F+CCC 2*NNFFF!F"N"NN-A)2" TU 9<* #! 2*NN!)!2"Nd"NA)C)-"N)N"A) TU $04&R)* $O Gg$))@#!!)49) 4=&7-('--6 )*12" *57 88

120 ,% -./9 =2)" #$" %& '(!77222=))=""7)2%) 77*%=G T,%U 1[A)QH H[3 1Y<GS#^0!)^#0% H2*NNFFF"N"F)"N N"!)""H3 1!)3 1")QH '(H3 13#$"1N3 13 '1N N3 13 1N3 1N"3 1")QH5' H3 13:% 1N N3 13 1N3 13 1N3 1"2)!)QH)<!:WH3 1!31N!3 1!3<#A1N!3 1N"2)!3 1N"3 1")QH ( H3 13<@<1N3 13 '1N3 1"2)!)QHR2 =))FH3 1!3OF1N!3 1!3<!<1N!3 1N"2)!3 1N"3 1")QH H3 13W"1N3 1"2)!)QH))O2-H3 1!31N!3 1!3<<)<!1N!3 1N"3 1N!)3 1N"2)!3 1Y00% 0&#!)I"`J3 1Y00% 0&#" I4I "2)!J`J3 1Y9###")<X$0.?$0<3 1Y00% 0&#IXS<9#9J3 1Y00% 0&#IXS<9#9J3 1Y00% 0&#IXS<9#9J3 1Y00% 0&#"2)!I!4!J3 1Y9###"2)!)S<9#9X$0.?$0<3 1Y00% 0&#!IXS<9#9J3 1Y00% 0&#!IXS<9#9J3 T<#<U P'!)4!&!1'2 )*12" *57 88

121 ,% -./9 #$" %& '(!77222=))=""7)2%) 77* )=G T,%U 1[A)QH H[3 1Y<GS#^0!^#0% H2*NNFFF"N"F)"N N!""H3 1!3 1QH 'H!QH"!H3 1)A3?1N)A3 1!3OF1N!3 1F31NF3 1N3 1QH H!QHAH3 1)A3,% "<!1N)A3 1!31N!3 12:)3G ( 6-6 1N2:)3 1F31NF3 1N3 1QH 6H!QH"AH3 1)A32<!1N)A3 1!31N!3 12:)3OIA% -JG 6 -' 1N2:)3 1F3 1NF3 1N3 1!<QHAH3 1)3<1N)313#A1N3 1N!3 1!<QH"H3 1)31N)3 13<!1N313<1N3 1N!3 1!<QH"!H3 1)3<1N)3 13<)1N313<!1N3 1N!3 1N!3 T<#<U 1Y00% 0&#!II!J`J3 1Y00% 0&#I)A4!4 2:)[4FJ3 1Y9###!<$0X$0.?$0<3 1Y9###S<9#9X$0.?$0<3 1Y00% 0&#I)A4!4 2:)[4FJ3 1Y9###S<9#9X$0.?$0<3 1Y00% 0&#!I)[4[4J3 1Y9###!"<X$0.?$0<3 1Y00% 0&#)AIXS<9#9J3 1Y00% 0&#!IXS<9#9J3 1Y00% 0&#2:)IXS<9#9J3 1Y00% 0&#FIXS<9#9J3 1Y00% 0&#)IXS<9#9J3 1Y00% 0&#IXS<9#9J3 1Y00% 0&#IXS<9#9J3 P'!+4!&!1$'2!77222=))=""7)2%) 77@%%HH* )=G T,%U 1[A)QH H[3 1Y<GS#^0!^#0% H2*NNFFF"N"F)"N N!""H3 1!3 1QH H!QHF:H3 1)A3% ""1N)A3 1!3!"1N!3 1F31NF3 1N3 1QH6H!QHAH3 1)A32<!1N)A3 1!31N!3 12:)35O" W) 1N2:)3 1F3 1NF3 1N3 1!<QHAH3 1)3<1N)313#A1N3 1N!3 1!<QHF:H3 1)3<1N)313O:1N3 1N!3 1N!3 T<#<U 1Y00% 0&#!II!J`J3 1Y00% 0&#I)A4!4 2:)[4FJ3 1Y9###!<$0X$0.?$0<3 1Y9###S<9#9X$0.?$0<3 1Y00% 0&#I)A4!4 2:)[4FJ3 1Y9###S<9#9X$0.?$0<3 1Y00% 0&#!I)[4[4J3 1Y9###!"<X$0.?$0<3 1Y00% 0&#)AIXS<9#9J3 1Y00% 0&#!IXS<9#9J3 1Y00% 0&#2:)IXS<9#9J3 1Y00% 0&#FIXS<9#9J3 1Y00% 0&#)IXS<9#9J3 1Y00% 0&#IXS<9#9J3 1Y00% 0&#IXS<9#9J3 P'!04!&!1!8!8$'2 )*12" *57 88

122 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, 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, Martina Welt Acherstr Waldbronn martina_welt@web.de Matrikelnummer:

123 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 2 Martina Welt, Matrikelnr Inhaltsverzeichnis 1. ÜBERBLICK 3 2. EINFÜHRUNG 5 3. DIE ANFRAGESPRACHE QUILT Anforderungen und Ziele beim Entwurf Die Vorgehensweise beim Entwurf Die Ein-/Ausgabestruktur in Quilt Ausdrücke in Quilt 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 Datenbankanfragen Grouping Joins Views Zusammenfassung und Bewertung Zusammenfassung Bewertung DIE ANFRAGESPRACHE XQUERY Anforderungen und Ziele beim Entwurf Die Vorgehensweise beim Entwurf Die Ein-/Ausgabestruktur von XQuery Ausdrücke in XQuery Primäre Ausdrücke Pfad-Ausdrücke Konstruktoren FLWR-Ausdrücke Sortierungsausdrücke Ausdrücke, die Operatoren und Funktionen beinhalten Bedingte Ausdrücke Funktionen Quantoren Datenbankanfragen Query Prolog Zusammenfassung und Bewertung Zusammenfassung Bewertung QUELLENANGABEN 26

124 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 3 Martina Welt, Matrikelnr Ü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.

125 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 4 Martina Welt, Matrikelnr Die Entstehung von Quilt und XQuery 1.0 XML-QL XQL SQL XPATH 1.0 OQL Lorel QUILT YATL XQuery 1.0 XPath 2.0 (Untermenge) Einfluss Übernahme von Features

126 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 5 Martina Welt, Matrikelnr 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.

127 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 6 Martina Welt, Matrikelnr Die Anfragesprache Quilt 3.1 Anforderungen und Ziele beim Entwurf 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 Die Vorgehensweise beim Entwurf 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.

128 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 7 Martina Welt, Matrikelnr 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 Elementkonstruktoren FLWR-Ausdrücke Ausdrücke, die Operatoren und Funktionen beinhalten Bedingte Ausdrücke Funktionen Quantoren Ausdrücke zum Binden von Variablen Nachfolgend wird mehr oder weniger detailliert auf die verschiedenen Ausdrücke eingegangen 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:. 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. Attribut des aktuellen Knotens * "any" (Knoten mit beliebigem Namen) [ ] schließen einen logischen Ausdruck ein, der als Bedingung für einen gegebenen Schritt dient [n] wählt das n-te Element einer Liste aus

129 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 8 Martina Welt, Matrikelnr 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 Pfad- Ausdrucks 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 "Baden- Wü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 = " NAMESPACE b2 = " document("schloesser.xml")//abc:museum[xyz:*] Elementkonstruktoren 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.

130 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 9 Martina Welt, Matrikelnr Beispiel: <Mitarbeiter Personalnummer = $pid> <Name> $name </Name> <Gehaltsgruppe> $gg </Gehaltsgruppe> </Mitarbeiter> 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 SELECT- FROM-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> $i </i> <j> $j </j>

131 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 10 Martina Welt, Matrikelnr </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> <i>1</i> <j>3</j> </Tupel> <Tupel> <i>1</i> <j>4</j> </Tupel> <Tupel> <i>2</i> <j>3</j> </Tupel> <Tupel> <i>2</i> <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 WHERE- Satz 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-

132 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 11 Martina Welt, Matrikelnr 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 WHERE- Satzes 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 Ausdrücke, die Operatoren und Funktionen beinhalten 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.

133 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 12 Martina Welt, Matrikelnr 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 C C B A B B C A 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 B B A A B 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>

134 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 13 Martina Welt, Matrikelnr 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) 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.

135 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 14 Martina Welt, Matrikelnr 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 Ausdrücke zum Binden von Variablen 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>

136 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 15 Martina Welt, Matrikelnr Datenbankanfragen In vielen Fällen können SQL-Anfragen direkt in Quilt-Anfragen übersetzt werden, indem SQL- Anfrageblö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 FOR $p IN document("produkt.xml")//produkttupel FROM Produkt WHERE contains ($p/beschreibung, "Zylinder") WHERE Beschreibung LIKE 'Zylinder' RETURN $p/produktnummer SORTBY (.) ORDER BY Produktnummer; -- Sortierung nach dem aktuellen Knoten 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 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 Views Mit Quilt können strukturierte XML-Views auf die Tabellen der relationalen Datenbank erstellt werden.

137 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 16 Martina Welt, Matrikelnr Zusammenfassung und Bewertung Zusammenfassung RANGE- Prädikat und Infix- Operatoren BEFORE und AFTER Binden von Variablen und Verwenden der gebundenen Variablen beim Erstellen neuer Strukturen Idee für FLWR- Ausdruck und der Subqueries, Aggregationsfunktionen und distinct-funktion XML-QL Pfad- Ausdrücke und Funktionenbibliothek XQL SQL Idee der Subqueries XPATH 1.0 OQL Lorel QUILT 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.

138 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 17 Martina Welt, Matrikelnr 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.

139 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 18 Martina Welt, Matrikelnr Die Anfragesprache XQuery 4.1 Anforderungen und Ziele beim Entwurf 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 Die Vorgehensweise beim Entwurf 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.

140 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 19 Martina Welt, Matrikelnr 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 Sortierungsausdrücke Ausdrücke, die Operatoren und Funktionen beinhalten 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.

141 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 20 Martina Welt, Matrikelnr 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 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"]

142 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 21 Martina Welt, Matrikelnr 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 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" } } }

143 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 22 Martina Welt, Matrikelnr 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 Sortierungsausdrücke 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 Ausdrücke, die Operatoren und Funktionen beinhalten 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.

144 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 23 Martina Welt, Matrikelnr 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 C C B A B B C A C A A B B Ergebnis von filter($doc//(a B)): B A B B A A B 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 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.

145 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 24 Martina Welt, Matrikelnr 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 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 Zusammenfassung und Bewertung 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

146 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 25 Martina Welt, Matrikelnr 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 Infix- Operatoren 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 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.

147 Seminar 1912: XML und Datenbanken - Thema 7: Quilt, XQuery Seite 26 Martina Welt, Matrikelnr 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, [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, => 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, [4] J. Clark und S. DeRose. XML Path Language (XPath), Version 1.0. W3C Recommendation 1999,

148 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 elke.pillis@fernuni-hagen.de

149 Elke Pillis Matrikelnummer: Seite: 1 Inhaltsverzeichnis 1 Einleitung und Grundbegriffe 2 2 Das XML-Modell MONET Ein Beispiel Datenstruktur und Algebra Das XML-Modell MONET Anfragen an das XML-Modell MONET 6 3 Hybride Datenbanken Objekt-Relationale Abbildungsverfahren 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 XML und Datenbanken Thema: Relationale DBMS I

150 Elke Pillis Matrikelnummer: 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 Abbildung 1-2 Vergleich XML und RDBMS (Software AG) 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 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

151 Elke Pillis Matrikelnummer: Seite: 3 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> <Hotel LfdNr = 2 > <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 o i zugewiesen wird. Hotelverzeichnis, o1 1 LfdNr Hotel, o2 Hotel, o9 LfdNr 2 Name, o3 Adresse, o5 Gastronomie, o7 Name, o10 Adresse, o12 Gastronomie, o14 CDATA, o4 CDATA, o6 CDATA, o8 CDATA, o11 CDATA, o13 CDATA, o15 string string string string string string Hotel Sonnenschein Zum Restaurant Sonnenberg 7 Hotel Zum Berg Am Bergrand 30 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,label E,label A,rank) ist ein Wurzelbaum mit Knoten V und Kanten E VxV und dem Wurzelknoten r V. Die Funktion label E : V string weist Knoten Labels zu, z.b. Elemente. label A : 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

152 Elke Pillis Matrikelnummer: Seite: 4 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 o 7. Der Pfad ist dann e e Hotelverzeichnis Hotel Gastronomie, der zugehörige Wert Restaurant hat den Pfad e e Hotelverzeichnis Hotel 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 M t (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. Seminar XML und Datenbanken Thema: Relationale DBMS I

153 Elke Pillis Matrikelnummer: Seite: 5 Unser Beispiel: e HotelVZ Hotel = {<o1,o2>,<o1,o9>} e e HotelVZ Hotel Name = {<o2,o3>,<o9,o10>} e e e HotelVZ Hotel Name CDATA = {<o3,o4>,<o10,o11>} e e e e HotelVZ Hotel Name CDATA String = {<o4, Hotel Sonnenschein >,o11, Hotel zum Berg >} e a HotelVZ Hotel Adresse = {o2,o5>,<o9,o12>} e e e HotelVZ Hotel Adresse CDATA = {<o5,o6>,o12,o13>} e e e e HotelVZ Hotel Adresse CDATA String = {<o6, Zum Sonnenberg 7 >,<o13, Am Bergrand 30 >} e e HotelVZ Hotel Gastronomie = {<o2,o7>,<o9,o14>} e e e HotelVZ Hotel Gastronomie CDATA = {<o7,o8>,<o14,o15>} HotelVZ e Hotel e e a Gastronomie CDATA String = {<o8, Restaurant >,<o15, Cafe >} e a HotelVZ Hotel LfdNr = {<o2, 1 >,<o9, 2 >} Exemplarisch wird im Folgenden der Aufbau der Tabellen für die Gastronomie dargestellt: Hotelverzeichnis -> Hotel o1 o1 o2 o9 Hotelverzeichnis -> Hotel -> Gastronomie o2 o9 o3 o10 Hotelverzeichnis -> Hotel -> Gastronomie -> CDA TA o3 o10 o4 o11 Hotelverzeichnis -> Hotel -> Gastronomie -> CDA TA -> String Insgesamt entstehen bei der Transformation unseres Beispiels 11 Tabellen. o4 o11 Restaurant Ca fe Abbildung 2-2 Tabellenaufbau Seminar XML und Datenbanken Thema: Relationale DBMS I

154 Elke Pillis Matrikelnummer: Seite: 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

155 Elke Pillis Matrikelnummer: 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 LfdNr = 1 > <Name>Hotel Sonnenschein</Name> <Adresse>Zum Sonnenberg 7</Adresse> <Gastronomie>Restaurant</Gastronomie> </Hotel> Dieses Beispiel sieht dann in der Datenbank so aus: OID Name Adresse Gastronomie 1 Hotel Sonnenschein Zum Sonnenberg 7 Restaurant 2... 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

156 Elke Pillis Matrikelnummer: Seite: 8 <Hotel LfdNr = 1 > <Name>Hotel Sonnenschein</Name> <Adresse>Zum Sonnenberg 7</Adresse> <Gastronomie>Restaurant</Gastronomie> </Hotel> <Hotel LfdNr = 3 > <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 Hotel Sonnenschein Zum Sonnenberg 7 NULL NULL Restaurant 3 Hotel Am Hang NULL Skigaudi Skihaserl 5 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 Hotel Sonnenschein Restaurant 3 Hotel Am Hang Apres Ski Bar Abbildung 3-3 Relation Hotel 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: Seminar XML und Datenbanken Thema: Relationale DBMS I

157 Elke Pillis Matrikelnummer: Seite: 9 <Hotel LfdNr = 1 > <Name>Hotel Sonnenschein</Name> <Adresse> <Straße>Zum Sonnenberg 7</Straße> <PLZ>99999</PLZ> <Ort>Sonnentaldorf</Ort> </Adresse> <Gastronomie>Restaurant</Gastronomie> </Hotel> Adresse OID Name Gastronomie Straße PLZ Ort 1 Hotel Sonnenschein Zum Sonnenberg Sonnentaldorf Restaurant Abbildung 3-7 Relation Hotel 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: <p> <b>nick Klappstuhl</b> aus lackiertem Metall/Kunststoff. 44x46 cm, 77 cm hoch. Sitzhöhe 43 cm. <i>dm 15.65</i> </p> Solche Elemente werden als XML-Typ in der OR-Datenbank abgelegt. Seminar XML und Datenbanken Thema: Relationale DBMS I

158 Elke Pillis Matrikelnummer: Seite: 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)> <!ATTLIST LfdNr id ID #REQUIRED> <!ELEMENT Anzahl_Zimmer (#PCDATA)> <! Privatzimmer -- > <!ELEMENT Privatzimmer (Name, Adresse, Fruehstueck)> <!ATTLIST LfdNr id ID #REQUIRED> <!ELEMENT Fruehstueck (#PCDATA)> </Zimmerverzeichnis> Zimmerverzeichnis Hotel Pension Privatzimmer Name Adresse Gastronomie Abendessen_fuer Name Adresse 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

159 Elke Pillis Matrikelnummer: Seite: 11 wd wq 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: Wie werden nun die einzelnen Gewichte ermittelt? w S wird folgendermaßen ermittelt: w = * w S + * w D + * w Q W S = S H + S A + S Q 3 wobei S H die Position in der Hierarchie ist Anzahl Vorgänger S H = 1 - Höhe des Baumes S A stellt die Ausnutzung der Alternativen in der DTD dar. Und zwar wird ermittelt, wie viele Elemente in der DTD als Alternativen definiert sind. S Q 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: D A W D = = D T 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

160 Elke Pillis Matrikelnummer: Seite: 12 Q A W Q = = Q T Anzahl der Abfragen, die dieses Element enthalten Gesamtanzahl der Abfragen Zusammenfassend kann dann die Gesamtgewichtung eines Knotens ermittelt werden: W = 1 1 D A 1 Q A (S H + S A + S Q ) D T 4 Q T 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

161 Elke Pillis Matrikelnummer: 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 XML- Dokument 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. Seminar XML und Datenbanken Thema: Relationale DBMS I

162 Elke Pillis Matrikelnummer: 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-3 Relation Hotel...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-7 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] 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 Seminar XML und Datenbanken Thema: Relationale DBMS I

163 Elke Pillis Matrikelnummer: Seite: 15 Anhang C: Vortragsfolien Seminar XML und Datenbanken Thema: Relationale DBMS I

164 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

165 Inhaltsverzeichnis: 1 Einleitung und Abgrenzung Der Ansatz von Florescu/Kossmann Der Kantenansatz ( Edge Approach ) Der Kantenansatz mit Separaten Datenwert-Tabellen Der Kantenansatz mit Inlining Der Attributansatz ( Attribute Approach ) Der Universelle-Tabelle-Ansatz ( Universal Table Approach ) Der Normalisierte-Universelle-Tabelle-Ansatz ( Normalized Universal Table Approach ) Performance Der Ansatz von Shanmugasundaram et al Die Basic Inlining Technik Die Shared Inlining Technik Die Hybrid Inlining Technik Transformation der semistrukturierten Abfragen in SQL Vorteile und Vergleich der Ansätze Vorteile und Probleme der vorgestellten Ansätze Vorteile im Vergleich zu anderen Datenbanksystemen Zusammenfassung...12 Abkürzungsverzeichnis 13 Literaturverzeichnis 14 Seite 2

166 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 XML- Daten 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 XML- Dokumenten 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 nichtrelationalen 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 XML- Dokumenten in relationalen Datenbanksystemen. Hier dargestellt werden die Speicherung nach Florescu/Kossmann [FlKo99a] und kurz die Speicherung nach Shan- Seite 3

167 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 XML- Element (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

168 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-Element- Referenz 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

169 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 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

170 Dabei ist die Struktur der Relationen die folgende: V type (vid, value) 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 Attribut- Tabellen wie es Attributnamen im Original-XML-Dokument gibt. Jede Attribut- Tabelle hat die folgende Struktur: A name (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

171 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, ordinal n1, flag n1, target n1, ordinal n2, flag n2, target n2,, ordinal nk, flag nk, target nk ) 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 Multiwert- Attribute in separaten Overflow-Tabellen gespeichert werden. Für jeden Attribut- Namen 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, ordinal n1, flag n1, target n1, ordinal n2, flag n2, target n2,, ordinal nk, flag nk, target nk ) Overflow n1 (source, ordinal, flag, target), Overflow nk (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

172 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

173 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

174 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 XML- Datenbanksysteme 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

175 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

176 Abkürzungsverzeichnis: DTD Oid OODBS ORDBS RDBS SQL Vid XML XML-QL Document Type Descriptors/Document Type Definition Object ID Objektorientiertes Datenbanksystem Objektrelationales Datenbanksystem Relationales Datenbanksystem Structured Query Language Value ID Extensible Markup Language XML Query Language Seite 13

177 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, [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), , [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), , 2001 [FeTS00] M. F. Fernandez, W. C. Tan und D. Suciu. SilkRoute: Trading Between Relations and XML. WWW9 / Computer Networks 33(1-6), , enoid_2.html [FiKM01] T. Fiebig, C.-C. Kanne und G. Moerkotte. Natix - ein natives XML- DBMS. 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, [FlKo99b] D. Florescu und D. Kossmann. Storing and Quering XML Data using an RDMBS. IEEE Date Engineering Bulletin 22(3), 27-34, Seite 14

178 [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, S , Berlin, [LOTU02] Lotus Notes [McAG+97] J. McHugh, S. Abiteboul, R. Goldmann, D. Quass und J. Widom. Lore: A database management system for semistructured data. SIG- MOD 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 , 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 , 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, S , Berlin, [Schö01] H. Schöning. Tamino - A DBMS designed for XML. ICDE 2001, , 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), , [STZ+99] J. Shanmugasundaram, K. Tufte, C. Zhang, G. He, D. J. DeWitt und Seite 15

179 [SYU99] [Timm99] J. F. Naughton. Relational Databases for Quering XML Documents: Limitations and Opportunities. VLDB 1999, , T. Shimura, M. Yoshikawa und S. Uemura. Storage and Retrieval of XML Documents using Object-Relational Databases. J. Timm. Speicherung von XML-Dateien in Objekt-relationalen Datenbanken. Diplomarbeit Universität Rostock, Fachbereich Informatik, Seite 16

180 FernUniversität Hagen Fachbereich Informatik Lehrgebiet Praktische Informatik IV 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

181 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 XML- Sichten 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* Name Gestein G1 Frankenjura Kalk G2 Pfalz Sandstein Tabelle Gebiet FelsID* GebietID Name kinderfreundlich F1 G1 Student nein F2 G2 Heufels ja F3 G1 Ankatalwand ja Tabelle Fels

182 - 3 - RoutenID* FelsID Name Laenge Schwierigkeit Ausrichtung R1 F3 Computerspiele 18 8 SW R2 F3 Internet 18 9 SW R3 F1 Simon S Tabelle Route RoutenID* Datum R R Tabelle Begehung Abb. 1: Tabellen der Datenbank Klettern <?xml version="1.0" encoding="iso "?> <!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"> <Länge>18</ Länge> <Schwierigkeit>8</ Schwierigkeit> <Ausrichtung>SW</Ausrichtung> </Route> <Route Name="Internet"> <Länge>18</ Länge> <Schwierigkeit>9</ Schwierigkeit> <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

183 SilkRoute SilkRoute SilkRoute XPERANTO XPERANTO XPERANTO XPERANTO <!-- klettergebiet.dtd (version 1.0) --> <!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 Route (Länge, Schwierigkeit, Ausrichtung?, Info?)> <!ATTLIST Route Name CDATA #REQUIRED> <!ELEMENT Länge (#PCDATA)> <!ELEMENT Schwierigkeit (#PCDATA)> <!ELEMENT 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: ist allgemein: die Daten aus einer relationalen Datenbank können auf eine beliebige DTD abgebildet werden ist dynamisch: die erzeugte XML-Sicht ist, wie oben bereits erwähnt, virtuell und wird erst im Zusammenhang mit Benutzerabfragen materialisiert 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 macht die Datenbestände auch ohne vorherige Abbildung auf eine DTD in einer Standardsicht zugänglich. ist rein XML-basiert, Sichtdefinition und Benutzerabfragen erfolgen in einer XML-Abfragesprache erlaubt nicht nur den Zugriff auf die Datenbestände der Datenbank, sondern auch auf Meta-Daten (Katalog-Information) 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-QL- Parser geparst. Der Abfrage-Zusammensetzer (s. Kap. 5) erzeugt aus der Benutzeranfrage und einer vorgegebenen Sichtdefinition (s. Kap. 4) eine zusammengesetzte Anfrage

184 Bei XPERANTO XPERANTO in 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 XML- Dokument, das an den Benutzer weitergegeben wird. Sichtdefinition (RXL) Anwendung Abfrage(XML-QL) XML-Schema XML-Dokument XML-QL Parser Abfrage- Zusammensetzer Abfrage- Übersetzer Sicht-Definition Sicht-Verwaltung Katalog- Information XML-Schema Erzeuger XML-Template XML- Erzeuger XML/DB Vermittler Abfrage(SQL) Ergebnis (Tupel) beide Systeme XPERANTO SilkRoute Abb. 4: Aufbau der Systeme zur Vermittlung zwischen XML und Datenbanken Datenbank Im Detail gibt es im Aufbau der beiden hier vorgestellten System einige Unterschiede: 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. generiert automatisch eine Standard-XML-Sicht in Form eines XML- Schemas 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. 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.

185 XPERANTO Der erzeugt zusätzlich zum XML-Dokument ein XML-Schema. Hierzu dient das Teilsystem XML-Schema-Erzeuger. 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 construct- Anweisung 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 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=" <complextype name ="gebiettupeltype"> <element name= "GebietID" type="string"/> <element name= "Name" type="string"/> <element name= "Gestein" type="string"/> </complextype>

186 - 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= "Name" 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= "Name" 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

187 Gewinnung Strukturierung Einfügen dem der Ausgehend 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: Weglassen von Elementen, die in der Sichtdefinition, nicht aber in der Benutzeranfrage enthalten sind 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 XML- Dokumenten 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 der Daten der Daten 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,

188 - 9 - Route.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

189 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

190 typ gebi D gebname Gestein fls ID felsname 1 G2 F2 Heufels ja kinde rfreun dlich rtnam e 2 G1 F3 Comput erspiele 1 G1 F3 Ankatalwand ja Laeng e Schwi erigke it 18 8 SW 2 G1 F3 Internet 18 9 SW 2 G1 F1 Simon S 1 G1 F1 Student nein 0 G2 Pfalz Sandstein 0 G1 Frankenjura Kalk Abb. 11: mögliches Abfrageergebnis nach dem (unsorted) node outer union-ansatz Ausric htung 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 D gebname Gestein fls ID 0 G1 Frankenjura Kalk felsname kinde rfreun dlich 1 G1 F1 Student nein rtnam e Laeng e Schwi erigke it 2 G1 F1 Simon S 1 G1 F3 Ankatalwand ja 2 G1 F3 Comput erspiele 18 8 SW 2 G1 F3 Internet 18 9 SW 0 G2 Pfalz Sandstein 1 G2 F2 Heufels ja Abb. 12: Abfrageergebnis nach dem sorted node outer union-ansatz Ausric htung 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

191 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:

192 GebietID Name Gestein G1 Frankenjura Kalk G2 Pfalz Sandstein FelsID GebietID Name kinderfreundlich F1 G1 Student nein F3 G1 Ankatalwand ja F2 G2 Heufels ja GebietID FelsID Name Laenge Schwierigkeit Ausrichtung G1 F1 Simon S G1 F3 Computerspiele 18 8 SW G1 F3 Internet 18 9 SW 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 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.

193 Abbildung Die Meta-Daten Vorhandene, 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: objektrelationaler Datenbanken (SQL 99) 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. können in Abfragen einbezogen werden. 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), , 2000, 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), , 2000, [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), , 2001, [4] Eric van der Vlist: Using W3C XML Schema, [5] XML-QL Users's Guide: Basics,

194 Native XML-Datenbanken: Natix und Tamino Seminararbeit zum Kurs 1912 im Sommersemester 2002 Dozent: Prof. Ralf H. Güting an der FernUniversität Hagen Lehrgebiet Praktische Informatik IV Von Monika Wienbeck, Matr.-Nr

195 Inhaltsverzeichnis 1. Natix und Tamino: Wer hat es entwickelt und warum? Daten- vs dokumentenzentrierte Dokumente Speicherung von XML-Dokumenten in relationalen Datenbanken Kernthemen in der Diskussion um native XML-Datenbanken Globale Vorgaben für Progammierschnittstellen (APIs) DOM (W3C) SAX Relevante Open issues, z.b. Views Natix Architektur Organisation der Speicherung von XML-Baumstrukturen Transaktionsverwaltung und Speicherebene in Natix Abfragen und Views Performance Diskussion Tamino Ausblick Literatur Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 2 von 22

196 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 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 XML- Datenbanken mit den Eigenheiten der zu verwaltenden Dokumente begründet. In der Praxis kommen jedoch häufig Zwischenformen vor. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 3 von 22

197 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, s, 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 von John Bosak in SGML Markup erstellt und auf XML umformatiert. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 4 von 22

198 Die data type definition (DTD) ist für alle im Korpus enthaltenen Dokumente einheitlich deklariert: <!-- DTD for Shakespeare J. Bosak , > <!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, Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 5 von 22

199 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> <p>text placed in the public domain by Moby Lexical Tools, 1992.</p> <p>sgml markup by Jon Bosak, </p> <p>xml version by Jon Bosak, </p> <p>this work may be freely copied and distributed worldwide.</p> </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. PERSONA- Textfelder (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 Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 6 von 22

200 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 XML- Ausfü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. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 7 von 22

201 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 Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 8 von 22

202 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 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 Software- AG bietet die Verwaltung von dokumentenzentrierten Dokumenten in nativen XML- Datenbanken 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. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 9 von 22

203 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 lassen 1 : 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 XML- Dokumente (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 Java- Programme 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-Groves 2 sowie des HyTime-Standards 3. 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] Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 10 von 22

204 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 SAX SAX ist eine eventbasierte Standard-API für XML (Simple API for XML). Der Java-Code und die Spezifikation sind unter publiziert und können dort frei heruntergeladen werden 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 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) 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. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 11 von 22

205 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++-DOM- Treiber, 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 Natix- Speicherebene 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 Speicherungsformat 4. 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. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 12 von 22

206 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.) Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 13 von 22

207 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üst- Aggregat 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 Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 14 von 22

208 des Objekts 5 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 Strukturinformation Header Header Inhalt Header PLAY-Knoten String-Literalknoten TITLE-Knoten Inhalt 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) Inhalt 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 Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 15 von 22

209 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) 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. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 16 von 22

210 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 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 Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 17 von 22

211 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. Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 18 von 22

212 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 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 Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 19 von 22

213 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 Seminar 1912, Ausarbeitung zum Vortrag Native XML-Datenbanken: Natix und Tamino von Monika Wienbeck Seite 20 von 22