Aufgabenstellung

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

1. Entwurf eines Datenbankschemas zur Speicherung von XML-Daten des Verlages Moderne Industrie 2. Entwicklung eines Algorithmus zum Import von XML-Daten in das DBMS, ·

zur Datenabfrage und ·

zur Präsentation der Abfrageergebnisse ·

3. Implementation des Importalgorithmus für ein DBMS anhand der Beispieldaten 4. Implementation der Datenabfrage für die Beispieldaten 5. Implementation der Ergebnisdarstellung für die Beispieldaten

i

Kurzreferat   

Kurzreferat   

Inhaltsanbieter,  die ihre Daten in XML halten, haben zum Teil eine so große Anzahl  

von  XML-Dateien zu verwalten, daß deren Verwaltung über das Dateisystem nicht  

mehr  zumutbar ist. Die Haltung dieser Daten in einem DBMS könnte durch die dort  

vorhandenen  Recherchemöglichkeiten die Arbeit erleichtern. In der vorliegenden  

Diplomarbeit  wird ein Datenbankschema zur Speicherung von XML-Daten im  

relationalen  Datenmodell entworfen und Algorithmen zum Import, der Abfrage, und  

dem  Export beschrieben. Ergebnis der Arbeit sind Klassen, die von einer Applikation  

zur  Speicherung und Recherche von XML-Daten genutzt werden können.  

ii

Inhalt

Inhalt   

1  Einleitung.  1

1.1  Ausgangssituation  1

1.2  Zielsetzung  4

2  Recherchemöglichkeiten durch das Dateisystem.  7

3  Speicherung der XML-Daten.  10

3.1  Dateiorientiert.  10

3.1.1  Aufgaben einer XML-Datenbank  10

3.1.2  Zu speichernde Daten.  10

3.1.3  Externe vs. interne Datenspeicherung.  11

3.1.4  Entwurf eines Datenbankschemas  11

3.2  Metaorientiert  12

3.2.1  Mangel der dateiorientierten Speicherung  12

3.2.2  Zu speichernde Informationen  13

3.2.3  Entwurf eines Datenbankschemas  13

3.3  Volltextorientiert  17

3.3.1  Mangel der metaorientierten Speicherung  17

3.3.2  Was soll physisch indiziert werden?  17

3.3.3  Was soll inhaltlich indiziert werden?  18

3.3.4  Worttrenner  19

3.3.5  Entwurf eines Datenbankschemas  19

3.4  XML-Orientiert  21

3.4.1  Mangel der volltextorientierten Speicherung.  21

3.4.2  Dokumenttypabhängiges Design  22

3.4.3  Dokumenttypunabhängiges Design  28

3.5  Zusammenfassung  40

4  Wahl des RDBMS  42

5  Datenimport  43

5.1  Klassendesign  43

5.2  Methode zum Einfügen einer XML-Datei in die Datenbank  45

5.3  DOM.  46

5.3.1  Laden einer XML-Datei als DOM  46

5.3.2  Einfügen eines XML-DOMs in eine Datenbank.  46

5.4  Größenabhängigkeit  47

6  Datenabfrage  50

6.1  Problemstellung.  50

6.1.1  Datenhaltung  50

iii

Inhalt

6.1.2  Ziel der Abfrage  50

6.1.3  Abfragesprachen  51

6.1.4  Probleme bei Wahl des Abfrageverfahrens  52

6.1.5  Lösungsmöglichkeiten  52

6.2  Problemlösung.  52

6.2.1  XQuery-Parser  53

6.2.2  SQL-Generator.  55

6.3  Abfragegeschwindigkeit.  60

7  Darstellung der Abfrageergebnisse.  66

7.1  Trefferliste  66

7.2  Visualisierung der XML-Daten.  66

7.2.1  Source-Code.  66

7.2.2  Baumstruktur.  67

7.2.3  Stylesheets.  67

8  Datenexport.  68

8.1  XML-Datei  68

8.2  XML-DOM  68

8.2.1  Speicherung externer Referenzen  68

8.2.2  Speicherung des DOM  69

8.2.3  DOM neu erzeugen  70

9  Beispielapplikation  72

A  Literaturverzeichnis  79

B  Verzeichnis der Tabellen  80

C  Verzeichnis der Abbildungen  81

D  Anlagenverzeichnis.  83

E  Verzeichnis der Abkürzungen.  84

F  Thesen  85

iv

1 Einleitung

1.1 Ausgangssituation

Am 6. Oktober 2000 verabschiedete das World Wide Web Consortium (W3C) die Empfehlung zu XML (Extensible Markup Language), 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 ¹ . So sind beliebig komplexe (Document Type Definition) oder ein XML-Schema

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 existiert bereits eine Vielzahl von zum Teil kostenlosen Tools, die diese Empfehlungen umsetzen. Durch die W3C-Empfehlungen XPath ² , XPointer ³ und XLink ⁴ zur Adressie-

rung, Selektion und Verlinkung von XML-Daten lassen sich Inhalte beliebig ⁵ (Extensible Stylesheet Language) rekombinieren. Infolge der W3C-Empfehlung XSL

läßt sich den in XML umgesetzten Strukturen ein beliebiges Layout zuweisen. Mit Hilfe ⁶ der Transformationsskriptsprache XSLT (Extensible Stylesheet Language

Transformations) als Bestandteil von XSL und deren Implementierung in (zum Teil frei ⁷ (Document verfügbaren) XSLT-Prozessoren oder der Implementierung des DOM Object Model) lassen sich XML-Dateien in jedes beliebige Format überführen.

¹ 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]

1

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.

XML selbst kann diese Aufgaben jedoch nicht erfüllen. Es handelt sich um kein Hard- oder Softwareprodukt, sondern lediglich um eine Formatdefinition für Textdateien 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 werden, es kann aber im Gegensatz zu Datenbanken nicht konsistente Zustände einer XML-

2

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 Probleme, 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 Recherchemöglichkeiten zum gezielten und schnellen Auffinden von Daten beitragen. Auf dem Markt existieren bereits einige Datenbanksysteme (DBS) speziell zur Speicherung von XML-Daten, bzw. etablierte DBMS verfügen über spezielle XML-Erweiterungen. Diese DBS werden im weiteren als XML-Datenbank bezeichnet. Einige Vertreter sind:

3

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 Untersuchung 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 ,

4

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-Konvertierungstools, 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.

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

5

XML-Applikation auf die XML-Datenbank zugreifen kann. So ergibt sich wie in

Abbildung 4 grafisch dargestellt folgende Implementierungsstruktur:

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.

6

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 Suchmö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 verschiedenen Verzeichnissen und auf verschiedenen Hosts abgelegt. Das erschwert mitunter die Suche nach bestimmten Dateien.

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

7

Recherchem  öglichkeiten durch das Dateisystem  

Abbildung  5 Dateianzeige unter Windows NT  

8

Recherchem  öglichkeiten durch das Dateisystem  

Abbildung  6 Dateianzeige unter  Linux

9

3 Speicherung der XML-Daten

Die Aufgabe besteht darin, XML-Daten in einem RDBMS recherchierbar zu speichern. 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 Speicherung 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 werden 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

10

und das Verzeichnis. Alternativ kann die XML-Datei direkt im RDBMS abgelegt werden. 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 Gegensatz dazu wird bei der internen Datenspeicherung die XML-Datei direkt im DBS abgelegt.

Die Vorteile der externen Datenspeicherung liegen in der relativ einfachen Implementierbarkeit, der Unabhängigkeit zu DBS, dem geringeren Speicherbedarf für das DBMS und dem schnelleren Dateizugriff. Der Hauptnachteil liegt jedoch in der inhaltlichen 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 Datenobjekt. 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.

11

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 Relation „file“ ändert sich durch den erweiterten Primärschlüssel zu:

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

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.

12

3.2.2 Zu speichernde Informationen

Beim metaorientierten Ansatz zur Speicherung von XML-Daten, soll das Datenbankschema 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 Verknü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.

file

meta

keyword

13

Diese Relationen lassen sich durch drei Tabellen abbilden:

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

keyword

15

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

Diese zwei Relationen lassen sich durch folgende zwei Tabellen abbilden:

3.3 Volltextorientiert

3.3.1 Mangel der metaorientierten Speicherung

Ein Nachteil in der Erfassung von Metadaten liegt darin, daß diese Daten nicht aus der XML-Datei hervorgehen, sondern manuell zu erfassen sind. Wird eine XML-Datei aktualisiert, werden diese Daten nicht automatisch mit aktualisiert. Werden diese Daten durch den Nutzer nicht gepflegt, kann es vorkommen, daß die Metadaten keinen inhaltlichen Bezug mehr zu den XML-Daten haben.

Es liegt somit nahe, die Recherchierbarkeit nach dem Inhalt der Datei zu gewährleisten, zumal die meisten Dateisysteme ebenfalls eine Volltextsuche erlauben. Wie weiter oben schon erwähnt, bieten einige Datenbanksysteme bei der Ablage von ASCII-Dateien als BLOB bzw. CLOB bereits eine Volltextsuche. Für Datenbanksysteme, die diese Möglichkeit nicht bieten, soll hier eine mögliche Lösung skizziert werden.

3.3.2 Was soll physisch indiziert werden?

Als erstes muß geklärt werden, was indiziert werden soll. Als ein Extrem wäre es möglich, die XML-Datei, die eine ASCII-Datei ist und somit deren Inhalt eine Zeichenkette darstellt, in der Gesamtheit in ein entsprechendes Datenfeld einer Datenbank abzulegen. Der SQL-Standard erlaubt über verschiedene Operatoren, wie „=“ oder „like“ und der Nutzung von Whitespaces sowie logischen Operatoren eine Suche nach beliebigen Textstellen.

17

Die Vorteile bestehen dabei in einem einfachen Datenbankdesign und ·

in der Möglichkeit, nach jeder beliebigen Zeichenkette zu suchen. ·

Die Nachteile sind dabei allerdings,

1. daß sequentiell durch die Dateien gesucht werden muß. Somit steigt die Suchzeit proportional mit der Datenmenge. Bei großen Datenmengen dürfte das Antwortverhalten der Datenbank nicht mehr akzeptabel sein.

2. Die durch die Datenbank und die Hardware zu verwaltende Datenmenge steigt, obwohl sich Teile von Zeichenketten innerhalb von XML-Dateien wiederholen und somit reduziert werden könnten.

Unter diesem Gesichtspunkt läßt sich das andere Extrem darin sehen, daß jedes einzelne Zeichen indiziert wird. Wird beim XML-Dateiinhalt vom ASCII-Zeichensatz (8 Bit) ausgegangen, gäbe es nur 256 Zeichen zu indizieren. Allerdings lassen sich jetzt keine Zeichenketten mehr suchen, sondern lediglich das Vorkommen von bestimmten Zeichen in der Datei. Diese Variante ist somit überhaupt nicht geeignet. Es ist an diesen beiden Extremen zu erkennen, daß nur nach der indizierten Zeichenkette und deren Teilen gesucht werden kann. Je länger diese jedoch wird, um so größer wird der Speicherbedarf. Übersteigt die zu indizierende Zeichenlänge und damit die möglichen Zeichenkombination die Länge von Zeichenkombinationen, nach denen überhaupt gesucht wird - niemand wird nach der kompletten Datei suchen können und auch nicht wollen -, so steigt auch die Suchzeit. Es ist also ein Kompromiß zwischen den beiden Extremen zu finden.

3.3.3 Was soll inhaltlich indiziert werden?

Es muß die längste Kombination von Zeichen bestimmt werden, nach der ein Nutzer suchen wird. Das läßt sich nicht pauschalieren. Der normale Nutzer wird nach mehr als nur einem Zeichen aber weniger als der gesamten Datei suchen. Ziel soll es sein, daß der Nutzer primär nach inhaltlichen und nur sekundär nach syntaktischen Gesichtspunkten XML-Dateien recherchiert. Daher soll es möglich sein, nach Wörtern und nicht nach einer Kombination von Zeichen zu suchen. Wird diese Zielstellung der inhaltlichen Erschließung auf die Zusammensetzung einer XML-Datei (Prolog, Element, Attribute und Text) angewandt, so ist der textuelle Inhalt der Elemente zu indizieren und nicht der gesamte syntaktische Inhalt einer XML-Datei.

18

3.3.4 Worttrenner

Um die Wörter, die Teile einer ASCII-Datei sind, zu indizieren, muß ein Trennsymbol gefunden werden. Im Allgemeinen kann davon ausgegangen werden, daß Whitespaces (Leerzeichen, Tabulatoren, Zeilenumbrüche) und Interpunktionszeichen (Punkt, Komma, Doppelpunkt, usw.) Worttrenner darstellen. Worttrenner können als separate Zeichen mit indiziert oder ignoriert werden. Es empfiehlt sich, diese zu indizieren, damit auch nach ihnen gesucht werden kann.

3.3.5 Entwurf eines Datenbankschemas

Das bisherige Datenbankschema, bestehend aus den Tabellen „file“ und „keyword“, soll um einen Volltextindex erweitert. werden.

Der Volltextindex stellt aus Dateisicht eine sortierte Liste von Wörtern dar, wobei zu jedem Wort eine Liste von Dateien hinterlegt ist, in denen das Wort vorkommt. Durch die Sortierung der Liste nach den Wörtern ist eine binäre Suche innerhalb des Index möglich. Bei der binären Suche steigt die Suchzeit logarithmisch mit der Anzahl der Einträge, so daß sie auch bei sehr großen Datenmengen sehr performant ist. Abbildung 9 Volltextindizierung, Quelle: [4], vgl. S. 18 f.

Im relationalen Datenbankmodell gibt es keine Listen. Obige Indexdatei muß als n:m-Beziehung zwischen den Dateien und den Stichwörtern realisiert werden. Somit kann man folgende Relationen formulieren:

file

keyword

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

19

Diese drei Relationen lassen sich durch folgende drei Tabellen abbilden:

3.4 XML-Orientiert

3.4.1 Mangel der volltextorientierten Speicherung

Die volltextorientierte Speicherung ermöglicht nur die Recherche nach den Textinhalten von Elementen, ohne die Elemente selbst zu berücksichtigen. Die Suche nach einer Zeichenfolge liefert jedes beliebige Vorkommen unabhängig seiner inhaltlichen Zuordnung. So wird beispielsweise bei der Suche nach der Zeichenkette „Müller“ nicht unterschieden, ob es sich um eine Berufsbezeichnung oder einen Namen handelt. Gerade diese inhaltlichen Auszeichnungsmöglichkeiten, die XML so bedeutsam machen, werden durch alle vorherigen Speicherungsansätze nicht berücksichtigt. Weiterhin lassen sich Informationen auch außerhalb von Textelementen sinnvoll ablegen,

21

z.B. als Attribute von Elementen (Parameterwert eines tags) oder durch Sequenzen und Hierarchien von bestimmten Elementen. Auf diese Informationen kann durch die vorherigen Speicherungsansätze nicht zugegriffen werden. Es ist vorstellbar, daß eine XML-Datei nicht ein Textelement enthält, daß alle Elemente auf unterster Ebene leere Elemente sind. Eine Volltextrecherche, wie oben beschrieben, ist in diesem Fall nicht möglich.

Es geht darum, nicht nur den Inhalt von XML-Dateien zu speichern, sondern auch ihre Struktur. Dabei sind zwei Ansätze vorstellbar:

a) ein Design, daß die spezielle Struktur einer konkreten Menge von XML-Dokumenten abbildet und

b) ein Design, daß die allgemeine Struktur von XML-Dokumenten abbildet.

3.4.2 Dokumenttypabhängiges Design

Bei XML-Dokumenten unterscheidet man zwei Arten. Zum einen Dokumente, die keiner speziellen Struktur genügen müssen und zum anderen Dokumente, die einer speziellen, vorher festgelegten Struktur, einem sogenannten Dokumenttyp entsprechen. Dieser Dokumenttyp läßt sich in Form einer DTD oder eines XML-Schemas beschreiben und ist inhaltlich vergleichbar mit dem konzeptionellen Datenbankschema einer Datenbankanwendung.

Für Dokumente, die einer speziellen Struktur genügen, scheint es naheliegend zu sein, diese Struktur (DTD oder XML-Schema) in ein entsprechendes relationales Datenmodell abzubilden.

Als Beispiel soll ein Datenbankschema entwickelt werden, daß XML-Dateien speichert, die jeweils ein gesamtes Buch enthalten und einer DTD genügen. Zur Veranschaulichung wird eine relativ einfache Struktur gewählt: Ein Buch enthält bibliographische Angaben wie ISBN, Verlag, Autor, Titel, Erschei-nungsort und Erscheinungsjahr. Weiterhin besteht ein Buch aus seinem eigentlichen Inhalt, der sich in Kapitel gliedern soll. Jedes Kapitel enthält eine Überschrift und kann beliebig viele Absätze und eventuell weitere Kapitel enthalten. Überschriften und

22

⁸ läßt sich beispielsweise durch Absätze enthalten den eigentlichen Text. Diese Struktur folgende DTD beschreiben:

isbn CDATA #REQUIRED

verlag CDATA #IMPLIED

titel CDATA #REQUIRED

ort CDATA #IMPLIED

jahr CDATA #IMPLIED

>

name CDATA #REQUIRED

vorname CDATA #IMPLIED

>

3.4.2.1 Entwurf eines Datenbankschemas für die Datenbank „Buch“ Diese DTD soll in ein Datenbankschema überführt werden. Das XML-Element „buch“ läßt sich in eine Relation überführen, die als Elemente die XML-Attribute enthält. Aus der DTD geht kein Primärschlüssel direkt hervor. Die International Standard Book Number (ISBN) ist weltweit eindeutig. Darüber hinaus ist sie in der DTD ein „Pflichtattribut“ (#REQUIRED), d.h. jedes Element „buch“ in den XML-Instanzen muß dieses Attribut belegen. Damit eignet sich das XML-Attribut „isbn“ als Schlüsselelement der Relation „buch“.

buch = {{isbn, verlag, titel, ort, jahr}, {isbn}}

Das XML-Element „buch“ enthält die zwei Kindelemente „autor“ und „kapitel“, von denen jedes mindestens einmal vorkommen muß. Da die beiden Kindelemente mehrfach vorkommen können, müssen sie jeweils durch eine eigene Relation abgebildet werden.

Die Relation „autor“ steht laut DTD zur Relation „buch“ in einer 1:n-Beziehung, da ein Buch durch mehrere Verfasser geschrieben sein kann. In einer XML-Datei wird immer nur ein Buch abgebildet. Die XML-Datenbank soll aber mehrere dieser XML-Dateien, also mehrere Bücher speichern. Ein Autor kann aber mehrere Bücher verfaßt haben. Eine n:m-Beziehung entspricht somit eher der realen Anwendungssituation. Ein Primärschlüssel läßt sich auch hier nicht direkt aus der DTD ableiten. Da verschiedene Autoren den selben Namen tragen können und somit Name und Vorname als einzige

⁸ Es handelt sich um eine sehr vereinfachte Strukturbeschreibung eines Buches. Es fehlen sehr wichtige

Inhaltscontainer wie Listen, Tabellen, Abbildungen, Fußnoten, Querverweise, Hervorhebungen, Schlagworte usw.

23

natürliche Elemente der Relation nicht zur Identifizierung eines Datensatzes ausreichen, muß ein künstlicher Schlüssel gebildet werden. Damit läßt sich diese Relation wie folgt formulieren:

autor = {{AutorNr, isbn, name, vorname}, {AutorNr, isbn}}

Das XML-Element „kapitel“ enthält keine XML-Attribute. Es besteht aus den Kindelementen „ueberschrift“, absatz“ und „kapitel“. Das Kindelement „ueberschrift“ muß genau einmal vorkommen, die anderen beiden Kindelemente sind optional und können beliebig oft enthalten sein. Für diese beiden Elemente muß jeweils eine eigene Relation gebildet werden. Das XML-Element „ueberschrift“ soll als Element der Relation „kapitel“ abgebildet werden. Für die Relation „kapitel“ ist in der DTD kein Primärschlüssel erkennbar. Überschriften können sich in Büchern wiederholen, so daß auch dieses Element nicht einen Datensatz identifiziert. Es muß ein künstlicher Schlüssel gebildet werden. Weiterhin muß in dieser Relation die 1:n-Beziehung zur Relation „buch“ abgebildet werden, denn ein Buch enthält ein oder mehrere Kapitel.

kapitel = {{isbn, KapitelNr, ueberschrift}, {KapitelNr}}

Die Relation Absatz enthält als natürliches Element den Text des Absatzes. Dieser kann sich prinzipiell in mehreren Büchern wiederholen (z.B. durch Zitate), so daß auch hier ein künstlicher Schlüssel gebildet werden muß. Da ein Kapitel mehrere Absätze enthalten kann, muß in dieser Relation die 1:n-Beziehung zur Relation „Kapitel“ abgebildet werden.

absatz = {{KapitelNr, AbsatzNr, text}, {AbsatzNr}}

Die Kapitel in Büchern können hierarchisch sein. In der DTD wird daher das XML-Element „kapitel“ rekursive definiert. Diese rekursive Struktur muß durch eine entsprechende Relation nachgebildet werden. Ein Unterkapitel hat genau ein Oberkapitel. Ein Oberkapitel kann mehrere Unterkapitel enthalten. Es besteht zwischen den Ober- und Unterkapiteln, die als einzelne Kapitel bereits in der Relation „kapitel“ abgebildet sind, eine 1:n-Beziehung, die durch die Relation „unterkapitel“ beschrieben werden soll:

unterkapitel = {{OberkapitelNr, UnterkapitelNr}, {UnterkapitelNr}}

Die aus den Relationen resultierende Tabellenbeziehung läßt sich durch Abbildung 11 darstellen.

24

3.4.2.2 Vorteile gegenüber vorherigen Speicheransätzen

Am obigen Beispiel ist zu erkennen, daß die XML-Daten nicht nur nach ihrem Volltext, sondern auch ihrem strukturellen Zusammenhang recherchiert werden können. Es kann beispielsweise ganz gezielt nach einem Autor oder einer Kapitelüberschrift gesucht werden.

Mit obigem Datenbankschema lassen sich die Geschäftsregeln der realen Anwendungssituation relativ gut abbilden. So wird z.B. für die Autoren eine n:m-Beziehung zu Büchern abgebildet oder die ISBN einem Buch eindeutig zugeordnet, was in der Beispiel-DTD nicht definiert ist, aber der Realität eher entspricht. Es können zum Teil schärfere Konsistenzbedingungen eingehalten werden, als es mit einer DTD und einem XML-Parser möglich ist. So läßt sich beispielsweise auf eine Kapitelüberschrift das Not-Null-Constraint legen, was erzwingt, daß sie nicht leer sein darf, d.h. immer einen Inhalt haben muß. Laut DTD muß es zwar das Element „ueberschrift“ geben. Der Inhalt des Elementes könnte aber auch leer sein.

Ist die DTD bzw. das XML-Schema bekannt, können die XML-Dateien prinzipiell bei einem Datenexport reproduziert werden. Es ist nicht zwingend erforderlich, die XML-Datei in der Datenbank als BLOB oder CLOB zu speichern.

25

3.4.2.3 Mangel des dokumenttypabhängiges Designs

Bei der dokumenttypabhängigen Speicherung muß ein Datenbankschema entsprechend des Dokumenttyps vorhanden sein bzw. generiert werden. Dazu muß der Dokumenttyp bekannt sein, d.h. es muß eine DTD oder ein XML-Schema existieren. Laut XML-Spezifikation muß eine XML-Datei aber nicht zwingend eine DTD oder ein XML-Schema enthalten ([18] #sec-documents): „A data object is an XML document if it is well-formed, as defined in this specification. A well-formed XML document may in

addition be valid if it meets certain further constraints.“ Für lediglich wohlgeformte

XML-Dateien (ohne DTD oder XML-Schema) ist diese Form der Speicherung nicht anwendbar.

Dem obigen Beispiel liegt eine relativ einfache DTD zu Grunde. Bei der Abbildung von Publikationen auf XML können die DTDs sehr komplex sein. Die DTDs des mi-Verlages beispielsweise definieren durchschnittlich 107 XML-Elemente und 185 XML-Attribute. Ein Teil der Elemente ist rekursiv definiert. Daraus ist zu erkennen, daß die Datenbankschemata, die aus den DTDs bzw. XML-Schemata zu entwickeln sind, sehr komplex werden können.

Mit dieser Methode lassen sich immer nur XML-Dokumente eines speziellen Dokumenttyps speichern. Für jeden neuen Dokumenttyp muß ein neues Datenbankschema entwickelt werden. Der mi-Verlag beispielsweise hielt im September 2001 XML-Instanzen mit acht verschiedenen Dokumenttypen.

Diese Dokumenttypen müssen nicht konstant sein. Technisch lassen sich an DTDs relativ einfach Änderungen vornehmen. Es können sich im Laufe der Zeit auch Änderungen an den strukturellen Anforderungen der XML-Dokumente ergeben, so daß in einem Verlag sich DTDs durchaus ändern können, was auch eine Änderung des Datenbankschemas nach sich ziehen muß. Der mi-Verlag hat innerhalb eines Jahres an seinen DTDs eine grundlegende und mehrere kleinere Änderungen vorgenommen. Es ist vorstellbar, daß ein Algorithmus gefunden wird, der ein Datenbankschema aus einer DTD oder einem XML-Schema generiert, um obige Probleme zu umgehen. Dann muß das Datenbankschema die Geschäftsregeln, die in XML definiert sind, nachbilden. Diese sind aber bereits eine subjektive Abstraktion der realen Anwendungssituationen mit den eingeschränkten Möglichkeiten, die DTDs bzw. XML-Schematas bieten. Der Vorteil des Konsistenzmechanismus von relationalen Datenbanken kommt dann nicht mehr zum Tragen. Die Möglichkeiten, Geschäftsregeln zu definieren, sind in XML und in Datenbankanwendungen unterschiedlich. Es gibt in XML Konsistenzbedingungen, die in Datenbanken nur schwer nachzubilden sind. Die Konsistenzbedingung „ID“ von XML-Attributen beispielsweise verlangt, daß der Wert des Attributes nur einmal in der XML-Datei vorkommt, egal zu welchem Element das Attribut gehört, kann aber in

26

anderen XML-Dokumenten erneut vorkommen. Das läßt sich nicht einfach mit dem „unique constraint“ von RDBMS abbilden.

Die Rekonstruktion von XML-Dateien, wie sie im vorherigen Abschnitt als Vorteil genannt wurde, ist nur möglich, wenn beim Datenexport die DTD bzw. das XML-Schema bekannt ist. Aus einem Datenbankschema lassen sich XML-Dokumente unterschiedlicher Struktur exportieren. Die obige Beispieldatenbank kann ebenfalls XML-Dateien exportieren, die einer anderen DTD genügen als der eingangs formulierten und dennoch ein Buch abbilden:

Da das Datenbankschema keine XML-Kommentare und Whitespaces berücksichtigt, sind diese beim Export auch nicht wiederherstellbar. Diese Informationen sind im Allgemeinen für XML-Anwendungen irrelevant, können aber für den Anwender eine spezielle Bedeutung haben. Genaugenommen sind mit dieser Speichermethode die XML-Dateien nicht rekonstruierbar.

3.4.2.4 Zusammenfassung

Die dokumenttypabhängige Speicherung ermöglicht zum einen eine sehr gute Recherche über den Datenbestand und zum anderen eine relativ gute Abbildung der Geschäftsregeln realer Anwendungssituationen. Ihr Hauptnachteil ist jedoch die Abhängigkeit vom jeweiligen Dokumenttyp. Dadurch läßt sich kein verallgemeinertes Datenbankschema entwerfen. Es muß für jeden Dokumenttyp eine spezielle Datenbankapplikation entwickelt werden. Damit soll dieses Datenbankdesign in der Arbeit nicht weiter betrachtet werden. Hat ein Anwender jedoch nur eine sehr kleine Anzahl von DTDs bzw. XML-Schemata, die sich zeitlich kaum ändern, könnte der hier dargestellte Ansatz durchaus geeignet sein.

27

3.4.3 Dokumenttypunabhängiges Design

3.4.3.1 Aufbau von XML-Dokumenten

Um XML-Daten unabhängig von ihrem Dokumenttyp zu speichern und dabei eine Recherche auch über die in XML abgebildete Struktur zu ermöglichen, ist es notwendig, die Struktur einer XML-Datei abzubilden.

Gemäß der XML-Spezifikation des W3C ([18]) besteht ein XML-Dokument aus einem Prolog, einem Element und optional einer beliebigen Anzahl von Verschiedenem:

document ::= prolog element Misc*

Unter Verschiedenem werden Kommentare, Processing Instructions (PI) und Whitspaces (Leerzeichen, Tabulator, Zeilenumbruch) verstanden:

Misc ::= Comment | PI | S

Der Prolog besteht optional aus der XML-Deklaration, Verschiedenem und einer Dokumenttypdeklaration:

prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?

Die einzelnen Bestandteile des Prologs sind optional. Sie beschreiben die XML-Datei näher durch Information wie beispielsweise der XML-Version oder dem Dokumenttyp. Sie selbst definieren nicht die inhaltliche Struktur der XML-Datei. Das erfolgt durch den XML-Bestandteil „element“.

Ein Element ist entweder leer oder besteht aus einem Starttag, dem Element Inhalt und dem Endetag:

element ::= EmptyElemTag | STag content ETag

Interessant ist der Inhalt von Elementen. Er kann aus Text oder weiteren Elementen bestehen:

content ::= CharData? ((element | Reference | CDSect | PI | Comment)

CharData?)*

Durch die rekursive Definition von Elementen lassen sich hierarchische Strukturen abbilden. Leere Elementtags (empty element tag) und Starttags enthalten einen Elementnamen und können noch Attribute enthalten:

EmptyElemTag ::= '<' Name (S Attribute)* S? '/>'

^{STag ::= '<' Name (S Attribute)* S? '>'} Ein Attribut besteht aus einem Namen und einem Wert:

Attribute ::= Name Eq AttValue

Ein XML-Dokument enthält somit genau ein Wurzelelement, welches eine beliebige Anzahl von Kindelementen enthalten kann. Die Kindelemente können wiederum Kind-

28

elemente enthalten usw. Die Elemente eines XML-Dokumentes lassen sich somit als Baum darstellen, wobei die Knoten des Baumes die Elemente sind. Neben den optionalen Kindelementen können Elemente auch Attribute und Text enthalten.

Wenn man die syntaktischen Informationen nicht weiter betrachtet, bleiben folgende strukturelle Objekte übrig, aus denen eine XML-Datei bestehen kann: XML-Deklaration ·

Dokumenttypdeklaration ·

Processing Instructions ·

Kommentare ·

Elemente ·

Attribute ·

Text ·

Die ersten beiden Objekte (XML-Deklaration, Dokumenttypdeklaration) kommen maximal einmal zu Beginn des Dokumentes vor. Die übrigen Objekte können sich beliebig oft wiederholen, wobei Elemente schachtelbar sind. Der eigentliche Inhalt sowie die Strukturierung des Inhaltes wird durch die letzten drei Objekte (Elemente, Attribute und Text) realisiert.

Folgendes Beispieldokument soll den Aufbau einer XML-Datei veranschaulichen:

29

Windscherung...">

Erscheinung...

Einflu&szlig; der Windscherung auf ein

Luftfahrzeug

Grundlagen

Beim Start bzw. bei der Landung h&auml;lt das

Luftfahrzeug...

Wie an Abbildung 13 zu erkennen ist, läßt sich ein XML-Dokument als Baum darstellen.

30

3.4.3.2 Entwicklung eines Datenbankschemas

3.4.3.2.1 Bestandteilorientiert

Die sieben Strukturobjekte von XML-Dokumenten (XML-Deklaration, Dokumenttypdeklaration, Processing Instructions, Kommentare, Elemente, Attribute und Text) stellen jeweils ein Datenobjekt dar, das im relationalen Modell abzubilden ist. Ausgehend vom Entity-Relationship-Model lassen sich somit folgende Entities formulieren: file (XML-Datei), XMLDecl (XML-Deklaration), doctypedecl (Dokumenttypdeklaration), PI (Processing Instruction), Comment (Kommentar), Element, Attribute (Attribut), und text. Diese Entitäten und ihre Beziehungen zueinander sind in Abbildung 14 grafisch dargestellt.

31

Abbildung 14 Enity-Relationship-Model der hierarchischen Beziehungen innerhalb eines XML-

Diehierarchische Struktur eines XML-Dokuments wird im obigen Entity-Relationship-Model als 1:n-Beziehung der Entität „Element“ auf sich selbst moduliert. In diesem Modell werden lediglich hierarchische Beziehungen abgebildet. Die Reihenfolge der Strukturobjekte innerhalb eines XML-Dokumentes ist jedoch von Bedeutung und wurde noch nicht berücksichtigt. Die Sequenz läßt sich z.B. durch eine einfach verkettete Liste darstellen, d.h. die Datenobjekte enthalten einen Verweis auf ihren

32

⁹ . Die Reihenfolge von XML-Deklaration und Dokument-Nachfolger bzw. Vorgänger

typdeklaration ist gemäß der XML-Spezifikation des W3C ([18]) fest (am Anfang des Dokumentes, erst XML- und dann Dokumenttypdeklaration) und braucht damit nicht abgebildet werden. Die Sequenz der Attribute eines Elements hat für XML-Applikationen keine Bedeutung und wird somit auch nicht berücksichtigt. Eine Processing Instruction kann als Vorgänger eine XML-Deklaration, eine Dokumenttypdeklaration, einen Kommentar, ein Element, Text oder eine Processing Instruction haben. Der Vorgänger eines Kommentars kann eine XML-Deklaration, eine Dokumenttypdeklaration, eine Processing Instruction, ein Element, Text oder ein Kommentar sein. Da die Position von XML-Deklaration, Dokumenttypdeklaration und dem ersten Element eine feste Sequenz ist, braucht sie nicht in der Datenbank abgelegt werden. Somit kann vor einem Element eine Processing Instruction, ein Kommentar, Text oder ein Element stehen. Text ist nur innerhalb von Elementen erlaubt. Die möglichen Vorgänger des Textes sind damit Kommentare, Processing Instructions und Elemente.

Die Vorgänger-Nachfolger-Beziehung läßt sich im Entity-Relationship-Model als 1:1-Beziehung modulieren. Damit läßt sich des Entity-Relationship-Model wie in Abbildung 15 grafisch dargestellt erweitern.

⁹ Um einen Datensatz erfolgreich einfügen zu können, muß der Verweis im Datenbanksystem auf den

Vorgänger erfolgen. Ein Verweis auf den Nachfolger, also einen noch nicht existierenden Datensatz, ist nicht möglich.

33

Abbildung 15 Entity-Relationship-Model der hierarchischen und sequentiellen Beziehungen inner-

Ausdem in Abbildung 15 dargestelltem Entity-Relationship-Model lassen sich folgende Relationen ableiten. file:

Die Relation „file“ identifiziert eine XML-Datei. Sie wurde bereits in Abschnitt 3.1.4 formuliert:

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

Es soll weiterhin die Möglichkeit einer Versionskontrolle bestehen, daher bilden der Dateiname und das Dateidatum den Primärschlüssel. Der Inhalt der Datei muß nicht zwingend gespeichert werden, da dieser durch obiges Entity-Relationship-Model (Abbildung 15) und das hier zu entwickelnde Relationenschema abgebildet wird. Diese

34

Abbildung ist jedoch nicht vollständig. Es werden keine Whitespaces und auch nicht die Sequenz von XML-Attributen eines XML-Elementes gespeichert, da sie für XML-Anwendungen nicht von Bedeutung sind. Eine Rekonstruktion des Dokumentes auf XML-Ebene ist somit möglich, aber nicht auf Dateiebene. Daher soll der Dateiinhalt weiterhin separat gespeichert werden. xmldecl:

Die Relation „xmldecl“ enthält als natürliche Elemente die Versionsnummer, das Encoding und die Standalone Document Declaration. Weiterhin ist die 1:1-Beziehung zur XML-Datei abzubilden.

xmldecl

doctypedecl:

Die Relation „doctypedecl“ enthält als natürliche Elemente einen Namen, einen Public Identifier, einen System Identifier und eine interne Deklaration. Weiterhin ist die 1:1-Beziehung zur XML-Datei abzubilden. doctypedecl

pi:

Die Relation „pi“ enthält als natürliche Elemente einen Namen und einen Wert. Keines der natürlichen Elemente identifiziert einen Datensatz eindeutig, so daß ein künstlicher Schlüssel gebildet werden muß. Es müssen die 1:1-Beziehungen (Vorgänger-Beziehung) zu sich selbst, der XML-Deklaration, der Dokumenttypdeklaration, dem Kommentar, dem Element und dem Text abgebildet werden. Die 1:n-Beziehungen „1“ und „3“ aus dem Entity-Relationship-Model zu „file“ und „Element“ sollen auch gleich mit abgebildet werden, ohne für sie eine extra Relation zu bilden. pi = {{piNr, name, content, filename, filedate, parentelement,

prevpi, prevxmldecl, prevdoctypedecl, prevcomment, prevelement,

^{prevtext}, {piNr}}} comment:

Die Relation „comment“ enthält als einziges natürliches Element den Kommentartext. Dieser kann aber innerhalb einer XML-Datei und erst recht in verschiedenen XML-Dateien mehrfach vorkommen. Es muß somit ein künstlicher Schlüssel gebildet werden. Weiterhin müssen die 1:1-Beziehungen (Vorgänger-Beziehung) zu sich selbst, der XML-Deklaration, der Dokumenttypdeklaration, der Processing Instruction, dem

35

Element und dem Text abgebildet werden. Die 1:n-Beziehungen „2“ und „4“ aus dem Entity-Relationship-Model zu „file“ und „Element“ sollen auch gleich mit abgebildet werden, ohne für sie eine extra Relation zu bilden. comment

element:

Die Relation „element“ enthält als einziges natürliches Element den Elementnamen. Dieser kann aber innerhalb eines XML-Dokumentes häufig vorkommen, so daß ein künstlicher Schlüssel gebildet werden muß. Es müssen die 1:1-Beziehungen (Vorgänger-Beziehung) zu sich selbst, der Processing Instruction, dem Kommentar und dem Text abgebildet werden. Weiterhin ist die 1:1-Beziehung zur XML-Datei abzubilden. Die 1:n-Beziehungen (Hierarchiebeziehung) „7“ aus dem Entity-Relationship-Model zu „Element“ soll auch gleich mit abgebildet werden, ohne für sie eine extra Relation zu bilden. element

attribute:

Die Relation „attrubute“ enthält die natürlichen Elemente Name und Wert, wobei beide sich für verschiedene Elemente wiederholen können und damit einen Datensatz nicht identifizieren, so daß ein künstlicher Schlüssel gebildet werden muß. Die 1:n-Beziehungen „5“ aus dem Entity-Relationship-Model zu „Element“ soll auch gleich mit abgebildet werden, ohne für sie eine extra Relation zu bilden. ^{attribute = {{attributeNr, name, value, elementNr}, {attributeNr}}} text:

Die Relation „text“ enthält als einziges natürliches Element den Text, der nicht eindeutig ist, so daß ein künstlicher Schlüssel zu bilden ist. Weiterhin müssen die 1:1-Beziehungen (Vorgänger-Beziehung) zu der Processing Instruction, dem Kommentar und dem Element abgebildet werden. Die 1:n-Beziehungen „6“ aus dem Entity-Relationship-Model zu „Element“ soll auch gleich mit abgebildet werden, ohne für sie eine extra Relation zu bilden. text = {{textNr, text, elementNr, prevcomment, prevpi, prevelement},

Aus den acht Relationen lassen sich acht Tabellen ableiten. Diese Tabellen sollen nicht weiter vorgestellt werden.

3.4.3.2.2 Knotenorientiert

Das Datenbankschema im vorherigen Abschnitt 3.4.3.2.1 geht von den Strukturelementen eines XML-Dokumentes aus und versucht die Geschäftsregeln, die durch das W3C in der XML-Spezifikation [18] definiert sind, nachzubilden. Dabei fällt auf, daß die Vorgänger-Beziehungen das Datenbankdesign unübersichtlich gestalten. Das Konsistenzmodell von RDBMS erlaubt es nicht, die Geschäftsregeln von XML-Dokumenten vollständig zu modellieren. Geht man bei der Betrachtung von syntaktisch korrekten ¹⁰ aus, ist es nicht erforderlich, die Geschäftsregeln sehr streng zu formu-XML-Dateien

lieren. Es muß lediglich gewährleistet werden, daß die inhaltliche Struktur erhalten bleibt. Dadurch läßt sich das Datenbankdesign minimieren. Betrachtet man ein XML-Dokument als Baum, ist es „lediglich“ erforderlich, die Knoten des Baumes mit ihren Eltern- und Vorgängerbeziehungen abzubilden. Die Art des Knotens muß nicht zwingend als extra Relation abgebildet werden. So lassen sich die Strukturobjekte Processing Instruction, Kommentar, Element, Attribut und Text in einer Relation „node“ modellieren. ^{node = {{nodeID, type, name, value, parent, prev}, {nodeID}}} Werden wie hier die XML-Deklaration und die Dokumenttypdeklaration nicht als Knoten des XML-Baumes aufgefaßt und somit nicht durch die Relation „node“ abgebildet, läßt sich die Sequenz von Kommentaren und Processing Instructions nur innerhalb der Elemente korrekt erfassen. Im Prolog eines XML-Dokumentes lassen sich durch dieses Modell die Reihenfolge dieser beiden Elemente „nur“ relativ zu sich selbst speichern. Es ist keine Aussage möglich, ob ein Kommentar vor oder nach der Dokumenttypdeklaration stand. Für eine Applikation zur Recherche von XML-Daten dürfte diese Information jedoch irrelevant sein. Kommentare habe für XML-Applikationen im Allgemeinen keine Bedeutung. Die XML-Adressierungssprache XPath erlaubt nur die Selektion von Kommentaren und Processing Instructions innerhalb von Elementen (vgl. [13]). In den Daten vom mi-Verlag kommen keine Processing Instructions vor. Noch nicht einmal jede hundertste XML-Datei (ca. 0,9 %) des mi-Verlages enthält Kommentare. So sollte die mit diesem Modell getroffene Vereinfachung keine praktische nachteilige Bedeutung auf die Recherchierbarkeit von XML-Daten haben.

¹⁰ Durch die Existenz von XML-Parsern, kann mit ihrer Hilfe vor dem Einfügen von XML-Dateien in die

Datenbank auf die Einhaltung der XML-Regeln geprüft werden, so daß das die Datenbank nicht leisten muß.

37

Mit diesem Modell erfolgt kein Verweis (Vorgängerbeziehung) mehr der Kommentare und Processing Instructions auf die XML-Deklaration und die Dokumenttypdeklaration. So kann die 1:1-Beziehung der XML-Deklaration und die Dokumenttypdeklaration zur XML-Datei auch direkt in der Relation „file“ umgesetzt werden.

Die 1:1-Beziehung im bestandteilorientierten Speichermodell zwischen der XML-Datei und dem Wurzelelement ändert sich jetzt in eine 1:1-Beziehung zwischen der XML-Datei und dem Wurzelknoten. Beide Relationen könnten prinzipiell zusammengefaßt werden. Aufgrund der Beziehungen innerhalb der Knoten sollen beide Relationen aber getrennt bleiben und die Knoten-Dateibeziehung in der Relation „file“ als Verweis auf den Wurzelknoten realisiert werden. Damit ändert sich die Relation „file“:

file = {{name, date, size, content, version, encoding, standalone,

^{doctypename, public, system, intern, rootnode},{name, date}}} Aus diesen beiden Relationen lassen sich folgende Datenbanktabellen ableiten:

Diese beiden Tabellen stehen über die Attribute „rootnode“ und „nodeID“ in einer 1:1-Beziehung, die in Abbildung 16 grafisch veranschaulicht wird.

39

3.5 Zusammenfassung

Für die hier zu erstellende Applikation sollen sowohl die Dateiinformationen (Abschnitt 3.1), Metainformationen (Abschnitt 3.2), die Volltexte (Abschnitt 3.3) und die XML-Struktur (Abschnitt 3.4) gespeichert werden. Die XML-Struktur soll dokumenttypunabhängig in Knotenform (Abschnitt 3.4.3.2.2) abgelegt werden. Zur Vereinfachung der Abfrage und des Löschens von Daten wird das Datenmodell wie folgt geändert:

Die Relation „file“ erhält einen künstlichen Schlüssel „fileID“. Die Referenz „rootnode“ in der Relation „file“ auf den Wurzelknoten wird ersetzt durch eine Referenz „file“ in der Relation „node“.

Somit ergibt sich das in Abbildung 17 grafisch dargestellte Datenbankdesign.

40

4 Wahl des RDBMS

Die Implementierung des Datenbankschemas ist an ein konkretes RDBMS gebunden. Mit dem Standard SQL und dem Quasi-Standards ODBC bzw. JDBC sollte es möglich sein, Datenbankapplikationen unabhängig von einem konkreten DBS zu implementieren. Die Implementation der Standards durch die DBS erfolgt jedoch nicht vollständig. Auch sind die Leistungen der einzelnen Systeme recht unterschiedlich. So ist es an dieser Stelle erforderlich, sich für ein RDBMS zu entscheiden. Das zu verwendende Datenbanksystem muß in der Lage sein, große Mengen baumstrukturierter Daten zu speichern und eine effiziente Abfrage zu ermöglichen. Dazu muß es unteranderem folgende Kriterien erfüllen: Existenz von BLOBs, CLOBs oder Ähnlichem ·

Index auf ein oder mehrere Attribute einer Tabelle ·

Speicherbarkeit großer Datenmengen (Anzahl Datensätze, absolute Datenmenge) ·

performantes Antwortverhalten bei Abfrage ·

SQL-Implementation ·

Vorhandensein eines Transaktionskonzeptes ·

Bereitstellung von Datenbanktreibern (ODBC, JDBC, BDE, Perl-DBI, ...) ·

Diese Kriterien werden von verschiedenen Datenbanksystemen erfüllt. Das im vorherigen Abschnitt 3.5 entworfene Datenbankdesin soll für das Datenbanksystem mySQL implementiert werden.

42

5 Datenimport

5.1 Klassendesign

Zu den XML-Dateien sollen die vier verschiedene Arten von Informationen Dateiinformationen, Meta-Informationen, Volltextinformationen und XML-Strukturinformationen

im Datenbankmanagementsystem gespeichert werden. Bis auf die Meta-Informationen ergeben sich die übrigen Informationen aus der XML-Datei selbst., wobei die Informationsgewinnung unterschiedlich ist. Die Meta-Informationen müssen durch den Benutzer angegeben werden. Daraus folgt, daß der Importalgorithmus die vier verschiedenen Informationsarten berücksichtigen muß. mySQL erlaubt eine performante Volltextsuche über den Datentyp BLOB. Daher wird die Volltextsuche nicht speziell implementiert.

Der Import erfolgt objektorientiert. Es wird eine Klasse gebildet, die alle für den Import notwendigen Daten und Methoden enthält. Weiterhin soll nicht nur ein Hinzufügen von Daten möglich sein, sondern es muß auch gewährleistet werden, daß XML-Dokumente wieder gelöscht oder geändert werden können. Da mit dem in den vorherigen Abschnitten entworfenen Datenbankdesign eine Versionsverwaltung möglich ist, beziehen Änderungen sich nur auf die Meta-Informationen. Dateiänderungen werden als neue Datei eingefügt. Es muß jedoch möglich sein, gezielt Versionen einer Datei wieder zu löschen. Da für das Einfügen, Ändern und Löschen von XML-Dokumenten unterschiedliche Informationen notwendig sind, die sich als Teilmengen aus den Maximalinformationen ergeben, sollen für die drei Aktionen der Datenmanipulation drei Klassen durch Vererbung gebildet werden.

Die Basisklasse soll die Aktion des Löschens realisieren, „XMLDelete“. Für diese Aktion sind lediglich Informationen über den Dateinamen und das Dateidatum notwendig. Von dieser Basisklasse soll die Klasse für das Ändern abgeleitet werden, „XMLUpdate“. Sie benötigt noch zusätzlich die zu ändernden Metainformationen. Von dieser Klasse wiederum wird die Klasse „XMLInsert“ für das Einfügen der XML-

43

Dokumente abgeleitet, die alle übrigen Informationen (Dateigröße, Volltext und XML-Struktur) benötigt. Die Klassenhierarchie ist in Abbildung 18 grafisch dargestellt.

Das Einfügen, Ändern und Löschen erfolgt immer für eine konkrete XML-Datei. Daher verlangen die Konstruktoren aller drei Klassen den XML-Dateinamen, auf den von außen lesend über die öffentliche Eigenschaft „FileName“ zugegriffen werden kann. Jede Klasse enthält eine öffentliche Methode zur Ausführung ihrer Aktion. Die Methoden „Update“ und „Delete“ benötigen das Dateidatum, um die zu ändernde bzw. zu löschende Datei zu identifizieren. Die Methode Insert benötigt keine weiteren Parameter. Der Dateiname wird über den entsprechenden Parameter des Konstruktors spezifiziert. Die Metainformationen werden durch entsprechende öffentliche Eigenschaften (properties) angegeben. Alle anderen Informationen können der Datei entnommen werden. In den Abbildungen 19 bis 21 sind die nicht privaten Mitglieder (Eigenschaften, Methoden und Ereignisse) grafisch dargestellt.

5.2 Methode zum Einfügen einer XML-Datei in die Datenbank

Die öffentliche Methode „Insert“ der Klasse „XMLInsert“ fügt eine XML-Datei in die Datenbank ein. Sie lädt die Datei, ermittelt alle dateiabhängigen Informationen, fügt die Dateiinformationen, die Metainformationen, die Volltexte und die XML-Strukturin-formationen ein.

Zum Einfügen der Daten in die Datenbank wird über einen ODBC-Treiber eine Datenbankverbindung hergestellt. Die Informationen werden per SQL-Statements gemäß dem konzeptionellen Datenbankschema (vgl. Abschnitt 3) eingefügt.

45

5.3 DOM

5.3.1 Laden einer XML-Datei als DOM

Zum Einfügen der XML-Struktur in die Datenbank soll das Document Object Model (DOM) genutzt werden. Das DOM ist eine Empfehlung des W3C vom 1.10.1998. Dabei handelt es sich um eine plattform- und sprachunabhängige Schnittstelle, die es Programmen und Skripten erlaubt, dynamisch auf XML-Dokumente zuzugreifen, und deren Inhalte sowie deren Struktur zu ändern (vgl. [8]). Die Struktur des Dokumentes wird als Baum umgesetzt, wobei jedes Strukturelement einem Knoten entsprecht. Bis auf den Wurzelknoten hat jeder Knoten genau einen Elternknoten und kann weitere Kindknoten haben. In Abhängigkeit vom Typ des Strukturelementes, haben die Knoten unterschiedliche Eigenschaften. Es gibt zahlreiche, zum Teil freie, objektorientierte ¹¹ soll hier zurückge-Implementationen des DOM. Auf eine solche Implementation griffen werden.

Für das Laden eines XML-Dokumentes werden in der DOM-Implementation entsprechende Methoden zur Verfügung gestellt. Dabei wird das Dokument auf korrekte XML-Syntax und optional gegen eine DTD bzw. ein XML-Schema geprüft. War der Ladevorgang erfolgreich, steht das XML-Dokument als Baum gemäß der W3C-Spezifikation zur Verfügung. Das Laden wird von der privaten Methode „LoadXML“ der Klasse „XMLInsert“ ausgeführt.

5.3.2 Einfügen eines XML-DOMs in eine Datenbank

Das konzeptionelle Datenbankschema im Abschnitt 3.4.3.2.2 sieht vor, daß jedes XML-Strukturelement als ein Datensatz in die Tabelle „node“ mit einer Referenz auf sein Elternelement und seinen Vorgänger einzufügen ist. Durch diese Verweise ist die Abarbeitungsreihenfolge des DOM-Baumes von untergeordneter Bedeutung. In dieser Arbeit wurde die Hauptreihenfolge (von „oben“ nach „unten“ und von „links“ nach „rechts“) gewählt. Die private Methode „InsertDOM“ der Klasse „XMLInsert“ extra- ¹¹ ZurImplementation wird die DOM-Implementation MSXML von Microsoft benutzt.

46

hiert zuerst den „Prolog“ der XML-Datei und fügt diesen in die Tabelle „file“ ein und ruft dann die Methode „InsertNode“ für das Wurzelelement auf.

Die private Methode „InsertNode“ der Klasse „XMLInsert“ arbeitet den DOM-Baum rekursiv in der Hauptreihenfoge ab und fügt jedes XML-Strukturelement in die Tabelle „node“ ein. Dabei wird zuerst der aktuelle Knoten in die Tabelle „node“ eingefügt. Anschließend wird für alle seine Kindknoten diese Methode erneut ausgeführt. Die Methode „InsertNode“ erwartet als Parameter den einzufügenden DOM-Knoten, die Datenbankreferenz auf seinen Elternknoten und die Datenbankreferenz auf seinen Vorgängerknoten. Der Rückgabewert dieser Methode ist die „nodeID“ (Primärschlüssel der Tabelle „node“) des aktuell in die Tabelle „node“ eingefügten Datensatzes (DOM-Knoten).

5.4 Größenabhängigkeit

Es lassen sich mit dem gewählten DBMS und dem gewählten konzeptionellen Datenbankschema nicht beliebig große XML-Dokumente importieren. Die maximale Größe eines BLOB bei mySQL (Ver 3.23.39-max-debug for Win95/Win98 on i32) beträgt zur Zeit 16 MB. Unabhängig dieser Größenbeschränkung steigt mit der Dokumentengröße auch die Zeit, die für das Importieren benötigt wird. Die obigen Klassen wurden implementiert und von einer Beispielapplikation benutzt. In Tabelle 14 sind exemplarisch für einige XML-Dateien die Zeiten aufgeführt, die die Beispielapplikation benötigte, um die Daten in das Datenbanksystem einzufügen. Die Tabelle ist aufsteigend nach der Zeitdauer sortiert.

47

Datenimport   

Diagramm  2 Zeit zum Einfügen in Abhängigkeit der Knotenzahl  

   400,0

   350,0

   300,0

   250,0

Zeit   

   200,0

   150,0

   100,0

   50,0

   0,0

0  10000 20000 30000 40000 50000 60000 70000  80000

Anzahl  Knoten  

49

6 Datenabfrage

6.1 Problemstellung

Entsprechend der Zielsetzung (vgl. Abbildung 4, Abschnitt 1.2) soll die Datenabfrage nicht auf Applikationsschicht erfolgen, sondern eine Schnittstelle der Applikation zur Datenbank darstellen. Zur Erfüllung dieser Aufgabe läßt sich die Abfrage als API oder als Abfragesprache implementieren. Bei der Implementation als Abfragesprache soll auf bereits existierende Standards zurückgegriffen werden bzw. eine Anlehnung an Standards und Quasi-Statandars erfolgen. Die Wahl des Abfrageverfahrens und der Abfragesprache hängt unter anderem von der Datenhaltung und dem Ziel der Abfrage ab

6.1.1 Datenhaltung

Die Daten werden in einem relationalen Datenbankmanagementsystem gehalten. Dafür existiert SQL als standardisierte Abfragesprache. Das benutzte RDBMS hat SQL implementiert, und diese Anwendung benutzt SQL für den Datenzugriff. Damit würde sich SQL als Abfragesprache anbieten. Das setzt jedoch die Kenntnis des konzeptionellen Datenbankschemas voraus.

Semantisch handelt es sich um Dateien und XML-Daten. Für Dateien gibt es keine standardisierte Abfragesprache. Die Suche nach Dateien findet im Allgemeinen auf Betriebssystemebene statt und ist somit vom jeweiligen Betriebssystem abhängig. Für XML existieren Empfehlungen zur Addressierung, Selektion und Verlinkung (z.B.: XPath, XPointer, XLink). Zur Abfrage von XML-Daten ist die Empfehlung XQuery in Vorbereitung (vgl. [16]).

6.1.2 Ziel der Abfrage

6.1.2.1 Abzufragende Inhalte

Abfragbar soll prinzipiell alles sein, was diese Datenbankapplikation an Informationen über die Datenobjekte speichert. Das sind Dateiinformationen, Metainformationen, Volltextinformationen und XML-Strukturinformationen.

Für Dateiinformationen gibt es auf Betriebssystemebene keine standardisierte Abfragesprache. Es würde sich zur Abfrage, da diese Informationen in einem RDBMS

50

gehalten werden, SQL anbieten oder eine eigene Abfragesprache, die sich syntaktisch an die entsprechenden Betriebssystembefehle anlehnt. Da die Befehlssyntax vom Betriebssystem abhängt, kann sich die Syntax nur an ein ausgewähltes Betriebssystem anlehnen.

Die Metainformationen sind eine klassische relationale Datenbankanwendung. Hier bietet sich SQL als Abfragesprache an, mit der Einschränkung, daß das konzeptionelle Datenbankschema veröffentlicht sein muß.

Für Volltextinformationen existiert ebenfalls keine standardisierte Abfrage. Es gibt im Sprachumfang von SQL Ausdrücke, die sich zur Textabfrage eignen. Weiterhin gibt es in einigen Betriebssystemen und Programmiersprachen Konstrukte zur Volltextsuche, deren Syntax für eine eigene Abfragesprache dienen könnten. Im Allgemeinen besteht eine Volltextabfrage aus dem Suchstring, Platzhaltern, logischen Operatoren oder regulären Ausdrücken, so daß die Volltextabfrage keine eigene Abfrage sein muß, sondern Bestandteil einer Abfrage wie z.B. SQL sein kann. Auf XML-Ebene ist vom W3C die Empfehlung XQuery in Vorbereitung.

6.1.2.2 Ergebnismenge

Das Ergebnis einer Abfrage sollen mindestens die Dateien sein, die die Abfragebedingungen erfüllen. Eine Erweiterung der Treffermenge stellen Listen von XML-Fragmenten (XML-Teilbäume) dar. Das Hauptergebnis, die Menge von Dateien, kann durch SQL realisiert werden. Da SQL eine Abfrage auf eine oder mehrere Tabellen darstellt und als Ergebnis eine (logische) Tabelle liefert, kann die Ergebnismenge kein Baum sein. Das läßt sich nur durch spezielle XML-Abfragesprachen oder ein API realisieren.

6.1.3 Abfragesprachen

6.1.3.1 SQL

SQL ist eine standardisierte Abfragesprache für RDBMS. Sie eignet sich im Kontext dieser Arbeit für die Datei-, Meta- und Volltextinformationen. Für die XML-Strukturin-formationen ist SQL nicht geeignet. Da die XML-Daten in einem RDBMS gehalten werden, müssen unabhängig von der implementierten Abfrage letzliche alle Anfragen in SQL-Statements umgewandelt werden.

51

6.1.3.2 XQuery

XQuery ist eine vom W3C in Vorbereitung befindliche Empfehlung zur Abfrage von XML-Dokumenten (Status: W3C Working Draft 07 June 2001, [16]). Sie stellt das Äquivalent zu SQL für XML-Dokumente dar. Zur Adressierung der XML-Knoten wird die W3C-Empfehlung XPath benutzt. XPath als eigenständige W3C-Empfehlung erlaubt die Selektion von XML-Daten nur innerhalb eines Dokuments. XQuery erlaubt Abfragen über mehrere XML-Dokumente und die Konstruktion von Ergebnismengen. XQuery eignet sich im Kontext dieser Arbeit zur Abfrage der XML-Daten. Das Ergebnis von XQuery sind Listen von XML-Teilbäumen. Es lassen sich mit XQuery nicht die Datei- und Metainformationen abfragen.

6.1.4 Probleme bei Wahl des Abfrageverfahrens

Zusammenfassend entstehen bei der Abfrage von XML-Dateien folgende Probleme. Die durch das Datenbanksystem gespeicherten Datenobjekte sind so verschieden, daß verschiedene Abfragesprachen benötigt werden, um die gestellten Ziele zu erreichen. Teilweise existieren noch keine Abfragestandards. Ein Nutzer der Datenbank soll keine Kenntnis über das interne Datenbankschema haben müssen.

6.1.5 Lösungsmöglichkeiten

Das Problem der unterschiedlichen Datenstrukturen läßt sich durch Verwenden nicht einer, sondern unterschiedlicher Abfragesprachen lösen. Zur Abfrage von Informationen auf Dateiebene wird SQL und auf XML-Ebene die XML-Abfragesprache XQuery ver-wandt. Weiterhin läßt sich ein relativ einfaches externes Datenbankschema definieren, das als Schnittstelle für die Abfrage veröffentlicht wird. Alternativ zur Verwendung von unterschiedlichen Abfragesprachen läßt sich auch eine externe, globale DTD (bzw. externes globales XML-Schema) definieren, das alle XML-Dokumente mit ihren Datei- und Metainformationen logisch als ein XML-Dokument zusammenfaßt. Auf dieses läßt sich dann eine (XML-) Abfragesprache anwenden. Eine weitere Alternative ist die Implementation eines APIs, das es erlaubt, Daten abzufragen.

6.2 Problemlösung

Für die zu entwickelnde Applikation wird ein API entwickelt, das es dem Nutzer erlaubt, auf die logisch relationalen Daten (Datei-, Meta- und Volltextinformationen) und auf die logisch baumstrukturierten XML-Daten zuzugreifen. Die Abfrage der rela-

52

tionalen Daten erfolgt über SQL. Dafür wird das konzeptionelle Datenbankschema veröffentlicht. Die Abfrage der XML-Daten erfolgt durch XQuery. Da die Speicherung der XML-Strukturdaten in einer relationalen Datenbank erfolgt, läßt sich XQuery nicht auf diese Datenbank anwenden. Ein XQuery-Statement muß entsprechend dem konzeptionellen Datenbankschema (Abschnitt 3.4.3.2.2) in ein oder mehrere SQL-Anfragen umgewandelt werden. Dazu ist im ersten Schritt das XQuery-Statement für die weitere Verarbeitung so aufzubereiten, daß auf seine strukturellen und inhaltlichen Elemente zugegriffen werden kann. Durch einen (zu entwickelnden) XQuery-Parser wird das Statement als Syntaxbaum zur Verfügung gestellt.

6.2.1 XQuery-Parser

Die aktuelle XQuery-Spezifikation des W3C inklusive Grammatik ist unter http://www.w3.org/TR/xquery/ veröffentlicht. Die Adressierung der abzufragenden XML-Daten wird innerhalb der XQuery-Syntax durch XPath realisiert. Spezifikation und Grammatik für XPath sind vom W3C unter http://www.w3.org/TR/xpath.html veröffentlicht.

Ziel dieser Arbeit soll es nicht sein, die komplette XQuery- und XPath-Grammatik zu implementieren. Es soll für den Anwender die Möglichkeit bestehen, die XML-Datenbank nach dem Inhalt von Elementen und dem Inhalt von Attributen zu durchsuchen. Der Parser soll bei XQuery nur den "LET"-Konstrukt und bei XPath nur folgende Sprachelemente unterstützen: Name eines Elementes

/ ("Pfad"-Trenner zwischen Knoten im XML-Baum) // (beliebige Hierarchieebene im XML-Baum) * (Wildcart für Element- und Attributnamen) [] (Filter) text() (Textinhalt eines Elementes) @ (Attribut) = (Vergleichsoperator Gleichheit) < (Vergleichsoperator kleiner) > (Vergleichsoperator größer)

53

Beispielsweise sollen folgende Abfragen realisiert werden: ^{let $a:=//publisher[text()="Edition digital"] return $a} Suche alle Elemente mit dem Namen "publisher" in beliebiger Hierarchieebene, die als Textinhalt die Zeichenkette "Edition digital" haben. let $a:=//*[@year="2000"] return $a

Suche alle Elemente (egal welchen Namen, egal welche Hierarchieebene), die ein Attribut mit dem Namen "year" haben und dessen Inhalt der String "2000" ist. Für diese vereinfachten Anforderungen ergibt sich folgende reduzierte XQuery-Grammatik:

XQuery

WhiteSpace

ReturnClause := "return" WhiteSpace Variable

LetClause

Variable

Name

Letter

Number

Expr

Path

PathChar

PathName

Attribute

Element

Filter

Left

Op

Right

String

Der Parser wird objektorientiert in drei Klassen realisiert. Die Klasse „XQueryParser“ bestimmt die Symbole der Sprache, nimmt die syntaktische Analyse vor und generiert den Syntaxbaum. Diese Klasse hat die öffentliche Methode „parse“, die ein XQuery-Statement, das als Parameter übergeben wird, verarbeitet. Der Rückgabewert dieser Methode ist eine Instanz der Syntaxbaum-Klasse „XQueryTree“. Der Scanner (Lexikaanalyse) wird über die private Methode „GetSym“ realisiert. Für jedes Nichtterminal der vereinfachten XQuery-Grammatik verfügt die Parser-Klasse über eine entsprechende private Methode. Durch rekursiven Abstieg werden die Symbole syntaktisch analysiert und bei Erfolg ein Knoten im Syntaxbaum generiert. Entspricht ein Zeichen nicht der Symbolmenge oder eine Folge von Symbolen nicht der Grammatik der Sprache, wird eine Instanz der Ausnahme-Klasse „XQueryException“ erhoben. Der Syntaxbaum wird als Baumklasse „XQueryTree“ realisiert. Diese Klasse hat die öffent-

54

liche Methode „AddNode“. Sie fügt dem Syntaxbaum einen Knoten hinzu, in dem sie einen Teilbaum als Instanz der selben Klasse „XQueryTree“ konstruiert und einer privaten Liste hinzufügt. Auf die Listenelemente kann über entsprechende öffentliche Eigenschaften (properties) zugegriffen werden („ChildCount“, „Childs[index]“). Eine öffentliche Eigenschaft („NodeType“) der Klasse gibt an, um welches Strukturelement im Syntaxbaum es sich handelt und eine weitere Eigenschaft („Value“) den (terminalen) String dieses Strukturelements.

6.2.2 SQL-Generator

Der XPath-Ausdruck im reduzierten XQuery-Statement stellt die Formulierung der Abfrage dar. Damit diese Anfrage auf die relationale Datenbank angewandt werden

55

kann, muß sie in ein SQL-Statement umgewandelt werden. Ergebnis der Abfrage soll nicht ein XML-Teilbaum, sondern die XML-Datei sein, für die diese Anfrage zutrifft.

Von den drei obigen Beispielen lassen sich folgende Regeln zur Umsetzung des Pfadausdruckes (XML-Hierarchie) ableiten:

Die Hierarchie läßt sich als inner join des Attributs „parent“ der Tabelle „node“ ·

auf das Attribut „nodeID“ der selben Tabelle abfragen. Taucht im Pfadausdruck ein Wildcard („*“) auf, wird das Attribut „name“ der ·

Tabelle „node“ nicht abgefragt, sonst ist dessen Inhalt der Element- bzw XML-Attributename.

Für das Rootelement („/*“ oder „/“Elementname) ist das Attribut „parent“ leer ·

(NULL).

Für den Typ des XML-Knotens ist das Attribute „type“ abzufragen. ·

Für den Filterausdruck im XPath-Audruck lassen sich folgende Regeln ableiten: Der Vergleichsoperator im XPath-Ausdruck entspricht dem Vergleichsoperator ·

in der where-Klausel des SQL-Statements.

Für den zu vergleichenden Inhalt ist das Attribute „value“ der Tabelle „node“ ·

abzufragen.

57

Für den Ausdruck „text()“ müssen die Bedingungen erfüllt sein, daß der Kno- ·

tentype (Attribute „type“ der Tabelle „node“) „text“ ist, das Attribute „value“ der Tabelle „node“ im Vergleichsstring enthalten ist, und das es sich um ein Kind des angegebenen Elementes handelt. Für die letzte Bedingung müssen inner joins der Attribute „parent“ und „nodeID“ gebildet werden. Da die Hierarchietiefe nicht bekannt ist, läßt sich diese Abfrage nicht durch ein Statement generieren. Es müssen mehrere Abfragen auf die jeweilige Ergebnismenge durchgeführt werden. Daher soll die folgende Vereinfachung getroffen werden. Der XPath-Ausdruck „text()“ wird als einzelner, direkter Kind-Textknoten des entsprechenden Elternelementes interpretiert. Diese Vereinfachung wurde bereits im Beispiel 1 getroffen.

Die Umsetzung dieser Regeln erfolgt in der Klasse „XQuery2SQL“. Die öffentliche Methode „GenSQL“ dieser Klasse wandelt ein XQuery-Statement in ein SQL-Statement um. Das XQuery-Statement wird der Methode als Syntaxbaum in Form einer Instanz der Klasse „XQueryTree“ übergeben. Der Rückgabewert ist das SQL-Statement, das bei Anwendung auf die Tabellen „file“ und „node“ die XML-Dateien als Ergebnismenge liefert, die den Bedingungen im XPath-Ausdruck genügen.

Die Methode „GenSQL“ geht alle Knoten des Syntaxbaumes durch und ruft rekursiv für jeden Knotentype eine entsprechende private Methode auf, die das Ergebnis-SQL-Statement manipuliert.

Für die Abfrage der Daten stellt die Klasse „XMLFinder“ die Schnittstelle zur Datenbank dar. Die öffentliche Methode „RelQuery“ erlaubt es, die relationalen Daten (Datei-

58

, Meta- und Volltextinformationen) abzufragen. Sie sendet das als Parameter übergebene SQL-Statement an die Datenbank. Das Abfrageergebnis wird in der öffentlichen Eigenschaft „ResultSet“ zur Verfügung gestellt. Zur Abfrage der XML-Daten führt die öffentliche Methode „XQuery“ das als Parameter übergebene XQuery-Statement aus. Das Abfrage Ergebnis ist ebenfalls über die öffentliche Eigenschaft „ResultSet“ abgreifbar. Die öffentliche Eigenschaft „SQL“ hält das zuletzt ausgeführte SQL-Statement bereit.

Die öffentliche Methode „XQuery“ der Klasse „XMLFinder“ konstruiert eine Instanz der Klasse „XQueryParser“ und übergibt deren Methode „Parse“ das XQuery-Statement. Konnte das Statement erfolgreich geparst werden, gibt diese Methode eine Instanz der Klasse „XQueryTree“ zurück. Die Methode „XQuery“ instanziiert danach die Klasse „XQuery2SQL“, übergibt deren Methode „GenSQL“ die Instanz der Klasse „XQueryTree“ und erhält ein SQL-Statement zurück. Dieses wird an die Datenbank gesendet.

59

6.3 Abfragegeschwindigkeit

Durch die Abbildung der hierarchischen Datenstruktur auf das relationale Datenmodell ist zu vermuten, daß bei großen Datenmengen mit der Anzahl der für eine Anfrage erforderlichen joins die Antwortzeit der Datenbank ansteigt. Daher wurden die oben beschriebenen Klassen implementiert und von einer Beispielapplikation für einen Per-formancetest benutzt. Dabei wird die Zeit vom Absetzen der XQuery-Anfrage an den Parser bis zum Erhalt der Ergebnismenge von der Datenbank gemessen. Es werden keine Prozessortakte gemessen und auch keine Anzahl von Maschinenbefehlszyklen ermittelt. Somit ist das Meßergebnis nicht nur von der verwendeten Maschine, sondern auch von der Systemlast abhängig. Die ermittelten Werte erlauben lediglich eine qualitative Abschätzung. Die Datenbank wurde mit den Standardeinstellungen installiert und nicht optimiert. Lediglich Indizes für die Primär- und Fremdschlüssel wurden angelegt. Untersucht wurde, wie sich die Antwortzeit in Abhängigkeit von der Datenmenge, der Anzahl der erforderlichen joins und der Ergebnismenge ändert. Zur Quantifizierung der Datenmenge wurde die Anzahl der Datensätze in der Tabelle „node“ verwendet. Die Ergebnismenge wird durch die Anzahl der in der Tabelle „node“ entsprechend der Abfrage gefundenen Datensätze ausgedrückt. Unter einem join soll hier die Auflösung einer Referenz in dem aus dem XQuery-Statement ermittelten SQL-Statement verstanden werden.

60

Die Anzahl der joins wurde durch die folgenden vier XPath-Ausdrücke variiert: 1. //*[text()="Suchstring"] (2 joins) 2. /*/*[text()="Suchstring"] (3 joins) 3. //*/*/*[text()"Suchstring"] (4 joins) 4. /*/*/*/*[text()"Suchstring"] (5 joins)

Die Ergebnismenge wurde durch den Wert von „Suchstring“ bestimmt. Um keine Treffermenge zu erhalten, wurde nach einer Zeichenfolge gesucht, die in den Beispieldaten nicht vorkommt. Für eine kleine Treffermenge wurde nach der Zeichenfolge „200-830-5“ gesucht (4...5 Treffer). Um eine relativ große Treffermenge zu erhalten, wurde der Suchstring leer gelassen.

Zur Variation der Datenmenge (Anzahl Datensätze in der Tabelle „node“) wurden drei mal 264 Dateien in die Datenbank eingefügt. Nach jedem der drei Einfügevorgänge wurden die Messungen durchgeführt.

61

Datenabfrage   

In  Tabelle 15 sind die Abfragezeiten aufgeführt. Die Tabelle ist aufsteigend nach der  

Zeit  sortiert.  

Tabelle 15  Abfragezeiten  

Anzahl  Knoten Anzahl joins Anzahl Treffer Zeit in  

431  190 2 0  1,73

431  190 4 0  1,75

431  190 5 0  1,78

658  874 5 0  2,65

658  874 4 0  2,68

658  874 2 0  2,73

431  190 5 112  3,19

431  190 2 4  3,20

431  190 4 4  3,25

658  874 4 5  4,13

1  154 936 2 0  4,47

1  154 936 4 0  4,47

1  154 936 5 0  4,50

1  154 936 5 31  5,30

658  874 2 5  5,54

658  874 5 115  5,56

1  154 936 4 5  6,10

1  154 936 2 5  7,39

1  154 936 5 979  21,79

431  190 3 1 978  130,56

658  874 3 2 234  159,54

1  154 936 3 3 590  342,85

62

Im Diagramm 3 sind die Meßergebnisse für 4 joins und 4 bis 5 Treffer in Abhängigkeit der Datenmenge grafisch dargestellt. Für diese Art der Abfrage scheint die Anfragezeit mit der Anzahl der in der Datenbank gespeicherten Knoten annähernd linear zu steigen.

7,00

6,00

5,00

4,00

Zeit [s]

3,00

2,00

1,00

0,00

Im Diagramm 4 sind die Abfragezeiten in Abhängigkeit von der Anzahl der joins für die „mittlere“ Datenmenge von 658 874 Datensätzen und einer Treffermenge von 5 bis 115 Treffern grafisch dargestellt. Danach scheint der Einfluß der join-Anzahl (zumindest bis zu dieser Größenordnung) nur gering zu sein.

6,00

5,00

4,00

Zeit [s]

3,00

2,00

1,00

0,00

Den größten Einfluß auf das Zeitverhalten scheint die Größe der Ergebnismenge zu haben. Im Diagramm 5 ist die Abfragezeit in Abhängigkeit der Treffer grafisch dargestellt. Kamen in der Meßtabelle, bedingt durch die beiden anderen Parameter, für eine Trefferzahl mehrere Zeiten in Frage, so wurde die mediane Zeit gewählt.

400,00

350,00

300,00

250,00

Zeit [s]

200,00

150,00

100,00

50,00

0,00

7 Darstellung der Abfrageergebnisse

Die Darstellung der Abfrageergebnisse ist gemäß Abbildung 4 in Abschnitt 1.2 nicht mehr Bestandteil der XML-Datenbank. Diese Aufgabe ist von der entsprechenden Datenbankapplikation zu implementieren. Diese Arbeit stellt eine mögliche Applikation dar, die die XML-Datenbank zur Recherche von XML-Daten nutzt.

7.1 Trefferliste

In dieser Arbeit ist die Treffermenge eine Liste von Dateien. Diese lassen sich als Liste darstellen, die prinzipielle alle Informationen enthalten kann, die in der Datenbank gespeichert werden. Hier sollen jedoch nur die Informationen in der Trefferliste enthalten sein, die in der Tabelle „file“ gespeichert werden. Die Liste kann nach jeder beliebigen Spalte auf- oder absteigend sortiert werden. In der zu implementierenden Beispielapplikation erfolgt eine Sortierung lediglich nach dem Dateinamen. Weiterhin ist ein Sortierung gemäß der Relevanz des Treffers vorstellbar. Die im Rahmen dieser Arbeit erfolgte Implementation läßt so ein Ranking jedoch nicht zu. Ist die Treffermenge eine Liste von XML-Teilbäumen, sollten diese auch in Baumstruktur dargestellt werden. Sie könnten einen abstrakten Wurzelknoten haben. Die nächste Hierarchieebene stellt das XML-Dokument dar, in dem das jeweilige XML-Fragment vorkommt. Daran würde sich der jeweilige XML-Teilbaum anschließen. XML-Teilbäume sind als Treffer für die Implementation der Beispielapplikation nicht vorgesehen.

7.2 Visualisierung der XML-Daten

7.2.1 Source-Code

Die einfachste Möglichkeit, XML-Daten darzustellen, ist die Anzeige als Text. Da die Tabelle „file“ der XML-Datenbank die XML-Datei als BLOB speichert, kann sie direkt angezeigt werden. Eine Erweiterung der XML-Quellcodeanzeige stellt das syntax coloring dar, bei dem die syntaktischen Bestandteile des XML-Dokumentes wie beispielsweise Elementnamen, Attributnamen, Attributwerte, Text farblich gekennzeichnet werden. Die Beispielapplikation verfügt über diese Möglichkeit jedoch nicht.

66

7.2.2 Baumstruktur

Um die Struktur der XML-Dokumente besser erfassen zu können, bietet es sich an, die XML-Dokumente als Baum darzustellen. Einige WWW-Browser wie beispielsweise der MS Internetexplorer stellen XML-Dokumente als Baum dar und nehmen auch noch ein syntax coloring vor. Die Beispielapplikation nutzt den Internetexplorer als ActiveX zur Baumdarstellung.

7.2.3 Stylesheets

Um ein XML-Dokument entsprechend seinem Kontext für Menschen gut lesbar zu gestallten, ist es erforderlich, dem XML-Dokument Layoutinformationen hinzuzufügen. Das kann zum einen mittels Cascading Style Sheets (CSS) oder Extensible Style Sheet Language (XSL) erfolgen. CSS erlaubt es, relativ einfach Zeichen- und Absatzformate zu definieren. Für umfangreichere Gestaltungen, wie Positionierungen, inhaltliche Veränderungen usw. eignetet sich XSL. Stylesheets werden durch die Beispielapplikationen durch die Processing Instruction „xml-stylesheet“ über das Internetexplorer-ActiveX unterstützt.

67

8 Datenexport

8.1 XML-Datei

Die Tabelle „file“ der XML-Datenbank speichert im Attribute „content“ die XML-Datei als BLOB. Die Abfrageschnittstelle (property „ResultSet“ der Klasse „XMLFinder“) liefert die original XML-Datei, so daß die Datenbankapplikation sie speichern kann.

In der XML-Datenbank werden die XML-Dateien, nicht jedoch externe Referenzen wie XML-Schemata oder DTDs gespeichert. Wird eine XML-Datei aus der Datenbank exportiert, ist sie nur dann wieder syntaktisch korrekt, wenn sie über keine externen Referenzen verfügt oder die Datei an einen Ort (URL) gespeichert wird, so daß die Referenzen wieder auflösbar sind.

8.2 XML-DOM

Ein XML-DOM läßt sich aus einer XML-Datei nur dann bilden, wenn sie syntaktisch korrekt ist. Soll es zu jeder Zeit möglich sein, unabhängig von externen Referenzen über ein XML-DOM verfügen zu können, müssen: 1. alle externen Referenzen gespeichert und exportiert, 2. beim Import das DOM persistent gemacht oder 3. das DOM aus der Tabelle „node“ neu gebildet werden.

8.2.1 Speicherung externer Referenzen

Bei der Speicherung von externen Referenzen entstehen einige Probleme. Es können in den referenzierten Dateien erneut externe Referenzen auftreten. Verschiedene XML-Dokumente können die gleichen Dateien referenzieren. Da die XML-Dateien aber nicht am selben Ort sein müssen und die Referenzierung sowohl relativ wie absolut erfolgen kann, ist es schwierig, Datenredundanz zu vermeiden. Die relative Adressierung bereitet beim Datenexport Schwierigkeiten, wenn auf Verzeichnisse, die sich oberhalb des Wurzelverzeichnisses befinden oder auf Verzeichnisse, für die die Applikation nicht über die erforderlichen Rechte verfügt, zugegriffen werden muß. Die absolute Adressierung mit Angabe über Host oder gar Laufwerksbuchstaben läßt sich nur in Spezialfällen

68

restaurieren (Host oder Laufwerk existiert nicht oder ist nicht zugreifbar, Referenzierung von CD-ROM-Laufwerken usw.). Externe Referenzen sollen daher in der XML-Datenbank nicht gespeichert werden.

8.2.2 Speicherung des DOM

Beim Import der XML-Daten in die Datenbank bedient sich die Klasse „XMLInsert“ des DOM (vgl. Abschnitt 5.3). Im DOM sind bereits alle Referenzen aufgelöst. Das DOM-Objekt muß lediglich serialisiert (persistent gemacht) werden. Die hier verwendete DOM-Implementation (MSXML) verfügt über entsprechende Methoden und Properties, die zur Implementation von Presistenzmechanismen genutzt werden können. Die Klasse „XMLInsert“ implementiert einen solchen Persistenzmechanismus über die Klassenprozeduren „XMLDOM2File“, „File2XMLDOM“, „XMLDOM2Stream“ und „Stream2XMLDOM“. Beim Einfügen einer XML-Datei in die XML-Datenbank wird das verwendete XML-DOM-Objekt unter Nutzung der Klassenprozedur „XMLDOM2Stream“ im Attribut „dom“ der Tabelle „file“ als BLOB gespeichert. Von der Klasse „XMLInsert“ wird die Klasse „XMLGet“ abgeleitet. Sie überschreibt die in der Klasse „XMLInsert“ geschützte, virtuelle Methode „SetFileDate“ und deklariert sie als öffentlich. Über den Konstruktor, der den Dateinamen und die öffentliche Methode „SetFileDate“, die das Dateidatum erwartet, wird die XML-Datei in der Tabelle „file“ identifiziert. Die überschriebene Methode „SetFileDate“ liest aus dem Attribut „dom“ der Tabelle „file“ das XML-DOM-Objekt in die Eigenschaft „XMLDoc“ unter Nutzung der Klassenprozedur „Stream2XMLDOM“. Die Eigenschaft „XMLDoc“ ist in der Klasse „XMLInsert“ geschützt und wird durch die Klasse „XMLGet“ veröffentlicht.

69

8.2.3 DOM neu erzeugen

In den Tabellen „file“ und „node“ der XML-Datenbank werden die relevanten Informationen einschließlich aufgelöster Referenzen gespeichert, um wieder ein XML-DOM-Objekt zu generieren. Dieses Verfahren stellt eine Umkehrfunktion zur Methode „Insert“ der Klasse „XMLInsert“ dar. Es wird ein DOM-Objekt generiert und die Knoten aus der Tabelle „node“ entsprechend ihrer Eltern- und Vorgängerbeziehung

70

eingefügt. Da bei großen XML-Dokumenten sehr viele Abfragen notwendig sind, kann das Erzeugen eines DOM-Objektes auf diese Weise sehr lange dauern.

71

9 Beispielapplikation

Die in dieser Arbeit beschriebenen Algorithmen wurden in der Beispielapplikation „XMLSearch“ implementiert. Die Quellen dafür befinden sich auf der als Anlage enthaltenen CD.

Die Oberfläche (Abbildung 35) enthält im linken Bereich die Trefferliste. Im rechten Bereich ist die Abfrage nach den XML-Daten möglich. Unten werden die ausgeführten Aktionen als Protokoll für Debug- und Meßzwecke aufgelistet. Über das Menü „Datei“ (Abbildung 36) können Dateien importiert und exportiert werden. Beim Import mehrerer Dateien erscheint ein Datei-öffnen-Dialog, in dem mehrere Dateien ausgewählt werden können. Über den Unterpunkt „Export“ läßt sich die in der Trefferliste markierte Datei im Dateisystem über einen Speichern-unter-Diaolog speichern.

72

Wählt der Nutzer im Menü „Datei“ den Unterpunkt „Import (eine)“ aus, können zur ausgewählten Datei Meta-Informationen eingetragen werden (Abbildung 37). Im Memofeld „Schlagwörter“ ist jedes Schlagwort in eine neue Zeile einzutragen.

73

Über das Menü „Datensatz“ lassen sich die XML-Dateien anzeigen, bearbeiten oder löschen (Abbildung 38).

Wählt der Nutzer den Unterpunkt „Löschen“, so wird nach einer Sicherheitsabfrage der in der Trefferliste markierte Datensatz gelöscht. Bei Auswahl des Unterpunktes „Ändern“ erscheint ein Fenster, in dem der Nutzer die Meta-Informationen editieren kann (Abbildung 39). Ändern bedeutet nicht, daß die XML-Datei selbst geändert wird. Bei der implementierten Beispielapplikation handelt es sich nicht um einen XML-Edi-tor.

75

Bei Auswahl des Unterpunktes „Anzeigen“ oder durch Doppelklick auf eine XML-Datei wird die in der Trefferliste markierte Datei angezeigt. Die Anzeige erfolgt als Text (Abbildung 40) oder in Baumform über das Internet Explorer-ActiveX (Abbildung 41).

76

Die Recherche nach XML-Dateien erfolgt in der rechten Seite des Hauptfensters entweder über eine XQuery-Abfrage oder eine SQL-Abfrage (Abbildung 42). In das jeweilige Textfeld wird die Abfrage eingegeben. Mit der Schaltfläche „Abfragen“ wird die Abfrage gestartet. In der Trefferliste werden die XML-Dateien angezeigt, die den Abfragebedingungen genügen. Im unteren Protokollbereich wird die Abfrage, bei XQuery-Statements das ermittelte SQL-Statement und die Abfragezeit angezeigt.

A Literaturverzeichnis

[1] BACH, MIKE: XSL und XPath - verständlich und praxisnah. München, Boston

[u.a]: Addison-Wesley Verlag, 2000

[2] EBNER, MICHAEL: Delphi 4 - Datenbankprogrammierung. Bonn; Reading, Mass.

[u.a.]: Addision-Wesley-Longman, 1999

[3] ECKSTEIN, ROBERT: XML kurz & gut. Beijing; Cambridge [u.a]: O'Reilly Verlag,

2000

[4] KLETTKE, MEIKE; MEYER, HOLGER: XML und Datenbanken. Vortrag: XML-

Tutorial 2, 3. IuK-Tage Mecklenburg-Vorpommern, Rostock, 14.6.2001. [5] MURPHY, CRAIG: XQuery: The Power Of Unified Querying. The Delphi Magazin

75 (2001) 11, S. 18-28

[6] SEEBOERGER-WECHSELBAUM, MICHAEL: Das Einsteigerseminar XML.

Landsberg: Verlag moderne industrie, 2001

[7] VAN HERWIJNEN, ERIC: Practical SGML. Boston; Dodrecht; London: Kluwer

Academic Publishers, 1994

[8] W3C: Document Object Model (DOM). http://www.w3.org/DOM/ [9] W3C: Extensible Markup Language (XML). http://www.w3c.org/XML/ [10] W3C: XML Schema. http://www.w3.org/XML/Schema [11] W3C: Extensible Stylesheet Language (XSL) Version 1.0.

http://www.w3.org/TR/xsl/

[12] W3C: XML Linking Language (XLink) Version 1.0. http://www.w3.org/TR/xlink/ [13] W3C: XML Path Language (XPath) Version 1.0. http://www.w3.org/TR/xpath [14] W3C: XML Pointer Language (XPointer) Version 1.0. http://www.w3.org/TR/xptr [15] W3C: XSL Transformations (XSLT) Version 1.1. http://www.w3.org/TR/xslt11/ [16] W3C: XQuery 1.0: An XML Query Language. 7.06.2001.

http://www.w3.org/TR/xquery/

[17] BOURRET, RONALD: XML Database Products. 5.08.2001,

http://www.rpbourret.com/xml/XMLDatabaseProds.htm

[18] W3C: Extensible Markup Language (XML) 1.0 (Second Edition). 6.10.2000.

http://www.w3.org/TR/REC-xml

79

Verzeichnis  der Tabellen  

B  Verzeichnis der Tabellen  

1.  Tabelle 1 Beispiele für XML-Datenbanken  4

2.  Tabelle 2 Datenbanktabelle "file"  12

3.  Tabelle 3 Datenbanktabelle "file" mit Versionskontrolle.  12

4.  Tabelle 4 Datenbanktabelle "file" mit Versionskontrolle.  14

5.  Tabelle 5 Datenbanktabelle "meta"  15

6.  Tabelle 6 Datenbanktabelle "keyword"  15

7.  Tabelle 7 Datenbanktabelle "file" mit Versionskontrolle und Metadaten.  16

8.  Tabelle 8 Datenbanktabelle "keyword"  17

9.  Tabelle 9 Datenbanktabelle "file" mit Versionskontrolle und Metadaten.  20

10.  Tabelle 10 Datenbanktabelle "keyword"  21

11.  Tabelle 11 Datenbanktabelle "fulltext"  21

12.  Tabelle 12 Datenbanktabelle "file"  38

13.  Tabelle 13 Datenbanktabelle "node"  39

14.  Tabelle 14 Zeit zum Einfügen in Abhängigkeit der Dateigröße  48

15.  Tabelle 15 Abfragezeiten.  62

1.  Beispiel 1  56

2.  Beispiel 2  56

3.  Beispiel 3  57

80

Verzeichnis  der Abbildungen  

C  Verzeichnis der Abbildungen  

1.  Abbildung 1 XML-Transformation  2

2.  Abbildung 2 Publikationen aus XML.  2

3.  Abbildung 3 Drei Implementationsschichten einer Datenbankapplikation.  5

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

5.  Abbildung 5 Dateianzeige unter Windows NT  8

6.  Abbildung 6 Dateianzeige unter Linux  9

7.  Abbildung 7 Tabellenbeziehung.  14

8.  Abbildung 8 Tabellenbeziehungen nach Zusammenfassen der Relationen  

„file“  und „meta“  16

9.  Abbildung 9 Volltextindizierung, Quelle: 4 , vgl. S. 18 f.  19

10.  Abbildung 10 Tabellenbeziehung mit Volltextindex  20

11.  Abbildung 11 Tabellenbeziehungen "Buch"  25

12.  Abbildung 12 Hierarchische Struktur der Elemente.  29

13.  Abbildung 13 Darstellung eines XML-Dokumentes in Baumstruktur.  30

14.  Abbildung 14 Enity-Relationship-Model der hierarchischen Beziehungen  

innerhalb  eines XML-Dokumentes  32

15.  Abbildung 15 Entity-Relationship-Model der hierarchischen und  

sequentiellen  Beziehungen innerhalb eines XML-Dokumentes  34

16.  Abbildung 16 Tabellenbeziehungen der Knoten und Dateien.  40

17.  Abbildung 17 Datenbankdesingn  41

18.  Abbildung 18 Vererbungshierarchie der Klassen zur Datenmanipulation.  44

19.  Abbildung 19 Mitglieder der Klasse „XMLDelete“  44

20.  Abbildung 20 Mitglieder der Klasse „XMLUpdate“  45

21.  Abbildung 21 Mitglieder der Klasse „XMLInsert“  45

22.  Abbildung 22 Struktogramm Methode „Insert“  45

23.  Abbildung 23 Struktogramm Methode „LoadXMLDoc“  46

24.  Abbildung 24 Struktogramm Methode „InsertDOM“  47

25.  Abbildung 25 Struktogramm Methode „InsertNode“  47

81

Verzeichnis  der Abbildungen  

26.  Abbildung 26 Mitglieder der Klasse XQueryParser.  55

27.  Abbildung 27 Mitglieder der Klasse XQueryTree  55

28.  Abbildung 28 Mitglieder der Klasse XQueryException  55

29.  Abbildung 29 Mitglieder der Klasse XQuery2SQL.  58

30.  Abbildung 30 Struktogramm Methode „GenSQL“  58

31.  Abbildung 31 Mitglieder der Klasse XMLFinder  59

32.  Abbildung 32 Beziehung zwischen Instanzen der Klassen zur XML-Abfrage.  60

33.  Abbildung 33 Vererbungshierarchie der Klassen XMLGet  70

34.  Abbildung 34 Mitglieder der Klasse XMLGet.  70

35.  Abbildung 35 Oberfläche der Beispielapplikation „XMLSearch“  72

36.  Abbildung 36 Menü „Datei“  73

37.  Abbildung 37 Einfügen einer Datei.  74

38.  Abbildung 38 Menü „Datensatz“  75

39.  Abbildung 39 Meta-Informationen bearbeiten  76

40.  Abbildung 40 XML-Anzeige als Text.  77

41.  Abbildung 41 XML-Anzeige als Baum  77

42.  Abbildung 42 XML-Abfrage.  78

1.  Diagramm 1 Zeit zum Einfügen in Abhängigkeit der Dateigröße  48

2.  Diagramm 2 Zeit zum Einfügen in Abhängigkeit der Knotenzahl.  49

3.  Diagramm 3 Abfragezeit in Abhängigkeit von der Datenbankgröße.  63

4.  Diagramm 4 Abfragezeit in Abhängigkeit von der Anzahl der joins.  64

5.  Diagramm 5 Abfragezeit in Abhängigkeit von der Ergebnismenge  65

82

D Anlagenverzeichnis

CD-ROM mit:

1. Quellen für XML-Datenbank im Verzeichnis /Quellen/DBKernl 2. Quellen für Datenbankapplikation im Verzeichnis /Quellen/DBApplication 3. Testdaten im Verzeichnis /Daten

83

E Verzeichnis der Abkürzungen

API Application Programming Interface BLOB Binary Large Object CD Compact Disc CLOB Character Large Object CSS Cascading Style Sheet DBMS Datenbankmanagementsystem DBS Datenbanksystem DOM Document Object Model DTD Document Type Definition ISBN International Standard Book Number JDBC Java Data Base Connectivity mi-Verlag Verlag moderne industrie ODBC Open Data Base Connectivity PI Processing Instructions RDBMS relationales Datenbankmanagementsystem SQL Structured Query Language URL Uniform Resource Locator W3C World Wide Web Consortium XML Extensible Markup Language XSL Extensible Style Sheet Language XSLT Extensible Stylesheet Language Transformations

84

F Thesen

Thema: Nutzung eines relationalen DBS zur Speicherung und Recherche von

XML-Daten

Bearbeiter: Sören Pekrul

1. Relationale Datenbankmanagementsysteme eignen sich zur Speicherung und Recherche von XML-Dateien.

2. Datei-, Meta- und Volltextinformationen sind klassische Datenbankanwendungen, für die sich RDBMS sehr gut eignen.

3. XML-Strukturinformationen lassen sich mit dem relationalen Datenmodell abbilden. Die Hierarchie kann als Eltern-Kind-Beziehung mittels Fremdschlüssel realisiert werden.

4. Der Datenimport ist mit Hilfe des DOM sehr gut möglich. 5. Die Abfrage der XML-Strukturinformationen ist mit Einschränkungen möglich. 6. Es sind nicht alle vom W3C für XPath und XQuery spezifizierten Informationen abfragbar oder nur mit Aufwand und Performanceverlust, wie z.B. Vergleich numerischer Datentypen, alle Kinder beliebiger Hierarchieebene eines konkreten Knotens.

7. Die Bereitstellung von XML-Teilbäumen als Ergebnismenge ist nur bedingt möglich.

8. Die Performance sinkt mit der Anzahl der gespeicherten Knoten und der Anzahl der Treffer. Sie ist unter anderem abhängig vom konzeptionellen Datenbankschema, der Wahl des Datenbanksystems und der Optimierung der Datenbankinstanz.

85

Selbständigkeitserklärung

Hiermit erkläre ich, daß ich die hier vorliegende Arbeit selbständig, ohne unerlaubte fremde Hilfe und nur unter Verwendung der in der Arbeit aufgeführten Hilfsmittel angefertigt habe.

Ort, Datum (Unterschrift)