Speicherung von XML-Dokumenten in Oracle
Prof. Dr. Thomas Kudraß
HTWK Leipzig
SIG Development (Tools),Oracle & XMLKassel, 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– Ausgabe des gespeicherten Dokuments in unveränderter Form
Der ganze Inhalt– 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
generisch definitorisch
– strukturorientiert zerlegt– opaque Ansatz (Large Objects)
Objektorientiert (Objektrelational)– 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 String-
Darstellung 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 XML- Dokumenten 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 XML- Dokumenten 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üsselspalteSAL ← 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 ZerlegungBewertung
Dokumentstruktur ist starr (durch relationales Schema gegeben)
– somit keine beliebigen (nicht vordefinierten) XML-Dokumente speicherbar
Beschränkungen in der Abbildung– Rekursion– mixed content
Informationsverlust (Round-Trip-Problem)– 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
feststehendes Datenbankschema benötigt nur eine relationale Datenbank
– Zerlegung eines XML-Dokumentes in kleine Einheiten (Elemente) und Speichern in der Datenbank
1 XML-Dokument n Datensätze – 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 <tree> <person age=’55‘> <name>Peter</name> </person> <person age=’38‘> <name>Mary</name> <address>Fruitdale Ave. </address> </person></tree>
tre e
p e rson p e rso n
nam
e
nam
e a d ress
3 4
Pe te rM a ry 4711
Fruitd a le Ave .
1
2
[a g e = 55] [a g e = 38]
© Prof. T. Kudraß, HTWK Leipzig
Datenmodell
tblDocs
DocId url
tblEdgeSourceId TargetId LeafId AttrId DocId EdgeName Type Depth
tblLeafs
LeafId Value
tblAttrs
AttrId Value
1
n
1
0/1 0/1
1
© Prof. T. Kudraß, HTWK Leipzig
Import-Algorithmus
<baum>
<person alter=“36“>
<name>Peter</name>
<adresse>
<strasse>Hauptstrasse 4</strasse>
<PLZ>04236</PLZ>
<Ort>Leipzig</Ort>
</adresse>
</person>
</baum>
Source
Id
TargetId
LeafId
AttrId
DocId
EdgeName Type Depth
0 1 -1 -1 1 baum ref 3
1 2 -1 -1 1 person ref 22 3 -1 1 1 alter attr 02 4 1 -1 1 name leaf 0
2 5 -1 -1 1 adresse ref 15 6 2 -1 1 strasse leaf 05 7 3 -1 1 PLZ leaf 0
5 8 4 -1 1 Ort leaf 0
DocId url1 Beispiel.xml
LeafId Value1 Peter2 Hauptstr
asse 4
3 04236
4 Leipzig
AttrId Value1 36
© Prof. T. Kudraß, HTWK Leipzig
Anfragemethode
Mit welcher Anfragesprache?– XML-Anfragesprache
auf XML-Dokumente sinnvoll
– Datenmodell ausgehend von XML-QL erstellt
XML-QLAnfrage Parser
Generierung desSQL Statement
Objekt-Struktur
SQLStatement
Row Set
Ausführung desSQL Statement
Konstruktion desErgebnisdokuments
XMLDokument
DB
Datenbank versteht nur SQL– Transformation von XML-QL
nach SQL notwendig– Erzeugen eines Ergebnis-
Dokumentes aus Tupeln
© Prof. T. Kudraß, HTWK Leipzig
Erzeugen eines SQL-Statements XML-QL Anfrage
CONSTRUCT <result> { WHERE <person> <name>$n</name>
<adresse>$a</adresse> </person>
CONSTRUCT <person>
<name>$n</name> <adresse>$a</adresse> </person>
} </result>
SQL-Statement
SELECT DISTINCT B.Type AS n_Type, B.TargetId AS n_TargetId, B.Depth AS n_Depth, C.Value AS n_Value, D.Type AS a_Type, D.TargetId AS a_TargetId, D.Depth AS a_Depth, E.Value AS a_ValueFROM tblEdge A,tblEdge B,tblLeafs C, tblEdge D,tblLeafs EWHERE (A.EdgeName = ‘person’) AND (A.TargetId = B.SourceId) AND (B.EdgeName = ‘name’) AND (B.LeafId = C.LeafId(+)) AND (A.TargetId = D.SourceId) AND (D.EdgeName = ‘adresse’) AND (D.LeafId = E.LeafId(+))
© Prof. T. Kudraß, HTWK Leipzig
Konstruktion des Ergebnis-Dokumentes
Ergebnistupel
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_Type n_TargetId
n_Depth n_Value a_Type a_TargetId
a_Depth a_Value
leaf 4 0 Peter ref 5 1
EdgeName Type A_LeafVal A_AttrVal
strasse leaf Hauptstrasse 4
PLZ leaf 04236Ort leaf Leipzig
• Teilbaum-Rekonstruktion
© 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– benutzt keine spezifischen DBMS-Eigenschaften
Stabilität Hohe Flexibilität der Anfragen
– 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
Insert into tblXMLClob values (1,‘person.xml‘,‘ <person> <name>Mary</name></person>‘ );
DocId url content
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
Ausführen der XPath Anfrage auf dem DOM-Baum für jedes
CLOB Objekt der Doc IDs
Doc IDs mit Ergebnis XML- Dokument
serverseitig
DB
Doc IDs
© Prof. T. Kudraß, HTWK Leipzig
Vergleich der Anfragemöglichkeiten
liefert Dokument-IDs Wordsuche (Default) kein Existenztest für Elemente oder
Attribute Pfadausdrücken beschränkt möglich
durch WITHINe.g.: (xml WITHIN title) WITHIN book
erlaubt begrenzt Attribut-wertsuche, keine Verschach-telung 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 struktur-
orientierte Anfragen //Book/Title/[contains(..‘xml‘)]
Suche nach Attributwerten und Element-Text kann kom-biniert werden
berücksichtigt auch Dezimal-werte Bereichsanfragen möglich mittels
Filter
interMedia Text XPath
© Prof. T. Kudraß, HTWK Leipzig
CLOB AnsatzVorteile
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 XPath-
Funktionalität– generiere ein DOM des Dokuments vor Anwendung
von XPath-Queries
© Prof. T. Kudraß, HTWK Leipzig
CLOB AnsatzNachteile
Beschränkte Ausdrucksfähigkeit von Text-Anfragen Performance vs. Genauigkeit der Anfrage-Ergebnisse
– interMedia Text Queries auf CLOBs schneller als DOM-API– Beispiel-Dokument: 12.5 MB, Übersetzungszeit 3 Min., Ladezeit 5 Min.
Restriktionen der Indexe– Maximale Länge der Tag-Namen fürs Indexieren (inkl. Namespace): 64
Bytes Probleme mit Markup
– 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 AnsatzMotivation
Einbeziehung mehrfach geschachtelter XML-Dokumente
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 V2 Parser DTD Parser
XML Dokument DTD
Schema Definition
Überprüfung, ob wohlgeformt / valid
XML2 Oracle
XML DOM Baum DTD DOM Baum
--------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
DBMS Oracle
JDBC / ODBC
Syntax Check
© Prof. T. Kudraß, HTWK Leipzig1 <!ELEMENT University (StudyCourse,Student*)>2 <!ELEMENT Student (LName,FName,Course*)>3 <!ATTLIST Student StudNr CDATA #REQUIRED>4 <!ELEMENT Course (Name,Professor*,CreditPts?)>5 <!ELEMENT Professor (PName,Subject+,Dept)>6 <!ENTITY cs “Computer Science“>7 <!ELEMENT LName (#PCDATA)>8 <!ELEMENT FName (#PCDATA)>9 <!ELEMENT Name (#PCDATA)>10 <!ELEMENT CreditPts (#PCDATA)>11 <!ELEMENT PName (#PCDATA)>12 <!ELEMENT Subject (#PCDATA)>13 <!ELEMENT Dept (#PCDATA)>14 <!ELEMENT StudyCourse (#PCDATA)>
© Prof. T. Kudraß, HTWK Leipzig
Transformation von DTD in Relationenschema [Bourret]
DTD Klassen Tabellen <!ELEMENT A (B,C)> CLASS A { CREATE TABLE A (<!ELEMENT C (D)> STRING b; a_pk INTEGER NOT NULL,<!ELEMENT D (#PCDATA)> C c;} b VARCHAR2(30) NOT NULL);<!ELEMENT B (#PCDATA)> CLASS C { CREATE TABLE C (
STRING d;} c_pk INTEGER NOT NULL, a_fk INTEGER NOT NULL,
d VARCHAR2(10) NOT NULL);
Grundidee:– Erzeugung von Klassen aus DTD – Abbildung der Klassen auf Tabellen entsprechend Regeln
Veränderung des Algorithmus von Bourret– Keine Klassenbildung (Klassen und Tabellen verschmolzen)– Nutzung der Objekte des DTD-Baumes
© Prof. T. Kudraß, HTWK Leipzig
• Jedes komplexe Element Tabelle
• Jedes mengenwertige Element Tabelle
• Primärschlüssel in jeder Tabelle
1 <!ELEMENT University (StudyCourse,Student*)>2 <!ELEMENT Student (LName,FName,Course*)>3 <!ATTLIST Student StudNr CDATA #REQUIRED>4 <!ELEMENT Course (Name,Professor*,CreditPts?)>5 <!ELEMENT Professor (PName,Subject+,Dept)>6 <!ENTITY cs “Computer Science“>7 <!ELEMENT LName (#PCDATA)>8 <!ELEMENT FName (#PCDATA)>9 <!ELEMENT Name (#PCDATA)>10 <!ELEMENT CreditPts (#PCDATA)>11 <!ELEMENT PName (#PCDATA)>12 <!ELEMENT Subject (#PCDATA)>13 <!ELEMENT Dept (#PCDATA)>14 <!ELEMENT StudyCourse (#PCDATA)>
Schritt 1
Andere Elemente & Attribute Spalten
Schritt 2
Abbildungsregeln DTD Relationenschema [Bourret]
Beziehungen zwischen Elementen Fremdschlüssel
Schritt 3
© Prof. T. Kudraß, HTWK Leipzig
1 <!ELEMENT University (StudyCourse,Student*)>2 <!ELEMENT Student (LName,FName,Course*)>3 <!ATTLIST Student StudNr CDATA #REQUIRED>4 <!ELEMENT Course (Name,Professor*,CreditPts?)>5 <!ELEMENT Professor (PName,Subject+,Dept)>6 <!ENTITY cs “Computer Science“>7 <!ELEMENT LName (#PCDATA)>8 <!ELEMENT FName (#PCDATA)>9 <!ELEMENT Name (#PCDATA)>10 <!ELEMENT CreditPts (#PCDATA)>11 <!ELEMENT PName (#PCDATA)>12 <!ELEMENT Subject (#PCDATA)>13 <!ELEMENT Dept (#PCDATA)>14 <!ELEMENT StudyCourse (#PCDATA)>
CREATE TABLE TabUniversity (IDUniversity INTEGER NOT NULL,attrStudyCourse VARCHAR(4000) NOT NULL,PRIMARY KEY (IDUniversity));
CREATE TABLE TabStudent (
IDStudent INTEGER NOT NULL,IDUniversity INTEGER NOT NULL,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));
...
Beispiel-Transformation
© 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
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));
<!ELEMENT Professor (PName,Subject,Dept)><!ATTLIST Professor PAddress CDATA #REQUIRED> <!ELEMENT PName (#PCDATA)><!ELEMENT Subject (#PCDATA)><!ELEMENT Dept (#PCDATA)><!ATTLIST Dept DAddress CDATA #REQUIRED>
XML Attribute & Einfache Elemente
© 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),attrProfessor Type_Professor,attrCreditPts VARCHAR(4000));
CREATE TYPE Type_Professor AS OBJECT (
attrPName VARCHAR(4000),attrSubject VARCHAR(4000),attrDept VARCHAR(4000));
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 uWHERE u.attrStudent.attrCourse.attrProfessor.attrPName
= ‘Kudrass';
Verschachtelung durch zusammen-gesetzte Object Types
© 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 ElementeCREATE 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)
<!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)
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
© 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 pWHERE 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
...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,CURSOR (SELECT s.attrSubject
FROM tabSubject s WHERE p.IDProfessor = s.IDProfessor) AS Subject
FROM tabProfessor;
Beispiel:Ausgabe eines Professorsund seiner Fachgebiete
Verarbeitung durch Oracle XSU
© 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– jeweils Vor- und Nachteile
Unterschiedliche Anforderungen (je nach Dokument-typ)
– 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 objekt-relationalen Systemen am Beispiel Oracle, Diplomarbeit, HTWK Leipzig, 2001.