Entwicklung eines Tutorials für XQuery

Inhaltsverzeichnis

Abbildungsverzeichnis

Beispielverzeichnis

Tabellenverzeichnis

1. Einführung
1.1. XML als Sprache
1.2. Was ist eine Abfrage')
1.3. Warum ist XQuery nötig')
1.4. Das Beispiel

2. Datenmodell
2.1 Knoten
2.1.1 Knotenhierarchie
2.1.2 Knotenfamilie
2.1.3 Knotenidentität
2.2 Atomic Values
2.3 Sequenzen
2.4 Namespaces
2.5 Das Datenmodell als Baum
2.6 Das Datenmodell als Sequenz

3. XQuery als Abfragesprache
3.1 Input Funktionen
3.2 Navigieren durch den XML-Baum
3.2.1 Schritte
3.2.2 Achsen
3.2.3 Knotentests
3.2.4 Prädikate
3.2.4.1 Werteprädikat
3.2.4.2 Prädikate für Position
3.2.4.3 Das Kontext- Item
3.2.4.4 Der Baum in beiden Richtungen durchlaufen
3.2.4.5 Vergleich zwischen verschiedene Baumzweige
3.2.4.6 Finden eines Elements anhand seinen Namen
3.3 Erzeugen von XML Knoten und Attributen
3.3.1 Miteinbezogene Elemente und Attribute aus der Input- Dokument
3.3.2 Direkte Element- Konstruktoren
3.3.3 Computed Constructors
3.4. Verbinden und Restrukturieren von Knoten (FLWOR)
3.4.1 „For“ und „Let“ Klausel
3.4.2 „Where“ Klausel
3.4.3 „Order by“ Klausel
3.4.4 „Return“ Klausel
3.4.5 Joins
3.5 Operatoren und Bedingte Ausdrücke
3.5.1 Arithmetische Operatoren
3.5.2 Vergleichsoperatoren
3.5.3 Sequenz Operatoren
3.5.4 Bedingte Ausdrücke
3.6 Funktionen
3.6.1 Built-In Funktionen
3.6.2 Benutzerdefinierte Funktionen

4. Vergleich von XQuery mit anderen Technologien
4.1 Vergleich mit SQL
4.1.1 Relationales Model vs. XML Datenmodell
4.1.2 Syntax
4.1.3 Zusammenspiel von SQL und XQuery
4.2 Vergleich mit XSLT
4.2.1 Gemeinsame Komponenten
4.2.2 Unterschiede

5. Implementierungen
5.1 Saxon
5.2 eXist

6. Erweiterungen und Weiterentwicklungen von XQuery
6.1 Update Facility
6.2 Volltextsuche
6.3 XQuery 1.1

7. Zusammenfassung

Appendix A: Primitive Datentypen

Appendix B: Built-In Funktionen

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Ergebnis nach Select-Operation

Abbildung 2: Ergebnis nach ausgeführtem Update

Abbildung 3: Verarbeitungsmodell

Abbildung 4: Datenmodellkomponenten

Abbildung 5: Knotenhierarchie

Abbildung 6: Datenmodellinstanz als Baum

Abbildung 7: Datenmodellinstanz als Sequenz

Abbildung 8: Das „Mediathek“ Dokument

Abbildung 9: Computed Konstruktor Syntax

Abbildung 10: Syntax der FLWOR- Ausdruck

Abbildung 11: Syntax der for Klausel

Abbildung 12: Syntax der let Klausel

Abbildung 13: Syntax der order by Klausel

Abbildung 14: Syntax: bedingter Ausdruck

Abbildung 15: Syntax der Funktionsdeklaration

Abbildung 16: SQL (relationale) Repräsentation von Mediathek.xml -Auszug

Abbildung 17: SQL (relationale) Repräsentation von PlaylistMediathek.xml - Auszug

Abbildung 18: XQuery / XSLT /XPath

Abbildung 19: Syntax des insert Ausdrucks

Abbildung 20: Syntax des delete Ausdrucks

Abbildung 21: Syntax des replace Ausdrucks

Abbildung 22: Syntax des rename Ausdrucks

Abbildung 23: Syntax des Transform- Ausdrucks

Beispielverzeichnis

Beispiel 1: Kleines XML Dokument

Beispiel 2: Auszug aus generierte Mediathek.xml

Beispiel 3: Auszug aus generierte PlaylistMediathek.xml

Beispiel 4: Query mit Prolog und Body

Beispiel 5: Queryergebnis anhand Beispiel 4

Beispiel 6: Knotenarten und Knotenverwandtschaft

Beispiel 7: Der Name des ersten Kinderknoten innerhalb des ersten Musikstücks

Beispiel 8: Extrahieren von Atomic Values mittels data und string

Beispiel 9:Atomization

Beispiel 10:Eingabedokument mit Namensraum

Beispiel 11: Query mit Namensraum

Beispiel 12: Einfache Query

Beispiel 13: Ergebnis der Query

Beispiel 14: Einfache Navigation durch den XML- Baum

Beispiel 15: Anfrage mit Werteprädikat

Beispiel 16: Anfrage mit Prädikat für Position

Beispiel 17: Das Kontext-Item

Beispiel 18: XML Baum nach oben und nach unten durchlaufen

Beispiel 19: Vergleich zwischen verschiedene Baumzweige

Beispiel 20: Element anhand seines Namens finden

Beispiel 21: Elemente aus dem Input- Dokument

Beispiel 22: Konstruieren von XML- Elemente mit XML- Syntax

Beispiel 23: Hinzufügen eines Attributs zu einem Elementen

Beispiel 24: Entfernen von Kinder- Elemente

Beispiel 25: Einfacher computed Konstruktor

Beispiel 26: FLWOR

Beispiel 27: Query mit for Klausel

Beispiel 28: Query mit let Klausel

Beispiel 29: Query mit for und let Klausel

Beispiel 30: Query mit for und let Klausel

Beispiel 31: For Klausel: mehrere Variablen

Beispiel 32: Query mit where Klausel

Beispiel 33: Order by Klausel

Beispiel 34: Order by Klausel 2

Beispiel 35: Join

Beispiel 36: Join mit Prädikat

Beispiel 37: Outer Join

Beispiel 38: Implizite Typumwandlung

Beispiel 39: Der eq Operator

Beispiel 40: Expliziter cast bei untyped Values

Beispiel 41: Operator für Reihenfolgevergleich

Beispiel 42: Der union Operator

Beispiel 43: Der except Operator

Beispiel 44: Bedingter Ausdruck innerhalb eines FLWORs

Beispiel 45: Built-in Funktionen

Beispiel 46: Die Funktion string

Beispiel 47: Funktionsdeklaration

Beispiel 48: Rekursive Funktion

Beispiel 49: Kombination von Werte / distinct-values

Beispiel 50: Join in SQL / XQuery

Beispiel 51: Geschachtelte SQL / XQuery Abfragen

Beispiel 52: Erzeugen einer relationalen Tabelle mit XML Inhalt

Beispiel 53: Auslesen von XML-Daten bei MySQL

Beispiel 54: XQuery Syntax vs. XSLT Syntax

Beispiel 55: Push Stylesheet

Beispiel 56: Emulation von Templates durch benutzerdefinierte Funktionen

Beispiel 57: Anlegen einer neuen Collection

Beispiel 58: Speichern von XML- Dokumente in der Datenbank

Beispiel 59: Einfügen von neuen Knoten

Beispiel 60: Löschen eines Musikstücks

Tabellenverzeichnis

Tabelle 1: Achsen

Tabelle 2: Operatoren für Wertevergleich bzw. generelles Vergleich

Tabelle 3: Knotenvergleich

Tabelle 4: Reservierte Funktionsnamen

Tabelle 5: SQL Query vs. XQuery Query

Tabelle 6: SQL vs XQuery: Der IN Operator

Tabelle 7: SQL und XQuery not Operator / Funktion

Tabelle 8: Äquivalente Funktionen bei XQuery und SQL

Tabelle 9: Mengenoperatoren

Tabelle 10: Vergleich zwischen XSLT und XQuery Merkmale

1. Einführung

Am Anfang dieser Master- Arbeit wird ein kurzer Überblick über XML als Sprache geschafft. Anschließend wird erklärt was unter den Begriff „Abfrage“ zu verstehen ist. Sind beide Begriffe erklärt, wird dann besprochen warum eine XML- Abfragesprache wie XQuery notwendig ist. In Kapitel 2 wird das XQuery Datenmodell beschrieben. In Kapitel 3 wird XQuery als Abfragesprache ausführlich beschrieben. Hier wird erklärt wie durch das XML- Baum navigiert werden kann, wie neue Knoten und Attribute er-zeugt werden können. Weiterhin wird beschrieben wie Knoten restrukturiert werden können. Die so genannten FLWOR- Ausdrücke werden Schritt für Schritt erläutert, um dann die Sprache XQuery mit weiteren Technologien wie SQL und XSLT kon-zeptionell vergleichen zu können. Im Nachhinein werden zwei Implementierungen vorgestellt und ihre Funktionalität erläutert. Im Anschluss wird klar gemacht wie die Zukunft von XQuery aussieht und welche Weiterentwicklungen und Anforderungen geplant sind. Das gesamte Tutorial wird durch ein, von Anfang an sich erweiterndes, Beispiel begleitet. Das Beispiel orientiert sich an klassische Musikstücke aus einer iTunes Mediathek.

1.1. XML als Sprache

Die Extensible Markup Language (engl. für erweiterbare Auszeichnungssprache) ab-gekürzt XML, ist eine Auszeichnungssprache für Dokumente, die strukturierte Infor-mationen enthalten [XMLcom01]. XML wird zur Darstellung hierarchisch struktu-rierter Daten in Form von Textdaten verwendet. Es wird vor allem zum Austausch von Daten zwischen verschiedenen IT-Systemen über das Internet eingesetzt. Im Vergleich zu HTML sind die Tags (engl. für Auszeichnungselement) nicht fest defi-niert. Der Benutzer kann selbst neue Elemente und Attribute definieren und sie, ent-sprechend seinem Nutzen, benennen. Ein XML- Element kann unterschiedliche Da-ten enthalten und beschreiben. Meistens sind es Daten in Form von Texte, aber auch Grafiken oder abstraktes Wissen. Der wichtigste Punkt dabei ist, dass die Struktur (DTD und Schemata) und das Layout (CSS, XSL) streng voneinander getrennt sind. Auf diese Weise können ein und dieselben Daten z.B. einmal als Grafik und einmal als Tabelle ausgegeben werden. Daraus lässt sich schließen, dass die XML- Ele-mente den Inhalt beschreiben, und nicht seine Darstellung.

XML- Dokumente müssen sich an einigen Regeln halten („Wohlgeformtheit“):

- Das Dokument hat genau ein Wurzelelement. Unterhalb dieses Wurzel-element können weitere Elemente mehrfach und verschachtelt vorkommen
- Die Elemente mit Inhalt sollen zunächst geöffnet und anschließend ge-schlossen werden. Elemente ohne Inhalt können auch in sich geschlossen sein.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 1: Kleines XML Dokument

- Die Start- und Endtags sind ebenentreu-paarig verschachtelt usw.

Soll XML für den Datenaustausch zwischen verschiedene Systeme zum Einsatz kommen, ist es vorteilhaft, wenn das Format mit Hilfe einer Grammatik (z.B. DTD oder XML- Schema) definiert ist. Ein XML- Dokument wird als „gültig“ gekenn-zeichnet, wenn das Dokument:

- wohlgeformt ist
- auf eine Grammatik (z.B. DTD) verweist
- sich an die Regel der Grammatik hält

Weiterhin lassen sich XML- Dokumente, anhand ihres beabsichtigen Gebrauchs und ihres Strukturiertheitsgrades in strukturierte, unstrukturierte und semi- strukturierte Dokumente klassifizieren.

- Strukturierte (oder „datenzentrierte“) Dokumente: Dokumente, die hauptsäch-lich für die maschinelle Verarbeitung bestimmt sind. Die Dokumente folgen ein Schema, das Entitäten eines Datenmodells beschreibt und definiert, in welcher Beziehung die Entitäten zueinander stehen, sowie, welche Attribute die Entitäten haben. Das Dokument ist somit stark strukturiert und für den un-mittelbaren menschlichen Gebrauch weniger geeignet.
- Unstrukturierte (oder „dokumentzentrierte“) Dokumente: Dokumente, die von Menschen auch ohne zusätzliche Metainformationen verständlich sind. XML-Elemente werden hauptsächlich zur semantischen Markierung von Passagen des Dokuments genutzt (z.B. Kapitel oder Paragraphen eines Buches). Der Begriff „unstrukturiert“ ist ein wenig irreführend, da alle Dokumente eine ge-wisse Struktur haben, auch wenn diese Struktur nur implizit gegeben ist (z.B. Satzzeichen). Aufgrund der schwachen Strukturierung ist eine maschinelle Verarbeitung schwierig. XML könnte verwendet werden, um unstrukturierte Daten auszuzeichnen und zu repräsentieren. Diese Möglichkeit sollte aber vermieden werden. Im Allgemeinen ist XML für die semantische Auszeich-nung gedacht. Die Präsentation der Daten sollte z.B. an XSLT (Extensible Stylesheet Language Transformation) überlassen werden.
- Semi- strukturierte Dokumente: Eine Mischform für Dokumente, die stärker strukturiert als dokumentzentrierte Dokumente und wiederum schwächer strukturiert als datenzentrierte Dokumente sind.

1.2. Was ist eine Abfrage?

In Kapitel 1.1 wurde kurz über XML als Sprache diskutiert. In diesem Kapitel wird ein Überblick über dem Begriff „Abfrage“ geschafft. Es wird weiterhin erklärt wie tra-ditionelle bzw. nicht traditionelle Daten abgefragt werden können. Im Allgemeinen ist eine Abfrage (engl. query) „ to ask questions of, especially with a desire for autho­ritative information “[MWqu] (engl. für „Fragen zu stellen, mit dem Wunsch, vor allem eine verbindliche Auskunft zu bekommen“). Wenn eine Datenbank abgefragt wird, ist das Ziel keine wohlbegründete Vermutung zu bekommen, sondern eine präzise und verbindliche Antwort. Die zweite Definition des Begriffs „Abfrage“ ist in Bezug auf Datenbanken. In diesem Kontext ist die Rede von einer Abfragesprache (engl. query language). „[databases] provide a means of retrieving records or parts of records and performing various calculations before displaying the results. The interface by which such manipulations are specified is called the query language.“[BritQL] Eine Ab-fragesprache ist eine formale Sprache zum Suchen nach Informationen. Das Ergeb-nis einer Abfrage ist eine Teilmenge des zugrundeliegenden Informationsbestandes. Man spricht auch von Filterung der Daten. Das Ergebnis soll nicht unbedingt eine Teilmenge des Informationsbestandes sein, da Berechnungen ebenfalls möglich sind.

Das Ergebnis der Abfrage soll nicht nur ein Datensatz oder eine Menge von Datensätze zurückgeben, sondern eine Teilmenge der zugrundeliegenden Daten. Eine Manipulation der Daten soll auch möglich sein (Vergleich, Aggregation, Trans­formation etc.). Im Allgemeinen wird unterschieden zwischen eine Anfrage zur Se-lektion von Daten (SELECT), und eine Anfrage, die die Daten manipuliert (INSERT , UPDATE , DELETE).

Wie schon weiter oben erwähnt wurde, wird hier ein kurzer Überblick geschafft, wie traditionelle bzw. nicht traditionelle Daten abgefragt werden können. Zunächst soll klar gemacht werden was traditionelle Daten sind. Weitestgehend sind traditionelle Daten, Daten vom Typ integer, date und string. D.h. Daten, die leicht in Tabellen und Spalten gespeichert werden können. In den letzten 20-30 Jahren hat sich als beste Lösung fürs Abfragen von traditionellen Daten, SQL (engl. Structured Query Lan­guage) erwiesen.

Die Mehrheit der kritischen Daten der Welt sind in relationale Datenbanken ge-speichert. Das führt dazu, dass viele Benutzer und Applikationen SQL verwenden, um Daten zu finden, aufzurufen oder zu manipulieren. Anders formuliert: SQL hat sich als Benchmark (gold standard) fürs Abfragen von Daten etabliert. Deshalb ist es für jeden neuen Ansatz wichtig, dass es alle Sachen bewältigen kann, oder zu-mindest einen guten Argument gibt, warum bestimmte Sachen nicht gemacht wer-den. In Abbildung 1 und Abbildung 2 ist ganz grob gezeigt wie eine Tabelle einer relationalen Datenbank aussieht und wie die Daten mittels SQL abgefragt werden. In dieser Arbeit wird nicht detailliert auf die Eigenschaften und die Funktionalität von re-lationale Datenbanken und SQL eingegangen.

select *

from mediathek

where TrackID >= 1038 and TrackID <= 1041

order by TrackID desc;

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Ergebnis nach Select-Operation

update mediathek

set DateAdded = "2008-11-26 18:00:00"

where TrackID = 1040;

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Ergebnis nach ausgeführtem Update

Allerdings sind mindestens 90% der Daten der Welt nicht traditionell. Viele wertvolle Informationen sind z.B. in Word-Dateien, Power Point Präsentationen, PDF- Doku-mente, Diagramme etc. versteckt. „Nicht traditionelle Daten“ sind solche Daten, die normalerweise nicht als Zahlen, Daten oder Zeichenketten repräsentiert werden kön-nen [QuXML01]. Solche Daten sind z.B. Bilder, Videofilme oder erzählerische, dis-kursive Texte.

In diesem Abschnitt werden drei Ansätze vorgestellt, wie nicht traditionelle Daten ab-gefragt werden können – durch Metadaten, Objekte und Textauszeichnungen. Es wird angenommen, dass für das Musikstück „III. Allegretto non troppo - Allegro molto vivace“ von Mendelssohn folgende Daten vorhanden sind:

- Musik: III._Allegretto_non_troppo_-_Allegro_molto_vivace.aac
- Video: III._Allegretto_non_troppo_-_Allegro_molto_vivace.mpg
- Bild: III._Allegretto_non_troppo_-_Allegro_molto_vivace.jpg
- Partitur: III._Allegretto_non_troppo_-_Allegro_molto_vivace.pdf

1. Ansatz: Metadaten

Ein erster Ansatz für das Speichern von nicht traditionellen Daten liegt in der Tat-sache, dass die Daten wie ein black-box Datenblock gespeichert werden. Dazu wer-den noch die Metadaten hinzugefügt. Dieser Datenblock wird BLOB (engl. binary large object) genannt. Trotz seinem Namen, hat ein LOB (large object) keines der nützlichen Objektattribute. Die LOB Speicherung bedeutet nur, dass das Datenobjekt als ein Ganzes an einer Stelle gespeichert ist. Wenn die Daten schon „in einem LOB“ sind, kann der LOB in der Datenbank gespeichert werden. Dabei werden auch Meta-daten in anderen Spalten der Tabelle hinzugefügt. Auf diese Weise können die Meta-daten abgefragt werden, um eine bestimmte Instanz des LOBs zu finden oder, um Informationen über dem LOB zu bekommen. Es gibt mehrere Möglichkeiten Meta-daten zu generieren:

- In einige Datenformate sind die Metadaten eingebettet. Z.B. PDF und Micro­soft Word Dateien haben automatisch generierte Metadaten: Name des Au-tors, Name des Dokumentes, wann die letzte Änderung vorgenommen war, etc. Diese Metadaten können extrahiert und dann in der Datenbank gespei-chert und anschließend abgefragt werden.
- Der Benutzer, der die Daten veröffentlicht (speichert in die Datenbank), kann z.B. durch ein CMS (kürz. Content Management System) neue Metadaten hin-zufügen.

2. Ansatz: Objekte

Dieser Ansatz ermöglicht die Speicherung von nicht traditionellen Daten in eine Weise, so dass die Objekte durchsichtig sind (to-open-the-box). So kann z.B. ein PDF- Dokument wie ein PDF- Dokument behandelt werden und nicht wie ein black-box LOB. Das einzige, was getan werden soll, ist ein Objekttyp zu definieren, der die PDF- formatierte Daten repräsentieren kann. Dazu müssen noch einige Methoden definiert werden, die für PDF sinnvoll sind. Anschließend kann das eigentliche Do-kument abgefragt werden und nicht seine Metadaten.

3. Ansatz: Markup

Es wurde diskutiert, wie man nicht traditionelle Daten mit Metadaten dekorieren kann. Es wurde auch die Möglichkeit vorgestellt nicht traditionelle Daten mit Hilfe des Objekt- Ansatzes direkt abzufragen. Beide Ansätze verlangen aber einen speziellen und nicht standardisierten Aufwand. Der Metadaten- Ansatz verlangt manueller Aufwand oder Aufwand für die Programmierung, um die Metadaten zu generieren. Dabei sollen auch einige Designentscheidungen getroffen werden, wie diese Meta-daten gespeichert werden. Der Objekt-Ansatz verlangt die Definition von Objekttypen und Methoden. Dabei müssen Objekttypen für jeden Datentyp definiert werden.

Der dritte Ansatz ist durch Markup. Auf diese Weise wird ein XML- Dokument erzeugt, das durch existierende Tools beschrieben und abgefragt werden kann. XML ist ziemlich anders im Vergleich zu relationale Daten. Man kann natürlich XML Daten in z.B. relationale Daten konvertieren, um dann z.B. SQL als Abfragesprache nutzen zu können. In einigen Fällen ist das auch die beste Strategie. Wenn z.B. die XML - Daten sehr regulär sind und wenn sie mehrmals auf die gleiche Art und Weise abgefragt werden, dann ist es vielleicht effizienter die Daten in einem relationalen Kontext parat zu haben. Manchmal ist aber erwünscht die Daten in XML Format speichern und repräsentieren zu können. Abfragen von XML- Daten ist unterschied-lich als das Abfragen von relationalen Daten. Hier soll durch die Baumstruktur navi-giert werden, um z.B. den Inhalt eines Elements zu finden.

1.3. Warum ist XQuery nötig?

XML wird in den letzten Jahren immer öfters verwendet. Mittlerweile werden viele Informationen in XML gespeichert. Das gilt sowohl für XML- Datenbanken als auch für XML- Dokumente, die auf dem Dateisystem gespeichert sind. Diese Informa-tionen können strukturiert, semi- strukturiert oder relativ nicht strukturiert (z.B. Bü-cher) sein. Noch mehr Informationen werden zwischen verschiedene Systeme vor-übergehend als XML ausgetauscht. Die Informationen, können für verschiede Zwe-cke gebraucht werden. In diesem Fall sind verschiedene Elemente von Interesse. Aus diesem Grund kann es wünschenswert sein, diese Daten entsprechend forma-tiert und transformiert zu bekommen.

XQuery (kürz. XML Query Language) ist eine vom W3C spezifizierte Ab-fragesprache. XQuery wurde implementiert um genau diese Anforderungen zu erfül-len. Mit XQuery ist es möglich XML- Elemente zu selektieren, die Datenstruktur zu reorganisieren oder zu transformieren. Es ist ebenfalls möglich die Ergebnisse, die von der Abfrage zurückgegeben werden, in einer gewünschten Struktur auszugeben. XQuery bietet viele Features, die viele verschiedene Operationen an XML- Daten und Dokumente ermöglichen, wie z.B.:

- Selektieren von Informationen auf Basis eines spezifischen Kriteriums
- Ausfiltern von Informationen
- Informationssuche in einem oder mehreren Dokumenten
- Zusammenstellen (join) von Daten aus verschiedenen Dokumenten
- Sortierung, Gruppierung, Aggregation von Daten
- Transformation und Restrukturierung von XML- Daten in einer anderen Struktur
- Manipulation von Zeichenketten (strings)
- Ausführen von arithmetische Operationen

Es wurde gezeigt, dass XQuery nicht nur für Selektion von XML Daten verwendet werden kann, sondern auch für die Manipulation und Transformation der Ergebnisse. Die aktuelle Version XQuery 1.0 unterstützt keine update Funktion, was für XML- Da-ten, die in einem XML Datenbank gespeichert sind, sehr nützlich wäre. Zum jetzigen Zeitpunkt wird die Erweiterung XQuery Update Facility 1.0 verwendet, um Aktuali-sierungsoperationen auszuführen. In die angekündigte Entwicklung von XQuery 1.1 soll die update Funktionalität (siehe Kapitel 6.1: Update Facility) ebenfalls kompatibel sein. In die Weiterentwicklungen von XQuery wird im Detail in Kapitel 6 eingegangen.

Es gibt viele Gründe warum XML- Daten abgefragt werden. Bestimmt so viel wie die Gründe warum XML- Daten verwendet werden. Einige Beispiele warum XQuery als Abfragesprache verwendet wird:

- Suchen von Textdokumente, die in einer nativen XML Datenbank gespei-chert sind und Ausgabe der Ergebnisse.
- Extrahieren von Informationen aus einer relationalen Datenbank, um die Informationen in einem Web-Service zu nutzen.
- Generieren von Ergebnisse aus einer Datenbank, um die Daten im Web als XHTML (erweiterbares HTML) zu präsentieren.

1.4. Das Beispiel

Das Beispiel was uns durch dieses Tutorial begleiten wird, ist eine aus iTunes ex-portierte Mediathek. Das Beispiel orientiert sich an klassische Musikstücke und Play-listen. Die wichtigsten Eigenschaften eines Musikstücks sind in der XML Dokument eingetragen (z.B. Titel, Komponist, Artist, Album Genre, etc.). Beispiel 2 enthält In-formationen über zwei Musikstücke. Die gesamte Mediathek enthält 714 Musik-stücke. Beispiel 3 enthält Informationen über eine Wiedergabeliste (engl. playlist). Die gesamte Playlist- Mediathek enthält 45 Wiedergabelisten.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 3: Auszug aus generierte PlaylistMediathek.xml

2. Datenmodell

Zunächst wird das Verarbeitungsmodell von XQuery erklärt. Im Anschluss wird das XQuery Datenmodell (kürz. XDM) vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Verarbeitungsmodell

In Abbildung 3 sind die Komponenten des XQuery Verarbeitungsmodels dargestellt. Die XML Input Dokumente sind in diesem Tutorial, die Daten die abgefragt werden. Die Daten können in verschiedenen Formen bereitgestellt werden. Sie können XML-Dokumente, Fragmente aus XML- Dokumente, in nativen XML Datenbanken gespei-cherte Daten (z.B. eXist, siehe Kapitel 5.2), in relationale Datenbanken gespeicherte Daten, sein. Die XML- Daten müssen aber auf jeden Fall wohlgeformt sein.

Die XQuery Anfrage kann in einer Text- Datei oder im Programmkode enthalten sein. Es kann dynamisch vom Programmkode generiert werden oder manuell durch den Anwender eingegeben werden. Die Anfrage muss nicht unbedingt in einer Datei sein. Es kann von mehreren Dateien konstruiert werden, die so genannten Module. Eine Query beinhaltet ein Prolog und ein Hauptteil (engl. body), wobei das Prolog- Teil op­tional ist. Der Prolog steht am Queryanfang und da werden die verschiedenen Deklarationen eingetragen. Der Hauptteil besteht aus einem Ausdruck oder aus einer Sequenz von Ausdrücken, die mit Komma voneinander getrennt werden (Beispiel 4).

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 4: Query mit Prolog und Body

Das Ergebnis der oberen Abfrage ist im Beispiel 5 zu sehen. Wäre das Hauptteil oh-ne Komma gewesen, so würde es ein Syntaxfehler geben, da der Hauptteil aus zwei separate Ausdrücke bestünde.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 5: Queryergebnis anhand Beispiel 4

Der Kontext (das blaue Quadrat in Abbildung 3) beinhaltet Informationen, die die Queryauswertung beeinflussen. Im Kontext stehen z.B. externe Bibliotheken, Varia-blen, die außerhalb der Query oder im Prolog definiert sind, usw.

Der Query Prozessor ist die Softwarekomponente, die die Query parst, analysiert und im Anschluss auswertet. Die Analyse und die Auswertung kann mit der Kompi-lierung und Ausführung von Programmkode verglichen werden. In der Analysephase wird die Syntax der Query überprüft. In der Auswertungsphase werden eigentlich die Ergebnisse der Query ausgewertet [XQ01]. Diese Ergebnisse basieren logischer-weise auf das Input Dokument. Beide Phasen können statische und dynamische Fehler erkennen und Fehlermeldungen auswerfen. In XQuery sind die Fehlernummer in der Form z.B. FOAR0001 (Division durch 0). Die vollständige Liste der Fehler-nummer kann bei Bedarf nachgeschlagen werden [XQT-ER]. Das Ergebnis ist eine Sequenz von Werten, die vom Query Prozessor zurückgegeben wird. Die Ergebnisse können an der graphischen Benutzeroberfläche angezeigt werden, in einer XML-Datei gespeichert werden (engl. serialization) oder an einer weiteren Applikation wei-tergeleitet werden, die sich dann für die anschließende Verarbeitung der Daten kümmert.

Beachte: Bis jetzt wurde das Verarbeitungsmodell erklärt und der ist nicht mit dem Datenmodell zu verwechseln!

Das XQuery Datenmodell ist als ein formales Datenmodell definiert und nicht als XML- Text. Das XQuery Datenmodell ist offiziell als XQuery 1.0 und XPath 2.0 Da-tenmodell (XDM) bekannt. Jede Eingabe einer Query ist eine Datenmodellinstanz. Beziehungsweise ist die Ausgabe einer Query ebenfalls eine Datenmodellinstanz. Das Datenmodell ist nicht mit dem Infoset (das W3C Modell für XML, [XML-IS]) iden-tisch, weil das XQuery Datenmodell auch solche Werte (Ergebnisse) unterstützen soll, die kein vollständiges, d.h. kein wohlgeformtes XML- Dokument sind. Ein Bei-spiel für ein solches Ergebnis ist eine Sequenz, die kein Wurzelelement hat. Das Datenmodell beschreibt sowohl die Struktur der Eingabedokumente, als auch die Struktur der Ausgabe. Die Komponenten des XQuery Datenmodells sind:

- Knoten (engl. node): Ein XML- Konstrukt wie z.B. ein Element oder ein Attribut
- Atomic value: Ein einfacher Wert, bei dem kein Markup assoziiert ist.
- Item: Ein generischer Ausdruck, dass auf einem Knoten oder auf einem Datenwert verweist
- Sequenz: Eine geordnete Liste bestehend aus keinem, einem oder mehreren Items

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Datenmodellkomponenten

XQuery Datenmodellinstanzen können auf verschiedene Art und Weise konstruiert werden. Die XQuery Datenmodellspezifikation beschreibt, wie eine XDM Instanz aus dem Infoset und dem PSVI (kürz. Post-Schema-Validation-Infoset) erzeugt werden kann. Instanzen können auch direkt erzeugt werden, entweder als Ausgabe einer XQuery, oder durch direkte Konstruktion mittels einer Applikation. Die XDM Spe-zifikation definiert die XDM Instanz als eine Sequenz von Items, wobei jedes Item ein Knoten oder ein Wert ist.

2.1 Knoten

Die Knoten werden verwendet, um Konstrukte wie Elemente und Attribute zu repräsentieren. Knoten kommen als Ergebnis einer Anfrage oft vor. Z.B der Pfadausdruck doc("Mediathek.xml")/library/Tracks/track gibt 714 Ele-mentknoten zurück.

Im Allgemeinen werden 7 Knotenarten unterschieden:

- Document Node: Stellt das gesamte XML- Dokument (und nicht das äußerste Element) dar.
- Element Node: ein XML- Element
- Attribute Node: ein XML- Attribut
- Text Nodes: repräsentieren Zeichenketten, die in einem Element enthalten sind
- Processing Instruction Node: XML Befehlsverarbeitung
- Comment Node: ein XML- Kommentar
- Namespace: Jeder Namespace Knoten repräsentiert die Bindung von einer Namespace URI zu einem Namespace- Präfix oder zum Default- Namespace

Das Hauptaugenmerk dieses Tutorials ist jedoch auf Element-, und Attributknoten gesetzt, da die beiden Knotenarten am meisten in die Abfragen verwendet werden. Im Allgemeinen werden die Begriffe „Element“ und „Attribut“, statt Elementknoten und Attributknoten, verwendet.

2.1.1 Knotenhierarchie

Ein XML- Dokument oder ein XML- Fragment ist mit Hilfe einer Knotenhierarchie aufgebaut. An dieser Stelle wird noch einmal auf Beispiel 2 verwiesen. Wird dieses XML- Dokument (bzw. Fragment) im XQuery Datenmodell übersetzt, wird die Kno-tenhierarchie ersichtlich (siehe Abbildung 5).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Knotenhierarchie

2.1.2 Knotenfamilie

Um die Verbindung zwischen den verschieden Knoten besser darzustellen, werden die Knoten in einer Art „Familie“ aufgeführt. Auf diese Weise hat jeder Knoten eine verschiedene Art und Anzahl von Verwandtschaften. In diesem Tutorial werden fünf Verwandtschaftsarten kategorisiert und unter Zuhilfenahme von Beispiel 6 erklärt:

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 6: Knotenarten und Knotenverwandtschaft

- Children: Ein Element kann keine, eine oder mehrere Elemente als Kinder haben. Es kann zusätzlich Text, Kommentar oder Instruktion als Kind auf-weisen. Hier ist zu bemerken, dass Attribute nicht als Kind eines Elements aufgeführt werden. Ein Dokumentknoten kann ein Element als Kind haben. In diesem Fall ist dieses Element auch das äußerste (das root) Element. Kinder eines Dokumentknotens können auch Kommentare oder Instruktionen sein. Im Beispiel 6: TrackID, Name, Artist, Composer, Album, Genre, Kind, Size, TotalTime, TrackNumber, TrackCount und Year sind Kinder von track.
- Parent: Das Parent (engl. für Eltern) von einem Element ist entweder ein über-geordnetes Element, oder der Dokumentknoten. Das Elternteil eines Attributs ist das Element, in dem das Attribut eingebunden ist. Im Beispiel 6: Das Ele­ment track ist das Parent von TrackID, Name, Artist, Composer, Album, Genre, Kind, Size, TotalTime, TrackNumber, TrackCount und Year. Das Element Kind ist das Parent vom Attribut „aac“.
- Ancestors: Die Ancestors eines Elements sind alle „Vorfahren“ dieses Ele­ments. Anhand Beispiel 6 kann die Beziehung besser veranschaulicht werden: Die Ancestors vom Element TrackID sind die Elemente track und library.
- Descendants: Die Descendants eines Elements sind alle „Nachkommen“ dieses Elements. Anhand Beispiel 6 kann die Beziehung besser veranschau-licht werden: Die Descendants des Elements library sind die Elemente track, TrackID, Name, Artist, Composer, Album, Genre, Kind, Size, TotalTime, TrackNumber, TrackCount und Year.
- Siblings: Elemente, die dieselben Eltern haben. Attribute innerhalb eines Ele­ments sind keine Siblings. In Beispiel 6 sind die Elemente TrackID, Name, Artist, Composer, Album, Genre, Kind, Size, TotalTime, TrackNumber, Track-Count und Year Siblings zueinander.

2.1.3 Knotenidentität

Jeder Knoten hat eine eindeutige Identität. Es kann vorkommen, dass ins Input-Dokument zwei oder mehrere Knoten existieren, die exakt den gleichen Inhalt haben. Das heißt jedoch nicht, dass die Knoten auch die gleiche Identität besitzen. Hier ist zu bemerken, dass die Identität jeden einzelnen Knoten eindeutig ist. Sie wird vom Query-Prozessor zugeordnet und kann nicht abgerufen werden. Identitäten können jedoch mit dem is Operator (siehe Kapitel 3.5.3: Sequenz Operatoren) verglichen werden [XQ02].

Elemente und Attribute besitzen zusätzlich noch Namen. Die Namen können mittels der eingebauten Funktionen name, node-name und lokal-name abgerufen werden.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 7: Der Name des ersten Kinderknoten innerhalb des ersten Musikstücks

Beispiel 7 veranschaulicht, wie der Name des ersten Kinderknotens des ersten Mu-sik-stücks aus Mediathek.xml abgefragt werden kann.

2.2 Atomic Values

Das Atomic Value ist ein Wert aus dem Werteraum eines atomic type. Atomic type ist seinerseits ein primitiver einfacher Datentyp oder ein Datentyp, der mit bestimmten Restriktionen von einen primitiven Datentyp abgeleitet ist. Es sind 23 primitive ein-fache Datentypen (engl. primitive simple datatypes) definiert [XMLSCH-PDT]. Die primitive simple datatypes können im Appendix A nachgeschlagen werden. Die Wer-te 464 und „aac“ sind ein Beispiel für atomic values. Diese Werte können mit Hilfe der Funktionen string und data von einem Knoten oder ein Attribut extrahiert werden (siehe Beispiel 8).

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 8: Extrahieren von Atomic Values mittels data und string

Die Grenzlinie zwischen ein Knoten und das Atomic Value, das der Knoten enthält, ist oft verwischt. Dies ist der Fall, weil die Funktionen, die als Operand ein Atomic Value erwarten, auch Knoten akzeptieren. Z.B die Funktion substring erwartet als erster Operand ein Atomic Value. Beim Beispiel 9 wird einen Knoten, statt ein Atomic Value, als erster Operand übergeben. In diesem Fall wird der Wert des Knotens automatisch extrahiert und verarbeitet. Dieser Vorgang wird atomization genannt.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 9:Atomization

2.3 Sequenzen

Sequenzen sind eine geordnete Reihe von Items. Eine Sequenz kann keine, genau eine oder mehrere Items beinhalten. Anschließend ist jedes Item entweder ein Kno-ten, oder ein Atomic Value.

Meistens werden Sequenzen erzeugt, nachdem ein Ausdruck oder eine Funktion ausgeführt wurde. Die Ergebnisse sind dann in der Form einer Sequenz. Z.B. der Ausdruck doc(„Mediathek.xml“)/library/Tracks/track liefert eine Sequenz von 714 Items (in diesem Fall Musikstücke) zurück.

Eine Sequenz kann zusätzlich explizit erzeugt werden. Dazu wird ein Sequenz-konstruktor benötigt. Der Sequenzkonstruktor ist folgendermaßen aufgebaut: Eine Reihe von Werten, die mit Kommas voneinander getrennt sind. Der Ausdruck ("a", "b", 3) erzeugt eine Sequenz, die die drei Werte beinhaltet. Der Sequenz-konstruktor kann zusätzlich ein oder mehrere Ausdrücke enthalten. Z.B der Ausdruck (doc("Mediathek.xml")/library/Tracks/track, "a", "b", 3) liefert eine Sequenz mit 717 Items (die 714 Musikstücke und die 3 Werte). An der Stelle ist zu bemerken, dass der Sequenzkonstruktor in Klammern umschlossen ist.

Sequenzen haben keine Namen, können aber an einer Variablen gebunden werden. Z.B. die let Klausel bindet die Sequenz von 714 Musikstücke an einer Variable (in diesem Fall $track):

let $track := doc("Mediathek.xml")/library/Tracks/track

Bei einer Sequenz, bestehend nur aus einem Item, gibt es keinen Unterschied zwischen die Sequenz selber und das beinhaltete Item. Deswegen können Funk-tionen, die auf Items operieren, verwendet werden.

Eine leere Sequenz (Sequenz ohne Items) ist unterschiedlich zum leeren String (““) oder zum Wert 0. Viele vordefinierte Funktionen akzeptieren die leere Sequenz als Argument. Der Pfadausdruck doc("Mediathek.xml")/library/Tracks/track_foo wü-rde eine leere Sequenz liefern, wenn kein Element track_foo in dem Dokument Mediathek.xml existiert.

Ganz wenig Funktionen und Operatoren können im XQuery auf Sequenzen an-gewendet werden (z.B. min, max, sum, avg). Zusätzlich können Sequenzen mit Hilfe von Vereinigung, Durchschnitt und Differenz (union, intersect und except) mit-einander kombiniert werden (für Details siehe Kapitel 3.5.3: Sequenz Operatoren).

Ähnlich wie bei Atomic Values haben Sequenzen keine Identität. Es macht kein Sinn zu fragen ob ("a", "b", 3) und ("a", "b", 3) dieselbe Sequenz ist. Es kann ab-gefragt werden, ob der Inhalt gleich ist oder nicht.

2.4 Namespaces

Der Namensraum (engl. namespace) wird verwendet, um das Vokabular der Elemente und Attribute eines XML- Dokuments zu identifizieren, und um Namen von unterschiedlichen Vokabularen eindeutig zu machen.

Beispiel 10 zeigt ein Eingabe- Dokument, das eine Namensraumdeklaration be-inhaltet. Der Namensraum wird in ein Attribut xmlns deklariert. Das Präfix musik ist zum Namensraum http://www.musik.com/musik abgebildet. Das bedeutet, dass je-des Element oder Attribut mit dem Präfix musik im oben genannten Namensraum liegt.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 10:Eingabedokument mit Namensraum

Beispiel 11 zeigt eine Query, die der Name des Musikstücks sucht und ausgibt.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 11: Query mit Namensraum

Die Namensraumdeklaration auf Zeile 1 http://www.musik.com/musik bildet den Namensraum zum Präfix musik ab. Das Präfix musik wird in das Queryhauptteil genutzt, um auf die Elemente des Input- Dokuments zu verweisen. Der Namensraum (und nicht das Präfix) wird als ein Teil des Namens berücksichtigt, deshalb muss der URI in der Query und im Input-Dokument identisch sein. Das Präfix selbst ist irrelevant und kann frei definiert werden.

2.5 Das Datenmodell als Baum

Es soll das folgende XML- Fragment und der dazugehörige Datenmodellbaum (Ab-bildung 6) betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 ist unvollständig – es werden nicht alle Knoten und deren Eigenschaften angezeigt. Der Baum ist ähnlich zum XPath 1.0 Datenmodellbaum (engl. XPath 1.0 Data Model Tree) [XpDM01]. Einige Begriffe haben sich geändert – z.B. der Root Node ist jetzt Document Node, die Kommentar (comment) Eigenschaft [string-value] ist jetzt [content] usw. Der wichtigste Unterschied besteht in der Tatsache, dass jeder Knoten Typinformationen besitzt. Die Typinformation kann explizit in der [type-name] und [type-value] Eigenschaft gesetzt werden. Abbildung 6 zeigt, dass die XQuery Da-tenmodelldefinition nicht vollständig sauber und symmetrisch ist. Zum Beispiel es wäre präziser, wenn jeder Knoten ein Stringwert ([string-value]) und ein typisierten Wert ([typed-value]) besitzen würde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Datenmodellinstanz als Baum

[...]