Nutzung eines relationalen DBS zur Speicherung und Recherche von XML-Daten

Inhalt

1 Einleitung
1.1 Ausgangssituation
1.2 Zielsetzung

2 Recherchemöglichkeiten durch das Dateisystem.

3 Speicherung der XML-Daten
3.1 Dateiorientiert
3.1.1 Aufgaben einer XML-Datenbank
3.1.2 Zu speichernde Daten.
3.1.3 Externe vs. interne Datenspeicherung
3.1.4 Entwurf eines Datenbankschemas
3.2 Metaorientiert
3.2.1 Mangel der dateiorientierten Speicherung
3.2.2 Zu speichernde Informationen
3.2.3 Entwurf eines Datenbankschemas
3.3 Volltextorientiert
3.3.1 Mangel der metaorientierten Speicherung
3.3.2 Was soll physisch indiziert werden?
3.3.3 Was soll inhaltlich indiziert werden?
3.3.4 Worttrenner
3.3.5 Entwurf eines Datenbankschemas
3.4 XML-Orientiert
3.4.1 Mangel der volltextorientierten Speicherung
3.4.2 Dokumenttypabhängiges Design
3.4.3 Dokumenttypunabhängiges Design
3.5 Zusammenfassung

4 Wahl des RDBMS

5 Datenimport
5.1 Klassendesign
5.2 Methode zum Einfügen einer XML-Datei in die Datenbank
5.3 DOM
5.3.1 Laden einer XML-Datei als DOM
5.3.2 Einfügen eines XML-DOMs in eine Datenbank.
5.4 Größenabhängigkeit

6 Datenabfrage
6.1 Problemstellung
6.1.1 Datenhaltung
6.1.2 Ziel der Abfrage
6.1.3 Abfragesprachen
6.1.4 Probleme bei Wahl des Abfrageverfahrens
6.1.5 Lösungsmöglichkeiten
6.2 Problemlösung
6.2.1 XQuery-Parser
6.2.2 SQL-Generator
6.3 Abfragegeschwindigkeit

7 Darstellung der Abfrageergebnisse
7.1 Trefferliste
7.2 Visualisierung der XML-Daten
7.2.1 Source-Code
7.2.2 Baumstruktur
7.2.3 Stylesheets

8 Datenexport
8.1 XML-Datei
8.2 XML-DOM
8.2.1 Speicherung externer Referenzen
8.2.2 Speicherung des DOM
8.2.3 DOM neu erzeugen

9 Beispielapplikation

A Literaturverzeichnis

B Verzeichnis der Tabellen

C Verzeichnis der Abbildungen

D Anlagenverzeichnis

E Verzeichnis der Abkürzungen.

F Thesen

1 Einleitung

1.1 Ausgangssituation

Am 6. Oktober 2000 verabschiedete das World Wide Web Consortium (W3C) die Empfehlung zu XML (E x tensible M arkup L anguage), dem „universellen Format für strukturierte Dokumente und Daten im Web“ [9]. XML ist eine einfache und sehr streng strukturierte Auszeichnungssprache. Mit ihr lassen sich in Dokumenten Inhalt, Struktur und Layout klar trennen. Die Strukturdefinition erfolgt relativ einfach durch eine DTD (Document Type Definition) oder ein XML-Schema^[1]. So sind beliebig komplexe Strukturen umsetzbar. Die Umsetzung der Strukturen in XML-Instanzen lassen sich durch XML-Parser prüfen (Validierung als wellformed XML und gegen eine DTD bzw. XML-Schema).

Das W3C hat rund um XML eine Reihe von Empfehlungen veröffentlicht. Es exi- stiert bereits eine Vielzahl von zum Teil kostenlosen Tools, die diese Empfehlungen umsetzen. Durch die W3C-Empfehlungen XPath^[2], XPointer^[3] und XLink^[4] zur Adressie- rung, Selektion und Verlinkung von XML-Daten lassen sich Inhalte beliebig rekombinieren. Infolge der W3C-Empfehlung XSL^[5] (Extensible Stylesheet Language) läßt sich den in XML umgesetzten Strukturen ein beliebiges Layout zuweisen. Mit Hilfe der Transformationsskriptsprache XSLT^[6] (Extensible Stylesheet Language Transformations) als Bestandteil von XSL und deren Implementierung in (zum Teil frei verfügbaren) XSLT-Prozessoren oder der Implementierung des DOM^[7] (Document Object Model) lassen sich XML-Dateien in jedes beliebige Format überführen.

Abbildung 1 XML-Transformation

Abbildung in dieser Leseprobe nicht enthalten

Damit eignet sich XML zur medienneutralen Datenhaltung, als Austauschformat und zur Mehrfachverwendung von Inhalten, was XML besonders für Inhaltsanbieter wie Verlage interessant macht. Ziel vieler Verlage ist es, aus einem gemeinsamen Datenpool annähernd „per Knopfdruck“ verschiedene Publikationen für verschiedene Medien zu produzieren. XML und seine weiteren Empfehlungen stellen dafür eine gute Basis dar.

Abbildung 2 Publikationen aus XML

Abbildung in dieser Leseprobe nicht enthalten

XML selbst kann diese Aufgaben jedoch nicht erfüllen. Es handelt sich um kein Hard- oder Softwareprodukt, sondern lediglich um eine Formatdefinition für Textda- teien ohne jegliche Funktionalität. Die Anwendung von XML ist immer an spezifische Softwareprodukte gebunden. Durch XML lassen sich Dokumente sehr gut strukturieren. Es gibt jedoch keinen Konsistenzmechanismus wie beispielsweise in Datenbanken. Mit einem XML-Parser kann zwar im Nachgang die Einhaltung der Struktur geprüft wer- den, es kann aber im Gegensatz zu Datenbanken nicht konsistente Zustände einer XML-

Instanz geben. XML bietet sehr gute Auszeichnungsmöglichkeiten, die auch sehr gezielte Recherchemöglichkeiten eröffnen, kann selbst als Formatdefinition aber keine Recherche realisieren.

Je nach Umfang der Publikationen kann die Anzahl der XML-Dateien sehr groß werden. Beispielsweise hatte der Verlag moderne industrie (mi-Verlag) Anfang September 2001 1600 XML-Dateien mit einer Gesamtgröße von 90 MB, wobei die größte Datei über 15 MB groß ist. Hinzu kommen noch 1000 Abbildungen und 16 000 chemische Formeln, die als externe Grafikdateien abgelegt sind und in den XML- Dateien referenziert werden. Der Verlag geht davon aus, daß bis Ende des Jahres der XML-Datenbestand auf 2800 XML-Dateien anwachsen wird. Moderne Dateisysteme können solche Datenmengen verwalten. Ein Mensch hat aber dann schon große Pro- bleme, den inhaltlichen Überblick zu behalten. An den Daten müssen ständig Aktualisierungen und teilweise Korrekturen vorgenommen werden. Hinzu kommt, daß aus diesem einen Datenpool verschiedene Publikationen erstellt werden. So hat der mi- Verlag bis September 2001 aus obigen XML-Daten zehn CDs, zwei Print-Grundwerke und 60 Print-Ergänzungslieferungen produziert. Bis zum Ende des Jahres sind ca. 30 CDs, vier Print-Grundwerke und ca. 100 Print-Ergänzungslieferungen geplant. Diese Aufgaben sind allein durch Nutzung der Möglichkeiten, die das Dateisystem bietet, nur sehr schwer zu lösen.

Ein Datenbankmanagementsystem (DBMS) könnte durch die vorhandenen Recher- chemöglichkeiten zum gezielten und schnellen Auffinden von Daten beitragen.

Auf dem Markt existieren bereits einige Datenbanksysteme (DBS) speziell zur Spei- cherung von XML-Daten, bzw. etablierte DBMS verfügen über spezielle XML- Erweiterungen. Diese DBS werden im weiteren als XML-Datenbank bezeichnet. Einige Vertreter sind:

Tabelle 1 Beispiele für XML-Datenbanken

Abbildung in dieser Leseprobe nicht enthalten

Die kommerziellen XML-Datenbanken sind zum Teil sehr teuer. Die Lizenz hängt dabei von verschiedenen Faktoren ab, so daß hier keine konkreten Preise angegeben werden können. Für die meisten Anbieter liegen die Lizenzpreise im sechsstelligen DM- Bereich. Diese Produkte erfüllen immer ganz bestimmte Aufgaben. Nicht alle sind für die spezifischen Belange skalierbar. Bei der Nutzung vorhandener Systeme begibt sich der Anwender immer in eine Abhängigkeit zum Hersteller des Produktes. Die Untersu- chung einzelnen XML-Datenbanken soll nicht Gegenstand dieser Arbeit sein. Im Internet kann man dazu einige Ausführungen finden [17].

1.2 Zielsetzung

Das Ziel dieser Arbeit liegt in:

- der Schaffung von Alternativen für Inhaltsanbieter zu den bereits existierenden kommerziellen XML-Datenbanken,
- der theoretischen Betrachtung von Lösungsansätzen für XML-Datenbanken,
- der realen Implementation einer XML-Datenbank und
- dem praktischen Nachweis, daß relationale Datenbankmanagementsysteme (RDBMS) zur Speicherung von XML-Daten geeignet sind.

Dabei sind folgende Grundprobleme zu lösen:

1. Speicherung der XML-Daten ,
2. Abfrage der Daten und
3. Darstellung der Ergebnisse

Darüber hinaus soll die mit dieser Arbeit zu schaffende XML-Datenbank als Kern für XML-Applikationen wie beispielsweise Content Management Systeme, XML-Kon- vertierungstools, XML-Server, XML-Produktionsumgebungen, XML-Erweiterung für DBS dienen können.

Betrachtet man eine Datenbankapplikation aus Sicht der Entwicklung einer externen Applikation, die auf ein bestehendes DBMS zugreift, so lassen sich in Anlehnung an die 3-Schichten-Architektur eines Datenbankentwurfes zur Datenunabhängigkeit (externes Schema, konzeptionelles Schema, internes Schema) drei Implementierungsschichten benennen:

1. die externe Applikation (Applikationsschicht), die die Schnittstelle zum Benutzer darstellt, die Geschäftslogik implementiert und die Kommunikation mit dem DBMS über einen Datenbanktreiber und eine Abfragesprache realisiert,
2. die logische Datenhaltung in Form eines Datenbankschemas (logische Schicht) als Bindeglied zwischen externer Applikation und DBMS und
3. die physische Datenhaltung durch das DBMS (physische Schicht). Dieses Schichtenmodell ist in Abbildung 3 grafisch dargestellt.

Abbildung 3 Drei Implementationsschichten einer Datenbankapplikation

Abbildung in dieser Leseprobe nicht enthalten

Die durch diese Arbeit zu implementierende XML-Datenbank soll ein existierendes RDBMS nutzen. In Anlehnung an obiges Modell setzt die Implementierung somit an der logischen Schicht und der Applikationsschicht an. Die physische Schicht ist durch das zuverwendende RDBMS vorgegeben. Wird die Zielstellung wie oben beschrieben verfolgt, einen Kern für XML-Applikationen zu schaffen, so muß die Implementation des Kerns wiederum diesem Schichtmodell entsprechen, damit eine beliebige externe

XML-Applikation auf die XML-Datenbank zugreifen kann. So ergibt sich wie in Abbildung 4 grafisch dargestellt folgende Implementierungsstruktur:

Abbildung 4 Anwendung des Schichtmodells für die XML-Datenbank

Abbildung in dieser Leseprobe nicht enthalten

Zusätzlich zur XML-Datenbank ist eine Beispielapplikation zu schaffen, die die in dieser Arbeit beschriebenen Funktionen nutzt und eine für Inhaltsanbieter geeignete Anwendung zur Speicherung und Recherche von XML-Daten zur Verfügung stellt.

2 Recherchemöglichkeiten durch das Dateisystem

Werden XML-Dateien allein durch das Dateisystem verwaltet, stehen einem Nutzer im Allgemeinen folgenden Informationen zur Verfügung, die er zum Auffinden seiner Daten nutzen kann:

1. Dateiname,
2. Dateigröße,
3. Dateidatum,
4. Dateiattribute und
5. Volltext

Nach den ersten vier Kriterien lassen moderne Betriebssystem relativ gute Such- möglichkeiten zu. Diese sind jedoch in der Praxis aufgrund der fehlenden Aussagekraft selten ausreichend. Die Möglichkeit der Volltextsuche ist sehr stark vom verwendeten Betriebssystem abhängig. In den meisten Fällen dauert diese jedoch aufgrund fehlender Indexdateien und damit zwangsläufiger sequentieller Suche relativ lange. In einigen Betriebssystemen (z.B.: MS Windows 9x oder MS Windows NT) sind logische Opera- toren und Wildcards bei der Volltextsuche nur über Zusatztools, die im Standardlieferumfang nicht enthalten sind, möglich. Häufig werden Dateien in ver- schiedenen Verzeichnissen und auf verschiedenen Hosts abgelegt. Das erschwert mitunter die Suche nach bestimmten Dateien.

Gerade die inhaltliche Strukturierungsmöglichkeit von XML bietet vielfältige Such- möglichkeiten, die durch das Dateisystem überhaupt nicht genutzt werden können.

Abbildung 5 Dateianzeige unter Windows NT

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Dateianzeige unter Linux

Abbildung in dieser Leseprobe nicht enthalten

3 Speicherung der XML-Daten

Die Aufgabe besteht darin, XML-Daten in einem RDBMS recherchierbar zu spei- chern. Die logische Datenablage in relationalen DBMS erfolgt in Tabellen. In Abhängigkeit des inhaltlichen Umfanges der Recherchierbarkeit der Daten lassen sich verschiedene Ansätze für ein konzeptionelles Datenbankschema formulieren:

1. dateiorientierter Ansatz,
2. metaorientierter Ansatz,
3. volltextorientierter Ansatz und
4. XML-orientierter Ansatz.

3.1 Dateiorientiert

3.1.1 Aufgaben einer XML-Datenbank

Ein DBMS im Allgemeinen hat sehr viele Aufgaben zu lösen. Mit Bezug auf die Aufgabenstellung dieser Arbeit soll auf die beiden Hauptaufgaben beschränkt werden. Die XML-Datenbank soll es ermöglichen, XML-Daten zu speichern und für den Nutzer einfach und schnell wieder aufzufinden. Dabei muß die XML-Datenbank mindestens das leisten, was auch mit Hilfe des Betriebssystems möglich ist.

3.1.2 Zu speichernde Daten

Es müssen daher mindestens die Daten zur Recherche bereitgestellt werden, die auch das Betriebssystem anbietet (Abschnitt 2). Zur Entwicklung einer Applikation zur Spei- cherung und Recherche von XML-Daten nach Dateiname, Dateigröße, Dateidatum und Dateiattributen ist nicht unbedingt ein RDBMS erforderlich. Diese Aufgabe läßt sich auch relativ einfach auf Dateiebene realisieren, d.h. in ein oder mehreren Dateien wer- den die für die Recherche notwendigen Informationen gespeichert, die dann von einer Applikation verwaltet werden.

Soll dafür jedoch ein RDBMS genutzt werden, besteht das Datenbankschema aus einer Tabelle mit Attributen für Dateiname, Dateigröße, Dateidatum und Dateiattributen sowie einem Attribut für die Datei selbst. Das kann ein Verweis auf das Dateisystem sein mit, je nach verwendetem Dateisystem, Informationen über den Host, das Laufwerk

und das Verzeichnis. Alternativ kann die XML-Datei direkt im RDBMS abgelegt wer- den. Viele RDBMS bieten entsprechende Datentypen in Form von Binary Large Object (BLOB) oder Character Large Object (CLOB) an.

Das Speichern der Dateiattribute ist rein akademisch. Zur Recherche über XML- Dateien haben sie für den Nutzer kaum eine Bedeutung. Die Art der Dateiattribute hängt sehr stark vom verwendeten Dateisystem ab. In den weiteren Betrachtungen sollen die Dateiattribute nicht mehr berücksichtigt werden.

3.1.3 Externe vs. interne Datenspeicherung

Externe Datenspeicherung bedeutet, daß die XML-Dateien im Dateisystem abgelegt werden. Im Datenbanksystem gibt es lediglich einen Verweis auf die Datei. Im Gegen- satz dazu wird bei der internen Datenspeicherung die XML-Datei direkt im DBS abgelegt.

Die Vorteile der externen Datenspeicherung liegen in der relativ einfachen Imple- mentierbarkeit, der Unabhängigkeit zu DBS, dem geringeren Speicherbedarf für das DBMS und dem schnelleren Dateizugriff. Der Hauptnachteil liegt jedoch in der inhaltli- chen Entkopplung vom DBS. Werden an einer XML-Datei, die in der XML-Datenbank gelistet ist, Änderungen vorgenommen, hat das keinen Einfluß auf die Daten in der Datenbank. Weder das Datum noch die Darteigröße kann aktualisiert werden. Wird die Datei umbenannt, an einem anderen Ort gespeichert oder gar gelöscht, existiert in der Datenbank ein Datensatz, der auf eine nicht existierende XML-Datei verweist.

Zusammenfassung:

Eine Datenkonsistenz kann durch die externe Datenspeicherung nicht gewährleistet werden. Daher kommt für eine XML-Datenbank nur die Speicherung der XML-Daten im DBS in Frage.

3.1.4 Entwurf eines Datenbankschemas

Für die dateiorientierte Datenspeicherung gibt es nur die Datei als einziges Daten- objekt. Dieses Datenobjekt enthält Eigenschaften wie Dateiname, Dateigröße, Dateidatum und den Dateiinhalt. Daraus läßt sich die Relation „file“ ableiten:

file={{name, date, size, content},{name}}

Der Dateiname (Attribut „name“) stellt dabei die kleinste Menge an Attributen, die zur Identifizierung eines Datensatzes notwendig sind, d.h. den Primärschlüssel, dar.

Tabelle 2 Datenbanktabelle "file"

Abbildung in dieser Leseprobe nicht enthalten

Wird das Dateidatum zur Bildung des Primärschlüssels mit hinzugezogen, so läßt sich durch die XML-Datenbank auch eine Versionsverwaltung realisieren. Das ist jedoch nur durch eine interne Speicherung der XML-Dokumente möglich, was sich als weiterer gravierender Vorteil gegenüber der externen Datenspeicherung zeigt. Die Rela- tion „file“ ändert sich durch den erweiterten Primärschlüssel zu:

file = {{name, date, size, content},{name, date}}

Tabelle 3 Datenbanktabelle "file" mit Versionskontrolle

Abbildung in dieser Leseprobe nicht enthalten

3.2 Metaorientiert

3.2.1 Mangel der dateiorientierten Speicherung

Bei der dateiorientierten Speicherung der XML-Daten werden keine inhaltlichen Informationen erfaßt, es sei denn, das verwendete DBMS läßt über BLOBs bzw. CLOBs eine Volltextsuche zu. Diese Funktionalität wird aber nicht von allen DBS angeboten. Ist der Dateiname sprechend, kann über ihn eine inhaltliche Recherche erfolgen. Das dürfte aber im Allgemeinen nicht ausreichend sein.

3.2.2 Zu speichernde Informationen

Beim metaorientierten Ansatz zur Speicherung von XML-Daten, soll das Datenbank- schema um Metadaten erweitert werden, die es ermöglichen, den Inhalt einer XML- Datei zu spezifizieren. Solche Metainformationen könnten beispielsweise der Titel, der Autor oder die inhaltliche Beschreibung einer XML-Datei sein. Weiterhin sollen Schlagwörter mit erfaßt werden können, nach denen dann auch mit logischen Ver- knüpfungen gesucht werden soll.

Auf diese Weise ließe sich dann eine inhaltliche Recherche über den XML-Datenbe- stand durchführen.

Es können noch weitere Metainformationen interessant sein. Hier soll exemplarisch von den oben genannten ausgegangen werden.

3.2.3 Entwurf eines Datenbankschemas

Das datenorientierte Schema soll nicht verworfen, sondern um die oben genannten Informationen erweitert werden.

Zum Datenobjekt Datei kommt jetzt das Datenobjekt Metadaten hinzu. Dieses Datenobjekt enthält Eigenschaften wie Titel, Autor, Beschreibung und Schlagwörter und bezieht sich auf eine Datei. Das Datenobjekt Metadaten enthält die Eigenschaft Schlagwörter. Da es sich im Allgemeinen nicht um ein einziges Schlagwort handelt, muß diese Eigenschaft im relationalen Modell als eigene Relation umgesetzt werden. Weiterhin können verschiedene XML-Dateien dieselben Schlagwörter benutzen, so daß sie in einer n:m-Beziehung zueinander stehen. Prinzipiell trifft das auch auf den Autor zu. Es soll hier aber keine Autorenverwaltung vorgenommen und das Datenbankschema nicht unnötig verkompliziert werden. Natürlich kann die Eigenschaft Autor auch als Referenz in ein Datenobjekt Autor aufgefaßt werden, das hier nicht weiter untersucht werden soll. Es lassen sich somit die drei Relationen „file“, „meta“ und „keyword“ ableiten, wobei die Relationen :„file“ und „meta“ in einer 1:1-Beziehung und „file“ und

„keyword“ in einer n:m-Beziehung zueinander stehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Tabellenbeziehung

Abbildung in dieser Leseprobe nicht enthalten

Diese Relationen lassen sich durch drei Tabellen abbilden:

Tabelle 4 Datenbanktabelle "file" mit Versionskontrolle

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6 Datenbanktabelle "keyword"

Abbildung in dieser Leseprobe nicht enthalten

Es ist zu erkennen, daß zwischen den Tabellen „file“ und „meta“ eine 1:1-Beziehung besteht. Um für eine das Datenbankdesign zur Realisierung einer performanten Abfrage minimal zu halten, lassen sich diese beiden Tabellen auch zusammenfassen. So sind nur noch zwei Relationen erforderlich:

file = {{name, date, size, content, title, author, description},{name, date}}

keyword = {{keyword, filename, date},{keyword, filename, date}}

Abbildung 8 Tabellenbeziehungen nach Zusammenfassen der Relationen „file“ und „meta“

Abbildung in dieser Leseprobe nicht enthalten

Diese zwei Relationen lassen sich durch folgende zwei Tabellen abbilden:

Tabelle 7 Datenbanktabelle "file" mit Versionskontrolle und Metadaten

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

^[1] W3C-Empfehlung „XML Schema“, Status: Recommendation vom 2.5.2001, Quelle: [10]

^[2] W3C-Empfehlung „XPath“, Version 1.0, Status: Recommendation vom 16.11.1999, Quelle: [13]

^[3] W3C-Empfehlung „XPointer“, Version 1.0, Status: Last Call Working Draft vom 8.1.2001, Quelle: [14]

^[4] W3C-Empfehlung „XLink“, Version 1.0, Status: Recommendation vom 27.6.2001, Quelle: [12]

^[5] W3C-Empfehlung „XSL“, Version 1.0, Status: Proposed Recommendation vom 28.8.2001, Quelle: [11]

^[6] W3C-Empfehlung „XSLT“, Version 1.1, Status: Working Draft vom 24.8.2001, Quelle: [15]

^[7] W3C-Empfehlung „DOM Level 1“, Version 1.0, Status: Recommendation vom 1.10.1998, Quelle: [8]