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 Informationen 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 verschiedene Zwecke gebraucht werden. In diesem Fall sind verschiedene Elemente von Interesse. Aus diesem Grund kann es wünschenswert sein, diese Daten entsprechend formatiert und transformiert zu bekommen.
XQuery (kürz. XML Query Language) ist eine vom W3C spezifizierte Abfragesprache. XQuery wurde implementiert um genau diese Anforderungen zu erfüllen. 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.
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 authoritative 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, Transformation 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 Language) 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 Microsoft 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 optional 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 Element 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 Elements. 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 Elements 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
[...]
- Citar trabajo
- Master of Science Dimitar Menkov (Autor), 2009, Entwicklung eines Tutorials für XQuery, Múnich, GRIN Verlag, https://www.grin.com/document/136542
