Oracle XML DB: XML Schema Handling für Entwickler und Administratoren

Transkript

1 Oracle XML DB: XML Schema Handling für Entwickler und Administratoren Annegret Warnecke Oracle Deutschland GmbH Berlin Schlüsselworte: Orale XML DB, XML Schema, XML Schema Registrierung, Annotationen, objektrelationale Speicherung, Performance, Indizes, Constraints 1. Einleitung In diesem Vortrag soll zum einen das Grundkonzept von XML Schema in der Oracle XML DB dargestellt, zum anderen anhand von Beispielen das XML Schema Handling erläutert werden. Die nachfolgenden Beispiele beziehen sich auf den Prozeß des Registrierens, inklusive einer Betrachtung, wie XML Schema Dokumente in der Oracle Datenbank abgebildet werden, sowie auf die Möglichkeiten, die sich durch die objektrelationale Speicherung ergeben. Um die verwendeten Scripte - inklusive der XML Schema Dokumente - zu erhalten, wenden Sie sich bitte per Mail an mich. 2. Das Grundkonzept von XML Schema in der Oracle Datenbank Die Oracle Datenbank bietet eine umfangreiche XML Unterstützung. Funktionalitäten im Zusammenhang mit XML Schema sind seit 9i Release 2 verfügbar. Mit 11g ist insbesondere die Möglichkeit der binären Speicherung ergänzt worden. Der Datenbank wird ein XML Schema bekannt gemacht. Sofern das XML Schema der XML Schema Spezifikation entspricht, wird es bei der Datenbank registriert. Im Zusammenhang mit der Registrierung werden standardmäßig objektorientierte Strukturen angelegt. Alternativ kann die Speicherung im CLOB oder in binären Form vorgesehen werden. Dies gilt sowohl für Instanzdokumente als Ganzes als auch für Strukturen innerhalb der Instanzdokumente. Letzteres geschieht, indem das defaultmäßige Mapping von XML Schema Strukturen auf Objekte in der Datenbank durch Annotationen überschrieben werden. Standardmäßig wird im Rahmen der XML Schema Registrierung eine default XMLType Tabelle eingerichtet, die dem betr. XML Schema entspricht. XML Dokumente, die das betr. XML Schema referenzieren, können nicht nur programmtechnisch sondern auch mittels WebDAV oder ftp in diese default Tabelle eingefügt werden. Weitere Tabellen, einzelne Spalten von Tabellen und Views können im Anschluß an die Registrierung dieses XML Schema referenzieren. Dokumente, die dort eingefügt werden, werden gegen das betreffende XML Schema geprüft. Für nicht binär gespeicherte Dokumente findet standardmäßig eine einfache XML Schema

2 Prüfung statt: Die XML Dokumente werden eingefügt, wenn sie mit den betreffenden objektorientierten Strukturen entsprechen. Eine vollständige XML Schemaprüfung kann eingerichtet werden. Bei binärer Speicherung erfolgt immer eine vollständige XML Schemaprüfung. Abb. 1: Speicherungsformen für XML Schema basierte Dokumente XPath-Abfragen auf XML Dokumente, die objektorientiert in der Oracle Datenbank abgelegt sind, unterscheiden sich zunächst nicht von Abfragen auf XML Dokumente im CLOB oder im binärer Form. Im Hintergrund wird eine XPath-Abfrage auf objektorientierte Strukturen allerdings so umgeschrieben, daß der Abfragepfad den betreffenden objektorientierten Strukturen entspricht. Dadurch können insbesondere bei stark strukturierten XML Dokumenten deutliche Performanceverbesserungen erzielt werden. Bei binärer Speicherung wird ein positiver Performance-Effekt dadurch erreicht, daß ein XPath-Streaming genutzt wird (Aufbau eines DOM-Baum wird dadurch vermieden). Zusätzliche Performanceverbesserungen in der Abfrage können durch den Einsatz von Indizes erreicht werden (insbesondere: B-Baum für objektorientierte Speicherung, XMLIndex für die Speicherung im CLOB oder binär). Bei objektorientierten und bei binärer Speicherung können zusätzlich zu Not Null und Check Constraints auch Unique und Foreign Key Constraints eingerichtet werden können. 3. Erläuterung des XML Schema Handlings anhand von Beispielen Im Zusammenhang mit dem XML Schema Handling bietet der Oracle Enterprisemanager umfangreiche Unterstützung. Für das Editieren von XML Schemata wird der JDeveloper empfohlen. 3.a) Der standardmäßige Prozeß der XML Schema Registrierung Das Generieren, Registrieren, Verändern und Löschen von XML Schemata erfolgt mithilfe des Datenbankpaketes dbms_xmlschema. Für das Registrieren ist es erforderlich, eine Bezeichnung anzugeben, unter der das XML Schema in der Datenbank registriert werden soll, sowie entweder das zu registrierende XML Schema direkt mitzugeben oder den Ort zu nennen, an dem das XML Schema zu finden ist.

3 Abb. 2: Registrierung eines XML Schemas bei der Datenbank unter Nutzung des Oracle Enterprise Managers BEGIN dbms_xmlschema.registerschema (schemaurl => ' End; / schemadoc => bfilename('xmldir', 'person.xsd'), CSID => nls_charset_id('al32utf8')); listing 1: Beispiel für die Registrierung eines XML Schemas bei der Datenbank Weitere Parameter können bei der Registrierung mitgegeben werden. Sie definieren, welche Art von Objekten automatisch generiert werden, welcher Benutzer welche Rechte an dem registrierten XML Schema hat und ob die Registrierung auch bei fehlerhafter XML Schema Definition erzwungen wird oder nicht. Als Option kann an dieser Stelle angegeben werden, daß die Speicherung binär erfolgen soll. Tabellen, Spalten in Tabellen oder Views, die gegen ein bestimmtes XML Schema geprüft werden sollen, müssen in dem betreffenden create Statement auf den Namen des Schemas verweisen. Bei binärer Speicherung gibt es die Optionen "ALLOW ANYSCHEMA" und "ALLOW NONSCHEMA". Diese Optionen lassen für an bestimmte XML Schemata

4 gebundene Tabellen und Spalten von Tabellen auch zu, daß XML Dokumente geladen werden, die andere XML Schemata bzw. kein Schema referenzieren. create table Person_Column (NR number(10), pers XMLTYPE) XMLTYPE column pers XMLSCHEMA " ELEMENT "Person"; listing 2: Beispiel für das Einrichten einer Tabelle mit XML Type Spalte, die gegen ein XML Schema referenziert wird create table PX of XMLType (CHECK (XMLIsValid(sys_nc_rowinfo$) = 1)) XMLSCHEMA " ELEMENT "Person"; listing 3: Beispiel für das Einrichten einer XML Type Tabelle, auf die eine vollständige XML Schema Prüfung durchgeführt wird Für das Rückgängig machen der XML Schema Registrierung ("Löschen") können verschiedene Optionen genutzt werden, die sich darin unterscheiden, in welcher Form und in welchem Ausmaß bei dem Löschvorgang abhängige Objekten und bestehende Instanzdaten beachtet / berücksichtigt werden. Abb. 3: Optionen im Zusammenhang mit dem "Löschen" von registrierten Schemata EXEC dbms_xmlschema.deleteschema(' dbms_xmlschema.delete_cascade_force); listing 4: Beispiel für das Löschen eines XML Schemas Die Änderung von registrierten XML Schema Definitionen wird durch die Prozeduren DBMS_XMLSCHEMA.copyEvolve und DBMS_XMLSCHEMA.inPlaceEvolve (letztere

5 Funktion ist mit Release 11g hinzu gekommen) unterstützt. Das Prinzip von copyevolve besteht darin, die bestehenden Instanzdokumente an anderer Stelle zwischen zu speichern, die XML Schema Registrierung durch das neue XML Schema auszutauschen und anschließend mit entsprechender Transformation die Instanzdokumente neu einzustellen. inplaceevolve kann verwendet werden, wenn das Speicherungsmodell bestehen bleibt und durch die Veränderungen in der XML Schema Struktur vorhandene Instanzdokumente nicht ungültig werden. Kopiervorgänge und Umwandlungen der Instanzdokumente werden in diesem Fall vermieden. Dadurch ist dieses Verfahren schneller als copyevolve. Das Generieren von XML Schemata kann aufbauend auf bestehenden Objekttypen erfolgen. 3.b) Das Mapping von XML Schemata auf die Oracle Datenbank Im Zusammenhang mit dem Registrierungsvorgang entscheidet die Datenbank insbesondere über Speicherungsformen und Namensgebungen in der Datenbank. Der Prozeß läuft vollkommen automatisch ab. Er kann unterdrückt werden, indem die Parameter gentables / gentypes auf false gesetzt wird, oder beeinflußt werden, indem in das zu registrierende XML Schema Dokument entsprechende Annotationen eingefügt werden. Abb. 4: Beispiel für den Einsatz des JDeveloper als Editor für XML Schema Dokumente

6 Das automatische Mapping von Strukturen erfolgt sowohl bei objektrelationaler als auch bei binärer Speicherung. Die in der Datenbank verfügbaren Ziel-Datentypen werden entsprechend ausgewählt. Wird das vollständige Dokument als CLOB abgespeichert, erübrigt sich eine weitere Zuordnung von Datentypen. Nachfolgend sollen Mapping im Zusammenhang mit objektrelationaler Speicherung näher beleuchtet werden. XML simpletypes werden auf den am engsten verwandten SQL Datentyp, in vielen Fällen auf VARCHAR2, NUMBER und DATE gemappt. Diese defaultmäßigen Zuordnung kann innerhalb eines vordefinierten Rahmens beeinflußt werden. So kann z.b. anstelle von VARCHAR2 CHAR oder CLOB gesetzt werden. Für complextypes werden Objekttypen, im Falle von Wiederholungen (maxoccurs > 1) varrays angelegt. Wenn sqlinline="false" angegeben wird, wird für das betreffende Element eine separate Tabelle eingerichtet, deren Inhalt direkt abgefragt werden kann (s. listing 5 bzw. Abb. 6). Strukturinformationen, die über diese Objekttypen nicht abgebildet werden (z.b. die Reihenfolge von Elementen), werden in sogenannten Pseudocolumns abgelegt. Falls es nicht notwendig ist, die vollständigen Strukturinformationen zu erhalten, kann die Generierung der Pseudocolumns unterdrückt werden, indem das Annotations Attribut "maintaindom" = false gesetzt wird. Wenn "maintainorder" = false gesetzt wird, wird die Information bezüglich der Reihenfolge der betr. Knoten nicht abgespeichert. Damit die Datenbank die Annotationen erkennt, muß in der Schema-Definition der XDB Namespace referenziert werden. Durch Anwendung des Präfixes xdb nehmen alle Annotationen auf diesen Namespace Bezug. Die Vorgabe der Namen für die zu erzeugenden objektrelationalen Objekte empfiehlt sich zumindest für die jeweiligen oberen Hierarchiestufen (z.b.: "defaulttable= "person_tab" in dem nachfolgenden Listing). Der JDeveloper bietet für das Einfügen von Annotationen Unterstützung (Abb. 4, roter Rahmen). <xs:schema xmlns:xs=" xmlns:xdb=" <xs:element name="person" xdb:defaulttable= "person_tab"> <xs:complextype xdb:sqltype="person_t"> <xs:sequence> <xs:element name="name" type="xs:string" xdb:sqlname="nachname" xdb:sqltype="clob"/> <xs:element name="ort" maxoccurs="unbounded xdb:sqlinline="false"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> listing 5: Beispiel für ein annotiertes XML Schemas Sofern die Mapping-Information betr. den SQLType nicht kompatibel ist mit den vorgesehenen möglichen Mappings, schlägt die Registrierung fehl (s. Beispiel in Abb. 5).

7 Abb. 5: Fehlermeldung im Oracle Enterprise Manager bei dem Versuch, den SQLType in Listing 5 durch "DATE" zu ersetzen Abb. 6: vollständig annotiertes Schema nach der Registrierung auf Basis des Schemas in listing 5

8 Die erzeugten objektorientierten Strukturen können programmtechnisch abgefragt werden. In das nachfolgende Beispiel sind zuvor zwei Datensätze eingefügt worden. SQL> desc "person_tab" Name Null? Typ TABLE of SYS.XMLTYPE(XMLSchema " Element "Person") STORAGE Object-relational TYPE "person_t" SQL> desc "person_t" Name Null? Typ SYS_XDBPD$ XDB$RAW_LIST_T Nachname CLOB Ort XDB$XMLTYPE_REF_LIST_T SQL> desc XDB$XMLTYPE_REF_LIST_T; XDB$XMLTYPE_REF_LIST_T VARRAY( ) OF REF XMLTYPE SQL> select * from "person_tab"; SYS_NC_ROWINFO$ <Person xmlns:xsi=" xsi:nonamespaceschemal ocation=" <Name>Heinrich</Name> <Ort>Braunschweig</Ort> </Person> <Person xmlns:xsi=" xsi:nonamespaceschemal ocation=" <Name>Otto</Name> <Ort>Hamburg</Ort> <Ort>Hannover</Ort> </Person> SQL> select * from "Ort1114_TAB"; SYS_NC_ROWINFO$ <Ort>Braunschweig</Ort> <Ort>Hamburg</Ort> <Ort>Hannover</Ort> SQL> listing 5a: Beispiel zur Abfrage der erzeugten objektórientierten Strukturen sowie der Inhalte der Tabellen

9 3.c) Query Rewrite (XPath Rewrite): verbesserte Performance und Indizierung / Constraints Bei objektorientierter Speicherung von XML Dokumenten in der Oracle XML DB kann auf Substrukturen der betr. Dokumente direkt mit SQL Mitteln zugegriffen werden. Der B-Baum- Index, Unique Index, Primary Key und Foreign Key Constraint machen von dieser Möglichkeit Gebrauch. Die Datenbank schreibt Anfragen von der XPath Notation in die entsprechende relationale Form um. Dieser Vorgang wird als Query Rewrite (XPath Rewrite) bezeichnet. Es ist zu beachten, daß nicht alle XPath Ausdrücke Query Rewrite benutzen können (z.b. werden ausschließlich Childknoten berücksichtigt). Der Foreign Key Constraint erlaubt es, Constraints zwischen XML Dokumenten und relationalen Tabellen einzurichten. Wie bei binärer Speicherung und Speicherung im CLOB können auch der funktionsbasierte und der Text Index auf objektorientiert gespeicherte XML Dokumente angewendet werden. Anstelle des B-Baum Indexes kann bei binärer Speicherung oder Speicherung im CLOB der mit Release 11g neu zur Verfügung stehende XMLIndex eingesetzt werden (ersetzt CTXXPath Index). Wenn Query Rewrite angewendet wird, entfällt der zeitintensive Aufbau des DOM Baums beim Parsen. Dadurch werden erhebliche Performanceverbesserungen erzielt. Indizierungen können diesen Effekt weiter verstärken. select extractvalue(value(p), '/PurchaseOrder/Requestor') as Anforderer from PURCHASEORDER p; select p.xmldata."requestor" as Anforderer from PURCHASEORDER p; listing 6: XPath Abfrage und die entsprechende mittels query rewrite umgeschriebene Abfrage Bei "xmldata" handelt es sich um eine XMLType Pseudocolumn, die den Zugriff auf die objektorientierten Strukturen ermöglicht. Query Rewrite erfolgt nicht nur im Rahmen reiner Abfragefunktionen (existsnode, extract, extractvalue, XMLExists, XMLQuery, XMLSequence, XMLTable), sondern auch im Zusammenhang mit Veränderungen an bestehenden Dokumenten (insertchildxml, updatexml, deletexml). Für nicht objektorientiert gespeicherte Substrukturen von XML Dokumenten wird kein Query Rewrite durchgeführt. Durch die Möglichkeit, auf XMLType Tabellen oder XMLType Spalten Constraints zu definieren, wird der Funktionsumfang von XML über die Grenzen des einzelnen Dokumentes hinaus ausgedehnt, indem bekannte relationale Technologie auf alle XML Dokumente der betr. XMLType Tabelle bzw. XMLType Spalte angewendet wird. Durch Foreign Key Constraints können relationale Tabellen mit XML Type Tabellen / Spalten verbunden werden.

10 create table purchaseorder_as_table of XMLType (UNIQUE ("XMLDATA"."REFERENCE"), FOREIGN KEY (XMLDATA."USERID") REFERENCES employees ( )) XMLSCHEMA " ELEMENT "PurchaseOrder"; listing 7: Beispiel für das Einrichten eines Unique Constraints in einer XMLType Tabelle alter table purchaseorder_as_table add constraint user_is_valid foreign key (xmldata."userid") references employees( ); listing 8: Beispiel für das Einrichten eines Foreign Key Constraints in einer XMLType Tabelle 4. Resumé Es stehen mit der Oracle XML DB sehr umfangreiche und ausgereifte Möglichkeiten zur Verfügung, mit XML Schema zu arbeiten, die an dieser Stelle exemplarisch dargestellt wurden. Besonders hingewiesen werden soll nochmals auf die großen Vorteile für die Performance, die bei objektorientiert gespeicherten XML Dokumenten entstehen, sowie auf die Besonderheit, für XML Dokumente Integritätsbedingungen definieren zu können. Kontaktadresse: Annegret Warnecke Oracle Deutschland GmbH Schloßstr. 2 D Berlin Telefon: +49(0) Fax: +49(0) annegret.warnecke@oracle.com Internet: