ppt - HTWK Leipzig

Vergleichende Untersuchungen
zur Verwaltung von XMLDokumenten in Datenbanken
Prof. Dr. Thomas Kudraß
HTWK Leipzig
Datenbanken-Stammtisch
HTW Dresden, 23.10.2002
© Prof. T. Kudraß, HTWK Leipzig
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 XMLDokumenten und deren Struktur
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
Daten und Dokumente

Semistrukturierte Daten
–
–
–

Mangel an Struktur
–
–
–
–

Strukturiert: Felder
Unstrukturiert: binäre Daten wie Text, Video- und Audio-Streams,
Bilder (in XML: External Entities, CDATA Sections)
unregelmäßiges Auftreten von Hyperlinks
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:
–
–
–
Daten: Geburtsdatum, Adresse, etc,
binäre Daten: Röntgenbilder
Dokumente: Diagnose, Anamnese etc.
© Prof. T. Kudraß, HTWK Leipzig
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>
<isbn>1-234-56789-0</isbn>
<number>2</number>
<price currency=“Euro“>30.00</price>
</position>
</order>
<content>
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>
<isbn>1-234-56789-0</isbn>
<content>
XML builds on the principles of two existing
languages, <emph>HTML</emph> and ..
</content>
</book>
© Prof. T. Kudraß, HTWK Leipzig
Warum XML in Datenbanken

XML als SGML-Nachfolger
–

entstehende Dokumente müssen gespeichert werden
XML als Austauschformat
–
Originaldaten werden in XML transformiert


Nur die Speicherung in Datenbanken garantiert
–
–
–

Austauschdaten müssen aber ebenfalls gespeichert werden (z.B.
beim Empfänger)
mächtige und effiziente Suchfunktionen
transaktionsorientierte Speicherung
Mehrbenutzerbetrieb
Anwendungen
–
–
–
Dokumentenverwaltung
Website-Management
Information Publishing
© Prof. T. Kudraß, HTWK Leipzig
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)
nach [H. Schöning]
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
Speichern und Liefern von
Dokumenten

Round-Trip-Eigenschaft
–

Der ganze Inhalt
–
–
–

Ausgabe des gespeicherten Dokuments in “unveränderter“ Form
Prolog
Kommentare
Processing Instructions
“unverändert“
–
–
unveränderte Reihenfolge der Elemente
identisches Aussehen gegenüber Original
© Prof. T. Kudraß, HTWK Leipzig
Anfragetypen für XML-Dokumente

werteorientiert
–
–

textorientiert
–



Information Retrieval Operationen: contains, similar
strukturorientiert
–

Suche nach Attributwerten
Suche nach Elementen
vgl. XPATH Query Language
linkorientiert
metadatenorientiert
kombinierte Anfragen
nach [H. Schöning]
© Prof. T. Kudraß, HTWK Leipzig
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
© Prof. T. Kudraß, HTWK Leipzig
XPath (Forts.)

Filter
–
–

Wildcard
–


//*[@*=“Hugo“]
Position [pos]
–

[expression]
Beispiel: //Buch[@ISBN=“3-557-06021-7“ AND Author]
/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)
© Prof. T. Kudraß, HTWK Leipzig
XML-Architektur
[M. Klettke]
Dokumentverarbeitung
XML
Konzeptueller
Entwurf von XMLDokumenten
<..>
<..>
<..>
</..>
</..>
</..>
Datenbanken
konzeptuelle
Ebene
logische
Ebene
physische
Ebene
© Prof. T. Kudraß, HTWK Leipzig
Bedeutung des
Dokumentcharakters

XML-Dokumente können die ganze Bandbreite von
Daten bis zu Volltextdokumenten ein-nehmen
–



dokumentzentriert, semistrukturiert, datenzentriert
dementsprechend unterschiedliche Speicherungsverfahren von der Dokumentenverarbeitung bis
zur DB-Technologie
weiterhin: Neuentwicklung von Methoden
keine optimale Lösung für alle Anwendungen,
Dokumentcharakter spielt entscheidende Rolle!
© Prof. T. Kudraß, HTWK Leipzig
physische
Ebene
datenzentriert semistrukturiert
dok-zentriert
Architektur: physische Ebene
Struktur auf Werteebene
Dateien
Volltextindex, Strukturindex
Struktur auf Schemaund Werteebene
generische Speicherung von
Graphen oder
DOM-Informationen
Struktur auf Schemaebene
relationale, objekt-relationale
oder objekt-orientierte
Datenbanken
© Prof. T. Kudraß, HTWK Leipzig
XML in Datenbanken - Optionen zur
Realisierung
Klassifizierung nach dem Ziel-Datenmodell

Relational
–
inhaltsorientiert zerlegt


–
–

strukturorientiert zerlegt
opaque Ansatz (Large Objects)
Objektorientiert (Objektrelational)
–
–

generisch
definitorisch
benutzerdefinierte Objekte
vordefinierte Objekte, basierend auf Large Objects (CLOBS)
“native“ XML-DBMS
–
Oracle-Konkurrenzprodukte (z.B. Tamino)
nach [H. Schöning]
© Prof. T. Kudraß, HTWK Leipzig
Speicherung von XML-Dokumenten
Als Dateien /
Clobs
Speicherung der
Dokumentstruktur
Strukturierte
Speicherung
in Datenbanken
Volltextindex
Abbildung der
Graphstruktur
Vollständiges
Mapping
Volltextindex
und XML-Index
Abbilden des
DOM-Modells
Benutzerdefiniertes
Mapping
Für dokument-zentrierte XML-Dokumente
Für semistrukturierte XML-Dokumente
Für daten-zentrierte XML-Dokumente
[M. Klettke ]
© Prof. T. Kudraß, HTWK Leipzig
Oracle XML Infrastruktur - Basis für
verschiedene Speicherungsformen
Jserver Runtime
Java Applikationen
Tabellen
Java XML SQL Utility
interMedia
Java XML Parser
PL/SQL XML
Packages
JDBC Driver
URIs
XML Type
Object Types
LOBs
© Prof. T. Kudraß, HTWK Leipzig
CLOB-Ansatz (Opaque Ansatz)

Merkmale
–
–

XML-Dokument gespeichert als Large Object (LOB)
Dokument bleibt vollständig erhalten
Speicherung
DocId
url
1
person.xml
content
<person>
<name>Mary</name>
</person>
Insert into tblXMLClob values (1,‘person.xml‘,‘
<person>
<name>Mary</name>
</person>‘ );
© Prof. T. Kudraß, HTWK Leipzig
Kombinierter
Volltext- und XML-Index
Volltext-Index
Term
Verweis
Element
Warnemünde
Seestraße
Rostock
<hotel>
<hotelname>Hotel Hübner</hotelname>
<adresse>
<plz>18119</plz>
<ort>Warnemünde</ort>
<strasse>Seestraße</strasse>
</adresse>
<anreisebeschreibung>
Aus Richtung Rostock kommend fahren Sie auf der
Stadtautobahn bis nach Warnemünde
...
<anreisebeschreibung>
</hotel>
XML-Index
Element VerweisVorgänger
hotel
adresse
ort
strasse
anreisebeschreibung
XML - Struktur kann in
Anfragen ausgewertet werden
© Prof. T. Kudraß, HTWK Leipzig
Oracle interMedia Text

Anfragen mit interMedia Text
–
–
–

Volltext-Retrieval (nur wortorientierte Suche)
Pfadangaben nur in Verbindung mit Wortsuche
keine Bereichsanfragen
Beispiel in interMedia Text:
SELECT DocId FROM tblXMLClob WHERE
CONTAINS(content,‘(Mary WITHIN name) WITHIN person‘)>0

XML Volltext-Index
–
–
–
Autosectioner Index
XML Sectioner Index
WITHIN operator

text_subquery WITHIN elementname

sucht den vollständigen Textinhalt innerhalb der genannten Tags
© Prof. T. Kudraß, HTWK Leipzig
Beispiel:
Arbeit mit interMedia Text (1)
Speicherung von XML-Dokumenten einer
Versicherungsgesellschaft
create table ins_claim
(id number (7) primary key,
when date,
doc clob);
Spalte doc ist indiziert mit auto_section_group:
create index doc_ix on ins_claim(doc)
indextype is ctxsys.context
parameters (‘section group ctxsys.auto_section_group‘);
© Prof. T. Kudraß, HTWK Leipzig
Beispiel:
Arbeit mit interMedia Text (2)
Beispiel-Dokument in der Spalte doc:
The insured‘s <VEHICLE>car</VEHICLE>broke through the
guard rail and plummeted into a ravine. The cause was
determined to be <CAUSE>faulty braked</CAUSE> Amazingly
there were no casualties.
XML Section <cause> kann abgefragt werden:
select id, when
from ins_claim
where contains (doc,‘brakes within cause‘) > 0;
ID
------1
WHEN
-----12-OCT-00
DOC
------The insured‘s <VEHICLE>car...
© Prof. T. Kudraß, HTWK Leipzig
Beispiel:
Arbeit mit interMedia Text (3)
Alternative zu vordefiniertem AutoSectioner: Definition eines eigenen
Sectioners und Verwendung im Index
section name
tag name
ctx_ddl.create_section_group(‘my_section‘,
‘XML_SECTION_GROUP‘);
ctx_ddl.add_zone_section(‘my_section‘,‘cause‘,‘Cause‘);
...
ctx_ddl.add_attr_section(‘my_section‘,‘make‘,‘Make@Vehicle‘);
...
create index my_doc_ix on ins_claim(doc)
indextype is ctxsys.context
parameters(‘section group my_section‘);
Mögliche Abfrage ist Suche nach Attributwerten:
... where contains (doc, ‘Audi within Make@Vehicle‘)
Findet: <Vehicle Make=“Audi“>
© Prof. T. Kudraß, HTWK Leipzig
XPath Anfragen mit PL/SQL


Voraussetzung: XDK für PL/SQL auf Server vorhanden
Übersetze CLOB in eine DOM-Darstellung
XPath
Anfrage
Ermittle Document IDs aller
CLOBs der XML-Tabelle
serverseitig
DB
Doc IDs
Ausführen der XPath Anfrage auf dem DOMBaum für jedes CLOB Objekt der Doc IDs
Doc IDs mit Ergebnis XMLDokument
© Prof. T. Kudraß, HTWK Leipzig
Oracle 9i XML Type
Funktionen des Oracle XML Type
•
•
•
•
•
•
•
•
createXML(xml IN varchar2 return XMLType
createXML(xml IN clob) return XMLType
existsNode(xpath IN varchar2) return number
extract(xpath IN varchar2) return XMLType
isFragment() return number
// 1 oder 0
getClobVal() return clob
getStringVal() return varchar2
getNumberVal() return number
in Oracle 9i (Release 1) intern als CLOB realisiert
© Prof. T. Kudraß, HTWK Leipzig
Nutzung des XML Type
Extraktion von Daten aus XML-Dokumenten mittels XML Type Funktionen
select d.document.extract(‘/Item/desc/text()‘).getStringVal()
from xmldocs d;
select * from xmldocs d
where d.document.extract(‘/Item/Qty/text()‘).getNumberVal()=4;
select * from xmldocs d
where d.document.existsNode(‘//Discount‘)=1;
Insert, Update und Delete auf Spalten vom Typ XMLType erlaubt
Zugriff auf XMLType in der DB in Java möglich mittels Klasse:
oracle.xdb.XMLType
© Prof. T. Kudraß, HTWK Leipzig
Vergleich der Anfragemöglichkeiten
interMedia Text




liefert Dokument-IDs
Wordsuche (Default)
kein Existenztest für
Elemente oder Attribute
Pfadausdrücken beschränkt
möglich durch WITHIN
e.g.: (xml WITHIN title) WITHIN book



erlaubt begrenzt Attributwertsuche, keine Verschachtelung von Attributsuchen
numerische und Datumswerte
werde nicht konvertiert
keine Bereichsanfragen auf
Attributwerten
XPath





findet Dokument-Fragmente
Substring-Suche
Suche nach vorhandenen
Elementen oder Attributen
Pfadausdrücke  strukturorientierte Anfragen
//Book/Title/[contains(..‘xml‘)]



Suche nach Attributwerten
und Element-Text kann kombiniert werden
berücksichtigt auch Dezimalwerte
Bereichsanfragen möglich
mittels Filter
© Prof. T. Kudraß, HTWK Leipzig
CLOB Ansatz
Vorteile


Bewahrung der Informationen des Dokuments
Behandlung großer Dokumente
–

geeignet für dokumentenzentrische Dokumente mit
wenig Struktur und textreichen Elementen
Verschiedene XML Document APIs
–
–
interMedia Text: eingeschränkte Menge von XPathFunktionalität
generiere ein DOM des Dokuments vor Anwendung
von XPath-Queries
© Prof. T. Kudraß, HTWK Leipzig
CLOB Ansatz
Nachteile


Beschränkte Ausdrucksfähigkeit von Text-Anfragen
Performance vs. Genauigkeit der Anfrage-Ergebnisse
–
–

Restriktionen der Indexe
–

Maximale Länge der Tag-Namen fürs Indexieren (inkl.
Namespace): 64 Bytes
Probleme mit Markup
–

interMedia Text Queries auf CLOBs schneller als DOM-API
Beispiel-Dokument: 12.5 MB, Übersetzungszeit 3 Min.,
Ladezeit 5 Min.
Character Entities: Dekodieren oder nicht?
Stabilität
–
–
maximale Dokumentgröße: 50 MB
Speicherfehler bereits bei kleineren Dokumenten möglich
© Prof. T. Kudraß, HTWK Leipzig
Speicherung von XML-Dokumenten
Als Dateien /
Clobs
Speicherung der
Dokumentstruktur
Strukturierte
Speicherung
in Datenbanken
Volltextindex
Abbildung der
Graphstruktur
Vollständiges
Mapping
Volltextindex
und XML-Index
Abbilden des
DOM-Modells
Benutzerdefiniertes
Mapping
Für dokument-zentrierte XML-Dokumente
Für semistrukturierte XML-Dokumente
Für daten-zentrierte XML-Dokumente
© Prof. T. Kudraß, HTWK Leipzig
Speicherung der Graphstruktur
Elements:
Element
Type
Value
plz
int
18119
ort
string
Warnemünde
strasse
string
Seestrasse
Descendant-of
hotel
adresse
Attributes:
Element Attribute Type
Value
url
string
www...
autor
string
Müller
generische Speicherung der
Struktur des XML-Dokumentes
© Prof. T. Kudraß, HTWK Leipzig
Relationale Strukturorientierte
Zerlegung

Prinzip
–
–

Speicherung in generischen Tabellen (festes DB-Schema)
Zerlegung eines XML-Dokumentes in kleine Einheiten
(Elemente) und Speichern in der Datenbank (Shredding)
Vielzahl von Mapping-Methoden
–
–
Abspeichern der Kanten und Knoten des zum XML-Dokument
gehörenden Strukturbaums
Speichern der Kanten in einer Tabelle




–
Kantenverfahren (Florescu, Kossmann)
(Normalisiertes) Universalverfahren
Model-based Fragmentation
Monet XML-Modell
Speichern der Kanten in mehreren Tabellen

Attributverfahren
© Prof. T. Kudraß, HTWK Leipzig
Speichermethode [Krumbein]
XML-QL Datenmodell
1
tree
2
pe
rso
n
4
[age= 38]
Mary
Peter
s
re s
na m
e
p
on
e rs
ad
<tree>
<person age=’55‘>
<name>Peter</name>
</person>
<person age=’38‘>
<name>Mary</name>
<address>Fruitdale Ave.
</address>
3
</person>
[age= 55]
</tree>
na m
e

4711
Fruitdale
Ave.
© Prof. T. Kudraß, HTWK Leipzig
Datenmodell
tblDocs
DocId
url
1
n
tblEdge
SourceId TargetId LeafId AttrId DocId EdgeName Type Depth
1
0/1
0/1
tblLeafs
LeafId
1
tblAttrs
Value
AttrId
Value
© Prof. T. Kudraß, HTWK Leipzig
Import-Algorithmus
<baum>
<person alter=“36“>
<name>Peter</name>
<adresse>
<strasse>Hauptstrasse4</strasse>
<PLZ>04236</PLZ>
<Ort>Leipzig</Ort>
Source Target Leaf
</adresse>
Id
Id
Id
</person>
0
1
-1
</baum>
1
2
-1
DocId
1
AttrId
1
url
Beispiel.xml
Value
36
2
2
2
5
5
5
3
4
5
6
7
8
-1
1
-1
2
3
4
LeafId
Value
1
Peter
2
Hauptstr
asse 4
3
04236
4
Leipzig
Attr Doc EdgeName Type Depth
Id
Id
-1
-1
1
-1
-1
-1
-1
-1
1
1
1
1
1
1
1
1
baum
person
alter
name
adresse
strasse
PLZ
Ort
ref
ref
attr
leaf
ref
leaf
leaf
leaf
3
2
0
0
1
0
0
0
© Prof. T. Kudraß, HTWK Leipzig
Anfragemethode
XML-QL
Anfrage

ObjektStruktur
Parser
Generierung des
SQL Statement
Mit welcher Anfragesprache?
– XML-Anfragesprache
auf XML-Dokumente
sinnvoll
– Datenmodell ausgehend
von XML-QL erstellt
DB
Konstruktion des
Ergebnisdokuments
Ausführung des
SQL Statement
Row Set

XML
Dokument
SQL
Statement
Datenbank versteht nur SQL
– Transformation von XML-QL
nach SQL notwendig
– Erzeugen eines ErgebnisDokumentes aus Tupeln
© Prof. T. Kudraß, HTWK Leipzig
Erzeugen eines SQL-Statements

XML-QL Anfrage

SQL-Statement
SELECT DISTINCT
CONSTRUCT <result> {
B.Type AS n_Type,
WHERE
B.TargetId AS n_TargetId,
<person>
B.Depth AS n_Depth,
<name>$n</name>
C.Value AS n_Value,
<adresse>$a</adresse>
D.Type AS a_Type,
</person>
D.TargetId AS a_TargetId,
D.Depth AS a_Depth,
CONSTRUCT
E.Value AS a_Value
<person>
FROM
<name>$n</name>
tblEdge A,tblEdge B,tblLeafs C,
<adresse>$a</adresse>
tblEdge D,tblLeafs E
</person>
WHERE
} </result>
(A.EdgeName
(A.TargetId
(B.EdgeName
(B.LeafId =
(A.TargetId
(D.EdgeName
(D.LeafId =
= ‘person’) AND
= B.SourceId) AND
= ‘name’) AND
C.LeafId(+)) AND
= D.SourceId) AND
= ‘adresse’) AND
E.LeafId(+))
© Prof. T. Kudraß, HTWK Leipzig
Konstruktion des ErgebnisDokumentes

Ergebnistupel
n_Type n_Target n_Depth
Id
leaf
4
0
SELECT
A.EdgeName,
A.Type,
Al.Value AS A_LeafVal,
Aa.Value AS A_AttrVal
FROM
tblEdge A,
tblLeafs Al,
tblAttrs Aa
WHERE
A.SourceId=5 AND
A.leafId=Al.leafId(+) AND
A.attrId=Aa.attrId(+)
n_Value
Peter
•
a_Type a_Target a_Depth a_Value
Id
ref
5
1
Teilbaum-Rekonstruktion
EdgeName
Type
A_LeafVal
strasse
leaf
PLZ
Ort
leaf
leaf
Hauptstrasse
4
04236
Leipzig
A_Attr
Val
© Prof. T. Kudraß, HTWK Leipzig
Anfrageergebnis

XML-Ergebnis-Dokument
<result>
<person>
<name>Peter</name>
<adresse>
<strasse>Hauptstrasse 4</strasse>
<PLZ>04236</PLZ>
<Ort>Leipzig</Ort>
</adresse>
</person>
</result>
© Prof. T. Kudraß, HTWK Leipzig
Strukturorientierte Zerlegung Vorteile

Herstellerunabhängigkeit
–

Keine Schemadefinition durch Benutzer notwendig
–
–


hohe Flexibilität bei dynamisch erzeugten XML-Dokumenten
verwendete relationale Strukturen für Benutzer unbrauchbar
(keine Anwendungssemantik)
Stabilität
Hohe Flexibilität der Anfragen
–
–

benutzt keine spezifischen DBMS-Eigenschaften
Lesen und Ändern einzelner Werte
volle SQL-Funktionalität nutzbar
Gute Eignung für strukturorientierte Anfragen
–
Strukturen in Tabellen repräsentiert
© Prof. T. Kudraß, HTWK Leipzig
Strukturorientierte Zerlegung Nachteile

Informationsverlust
–
–
–
–
–

Comments
Processing Instructions
Prolog
CDATA Sections
Entities
Restriktionen des Abbildungsalgorithmus
–
nur ein Text (Inhalt) pro Element
<element>
Text1
<subelement/>
Text2
 geht verloren
</element>
–
Element-Text als VARCHAR(n); n <= 4000
© Prof. T. Kudraß, HTWK Leipzig
Strukturorientierte Zerlegung Nachteile (2)

Anfragesprache: nur SQL
–
–
–

keine XML-adäquaten Anfragekonstrukte
Anfrageformulierung schwierig
Änderungen auf SQL-Ebene können Struktur des
Dokuments zerstören
Schlechte Performance
–
lange Ladezeit

–
–
Beispiel-Dokument: 3.3. MB, 130.000 Zeilen, 13 Minuten
komplexe Joins
Sortierung in Anfragen (wegen
Reihenfolgeerhaltung)
© Prof. T. Kudraß, HTWK Leipzig
Speicherung von XML-Dokumenten
Als Dateien /
Clobs
Speicherung der
Dokumentstruktur
Strukturierte
Speicherung
in Datenbanken
Volltextindex
Abbildung der
Graphstruktur
Vollständiges
Mapping
Volltextindex
und XML-Index
Abbilden des
DOM-Modells
Benutzerdefiniertes
Mapping
Für dokument-zentrierte XML-Dokumente
Für semistrukturierte XML-Dokumente
Für daten-zentrierte XML-Dokumente
© Prof. T. Kudraß, HTWK Leipzig
Speicherung des DOM (1)

Informationen des
Document Object
Models werden in
Datenbanken
gespeichert
DOMImplementation
Node
NodeList
NamedNodeMap
Attr
CharacterData
Comment
Text
CDataSection


Verwendung
relationaler oder
objekt-orientierter
Datenbanken oder
Entwicklung eigener
Speicherungsstrukturen
Document
DocumentFragment
DocumentType
Element
Entity
EntityReference
Notation
ProcessingInstruction
© Prof. T. Kudraß, HTWK Leipzig
Speicherung des DOM (2)
Methoden der Klasse Node:
- getChildren()
- getFirstChild()
- getNextSibling()
- getNodeType()
- getParentNode()
- getPreviousSibling()
- hasChildren()
NodeID
NodeType
PreviousSibling
NodeID
ParentNode
NextSibling
FirstChild
NodeID
TagName
Methoden der Klasse Element:
- getAttributes()
- getElementsByTagName(String)
- getTagName()
Methoden der Klasse Attribut:
- getName()
- getValue()
DocID
ElementID
AttributName
AttributValue
© Prof. T. Kudraß, HTWK Leipzig
Speicherung des DOM: Bewertung

Vorteile
–
–
–
–
benötigt keine Schemabeschreibung
XML-Anfragen möglich
standardisierte und allgemein akzeptierte Schnittstelle
vielfältige Einsatzmöglichkeiten:


für daten- und dokumentzentrierte sowie semistrukturierte XMLAnwendungen
Nachteile
–
–
Dokumentrekonstruktion möglich, aber aufwändig
wenig Produkte auf dem Markt



infonyte (IPSI Darmstadt)
eXcelon XIS (POET)
ozone (SMB Leipzig)
© Prof. T. Kudraß, HTWK Leipzig
Speicherung von XML-Dokumenten
Als Dateien /
Clobs
Speicherung der
Dokumentstruktur
Strukturierte
Speicherung
in Datenbanken
Volltextindex
Abbildung der
Graphstruktur
Vollständiges
Mapping
Volltextindex
und XML-Index
Abbilden des
DOM-Modells
Benutzerdefiniertes
Mapping
Für dokument-zentrierte XML-Dokumente
Für semistrukturierte XML-Dokumente
Für daten-zentrierte XML-Dokumente
© Prof. T. Kudraß, HTWK Leipzig
Strukturierte Speicherung in
Datenbanken - Überblick

inhaltsorientiert
–

Struktur des Dokuments bestimmt DB-Struktur
generisch vs. definitorisch
–
generisch: vorgefundene Strukturen werden nach einem
allgemeingültigen Konzept in XML-Strukturen umgesetzt

–


gilt analog auch für Generierung einer DTD aus relationalem
Schema
definitorisch: die Abbildung der existierenden Strukturen in
XML-Strukturen (und umgekehrt) wird jeweils spezifiziert
relational vs. objektrelational
Beispiel (generisch & relational):
–
Oracle XML SQL Utility (XSU) für Queries und DMLOperationen
© Prof. T. Kudraß, HTWK Leipzig
Abbildung der XML- Struktur
auf relationale Datenbanken
XML-Dokument
<hotel url="www.hotel-huebner.de">
<hotelname>Hotel Hübner</hotelname>
<adresse>
<ort>Warnemünde</ort>
<strasse>Seestraße</strasse>
...
Hotel: HotelID
</adresse>
<preise>
<einzelzimmer>198</einzelzimmer>
...
</preise>
</hotel>
Adresse: AdresseID Ort
H0001
Hotelname
Adresse
Preise
Hotel Hübner
A0001
P0001
A0001
Preise:
- DTD ist erforderlich
- Anfragen verwenden SQL - Funktionalität
- Datentypen
Strasse
Warnemünde
...
Seestraße
PreiseID
Einzelzimmer
P0001
198
...
© Prof. T. Kudraß, HTWK Leipzig
Oracle XML SQL Utility (XSU)

Prinzip:
–
–
–

Generierung von XML-Dokumenten aus SQL-Abfragen (in
String-Darstellung oder DOM)
Speichern von XML-Dokumenten durch Einfügen von Daten
aus Dokumenten (“generated“ XML)
Aktualisieren und Löschen von Daten aus XML-Dokumenten in
der Datenbank
Schnittstellen:
–
–
–
XSU Java API (Java-Klasse OracleXML)
XSU PL/SQL API (Packages DBMS_XMLQuery und
DBMS_XMLSave)
Kommandozeilen-Interface
java OracleXML [putXML | getXML] optionen
© Prof. T. Kudraß, HTWK Leipzig
Beispiel Generierung von XMLDokumenten mit XSU
CREATE TABLE emp (
EMPNO NUMBER,
ENAME VARCHAR2(20),
JOB VARCHAR2(20),
MGR NUMBER,
HIREDATE DATE,
SAL NUMBER,
DEPTNO NUMBER


);
Ausführen einer SQL-Abfrage
Bsp.: SELECT * FROM emp WHERE EMPNO=7369;
© Prof. T. Kudraß, HTWK Leipzig
Beispiel Generierung von XMLDokumenten mit XSU (SELECT)


Analyse der Metadaten der Ergebnismenge
Konvertierung in folgende Form:
<?xml version='1.0'?>
<ROWSET>
<ROW num="1">
<EMPNO>7369</EMPNO>
<ENAME>Smith</ENAME>
<JOB>CLERK</JOB>
<MGR>7902</MGR>
<HIREDATE>12/17/1980 0:0:0</HIREDATE>
<SAL>800</SAL>
<DEPTNO>20</DEPTNO>
</ROW>
</ROWSET>
© Prof. T. Kudraß, HTWK Leipzig
Einfügen aus XML (INSERT)


Analyse der Metadaten der Zieltabelle
Generierung eines Statements der Form:
INSERT INTO emp
(EMPNO,ENAME,JOB,MGR,HIREDATE,SAL,DEPTNO)
VALUES (?,?,?,?,?,?,?);


Extrahieren der zu den Metadaten passenden
Elemente aus dem XML-Dokument
Ausführen des generierten SQL-Statements
unter Verwendung der extrahierten Daten
© Prof. T. Kudraß, HTWK Leipzig
Aktualisieren mit XML (UPDATE)





Festlegung von Schlüsselattributen, die zur
Identifizierung der zu aktualisierenden
Datensätze dienen
Festlegung der zu aktualisierenden Attribute;
sonst erfolgt Aktualisierung aller Attribute
Analyse der Metadaten der Zieltabelle
Generierung eines Update-Statements
Extrahieren der Daten aus XML-Dokument
© Prof. T. Kudraß, HTWK Leipzig
Aktualisieren mit XML (UPDATE)

Bsp.:
EMPNO ← Schlüsselspalte
SAL ← zu aktualisierende Spalte
<?xml version='1.0'?>
<ROWSET>
<ROW num="1">
<EMPNO>7369</EMPNO>
<JOB>CLERK</JOB>
<SAL>800</SAL>
<DEPTNO>20</DEPTNO>
</ROW>
</ROWSET>
UPDATE emp SET SAL=800 WHERE EMPNO=7369;
© Prof. T. Kudraß, HTWK Leipzig
Löschen mit XML (DELETE)





Festlegung von Schlüsselattributen, die zur
Identifizierung der zu löschenden Datensätze
dienen
Analyse der Metadaten der Zieltabelle
Generierung eines DELETE-Statements
Extrahieren der Daten aus XML-Dokument
Ausführung des generierten SQL-Statements
unter Verwendung der extrahierten Daten
© Prof. T. Kudraß, HTWK Leipzig
Abbildung der XML- Struktur
auf objekt-relationale Datenbanken
XML-Dokument
<hotel url="www.hotel-huebner.de">
<hotelname>Hotel Hübner</hotelname>
<adresse>
<ort>Warnemünde</ort>
<strasse>Seestraße</strasse>
...
</adresse>
<preise>
<einzelzimmer>198</einzelzimmer>
...
</preise>
</hotel>
Hotel:
HotelID Hotelname
H0001
Hotel Hübner
Adresse
Ort
Strasse
Warnemünde
Seestraße
- DTD ist erforderlich (Datentypen)
- Anfragen verwenden SQL - Funktionalität
- Datenbanken mit vielen Nullwerten
Preise
...
einzelzimmer
198
...
© Prof. T. Kudraß, HTWK Leipzig
Objektrelationaler Ansatz
Motivation



Einbeziehung mehrfach geschachtelter XMLDokumente
Schema des Dokuments vorhanden und bekannt
Umgang mit komplexen Objekten
–
–

XML-Dokument = komplexes Objekt
Vermeiden Dekomposition (vgl. relationaler Ansatz)
Objektrelationale Technologie sehr gut geeignet für
Darstellung komplexer Objekte
–
–
Objekt-Sichten (Object Views)
benutzerdefinierte Typen (Object Types)
© Prof. T. Kudraß, HTWK Leipzig
Behandlung von Nested XML Object View Ansatz (1)


Speicherung und Wiedergewinnung von
mehrfach geschachtelten XML-Dokumenten in
Oracle mit Hilfe von Object Types und Object
Views
Schritte
–
–
–
Definiere die passenden Tabellen und Object Types
Baue eine Object View, die mit Dokumentstruktur
übereinstimmt
Nutze Object Views für Insert- und RetrievalOperationen in XSU
© Prof. T. Kudraß, HTWK Leipzig
Behandlung von Nested XML (2)
XML Source Dokument
<?xml version=‚‘1.0‘ encoding=‚‘UTF-8‘?>
<ROWSET>
<ROW><Book>
<ISBN>0449908585</ISBN>
<Title>Fun with XML</Title>
<Price>13</Price>
<Author>
<First>Paul</First>
<Last>Theroux</Last>
</Author>
</Book></ROW>
. . .
</ROWSET>
© Prof. T. Kudraß, HTWK Leipzig
Behandlung von Nested XML (3)
Schema der Ziel-Datenbank:
Object
Types
Tabellen
Person_T
first
last
1
*
Book_T
isbn
title
price
Author_Table
Book_Table
first_name
last_name
isbn
title
price
© Prof. T. Kudraß, HTWK Leipzig
Behandlung von Nested XML (4)
Anlegen einer View auf der Basis von Object Types:
CREATE VIEW book as
SELECT Book_T (b.ISBN,
b.Title,
b.Price,
Person_T(a.First_Name, a.Last_Name)
) as Book
FROM book_table b, author_table a
WHERE b.author_id = a.id;
Object View nutzbar für Retrieval- und Insert-Operationen
XSU kann SQL Cursor Operator nutzen in SQL-Statements, um
beliebig geschachtelte XML-Dokumente zu erzeugen:
SELECT id,first_name,last_name
CURSOR (SELECT isbn,title,price
FROM book_table b
WHERE a.id = b.author_id) as book
FROM author_table a;
© Prof. T. Kudraß, HTWK Leipzig
Behandlung von Nested XML (5)
Ergebnis-Dokument
<?xml version=‚‘1.0‘ encoding=‚‘UTF-8‘?>
<ROWSET>
<ROW num=“1“>
<ID>2000</ID>
<FIRST_NAME>Paul</FIRST_NAME>
<LAST_NAME>Theroux</LAST_NAME>
<BOOK>
<BOOK_ROW num=“1“>
<ISBN>449908585</ISBN>
<TITLE>Fun with XML</TITLE>
<PRICE>13</PRICE>
</BOOK_ROW>
<BOOK_ROW num=“2“>
. . .
</BOOK_ROW>
</BOOK>
</ROW>
. . .
</ROWSET
© Prof. T. Kudraß, HTWK Leipzig
Objektrelationale Speicherung Überblick

benutzerdefinierte Objekte
–
–
–

Transformation DTD  Relationenschema
Transformation DTD  objektrelationales Schema
Vorstellung eines selbstentwickelten Werkzeugs
vordefinierte Objekte
–
–
CLOB-basiert (vgl. dort)
XML Object Type (seit Oracle 9i Release 2)
© Prof. T. Kudraß, HTWK Leipzig
Verarbeitung von DTD and XML
XML Dokument
Überprüfung, ob
wohlgeformt / valid
-----------------------------------------------------------------------------
--------------------------------------------------------------------------------
DTD
Syntax Check
XML V2 Parser
DTD Parser
XML DOM Baum
DTD DOM Baum
Schema Definition
XML2 Oracle
JDBC / ODBC
DBMS Oracle
© Prof. T. Kudraß, HTWK Leipzig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!ELEMENT
<!ELEMENT
<!ATTLIST
<!ELEMENT
<!ELEMENT
<!ENTITY
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
University (StudyCourse,Student*)>
Student (LName,FName,Course*)>
Student StudNr CDATA #REQUIRED>
Course (Name,Professor*,CreditPts?)>
Professor (PName,Subject+,Dept)>
cs “Computer Science“>
LName (#PCDATA)>
FName (#PCDATA)>
Name (#PCDATA)>
CreditPts (#PCDATA)>
PName (#PCDATA)>
Subject (#PCDATA)>
Dept (#PCDATA)>
StudyCourse (#PCDATA)>
© Prof. T. Kudraß, HTWK Leipzig
Transformation von DTD in
Relationenschema [Bourret]

Grundidee:
–
–
Erzeugung von Klassen aus DTD
Abbildung der Klassen auf Tabellen entsprechend Regeln
DTD
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT

A
C
D
B
(B,C)>
(D)>
(#PCDATA)>
(#PCDATA)>
Klassen
CLASS A
STRING
C
CLASS C
STRING
{
b;
c;}
{
d;}
Tabellen
CREATE TABLE A (
a_pk INTEGER NOT NULL,
b
VARCHAR2(30) NOT NULL);
CREATE TABLE C (
c_pk INTEGER NOT NULL,
a_fk INTEGER NOT NULL,
d
VARCHAR2(10) NOT NULL);
Veränderung des Algorithmus von Bourret
–
–
Keine Klassenbildung (Klassen und Tabellen verschmolzen)
Nutzung der Objekte des DTD-Baumes
© Prof. T. Kudraß, HTWK Leipzig
Abbildungsregeln DTD 
Relationenschema [Bourret]
Schritt 1
• Jedes komplexe Element  Tabelle
• Jedes mengenwertige Element  Tabelle
• Primärschlüssel in jeder Tabelle
Schritt 2
Andere Elemente & Attribute  Spalten
1 <!ELEMENT
2 <!ELEMENT
3 <!ATTLIST
4 <!ELEMENT
5 <!ELEMENT
6 <!ENTITY
7 <!ELEMENT
8 <!ELEMENT
9 <!ELEMENT
10 <!ELEMENT
11 <!ELEMENT
12 <!ELEMENT
13 <!ELEMENT
14 <!ELEMENT
Schritt 3
Beziehungen zwischen Elementen  Fremdschlüssel
University (StudyCourse,Student*)>
Student (LName,FName,Course*)>
Student StudNr CDATA #REQUIRED>
Course (Name,Professor*,CreditPts?)>
Professor (PName,Subject+,Dept)>
cs “Computer Science“>
LName (#PCDATA)>
FName (#PCDATA)>
Name (#PCDATA)>
CreditPts (#PCDATA)>
PName (#PCDATA)>
Subject (#PCDATA)>
Dept (#PCDATA)>
StudyCourse (#PCDATA)>
© Prof. T. Kudraß, HTWK Leipzig
Beispiel-Transformation
1 <!ELEMENT
2 <!ELEMENT
3 <!ATTLIST
4 <!ELEMENT
5 <!ELEMENT
6 <!ENTITY
7 <!ELEMENT
8 <!ELEMENT
9 <!ELEMENT
10 <!ELEMENT
11 <!ELEMENT
12 <!ELEMENT
13 <!ELEMENT
14 <!ELEMENT
University (StudyCourse,Student*)>
Student (LName,FName,Course*)>
Student StudNr CDATA #REQUIRED>
Course (Name,Professor*,CreditPts?)>
CREATE TABLE TabUniversity (
Professor (PName,Subject+,Dept)>
cs “Computer Science“>
IDUniversity
INTEGER NOT NULL,
LName (#PCDATA)>
attrStudyCourse VARCHAR(4000) NOT NULL,
FName (#PCDATA)>
PRIMARY KEY (IDUniversity));
Name (#PCDATA)>
CreditPts (#PCDATA)>
CREATE TABLE TabStudent (
PName (#PCDATA)>
IDStudent
INTEGER NOT NULL,
Subject (#PCDATA)>
Dept (#PCDATA)>
IDUniversity
INTEGER NOT NULL,
StudyCourse (#PCDATA)> attrStudNr
VARCHAR(4000) NOT NULL,
attrLName
VARCHAR(4000) NOT NULL,
attrFName
VARCHAR(4000) NOT NULL,
PRIMARY KEY (IDStudent),
CONSTRAINT conStudent FOREIGN KEY (IDUniversity)
REFERENCES TabUniversity (IDUniversity));
...
© Prof. T. Kudraß, HTWK Leipzig
Tool zur objektrelationalen
Speicherung von XML

Grundidee:
–
–
–

Darstellung eines XML-Dokuments durch Kombination von
benutzerdefinierten Typen
Generiere ein objekt-relationales Schema aus der DTD
Generiere Programm zum Laden des Dokuments in Oracle-DB
Abbildungsregeln:
–
–
–
–
–
Attribute und einfache Elemente
Komplexe Elemente
Mengenwertige Elemente
Komplexe mengenwertige Elemente
Constraints
© Prof. T. Kudraß, HTWK Leipzig
XML Attribute & Einfache Elemente

Elemente vom Typ #PCDATA und XML Attribute
 Attribut eines Objekttyps

Wertebereich einfacher Elemente:
–
Keine Typ-Information in der DTD


–

numerisch vs. alphanumerisch?
Länge?
Beschränkungen des DBMS (z.B. VARCHAR 4000 Zeichen)
Abbildung eines XML-Attributes eines einfachen
Elements
 Definition eines Objekttyps für Attribut und Element
© Prof. T. Kudraß, HTWK Leipzig
XML Attribute & Einfache Elemente
<!ELEMENT
<!ATTLIST
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Professor (PName,Subject,Dept)>
Professor PAddress CDATA #REQUIRED>
PName
(#PCDATA)>
Subject
(#PCDATA)>
Dept
(#PCDATA)>
Dept DAddress CDATA #REQUIRED>
CREATE TABLE TabProfessor
OF Type_Professor;
CREATE TYPE Type_Professor AS OBJECT (
attr PAddress
VARCHAR(4000),
attrPName
VARCHAR(4000),
attrSubject
VARCHAR(4000),
attrDept
Type_Dept);
CREATE TYPE Type_Dept AS OBJECT (
attrDept
VARCHAR(4000),
attrDAddress
VARCHAR(4000));
© Prof. T. Kudraß, HTWK Leipzig
Komplexe Elemente
CREATE TABLE TabUniversity (
attrStudyCourse VARCHAR(4000),
attrStudent Type_Student );
CREATE TYPE Type_Student AS OBJECT (
attrStudNr VARCHAR(4000),
attrLName VARCHAR(4000),
attrFName VARCHAR(4000),
attrCourse Type_Course );
CREATE TYPE Type_Course AS OBJECT (
attrName VARCHAR(4000),
attrProfessorType_Professor,
attrCreditPts VARCHAR(4000));
CREATE TYPE Type_Professor AS OBJECT (
attrPName VARCHAR(4000),
attrSubject VARCHAR(4000),
attrDept
VARCHAR(4000));
Verschachtelung durch zusammengesetzte Object Types
INSERT INTO TabUniversity
VALUES ( ‘Computer Science' ,
Type_Student('23374','Conrad','Matthias',
Type_Course(‘Databases II‘,
Type_Professor(‘Kudrass‘ ,
‘Database Systems‘',
‘Computer Science‘), '4')));
SELECT u.attrStudent.attrLname
FROM TabUniversity u
WHERE u.attrStudent.attrCourse.attrProfessor.attrPName
= ‘Kudrass';
© Prof. T. Kudraß, HTWK Leipzig
Mengenwertige Elemente


Mehrfaches Auftreten eines Elements (DTD): + oder *
Beschränkungen des DBMS (Oracle 8i)
–
–
Kollektionstypen nur anwendbar auf textwertige Subelemente,
z.B. ARRAY OF VARCHAR
Was ist mit komplexen Subelementen?


Subelemente können wiederum mengenwertig sein
Lösung
–
–
Oracle ab Release 9i verwenden
Beziehungen über Objektreferenzen realisieren (aufwendig!)
© Prof. T. Kudraß, HTWK Leipzig
Mengenwertige Elemente
CREATE TYPE TypeVA_Student AS VARRAY(100) OF Type_Student;
CREATE TYPE TypeVA_Course AS VARRAY(100) OF Type_Course;
CREATE TYPE TypeVA_Professor AS VARRAY(100) OF Type_Professor;
CREATE TYPE TypeVA_Subject AS VARRAY(100) OF VARCHAR(4000);
CREATE TABLE TabUniversity (
attrStudyCourse VARCHAR(4000),
attrStudent TypeVA_Student );
CREATE TYPE Type_Student AS OBJECT (
attrStudNr VARCHAR(4000),
attrLName VARCHAR(4000),
attrFName VARCHAR(4000),
attrCourse TypeVA_Course );
CREATE TYPE Type_Course AS OBJECT (
attrName VARCHAR(4000),
attrProfessor TypeVA_Professor,
attrCreditPts VARCHAR(4000));
CREATE TYPE Type_Professor AS OBJECT (
attrPName VARCHAR(4000),
attrSubject TypeVA_Subject,
attrDept
VARCHAR(4000));
University
Student
Course
Professor
Subject
© Prof. T. Kudraß, HTWK Leipzig
Einfügen der Dokument-Daten
(Beispiel)
INSERT INTO TabUniversity VALUES ( ‘Computer Science' ,
TypeVA_Student (
Type_Student('23374','Conrad','Matthias',
TypeVA_Course (
Type_Course(‘Databases II‘,
TypeVA_Professor (
Type_Professor(‘Kudrass‘ ,
TypeVA_Subject (
‘Database Systems,‘Operating Systems‘),
‘Computer Science‘)),‘4‘),
Type_Course(‘CAD Intro‘,
TypeVA_Professor (
Type_Professor(‘Jaeger‘ ,
TypeVA_Subject (
‘CAD‘,‘CAE‘),
‘Computer Science‘)),‘4‘),
...)),
Type_Student(‘00011',‘Meier',‘Ralf', … ) … )
...);
© Prof. T. Kudraß, HTWK Leipzig
Oracle 9i Release 2
Objektrelationale Speicherung (1)

XMLType
–
–




Unterstützung von XML Schema
XPATH kann als Ausdruck in DML Statements genutzt
werden
Kombination von SQL Anfragen mit XPATH möglich
Neue XML Operatoren
–
–

2 Speicherungs-Optionen: CLOB vs. objektrelational
Informationserhaltung entsprechend DOM
XMLTABLE (Umwandlung einer Knotenliste in Tabelle)
XMLELEMENT (Erzeugen von XML-Elementen on-the-fly)
XSL Transformationen für XMLType
© Prof. T. Kudraß, HTWK Leipzig
Oracle 9i Release 2
Objektrelationale Speicherung (2)

Performance-Verbesserungen
–
–
–

Foldering
–




Lazy XML Load
Schema Caching
hierarchischer Index
Abbildung von Verzeichnisstrukturen in DB-Strukturen
Access Control auf der Ebene von XML-Objekten
WebDAV und FTP Zugriff
Suche in Metadaten, Strukturen und Inhalten mittels
SQL
Neue APIs
–
–
Java Bean Interface
Servlet API zum Zugriff auf XML-Daten
© Prof. T. Kudraß, HTWK Leipzig
Oracle 9i Release 2
Beispiele
SELECT xml_order FROM orders
WHERE EXISTSNODE (xml_order,‘//ship_to/state‘) > 0;
SELECT xml_order FROM orders
WHERE EXTRACTNODE(xml_order,
‘//ship_to/state‘).getClobVal() = ‘CA‘;
Speicherungsmodus in Anfrage nicht sichtbar
Somit auch erlaubt:
SELECT xml_order FROM orders
WHERE EXTRACTNODE(xml_order,
‘//ship_to/state‘) = ‘CA‘;
© Prof. T. Kudraß, HTWK Leipzig
Strukturierte Speicherung
Bewertung

Dokumentstruktur ist starr (durch relationales Schema
gegeben)
–

Beschränkungen in der Abbildung
–
–

Rekursion
mixed content
Informationsverlust (Round-Trip-Problem)
–
–
–

somit keine beliebigen (nicht vordefinierten) XML-Dokumente
speicherbar
Kommentare, Processing Instructions
Reihenfolge der Elemente
Element vs. Attribute (wie war es im Original?)
Anfragesprache ist immer SQL (erfordert Übersetzung)
–
strukturorientierte Anfragen schwierig
© Prof. T. Kudraß, HTWK Leipzig
Fazit

Vielzahl von Speicherungsmethoden verfügbar
–
–

Unterschiedliche Anforderungen (je nach Dokumenttyp)
–
–
–



jeweils Vor- und Nachteile
Mischformen innerhalb einzelner Dokumente denkbar
Skalierbarkeit
Performance
Anfragemöglichkeiten
Semantik (Information aus Dokumenten bewahren!)
Auswahl der günstigsten Methode?
Werkzeugunterstützung für XML-Datenbankentwurf?
© Prof. T. Kudraß, HTWK Leipzig
Quellen


Steve Muench: Building Oracle XML Applications,
O‘Reilly, 2000.
Oracle Technology Network:
http://www.oracle.com/xml



Harald Schöning: XML und Datenbanken, BTWTutorium, März 2001.
Meike Klettke: XML-Speicherungsmethoden, eine
Klassifikation, http://www.xml-und-datenbanken.de
Ron Bourret: XML and Databases,
http://www.rpbourret.com/xml/
XMLAndDatabases.htm