XML Repositories

(1)

XML Repositories

Web Informationssysteme Wintersemester 2002/2003

Donald Kossmann

Wieso speichert man XML?

• Cache (z.B. Web Proxies)

• Dokumentenmanagementsysteme, Web Site

• Protokollierung von Business Prozessen

• Metadaten, Kataloge, Indexe

• Zwischenergebnis der Anfragebearbeitung

• Archivierung von Dokumenten

• Wissenschaftliche Daten (Messreihen) XML im „Äther“ bleibt wichtigstes Szenario!

Klassische Anforderungen an DB (nach Kemper / Eickler)

• Vermeidung von Redundanz, Inkonsistenzen

• Mächtige Zugriffsmöglichkeiten

• Mehrbenutzerbetrieb

• Dauerhaftigkeit der Daten, Robustheit

• Prüfung von Integritätsbedingungen

• Sicherheit

• Skalierbarkeit

Man braucht nicht immer alles. Es ist aber schön, nicht darüber nachdenken zu müssen!

Übersicht

• Reines XML

– Evtl. komprimiert – Evtl. indexiert

• Spezielle (interne) Repräsentation

– (DOM) Baum

– Token Stream

• (Objekt-) Relationaler Datenbank

– XML als BLOB

– SQL/XML

– Geschredded (generisch) – DTD / Schema Mapping – (XML Sicht auf relationale Daten)

Reines XML

• Beispiel: Normale Dateien im Filesystem

• (Alternativ: in DB als BLOB -> siehe später)

• Referenzierung über „Dateinamen“ (oder URI)

• Zusätzliche Indexe mit speziellen Tools möglich

– Insbesondere Schlüsselwortsuche

• Besonders relevant für folgende Anwendungen

– Cache, Web Site, Archivierung

• Zusätzliche Verbesserung durch Komprimierung

• Schätzung: 70 Prozent Marktanteil

Komprimierung

• Jedes klassische Verfahren anwendbar

– Z.B. Lempel-Ziv oder Huffman-Codierung

• Xmill: Besseres Verfahren; nutzt XML Struktur

– Grundidee: Trenne Daten -> geringere Enthropie – Trenne Daten und Struktur in Containern

komprimiere Tags im speziellen Container – Gruppiere Daten nach Typ (z.B. Integer, Namen, ...) – Verwende spezielle Kompressionsalgos für Container

z.B. gzip für strings; Nullsuppression für Integer

• Vorsicht

– Komprimierung nur für große Dokumente (> 20 KB) – Konflikt zwischen Komprimierung und Indexierung (?)

(2)

XML

Parser Path Processor

Cont. 1 Cont. 2 Cont. 3 Cont. 4

Compr. Compr. Compr. Compr.

Komprimiertes XML

Xmill Beispiel

<title> Die wilde Wutz </title>

</book>

– Codierung der Tags (Dictionary Compression):

book = #1, @price = #2, title = #3, author = #4

– Codierung des Inhaltes:

ints in C1, strings in C2

– Codierung der Struktur (/ für Endtags):

gzip( #1 #2 C1 #3 C2 / #4 C2 / #4 C2 / / )

Indexierung

• Index ist Abbildung Wert -> XML Instanz

• Für XML verschiedene Arten von Indexen

– Siehe Kapitel 7

• Problem: Zeiger auf XML Instanz.

• Identifiziere einen Knoten oder Wert durch

– URI des Dokumentes

– Start Offset im Dokument

– Ende Offset im Dokument (alternativ Länge) – Schön: IDs drücken Eltern-Kind Beziehungen aus – Schlecht: Physische IDs bei Updates

Bewertung

• Vermeidung von Redundanz, Inkonsistenzen

• Mächtige Zugriffsmöglichkeiten

– Abhängig von Indexierung und Tools evtl. okay

• Mehrbenutzerbetrieb

• Dauerhaftigkeit der Daten, Robustheit

– Bei niedriger Updaterate; sonst schlecht

• Prüfung von Integritätsbedingungen

• Sicherheit

• Skalierbarkeit, Performance

• Kosten

(DOM) Bäume

• Speichere XML Dokument als Baum – Geordnet und annotiert

• Beliebteste Schnittstelle zur Navigation: DOM – W3C Standard, viele Tools, sehr beliebt bei Apache – Aber Vorsicht: DOM und Xquery DM beißen sich

• Vorteile

– DOM als stabile Schnittstelle (Formatänderungen möglich) – Updates einfach zu implementieren

• Nachteile

– DOM schwergewichtiges Interface (-> Performance) – Pipelining nicht einfach

– Serialisierung für Speicherung auf Platte teuer (oder schwer)

Document Object Model (DOM)

• Erstes vom W3C standardisierte Datenmodell

• Drei Level ...

• Sehr beliebt in der Apache Community

• Verwendet im Internet Explorer (ab V 5.0)

• Repräsentiert XML als Baum

– Beliebte Repräsentation von XML (s. Kapitel 5)

• API zur Navigation im Baum

• Schwergewichtig

(3)

<person, id = 4711>

<name> Lilly Potter </name>

<name> Harry Potter </name>

</child>

</person>

<person, id = 666>

<name> James Potter </name>

</person>

person person

Harry Potter

name

name name

person

Lilly Potter James Potter

child

314 4711 666

Bewertung

• Vermeidung von Redundanz, Inkonsistenzen

• Mächtige Zugriffsmöglichkeiten

• Mehrbenutzerbetrieb

• Dauerhaftigkeit der Daten, Robustheit

• Prüfung von Integritätsbedingungen

• Sicherheit

• Skalierbarkeit, Performance

• Kosten (?) - viele public domain tools

Man kann mit DOM ein „Baum DBMS“ bauen. Aber ich glaube nicht, dass es einfach wird, gute Performance zu kriegen.

Natix

• Repräsentiere Dokument als Baum Referenzen auf Kinder, Vater, Geschwister

• Speichere Bäume in Blöcke auf Festplatte

• Mehrere Bäume (Dokumente) pro Block möglich

• Große Dokumente - Prinzip von B-Bäumen

– Splitte falls Dokument größer als Block – Halte Proxies für Teilbäume im Wurzelblock

Proxy hält Referenz auf einen Teilbaum im Kindblock – Speichere Teilbäume in jedem Kindblock

– (Baum von Blöcken ist allerdings nicht balanciert)

Natix

<bib>

<book>

</book>

</bib>

bib book

title author

Token Stream

• Grundidee: XML als Folge von Tokens

– Z.B. ein Token für die Zahl „3“

– Z.B. ein Token für <book>

– Z.B. ein Token für END ELEMENT.

• Verwende einen eventbasierten Parser (z.B. SAX)

– Events werden direkt in Tokens übersetzt

• Vorteile

– Sehr kompakte Repräsentation (Objektsharing!!!) – Pipelining sehr gut unterstützt

• Nachteile

– Schwierig zu debuggen, sensibel bei Formatänderung (man sieht nicht ganzes Element, schlechte Kapselung)

DM <-> Token Stream

• Document Knoten

[BEGIN DOC] ... Content ... [END DOC]

– Content ist Repräsentation von PIs, Wurzelelement, Kommentaren und Texten

• Text Knoten

[BEGIN TEXT] [CharData] [END TEXT]

– [CharData] trägt den Inhalt als Zeichenkette

• Kommentar

[BEGIN COMMENT] [CharData] [END TEXT]

• Processing Instruction

[BEGIN PI] [QName] [CharData] [END PI]

– [QName] repräsentiert einen qualifizierten Namen („prefix“ vom Typ URI und „localname“ als Zeichenkette)

• Namespace Knoten

[BEGIN NS] [QNAME] [END NS]

(4)

[BEGIN ELEM] [QName] [QName]

Namespaces Attributes

(Elements | Comments | PIs | Text)*

typed-value*

[END ELEM]

• 1. Qname: (qual.) Namen des Elementes

• 2. Qname: (qual.) Namen des Typs des Elementes

• <code>007</code>

[BEGIN ELEM] [code] [element of int]

[BEGIN TEXT] [CharData(„007“)] [END TEXT] [Int(5)]

[END ELEM]

Attribute Knoten

[BEGIN ATTR] [Qname] [Qname]

[CharData] [typed-values]*

[END ATTR]

• Namen und Typen wie beim Element

• „string-value“ als Zeichenkette

• <... hobby = „Fußball Hockey Lesen“ ...>

[BEGIN ATTR] [hobby] [string*]

[CharData(„Fußball Hockey Lesen“)]

[string(„Fußball“)] [string(„Hockey“)] [string(„Lesen“)]

[END ATTR]

Komprimierung, Mergen

• Qnames kann man „sharen“

– Wichtig für Dokumente mit vielen gleichen Elementen – Halte nur Zeiger auf Name und Typ

– MM: Spart Speicher und CPU für Object Allocation – Disk: Dictionary Compression

• „End“ Tokens sind statische Objekte – Erneut nur Zeiger anstatt ganzes Token notwendig – MM: Spart Speicher und CPU für Object Allocation – Disk: Spezielles (kurzes) END Symbol wie bei Xmill

• Mergen der Qnames in [BEGIN ELEM/ATTR]

– Spart keinen Speicher

– Spart CPU bei Iteration durch den Tokenstrom

Identifikatoren

• Optionaler Teil eines „Begin“ Tokens

– N.B. ohne IDs sind „Begin“ Tokens statische Objekte

• Aufbau eines Identifikators

– Code des Dokumentes (Ordnung auf Dokumenten) – Präfixnummer im Dokumentenbaum

– Postfixnummer im Dokumentenbaum – Zeiger auf Vater

• Verwendung von Ids in Anfragebearbeitung

– Sortieren in Dokumentorder, Prädikate auf Ordnung – Parent, Ancestor, Root Axes

Abbildung auf Blöcke auf Platte

• Zerhacke TokenStream in Blöcke

• (Alternative: Organisation alla Natix)

• Optional: Speichere zusätzliche Referenzen

– Begin -> End (für Geschwister, Insert at End) – Begin -> Parent (für Reverse Traversal) – (Verzeigerung zu Kindern implizit)

• Optional: Verwende B+ Baum für Ids

B+ Baum für Suche nach ID

1 2 3 4 5 6 7 8

5

3 3

(5)

B+ Baum für Suche nach ID

1 2 3 4 5 7 8 9

6

3 3

6

Bewertung

• Vermeidung von Redundanz, Inkonsistenzen

• Mächtige Zugriffsmöglichkeiten

• Mehrbenutzerbetrieb

• Dauerhaftigkeit der Daten, Robustheit

• Prüfung von Integritätsbedingungen

• Sicherheit

• Skalierbarkeit, Performance

• Kosten (?)

Ich habe es gebaut. Es funktioniert!

XML in Relationalen DBs

• XML als BLOB

• XML als Datentyp (SQL/XML)

• Generische Ansätze (shredding)

– Edge Ansatz, Binary Ansatz, Inlining, ...

– XML Triple

• Mapping von DTDs

XML ungleich Relational

• viele NULL Werte

• Probleme mit Kollektionen (mehrere Hobbies)

• Verschachtelung vs. IDREFs

• wie behandelt man neue Elemente (z.B. Adresse)

• XML Elemente vs. Attribute, Reihenfolge

NULL

? NULL Lilly Potter

NULL

? NULL James Potter

? NULL 12

Harry Potter

Hobby Child

Age Name

XML als BLOB

create table web page ( url varchar(100), xmlcontent blob);

• DB weiß nicht, dass sie XML speichert

• Keine Queryfunktionalität, keine Indexierung

– Anwendung, Middleware macht die Arbeit – Keine Integritätsbedingungen

• Zugriff in Granularität ganzer Dokumente

• Speichere reines XML oder Token Stream

• Dauerhaftigkeit, Robustheit, Sicherheit: okay

• Marktanteil (geschätzt): ca. 25 Prozent

SQL/XML

create table web page ( url varchar(100), xmlcontent XML);

• Derzeitige ISO (SQL) Standardisierungsinitiative – Besonders von Oracle gepusht

– http://otn.oracle.com/tech/xml/xmldb/htdocs/sql_xml_codeexamples.html

• Idee: XML als Datentyp für Spalte – XML Schemata importierbar

• Besondere Syntax für Konstruktoren, Xquery Ausdrücke

• Die Version, die ich kenne, noch unausgereift! (03/2002)

• Wird aber kommen!

(6)

Shredding

• Idee: Zerlege XML in seine Einzelteile – Abbildung: XML -> Graph

– Speichern der Knoten und Kanten in Tabellen

• Übersetze Anfrage nach SQL – Abbildung: XML Anfrage -> Graph

– Implementierung der Kanten durch Joins in SQL – Tagger in Middleware erzeugt XML

• Gutes Preis/Leistungsverhältnis

– Sehr einfacher, generischer Ansatz für jedermann

– Indexierung möglich (Werte, Struktur und Text/Schlüsselworte) – Ausnutzung der TA und Querymöglichkeiten von RDBMS – Anfragen auf XML und relationale Daten möglich – Aber: nicht optimal und passt nicht zu XQuery

• Hat den „Test of Time“ nicht bestanden!

<person, id = 4711>

<hobby> Quidditch </hobby>

</child>

</person>

<person, id = 666>

</person>

<person, id = 4711>

</child>

</person>

<person, id = 666>

</person>

person person

Harry Potter

name

name name

person

Lilly Potter James Potter

child

314 0

4711 666 i314

Speichern eines Graphen Edge Approach

i314 child 666

v2 name 666

i314 child 4711

v1 name 4711

666 person 0

4711 person 0

Target Label Source

Harry Potter v3

James Potter v2

Lilly Potter v1

Value Id

12 v4

Value Id

Edge Table Value Table (String)

Value Table (Integer)

Binary Approach

Partitioniere die Edge Tabelle nach Label

314 i314

666 0

4711 0

Target Source

Person Tabelle

v4 314

Target Source

Age Tabelle v3

314 v2 666

v1 4711

Target Source

Name Tabelle

i314 666

i314 4711

Target Source

Child Tabelle

Weitere Ansätze

• Universal Approach

OuterJoin aller „Binary Tables“

• Universal Normalized Approach

besondere Behandlung von Kollektion

• Inlining

„Binary Tables“ OuterJoin „Value Tables“

• XML Triple: Codierung der Pfade

• Mischformen und Varianten

• Besonderheit aller Varianten

– zusätzliche Felder für Reihenfolgetreue,

Unterscheidung von Elementen und Attributen, etc.

(7)

XML Triple (R. Bayer)

Bayer Rudolf Value 2.1.2.1 Author[1]/LN[1]

2.1.1.1 Author[1]/FN[1]

Surrogat Pfad

XML Anfragen

• Finde den Namen aller Personen, die jünger als 18 sind und Quidditch als Hobby haben

/persons[@age < 18 AND ./hobby = „Quidditch“]/name

• Repräsentiere Anfrage als Graph + Überdeckung person

name age

hobby

<18 Quidditch

XML-Anfragen -> SQL

• Jede Kante in der XML Anfrage wird zu einem Join in der SQL Anfrage

• Blätter in der XML Anfrage werden zu Joins mit der „Value Tabelle“

• // wird zu rekursiven SQL Anfragen

• Optionale Prädikate werden zu Outerjoins

• ...

Übersetzung kann automatisch realisiert werden ABER! Nur für einen Subset von Xquery untersucht

Beispiel (Edge Approach)

SELECT nv.value FROM Edge p, Edge n, Edge h, Value nv, Value hv WHERE p.label = „person“ AND

p.target = n.source AND n.label = „name“ AND n.target = nv.id AND p.target = h.source AND h.label = „hobby“ AND h.target = hv.id AND hv.value = „Quidditch“;

Bewertung

• Vermeidung von Redundanz, Inkonsistenzen

• Mächtige Zugriffsmöglichkeiten

– Komplettes Xquery nur in Middleware

• Mehrbenutzerbetrieb

• Dauerhaftigkeit der Daten, Robustheit

• Prüfung von Integritätsbedingungen

– Nur in Middleware möglich

• Sicherheit

• Skalierbarkeit, Performance (ausreichend?)

• Kosten (?)

Einsatzgebiete noch unklar.

DTD -> RDB Mapping

• Lit.: Shanmugarsadaran et al. VLDB 1999

• Idee: Übersetze DTDs -> Relationen – Elementtypen -> Tabellen

– Attribute -> Spalten

– Verschachtelung (= Beziehung) -> Tabellen – „Inlining“, um Fragmentierung aufzuheben

• Vorteile

– Intuitiv (?), gute Performance

• Nachteile

– Nicht universell: ANY, XML Schema (?)

• Keine Produkte bekannt; Leute machen es händisch

(8)

• Vereinfache DTDs (rechte Seite von Elemtyp)

(e1, e2)* -> e1*, e2* (e1, e2)? -> e1?, e2?

(e1 | e2) -> e1?, e2? e1** -> e1*

e1*? -> e1* e1?? -> e1?

..., a*, ... , a*, ... -> a*, ....

• Grundlage

– Gesetze regulärer Ausdrücke – Ordnung (Reihenfolge) ignorieren – Quantoren verallgemeinern

(Obermenge repräsentieren)

Beispiel

<!ELEMENT book (title, author)>

<!ELEMENT article (title, author*)>

<!ATTLIST book price CDATA>

<!ELEMENT title (#PCDATA)>

<!ELEMENT author (firstname, lastname)>

<!ELEMENT firstname (#PCDATA)>

<!ELEMENT lastname (#PCDATA)>

<!ATTLIST author age CDATA>

Beispiel: Relation „book“

<!ELEMENT author (fname, lname)>

book(bookID, book.price, book.title, book.author.fname, book.author.lname, book.author.age)

Beispiel: Relation „article“

<!ELEMENT author (fname, lname)>

article(artID, art.title)

artAuthor(artAuthorID, artID, art.author.fname, art.author.lname, art.author.age)

Alle weiteren Elementtypen

• Jeder Elementtyp -> Relation

– Element könnte ja Wurzel sein!

title(titleId, title)

author(authorId, author.age, author.fname, author.lname) fname(fnameId, fname)

lname(lnameId, lname)

XML-Anfrage -> SQL

• Intuitive Vorgehensweise, Rekursion bei //

– Viel weniger Joins als bei Shredding (!)

• Titel der Artikel mit einem Autor jünger als 18 /article[author/@age < 18]/title

SELECT a.title

FROM article a, artAuthor aa

WHERE aa.age < 18 AND a.artId = aa.artId;

(9)

DTDs mit Rekursion

<!ELEMENT book (author)>

<!ATTLIST book title CDATA>

<!ELEMENT author (book*)>

<!ATTLIST author name CDATA>

book(bookId, book.title, book.author.name) author(authorId, author.name)

author.book(author.bookId, authorId, author.book.title)

Bewertung

• Vermeidung von Redundanz, Inkonsistenzen

• Mächtige Zugriffsmöglichkeiten

– Komplettes Xquery nur in Middleware

• Mehrbenutzerbetrieb

• Dauerhaftigkeit der Daten, Robustheit

• Prüfung von Integritätsbedingungen

– Nur in Middleware möglich

• Sicherheit

• Skalierbarkeit, Performance (ausreichend?)

• Kosten (?)

Einsatzgebiete noch unklar.

Fazit

• Für einfache Anwendungen

– Reines XML im Filesystem oder als BLOB in RDB

• Für anspruchsvollere Anwendungen

– Token Stream

• Einsatz von relationalen Datenbanken

– Politikum, Religionskrieg

– RDBs ausgereifteste Technologie, aber passen nicht!

– SQL/XML könnte der Akzeptanz helfen

• Zusatzgimmics beachten

– Indexierung, Komprimierung, Verschlüsselung

Übungen

• Wieso braucht man bei der Repräsentation von Attributen im TokenStream sowohl den „string-value“ als auch die

„typed-values“. Geben Sie eine Beispielanfrage an.

• Repräsentieren Sie unsere Bibliothek (aus Kapitel 1) als XML TokenStream. Speichern Sie die Bibliothek in Tabellen.

• Bilden Sie folgende DTD ... auf ein relationales Schema ab.

• Wie kann man aus einem XML Schema ein äquivalentes relationales Schema ableiten. Was unterscheidet bzgl. des Mappings XML Schema von DTDs?