DOAG02

Speicherung von XMLDokumenten in Oracle
Prof. Dr. Thomas Kudraß
HTWK Leipzig
SIG Development (Tools),
Oracle & XML
Kassel, 04.06.2002
© Prof. T. Kudraß, HTWK Leipzig
Daten oder Dokumente [Bourret]

Dokumentenzentrische Dokumente (document-centric)
–
–
–
–
–
für Menschen lesbare Dokumente
Reihenfolge wichtig
sinntragende Daten auf allen Ebenen, auch mixed content
zumeist Volltextsuche bzw. Retrieval-Operationen
Beispiele:





–
Zeitschriftenartikel, Bücher
Gebrauchsanweisungen, Handbücher
e-Mail, News-Artikel und Forumsbeiträge
Präsentationen
Verträge
Anteil: 70% der Informationen in Textdokumenten (Schätzwert)
© Prof. T. Kudraß, HTWK Leipzig
Daten oder Dokumente (Forts.)

Datenzentrische Dokumente (data-centric)
–
–
–
–
–
–
–
Daten im herkömmlichen Sinne
Reihenfolge oft nicht wichtig
einheitliche und einfache Struktur
Daten haben Datentypen
sinntragende Elemente in Blattelementen oder Attributen
mixed content nicht üblich
Beispiele:




Telefonbücher
wissenschaftliche Daten (Meßreihen)
Fahrpläne, Flugpläne
Bestellungen
© Prof. T. Kudraß, HTWK Leipzig
Daten und Dokumente


XML für beide Dokumenttypen geeignet
XML erlaubt Mischformen, z.B.
–
–
Produktkataloge
Krankenakten




Daten: Geburtsdatum, Adresse, etc.
binäre Daten: Röntgenbilder
Textdokumente: Diagnose, Krankengeschichte
Binäre Daten in XML
–
–
external entities
CDATA sections
© Prof. T. Kudraß, HTWK Leipzig
Warum XML in Datenbanken?

XML als SGML-Nachfolger
–

Speicherung von Dokumenten
XML als Austauschformat
–
Transformation der Originaldaten nach XML


Speicherung der Austauschdaten ebenfalls erforderlich (z.B. beim
Empfänger)
Nutzung der Funktionalität eines DBMS
–
–
–
mächtige und effiziente Suchfunktionen
transaktionsorientierte Speicherung
Mehrbenutzerbetrieb
© 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
XML in Datenbanken - Optionen zur
Realisierung

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
© Prof. T. Kudraß, HTWK Leipzig
Inhaltsorientierte Zerlegung
Überblick


generisch vs. definitorisch
Beispiel (generisch):
–
Oracle XML SQL Utility (XSU):





Queries
Insert
Update
Delete
Bewertung
© Prof. T. Kudraß, HTWK Leipzig
Inhaltsorientierte Zerlegung

außerhalb der Datenbank
–



Oracle XML SQL Utility for Java
macht vorhandene Datenbanken im XML-Format
zugänglich
2 Ansätze: 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
© Prof. T. Kudraß, HTWK Leipzig
XML SQL Utility (XSU)




Beispiel für inhaltsorientierte Zerlegung (generisch)
Generierung von XML aus Daten einer Oracle
Datenbank
Generierung von XML-Dokumenten in ihrer StringDarstellung bzw. als DOM-Modell aus SQL-Abfragen
heraus
Extrahieren von Daten aus XML-Dokumenten und
Verwendung dieser für:
–
–
–
Einfügeoperationen (INSERT)
Änderungsoperationen (UPDATE)
Löschoperationen (DELETE)
© 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
Inhaltsorientierte Zerlegung definitorisch (Shredding)



Definition einer Abbildungsvorschrift zwischen
XML-Dokument und Datenbanktabellen
Elemente und Attribute können auf
Zeilen/Spalten verschiedener Tabellen
abgebildet werden
Oracle-Ansatz:
–
Internet File System (iFS): Parsen und Speichern
von XML-Dokumenten in relationaler DB
© Prof. T. Kudraß, HTWK Leipzig
Inhaltsorientierte Zerlegung
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)
© Prof. T. Kudraß, HTWK Leipzig
Strukturorientierte Zerlegung
Überblick


Prinzip
Vorstellung eines selbstentwickelten
Werkzeugs auf Basis Oracle 8i
–
–
–

Datenmodell
Algorithmus
Verarbeitung von Anfragen
Bewertung
–
Vor- und Nachteile
© Prof. T. Kudraß, HTWK Leipzig
Relationale Strukturorientierte
Zerlegung

Prinzip
–
Speicherung in generischen Tabellen


–

Zerlegung eines XML-Dokumentes in kleine Einheiten
(Elemente) und Speichern in der Datenbank
1 XML-Dokument  n Datensätze
–

feststehendes Datenbankschema
benötigt nur eine relationale Datenbank
Informationsverlust möglich (Kommentare, mixed content)
Vorteil: Keine Schemadefinition durch Benutzer
notwendig
–
–
hohe Flexibilität bei dynamisch erzeugten XML-Dokumenten
verwendete relationale Strukturen für Benutzer unbrauchbar
(keine Anwendungssemantik)
© Prof. T. Kudraß, HTWK Leipzig
Relationale Strukturorientierte
Zerlegung (Forts.)
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)
Universalverfahren
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
[age= 55]
</person>
</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>
LeafId
Value
<person alter=“36“>
1
Peter
<name>Peter</name>
2
Hauptstr
<adresse>
asse 4
<strasse>Hauptstrasse 4</strasse>
3
04236
4
Leipzig
<PLZ>04236</PLZ>
<Ort>Leipzig</Ort>
Source Target Leaf Attr Doc EdgeName Type Depth
</adresse>
Id
Id
Id
Id
Id
</person>
0
1
-1
-1
1
baum
ref
3
</baum>
1
2
-1
-1
1
person ref
2
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
1
-1
-1
-1
-1
-1
1
1
1
1
1
1
alter
name
adresse
strasse
PLZ
Ort
attr
leaf
ref
leaf
leaf
leaf
0
0
1
0
0
0
© Prof. T. Kudraß, HTWK Leipzig
Anfragemethode
XML-QL
Anfrage

Parser
ObjektStruktur
Generierung des
SQL Statement
Mit welcher Anfragesprache?
– XML-Anfragesprache
auf XML-Dokumente
sinnvoll
– Datenmodell ausgehend
von XML-QL erstellt
Konstruktion des
Ergebnisdokuments
DB
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
n_Value
Peter
a_Type a_Target a_Depth a_Value
Id
ref
5
1
SELECT
Teilbaum-Rekonstruktion
A.EdgeName,
A.Type,
EdgeName
Al.Value AS A_LeafVal,
Aa.Value AS A_AttrVal
strasse
FROM
tblEdge A,
PLZ
tblLeafs Al,
Ort
tblAttrs Aa
WHERE
A.SourceId=5 AND
A.leafId=Al.leafId(+) AND
A.attrId=Aa.attrId(+)
•
Type
A_LeafVal
leaf
Hauptstrasse
4
04236
Leipzig
leaf
leaf
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
–


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
Opaque Ansatz (CLOB Ansatz)




Prinzip
Oracle interMedia Text
XPath-Anfragen (XML Developer Kit)
Anfragemöglichkeiten:
–


interMediaText vs. XPath
Prototyp
Bewertung
© Prof. T. Kudraß, HTWK Leipzig
Opaque Ansatz (CLOB 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
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
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
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



XPath





erlaubt begrenzt Attributwertsuche, keine Verschachtelung von Attributsuchen
numerische und Datumswerte
werde nicht konvertiert
keine Bereichsanfragen auf
Attributwerten
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
Prototyp: User Interface
© Prof. T. Kudraß, HTWK Leipzig
Objektrelationaler Ansatz
Überblick

benutzerdefinierte Objekte
–
–
–
Transformation DTD  Relationenschema
Transformation DTD  objektrelationales Schema
Vorstellung eines selbstentwickelten Werkzeugs

–

Bewertung
Alternative: Oracle Object Views
vordefinierte Objekte (basierend auf CLOBs)
–
Ausblick auf Oracle 9i
© 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
–
–
benutzerdefinierte Typen (Object Types)
Objekt-Sichten (Object Views)
© 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
© 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
Probleme mit CHECK Constraints
(Beispiel)

Restriktionen bei NOT NULL
–
–

Definiere NOT NULL in Tabelle - nicht im Objekttyp!
NOT NULL nicht anwendbar auf Kollektionstypen
Objektwertige Attribute:
–
NOT NULL durch CHECK-Constraint ausdrücken
<!ELEMENT Course (Name, Address?)>
<!ELEMENT Address (Street, City?)>
CREATE TYPE Type_Address AS OBJECT (
attrStreet VARCHAR(4000),
attrCity
VARCHAR(4000));
CREATE TYPE Type_Course AS OBJECT (
attrName VARCHAR(4000),
attrAddress Type_Address);
CREATE TABLE TabCourse OF Type_Course (
attrName NOT NULL,
CHECK (attrAdress.attrStreet
IS NOT NULL));
// ORA-02290: Erwünschter Fehler
1.
INSERT INTO TabCourse (
VALUES (‘CAD Intro’,Type_Address
(NULL,’Leipzig’);
// ORA-02290: Unerwünschter Fehler
2.
INSERT INTO TabCourse (
VALUES ('RN', NULL)
© Prof. T. Kudraß, HTWK Leipzig
Objektrelationale Alternative:
Object Views



strukturierte logische Views auf Tabellen, die
strukturierte Datensätze liefern
setzt relationales Schema voraus
nutzbar für Retrieval und Insert
CREATE VIEW OView_University AS
SELECT Type_University (u.attrStudyCourse,
Type_Student (s.attrStudNr, s.attrLName, s.attrFName,
Type_Course (c.attrName,
Type_Professor (p.attrPName,p.attrSubject,p.attrDept))))
AS University
FROM tabUniversity u, tabStudent s, tabCourse c, tabProfessor p
WHERE s.IDStudNr = c.IDStudNr AND c.IDCourse = p.IDCourse;
© Prof. T. Kudraß, HTWK Leipzig
Zugriff auf Object Views

Transformation eines mengenwertigen Elements, das
als separate Tabelle gespeichert ist, beim Retrieval
Beispiel:
Ausgabe eines Professors
und seiner Fachgebiete
...Type_Professor (p.attrPName,
CAST (MULTISET (SELECT s.attrSubject
FROM tabSubject s
WHERE p.IDProfessor = s.IDProfessor)
AS TypeVA_Subject),
p.attrDept), ...
SELECT p.attrPName,
Verarbeitung durch Oracle XSU
CURSOR (SELECT s.attrSubject
FROM tabSubject s
WHERE p.IDProfessor = s.IDProfessor) AS Subject
FROM tabProfessor;
© Prof. T. Kudraß, HTWK Leipzig
Oracle 9i
Objektrelationaler Ausblick

Weiterentwicklung des CLOB-Ansatzes
–
spezieller Datentyp XMLType mit vordefinierten Funktionen




createXML()
extract()
existsNode()
Ausgabe von Anfrageergebnissen im XML-Format
–
Funktionen innerhalb von SQL-Anfragen


SYS_XMLGEN()
SYS_XMLAGG()
© Prof. T. Kudraß, HTWK Leipzig
Fazit

Vielzahl von Speicherungsmethoden verfügbar
–

Unterschiedliche Anforderungen (je nach Dokumenttyp)
–
–
–



jeweils Vor- und Nachteile
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.
Ron Bourret: XML and Databases,
http://www.rpbourret.com/xml/XMLAndDatabases.htm


Tobias Krumbein: Speicher- und Anfragemethoden für
XML-Dokumente ohne Schema in objektrelationalen
Systemen am Beispiel Oracle, Diplomarbeit, HTWK
Leipzig, 2001.
Matthias Conrad: Speicherungsmöglichkeiten von
XML-Dokumenten mit bekanntem Schema in objektrelationalen Systemen am Beispiel Oracle,
Diplomarbeit, HTWK Leipzig, 2001.