XML databases
Werbung
KU Verkehrsinformatik - Datenbankkonzepte Ass.Dipl.-Ing. Fuchs Simone LV Nr 623.904, SS 2006 XML databases Verfasser/Referent: Martin Hölbling 0160062 [email protected] XML databases Martin Hölbling Inhaltsverzeichnis 0 1 2 Abstract............................................................................................................... 3 Einleitung............................................................................................................ 3 Bedeutung von XML in DAM-Systemen ........................................................... 3 2.1 Digital Asset Management.......................................................................... 3 2.2 Realisierung eines DAM-System................................................................ 4 3 Zusammenspiel von XML-Dateien und relationalen DBs.................................. 5 3.1 XML-enabled Databases............................................................................. 5 3.1.1 Bekannte Vertreter von XML-enabled Databases .............................. 6 3.2 XML Shredding .......................................................................................... 6 3.2.1 ShreX .................................................................................................. 6 3.3 Native XML Datenbanken.......................................................................... 9 3.3.1 Kategorien von Nativen XML-Datenbanken:..................................... 9 3.3.2 Vertreter von Nativen XML-Datenbanken ......................................... 9 3.3.3 Native XML in DB2 Viper ............................................................... 10 4 Anwendungsbeispiel – XML in DB2 Viper: .................................................... 12 4.1 Datenbankschema: .................................................................................... 12 4.2 Abfragen ................................................................................................... 13 4.2.1 Selektion der Fahrer des Fahrzeugs mit der ID 144 ......................... 13 4.2.2 Restriktion aufgrund eines XML-Werts ........................................... 13 4.2.3 XMLQuery........................................................................................ 14 4.2.4 Umwandlung von XML in SQL-Datentypen ................................... 14 4.2.5 Joins von XML und nicht-XML Daten: ........................................... 15 4.2.6 Umwandlung von relationalen Daten in XML: ................................ 15 4.2.7 Update-Statement: ............................................................................ 15 4.2.8 SQL/XML-Statements in Java :........................................................ 15 5 Zusammenfassung ............................................................................................ 16 2 XML databases 0 Martin Hölbling Abstract Durch das vermehrte Aufkommen von XML-Daten in unterschiedlichen Formen wie Webcontent, Multi-Media-Daten-Header etc. ist auch der Bedarf an XMLDatenbanken zur Verwaltung von XML-Content gestiegen. Dabei gilt es nicht nur reine XML-Daten zu verwalten, sondern auch bestehende relationale Datenbanken zu integrieren. Diese Arbeit befasst sich mit der Problematik der Verwaltung von XML-Daten und der Integration von relationalen Daten mit XML-Daten. Dazu werden XML-enabled databases vorgestellt, die eine Abbildung von XML-Daten auf relationaler Ebene ermöglichen. In diesem Zusammenhang wird auch auf XMLShredding – im Speziellen auf das System „ShreX“, einem Framework zur Abbildung von XML-Daten auf eine beliebige relationale Datenbank - eingegangen. Überdies werden Native XML-Datenbankkonzepte vorgestellt, die XML-Daten und relationale Daten verwalten können, ohne die XML-Daten auf relationale Ebene abbilden zu müssen. Im Anwendungsbeispiel wird abschließend gezeigt, wie relationale und XML-Daten in der Nativen XML-Datenbank „DB2 Viper“ abgelegt und bearbeitet werden können. 1 Einleitung Viele Unternehmen verfügen über große Mengen an digitalem Material, bei denen Metadaten in Form von XML eine wesentliche Rolle spielen. Diese Metadaten beschreiben die Datei (z.B. Video, Foto, Präsentation etc.) und deren Inhalt (z.B. Aufnahmedatum, Belichtung, Auflösung, Inhalt, Lizenzen etc.). Dabei wird XML als Header für diese Dateien eingesetzt. Zudem bietet sich XML als ideales temporäres Austauschformat für das Web und andere Applikationen an. Eine Applikation generiert beispielsweise ein XMLDokument, eine andere liest dieses wieder aus und verarbeitet es. Viele dieser XMLDaten sollen aber auch dauerhaft gespeichert werden können. Dabei müssten sie in Datenbanken abgelegt werden. Dies kann rein als XML erfolgen oder durch eine Abbildung der Dokumente auf eine (objekt-)relationale Datenbank. Will man durch eine Abbildung von XML-Dokumenten auf relationale Datenbanken (und vice versa) diese beiden „Welten“ zusammenführen, so muss man sich über die Unterschiede im Klaren sein. So ist die Struktur von relationalen Daten in mehreren flachen Tabellen gespeichert, bei XML hingegen gibt es oft hierarchische, beliebig tiefe Strukturen. Außerdem besitzen Spalten in relationalen Datenbanken einen eindeutigen Wert, bei XML können Elemente jedoch mehrfach auftreten. 2 Bedeutung von XML in DAM-Systemen Die Anwendungsgebiete von XML sind sehr vielfältig. XML wird als Austauschformat für das Web und anderen Applikationen eingesetzt. Zudem spielen Metadaten in Form von XML für Digital Assets eine wesentliche Rolle. 2.1 Digital Asset Management Viele Unternehmen, vor allem im Medienbereich, verfügen über eine große Anzahl an Digital Assets in Form von Bildern, Videos, Audio-Dateien, Präsentationen, Webseiten etc., die es zu verwalten gilt. Diese Verwaltung obliegt dem Digital Asset Managament-System, das in Form von Datenbanken realisiert wird. Die Herausfor3 XML databases Martin Hölbling derung ist es die digitalen Daten zu verwalten, zu katalogisieren und zu verteilen. Im Folgenden werden die wichtigsten Faktoren, die bei der Realisierung von DAMSystemen zu beachten sind, aufgelistet:[1] • Speicherung: Die Datenträger zur Speicherung von digitalen Daten sind Alterungsprozessen unterworfen. So können digitale Daten unter Umständen nicht verfügbar oder die Ressource könnte mit zukünftigen Technologien nicht mehr kompatibel sein. • Prozedurale Angelegenheiten: Viele Dokumente, wie z.B. Textdokumente, müssten erst digitalisiert werden. Dieser Prozess kann sehr arbeits- und ressourcenintensiv sein. • Sicherheit: Konzerne müssen ihre digitalen Assets vor Missbrauch, Diebstahl und Schaden schützen. • Copyright: Copyright-Besitzer haben das exklusive Recht Daten zu nutzen. Digitalisierung verletzt diese Rechte oft. • Verteilung: Digital Assets müssen über geeignete Kommunikationskanäle zu den richtigen Benutzerinnen und Benutzern gelangen. • Infrastruktur: Für DAM-Systeme ist eine stabile IT Infrastruktur notwendig. • Menschliche Faktoren: Benutzerinnen und Benutzer müssen mit dem System vertraut gemacht werden. In einem Medien-Unternehmen (z.B. Werbeagentur) stellt der durchschnittliche User 83 Mal pro Woche Anfragen nach Media-File, dabei schlagen allerdings 35 % der Suchanfragen fehl. Durch den Einsatz von DAM-Systemen verspricht man sich eine Senkung dieser fehlgeschlagenen Anfragen auf 5 %[1]. Um ein effektives Filemanagement zu garantieren, spielen Metadaten der Dateien in XML-Form eine wesentliche Rolle. Adobe´s Extensible Metadata Platform (XMP) [2] ermöglicht es beispielsweise eigene Metadaten-Tags für ein File zu definieren. Dabei werden flexible Suchverfahren und „Smart Assets“, die den Kontext bei unterschiedlichen Dateiformaten, Softwareapplikationen und Datenbanken erhalten, ermöglicht. Außerdem wird der Content-Lifecycle, d. h. der Ursprungskontext einer Datei kann über mehrere Versionen erhalten werden, erhöht. Dies kann vor allem für effiziente Suchverfahren, Workflow-Automation, Rechte-Management und Verwaltung in Datenbanken nützlich sein. XMP wird in der aktuellen Version von Adobe´s Creative Suite (CS 2) bereits eingesetzt. Die NASA setzte XMP zum Beispiel zur Katalogisierung von mehreren tausend Fotos nach GPS-Daten ein. 2.2 Realisierung eines DAM-System Ein Digital-Asset-Management-System sollte über folgende Funktionalitäten verfügen[1]: • Indexing: Das Indexing muss umfassend sein und auch alle Metadaten, die oft den Content beschreiben, beinhalten. • Rights Management: Rechte müssen verwaltet werden können. • Reuse: Der Content muss leicht auffindbar und wiederverwendbar sein. • Review: DAM Systeme sollen den Review von altem Content erleichtern. 4 XML databases Martin Hölbling Um ein DAM-System zu realisieren, bieten sich XML-Datenbanken an. Da viele Unternehmen bereits über relationale Datenbanken verfügen, sollen XML-Daten mit den Daten aus relationalen Datenbanken verknüpft werden. Welche Ansätze sich dazu eignen, wird im nächsten Abschnitt behandelt. 3 Zusammenspiel von XML-Dateien und relationalen DBs Um die „Welten“ XML-Dokumente und relationale Datenbanken zusammen zu führen, muss man sich über die Unterschiede, die bei der Integration von XMLDaten und relationalen Datenbanken überwunden werden müssen, klar werden. Diese betreffen: [3, 4] • Struktur: Relationale Daten werden in flachen Tabellen gespeichert. XML hingegen bietet die Möglichkeit eine hierarchische, beliebig tiefe Struktur aufzubauen. Diese XML-Strukturen in relationale Daten zu überführen, kann sehr komplex sein. • Eindeutigkeit: In relationalen Datenbanken ist jeder Spalten/ZeilenKombination ein Wert zugewiesen, während bei XML-Dokumenten mehrere Attribut-Ausprägungen zulässig sind und somit Werte pro Spalte mehrfach auftreten können. • Vollständigkeit: In der relationalen Welt sind Tabellen vollständig. XML ist hingegen optional und Attribute können offen sein. Die wichtigsten Ansätze, um eine Kombination aus relationalen Datenbanken und XML-Daten nutzen zu können, sind XML-enabled Databases und native XMLDatenbanken. Der Unterschied zwischen XML-enabled und native Databases ist, dass XML-enabled Databases schemen-spezifische Strukturen, die auf das XMLFile zur Design-Zeit gemappt werden müssen, verwenden, während native XML Datenbanken generische Strukturen nutzen, die jedes beliebige XML-Dokument enthalten können. [1] Native XML databases können die physische Struktur sowie Kommentare, DTDs, Pls etc. verwalten. [5] XML-enabled databases können dies zwar auch, jedoch ist die Realisierung sehr umständlich und die Performance schlecht. Außerdem gibt es bei nativen XML-Datenbanken ein einheitliches Interface. Bei XML-enabled Databases muss dies nicht gewährleistet sein. Im Folgenden wird genauer auf diese Ansätze eingegangen. Zudem wird XMLShredding vorgestellt, das es erlaubt, XML-Daten in jede beliebige relationale Datenbank zu integrieren. 3.1 XML-enabled Databases In einer XML-enabled Datenbank werden Dokumente in einzelnen Fragmenten gespeichert. Hierbei wird der XML-Content in objektrelationale Form umgewandelt und gespeichert. Diese Datenbanken haben eine eigene XML-Mapping layer, die die Speicherung und die Wiederherstellung von XML-Daten durchführt. XML SQL Utility (XSU) oder SQL mit Packages werden dazu verwendet, den ursprünglichen Inhalt zu generieren. Neben dem entstehenden Performanceverlust, können dabei auch leicht Daten verloren gehen. Der Grund dafür liegt darin, dass über ein Schema zur Designzeit definiert werden muss, wie ein XML-Dokument, das akzeptiert werden soll, auszusehen hat. Entspricht nun ein XML-Dokument nicht den Vorgaben, wird es entweder nicht akzeptiert oder Attribute, die nicht in der Schema-Definition enthalten sind, können bei der Rekonstruktion aus den relationalen Daten nicht mehr wiederhergestellt werden. [1, 5] 5 XML databases Martin Hölbling Die momentane XML-Lösung von Oracle und Microsoft arbeiten auf diese Weise. 3.1.1 Bekannte Vertreter von XML-enabled Databases [6] • Microsoft Access: ab Version 2002 – transferiert Daten von/zu XML Dokumenten über ein tabellenbasiertes Mapping.1 • Cache: von InterSystems Corp. • DB2: von IBM • eXtremeDB: von McObject LLC. eXtremeDB unterstützt XML über ein XML-Data-Binding und kann von einem Datenbankschema Methoden generieren, die neue Objekte von XML-Dokumenten erzeugt, mit bestehenden Objekten updatet. Diese Objekte werden vorzugsweise für SOAPNachrichten eingesetzt. • PostgreSQL: von PostgreSQL Global Development Group • SQL Server 2000: von Microsoft • Oracle: Oracle9i unterstützt XML-Datentyp, SQL/XML, XQuery, XSLT, DOM etc. XML-Daten können entweder objektrelational oder als CLOB gespeichert werden. Ein CLOB speichert die Dokumente exakt ab, speichert jedes Dokument, kann aber nur Dokumenten-Updates durchführen, also das Dokument als Ganzes neu laden, und hat weniger Indexierungsoptionen als im objektrelationalen Modus. Der Vorteil bei Oracle ist, dass XMLDokumente auf DOM-Level durchlaufen werden können. Dazu speichert es versteckte Spalten, in relationaler Form, ab und ist somit in die Kategorie der XML-enabled Databases einzuordnen.[6] 3.2 XML Shredding XML Shredding bietet ein Framework, das es erlaubt, XML-Daten auf jede beliebige relationale Datenbank zu mappen. Die XML-Daten werden in relationale Form gebracht und in die Datenbank geschrieben. [7] 3.2.1 ShreX ShreX (Shredding XML) ist ein frei verfügbares System, mit dem Mappings von XML in relationale Datenbanken ermöglicht werden. Mit ShreX können eigene Mapping-Strategien angewandt werden, die auf die Applikation zugeschnitten wird. Das Mapping kann für jede beliebige Datenbank verwendet werden.[4] 1 Anmerkung: Microsoft Access ist kein Datenbanksystem, sondern ein Datenerhaltungsprogramm. 6 XML databases Martin Hölbling Abbildung 1: ShreX Architecture [7] In ShreX wird ein Mapping durch das Hinzufügen von Anmerkungen ins XMLSchema definiert. Diese Anmerkungen geben an, wie Elemente und Attribute in der relationalen Datenbank gespeichert werden. Der „annotation processor“ (Abbildung 1) parst das mit Anmerkungen versehene XML-Schema, prüft die Gültigkeit des Mappings und erzeugt daraus ein relationales Schema. Die Validierung des XMLSchemas umfasst die Überprüfung auf Richtigkeit der Anmerkungen und die Uniqueness-Prüfung der einzelnen Elemente in der Tabelle. Zusätzlich kann noch überprüft werden, ob die Abbildung verlustfrei passiert. ShreX verfügt auch über eine automatische Mapping-Funktion. [4] Die Informationen zum Mapping werden im Mapping-Repository gespeichert und können wiederverwendet werden. Der Document Shredder bekommt das XMLDokument und benutzt die Mapping API, um auf die Informationen im Mapping Repository zu zugreifen. Er vollzieht das Shredding des XML-Dokuments und befüllt die Tabellen. Außerdem verfügt der Document Shredder über einen Validierungsmechanismus, der das Input überprüft. [4] Der Query-Translator generiert SQL-Queries aus XML-Queries, die mit XPath definiert wurden. Die Mappings werden über ein XML-Schema definiert, was sie einerseits portabel macht, andererseits auch erweiterbar. Außerdem können Mappings zur Validierung herangezogen werden. Annotation attributes: [4] • outline (true or false): Wenn Outline true ist, wird eine Tabelle für das entsprechende Attribut kreiert. 7 XML databases Martin Hölbling • tablename (string):Dieser String wird als Tabellenname benutzt. • columnname(String): Dieser String wird als Spaltenname benutzt. • sqltype (String): Dieser String überschreibt den Sqltyp der Spalte. • structurescheme (KFO, Interval, Dewey): Spezifiziert die Struktur des Mappings – Dewey – Dezimale Klassifikation, Interval – in bestimmten Intervallen; KFO – kostenbasierter Ansatz für parent-child-relations • edgemapping (true, false): Ist der Wert true, wird das Element und seine Nachfolger nach dem Edge-Mapping-Verfahren geshreddet. • maptoclob (true, false): Ist der Wert true, wird das Element oder Attribut als CLOB-Spalte gemappt. Beispiel ShreX: Abbildung 2: Annotated movie schema [7] Abbildung 2 zeigt ein mit Anmerkungen versehenes Schema, das in das Mapping Repository geladen wird. Die Anmerkung „outline=true“ im Element TITLE gibt an, dass dafür eine extra Tabelle mit Namen „Showtitle“ angelegt wird. Das outlineAttribut von YEAR hingegen ist false, d. h. es wird direkt unter der Tabelle SHOW angelegt und erhält keine eigene Tabelle. Durch sqltype wird der Typ überschrieben. Das Attribut edgemapping=true im Element REVIEW wird dazu eingesetzt, um alle REVIEW-Elemente und deren Inhalt zu mappen – Meistens dann, wenn die Struktur nicht im Vorhinein bekannt ist. 8 XML databases Martin Hölbling Abbildung 3: Relational configuration for movie schema [7] Das aus Abbildung 2 resultierende Datenbankschema ist in Abbildung 3 zu sehen. 3.3 Native XML Datenbanken In einem nativen Datenbank-Ansatz wird die gesamte XML-Datenbank als Ganzes abgespeichert. Dokumente werden in ihrem Orginalformat gespeichert, indiziert und wiederhergestellt. Die XML-Datenbank verarbeitet XML in seiner natürlichen Form, was die Performance wesentlich verbessert. Eine native XML-Datenbank definiert ein logisches Modell für ein XML-Dokument. Dementsprechend speichert sie Dokumente und stellt Dokumentabfragen. Als fundamentale Einheit dient ein XML-Dokument. Ein darunterliegendes physikalisches Speichermodell ist nicht erforderlich. Die Datenbank kann auf einer relationalen, hierarchischen oder objektorientierten Datenbank aufgesetzt bzw. in indizierten, komprimierten Files gespeichert sein. [5, 6] 3.3.1 Kategorien von Nativen XML-Datenbanken: Native XML-Datenbanken kann man in zwei Kategorien einteilen[5]: Dokumentbasierte Native XML-Datenbank/Text-Basiertes Speichern: Eine textbasierte native XML-Datenbank speichert XML als Text, in einem Filesystem, in einem BLOB in einer relationalen Daten oder einem eigenen Textformat. Diese Datenbanken sind indiziert und können leicht von einem Knoten zum Anderen im XML-Dokument springen, was die Performance erhöht. Die Datenbank kann das ganze Dokument oder einzelne Fragmente in einem einzigen Leseprozess auslesen. Eine textbasierte XML-Datenbank entspricht einer hierarchischen Datenbank. Beim Auslesen von meheren XML-Files sind allerdings mehrere Leseprozesse notwendig. Modellbasierte Native Datenbanken/Knoten-Basiertes Speichern: Dem Dokument werden separate Knoten entnommen und in einem bestehenden Speicherbereich abgelegt. Bei Knoten-basiertem Speichern können Fragmente aus unterschiedlichen Dokumenten mit wenigen Leseprozessen kombiniert werden. Beim Auslesen eines gesamten Dokuments sind jedoch auch mehrere Leseprozesse notwendig. 3.3.2 Vertreter von Nativen XML-Datenbanken [6] • 4 Suite Server: von FourThougt – Open Source. 9 XML databases Martin Hölbling • Berkeley DB XML: von Sleepycat Software – Open Source. Dabei handelt es sich um eine die relationale Berkeley DB mit einem integriertem XMLParser, XML Indizes und einer XQuery Engine. Berkeley DB XML speichert Dokumente in Containern. • DBDOM: Open Source • dbXML: von dbXML Group – OpenSource. • Ozone: von ozone-db.org – OpenSource. • Tamino: von Software AG – kommerzielle Nutzung. Tamino XML Server inkludiert eine native XML Datenbank, eine integrierte relationale Datenbank, Sicherheitstools, Administrationssoftware. Die XML-Engine benutzt eine Data Map, die angibt wo die Daten in einem gegebenen XML-File oder auf der relationalen Datenbank liegen. Inkludiert sind DOM, JDOM, SAX, XQuery und SOAP. • Timber: von der University of Michigan – Open Source. Zielt vor allem auf die Integration von relationalen Datenbanken und XML ab. • Xindice: von der Apache Software Foundation – Open Source. Eine knotenbasierte native XML Datenbank in Java speziell für eine große Menge an kleinen XML-Dokumenten. Xindice komprimiert Dokumente, um Platz zu sparen. Die Query-Language ist XPath. Xindice verfügt über eine experimentelle Linking Language, die es dem User ermöglicht XML-Content in einem XML-Dokument zur Anfrage-Stellungszeit zu ersetzen oder einzufügen. 3.3.3 Native XML in DB2 Viper Die XML-Datenbank von IBM “DB2” Codename: Viper wird neben ihrer nativen Definition auch als hybride Datenbank bezeichnet. Abbildung 4 zeigt die Architektur von DB2 Viper. Relationale Daten werden unabhängig von XML-Daten gespeichert und in einem eigenen Speicherbereich abgelegt. Abbildung 4: DB2 Viper Architecture [8] IBM hat die neue DB2 um eine native XML-Datenbank erweitert. Die Benutzerin bzw. der Benutzer kann vollständige XML-Dokumente mit voller DBMSUnterstützung speichern. DB2 ermöglicht es, mit normalen Tabellen und XML10 XML databases Martin Hölbling Strukturen zu arbeiten. Abfragen können dabei in SQL/XML oder XQuery gestellt werden. DB2 Viper verwendet zwei separate Speicher-Mechanismen. Für die darüberliegenden Applikationen ist der Speicherort jedoch transparent, d. h. dass die Applikation sich nicht um den Speicherort kümmern muss. Außerdem können einzelne XML-Dokumente effektiv über mehrere Datenbank-Seiten gesplittet werden. [8] Logical storage XML-Dokumente werden in DB2-Tabellen gespeichert, wobei sie eine oder mehrere XML-Datentypen haben können. DB2 speichert und manipuliert XML-Daten in geparster Form, wie es die hierarchische Struktur des XML-Dokuments vorschreibt. Dabei benutzt es Bäume und Knoten, um die XML-Daten zu speichern. DB2 behält die gesamte interne Struktur des XML-Dokuments bei und wandelt Tag-Names und andere Informationen in Integer-Values um. Dadurch verspricht sich IBM mehr Query-Performance und weniger Speicherplatzbedarf. Außerdem splittet DB2 Teile des Dokuments automatisch auf, damit diese Teile über mehrere Datenbank-Seiten verwendet werden können. [9] Indexing DB2 ermöglichte eine schnelle Indexierung für XML-Daten über normales SQLDDL (Create Index). Zusätzlich kann der Benutzer bzw. die Benutzerin ein XMLPattern (ähnlich zu XPath) definieren, das die wichtigen Informationen aus dem XML-Dokument definiert. Dabei ist zu beachten, dass eine Zeile aus der Tabelle eventuell in mehreren XMLIndex-Einträgen resultiert, da XML-Dokumente mehrere gleichnamige Knoten enthalten können. DB2 verwendet Volltext-Indizes, um die Such-Performance zu erhöhen. [9] Query Language Abfragen könnnen bei DB2 Viper mittels SQL oder XQuery gestellt werden. DB2 hat 2 Language-Parser, einen für XQuery und einen für SQL (sh. Abbildung 4). Beide erzeugen jedoch eine gemeinsame, sprachunabhängige, interne Repräsentation der Query, was beiden Abfragesprachen die gleichen Optimierungstechniken ermöglicht. DB2 ermöglicht es außerdem XML-Files nach gewissen Schemata zu validieren. [9] Mit DB2 Viper wurden 15 SQL/XML-Funktionen implementiert, die Suchen innerhalb von XML-Dokumenten, Konvertierung von relationalen Daten in XML, Konvertierung von XML-Daten zu relationalen Daten etc. ermöglichen. Die Wichtigsten sind: • xmlexists - Resultate werden nach einem bestimmten XML-Element-Wert eingeschränkt. • xmlquery – Mit XMLQuery wird eine Query auf eine XML-Datei durchgeführt. • xmltable – erzeugt aus XML-Daten eine relationale Tabelle. • xmlelement – erzeugt aus relationalen Daten ein XML-Dokument • xmlparse – parst Elemente aus einem XML-File, um ein Update oder Delete durchführen zu können 11 XML databases 4 Martin Hölbling Anwendungsbeispiel – XML in DB2 Viper: Im Anwendungsbeispiel wird ein Autofeedbacksystem mit DB2 Viper vorgestellt. Das Autofeedbacksystem speichert Fehlermeldungen eines Autos als XML-Datei und überträgt diese Daten per UMTS/EDGE an den Hersteller/Vertriebspartner. Dieser verfügt über eine Kundendatenbank, die das Auto einem Kunden zuordnen kann. Aus Komplexitätsgründen wird angenommen, dass ein Kunde nur ein Auto besitzt. 4.1 Datenbankschema: Das Datenbankschema besteht aus einer relationalen Datenbank mit den Tabellen Fahrzeug und Kunde. create table fahrzeug( id int primary key not null, modellname varchar(30), variante int, error_reports xml) create table kunde( id name fahrzeug_id kontaktinfos int primary key not null, varchar(50), int, xml) Weiters werden XML-Dateien zu Autos und Kunden abgelegt: <error_report> <id>512.18b</id> <bezeichnung>ABS ausgefallen</bezeichnung> <kunde_id>43</client_id> </error_report> <kontakt> <adresse> <strasse>Sponheimerstr. 2/1/11</strasse> <plz>9020</plz> <ort>Klagenfurt</ort> <land>Österreich</land> </adresse> <telefon> <privat>+436606278464</privat> </telefon> <email>[email protected]</email> <email>[email protected]</email> </kontakt> 12 XML databases 4.2 4.2.1 Martin Hölbling Abfragen Selektion der Fahrer des Fahrzeugs mit der ID 144 Eine Selektion der Kunden, die ein Fahrzeug mit der ID 144 fahren, werden mit einem normalen SQL-Statement ausgelesen. Select name, contactinfo from kunde where fahrzeug_id=144 Als Ergebnis werden relationale und XML-Daten geliefert: Martin Hölbling <kontakt> <adresse> <strasse>Sponheimerstr. 2/1/11</strasse> <plz>9020</plz> <ort>Klagenfurt</ort> <land>Österreich</land> </adresse> <telefon> <privat>+436606278464</privat> </telefon> <email>[email protected]</email> <email>[email protected]</email> </kontakt> 4.2.2 Restriktion aufgrund eines XML-Werts Selektion der Fahrer der Fahrzeuge mit der ID 144 und dem error_report mit der id 512.18b select k.name, k.kontaktinfo from kunde k, fahrzeug f where k.fahrzeug_id=144 and f.id=144 and xmlexists(‘$c/error_report[id=”51218”]’ passing f.error_reports as “c”) Mit der xmlexists-Anweisung werden alle Fahrer des Fahrzeugs 144 bei denen die Fehlermeldungen mit der ID “512.18b” (ABS ausgefallen) aufgetreten ist, selektiert. Diese könnten zum Beispiel über eine Rückrufaktion verständigt werden. Als Ergebnis wird Folgendes geliefert: Martin Hölbling <kontakt> <adresse> <strasse>Sponheimerstr. 2/1/11</strasse> <plz>9020</plz> <ort>Klagenfurt</ort> <land>Österreich</land> 13 XML databases Martin Hölbling </adresse> <telefon> <privat>+436606278464</privat> </telefon> <email>[email protected]</email> <email>[email protected]</email> </kontakt> 4.2.3 XMLQuery Selektion aller E-Mail Adressen von allen Fahrern des Fahrzeugs mit der ID 144. Mit der xmlquery-Anweisung werden XML-Daten selektiert. Das passing Attribut gibt den Pfad der XML-Datei in die Pfadvariable $c. select xmlquery(‘$c/kontakt/email’ passing kontaktinfos as $c) from clients where fahrzeug_id=144 Als Ergebnis werden XML-Tags in folgender Form geliefert: … <email>[email protected]</email> … <email>[email protected]</email> … Das Problem hierbei ist, dass auch leere Tags ausgegeben werden, werden bei einem Kunden keine E-Mail-Adresse existiert. Um dies zu verhindern wird genau eine E-Mail-Adresse von allen Fahrern mit einem bestimmten Fahrzeug auslesen, sofern eine E-Mail-Adresse existiert. select xmlquery(‘$c/kontakt/email[1]’ passing kontaktinfos as $c) from clients where fahrzeug_id=144 and xmlexists(‘$c/kontakt/email’ passing kontaktinfos as “c”) Mit dem email[1]-Attribut wird genau eine E-Mail-Adresse selektiert. Mit der xmlexists-Anweisung wird überprüft, ob eine 4.2.4 Umwandlung von XML in SQL-Datentypen XML-Elemente können in „traditionelle“ SQL-Datentypen umgewandelt werden. Das folgende Statement liefert alle E-Mail-Adressen der Kunden aus Österreich und speichert diese in einer Tabelle: select k.name, i.email from kunde k, xmltable(‘$c/kontakt’ passing kontaktinfos as “c” columns i.email varchar(50) path ‘email[1]’) as i where xmlexists(‘$c/kontakt/email’ passing kontaktinfos as “c”) 14 XML databases Martin Hölbling Mit der xmltable-Anweisung werden XML-Tags in Tabellenform gebracht. „columns“ gibt an wie die Spalten bezeichnet werden und welches Attribut („email[1]) in die Spalte geschrieben werden. Als Ergebnis wird folgende Tabelle zurückgegeben: Name Martin Hölbling Doris Weidner … 4.2.5 email [email protected] [email protected] Joins von XML und nicht-XML Daten: Das Statement gibt eine Liste aller Fahrer der Fahrzeuge 144 mit der Fehlermeldung 512.18b aus. select k.name from kunde k, fahrzeug f xmltable(‚$c/error_report’ passing f.error_reports as „c“ columns e.kunden_id int path ‘kunde_id’) as e where f.id=144 and xmlexists(‚$c/error_report[id=”512.18b”]’ passing f.error_reports as “c”) and k.id=e.kunden_id 4.2.6 Umwandlung von relationalen Daten in XML: Das folgende Statement erzeugt eine XML-Datei aller Fahrzeuge. Mit der xmlelement-Anweisung werden XML-Tags mit Namen und Attributen erzeugt. select xmlelement (name „fahrzeug“, xmlelement (name „id“, id), xmlelement (name „modell“, modellname)) from fahrzeug Folgende XML-Datei wird erzeugt: … <fahrzeug> <id>144</id> <modell>C4</modell> </fahrzeug> 4.2.7 Update-Statement: Das Statement fügt dem Kunden mit der ID 43 eine weitere E-Mail-Adresse hinzu. Mit der xmlparse-Anweisung wird die Stelle geparst, in der die E-Mail-Adresse eingefügt werden soll. update kunde set kontaktinfo=( xmlparse(document ‚<email>[email protected]</email>)) where id = 43 4.2.8 SQL/XML-Statements in Java : 15 XML databases Martin Hölbling DB2 Viper mit SQL/XML lässt sich auf übliche Form in Java-Code verwenden. String selectStmt = null; String query = null; ResultSet rs = null; Connection conn = null; String zipCode = "9020"; try { . . . // erstelle eine Verbindung zur Datenbank (JDBC) . . . query = "select name from kunde where xmlexists(" + "'$c/Client/adresse[plz=$x]' "+ "passing clients.kontaktinfo AS \"c\", cast(? as char(5)) as \"x\" )"; //führe Anfrage durch selectStmt = conn.prepareStatement(query); selectStmt.setString(1, zipCode); // execute the statement rs = selectStmt.executeQuery(); // durchlaufe das ResultSet . . . // schließe die Verbindung . . . } catch (Exception e) { . . . 5 } Zusammenfassung Durch den enormen Zuwachs von Media-Files in Unternehmen und der signifikanten Bedeutung von XML im Webbereich, ist der Bedarf nach XML-Datenbanken gestiegen, um diese XML-Daten (wie z.B. Metadaten) persistent zu halten und zu verwalten. Vielfach existieren nicht nur reine XML-Daten, sondern auch relationale Datenbanken, die mit XML-Daten zusammengeführt werden sollen. Da XML tiefe Strukturen hat und unter Umständen nicht eindeutig und vollständig ist, geschieht die Zusammenführung mit relationalen Datenbanken nicht problemlos. Die Integration kann in XML-enabled Databases, mittels XML-Shredding oder in Nativen XML-Datenbanken durchgeführt werden. Während XML-enabled databases und XML-Shredding die XML-Daten in relationale Daten umwandeln, können Native XML-Datenbanken XML-Daten unabhängig von den relationalen Daten aufbewahren. Der Vorteil von Nativen XML-Datenbanken liegt vor allem in der Performanz. Zudem kann die ursprüngliche XML-Datei vollständig rekonstruiert werden, was bei XML-enabled Databases und XML-Shredding nicht unbedingt gewährleistet ist. 16 XML databases Martin Hölbling Literaturverzeichnis: [1] Digital Asset Management – Using A Native XML Database Implementation. S. Natu, J. Mendonca. 2003. CITC4´03 [2] XMP. Adobe. 2005. aus : http://www.adobe.com/xmp/ [3] Relational Databases for Querying XML Documents: Limitations and Opportunities. J. Shanmugasundaram, K. Tufte, G. He, C. Zhang, D. DeWitt, J. Naughton. 1999. Proceedings of the 25th VLDB Conference. [4] A Comprehensive Solution to the XML-to-Relational Mapping Problem. S. Amer-Yahia, F. Du, J. Freire. 2004. WIDM´04. [5] XML and Databases. R. Bourret. 1999 – 2005. aus: http://www.rpbourret.com/xml/XMLAndDatabases.htm [6] XML-Databaseproducts. R. Bourret. 2000 – 2005. aus: http://www.rpbourret.com/xml/XMLDatabaseProds.htm [7] ShreX: Managing XML Documents in Relational Databases. F. Du, S. Amer-Yahia, J. Freire. 2004 [8] DB2 Viper Specification. IBM. 2006. aus: http://www306.ibm.com/software/data/db2/udb/viper/xml.html [9] XML Guide – DB2 Viper. IBM 2006. S. 10 - 75 17
