Ausarbeitung - Fakultät für Mathematik und Informatik
Werbung
Strukturbasierte Abbildung von XML auf relationale Datenbanken Marcel Keller Matrikel 46134 [email protected] Juni 2004 Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken und Informationssysteme Prof. Dr. K. Küspert, T. Müller, K. Stolze Sommersemester 2004 Seminar „XML und Datenbanken“ Inhaltsverzeichnis 1. Einführung ......................................................................................................... 3 1.1. Motivation ................................................................................................... 3 1.2. Art der zu speichernden XML-Dokumente ................................................ 4 2. Automatisches Mapping .................................................................................... 4 2.1. Allgemeine Eigenschaften .......................................................................... 4 2.2. Prinzipielle Abbildungsvorschrift nach Klettke und Meyer ....................... 5 2.3. Abbildungsvorschrift nach Ronald Bourret ................................................ 7 2.4. Probleme beim automatischen Mapping .................................................... 8 2.5. Weitere Merkmale der Speicherung mit automatischem Mapping .......... 10 3. Benutzerdefiniertes Mapping .......................................................................... 11 3.1. Allgemeine Eigenschaften ........................................................................ 11 3.2. Mappingvorschrift nach Ronald Bourret .................................................. 12 3.3. Weitere Merkmale der Speicherung mit ................................................... 14 benutzerdefiniertem Mapping .......................................................................... 14 4. Was machen die Hersteller? ............................................................................ 16 4.1. Oracle 9i .................................................................................................... 16 4.2. IBM DB2 UDB ......................................................................................... 17 5. Zusammenfassung ........................................................................................... 21 6. Quellenverzeichnis .......................................................................................... 22 7. Anhang ............................................................................................................ 23 A) Relationenschema ...................................................................................... 23 2 1. Einführung 1.1. Motivation Der weit verbreitete Einsatz von XML als temporäres Austauschformat führt zur Frage wie man die in XML enthaltenen Daten dauerhaft und effizient speichern kann. Für die Datenhaltung bieten sich relationale und objektorientierte Datenbanken, Dateisysteme und reine XML-Datenbanken an. Da relationale und objektrelationale Datenbanken in der Wirtschaft eine breite Verwendung finden, kommt diesen die größte Bedeutung zu. Viele Hersteller von relationalen Datenbanken unterstützen schon die Speicherung von XMLDaten in ihren Systemen. Im Allgemeinen werden dabei drei verschiedene Ansätze verfolgt. Der erste Ansatz, genannt textbasierte Abbildung, speichert das gesamte XML-Dokument als CLOB (Character Large Object) in einer Tabellenspalte. Dieser Ansatz ist zwar einfach zu realisieren, bietet jedoch nur eingeschränkte Funktionalität und Effizienz, wenn auf Teile des Dokumentes zugegriffen werden soll. Ein zweiter Ansatz wandelt das XML-Dokument in eine Graphenstruktur um und speichert zum Beispiel jeden Elementtyp mit einer eindeutigen Elementtyp-ID, einer zugehörigen Dokument-ID, einem Verweis auf den Vorgänger und die Elementordnung ab. Zwar ist das Dokument später wieder aus der Datenbank rekonstruierbar, jedoch ist dies aufgrund der hohen Anzahl von Joins nur sehr langsam möglich und auch das Beantworten von Anfragen ist nicht effizient. Diese Seminararbeit befasst sich mit der Erläuterung von verschiedenen Abbildungsverfahren, die zur strukturbasierten Speicherung von XML-Daten in relationale Datenbanken entwickelt wurden. Bei diesem dritten Ansatz werden die XML-Dokumente zunächst strukturell analysiert und dann die im XML-Dokument enthaltenen Daten in relationaler Form in einer oder mehreren Tabellen abgespeichert. Dieser Ansatz ist weitaus mächtiger als die Anderen, da im Gegensatz zu Ansatz 1 jetzt die komplette Funktionalität des Datenbanksystems zum tragen kommt und weiterhin im Vergleich zu Ansatz 2 viel effizientere Anfragen und Rekonstruktionen möglich sind. Also ist prinzipiell der dritte Ansatz vorzuziehen. Die Umsetzung in der Praxis ist jedoch nicht immer unproblematisch. Für die Anwendung eigenen sich nur bestimmte XML-Dokumente, die im nächsten Abschnitt genauer beschrieben werden sollen. 3 1.2. Art der zu speichernden XML-Dokumente Da sich das relationale Modell wesentlich vom hierarchischen Modell von XML unterscheidet ist es manchmal schwer bis unmöglich eine geeignete Abbildung zu finden. Um bei der Wahl des Ansatzes eine Richtlinie zu haben, wurden XML-Dokumente anhand ihrer Struktur charakterisiert. Dabei gibt es im wesentlichen zwei Arten, die datenzentrierten Dokumente, die sehr strukturiert und regulär sind, und die dokumentzentrierten Dokumente die einen unstrukturierten Aufbau aufweisen und unregulär sind. Die dritte Art der semistrukturierten Dokumente umfasst alle Dokumente, die sowohl datenzentrierte als auch dokumentzentrierte Anteile besitzen. Für die strukturbasierte Abbildung eignen sich besonders datenzentrierte XML-Dokumente, da bei diesen eine leichte, unproblematische Abbildung in das relationale Schema möglich ist. Solche strukturierten XML-Dokumente finden wir besonders dort, wo XML als Medium zum Datenaustausch zwischen Systemen fungiert. Beispiele hierfür wären die Übermittlung von Bestellungs-, Rechnungs- und Produktdaten. Nun stellt sich jedoch die Frage, was heißt “strukturiert“, das heißt welche Merkmale muss ein XML-Dokument aufweisen damit es als datenzentriert klassifiziert werden kann. Bei datenzentrierten XML-Dokumenten treten selten gemischte Inhalte bei Elementen (Mixed Content, ANY) auf und auch die Reihenfolge von Geschwisterelementen spielt in der Regel keine Rolle. Weiterhin lassen sich hierarchische Strukturen ohne Rekursivität leicht auf mehrere Tabellen mit entsprechenden Fremdschlüsselbeziehungen abbilden. Im nächsten Abschnitt werden nun Verfahren vorgestellt, die auf der automatischen Abbildung von XML-Daten auf relationale Strukturen basieren. 2. Automatisches Mapping 2.1. Allgemeine Eigenschaften Bei dieser ersten Methode der Abbildung werden die XML-Strukturen von einem allgemeingültigen, vom konkreten Schema unabhängigen Konzept umgesetzt. Es muss natürlich eine DTD oder ein XML-Schema vorhanden sein, um daraus die Strukturinformationen zu gewinnen, die für die Umsetzung ins relationale Schema benötigt werden. 4 Eine sogenannte Defaultmappingvorschrift spezifiziert, welche Strukturen auf welche relationale Strukturen abgebildet werden. Es ist zu beachten, dass diese Vorschrift für sämtliche zu speichernde XML-Dokumente gilt, da in dieser kein Bezug auf bestimmte Elementtypen genommen wird, sondern nur Strukturen, wie zum Beispiel Elementtyp mit Subelementen, von Bedeutung sind. Wie man leicht erkennt, richtet sich bei dieser Variante der Datenbankentwurf nach der Struktur der XML-Dokumente. Das bedeutet, ändert man das XML-Schema, dann muss auch das Datenbankschema angepasst werden. Nachteil dieser Methode ist, dass immer nur das gesamte XML-Dokument abgebildet werden kann. In der Praxis ist es aber oft nötig, dass Teile aus XML-Dokumenten in zum Beispiel schon bestehende Datenbanken gespeichert werden. Für diesen Zweck wird im Kapitel 3 eine weitaus flexiblere Methode der strukturbasierten Abbildung vorgestellt. 2.2. Prinzipielle Abbildungsvorschrift nach Klettke und Meyer In Klettke und Meyer [1] wird ein prinzipielles Verfahren zur Abbildung von XML-Daten auf objektrelationale Datenbanken vorgestellt. Für die Abbildung auf relationale Datenbanken, die ja keine Objekttypen unterstützen, wurde von mir eine Anpassung vorgenommen. Die Grundidee dieses Verfahrens ist, dass man Elemente und Attribute von XML-Dokumenten mit Hilfe der zugehörigen DTD oder eines XML-Schemas aufgrund von Strukturmerkmalen einteilen kann. Begonnen wird mit der Abbildung von Elementen: 1) Ist der Elementtyp das Wurzelelement mit mehreren verschiedenen Subelementtypen, dann wird eine Relation angelegt, die den Namen des Wurzelelementtyps erhält und eine eindeutige ID als Attribut, um die Zuordnung zum XML-Dokument zu gewährleisten. Besteht das Wurzelelement in der nächst tieferen Ebene aus nur einem Subelementtyp, dann kann man den Namen des Wurzelementtyps der Datenbank zuordnen und den Subelementtyp als Namen einer Relation mit eindeutiger ID verwenden. 2) Ein normaler Elementtyp wird auf ein Attribut einer Relation abgebildet. 3) Besteht ein Elementtyp aus einer Sequenz von Elementtypen, dann werden diese auf Attribute einer Relation abgebildet. 5 4) Besteht ein Elementtyp aus einer Alternative von Elementtypen, dann werden diese auf Attribute einer Relation abgebildet. 5) Elementtyp mit dem Quantifizierer ? wird auf ein Attribut einer Relation abgebildet, wobei dieses Attribut NULL annehmen kann 6) Elementtyp mit dem Quantifizierer + oder * wird auf eine eigene Relation abgebildet mit einer eindeutigen ID. Die Relation erhält außerdem ein Attribut das den Namen des Elementtyps entspricht. 7) Komplex strukturierte (geschachtelte) Elementtypen werden in eine eigene Relation ausgegliedert, wobei die Subelementtypen den Attributen der Relation entsprechen. Abbildung von Attributen: 1) XML-Attribut wird auf ein Attribut einer Relation abgebildet. 2) Ist das Attribut #IMPLIED, dann sind NULLs erlaubt. 3) Ist das Attribut #REQUIRED, dann sind NULLs nicht erlaubt. 4) Bei Attribut mit Defaultwert, muss ein Defaultwert bei der „Create Table-Anweisung“ angegeben werden. Nun folgt an einem Beispiel die Anwendung der Vorschrift: Wie oben schon erwähnt, wird eine DTD benötigt, aus der die Strukturinformationen auslesen werden können. Eine solche Beispiel-DTD ist wie folgt aufgebaut: <!ELEMENT hotel (hotelname, kategorie, adresse, telefon+, fax)> <!ATTLIST hotel id ID #REQUIRED> <!ELEMENT hotelname (#PCDATA)> <!ELEMENT kategorie (#PCDATA)> <!ELEMENT adresse (plz, ort, strasse, nummer)> <!ELEMENT plz (#PCDATA)> <!ELEMENT ort (#PCDATA)> <!ELEMENT strasse (#PCDATA)> <!ELEMENT nummer (#PCDATA)> <!ELEMENT telefon (#PCDATA)> <!ELEMENT fax (#PCDATA)> 6 Der abgeleitete Datenbankentwurf würde dann folgendermaßen aussehen: CREATE TABLE Hotel ( ID INTEGER PRIMARY KEY, Hotelname VARCHAR(50) NOT NULL, Kategorie INTEGER NOT NULL, Adresse VARCHAR(5) NOT NULL, Telefon VARCHAR(5) NOT NULL, Fax VARCHAR(30) NOT NULL ); CREATE TABLE Telefon ( ID INTEGER NOT NULL, Telefon VARCHAR(30) NOT NULL, PRIMARY KEY (ID,Telefon), FOREIGN KEY (ID) references Hotel (ID) ); CREATE TABLE Adresse ( ID INTEGER PRIMARY KEY, Plz INTEGER NOT NULL, Ort VARCHAR(50) NOT NULL, Strasse VARCHAR(30) NOT NULL, Nummer INTEGER NOT NULL, FOREIGN KEY (ID) references Hotel (ID) ); Das daraus abgeleitete Relationenschema befindet sich im Anhang A. 2.3. Abbildungsvorschrift nach Ronald Bourret Eine weitere Abbildungsvorschrift wurde von Ronald Bourret entwickelt, die im diesem Abschnitt kurz vorgestellt wird. 7 Ein wesentlicher Unterschied zu der Vorschrift von Klettke und Meyer ist, dass die PCDATA-Komponente eines Elementes mit gemischten Inhalt in eine separate Tabelle ausgegliedert wird. 1) Erzeuge für jeden Elementtyp mit Subelementen beziehungsweise gemischtem Inhalt eine Tabelle mit einer Primärschlüsselspalte 2) Erzeuge für jeden Elementtyp mit gemischtem Inhalt eine separate Tabelle zur Speicherung der PCDATA-Komponente. Diese Tabelle wird mit der Tabelle des Elementtyps über deren Primärschlüssel verknüpft. 3) Erzeuge in der Tabelle eines Elementtyps für jedes einwertige Attribut des Elementtyps und jeden nur einmal vorkommenden Subelementtyp, der nur PCDATA enthält eine Spalte. Wenn der Subelementtyp beziehungsweise das Attribut optional sind, muss die Spalte den Wert Null annehmen können. 4) Erzeuge für jedes mehrwertige Attribut eines Elementtyps und für jeden Subelementtyp, der ein Mehrfachvorkommen erlaubt, jedoch nur PCDATA enthält, eine separate Tabelle zur Speicherung der Werte. Diese Tabelle wird mit der Tabelle des Elementtyps über deren Primärschlüssel verknüpft. 5) Verknüpfe für jeden Subelementtyp mit Subelementen oder gemischtem Inhalt die Tabelle des Elementtyps mit der Tabelle des Subelements über den Primärschlüssel des Elementtyps. 2.4. Probleme beim automatischen Mapping 2.4.1. Einführung Mit der oben vorgestellten prinzipiellen Abbildungsvorschrift nach Klettke und Meyer sind gewisse Probleme verbunden, die nicht immer zu lösen sind. Diese Probleme werden erst ersichtlich, wenn bei datenzentrierten Dokumenten der Fall eintritt, dass gemischter Inhalt und Rekursionen auftreten oder die Elementordnung von Bedeutung ist. Da bei der Abbildungsvorschrift nur Elemente und Attribute abgebildet werden, kann das ursprüngliche Dokument nicht exakt wiederhergestellt werden, da zum Beispiel Kommentare, Processing Instructions, XML-Prolog und die DTD an sich zwangsweise verloren gehen. 8 2.4.2. Abbildung von Alternativen Bei Abbildung von Alternativen werden alle Elementtypen in der Alternative auf Attributnamen einer Relation abgebildet. Da nur ein Elementtyp aus der Alternative im zugehörigen XML-Dokument auftritt, man aber im voraus nicht erkennen kann welcher Elementtyp auftreten wird und weiterhin sich die Elementtypen je nach Dokument unterscheiden können, müssen alle Elementtypen der Alternative abgebildet werden. Dies führt natürlich zu dünn besetzten Relationen, was eher unerwünscht ist. Um dieses Problem zu umgehen, kann man alle Elementtypen in einer Alternative in eine jeweils eigene Relation ausgliedern. 2.4.3. Abbildung von rekursiven Datendefinition In XML-Dokumenten können keine Rekursionen auftreten, da diese Dokumente endlich sind. In DTDs oder einem XML-Schema können allerdings Rekursionen auftreten, die nicht exakt auf relationale Datenbanken abgebildet werden können. Rekursionen müssen in separate Tabellen aufgespaltet werden und Primär- beziehungsweise Fremdschlüsselbeziehungen verwendet werden, um die Rekursion zu verdeutlichen. Diese Problematik soll anhand einer Beispiel-DTD verdeutlicht werden: .... <!ELEMENT ort (name, einwohnerzahl, ausflugsziel*)> <!ELEMENT ausflugsziel (ort, entfernung, beschreibung)> .... In diesem Beispiel enthält die Beschreibung von Orten neben anderen Informationen auch Vorschläge für ein Ausflugsziel. In diesen Ausflugszielen sind nun wiederum Orte vorhanden Diese DTD enthält also eine Rekursion. Ein Beispiel für ein entsprechendes Relationenschema könnte wie folgt aussehen: Ort (ID, Name, Einwohnerzahl, Ausflugsziel) Ausflugziel (ID, OrtID, Entfernung, Beschreibung) 9 Wie man erkennt, wurde die Rekursion in separate Tabellen aufgespaltet. Die unterstrichenen Attribute sind Primärschlüssel der jeweiligen Relation. Dabei verweist OrtID von Ausflugsziel als Fremdschlüssel auf ID von Ort. Nun müsste theoretisch auch noch Ausflugziel von Ort auf ID von Ausflugsziel verweisen, was aber nicht möglich ist, da ID nur ein Teil des Primärschlüssels ist und somit die verlangte Eindeutigkeit aufweist. 2.4.4. Abbildung von Elementordnungen Wenn man Inhalte von XML-Dokumenten auf Datenbanken abbildet, bleibt die Dokumentordnung nicht zwingend erhalten, beziehungsweise sie ist bei der Rekonstruktion der Dokumente aus der Datenbank nicht wieder herstellbar. In vielen Anwendungen ist diese Ordnung jedoch von großer Bedeutung. Ein Beispiel hierfür wären wissenschaftliche Publikationen, bei denen die Reihenfolge der Kapitel nicht vernachlässigt werden darf. Ist es also notwendig, die Ordnung der Elemente zu erhalten, dann muss ein zusätzliches Datenbankattribut eingeführt werden, welches sicherstellt, dass die Ordnung gespeichert wird. 2.4.5. Abbildung von Mixed Content Types Ein weiterer Problemfall ist die Speicherung von Mixed Content Types, da hier Texte und andere Elemente gemischt auftreten können. Die Speicherung von solchen Typen ist sehr umständlich, da bei Texten auch die Elementordnung von Bedeutung ist. Auch Anfragen an solche Relationen sind nicht effizient durchführbar. Da bei datenzentrierten Dokumenten Mixed Content Types nur selten auftreten, kann das Problem bei der Speicherung vernachlässigt werden. 2.5. Weitere Merkmale der Speicherung mit automatischem Mapping Bis jetzt wurden Verfahren für das automatische Mapping aufgezeigt und Problemfälle angesprochen. Nun werden die wichtigsten Merkmale des automatischen Mappings noch einmal kurz zusammengetragen. 10 Für die strukturbasierte Abbildung von XML-Daten auf relationale Datenbanken mit automatischem Mapping ist immer eine Schemabeschreibung, also eine DTD oder ein XMLSchema, erforderlich. Ist nur eine DTD vorhanden, dann ist vom Anwender noch eine Anpassung der Datenbankattributtypen notwendig, da in einer DTD keine Typisierung von Elementen möglich ist. Datenbankanfragen sind mit SQL möglich, dazu muss jedoch verständlicherweise die Struktur der Datenbank bekannt sein. Hier kann der Anwender nun die Vielzahl von Funktionalitäten des Datenbanksystems nutzen und Anfragen werden durch das Datenbankmanagementsystem optimiert. Für Anfragen mit XPath oder XQuery muss der Prozess der Abbildung von XML auf die Datenbank protokolliert werden. In einem weiteren Schritt muss nun die Datenbankanfrage automatisch aus der XML-Anfrage generiert und das Ergebnis der Datenbankanfrage wieder in das XMLFormat umgewandelt werden. Während der Prozess der Ausgabe von SQL-Anfragen in Form von XML schon in vielen Datenbanksystemen umgesetzt ist, so ist die Protokollierung und die Umformung von XML-Anfragen in SQL-Statements relativ schwierig zu bewerkstelligen. Die Effizienz von Anfragen ist im Vergleich zu den in Punkt 1.2. erwähnten anderen Verfahren relativ hoch. Bei dieser Art der Abbildung wird oft ein großes Schema erzeugt und wie schon angesprochen, kann der unerwünschte Fall einer schwach gefüllten Datenbank auftreten. Elementhierarchien können zwar mit entsprechenden Schlüsselbeziehungen abgebildet werden, doch im Allgemeinen erlauben objektorientierte oder objektrelationale Datenbanksysteme eine natürlichere Abbildung. Die Speicherung von Elementen vom Typ ANY ist überhaupt nicht möglich, da diese Elemente beliebigen Inhalt besitzen können. 3. Benutzerdefiniertes Mapping 3.1. Allgemeine Eigenschaften Bisher konnte die Art der Speicherung nicht beeinflusst werden, das bedeutet, der Nutzer konnte nicht steuern, welche XML-Strukturen auf welche Datenbankstrukturen abgebildet werden sollen. Weiterhin war es bisher nicht möglich nur Teile eines XML-Dokumentes abzubilden. 11 Benutzerdefinierte Abbildungen lassen den Nutzer nun steuern welche Speicherungsstruktur zum Einsatz kommt. In einer vom Nutzer erstellten Mappingvorschrift wird spezifiziert welche Informationen aus dem XML-Dokument auf welche Datenbankstruktur abgebildet werden. Somit ist es möglich zu entscheiden, ob das XML-Dokument vollständig abgebildet wird oder nur ein Ausschnitt des XML-Dokumentes von Bedeutung ist. Benutzerdefiniertes Mapping erweist sich also als eine sehr flexible Methode. Man kann außerdem das XML-Schema und das Datenbankschema unabhängig voneinander entwerfen und auch das Speichern von XML-Daten in schon bestehende Datenbanken stellt kein Problem dar. Zwar gibt es Utilities, die einen bei der Erstellung der Mappingvorschrift unterstützen, jedoch erfordert dies dennoch einen großen manuellen Aufwand. Für das Verfahren wird auch der Begriff „Schreddern“ oder „Shredding“ verwendet, denn man kann die Mappingvorschrift so wählen, das vom Originaldokument bei der Speicherung nicht mehr viel zu erkennen ist. In solchen Fällen sind die XML-Dokumente nicht wiederherstellbar. Auch Anfragen die sich an XML-Dokumente stellen ließen, sind nicht immer mehr an die Datenbank zu stellen. Dies sind Probleme, die auftreten, wenn nur unvollständig gespeichert wird oder die Art der Speicherung gegenüber dem Originaldokument stark verändert wurde. Die Verantwortung für eine korrekte Abbildung liegt hier beim Anwender. 3.2. Mappingvorschrift nach Ronald Bourret Ein mögliche Form einer Mapping-Vorschrift ist von Ronald Bourret entwickelt wurden. In diesem konkreten Fall basiert die Mappingvorschrift auf XML-Syntax, wobei aber auch XLST als Basis verwendet werden kann. Im folgenden Beispiel ist ein XML-Dokument angegeben, aus dem bestimmte Informationen mit Hilfe einer Mappingvorschrift in eine relationale Datenbank abgebildet werden sollen. 12 <Hotel url= "www.hotel-huebner.de“> <HotelID>H0001</HotelID> <Name>Hotel Huebner </Name> <Adresse> <PLZ>18119</PLZ> <Ort>Warnemünde</Ort> <Strasse>Seestrasse</Strasse> <Nr>12</Nr> </Adresse> <Preise> <Einzelzimmer>198</Einzelzimmer> </Preise> </Hotel> Das XML-Dokument enthält Informationen über ein Hotel, wie das Attribut url und die Elementtypen HotelID, Name, Adresse und Preise. Der Elementtyp Adresse enthält die Subelementtypen PLZ, Ort, Strasse und Nr und der Elementtyp Preise enthält den Subelementtyp Einzelzimmer. Nun folgt die von Ronald Bourret entwickelte MappingVorschrift. <ClassMap> <ElementType Name="Hotel“/> <ToClassTable> <Table Name="Preise"> </ToClassTable> <PropertyMap> <Attribute Name="url"/> <ToColumn> <Column Name="Hotel_url"> </ToColumn> </PropertyMap> <PropertyMap> <ElementType Name="hotelname"/> <ToColumn> <Column Name="Name"/> </ToColumn> </PropertyMap> <PropertyMap> <ElementType Name="Einzelzimmer"/> <ToColumn> <Column Name="Einzelzimmer"/> </ToColumn> </PropertyMap> ..... </ClassMap> 13 Im ersten Teil dieser Vorschrift wird das Wurzelelement Hotel der Datenbanktabelle Preise zugeordnet. Hinter den einzelnen PropertyMap-Tags stehen Zuordnungen von Attributen und Elementtypen zu Datenbankattributen der Tabelle Preise. Im Einzelnen wird das Attribut url dem Datenbankattribut Hotel_url, der Elementtyp hotelname dem Datenbankattribut Name und der Elementtyp Einzelzimmer dem Datenbankattribut Einzelzimmer zugeordnet. An dieser Mappingvorschrift wird deutlich, dass in jeder Mappingvorschrift die Darstellung von Informationen dem Datenbankschema zugeordnet werden muss. Aus diesem Fakt ergibt sich, dass die Datenbanken entweder schon existieren müssen oder die Datenbank aus der Mappingvorschrift erstellt werden muss. 3.3. Weitere Merkmale der Speicherung mit benutzerdefiniertem Mapping Benutzerdefiniertes Mapping hat viele Vorteile gegenüber automatischem Mapping und besitzt aufgrund der großen Variabilität und Flexibilität der Methode eine größere Bedeutung in der Praxis. Wie auch beim automatischen Mapping ist für die Umsetzung eine Schemabeschreibung erforderlich. Die Dokumentrekonstruktion ist aus in Punkt 3.1. genannten Gründen meist nicht möglich. Anfragen an die Datenbank sind mit SQL möglich, jedoch muss auch hier die Struktur der Datenbank bekannt sein. Um XML-Anfragen zu stellen, muss der Abbildungsprozess in Metadaten protokolliert werden. Dafür ist es nötig, dass alle für die Anfrage relevanten Daten gespeichert sind. Die Anfragemöglichkeiten mit XML-Anfragesprachen sind also nur sehr eingeschränkt. Die Dokumentordnung kann nur über ein zusätzliches Attribut gewährleistet werden. Ein weiteres Merkmal ist, dass durch die flexible Abbildung der Zusammenhang zwischen Attributen und Elementen verloren gehen kann. Bei Änderungen des XML-Schemas oder des Datenbankschemas muss außerdem die Mappingvorschrift angepasst werden. Dies zeigt auch deutlich, dass die Verantwortung für die korrekte Abbildung beim Anwender, also beim Entwerfer der Mappingvorschrift liegt. Auch bei dieser Abbildungsmethode werden der Prolog des XML-Dokumentes, Processing Instructions, Kommentare und das Schema des XML-Dokumentes nicht gespeichert. 14 Probleme können auch bei der Typisierung der Datenbankattribute entstehen, da in einer DTD keine Typisierung zur Verfügung steht. Ist zum Beispiel ein Datenbankattribut vom Typ DATE vorhanden, so muss das Element oder Attribut im XML-Dokument auch den syntaktischen Anforderungen von DATE entsprechen. Gegebenfalls ist eine Konvertierung in das richtige Format notwendig. Ein weiteres Problem, das bis jetzt noch nicht betrachtet wurde, zeigt sich, wenn man überlegt, wie Zeichenketten behandelt werden, denn Entities und CDATA-Abschnitte müssten ja aufgelöst werden, um korrekt gespeichert zu werden. 15 4. Was machen die Hersteller? 4.1. Oracle 9i Oracle bietet nur für die objektrelationale Speicherung automatisches Mapping an. Bennutzerdefiniertes Mapping ist nicht möglich. Für die relationale Speicherung von XMLDaten bietet Oracle das Programm XSU (XML SQL Utility) an, welche Ergebnisse von SQLAnfragen in XML ausgeben kann und Daten aus XML-Dokumenten in Tabellen einliest. Das auf Java basierende XSU wird über ein Java Application Interface angesprochen. Für den Import von XML-Daten muss der Name der bestehenden Tabelle und der Name des abzubildenden XML-Dokumentes angegeben werden. XSU erzeugt dann automatisch SQLInsert-Befehle. Die Verwendbarkeit des Programms ist durch strikte Strukturanforderungen an das XML-Dokument und die bestehende Tabelle stark eingeschränkt. So müssen XMLSchema und relationales Schema exakt übereinstimmen. Ist dies nicht der Fall, dann muss entweder das relationale Schema angepasst werden oder das XML-Dokument mit XLST transformiert werden. Diese Strukturanforderungen sollen an folgendem Beispiel erklärt werden. <ROWSET> <ROW num="1"> <PersNr>234<PersNr> <Name>Müller<Name> <Gehalt>4000<Gehalt> </ROW> <ROW num="2"> ... </ROW> ... </ROWSET> XSU erzeugt beim Auslesen aus der Datenbank das eben vorgestellte XML-Dokument mit ROWSET als Wurzelelement und für jede gelesene Zeile des Anfragergebnisses ein ROWElement in dem die einzelnen Datenbankattribute auf Elemente des XML-Dokumentes abgebildet wurden. Die Struktur beim Import von XML-Dokumenten muss genau der Struktur entsprechen, die beim Auslesen aus der Datenbank entsteht. 16 4.2. IBM DB2 UDB IBM bietet in DB2 benutzerdefiniertes Mapping an. Dazu wurde ab Version 7.1 mit dem Erweiterungsmechanismus von DB2 der XML-Extender eingeführt, der verschiedene Zugriffs- und Speicherungsformen für XML zur Verfügung stellt. Nun folgt eine Grafik die diese Formen verdeutlichen soll. Die erste Speicherungsform ist XML-Collection, welche die Abbildung auf relationale Strukturen ermöglicht. XML-Column bietet einen XML-Datentyp an, welcher die Speicherung von ganzen XML-Dokumenten oder Fragmenten in einer Spalte unterstützt. Diese zweite Speicherungsform wird in dieser Arbeit jedoch nicht weiter beleuchtet, denn sie ist Thema der textbasierten Abbildung. Die genaue Form der Speicherung wird in einer sogenannten DAD-Datei (Document Access Definition) beschrieben. Diese DAD-Datei ist nichts anderes als die schon oft erwähnte Mappingvorschrift, also ein XML-formatiertes Dokument, welches auf dem Client gespeichert ist. DTDs werden beim automatischen Mapping mit DB2 in einem DTD-Repository abgelegt und auch die DAD-Datei wird in einer sogenannten XML-Usage-Table gespeichert. Um automatisches Mapping durchführen zu können, muss zunächst eine XML-Collection aktiviert werden. 17 Bei dieser Aktivierung mit der Methode dxxEnableCollection() muss der Datenbankname, Name der Collection, DAD-Datei und der Tablespace angegeben werden. Die Prozedur dxxInsertXML() bekommt als Eingabeparameter nun den Namen der aktivierten XMLCollection und die XML-Datei und führt anhand der Abbildungsregeln in der DAD-Datei das Shredding aus. Es gibt auch eine Möglichkeit das Aktivieren der XML-Collection zu umgehen, indem die Prozedur dxxShredXML() für das Shredding benutzt wird. Als Eingabeparameter erhält diese Prozedur die DAD-Datei und die XML-Datei. Verwende ich XML-Collection dann muss dies in der DAD-Datei explizit kenntlich gemacht werden. Weiterhin stehen 2 Abbildungsmethoden zur Verfügung. Die SQL-Zuordnung, welche allerdings nur für den Export von XML-Daten aus der Datenbank gewählt werden kann, und die RDB_node-Zuordnung. Da das Augenmerk dieser Arbeit auf dem Import von XML-Daten in relationale Datenbanken liegt, können wir die erste Methode vernachlässigen. 18 Ein Beispiel für eine DAD-Datei: <?xml version="1.0"?> <!DOCTYPE DAD SYSTEM "dxx_install_verz/samples/db2xml/dtd/dad.dtd"> <DAD> <dtdid>dxx_install_verz/samples/dad/getstart.dtd</dtdid> <validation>YES</validation> <Xcollection> <prolog>?xml version="1.0"?</prolog><doctype>! DOCTYPE Order SYSTEM "dxx_install_verz/samples/db2xml/dtd/getstart.dtd"</doctype> <root_node> <element_node name="Order"> <RDB_node> <table name="order_tab" key="order_key"/> <table name="part_tab" key="part_key order_key"/> <condition>order_tab.order_key = part_tab.order_key</condition> </RDB_node> <attribute_node name="key"> <RDB_node> <table name="order_tab"/> <column name="order_key" type="integer"/> </RDB_node> </attribute_node> <element_node name="Customer"> <element_node name="Name"> <text_node> <RDB_node> <table name="order_tab"/> <column name="customer_name" type="varchar(30)"/> </RDB_node> </text_node> </element_node> <element_node name="Email"> <text_node> <RDB_node> <table name="order_tab"/> <column name="email_name" type="varchar(30)"/> </RDB_node> </text_node> </element_node> </element_node> ................ .......... </element_node> </root_node>. </Xcollection> </DAD> 19 Die DAD-Datei beginnt ganz normal mit dem Prolog und der Angabe einer externen DTD die die DAD-Datei beschreibt. Weiterhin wird eine DTD angebeben für die die Beschreibung in der Xcollection gilt. Zur Beschreibung der Dokumentenaufbaus des XML-Dokumentes, bedient man sich einem sogenannten node-Set, welches aus root_node-, element_node-, attribut_node-, text_node- und RDB_node-Elementen besteht. Ein RDB-node beinhaltet wiederum table-, column- und condition-Elemente Unter dem root-node steht das Wurzelelement des XML-Dokumentes, danach folgt in dem ersten RDB-node die Angabe der beteiligten Tabellen und die Angabe der Primärschlüssel. In der Condition wird die Verbundbedingung zwischen den Tabellen angegeben, also die Fremdschlüsselbeziehungen. Ein Column-Element anzulegen ist hier nicht möglich und auch nicht sinnvoll. Nun wird der attribut_node key einer Tabelle und einer Spalte zugeordnet. Optional könnte man auch hier eine condition angeben, aber nur gegen ein konstantes Literal um bestimmte Attributinhalte auszuschließen. Die weiteren Abbildungen in diesem Beispiel sind selbsterklärend. Wichtig zu wissen ist außerdem, dass die Verschachtelung der nodeElemente den hierarchischen Beziehungen des XML-Dokumentes entsprechen muss. Die nächste Grafik zeigt die zu dieser DAD-Datei passende DTD und das daraus entstehende Relationenschema . <!ELEMENT Order (Customer, Part+)> <!ATTLIST Order order_key ID #REQUIRED> <!ELEMENT Customer (Name, Email)> <!ELEMENT Name (#PCDATA)> <!ELEMENT Email (#PCDATA)> <!ELEMENT Part (Key, Quantity, ExtendedPrice,Tax,Shipment)> <!ATTLIST Part color CDATA #IMPLIED> <!ELEMENT Key (#PCDATA)> <!ELEMENT Quantity (#PCDATA)> <!ELEMENT ExtendedPrice (#PCDATA)> <!ELEMENT Tax (#PCDATA)> <!ELEMENT Shipment (ShipDate, ShipMode)> <!ELEMENT ShipDate (#PCDATA)> <!ELEMENT ShipMode (#PCDATA)> 20 order_tab order_key customer_name cuctomer_email 1 Müller mü[email protected] part_tab part_key order_key price tax quantity color date mode 1 1 100 16 1 black 20.05.2004 1 5. Zusammenfassung Die XML-Speicherung ist eine wichtige Anforderung an Datenbanksysteme besonders im eCommerce geworden. Die Hersteller von Datenbanksystemen erweitern aufgrund dieser neuen Anforderungen ständig die XML-Funktionalität ihrer Datenbanksysteme. Speicherung von XML-Dokumenten in relationalen Datenbanksystemen ist nur für bestimmte einfach strukturierte XML-Dokumente zu empfehlen. Je komplexer die Hierarchie von XMLDokumenten ist, umso größer werden die Relationenschemas. Daraus folgt aber, dass die Effizienz von Anfragen sinkt. Für XML-Dokumente mit einer komplexen Struktur sind also andere, auf XML zugeschnittene Datenbanksysteme, besser geeignet. Der Firma Oracle bietet zwar vielfältige Möglichkeiten für die objektrelationale Speicherung von XML an, zur relationalen Speicherung steht aber nur das Tool XSU zur Verfügung, welches in seiner Funktionalität sehr eingeschränkt ist. IBM bietet unter Verwendung des DB2-XML-Extenders verschiedene Möglichkeiten um XML zu speichern und Daten aus relationalen Datenbanken in XML darzustellen. Eine gute Lösung für die strukturbasierte Speicherung von XML ist IBM mit der XcollectionSpeicherungsform gelungen. Da benutzerdefiniertes Mapping viele Vorteile gegenüber automatischem Mapping bietet, ist diese flexible Methode nur zu empfehlen. 21 6. Quellenverzeichnis [1] Meike Klettke und Holger Meyer: „XML und Datenbanken – Konzepte, Sprachen und Systeme“; dpunkt.verlag; 2002 [2] Harald Schöning: „XML und Datenbanken“; Carl Hanser Verlag; München/Wien; 2003 [3] Harald Schöning Vortrag: „XML-Speicherung in Datenbanksystemen“ ; http://www.xml-und-datenbanken.de/tutorials/nod02-sys.pdf [4] Informatik-Spektrum vom 24.Dezember 2001 Hauptbeitrag von Jost Enderle: „XML in relationalen Datenbanken“ ; http://www.informatik.uni-ulm.de/dbis/01/dbis/downloads/Ende01.pdf [5] Oliver Braun, Studienarbeit: „XML und relationale Datenbanken – Abbildungsverfahren und deren Implementierung“; http://i10www.ira.uka.de/arbeiten/xml-sql/Ausarbeitung.pdf [6] Dr. C. Türker, Vorlesung WS 200372004: „ XML und Datenbanken“ ; http://www-dbs.inf.ethz.ch/~xml/WS_03/folien/05AbbildungXMLaufDBMS.pdf 22 7. Anhang A) Relationenschema Hotel ll ID Hotelname Kategorie Fax 1 Hotel Hübner 1 0381-543444 ID PLZ Ort Strasse Nummer 1 18119 Warnemünde Seestraße 12 Adresse Telefon ID Telefon 1 0381-54340 1 0381-540 23
