Speicherung von XML-Dokumenten in Oracle Prof. Dr. Thomas Kudraß HTWK Leipzig SIG Development (Tools), Oracle & XML Kassel, 04.06.2002

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)

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

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

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

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

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

Inhaltsorientierte Zerlegung Überblick generisch vs. definitorisch Beispiel (generisch): Oracle XML SQL Utility (XSU): Queries Insert Update Delete Bewertung

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

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)

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;

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>

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

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

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;

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

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

Inhaltsorientierte Zerlegung Bewertung 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)

Strukturorientierte Zerlegung Überblick Prinzip Vorstellung eines selbstentwickelten Werkzeugs auf Basis Oracle 8i Datenmodell Algorithmus Verarbeitung von Anfragen Bewertung Vor- und Nachteile

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)

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

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>

Datenmodell tblDocs tblEdge tblLeafs tblAttrs DocId url SourceId 1 n tblEdge SourceId TargetId LeafId AttrId DocId EdgeName Type Depth 1 1 0/1 0/1 tblLeafs LeafId Value tblAttrs AttrId Value

Import-Algorithmus <baum> <person alter=“36“> <name>Peter</name> <adresse> <strasse>Hauptstrasse 4</strasse> <PLZ>04236</PLZ> <Ort>Leipzig</Ort> </adresse> </person> </baum> LeafId Value 1 Peter 2 Hauptstrasse 4 3 04236 4 Leipzig Source Id TargetId LeafId AttrId DocId EdgeName Type Depth 1 -1 baum ref 3 2 person alter attr 4 name leaf 5 adresse 6 strasse 7 PLZ 8 Ort DocId url 1 Beispiel.xml AttrId Value 1 36

Anfragemethode DB XML-QL Anfrage Parser Objekt- Struktur Generierung des SQL Statement SQL Statement Mit welcher Anfragesprache? XML-Anfragesprache auf XML-Dokumente sinnvoll Datenmodell ausgehend von XML-QL erstellt DB Ausführung des SQL Statement Konstruktion des Ergebnisdokuments Row Set Datenbank versteht nur SQL Transformation von XML-QL nach SQL notwendig Erzeugen eines Ergebnis-Dokumentes aus Tupeln XML Dokument

Erzeugen eines SQL-Statements XML-QL Anfrage CONSTRUCT <result> { WHERE <person> <name>$n</name> <adresse>$a</adresse> </person> CONSTRUCT } </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_Value FROM tblEdge A,tblEdge B,tblLeafs C, tblEdge D,tblLeafs E WHERE (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(+))

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 Peter ref 5 1 Teilbaum-Rekonstruktion EdgeName Type A_LeafVal A_AttrVal strasse leaf Hauptstrasse 4 PLZ 04236 Ort Leipzig

Anfrageergebnis XML-Ergebnis-Dokument <result> <person> <name>Peter</name> <adresse> <strasse>Hauptstrasse 4</strasse> <PLZ>04236</PLZ> <Ort>Leipzig</Ort> </adresse> </person>   </result>

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

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

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)

Opaque Ansatz (CLOB Ansatz) Prinzip Oracle interMedia Text XPath-Anfragen (XML Developer Kit) Anfragemöglichkeiten: interMediaText vs. XPath Prototyp Bewertung

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>

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

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 Doc IDs serverseitig DB Ausführen der XPath Anfrage auf dem DOM-Baum für jedes CLOB Objekt der Doc IDs Doc IDs mit Ergebnis XML- Dokument

Vergleich der Anfragemöglichkeiten interMedia Text XPath 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 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 

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 XPath- Funktionalität generiere ein DOM des Dokuments vor Anwendung von XPath-Queries

CLOB Ansatz Nachteile 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

Prototyp: User Interface

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

Objektrelationaler Ansatz Motivation 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)

Verarbeitung von DTD and XML -------------------------------------------------------------------------------- ----------------------------------------------------------------------------------- XML Dokument DTD Überprüfung, ob wohlgeformt / valid Syntax Check XML V2 Parser DTD Parser XML DOM Baum DTD DOM Baum Schema Definition XML2 Oracle JDBC / ODBC DBMS Oracle

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)>

Transformation von DTD in Relationenschema [Bourret] Grundidee: Erzeugung von Klassen aus DTD Abbildung der Klassen auf Tabellen entsprechend Regeln 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); Veränderung des Algorithmus von Bourret Keine Klassenbildung (Klassen und Tabellen verschmolzen) Nutzung der Objekte des DTD-Baumes

Abbildungsregeln DTD  Relationenschema [Bourret] Schritt 1 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)> Jedes komplexe Element  Tabelle Jedes mengenwertige Element  Tabelle Primärschlüssel in jeder Tabelle Schritt 2 Andere Elemente & Attribute  Spalten Schritt 3 Beziehungen zwischen Elementen  Fremdschlüssel

Beispiel-Transformation 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));  ...

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

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

XML Attribute & Einfache Elemente <!ELEMENT Professor (PName,Subject,Dept)> <!ATTLIST Professor PAddress CDATA #REQUIRED> <!ELEMENT PName (#PCDATA)> <!ELEMENT Subject (#PCDATA)> <!ELEMENT Dept (#PCDATA)> <!ATTLIST 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)); 

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)); Verschachtelung durch zusammen- gesetzte 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';

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!)

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

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‘, Type_Professor(‘Jaeger‘ , ‘CAD‘,‘CAE‘), ...)), Type_Student(‘00011',‘Meier',‘Ralf', … ) … ) ...);

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?)>  // 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)    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));

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;

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, CURSOR (SELECT s.attrSubject FROM tabSubject s WHERE p.IDProfessor = s.IDProfessor) AS Subject FROM tabProfessor; Verarbeitung durch Oracle XSU

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()

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?

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.