XML Repositories Wieso speichert man XML? Klassische

Wieso speichert man XML?
XML Repositories
Web Informationssysteme
Wintersemester 2002/2003
Donald Kossmann
•
•
•
•
•
•
•
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!
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
Ü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)
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 (?)
1
Xmill Architektur
Xmill Beispiel
XML
<book price=„69.95“>
<title> Die wilde Wutz </title>
<author> D.A.K. </author>
<author> N.N. </author>
</book>
Parser
Path Processor
Cont. 1
Cont. 2
Cont. 3
Cont. 4
Compr.
Compr.
Compr.
Compr.
– 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 / / )
Komprimiertes XML
Bewertung
Indexierung
• Index ist Abbildung Wert -> XML Instanz
• Für XML verschiedene Arten von Indexen
• Vermeidung von Redundanz, Inkonsistenzen
• Mächtige Zugriffsmöglichkeiten
– Abhängig von Indexierung und Tools evtl. okay
– Siehe Kapitel 7
• Mehrbenutzerbetrieb
• Dauerhaftigkeit der Daten, Robustheit
• Problem: Zeiger auf XML Instanz.
• Identifiziere einen Knoten oder Wert durch
–
–
–
–
–
– Bei niedriger Updaterate; sonst schlecht
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
•
•
•
•
(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)
Prüfung von Integritätsbedingungen
Sicherheit
Skalierbarkeit, Performance
Kosten
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
2
Bewertung
<person, id = 4711>
<name> Lilly Potter </name>
person
<child> <person, id = 314>
<name> Harry Potter </name>
</child>
name
person
4711
child
Lilly Potter
James Potter
person
314
name
</person>
<person, id = 666>
<name> James Potter </name>
666
name
Harry Potter
<child> 314 </child>
•
•
•
•
•
•
•
•
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.
</person>
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)
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)
Natix
<bib>
<book>
<title>...</title>
<author>...</author>
</book>
</bib>
bib
book
title
author
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]
3
Element Knoten
[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>
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 ELEM] [code] [element of int]
[BEGIN TEXT] [CharData(„007“)] [END TEXT] [Int(5)]
[END ELEM]
[BEGIN ATTR] [hobby] [string*]
[CharData(„Fußball Hockey Lesen“)]
[string(„Fußball“)] [string(„Hockey“)] [string(„Lesen“)]
[END ATTR]
Komprimierung, Mergen
Identifikatoren
• 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
• 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
B+ Baum für Suche nach ID
• Zerhacke TokenStream in Blöcke
• (Alternative: Organisation alla Natix)
• Optional: Speichere zusätzliche Referenzen
5
– Begin -> End (für Geschwister, Insert at End)
– Begin -> Parent (für Reverse Traversal)
– (Verzeigerung zu Kindern implizit)
3
3
• Optional: Verwende B+ Baum für Ids
1
2
3
4
5
6
7
8
4
Bewertung
B+ Baum für Suche nach ID
•
•
•
•
•
•
•
•
6
3
1
2
3
3
4
5
6
7
8
9
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 ungleich Relational
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
•
•
•
•
•
Name
Harry Potter
Age
12
Child
NULL
Hobby
?
James Potter
NULL
?
NULL
Lilly Potter
NULL
?
NULL
viele NULL Werte
Probleme mit Kollektionen (mehrere Hobbies)
Verschachtelung vs. IDREFs
wie behandelt man neue Elemente (z.B. Adresse)
XML Elemente vs. Attribute, Reihenfolge
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!
5
XML Beispiel
Shredding
<person, id = 4711>
• Idee: Zerlege XML in seine Einzelteile
– Abbildung: XML -> Graph
– Speichern der Knoten und Kanten in Tabellen
<name> Lilly Potter </name>
<child> <person, id = 314>
• Ü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>
person
<child> <person, id = 314>
</child>
Lilly Potter
</person>
<person, id = 666>
<person, id = 666>
<name> James Potter </name>
<child> 314 </child>
Speichern eines Graphen
Edge Approach
person
<name> James Potter </name>
i314
person
314
name
666
name
James Potter
Harry Potter
<child> 314 </child>
</person>
Binary Approach
Partitioniere die Edge Tabelle nach Label
Target
4711
666
314
</person>
</person>
4711
name child
<name> Harry Potter </name>
Person Tabelle
<hobby> Quidditch </hobby>
</child>
0
<name> Lilly Potter </name>
Source
0
0
i314
<name> Harry Potter </name>
Name Tabelle
Source
4711
666
314
Target
v1
v2
v3
Child Tabelle
Source Target
4711 i314
666
i314
Age Tabelle
Source Target
314
v4
Edge Table
Source
0
0
4711
4711
666
666
Label
person
person
name
child
name
child
Value Table (String)
Target
4711
666
v1
i314
v2
i314
Id
v1
v2
v3
Value
Lilly Potter
James Potter
Harry Potter
Value Table (Integer)
Id
v4
Value
12
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.
6
XML Triple (R. Bayer)
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
Pfad
Surrogat
Value
Author[1]/FN[1]
2.1.1.1
Rudolf
Author[1]/LN[1]
2.1.2.1
Bayer
name
<18
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
• ...
SELECT
FROM
WHERE
Bewertung
– 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.
Quidditch
Beispiel (Edge Approach)
Übersetzung kann automatisch realisiert werden
ABER! Nur für einen Subset von Xquery untersucht
• Vermeidung von Redundanz, Inkonsistenzen
• Mächtige Zugriffsmöglichkeiten
hobby
age
nv.value
Edge p, Edge n, Edge h, Value nv, Value hv
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“;
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
7
DTD Normalisierung
• 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: Relation „book“
<!ELEMENT book (title, author)>
<!ELEMENT article (title, author*)>
<!ATTLIST book price CDATA>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (fname, lname)>
<!ELEMENT firstname (#PCDATA)>
<!ELEMENT lastname (#PCDATA)>
<!ATTLIST author age CDATA>
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 „article“
<!ELEMENT book (title, author)>
<!ELEMENT article (title, author*)>
<!ATTLIST book price CDATA>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (fname, lname)>
<!ELEMENT firstname (#PCDATA)>
<!ELEMENT lastname (#PCDATA)>
<!ATTLIST author age CDATA>
book(bookID, book.price, book.title, book.author.fname,
book.author.lname, book.author.age)
article(artID, art.title)
artAuthor(artAuthorID, artID, art.author.fname,
art.author.lname, art.author.age)
Alle weiteren Elementtypen
XML-Anfrage -> SQL
• 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)
• 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;
8
DTDs mit Rekursion
<!ELEMENT book (author)>
<!ATTLIST book title CDATA>
<!ELEMENT author (book*)>
<!ATTLIST author name CDATA>
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
book(bookId, book.title, book.author.name)
author(authorId, author.name)
author.book(author.bookId, authorId, author.book.title)
• 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
Ü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?
– Indexierung, Komprimierung, Verschlüsselung
9