Verwaltung von XML-Dokumenten

(1)

(2)

Motivation



XML-Dokumente können für sehr verschiedene Anwendungen eingesetzt werden



Aussehen der Dokumente unterscheidet sich stark



Vielzahl von Methoden zur Speicherung existiert



verschiedene Abfragemethoden



Mehrere Varianten zur Modellierung von XML-

Dokumenten und deren Struktur

(3)

Daten oder Dokumente (1)



„Lesbare Dokumente“ (dokumentzentriert)

–

sind selten genau gleich strukturiert

–

Reihenfolge ist wichtig

–

sinntragende Daten auf allen Ebenen, viel Mixed Content

–

Volltextsuche ist unabdingbar, aber nicht ausreichend

–

Beispiele

 Zeitschriftenbeiträge, Bücher

 Gebrauchsanweisungen, Handbücher

 e-Mail

 Präsentationen

 Verträge

(4)

Daten oder Dokumente (2)



Datenzentrierte Dokumente

–

wie Daten im herkömmlichen Sinn (z.B. in relationalen Datenbanken)

–

Reihenfolge ist oft nicht relevant

–

sind einheitlich und meist einfach strukturiert

–

haben Datentypen

–

sinntragende Daten in Blattelementen oder Attributen

–

Mixed Content ist die Ausnahme (oder Dekoration)

–

Beispiele:

 Telefonbücher

 wissenschaftliche Daten

 Fahrpläne, Flugpläne Bestellungen

(5)

Daten und Dokumente



Semistrukturierte Daten

– Strukturiert: Felder

– Unstrukturiert: binäre Daten wie Text, Video- und Audio-Streams, Bilder (in XML: External Entities, CDATA Sections)

– unregelmäßiges Auftreten von Hyperlinks



Mangel an Struktur

– Mischform aus datenzentriert und dokumentenzentriert

– Struktur implizit oder verborgen

– Integration von Daten aus heterogenen Quellen (hierfür strukturiertes Modell oft zu restriktiv)

– Bestimmte Anfragetypen ignorieren Schema bewußt (z.B.

Zeichenkettensuche über gesamte Datenbank hinweg)



Beispiel Krankenakten:

– Krankenakten

 Daten: Geburtsdatum, Adresse, etc,

 binäre Daten: Röntgenbilder

(6)

Klassifikation: Beispiel

Datenzentrierte Dokumente

(strukturiert, regulär

Beispiele: Produktkataloge, Bestellungen, Rechnungen)

Dokumentzentrierte Dokumente

(unstrukturiert, irregulär

Beispiele: wissenschaftliche Artikel, Bücher, E-Mails, Webseiten)

Semistrukturierte Dokumente

(datenzentrierte und dokumentenzentrierte Anteile

Beispiele: Veröffentlichungen, Amazon)

<order>

<customer>Meyer</customer>

</position>

</order>

XML builds on the principles of two existing languages, <emph>HTML</emph> and

<emph>SGML</emph> to create a simple mechanism ..

The generalized markup concept ..

</content>

<book>

<author>Neil Bradley</author>

<title>XML companion</title>

XML builds on the principles of two existing languages, <emph>HTML</emph> and ..

</content>

(7)

Warum XML in Datenbanken



XML als SGML-Nachfolger

– entstehende Dokumente müssen gespeichert werden



XML als Austauschformat

– Originaldaten werden in XML transformiert

 Austauschdaten müssen aber ebenfalls gespeichert werden (z.B. beim Empfänger)



Nur die Speicherung in Datenbanken garantiert

– mächtige und effiziente Suchfunktionen

– transaktionsorientierte Speicherung

– Mehrbenutzerbetrieb



Anwendungen

– Dokumentenverwaltung

– Website-Management

– Verkaufsunterstützung

(8)

XML-Datenbanksysteme (1)



kann beliebige XML-Dokumente als solche speichern



kann XML-spezifische Anfragesprache verarbeiten



liefert XML als Ergebnis einer Anfrage

–

Dokumente und Extrakte



effiziente struktur-und wertebasierte Anfragen



unterstützt Daten- und Dokumentsicht (Mixed Content, Kommentare etc.)



erlaubt eine schematische Beschreibung der

Dokumente (Validierung möglich)

(9)

XML-Datenbanksysteme (2)



DB-Eigenschaften (Transaktionen, Skalierbarkeit etc.)



standardkonform



Sammlung von XML-Dokumenten?



Sammlung von XML-Dokumentfragmenten?



Unabhängigkeit von der Speicherungsstruktur



Indizierung?



Validierung



Sicherheit



Erweiterbarkeit

(10)

Speichern & Liefern von Dokumenten



Round-Trip-Problem

–

Gespeicherte Dokumente werden “unverändert“

geliefert



Der ganze Inhalt

–

Prolog

–

Kommentare

–

Processing Instructions



Was heißt “unverändert“

(11)

Anfragetypen: Werteorientiert



@attribute < 5

–

<element attribute=“4“/>



element < 7.1

–

<element>6.1</element>



element = “Hugo“

–

<element>Hugo</element>

–

<element><subelement>

Hugo

</subelement></element>

–

<element><B>H</B>ugo</element>

(12)

Anfragetypen: Textorientiert



documents containing “XML“



documents containing “XML“ OR “HTML“ but not “SGML“



documents containing “XML“ within two words of “database“



documents with word similar to “XML“ (ranking)

(13)

Anfragetypen: Strukturorientiert



siehe XPath Query Language



//Buch bzw. /[//Buch]

alle Buch-Elemente bzw. Dokumente, in denen ein Element “Buch“ vorkommt



//Buch/@ISBN bzw. /[//Buch/@ISBN]

der Wert des Attributs ISBN von Buch bzw.

Dokumente, in denen ein Element “Buch“ ein Attribut

“ISBN“ hat



/Buch/@*



/Buch/Titel



/Buch/Autor[1]



/Buch/*[1]



Titel AFTER /Buch/Autor

(14)

Weitere Anfragetypen



Linkorientiert

–

Dokumente, die auf eine bestimmte Stelle zeigen

–

Dokumente, die aus einem Dokument referenziert werden



Metadatenorientiert

–

Dokumente, die seit dem 1.1.2002 geändert wurden

–

Dokumente, die von Matthias Conrad gespeichert wurden



Kombinationen daraus

–

//Buch[Preis < 50 AND Titel CONTAINS “XML“]

(15)

Anfragesprachen



Es gibt noch keine normierte Anfragesprache für XML

– die XML Query Working Group (W3C) arbeitet daran



Anforderungen an die Anfragesprache liegen vor

– deklarativ

– protokoll-unabhängig

– auf allen Arten von Dokumenten (dokument- oder datenzentrisch), mit und ohne DTD

– Operationen auf Hierarchie und Reihenfolge

– Unterstützung von Sortierung von Aggregation

– XML-Repräsentation einer Query

– Berücksichtigung von Namespaces

– Unterstützung von Referenzen innerhalb und außerhalb von Dokumenten

(16)

XML-QL



W3C: http://www.w3.org/TR/NOTE-xml-ql



Datenquelle als URI



Aufbau:

WHERE Suchmuster IN Quelle CONSTRUCT Ausgabemuster



Beispiel-Anfrage in XML-QL (WHERE-Klausel):

WHERE <BOOK>

</BOOK> IN “www.booklist.com/books.xml“

CONSTRUCT <RESULT> $1 </RESULT>

Anfrage extrahiert Daten aus einem XML-Dokument, die in der Struktur BOOK-NAME-LAST zu finden sind und erzeugt Ergebnis- Dokument

(17)

XPath



Für die Verwendung in XSLT und XPointer entworfen



Beim W3C normiert (W3C Recommendation) http://www.w3.org/TR/xpath.html



Navigation in einem Dokument

–

Location Path

 Achsen zur Navigation

 child, descendant, parent, ancestor, sibling, following, preceding, attribute, namespace, self,

z.B. descendant::Name/child::Vorname

 Kurznotation ist verfügbar: //Name/Vorname

(18)

XPath (Forts.)



Filter

– [expression]

– Beispiel: //Buch[@ISBN=“3-557-06021-7“ AND Author]



Wildcard

– //*[@*=“Hugo“]



Position [pos]

– /book/author[1]



kann auf Processing Instructions und Kommentare zugreifen



Weitere Query Languages

– XQL: basiert auf XPath, W3C-Proposal

– Quilt: Basis für XQuery (zur Zeit diskutierter Sprachvorschlag)

– IPSI-QL (erste Implementierung)

(19)



Ziel: Anfrageergebnis wohlgeformtes XML



unterschiedliche Granulate

–

Dokument

–

Menge von Dokumenten (mengenorientierte Anfrage)

 erfordert systemdefinierte Wurzel

–

Element / Menge von Elementen (aus Dokument)

–

Attributwerte / Menge von Attributwerten

–

Elementwert / Menge von Elementwerten

Anfrageergebnisse

(20)

XML-Architektur

<..>

physische Ebene Ebene

Dokument- verarbeitung

Dokumenten Entwurf von XML-

Konzeptueller

</..>

logische Ebene

<..>

konzeptuelle

</..>

<..>

XML

Datenbanken

(21)

Logische Ebene

logische Ebene

<..>

<..> </..>

</..>

<..> </..>

datenzentriertsemistrukturiertdok-zentriert

Datenmodell

Anfragen/Updates an Inhalt

XML, RDBM, OODBM XQuery, SQL, OQL

Daten- und Dokumentmodell Struktur und InhaltAnfragen/Updates an

XML, OEM XQuery, Lorel Dokumentmodell Anfragen/Updates an Struktur und Inhalt XML,SGML

XQuery, XPath, DOM, IR-Anfragen

(22)

Realisierung Physische Ebene



Speicherung der XML-Dokumente als Ganzes und Indizierung (textbasiert native)

– Volltextindex

– Volltext- und Strukturindex



Speicherung der Graphenstruktur (modellbasiertes natives Verfahren)

– generische Graphspeicherung

– Speicherung der DOM-Informationen



strukturierte Abbildung auf Datenbanken

– relationale Datenbanken

– objekt-orientierte und objekt-relationale Datenbanken

– Einsatz von benutzerdefinierten Mappingverfahren

Ebene physische

(23)

Bedeutung des Dokumentcharakters



XML-Dokumente können die ganze Bandbreite von Daten bis zu Volltextdokumenten ein-

nehmen

–

dokumentzentriert, semistrukturiert, datenzentriert



dementsprechend unterschiedliche Speiche- rungsverfahren von der Dokumenten-

verarbeitung bis zur DB-Technologie



weiterhin: Neuentwicklung von Methoden



keine optimale Lösung für alle Anwendungen,

Dokumentcharakter spielt entscheidende Rolle!

(24)

Architektur: physische Ebene

datenzentriertsemistrukturiertdok-zentriert

relationale, objekt-relationale oder objekt-orientierte

Datenbanken

generische Speicherung von Graphen oder

DOM-Informationen Dateien

Volltextindex, Strukturindex Struktur auf Werteebene

Struktur auf Schema- und Werteebene

Struktur auf Schemaebene Ebene

physische

(25)

Volltextindex und XML-Index

Volltextindex Als Dateien /

Clobs

Speicherung der Dokumentstruktur

Strukturierte Speicherung in Datenbanken

Vollständiges Mapping Benutzer- definiertes

Mapping Abbilden des

DOM-Modells Abbildung der Graphstruktur

Für dokument-zentrierte XML-Dokumente

Für daten-zentrierte XML-Dokumente Für semistrukturierte XML-Dokumente

Speicherung von XML-Dokumenten

(26)

Grundprinzip der invertierten Liste

1 2 2 1 3 1 A

B

D E C

F 2

1

3

A D F

3

C D 3

B

A C D E

2

Bestimmung der Stichworte der Dokumente

Dokumente Stichworte

Invertierte Speicherung:

Speicherung der Stichworte und der zugehörigen Dokumente

Stichworte Dokumente

(27)

Volltext-Index

- bekannte Methode (älter als relationale Datenbanken) - Boolesches Retrieval (AND, OR, NOT)

Verweis

Warnemünde

<ort>Warnemünde</ort>

</adresse>

</anreisebeschreibung>

</hotel>

<hotelname>Hotel Hübner</hotelname>

Aus Richtung Rostock kommend ...

<hotel>

Begriff

anreisebeschreibung ort

Rostock hotel

<strasse>Seestraße</strasse>

(28)

Eigenschaften des Volltext-Indexes



Schemabeschreibung

– nicht erforderlich



Dokumentrekonstruktion

– Dokumente bleiben im Original erhalten



Anfragen

– Anfragen des Information Retrieval



Weitere Besonderheiten

– Volltextfunktionen (vgl. SQL-MM)

– keine Auswertung des XML-Markups



Einsatz

– für dokumentzentrierte XML-Anwendungen



Produkte

– Oracle InterMedia Text, DB2 Text Extender

(29)

Volltext- und XML-Index

Verweis

Verweis Seestraße

. . .

Vorgänger

Element

Volltext-Index

XML-Index Element

ort

Aus Richtung Rostock kommend fahren Sie auf der

hotel adresse

Stadtautobahn bis nach Warnemünde

strasse

<hotel>

</adresse>

Term

Warnemünde

Rostock

anreisebeschreibung

</hotel>

(30)

Volltext- und XML-Indexes

 Schemabeschreibung

– nicht erforderlich

 Dokumentrekonstruktion

– Dokumente bleiben im Original erhalten

 Anfragen

– Anfragen des Information Retrieval

– Auswertung des Markup in den Anfragen

– XML-Anfragen möglich

 Weitere Besonderheiten

– Volltextfunktionen (vgl. SQL-MM)

 Einsatz

– für dokumentzentrierte XML-Anwendungen

– auch für semistrukturierte Anwendungen

 Produkte

– Oracle InterMedia Text, DB2 Text Extender

(31)

Speicherung der Graphstruktur

Element

www...

Müller ort

plz

Value

Type Descendant-of

string string strasse

Warnemünde Seestrasse hotel

string Element

adresse

int 18119

Attribute Type Value

url autor

string Attributes:

Elements:

(32)

Speicherung der Graphenstruktur



Schemabeschreibung

– Zur Speicherung nicht erforderlich



Dokumentrekonstruktion

– Möglich, aber sehr aufwendig



Anfragen

– Angepaßte Datenbankanfragen



Weitere Besonderheiten

– Anfragen über vielen Elementen/Attributen sind aufwendig



Einsatz

– für daten- und dokumentzentrierte, sowie semistrukturierte XML- Anwendungen



Produkte

– Algorithmen von Florescu/Kossmann, Bradley u.a.

(33)

Speicherung des DOM / 1



Informationen des Document Object Models werden in Datenbanken

gespeichert



Verwendung

relationaler oder objekt-orientierter Datenbanken oder



Entwicklung eigener Speicherungsstrukturen

Comment

Document DocumentFragment

DocumentType Element

Entity EntityReference

Text

CDataSection

DOMImplementation Node NodeList NamedNodeMap

CharacterData Attr

(34)

Speicherung des DOM / 2

Methoden der Klasse Node:

- getChildren() - getFirstChild() - getNextSibling() - getNodeType() - getParentNode() - getPreviousSibling() - hasChildren()

Methoden der Klasse Element:

- getAttributes()

- getElementsByTagName(String) - getTagName()

Methoden der Klasse Attribut:

- getName() - getValue()

NodeID NodeType DocID ParentNode

NodeID ElementID AttributName AttributValue PreviousSibling NextSibling FirstChild

NodeID TagName

(35)

der Speicherung von DOM



Schemabeschreibung

– Zur Speicherung nicht erforderlich



Dokumentrekonstruktion

– Möglich, aber auswändig



Anfragen

– Angepasste Datenbankanfragen



Weitere Besonderheiten

– Standardisierte und allgemein akzeptierte Schnittstelle



Einsatz

– für daten- und dokumentzentrierte, sowie semistrukturierte XML-Anwendungen



Produkte

infonyte (IPSI Darmstadt), eXcelon XIS (POET), ozone (SMB)

(36)

auf relationale Datenbanken

-

DTD ist erforderlich

- Anfragen verwenden SQL - Funktionalität - Datentypen

...

</adresse>

</preise>

...

</hotel>

XML-Dokument HotelID Hotelname Adresse Preise

H0001 Hotel Hübner A0001 P0001

AdresseID Ort Strasse ...

A0001 Warnemünde Seestraße

PreiseID Einzelzimmer ...

P0001 198 Hotel:

Preise:

Adresse:

(37)

auf objekt-orientierte Datenbanken

-

DTD ist erforderlich

- Anfragen verwenden SQL - Funktionalität - Datentypen

HotelID Hotelname Adresse Preise

Ort Strasse ... einzelzimmer ...

H0001 Hotel Hübner Warnemünde Seestraße 198 Hotel:

XML-Dokument

...

</adresse>

</preise>

...

</hotel>

(38)

in Datenbanken



Schemabeschreibung

– Zur Speicherung erforderlich



Dokumentrekonstruktion

– Nur eingeschränkt möglich (Protokollierung des Abbildungsprozesses)



Anfragen

– Datenbankanfragen



Weitere Besonderheiten

– Föderationen mit bestehenden Datenbanken möglich



Einsatz

– für datenzentrierte XML-Anwendungen



Produkte

– Algorithmen: Bourret, Suciu (STORED), Shanmugasundaram u.a.

– Oracle XDK (XSU), Bluestone’s XML Suite

(39)

Benutzerdefiniertes Mapping

- Flexible Methode

- Integration von XML-Dokumenten in existierende Datenbanken

Hotel Hübner Hotel_URL

Hotelpreise

Name Einzelzimmer

www.hotel- huebner.de

198

Datenbank

</ToClassTable>

...

</adresse>

</preise>...

</hotel>

</ToColumn>

</PropertyMap>

</ToColumn>

</PropertyMap>

...

</Classmap>

XML-Dokument Mapping Vorschrift

(40)

benutzerdefiniertem Mapping



Schemabeschreibung

– Zur Speicherung erforderlich



Dokumentrekonstruktion

– Meist nicht möglich (Voraussetzung: Protokollierung des Abbildungsprozesses, vollständige Abb.)



Anfragen

– Datenbankanfragen

– XML-Anfragen in Ausnahmefällen möglich



Weitere Besonderheiten

– Integration in bestehende Datenbanken möglich



Einsatz

– für datenzentrierte XML-Anwendungen



Produkte

– DB2 XML Extender, Oracle XDK, Oracle 9iR2

(41)

Hybride Ansätze

Auswahl

unterschiedlicher

Speicherungsmethoden für verschiedene

Dokumentanteile

Hotel Ort Strasse Telefon komfortabel eingerichtetes 4-Sterne Hotel

direkt an der Strandpromenade von Warnemünde mit Blick auf Leuchtturm, Hafeneinfahrt

Sie finden unser elegant und

und Ostsee.

<hotel>

</adresse>

<hausbeschreibung> Sie finden unser elegant und

</hotel>

komfortabel eingerichtetes 4-Sterne Hotel

direkt an der Strandpromenade von Warnemünde mit Blick auf Leuchtturm, Hafeneinfahrt

und Ostsee. </hausbeschreibung>

<hotelname>Strand Hotel Hübner</hotelname>

(42)

Beschränkungen der Ansätze (1)



Speicherung als Ganzes

– Locking nur auf Dokumentebene möglich

– Bearbeitung von Teildokumenten schwieriger

– oft nur proprietäre Lösungen implementierbar

– Einschränkungen bei Anfragen (z.B. wertbasierte Suche)



Speicherung der Dokumentstruktur (bei Abbildung der Graphstruktur in Relationen):

– Anfragesprache: nur SQL

 keine adäquaten Anfragekonstrukte

 Anfrageformulierung schwierig

 Änderungen auf SQL-Ebene können Struktur des Dokuments zerstören

– schlechte Performance

 Shredding der Relationen ->komplexe Joins

 umfangreiche Sperren)

(43)

Beschränkungen der Ansätze (2)



strukturierte Speicherung in Datenbanken

–

Dokumente mit a priori bekanntem Schema, d.h.

geringe Flexibilität bei Schemaänderung

–

unterschiedliche Schemamächtigkeit

 Rekursion?

 Mixed Content?

–

Keine vollständige Abbildung von Dokumenten

 Reihenfolgeerhaltung

 Prolog, Kommentare, Processing Instructions

–

strukturorientierte Anfragen schwierig

(44)