Humboldt-Universität zu Berlin · Letztlich sind konkrete Indexe für den AST/TA P1 zu...

Humboldt-Universität zu Berlin

Institut für Informatik

Lehrstuhl für Datenbanken und Informationssysteme

Indexierung von XML-Dokumenten:

Entwurf und Implementation für

die AST/TAP-Datenstruktur

Diplomarbeit von Karsten Lücke

Berlin, im März 2003

Erstgutachter: Prof. Johann-Christoph Freytag, Ph.D.Zweitgutachter: Dipl.-Inf. Dieter Sche�ner

Betreuer: Dipl.-Inf. Dieter Sche�ner

Inhaltsverzeichnis

1 Einleitung 111.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Konventionen für Sprache und Schrift . . . . . . . . . . . . . . . . . 12

2 Grundlagen 152.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Markup & logische Struktur . . . . . . . . . . . . . . . . . . . 152.1.2 Aufbau eines XML-Dokumentes . . . . . . . . . . . . . . . . 162.1.3 Wohlgeformte und gültige XML-Dokumente . . . . . . . . . . 182.1.4 Physische Struktur . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Charakterisierung des Retrievals auf XML-Dokumenten . . . . . . . 212.2.1 Information Retrieval (IR) versus Data Retrieval (DR) . . . . 232.2.2 Information Retrieval (IR) . . . . . . . . . . . . . . . . . . . . 242.2.3 Text-Normalisierung . . . . . . . . . . . . . . . . . . . . . . . 252.2.4 Data Retrieval (DR) . . . . . . . . . . . . . . . . . . . . . . . 262.2.5 Anfrage-Klassi�zierung . . . . . . . . . . . . . . . . . . . . . 27

2.3 Das XEE - Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.1 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.2 Die AST/TA-Datenstruktur . . . . . . . . . . . . . . . . . . . 302.3.3 Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Anforderungen 333.1 Anfragen: Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.1 Suche nach Zeichenfolgen . . . . . . . . . . . . . . . . . . . . 333.1.2 Suche nach Wörtern . . . . . . . . . . . . . . . . . . . . . . . 343.1.3 Suche nach Phrasen . . . . . . . . . . . . . . . . . . . . . . . 343.1.4 Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.5 Zuordnung zu IR / DR . . . . . . . . . . . . . . . . . . . . . 36

3.2 Anfragen: Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.1 Suche nach Elementen (anhand ihres Namens) . . . . . . . . 363.2.2 Suche nach Attributen (anhand ihres Namens) . . . . . . . . 363.2.3 Pfad - Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.4 Anfragen: Reihenfolge (Sequenz) / Position . . . . . . . . . . 373.2.5 Anfragen: bezüglich Namensräumen (Namespaces) . . . . . . 37

3.3 Anfragen: Inhalt & Struktur . . . . . . . . . . . . . . . . . . . . . . . 383.3.1 Text-Suche in Elementen / Unterstrukturen . . . . . . . . . . 383.3.2 Werte-basierte Anfragen . . . . . . . . . . . . . . . . . . . . . 39

3

Inhaltsverzeichnis

3.4 Weitere Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . 393.5 Besondere Anforderungen des AST/TA . . . . . . . . . . . . . . . . 40

3.5.1 Namensraum - Index . . . . . . . . . . . . . . . . . . . . . . . 403.5.2 Entity - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.5.3 CData Section - Index . . . . . . . . . . . . . . . . . . . . . . 41

3.6 Übersicht Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Zugri�smethoden 434.1 Klassische Zugri�smethoden . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Allgemeines / Klassi�kation . . . . . . . . . . . . . . . . . . . 434.1.2 Baumstrukturierte Zugri�spfade . . . . . . . . . . . . . . . . 444.1.3 Hash-Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.4 Sekundäre Zugri�spfade . . . . . . . . . . . . . . . . . . . . . 484.1.5 Mehrdimensionale Zugri�spfade . . . . . . . . . . . . . . . . . 49

4.2 Zugri�smethoden für Texte . . . . . . . . . . . . . . . . . . . . . . . 504.2.1 Wort-Indexe . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.2 Zeichenketten-Suche . . . . . . . . . . . . . . . . . . . . . . . 54

4.3 Zugri�smethoden für Dokument-Strukturen . . . . . . . . . . . . . . 554.3.1 Erweiterung IR-Indexe um Struktur-Information . . . . . . . 554.3.2 Spezielle Struktur-Indexe . . . . . . . . . . . . . . . . . . . . 564.3.3 Pfad-Indexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3.4 Problem: Update . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Entwurf 635.1 Revision der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 63

5.1.1 Inhalts - Anfragen . . . . . . . . . . . . . . . . . . . . . . . . 635.1.2 Struktur - Anfragen . . . . . . . . . . . . . . . . . . . . . . . 665.1.3 Behandlung von Anfragen auf Inhalt & Struktur . . . . . . . 69

5.2 Element-(Namen-)Index . . . . . . . . . . . . . . . . . . . . . . . . . 715.2.1 Datenstruktur: Variante des B+-Baumes . . . . . . . . . . . . 715.2.2 Kostenbetrachtung . . . . . . . . . . . . . . . . . . . . . . . . 725.2.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3 Inklusions-Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.3.1 Naiver Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . 735.3.2 Ausnutzen der TextSurogate . . . . . . . . . . . . . . . . . . 735.3.3 Direkter Index: Element-Name → TextSurrogat . . . . . . . 735.3.4 Nutzung Element-Index: Element-Name → Node-ID . . . . . 745.3.5 Kostenbetrachtung . . . . . . . . . . . . . . . . . . . . . . . . 755.3.6 Optimierung Inklusionstest . . . . . . . . . . . . . . . . . . . 765.3.7 Weitere Optimierung: Seitenhierarchie als Vor�lter . . . . . . 77

5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6 Realisierung 816.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.1.1 Genutzte Datenstruktur . . . . . . . . . . . . . . . . . . . . . 816.1.2 Code-Nachnutzung . . . . . . . . . . . . . . . . . . . . . . . . 826.1.3 Element-Index . . . . . . . . . . . . . . . . . . . . . . . . . . 826.1.4 Pfad-Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4

Inhaltsverzeichnis

6.1.5 Integration in den AST/TAP . . . . . . . . . . . . . . . . . . 836.1.6 Schwierigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 846.1.7 Weitere Indexe . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.2 Analyse & Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.2.1 Kostenrelevante Eigenschaften des Baumes . . . . . . . . . . 856.2.2 Test MulValTree . . . . . . . . . . . . . . . . . . . . . . . . . 856.2.3 Gröÿe Element-Index . . . . . . . . . . . . . . . . . . . . . . . 876.2.4 Analyse Pfad-Index . . . . . . . . . . . . . . . . . . . . . . . 886.2.5 Test Pfad-Index . . . . . . . . . . . . . . . . . . . . . . . . . 88

7 Resüme / Ausblick 91

A Beispiel-Dokumente 93A.1 DTD für das XML-Dokument aus Abb. 2.2 . . . . . . . . . . . . . . 93A.2 XML-Dokument für den Test des Pfad-Indexes (in Abschnitt 6.2.5) . 93

5

Inhaltsverzeichnis

6

Abbildungsverzeichnis

2.1 Ein einfaches XML-Dokument . . . . . . . . . . . . . . . . . . . . . 152.2 Ein XML-Dokument . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Skizze der logischen Struktur des XML-Dokumentes aus Abb. 2.2 . 182.4 Physisch besteht ein XML-Dokument aus Entities. . . . . . . . . . . 192.5 xmldoc.dtd; DTD für das XML-Dokument aus Abb. 2.6 . . . . . . . 202.6 Erweitertes XML-Dokument, DTD siehe Abb. 2.5 . . . . . . . . . . 222.7 Klassi�zierung monothetic versus polythetic . . . . . . . . . . . . . 242.8 XML-Dokument, Inhalt und Struktur-Darstellung. . . . . . . . . . . 282.9 Einordnung von content-based & structured based sowie Daten & Infor-

mation Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.10 Abbildung von XML in ein AST/TA-Paar. . . . . . . . . . . . . . . 31

3.1 Bsp. für verschiedene Zugri�spfade zu eingebetteten Standard- Schema-Elementen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Einsparung von AST-Knoten durch Gleichbehandlung aller Zeichen-daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Klassi�kation der Verfahren für (eindimensionalen) Schlüsselzugri�aus [HR01] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 B-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 B+-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4 Skizze eines Digital-Baumes über dem Alphabet A..Z . . . . . . . . . 464.5 Trie, teilweise zur Liste entartet . . . . . . . . . . . . . . . . . . . . . 474.6 Patricia-Baum, äquivalent zum Trie in Abb. 4.5 . . . . . . . . . . . 474.7 Eingebettete und separat gespeicherte Verweislisten (nach [HR01]) . 484.8 Quadranten-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.9 Vergabe von UIDs zu jedem Knoten nach [LYYB77] . . . . . . . . . 574.10 XML-Dokument als (OEM-)Baum in Lore . . . . . . . . . . . . . . . 584.11 DataGuide für das XML-Dokument in Abb. 4.10 . . . . . . . . . . . 584.12 �Reverser Pfad�-Index für Dokument in Abb.2.3 . . . . . . . . . . . . 594.13 PAT-Phrasen über normalem und reversem Pfad . . . . . . . . . . . 594.14 Mittels der Relative Region Coordinates ist bei einem Update von

�U� nur ein Teil des Indexes betro�en. . . . . . . . . . . . . . . . . . 60

5.1 Wort-Index, nach Element(Namen) geclustert . . . . . . . . . . . . . 705.2 MulValTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.3 Der AST für ein XML-Dokument enthält direkt die TextSurrogate

für jedes Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.4 Die Hierachie der Elemente bestimmt die Seitenhierarchie des ASTP . . . 77

7

Abbildungsverzeichnis

5.5 ASTP : Seitenhierarchie & Beispiel-Verteilung von Elementen mit bestimm-ten Namen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.1 Blatt-Knoten: Einträge teilen sich in einen Teil mit fester und einenTeil variabler Länge. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2 Struktur-Skizze des XML-Test-Dokumentes . . . . . . . . . . . . . . 88

8

Tabellenverzeichnis

2.1 Abgrenzung von Information Retrieval und Data Retrieval nach VanRijsbergen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Zusammenfassung der zu unterstützenden Anfragen . . . . . . . . . 42

6.1 Zusammenfassung der Baum-Tests für die Datentypen int/int. . . . . 866.2 Zusammenfassung Tests auf dem Baum. Schlüssel: zufällig generierte

Zeichenkette zufälliger Länge, Wert: Ganzzahl. . . . . . . . . . . . . 86

9

Tabellenverzeichnis

10

1 Einleitung

1.1 Motivation

XML etabliert sich als Standard für die Speicherung von Informationen aller Art inder vernetzten Datenwelt. Ganz unterschiedliche Dokumente lassen sich mit XML�exibel strukturieren und so für jede beliebige Anwendung anpassen. Die benötigteStruktur-Information wird dabei � mit Hilfe einer standardisierten Syntax � stetsim Dokument selbst mit gespeichert. Damit eignen sich XML-Dokumente besondersfür den elektronischen Datenaustausch (EDI=Electronic Data Interchange), für dasautomatische Bearbeiten und Transformieren sowie vielfältige andere Applikatio-nen.Entsprechend wuchs und wächst die Zahl von XML-Dokumenten enorm. Derzeit

wird XML noch häu�g nur als Zwischenformat beim Datenaustausch eingesetzt.Entsprechend oft ist eine Umwandlung nach/von XML in andere Datenformateerforderlich. Hierbei werden erhebliche Ressourcen verbraucht, die eigentlich bes-ser zur direkten Verarbeitung von XML-Dokumenten eingesetzt werden könnten.Dazu ist jedoch eine native/direkte Speicherung (und Verarbeitung) von XML-Dokumenten notwendig.Aufgrund der zu erwartenden Gröÿe solcher XML-Repositories ist ein leistungs-

fähiges und e�zientes Verwaltungssystem erforderlich. Dieses System sollte auchalle Eigenheiten von XML direkt unterstützen, um die Möglichkeiten von XML vollauszuschöpfen. Verschiedene Ansätze/Versuche, XML-Dokumente in existierendeSysteme (wie RDBM-, OODBM- oder Information Retrieval-Systeme) zu �pressen�,erwiesen sich als unzulänglich. Auch besteht hier wieder die Notwendigkeit der Um-wandlung der internen Daten von und nach XML.

1.2 Aufgabenstellung

Im Rahmen des Forschungprojektes XEE (�XML Query Execution Engine�[S+])am Lehrstuhl für Datenbanken und Informationssysteme der Humboldt-Universitätzu Berlin wird eine Datenstruktur für die Speicherung von und den Zugri� auf XML-Dokumente entwickelt: genannt �Access Support Tree� (AST/TA). Das Ziel dervorliegenden Arbeit ist es, die Anfragee�zienz der oben genannten Datenstrukturunter Ausnutzung von Indexierung zu verbessern.Zu diesem Zweck wird zunächst untersucht, welche typischen Anfragen mit Hilfe

von Indexierung unterstützt werden müssen. In besonderem Maÿe soll hierbei die In-dexierung hinsichtlich sowohl der logischen Struktur als auch des textlichen Inhalts

11

1 Einleitung

von XML-Dokumenten untersucht werden. Neben neuen Modellen und Ansätzenwird auf die beiden groÿen Ein�uÿbereiche � Daten- und Information Retrieval� genauer eingegangen und ihre Rolle in Bezug auf XML, Inhalts- und Struktur-Anfragen untersucht.Aufbauend auf diese Untersuchung sollen �ideale� und umfassende Indexe für An-

fragen an XML-Dokumente unter Berücksichtigung der Besonderheiten der AST/TA-Datenstruktur entworfen werden. Letztlich sind konkrete Indexe für den AST/TAP1

zu implementieren, um das Anfrageverhalten des Systems zu verbessern.

1.3 Vorgehensweise

Erö�nen wird diese Arbeit die Erläuterung einiger Grundlagen [Kapitel 2], welchedas Verständnis der Arbeit erleichtern sollen.Wie schon erwähnt, ist das Ziel dieser Arbeit das Erweitern des AST/TAP um

geeignete und e�ektive Indexe. Indexe unterstützen immer konkret bestimmte An-fragen. So stellt sich die Frage, welche Art von Anfragen durch einem Index unter-stützt werden müssen. In Kapitel 3 werden typische Anfragen zusammengetragenund eine Übersicht von Anfrage-Arten erstellt. Bei vielen Anfragesprachen bzw.-systemen dominieren entweder Anfragen an die logische Struktur oder an den text-lichen Inhalt eines Dokumentes. In der vorliegenden Arbeit wird besonderen Wertdarauf gelegt, beide Anfragetypen gleichberechtigt ein�ieÿen zu lassen.Anschlieÿend gilt es in Kapitel 4, für die Anfrage-Arten geeignete Indexverfahren

zu �nden. Hierbei wird zuerst auf allgemeine und etablierte Index-Verfahren aus demDatenbank- und Textretrieval-Bereich eingegangen. Dem folgen einige interessante,neue Ansätze zur Indexierung von strukturierten Dokumenten.Wie die einzelnen Anfragen unterstützt werden können, wird in Kapitel 5 betrach-

tet. Kosten werden analysiert, konkrete Indexe entworfen und einige Details undOptimierungsmöglichkeiten diskutiert. Besondere Anforderungen des AST/TAP �als Zielplattform � �ieÿen mit ein.Kapitel 6: Implementation, Analyse und Test. Die Richtigkeit und Praxistaug-

lichkeit der gewonnenen Information kann bei der Implementierung der Indexe fürden AST/TAP überprüft werden. Die Implementation wird in C/C++ erfolgen.Kritische Punkte des Designs und der Implementation werden analysiert. Weiter-hin müssen Testfälle entwickelt werden, um die Funktionstüchtigkeit zu testen unddie Analysen zu überprüfen.Abschlieÿend folgt eine kurze Zusammenfassung der Arbeit sowie ein Ausblick

auf mögliche Ergänzungen und Verbesserungen.

1.4 Konventionen für Sprache und Schrift

Englische Fachbegri�e

Soweit möglich, werden fremdsprachliche Begri�e ins Deutsche übersetzt. Der er-sten Übersetzung des Fachbegri�es wird der Originalbegri� (kursiv in Klammern)1P steht hier für �persistent�. AST/TAP meint so die Implementation des AST/TA-Modells mitAusrichtung auf den sekundären Speicher.

12

1.4 Konventionen für Sprache und Schrift

beigefügt. Von da an wird nur noch die deutsche Übersetzung verwendet.Gerade auf dem Gebiet der Informatik haben sich jedoch einige englische Fach-

begri�e sehr stark etabliert; sie bezeichnen präzise bestimmte Sachverhalte bzw.Objekte. Durch eine Übersetzung würden weitere Begri�e neu erscha�en, deren Ver-wendung eher verwirren als das Verständnis fördern. Sehr gebräuchliche englischeFachbegri�e sollen deshalb durchgängig verwendet werden. Auch ihnen folgt bei derersten Nennung eine Übersetzung (kursiv in Klammern). Englische Fachbegri�e fol-gen der englischen Rechtschreibung; für ein einheitliches Bild werden Substantivejedoch wie im Deutschen groÿ geschrieben.

Abkürzungen

Für häu�g verwendete Begri�e werden gelegentlich Abkürzungen verwendet. Allenicht im Duden verzeichneten Abkürzungen werden vor der Verwendung eingeführt.

Hervorhebungen

Kursive Schrift wird verwendet, um die besondere Aufmerksamkeit des Lesers aufbestimmte Sachverhalte zu lenken.Alle Fachbegri�e werden bei der Einführung fett gedruckt.Beispiele im Text sowie Schlüsselwörter in Bezug auf solche werden in Schreib-maschinenschrift gefaÿt.

13

1 Einleitung

14

2 Grundlagen

Um das Verständnis der Arbeit zu erleichtern, wird in diesem Kapitel zunächst aufwichtige Grundlagen eingegangen.

2.1 XML

XML (eXtensible Markup Language) ist � wie HTML oder SGML � eine Doku-ment-Auszeichnungs-Sprache, welche es ermöglicht, zusätzlich zum eigentlichen Do-kumenttext weitere Information mittels Tags (Schildchen) in einem Dokument un-terzubringen. Zur Abgrenzung von �normalen Daten� sind Tags immer von spitzenKlammern umgeben. Die Gesamtheit der Tags (zuzüglich XML- und Dokument-Typ-Deklaration, s.u.) bilden das Markup (Auszeichnung).Ergo besteht ein XML-Dokument formal aus Markup und Zeichendaten

(character data, s.a. [GQ99]). Grundsätzlich werden in XML alle Daten als Textbehandelt (daher sind auch keine Anführungsstriche oder Hochkommata notwen-dig). Spezielle Kennzeichnung und Verwendung von Daten anderen Typs ist zwarmöglich, soll hier jedoch nicht weiter vertieft werden.

2.1.1 Markup & logische Struktur

Wie in HTML enthalten die Tags Information über die logische Struktur des Doku-mentes. Während in HTML die Tags fest vorgeschrieben sind und vorwiegend dasLayout beschreiben, sind die Tags in XML frei de�nierbar.Im Gegensatz zu HTML � deren Tags in erster Linie das Layout des Dokumen-

tes bestimmen � wird hier Information über die logische Struktur des Dokumentesgespeichert. Ein Beispiel: Abbildung 2.1 zeigt ein einfaches XML-Dokument. Paarevon einem Start-Tag und einem Ende-Tag schlieÿen einzelne Textteile eines Do-kumentes (in XML: Elemente) ein und geben Aufschluÿ über die Bedeutung derdazwischen liegenden Information.

<book><author> Karsten Lücke </author><title> Indexe für ein XML-Repository </title>

</book>

Abbildung 2.1: Ein einfaches XML-Dokument

Jedes XML-Dokument besitzt ein ausgezeichnetes Element: das Document Ele-ment (Dokument Element, De�nition siehe [W3C01]). Dieses umfaÿt alle weiteren

15

2 Grundlagen

Elemente des XML-Dokumentes. Ein Element kann eine beliebige Folge von wei-teren Elementen und/oder Textdaten enthalten. Jedes Element hat einen Namen,welcher sowohl im Start-Tag als auch im Ende-Tag (in exakt gleicher Schreibweisemit Beachtung Groÿ-/Kleinschreibung!) enthalten sein muÿ. Zu jedem Start-Taggehört zwingend ein Ende-Tag; beide schlieÿen den Inhalt des Elementes ein. DasXML-Dokument in Abbildung 2.1 enthält demnach drei Elemente: book (das Do-cument Element), author und title. Die Elemente author und title enthaltenbeide ausschlieÿlich Text(daten); beide Elemente bilden den Inhalt von book.Elemente können weiterhin Attribute besitzen. Attribute werden über

�Name=Wert�-Paare realisiert und sind Bestandteil des Start-Tags (bzw. des Empty-Element-Tags) des zugehörigen Elementes. Empty-Element-Tags vereinen Start-Tag und Ende-Tag für sogenannte leere Elemente, d.h. Elemente ohne Inhalt (Bsp.:<published year="2003" />).Die logische Struktur eines beliebigen XML-Dokumentes kann als Baum darge-

stellt werden (siehe Bsp. in Abbildung 2.3). Um dokumentinterne Verweise zwi-schen Elementen zu ermöglichen, wurden spezielle Attributtypen eingeführt: IDund ID-Ref. Seien (A) und (B) zwei Elemente eines XML-Dokuments. Über einID-Attribut kann dem Element (A) ein Identi�kator � der innerhalb des XML-Dokumentes eindeutig sein muÿ � zugewiesen werden. Man erstellt einen Verweisvon (B) nach (A), indem man Element (B) eben jenem Identi�kator als Wert einesID-Ref-Attributes zuweist. Im XML-Dokument aus Abb. 2.2 wird z.B. das enthal-tene Bild (<figure>)[Zeile 26] aus dem laufenden Text über <Ref> in [Zeile 23]referenziert.Weiterhin können in einem XML-Dokument auftreten:Kommentare (comments)

und Processing Instructions (PI) (Bearbeitungs-Anweisungen). Kommentaregehören zum Markup und können � auÿerhalb anderer Tags � an beliebiger Stellein ein XML-Dokument eingefügt werden. Kommentar-Tags werden wie folgt gebil-det: .Über PIs können an externe Anwendungen Bearbeitungsanweisungen übergeben

werden, so z.B. das Starten eines Betrachters zur Darstellung eines (im XML-Dokument) referenzierten Bildes. Oder eine Anweisung an den Drucker, beim Aus-druck an bestimmter Stelle einen Seitenumbruch einzufügen, wie im Beispiel-Doku-ment aus Abb. 2.2 [Zeile 13]. Obwohl die XML-Spezi�kation dies zuläÿt, ist zuüberlegen, inwieweit es sinnvoll und sicherheitstechnisch vertretbar ist, daÿ fremdeXML-Dokumente den Start von Programmen auf dem lokalen Rechner veranlassenoder diese steuern können.

2.1.2 Aufbau eines XML-Dokumentes

Bisher wurde � der Einfachheit halber � nur die Instanz eines XML-Dokumentesbetrachtet. Formal besteht ein vollständiges XML-Dokument jedoch aus drei Teilen,wobei (1) und (2) optional sind:

(1) XML-Deklaration

(2) Dokument-Typ-Deklaration

(3) XML-Dokument-Instanz

16

2.1 XML

1 2 <book>3 <author> Karsten Lücke </author>4 <title>5 <published year="2003"/> Indexe für ein XML-Repository6 </title>78 <section>9 <title> Motivation </title>10 <paragraph> Für die e�ziente Verwaltung groÿer Sammlungen von11 XML-Dokumenten werden e�ziente Indexe benötigt... </paragraph>12 </section>13 <?psprinter pagebreak?>14 <section>15 <title> Grundlagen </title>16 17 <paragraph> Ein paar Grundlagen ... </paragraph>18 <section>19 <title> XML </title>20 <paragraph> XML ist ... </paragraph>21 <section>22 <title> Markup und logische Struktur </title>23 <paragraph> ... <Ref Reference="struktur"> Abbildung 1 </Ref>24 zeigt die logische Struktur eines XML-Dokumentes.25 </paragraph>26 <figure id="struktur"27 source="doc_struc_img"/>28 </section>29 ...30 </section>31 </section>32 </book>

Abbildung 2.2: Ein XML-Dokument

Ist (1) vorhanden, muÿ die XML-Deklaration das XML-Dokument erö�nen. Siedeklariert das vorliegende Dokument als XML-Dokument und spezi�ziert die Ver-sion und die zu benutzende Zeichenkodierung. Für die aktuelle XML-Version undtypische Kodierung würde diese wie folgt aussehen:<?xml version="1.0" encoding="UTF-8"?>

(2) kann ein Schema für das vorliegende Dokument (z.B. in Form eines XML-Schemas, einer internen oder externen DTD) enthalten. Um dem XML-Dokumentaus Abb. 2.2 eine externe DTD(siehe Anhang A.1) zuzuweisen, könnte man derInstanz voranfügen:<!DOCTYPE book SYSTEM "xmldoc.dtd">

(3) enthält die Dateninstanz, beziehungsweise den eigentlichen Dokumentinhalt.Dieser besteht in erster Linie aus dem Document Element (und seinem gesamtenInhalt). Nur Kommentare und PIs können zusätzlich (auch auÿerhalb des DocumentElements) hier auftreten.

17

2 Grundlagen

element

para

section

title

comment

PI

published

{year = 2003}

titleauthor

section

title

commentpara

figure

section

titlepara

bookLegende=======

{attribute=x}

comment,

... ...

...

...

{source = doc_struc_img}{id = strukur}

PI etc.

Abbildung 2.3: Skizze der logischen Struktur des XML-Dokumentes aus Abb. 2.2

2.1.3 Wohlgeformte und gültige XML-Dokumente

Man unterscheidet in XML wohlgeformte (wellformed) und gültige (valid) XML-Dokumente.Die Anforderungen an �wohlgeformte� XML-Dokumente sind relativ gering. Die

�Verschachtelung� der Elemente muÿ korrekt erfolgen (wie Klammern in mathemati-schen Formeln) und alle Attribute müssen eindeutig sein. �Eindeutig� heiÿt, es darfnicht mehr als ein Attribut mit demselben Namen zu einem Element existieren.Gültige XML-Dokumente müssen darüber hinaus vollständig ihrer angegebenen

DTD bzw. ihrem XML-Schema entsprechen. Mit anderen Worten: Sie müssen derdort angegebenen Grammatik genügen (Das XML-Dokument aus Abb. 2.2 ent-spricht der DTD aus Anhang A.1).

2.1.4 Physische Struktur

Physikalisch gesehen bestehen XML-Dokumente aus einer oder mehreren �Speicher-Einheiten�, sogenannten Entities. Der universelle Begri� Entity wurde gewählt, dasolche Einheiten verschiedene Formen annehmen können: Dateien, Zeichenfolgenetc.Ausgangspunkt ist die Document-Entity (das eigentlichen XML-Dokument,

mit dem gestartet wird). In ihr können diverse andere Entities über ihren Nameneingefügt bzw. referenziert werden. Ein Beispiel skizziert Abb. 2.4. Während dieEntity titel eine Zeichenfolge abbildet, verweisen book und doc_struc_img aufexterne Dateien (xmldoc.dtd bzw. xmldoc_stru.png).Deklariert werden Entities grundsätzlich innerhalb des zum Dokument gehören-

den Schemas. Für Details siehe [GQ99]; für Beispiele: Abbildung 2.6. Man unter-scheidet:

Internal und External Entities

Die Deklaration von internal Entities (interne Entities) erfolgt über die direkteZuweisung einer Zeichenfolge zu einem Entity-Namen. Deklarationen von exter-nal Entities (externe Entities) werden mit dem Schlüsselwort �SYSTEM� bzw.

18

2.1 XML

section

title

section

title

commentpara

published

book

author

Unparsed External Entity (xmldoc_stru.png)

Document element (xmldoc3.xml)External Parameter Entity (xmldoc.dtd)

}<?xml version="1.0" encoding="UTF−8"?>

<!ELEMENT section (title, paragraph, section*, figure*)><!ELEMENT author (#PCDATA)><!ELEMENT figure EMPTY><!ATTLIST figure id ID #REQUIRED source ENTITY #REQUIRED><!ELEMENT paragraph (#PCDATA | Ref)*><!ELEMENT published EMPTY><!ATTLIST published year CDATA #REQUIRED>

<!ELEMENT Ref (#PCDATA)><!ATTLIST Ref Reference IDREF #REQUIRED>

<!NOTATION image SYSTEM "image/gif:image/jpg:image/png">

<book><author> Karsten Lücke </author>

<!−− Dies ist ein Beispiel− XML−Dokument −−>

...

<?xml version="1.0" encoding="UTF−8"?>

<!DOCTYPE book SYSTEM "xmldoc.dtd">

<published year="2003"/></title><section>

<figure ...source="doc_struc_img"/>

<!ENTITY doc_struc _img SYSTEM "xmldoc_stru.png" NDATA image >

<title> &Titel;

<!ENTITY Titel "Indexe für ein XML−Repository">

<!ELEMENT book (author, title, section+)>

<!ELEMENT title (published?, #PCDATA)>

Abbildung 2.4: Physisch besteht ein XML-Dokument aus Entities.

�PUBLIC� versehen und verweisen mittels einer URI1 auf eine Quelle auÿerhalbdes XML-Dokument.

Die Referenzierung einer Entity erfolgt direkt über ihren Namen (mit vorange-stelltem '&' bzw. '%' und nachgestelltem ';', siehe z.B. 'Titel'-Referenz in Abbildung2.6). Abgesehen von Unparsed External Entities (s.u.) werden Entity-Referenzenbeim Parsen des XML-Dokumentes durch ihre zugewiesene Zeichenfolge ersetzt(Ausnahmen siehe [GQ99]).

General und Parameter Entities

General Entities (allgemeine Entities) können z.B. genutzt werden, um mehrfachvorkommende Teile eines XML-Dokumentes einmal zu de�nieren und dann mehr-fach zu verwenden � oder auch, um einen Teil des XML-Dokumentes variabel zuhalten (für eine Änderung ist nur ein Ändern der Entity-De�nition nötig). GeneralEntities können überall in der XML-Dokument-Instanz referenziert werden (undsehr eingeschränkt innerhalb der DTD).

Zur Ersetzung von Teilen innerhalb einer DTD sind Parameter Entities gedacht.Sowohl General als auch Parameter Entities werden beim Parsen durch ihren zuge-wiesenen Wert ersetzt (für die Reihenfolge und weitere Details siehe [GQ99] bzw.[W3C]).

1Uniform Resource Identi�er. URIs ermöglichen die Lokalisation von Ressourcen im Internet.

19

2 Grundlagen

<?xml version="1.0" encoding="UTF-8"?><!ELEMENT book (author, title, section+)><!ELEMENT section (title, paragraph, section*, figure*)><!ELEMENT author (#PCDATA)><!ELEMENT figure EMPTY><!ATTLIST figure

id ID #REQUIREDsource ENTITY #REQUIRED

><!ELEMENT paragraph (#PCDATA | Ref)*><!ELEMENT published EMPTY><!ATTLIST published

year CDATA #REQUIRED><!ELEMENT Ref (#PCDATA)><!ATTLIST Ref

Reference IDREF #REQUIRED><!ELEMENT title (published?, #PCDATA)><!ENTITY Titel "Indexe für ein XML-Repository"><!ENTITY doc_struc_img SYSTEM "xmldoc_stru.png" NDATA image ><!NOTATION image SYSTEM "image/gif:image/jpg:image/png">

Abbildung 2.5: xmldoc.dtd; DTD für das XML-Dokument aus Abb. 2.6

Parsed und unparsed external Entities

External Entities können vom Typ parsed (analysiert) oder unparsed (nicht analy-siert) sein. Parsed external Entities verweisen immer auf gültige XML-Daten.Unparsed Entities können beliebige Daten enthalten. Sie benötigen entsprechend

eine XML-Notation(Bezeichnung), die spezi�ziert, welche Art von Daten vorliegen.Auch Notationen müssen deklariert werden. Die Zuweisung von MIME-Typen2 anzu verwendende Notationen ist oft eine gute Idee. Daten von Unparsed Entitieswerden niemals direkt in ein XML-Dokument einfügt. Sie werden referenziert, indemeinem Element ein Entity-Attribut mit dem Namen der unparsed Entity als Wertzugewiesen wird. Ein XML-Parser stellt keinerlei weitere Überprüfungen an, dieDaten einer unparsed Entity werden zusammen mit der Notation bei Bedarf direktan die Anwendung übergeben.

Character References & vorde�nierte Entities

Character References (Zeichen-Referenzen) sind eine Möglichkeit, Zeichen an-hand ihres numerischen Wertes im Unicode Zeichensatz (ISO/IEC 10646) zu re-ferenzieren. Dies kann praktisch (z.B. zur Darstellung von auf der Tastatur nichtvorhandenen Zeichen ) oder auch notwendig sein ( �Escapen� (�Schützen vor In-terpretation�) von nicht erlaubten Zeichen). Z.B. ist das Zeichen '<' innerhalb des2�Multipurpose Internet Mail Extension� (Mehrzweck-Erweiterung für �Internet-Post� (besser:elektronische Post)). Ehemals als Erweiterung für E-mail erfunden, ist MIME heute ein bedeu-tender Internet-Standard, den Inhalt von Dateien anhand von Kategorie und Unterkategoriezu spezi�zieren und damit den Umgang mit diesen Dateien zu steuern

20

2.2 Charakterisierung des Retrievals auf XML-Dokumenten

Textinhaltes eines Elementes nicht erlaubt (es würde als Beginn eines neuen Tagsinterpretiert).Für häu�g gebrauchte � jedoch in bestimmten Kontexten verbotene � Zeichen

sind einige (internal general) Entities in XML vorde�niert:

Zeichen & < > � 'Entitity Referenz & < > " '

CDATA Sections

Wie im vorigen Abschnitt erwähnt, haben einige Zeichen in bestimmten Kontexteneine Sonderbedeutung. Diese können durch Character References oder vorde�nier-te Entities ersetzt werden; bei längeren Abschnitten ist dies jedoch umständlichbzw. schlecht lesbar. Praktischer ist hier die Verwendung von CDATA Sections(Zeichendaten-Abschnitten): Solche Abschnitte beginnen mit <![CDATA[ und en-den mit ]]>. Innerhalb des Abschnittes sind beliebige Zeichendaten erlaubt mitAusnahme von ]]>.

Beispiel und weiterführende Literatur

Abbildung 2.6 zeigt das schon bekannte XML-Dokument (jetzt besser: �Document-Entity�) � erweitert um XML-Deklaration, Dokument-Typ-Deklaration und einigeEntities. Als erste Entity wird die DTD (siehe Abbildung 2.5) referenziert. Hier�nden wir am Ende zwei weitere Entities: Die general parsed Entity �Titel� unddie unparsed Entity �doc_struc_img�. Letzterer wurde die Notation �image� zuge-wiesen, deren Deklaration darüber Auskunft gibt, daÿ es sich um Daten einer derMIME-Typen �image/gif�, �image/jpg� oder �image/png� handelt.Als weiterführende Literatur bietet [HS95, Kap. 14.3.3] oder [Bos00] einen kurzen

Einblick in XML; in [GQ99] bzw. unter [W3C] �ndet man eine genaue Beschreibungdes Standards.

2.2 Charakterisierung des Retrievals aufXML-Dokumenten

XML-Dokumente werden als semi-strukturierte Daten klassi�ziert. Entsprechendsoll Erfahrung über semi-strukturierte Daten hier direkt ein�ieÿen. Relevante Lite-ratur über Management- bzw. Anfragesysteme für semi-strukturierte Daten / Do-kumentsammlungen stützen sich fast ausschlieÿlich auf Ideen, Anfragemöglichkeitenund Techniken aus zwei Bereichen:

1. Information Retrieval (Informations Retrieval).

2. Anfrage-Techniken/Anfragesprachen aus dem Datenbankbereich (oder allge-meiner gehalten: dem Data Retrieval (Daten- oder Fakten Retrieval).

21

2 Grundlagen

1 <?xml version="1.0" encoding="UTF-8"?>2 <!DOCTYPE book SYSTEM "xmldoc.dtd">34 <book>5 <author> Karsten Lücke </author>6 <title>7 <published year="2003"/> &Titel;8 </title>910 <section>11 <title> Motivation </title>12 <paragraph> Für die e�ziente Verwaltung groÿer Sammlungen von13 XML-Dokumenten werden e�ziente Indexe benötigt. Dieses Werk zeigt14 auf, welche Indexe benötigt werden und wie sie umgesetzt werden.15 ... </paragraph>16 </section>17 <?psprinter pagebreak?>18 <section>19 <title> Grundlagen </title>20 21 <paragraph> Ein paar Grundlagen ... </paragraph>22 <section>23 <title> XML </title>24 <paragraph> XML ist ... </paragraph>25 <section>26 <title> Markup und logische Struktur </title>27 <paragraph> ... <Ref Reference="struktur"> Abbildung 1 </Ref>28 zeigt die logische Struktur eines XML-Dokumentes.29 </paragraph>30 <figure id="struktur"31 source="doc_struc_img"/>32 </section>33 ...34 </section>35 </section>36 </book>

Abbildung 2.6: Erweitertes XML-Dokument, DTD siehe Abb. 2.5

22


2.2.1 Information Retrieval (IR) versus Data Retrieval (DR)

Wodurch unterscheiden sich Information Retrieval und Data Retrieval? Schon VanRijsbergen ging in [Rij79] auf die Unterschiede zwischen Daten Retrieval und Infor-mation Retrieval (siehe Tabelle 2.1) und schreibt hierzu:Im DR wird vom Nutzer eine komplette Spezi�kation dessen, was er sucht (Que-

ry speci�cation), erwartet. Dazu steht dem Nutzer eine (künstliche) Anfragesprachemit vorgeschriebener Syntax & Wortschatz zur Verfügung (Query language). AlsErgebnis erwartet er die Menge der Objekte, welche exakt seinen Spezi�kationenentsprechen (Matching/Items wanted). Da eine exakte Übereinstimmung gefordertwird, führen selbst kleine Fehler in nur einem der Auswahlkriterien � auch falscheoder abweichende Schreibweisen � notwendigerweise zu einem Ausschluÿ von Ob-jekten aus der Ergebnismenge (Error response).Im IR wird die eher natürliche Sprache zur Anfragespezi�kation genutzt. Eine

genaue, festgelegte Syntax zur Spezi�kation des Gesuchten steht selten zur Ver-fügung; entsprechend ist die Spezi�kation i.d.R. unvollständig (�incomplete�). Imeinfachsten Fall besteht eine Anfrage aus ein oder mehreren Begri�en, welche imErgebnisobjekt vorkommen sollen. Gesucht werden im Gegensatz zum DR nichtgenaue Übereinstimmungen, sondern relevante Objekte � Objekte, welche mit denSuchbegri�en möglichst viel gemein haben. Entsprechend muÿ ein IR-System relativunanfällig gegen kleine Fehler/Abweichungen sein(Error response).Analog der Exaktheit bei Anfragespezi�kation und Matching wird beim DR eine

monothetic Klassi�zierung bevorzugt: Welche Objekte zu einer Klasse gehören, wirddurch festgelegte Attribute bestimmt. Deren Existenz ist sowohl notwendige alsauch hinreichende Bedingung für die Zugehörigkeit zur Klasse. In IR wird eher einepolythetic Klassi�kation gewünscht: Jedes Objekt einer Klasse besitzt nur einenTeil der Obermenge der Attribute aller zur Klasse gehörenden Objekte (⇒ keinAttribut ist notwendig oder hinreichend). Abbildung 2.7 skizziert den Unterschiedzwischen monothetic und polythetic .Weiterhin nutzt DR einfaches induktives Schlieÿen zur Bestimmung der Ergeb-

nismenge (d.h.: aRb∧

bRc ⇒ aRc). In IR ist induktives Schlieÿen gebräuchlicher,Beziehungen werden nur mit einem bestimmten Grad an Gewiÿheit / Bestimmtheitfestgelegt, d.h. das Vertrauen in die Schluÿfolgerung variiert. Hieraus folgt, daÿ DRdeterministisch arbeitet, IR Wahrscheinlichkeits(theorie)-basiert.

Data Retrieval Information RetrievalMatching Exact match Partial match, best matchInference Deduction InductionModel deterministic ProbabilisticClassi�cation Monothetic PolytheticQuery language Arti�cial NaturalQuery speci�cation Complete IncompleteItems wanted Matching RelevantError response Sensitive Insensitive

Tabelle 2.1: Abgrenzung von Information Retrieval und Data Retrieval nach VanRijsbergen

23

2 Grundlagen

A B C D E F G H

monothetic

4 + + +3 + + +2 + + +1 + + +

5 + + +6 + + +7 + + +8 + + +

polythetic

monotheticObj

ekte

Attribute

Abbildung 2.7: Klassi�zierung monothetic versus polythetic

Aus heutiger Sicht scheinen die in der Tabelle hervorgehobenen Punkte (kursiv)besonders erwähnenswert; deshalb wird im Folgenden hierauf noch besonders ein-gegangen.

2.2.2 Information Retrieval (IR)

Seinen traditionellen Ursprung hat das Information Retrieval in Literatur-Daten-banksystemen. Beim klassischen IR wird jedem Dokument (bzw. Buch, Bericht etc.)gezielt eine Menge von Begri�en (�Deskriptoren�, �Schlüsselwörtern�) zugeordnet,welche das Dokument inhaltlich repräsentieren ([SM87, Kap. 1.4]). Die Auswahl derBegri�e ist ein komplexer Prozeÿ (siehe [SM87, Kap. 3]) und bestimmt entscheidenddie Güte des Systems. Erwähnt sei nur die Möglichkeit, den Informationsgehalt ein-zelner Wörter mit zu berücksichtigen. Es existieren vielfältige Weiterentwicklungenund Verbesserungen. Wichtigster Punkt ist jedoch nach wie vor, den Inhalt vonDokumenten abzubilden und über Anfragen zugänglich zu machen.Eine Anfrage besteht entsprechend im einfachsten Fall aus ein oder mehreren

Begri�en, welche im Dokument vorkommen sollen bzw. welche den Inhalt gut be-schreiben. Das IR-System wählt daraufhin jene Objekte aus, die den Kriterien ambesten (nicht notwendigerweise syntaktisch exakt! ↗ vage Anfragen, s.u.) entspre-chen. Kleine Abweichungen in einzelnen Kriterien führen nicht notwendigerwei-se zum Ausschluÿ des Dokumentes aus der Ergebnismenge sondern nur zu einerschlechteren Gesamtwertung.Zentrale Probleme beim IR sind somit die Bestimmung der Relevanz eines

Objektes und das Ranking (Bestimmung der Wertung, Reihenfolge). Statt desRankings kann auch eine einfache boolesche Verknüpfung der einzelnen Suchbegri�edurchgeführt werden; dies ist besonders bei Internet-Such-Maschinen beliebt.

Bsp.: Wir suchen Literatur über Indexe für XML-Dokumente.Search for: Index AND XML AND Document

Man sieht, daÿ auch die Suchkriterien äuÿerst selten exakt bestimmt werden (oftschwierig bestimmbar sind). Man spricht hier von vagen Anfragen (siehe auch[Lü01, 2.4], [Ges], [Fuh97]). Da der Nutzer sehr selten eine genaue Kenntnis über

24


Struktur und Inhalt der Datenbasis hat, wird er kaum auf die erste Anfrage ei-ne vollständig befriedigende Ergebnismenge erhalten. Vielmehr wird er in einemiterativem Dialog mit dem IR-System das Ergebnis Schritt für Schritt verbessern.Hier spielt ein weiterer wichtiger Punkt eines IR-System mit hinein: das Feedback(englisch für Relevanz-Rückmeldung) des Nutzers. Es kann in einer einfachen Refor-mulierung der Anfrage bestehen oder in direkter Information, welche Objekte desZwischenergebnisses für den Nutzer interessant sind (bzw. nicht), welche zusätzli-chen Eigenschaften diese noch aufweisen sollten etc. etc.Von einem IR-System wird mehr verlangt, als nur rein syntaktische Text-Suche.

Damit wichtige Dokumente nicht von vornherein aus dem Ergebnis ausgeschlossenwerden(s.o.), sollte es u.a.:

• auch unterschiedliche Schreibweisen, Plural von Begri�en etc. �nden(⇒3 z.B. Finden von �On Indices Suitable for XML Documents�),

• Synonyme und Ontologien berücksichtigen (⇒3 z.B. Finden von �Indexingsemistructured data�; da XML ⊂ semi-strukturierte Daten ),

• ggf. auch Dokumente berücksichtigen, welche nicht alle Kriterien erfüllen(⇒3 z.B. Finden von �An Indexing Scheme for Structered Documents�).

Anmerkung: Die ersten beiden Punkte können die Suche extrem aufwendig wer-den lassen, eine Text-Normalisierung kann die E�zienz jedoch um Gröÿenordnungensteigern (siehe nächster Abschnitt).IR hat den Vorteil, daÿ die zu durchsuchenden Daten keinerlei Strukturierung

aufweisen müssen und auf beliebige Datenarten ganz gleich ob Text, Gra�k, Au-dio etc. anwendbar sind. Da XML-Dokumente hauptsächlich Textdaten enthalten,möchten wir uns hier auf IR-Methoden für Text beschränken. Als weiterführendeLiteratur zu IR siehe [Fuh97], [Ges], [Bec98], [KR98] und [Fer99].

2.2.3 Text-Normalisierung

Unter Text-Normalisierung versteht man das Ausführen einer Reihe von Nutzer-de�nierten Transformationen auf dem Originaltext (und der Anfrage), welche dieTextinhalte in gewisser Weise standardisieren und somit die Suche vereinfachensollen [BY, BY92]. Übliche Transformationen sind u.a:

• Mapping von Zeichen (z.B. Umwandeln aller Groÿbuchstaben in Kleinbuch-staben⇒ case-insensitive Suche möglich (keine Beachtung der Groÿ-/Klein-schreibung)),

• Entfernen von Sonderzeichen,

• Ersetzen von �white spaces� (Zeilenwechsel, Tabulatoren, Leerzeichen) undFolgen dieser durch ein einzelnes Leerzeichen,

• De�nition von Wort-Trenn/Fortsetzungs-Zeichen und deren Behandlung,3für obige Beispielsuche würde dies bedeuten...

25

2 Grundlagen

• Entfernen von sehr oft vorkommenden Wörtern, welche für die Suche gerin-gen Wert besitzen (z.B. Artikel: �der�, �die�, �das� etc. � sogenannten �stop-words�),

• Ersetzen von Synonymen durch einen festgelegten eindeutigen Term,• Zurückführen von Wörtern auf Ihren Wortstamm,• Transformation verschiedener Buchstabierungs-Varianten mit Hilfe vonSoundex-Methoden (Finden �ähnlich klingender� Wörter),

• Überführung von Zahlen und Daten in ein Standardformat.

Neben der Vereinfachung der Text-Suche kann eine Text-Normalisierung den Spei-cherplatzbedarf eines aufzubauenden Indexes und die Suchzeiten stark mindern,ohne die Leistungsfähigkeit nennenswert einzuschränken (s.a. [MS99], [FM96]). Je-doch bringt sie immer einen mehr oder weniger groÿen Informationsverlust mit sich.Nach der Durchführung obiger Transformationen können wir z.B. nicht mehr nachSonderzeichen, speziellen �white spaces� oder ersetzten Synonymen suchen; auchcase-sensitive Suche sowie die Suche nach Wortfolgen, welche oft vorkommendenWörter enthalten, sind nicht möglich.Für viele Transformationen ist es zweckmäÿig, die Datenbasis normalisiert in den

Index ein�ieÿen zu lassen. Dann ist zu beachten:

• vor der Indexierung muÿ feststehen, welche Normalisierung gewünscht wird• es ist nur eine Normalisierung (per Index) umsetzbar.

2.2.4 Data Retrieval (DR)

Beim DR werden immer alle Objekte/Datensätze erwartet, welche die Anfragekri-terien exakt erfüllen. Bedenkt man die Gröÿe heutiger Datenbanken, so ist einegroÿe Einschränkung der Ergebnismenge notwendig, um den Nutzer nicht mit ei-ner riesigen Anzahl von zurückgelieferten Objekten zu �überschwemmen�. Hierzuleistet die exakte Überprüfung der Anfragekriterien ihren Beitrag und garantiertgleichzeitig die absolute Korrektheit des Ergebnisses (vollständiges Erfüllen allerAnforderungen). Dies führt jedoch auch dazu, daÿ alle Datensätze, welche nur diekleinste Abweichung aufweisen, nicht als Ergebnis erkannt werden.

Bsp.: Wir suchen die Telefonnummer eines Herrn Meier aus der Lindenstr. 24 inBerlin:

SELECT telnr FROM telefonbuch WHEREnachname="Meier" AND strasse="Lindenstr. 24" AND ort="berlin";

Falls Herr Meier sich nun mit y schreibt (�Meyer�) werden wir ihn mit der Suchenach �Meier� nie �nden, auch wenn unsere anderen Angaben alle korrekt sind undvielleicht nur einige wenige Datensätze klassi�zieren.Typische Vertreter des Data Retrieval sind die Datenbank-Anfragesprachen.

Grundlage für jede Anfrage ist hier die Struktur der Datenbasis � auch als Meta-daten bezeichnet. Auch XML-Dokumente haben eine Struktur (siehe 2.1.1 und Bsp.

26


in Abbildung 2.3), eine Diplomarbeit ist z.B. in Überschriften, Kapitel, Absätze etc.gegliedert. Datenbanktypische Anfragen setzen zwar zwingend eine wohlde�nierteStruktur und Semantik der Datenbasis voraus, bieten dafür jedoch interessante An-fragemöglichkeiten:

(1) Anfragen an die Struktur des Dokumentes

Bsp: Gib mir alle Titel von Büchern aus der Bibliographie-Datenbank.

(2) attributierte Anfragen: Der Benutzer kann (ggü. IR) viel exakter spezi�zieren,was er genau sucht, indem er angibt, in welchem Teil des Dokumentes einbestimmter Inhalt vorkommen soll

Bsp: Suche 'Meyer' ↔ suche 'Meyer' im Feld 'Autor'. Dadurch ist eine vielbessere Einschränkung der Ergebnismenge möglich und die Anfragenwerden �tre�sicherer�.

(3) Ausnutzung von Datentypen: Es ist möglich, typspezi�sche Operationenanzuwenden (z.B. Vergleich, Bereichsanfragen, ...)

Bsp: Gib mir alle Bücher, welche in den Jahren 1998-2002 verö�entlicht wur-den.

(4) Verknüpfung und Re-Strukturierung: Der Benutzer kann vorhandene Daten(möglicherweise aus verschiedenen Quellen) beliebig miteinander verknüpfenund daraus neue Information gewinnen. Auÿerdem kann er dem Ergebnis eineneue Struktur verleihen (lassen). Da dies jedoch mit dem Thema dieser Arbeit(e�zienter Zugri� auf Daten) wenig zu tun hat, soll der letzte Punkt hierunberücksichtigt bleiben.

2.2.5 Anfrage-Klassi�zierung

Im Folgenden sollen die Anfragemöglichkeiten des Data- und Information Retrievalszusammengefaÿt und klassi�ziert werden, um ein Bild von möglichst umfassenderFunktionalität zu erhalten.Die Hauptfunktionalität des klassischen IR kann man kurz als �Inhaltliche Suche

in Texten� beschreiben. Über verschiedene Methoden (Stichwort-Vergabe für Text-Dokumente; Klassi�zierung; Abbildung von logischen, semantischen und Layout-Sichten über Dokumenten - siehe [Fuh97]) wird versucht, den Inhalt des Dokumentesabzubilden und über Anfragen zugänglich zu machen. Ergänzt wird dies i.d.R. übereine Volltext-Suche auf der Datenbasis [BYN99]. In der Literatur hat sich hierfür derBegri� inhalts-basiertes Retrieval (content based Retrieval) etabliert. Was wirunter dem Inhalt eines XML-Dokumentes im besonderen verstehen, soll Abbildung2.8 skizzieren.Dagegen stützen sich Operatoren von Datenbank-Anfragesprachen bei der Aus-

wahl der Ergebnis-Objekte hauptsächlich auf die Struktur der Datenbasis. SolcheAnfragen sollen im Folgenden unter dem Begri� Struktur Anfragen zusam-mengefaÿt werden. Man beachte, daÿ es sich bei den Beispielen aus dem vorigenAbschnitt nur bei (1) um eine reine Strukturanfrage handelt, die anderen betrach-ten zusätzlich den Inhalt � jedoch nachgeordnet. Auch viele (Vorschläge für) XML-

27

2 Grundlagen

<paper year = �1998�><title> Indexing semistructured Data </title><author> J. McHugh </author><author> J. Widom </author><author> S. Abiteboul </author>...<section><title> Abstract </title><para> This paper describes techniques for building andexploiting indexes on semistructured data: data that maynot have a �xed schema and that may be irregular orincomplete. ... </para>...</section><section><title>1 Introduction </title><para> We call data that is irregular or that exhibits typeand structural heterogeneity semistructured, since it maynot conform to a rigid, prede�ned schema. Such data arisesfrequently on the Web ... </para></section><section><title>1.1 Related Work</title><para> A description of the Lore architecture and queryexecution engine can be found in [MAG + 97]. Lore'scost-based query optimizer was introduced ...</para></section><section><title>1.2 Paper Outline </title><para> Section 2 provides a brief introduction to the datamodel and query language used in Lore and ... </para></section></section><section><title>2 Preliminaries and Motivation </title><para> To set the stage for our discussion of indexingsemistructured data, ...</para>...</section>...</paper>

(a) XML-Dokument-Ausschnitt

Indexing semistructured DataJ. McHugh J. Widom S. Abiteboul ...

Abstract

This paper describes techniques for building andexploiting indexes on semistructured data: datathat may not have a �xed schema and that may beirregular or incomplete. ......

1 IntroductionWe call data that is irregular or that exhibitstype and structural heterogeneity semistructured,since it may not conform to a rigid, prede�nedschema. Such data arises frequently on the Web ...1.1 Related WorkA description of the Lore architecture and que-ry execution engine can be found in [MAG + 97].Lore's cost-based query optimizer was introduced ......1.2 Paper OutlineSection 2 provides a brief introduction to thedata model and query language used in Lore and ...2 Preliminaries and MotivationTo set the stage for our discussion of indexingsemistructured data, .........

(b) Text-Inhalt

Abbildung 2.8: XML-Dokument, Inhalt und Struktur-Darstellung.

Anfragesprachen stützen sich bei Anfragen hauptsächlich auf die Struktur � so z.B.XPath/XQL, XML-QL, Quilt und XQuery.Auf der Suche nach mehr Funktionalität wurde in den letzten Jahren im IR-

Bereich damit begonnen, auch die existierende interne Struktur eines Dokumenteszu berücksichtigen � es entstand das �Structered Text Retrieval� (s.a. [BYN99]). Derzunehmende Ein�uÿ von Dokument-Kennzeichnungssprachen (wie HTML, SGMLund XML) � welche es ermöglichen, Struktur-Information syntaktisch in einemDokument mit abzulegen � hat hier sicher stark mit beigetragen.Analog versuchen Autoren von Datenbank-Anfragesprachen, die Funktionalität

in Richtung content based Retrieval zu erweitern. So scheinen sich auf den erstenBlick beide Bereiche langsam zu vermischen. Versuchen wir zu ordnen:Wie man sieht, kommt keine neue Funktionalität hinzu, wir müssen nur inhalts-

basierte Anfragen und Struktur-Anfragen entsprechend dem jeweiligen Kontext in-terpretieren. Beim Data Retrieval ist eine exakte Übereinstimmung der Kriteriengefragt; das Ergebnis ist homogen. Auf die Suche nach dem Wort �Index� erhal-ten wir die einfache Menge aller Dokumente, welche das Wort �Index� in exakterSchreibweise enthalten. Alle Dokumente erfüllen unsere Kriterien gleich gut - näm-lich exakt. Nicht mehr und nicht weniger. Weicht ein Dokument nur in kleinsterWeise ab (z.B. andere Schreibweise), wird es aus dem Ergebnis ausgeschlossen.Bei einer Information Retrieval Anfrage werden auch ähnliche Dokumente ge-

28

2.3 Das XEE - Projekt

Retrieval (IR)

Information Retrievalbasierend auf Struktur

Daten Retrieval

inhaltsbasiertes

Information Retrieval Daten Retrieval

* exakt* Fehler−sensitiv

* fehlertolerant

(* feedback)* Relevanz

* Ranking

* Ergebnis "monothetic"

Struktur−basierte Anfragen

Inhalts−basierte Anfragen

Anfragen auf Inhalt & Struktur Structured Text

Konzept der DatenbankAnfragesprachen

klassisches IR

IR

QL

Abbildung 2.9: Einordnung von content-based & structured based sowie Daten & Infor-mation Retrieval

funden. Die Suche nach dem Wort �Index� würde so z.B. auch Dokumente zurückliefern, welche �Indexierung� etc. (s.o.) enthalten. Weiterhin wird das Ergebnis ent-sprechend der Relevanz geordnet (beste Ergebnisse zuerst). Wichtung und Feedback(s.o.) können hierzu zusätzlich herangezogen werden.Viele Autoren von XML-Anfragesprachen/-systemem behaupten, sowohl Inhalt

als auch Struktur zu berücksichtigen. Schaut man in die Literatur oder auf exi-stierende Systeme, so stellt man fest, daÿ die Anfragemöglichkeiten fast alle ent-sprechend dem eben Erklärten entweder vorrangig auf der Struktur oder auf demInhalt basieren. Nicht nur Baeza Yates erkannte, daÿ die optimale Lösung nur in dergleichwertigen Kombination von content based Retrieval und Structered Retrievalbesteht (s.a. [BYN99]); wie sie z.B. in Proximal Nodes[NBY97] umgesetzt wurde.Anfragen, welche Operatoren sowohl aus dem Text Retrieval- als auch Struktur

Retrieval-Bereich kombinieren, sollen im weiteren unter dem Begri� Anfragen aufInhalt & Struktur zusammengefaÿt werden. Wie schon erwähnt, wird deshalbhauptsächlich von Text Retrieval gesprochen, da XML-Dokumente in erster LinieText-Daten enthalten.


Seit Sommer 2001 läuft am Lehrstuhl DBIS4 der HU zu Berlin die Entwicklungeines Anfragesystems für XML-Dokumente: das Projekt �XML Query ExecutionEngine� (XEE)[S+]).

2.3.1 Ziele

Ziel des Projektes ist die Erforschung neuer Wege der Speicherung, Verwaltungund Anfrage von XML-Dokumenten. Folgende Punkte werden dabei als besonderswichtig angesehen:4Lehrstuhl für Datenbanken und Informationssysteme (DBIS) des Institutes für Informatik ander Humboldt Universität zu Berlin

29

2 Grundlagen

• vollständige Unterstützung der Möglichkeiten von XML (konkret: Unterstüt-zung des kompletten XML Information Set[W3C01]),

• Unterstützung möglichst vielfältiger Anfragen � sowohl über Inhalt als auchStruktur von XML-Dokumenten (sprich: gleichrangige Unterstützung von Kon-zepten der Anfragesprachen und des Information Retrieval),

• Trennung von Struktur und Inhalt eines XML-Dokumentes (analog des Daten-bank-Grundkonzeptes der Trennung von Daten und Meta-Daten),

• Unterstützung des generischen Speicherns von XML-Dokumenten (unabhän-gig von der Nutzung/des Vorhandenseins irgendeines Schemas),

• E�zienz von Operationen auf Dokumenten � insbesondere dem Ändern vonStruktur und Inhalt.

Um die Eigenschaften von XML auf physischer Ebene besser zu unterstützen,wurde die Speicherung der XML-Dokumente von Grund auf neu überdacht. Esentstand die Access Support Tree / Text Array (AST/TA) - Datenstruktur. EineHauptspeicherimplementierung von AST/TA liegt vor. Derzeit wird das Systemzur dauerhaften Speicherung der Daten auf Sekundärspeicher erweitert (genanntAST/TAP für persistente AST/TA-Datenstruktur).

2.3.2 Die AST/TA-Datenstruktur

AST/TA[SC] wurde entwickelt, um XML-Dokumente e�zient zu speichern undverwalten zu können. Anfragen sowohl auf Struktur- als auch Text(inhalts)-Aspektesollen unterstützt werden.Die Grundidee von AST/TA ist die Trennung von (logischer) Struktur und Inhalt

eines XML-Dokumentes (Was im besonderen unter Textinhalt eines Dokumentesverstanden wird, skizzierte Abb. 2.8). Dazu wird der gesamte Textinhalt eines XML-Dokumentes � ohne Markup � als eine fortlaufende Zeichenkette dargestellt undin einem sogenannten TextArray (TA) gespeichert.Die logische Struktur (extrahiert aus dem Markup) wird getrennt in einer eigenen

Baum-Datenstruktur verwaltet. Diese wird als Access Support Tree (AST) bezeich-net, da sie Zugri� auf einzelne Elemente und deren Inhalt gewährt. Ein AST bildetdamit die komplette logische Struktur bzw. Hierarchie eines XML-Dokumentes ab.Ein kleines Beispiel: Abb. 2.10 zeigt einen Ausschnitt aus dem Beispieldokument

und seine Abbildung in ein AST/TA-Paar. Der AST besteht aus sieben Knoten (r,..., x), welche die einzelnen XML-Komponenten (vier Elemente, einen Kommentarund Textabschnitte) repräsentieren. Kanten zwischen den Knoten repräsentierenKind-/Eltern-Beziehungen (durchgezogene Linien).Die Knoten r, t, v und w bilden XML-Elemente ab, ihr Label (Beschriftung)

spiegelt den zugehörigen Elementnamen wieder. Eventuell vorhandene Attributewerden ebenfalls im AST gespeichert. Das �Name=Wert�-Paar jeden Attributes wirddem zugehörigen Elementknoten angefügt; siehe z.B. Knoten w (published) in derAbbildung.Knoten s repräsentiert einen Kommentar. Die Beschriftung solcher Knoten ent-

hält den kompletten Text des abgebildeten Kommentars (ohne die Begrenzer <!--

30


<book>

<author > Karsten Lücke </author> <title>

</title>

<published year="2003" /> Indexe für ein XML−Repository

<!−− Ein Beispiel−Dokument −−>

...

(14,29)xu (0,13)

(0,13)authort

(0,−1)DokumentEin Beispiel−

TextArray

r

Access Support Tree

book

Karsten Lücke#

w

(14,29)titlevs

published

(14,−1)year="2003"

Indexe für ein XML−Repository#

(0,43)

Abbildung 2.10: Abbildung von XML in ein AST/TA-Paar.

und -->). Zeichendaten � CData Sections etc. � werden im AST durch zusätzlicheingefügte Textknoten abgebildet. Diese Knoten (u, x) besitzen keine Beschriftung,sondern verweisen nur auf den zu ihnen gehörenden Text im TextArray.Die Kopplung von AST und TA erfolgt über so genannte TextSurrogate. TextSur-

rogate sind Zahlenpaare, wobei die erste Zahl den Beginn des zum Knoten gehören-den Abschnittes im TA spezi�ziert, die zweite dessen Länge. In der Abbildung sinddiese jedem Knoten in runden Klammern angefügt. (15,29) am Knoten v bedeutetz.B., daÿ der Titel im TextArray an Position 15 beginnt und 29 Zeichen lang ist.Knoten w zeigt eine Besonderheit auf: eine Länge von -1. Dieser Wert wurde ge-

wählt, um als leer de�nierte Elemente von Elementen mit der Länge Null (z.Zt. ohneInhalt) zu unterscheiden. Gestrichelte Linien veranschaulichen die Startposition derzu Knoten gehörenden Abschnitte im TA und die Überspannung.Um Veränderungen am AST e�zienter zu gestalten, enthält die Implementierung

zusätzlich O�sets für jeden Knoten. Weiterhin wird im TextArray der Beginn einesneuen Elementes/Textabschnittes mit einem speziellen Zeichen markiert (in derAbbildung durch '#' gekennzeichnet). Da hier jedoch nur ein Überblick gegebenwerden soll, wird für Details auf [SC] verwiesen.

2.3.3 Vorteile

Die Trennung von Struktur und Inhalt bringt mehrere Vorteile:

• Der Inhalt eines XML-Dokumentes ist stets �durchsetzt� mit Markup (Bsp.:Abbildung <ref> 2 </ref> zeigt ein XML-Dokument). Eine Anfrage auffortlaufenden Text wird somit problematisch, eine Filterung oder aufwendigeAlgorithmen sind nötig. Im TA wird der Text als ein fortlaufender Stringgespeichert. Anfragen auf fortlaufenden Text sind so problemlos und direktmöglich � auch über Elementgrenzen und mehrere Elemente hinweg.

31

2 Grundlagen

• Die (logische) Struktur ist wesentlich kompakter abbildbar, da der Textinhaltaller Elemente entfernt und extra gespeichert wird. Dadurch ist möglich:

� schnelleres Navigieren (Struktur beansprucht wenig Speicher, paÿt evtl.sogar in den Hauptspeicher),

� reine Anfragen auf die (logische) Struktur sind möglich, ohne überhauptauf den Textinhalt zuzugreifen ⇒ E�zienz(Bsp.: Welche Dokumente enthalten (mindestens) ein Element mit demNamen figure?),

� Ein Verändern der (logischen) Struktur � wie Umbenennung, Einfügenoder Löschen von Elementen � kann unter Umständen durchgeführtwerden, ohne auf den Textinhalt zuzugreifen ⇒ E�zienz.

• Über ein und demselben Text können mehrere Hierarchien aufgebaut werden.Bsp.:

(1) <person>Norbert Fuhr</person> beschreibt in<ref>[Fuhr97]</ref> ...

(2) <subject>Norbert Fuhr</subject> <pred>beschreibt</pred>... <object> ...

Besonderheiten

Im derzeitigen Stand des AST/TAP wird die gesamte Datenbasis nur als ein Doku-ment betrachtet (Vereinfachung).DTD's können in Form eines XML-Schema abgespeichert werden. Als solches

werden sie wie jedes andere XML-Dokument angesehen und genauso behandelt.

32

3 Anforderungen

Indexe unterstützen den e�zienten Zugri� auf gespeicherte Daten. Was zweckmäÿi-gerweise indexiert wird, hängt somit von der Art der Anfrage an die Datenbasis ab.Welche Funktionalität eine XML-Anfragesprache nach Meinung von Gremien ab-decken muÿ, ist in [W3C00] und [CFMR01] festgelegt; [Lü01] gibt einen Überblick.Ergänzt um Praxiserfahrung und Ideen relevanter Projekte und Modelle wird

im Folgenden versucht, die elementaren (simplen) Anfragetypen zu identi�zieren.Eingeordnet in die in 2.2.5 klassi�zierten Bereiche bilden sie die allgemeine Grund-lage für mögliche Indexe für XML-Dokumentsammlungen. Es folgen Ergänzungen,spezielle Indexe für AST/TAP sowie eine Übersicht.

3.1 Anfragen: Inhalt

Der folgende Abschnitt gibt einen Überblick über inhaltsbasierte Anfragemöglich-keiten (s.o.). Wie der Name schon sagt, steht dabei der Inhalt (von XML-Dokumen-ten) im Vordergrund. Meist handelt es sich um die Suche nach Begri�en, Wörternoder Zeichenfolgen. Hierbei ist von entscheidender Bedeutung, wie der Text einesDokumentes betrachtet wird (siehe [Tom97]).

3.1.1 Suche nach Zeichenfolgen

Das einfachste Modell betrachtet den Text als fortlaufende Folge von Zeichen.Eine typische Anfrage an ein solches System wäre demnach die (freie) Suche nachZeichenfolgen.

Bsp.:

• Suche alle Vorkommen von �Index� (Beachte: auch �Indexierung� wird gefun-den).

• Suche alle Vorkommen von �techniques for building�.

• Suche alle Vorkommen von �iques for build�.

• Suche alle Vorkommen von �<title>abstract</title>�.

Die freie Suche nach Zeichenfolgen � auch Volltext-Suche genannt � bietet diegröÿten Freiheiten bei der Suche, ist jedoch auch sehr aufwendig bei der Umsetzung(in Abschnitt 5.1.1.1 wird hierauf noch eingegangen).

33

3 Anforderungen

3.1.2 Suche nach Wörtern

Die wohl verbreitetste Art ist die Betrachtung eines Textes als Folge von Wörtern,welche durch Zeichen bzw. Zeichenfolgen aus einem Stoplist-Alphabet getrenntwerden. Ein Wort ist dabei de�niert als kurze Zeichenfolge von Zeichen aus einemText-Alphabet.In unserer natürlichen deutschen Sprache z.B. besteht ein Text aus kurzen Buch-

stabenfolgen (möglichst Wörter aus dem Duden oder Abwandlungen dieser), welchedurch Leerzeichen, Kommata, Anführungsstriche, Zeilenumbrüche etc. (↗ �Stoplist-Alphabet�) getrennt werden.Eine Anfrage ist dementsprechend eine Suche nach Wörtern; als Antwort werden

alle Dokumente erwartet, welche diese Wörter enthalten. Viele Systeme, welche aufText- bzw Information- Retrieval aufsetzen, gehen auf dieses System zurück, so u.a.[DSDA], [ZMSD], [ST94].

Bsp.: Suche alle Dokumente, welche das Wort �Index� enthalten.

Dem aufwendigen (oft manuellen) Zuordnen von Schlüsselwörtern zu Dokumentendes klassischen Information Retrievals (siehe Abschnitt 2.2.2) wird heute � ange-sichts der Festplattengröÿen � meist eine Volltext-Indexierung vorgezogen. Somitläÿt sich jedes in der Datenbasis existierende Wort schnell lokalisieren.Um den Speicherbedarf erheblich zu verringern und die Suche zu optimieren,

ist es oft nützlich, eine Text-Normalisierung durchzuführen (siehe Abschnitt 2.2.3).Einfachstes Beispiel ist der Ausschluÿ von Wörtern aus dem Index, welche nurgeringen Wert für die Suche besitzen (z.B. �der�, �die�, �das�, �ein�, etc. - sogenannten�stopwords�).

3.1.3 Suche nach Phrasen

Die Autoren von Pat[ST94] de�nieren eine weitere Sichtweise, um besser auf die In-dexierung und die Textsuche Ein�uÿ nehmen zu können1. A. Salminen und F. Wm.Tompa betrachten einen Text als Folge von Index-Termen (�indexed_elements�,s.u.) und Trennzeichen (�delimiters�).

Index-Term

Ein Index-Term ist entweder ein de�niertes einzelnes Zeichen (�stand_alone char�)oder eine kurze Folge von Zeichen aus einem Text-Alphabet. Als Wortbegrenzungdienen �delimiters� (Trennzeichen, analog der Wortbegrenzung aus 3.1.2). Zusätz-lich können jedoch auch spezielle �Signalzeichen� einen neuen Index-Term einleiten.Das Signalzeichen gehört dann als erstes Zeichen mit zum (neuen) Index-Term.Sei de�niert:

indexed_element ::= element_char+ | signal_char element_char*signal_char ::= < .element_char ::= 'a' | .. | 'z' | 'A' | .. |'Z' | '/' .delimiter ::= ' ' | '>', | '-' .

1Im folgenden nur eine vereinfachte Darstellung, für Details siehe [ST94].

34

3.1 Anfragen: Inhalt

So besteht folgender Textauschnitt aus vier Index-Termen ( '<author', 'Serge','Abiteboul', '</author' ) sowie drei �delimiters� ):

<author>Serge Abiteboul</author>

Jeder Index-Term in einem Text leitet eine neue Phrase ein, welche bis zum Endedes Textes verläuft. Entsprechend kann ein Text auch als eine Menge von Phrasenbetrachtet werden.Formal:

text ::= [delimiter] phrase .phrase ::= indexed_element [delimiter] [phrase] .

Der Text �<title>Indexing semistructured data</title>� mit fünf Index-Termen enthält entsprechend fünf Phrasen:

<title>Indexing semistructured data</title>Indexing semistructured data</title>semistructured data</title>data</title></title>

Bsp.: Suche alle Dokumente, welche die Phrase �Indexing XML� enthalten.Beachte: Gesucht wird die exakte Phrase, nicht einzelne Wörter!

3.1.4 Erweiterungen

• Nähe von Wörtern/Phrasen � eine klassische Information Retrieval Anfor-derung (siehe [SM87]), wird von vielen Information- /Text Retrieval Systemenabgedeckt (in PAT: �near�, �followed_by�, �preceeded_by� auf der Grundlagevon Zeichen; in IRQL: �before�/�after� mit Unit-Angabe (z.B.: �Section�)).

Bsp.: Suche alle Dokumente, in denen die Wörter �Index� und �XML� direkthintereinander auftreten.

• Häu�gkeit des Auftretens von Wörtern/Phrasen � auch eine klassische In-formation Retrieval-Anforderung [SM87]. U.a. von PAT[ST94] als Operatorde�niert; in IRQL durch �atleast�/�atmost�-Angabe bei der Anfrage spezi�-zierbar.Bsp.: In welchen Dokumenten kommt das Wort �Index� am häu�gsten vor?

• Ähnlichkeit: Finden von Wörtern/Phrasen mit ähnlicher Schreibweise, z.B.Soundex oder das Zulassen von einer (maximalen) Anzahl von abweichendenZeichen. Solche Anfragemöglichkeiten bietet z.B. sehr anschaulich und gutsteuerbar IRQL[HP].Bsp.: ( /book/author ) SOUNDEX ( �Meyer� ).

• semantische Verhältnismäÿigkeit: Möglichkeit der Suche nach Informa-tion unabhängig ihrer (syntaktischen) Darstellung.

35

3 Anforderungen

Bsp.: Suche nach Büchern, welche 2001 verö�entlicht wurden.

Wünschenswert wäre, daÿ alle Bücher gefunden werden würden � unabhängigdavon, ob das Erscheinungsjahr als Element oder Attribut gespeichert wurde;�year� oder �publicationdate� heiÿt; etc.

3.1.5 Zuordnung zu IR / DR

Die strikte Suche nach Zeichenfolgen, Wörtern oder Phrasen gehört von der Na-tur her erst mal zum Data Retrieval (s.a. [BYN99])! Demgegenüber wird jedochmeist eine fehlertolerante Inhalts-Suche gewünscht; Synonyme etc. sollen gefun-den werden. IR-Verfahren wie Text-Normalisierung, Wörterbücher, Ontologien undThesauri bieten sich hierfür an. Auch Anfragen mit Bezug auf Ähnlichkeit, Näheund Häu�gkeiten bilden eine gute Grundlage für ein Ranking der Ergebnisse (⇒IR). Vertreter des IR nehmen für sich in Anspruch, mit dem IR dem Menschen einbesseres Werkzeug für die Inhalts-Suche in die Hand zu geben.

3.2 Anfragen: Struktur

In Ergänzung zur inhaltsbasierten Suche bieten Anfragen an die Struktur von Doku-menten den zweiten groÿen Pool der Möglichkeiten, die gesuchten Dokument(teil)egenauer zu spezi�zieren. Sie können genutzt werden, um gezielt auf Objekte oderUnterstrukturen zuzugreifen.

3.2.1 Suche nach Elementen (anhand ihres Namens)

Eine der typischsten und einfachsten Struktur-Anfragen ist die Suche nach Elemen-ten eines �bestimmten Typs� � womit Elemente mit dem gleichen Namen gemeintsind (siehe [DSDA], [NBY97], �direct indexing� in [BAK99, 3.5.2]).

Bsp.: Suche alle Titel (aus der XML-Datenbasis über Bücher)=̂ Suche alle Elemente mit dem Namen �Titel�

Oft sind jedoch Elemente des gleichen Typs quer über ein oder mehrere Dokumenteverstreut. Ohne einen Element(namen)-Index � welcher jeweils direkten Zugri� aufdie einzelnen Elemente (eines Typs) gewährt � wäre ein sequentielles Lesen, bzw.ein Traversieren durch sämtliche Dokument-Strukturen, unvermeidlich.

3.2.2 Suche nach Attributen (anhand ihres Namens)

Eben Gesagtes gilt selbstverständlich auch für die Suche nach Attributen (einesbestimmten Typs). Hier gestaltet sich die Suche eher noch schwieriger, da Attributenur �Eigenschaften� eines Elementes und demzufolge noch schwerer lokalisierbarsind.

Bsp.: Suche alle Attribute mit Jahresangaben.

36

3.2 Anfragen: Struktur

3.2.3 Pfad - Anfragen

XML-Dokumente haben eine hierarchische Struktur (⇒ als Baum darstellbar).Der Weg von der Dokument-Wurzel zu einem bestimmten Element wird als Pfadbezeichnet und durch die Folge der Namen der dabei �besuchten� Elemente, getrenntdurch '/', dargestellt. Ein Beispiel: /book/title/published. Ein Pfad enthält soInformation, in welchen (Ober)strukturen das entsprechende Element zu �ndenist. Was liegt also näher, als gesuchte Elemente bzw. Teilstrukturen mittels (par-tiell) spezi�zierter Pfade zu bestimmen (s.a. Anforderung in [Lü01], �PathIndex� inLore[MWA+98], �structual index� in [Sch], [BAK99]).Werden z.B. alle Überschriften innerhalb von Kapiteln in Büchern gesucht, läÿt

sich diese Suche durch einfaches Aneinanderreihen der gewünschten Elementtypenals Suchpfad ausdrücken: /book/section/title . Auch die Verwendung vonWild-cards und regulären Ausdrücken à la Unix ist möglich; somit sind selbst überauskomplexe Pfadanfragen umsetzbar.Der Literatur zufolge scheinen hierbei � neben den (erwähnten) allgemeinen

Pfadanfragen � einige konkrete Operatoren besonders wichtig:

1. Enthaltensein von Elementen in Unterstruktur (vergleiche: �in� / �with� in[NBY97], �including� in [ST94], �containedIn� in [Böh95], ...)Bsp.: Suche alle Abbildungen innerhalb des Elementes �book�

( /book//�gure )2. direkte Eltern-/Kind-Beziehungen (s.a. [NBY97], [GW97])

Bsp.: Suche den Autor des Buches mit dem Titel �using the new DB/2�(/book[title=�using the new DB/2�]/author)

3.2.4 Anfragen: Reihenfolge (Sequenz) / Position

Im Gegensatz zu relationalen oder objektorientierten Datenbanken besitzen Doku-mente eine Reihenfolge, welche durch eine Anfragesprache beachtet werden muÿ(siehe [W3C00], [Lü01]). Auch sind Posistionsangaben von Elementen interessanteAnfragemöglichkeiten (siehe [NBY97], [Lü01]):

Bsp.:

• Suche das letzte Kapitel jeden Buches ( /book/chapter[last] )• Suche die erste und zweite Abbildung, welche irgendwo in einem Buch vor-kommen: ( /book//�gure[1-2] )

3.2.5 Anfragen: bezüglich Namensräumen (Namespaces)

Von einer XML-Anfragesprache wird verlangt, daÿ sie auch Namensräume beachtet(siehe Anforderungen an eine XML-Anfragesprache des W3C[W3C00], [Lü01]). Ya-mamoto, Yoshikawa und Uemura gehen in [YYU99a] anschaulich auf Namensraum-Indexe für XML-Dokumente ein.

37

3 Anforderungen

Die Idee hinter dem Ganzen ist folgende: Es existieren immer mehr standardi-sierte XML-Schemata für verschiedenste Anwendungsbereiche (z.B. Dublin-Core,ISBN, MathML etc.). Selbstverständlich decken diese Standards oft nur einen Teilder Struktur ab, welche man seinen spezi�schen XML-Dokumenten geben möchte.Entsprechend werden die XML-Standards in ein XML-Schema eingebettet und des-sen Elementen zur Abgrenzung von eigenen Elementtypen bzw. anderen Standard-Strukturen ein Namensraum zugewiesen. Dies ist die gleiche Vorgehensweise wieman es zur Abgrenzung von Variablen, Objekten bzw. Methoden aus Programmier-sprachen kennt.Neben anderen Vorteilen machen sich solche Standards bei Anfragen sehr posi-

tiv bemerkbar. Ohne die genaue Struktur der Dokumente zu kennen, kann mandetaillierte Anfragen bezüglich Standard- Elemente/Strukturen an alle Dokumentestellen, welche das zugehörige standardisierte XML-Schemata als Teil ihrer Struktureinschlieÿen.

Bsp.: Suche alle �DC:Creator�, �DC:Title� und �ISBN:ISBN�-Elemente aus derDatenbasis.⇒ Diese Anfrage kann an alle Dokumente gestellt werden, welche die Schema-ta Dublin-Core (�DC:�) und ISBN (�ISBN:�) als Teil ihrer Struktur beinhalten.

Der physische Zugri� auf solche Elemente birgt jedoch ein Problem: Die Standard-Elemente sind (entsprechend Schemata) in den Dokument-Instanzen enthalten, jenach Gesamt-Struktur des Dokumentes jedoch quer über die Instanzen verstreutund die Zugri�spfade unterscheiden sich jedoch enorm. Ein Beispiel ist in Abbildung3.1 skizziert. E�zienten Zugri� auf solche Strukturen/Elemente verspricht ein Index(siehe [YYU99a]).

Abbildung 3.1: Bsp. für verschiedene Zugri�spfade zu eingebetteten Standard-Schema-Elementen.

3.3 Anfragen: Inhalt & Struktur

3.3.1 Text-Suche in Elementen / Unterstrukturen

Einen typische Anfragetyp bildet auch Text Retrieval in bestimmten Elementenbzw. Unterstrukturen.

Bsp.: Suche alle Zusammenfassungen, in denen die Wörter �Index� und �XML�vorkommen.

38

3.4 Weitere Funktionalität

Günstig wäre eine direkte Unterstützung solcher Anfragen durch einem Index. ImGegensatz zu Systemen, welche Text-Indexe nur über gesamten Dokumenten auf-bauen ( z.B. [ZMSD]) bietet ein solcher Index präzisere Anfragemöglichkeiten sowiegenauere Lokalisation des gewünschten Textauschnittes. Weiterhin kann die Ein-schränkung der Suche auf ein (wesentlich kleineren) Teil Datenbasis die Bearbeitungeiner Anfrage enorm beschleunigen.Indexiert werden könnten (je nach Text-Betrachtungsweise) einzelne Wörter,

Wort- bzw. Zeichenfolgen innerhalb von Elementen. Unterstützt werden solcheAnfragetypen u.a. von [DSDA] (�containing�), [MWA+98], [ST94] ( �including� ),[NBY97] und [CA98].

3.3.2 Werte-basierte Anfragen

Werte-basierte Anfragen spezi�zieren ein bestimmtes Objekt (Element/Attribut)und vergleichen dessen gesamten Inhalt mit einem bestimmten Wert [Böh95]. ImUnterschied zur Textsuche in Elementen (s.o.) wird der Inhalt nicht nur auf dasEnthaltensein von einzelnen Wörtern, Wort- bzw. Zeichenfolgen geprüft, sondernals atomare Einheit (Ganzes) betrachtet. Als Vergleichsoperatoren sollten =, <,

>,<=, >=zur Verfügung stehen. Damit sind auch Bereichsanfragen möglich.

Beispiele:

• Suche alle Bücher des Autors �Serge Abiteboul�( //book[/author="Serge Abiteboul"] )

• Suche alle Bücher, welche im Jahre 2001 oder später herausgegebenworden sind ( //book[@year >= "2001"] )

3.4 Weitere Funktionalität

Bisher wurden nur XML-Elemente und -Attribute betrachtet. Auch alle dem Autorbekannten XML-Anfragesprachen beschränken sich auf die Anfrage an Elemente,Attribute und maximal �ID-Referenzen�. [CFMR01] verlangt zusätzlich Text-Suchesowie Namensraum-Anfragemöglichkeit, de�niert darüber hinaus jedoch keine wei-tere Funktionalität. Nach [W3C00] müssen jedoch Anfragen an alle Items des XML-InfoSets[W3C01] abgedeckt werden. Im Folgenden soll kurz auf die noch nicht be-trachteten XML-InfoSet-Items eingegangen werden:

Referenzen Mit Ausnahme ihrer semantischen Bedeutung werden �ID� und �ID-Ref� in XML wie alle anderen Attribute behandelt. Entsprechend können sieauch wie �normale� Attribute indexiert werden.Ob eine Extra-Behandlung von ID/ID-Refs � wie sie z.B. in [Böh95, Kap.3.3] vorgesehen ist � sich wirklich als e�zienter erweist, könnte man in einerspäteren Untersuchung feststellen.

Kommentare Könnten wie �normale� Elemente behandelt werden. Zu beachten isteine Besonderheit: Sie besitzen keinen Namen.

39

3 Anforderungen

Processing Instructions Mögliche Anfragen auf eine Processing Instructions könn-ten sich auf das Ziel (�target�) oder auch auf den zu übergebenden Inhaltbeziehen. Ob die Anfrage auf Processing Instructions allerdings so wichtig ist,daÿ sie durch einen Index zu unterstützen ist, sollte noch näher untersuchtwerden.

Unexpanded Entity-, Unexpanded Entity Reference-Information-Items Hieraufwird im folgenden Abschnitt noch eingegangen.

Character-Information-Items enthalten Information über jedes einzelne Text- Zei-chen eines XML-Dokumentes (als Textinhalt eines Elementes, Character Re-ference oder in einer CDATA Section) wie Zeichen-Kodierung, ob es ein�whitespace�-Zeichen darstellt und das zugehörige �Eltern-Element�. Da dieseAngaben alle über andere Speicherstrukturen ableitbar sind, wird im Folgen-den auf eine weitere Betrachtung verzichtet. Eine Ausnahme bilden die CDataSections, auf die im nächsten Abschnitt noch eingegangen wird.

DTD-Information-Items Das AST/TAP -Modell betrachtet nur wohlgeformte XML-Dokumente. Entsprechend ist eine Speicherung der Bestandteile des DTD-Information-Items nicht vorgesehen und eine Indexierung damit nicht mög-lich.Falls gewünscht oder notwendig, könnte die im DTD-Information-Items refe-renzierte DTD jedoch � in Form eines XML-Schemas � als normales XML-Dokument im AST/TAP gespeichert werden. Ihre Bestandteile könnten dannüber die normalen Element- und Attribut-Indexe angesprochen werden.

Notation-Information-Items Notations-Deklarationen kommen nur in DTDs bzw.XML-Schemata vor. DTDs könnten im AST/TAP in Form eines XML-Sche-mas als normales XML-Dokument gespeichert werden. Innerhalb eines XML-Schemas wird eine Notations-Deklaration als Element mit entsprechendenAttributen gespeichert und ist so über Element-/Attribut-Indexe anfragbar.

3.5 Besondere Anforderungen des AST/TA

Laut Spezi�kation des AST/TAP sollte in Erwägung gezogen werden, folgendeIndexe zu realisieren:

3.5.1 Namensraum - Index

Auf die Notwendigkeit eines Namensraum-Indexes wurde schon in 3.2.5 eingegan-gen. Folgende Struktur wird für den Index vorgeschlagen:pre�x | URI | TextSurrogat | Knoten-ID

3.5.2 Entity - Index

Entities präsentieren die physische Struktur (siehe 2.1.4); der AST die logischeStruktur eines XML-Dokumentes. Da physische und logische Struktur orthogonalzueinander stehen, sollten sie auch in verschiedenen Speicherstrukturen verwaltet

40

3.6 Übersicht Anforderungen

� �� Knoten, welche

durch ersetzbar sind

� ��

� �� CharDataKnoten

Elementknoten

CDSect−KnotenEntityRef−Knoten

Text & <!CDATA[<Markup>]]>

Virtueller Textknoten

Abbildung 3.2: Einsparung von AST-Knoten durch Gleichbehandlung aller Zeichen-daten

werden. Zur Lokalisation von Entities und deren Referenzen wird ein Index mitfolgender Struktur vorgeschlagen:EName | TextSurrogat

3.5.3 CData Section - Index

Manchmal ist es gewünscht, in einem Dokument Zeichen mit Sonderbedeutungals ganz normale Zeichendaten zu verwenden. Innerhalb eines XML-Dokumentesmüssen Abschnitte mit solchen Zeichen in CData Sections eingeschlossen werden(oder durch Entity bzw. Character References ersetzt werden, siehe 3).Im AST/TAP erfolgt die Speicherung aller Zeichendaten eines XML-Dokument

getrennt vom Markup im TA. D.h. auch, alle Daten innerhalb des TA sind Zeichen-daten. Eine extra Kennzeichnung � wie durch die CData Section-Klammerung �ist somit für die Verarbeitung nicht notwendig. Ebensowenig eine Unterscheidungzwischen �normalen� Zeichendaten und denen einer CData Section.Behandelt man alle Zeichendaten gleich, lassen sich im Gegenzug einige Knoten

innerhalb des AST einsparen, was die Behandlung des AST wiederum e�ektiviert.Ein Bsp.: Durch die Gleichbehandlung aller Zeichendaten würden in dem in Abb.3.2 skizzierten nur noch einer statt drei Textknoten benötigt.Die so verlorene Information (Existenz, Beginn und Ende einer CData Section)

muÿ jedoch in anderer Form � z.B. für die Rekonstruktion des XML-Dokument �festgehalten werden.

3.6 Übersicht Anforderungen

In diesem Kapitel wurde versucht, Art und Umfang optimaler XML-Indexe aus-zuarbeiten. Hierzu wurden zunächst allgemein de�nierte Anforderungen (des W3Cu.a.) als auch Ideen verwandter Arbeiten zu semi-strukturierten Daten betrachtet.Im zweiten Teil wurde dann auf besondere Anforderungen bezüglich des AST/TAP -Modells eingegangen. Diese fügen sich gut in das Gesamtschema � entsprechendder Klassi�zierung in Anfragen an Struktur, Inhalt sowie Inhalt und Struktur (siehe2.2.5) � ein. Tabelle 3.1 faÿt die Anforderungen zusammen.

41

3 Anforderungen

Anfragen:Inhalt

Anfragen

auf

Anfragen:Struktur

Inhalt&Struktur

lexikalischeSuchenach:

•Zeich

enfolgen

•Wörter

n

•Wortfo

lgen/Ph

rasen

Erweiterungen:

•Nä

he �nic

htwe

itera

lsxx

<Einh

eiten>

voneina

nder

�xx

<Einh

eiten>vor...

�xx

<Einh

eiten>nach

...

•Hä

u�gkeit

•Äh

nlichkeit

�Wortst

ämme

/Teilmu

ster

�Soundex

�Erlau

benein

erbestimm

tenAn

zahl

abwe

ichenderZ

eichen

•Sema

ntische

Verhält

nismä

ÿigkeit

•Text

Retrieval

�in

Elem

enten

�in

Unter

strukturen

•Wert

e-basierte∼

(fürE

lemente)

•Ko

mbiniert

eAnfragen

•Elem

ent-∼(direkt)

•Attribut-∼(direkt)

•Pfad

-∼

�allgeme

inePfadanfra

gen

(Label-folgen)

�Inklu

sion

(elem

1//e

lem2)

�dir

ekte

Kind/E

ltern-

Bezie

hung

•Po

sition

/Reih

enfolge

•Na

mensraum

-∼

•Wert

e-basierter∼(fü

rAttr

ibute)

•Ko

mmentar-∼

•(Evtl.Processin

gInstru

ctions)

•En

tity-Index

•CD

ataS

ectio

n-Index

Tabelle 3.1: Zusammenfassung der zu unterstützenden Anfragen

42

4 Zugri�smethoden

In Kapitel 3 wurden die Anforderungen ausgearbeitet. Nun gilt es, geeignete Index-Verfahren für die jeweiligen elementaren Anfragen zu �nden. Unter diesem Gesichts-punkt werden im Folgenden verschiedene existierende Zugri�smethoden � für Tex-te, (Dokument-)Strukturen als auch allgemeine � vorgestellt und charakterisiert.Neben der Art der zu indexierenden Daten/Beziehungen müssen folgende Punkte

mit beachtet werden: Eines der Ziele des AST/TAP -Modells (siehe 2.3) ist die e�zi-ente Unterstützung von Veränderungsoperationen. Auszuwählende Indexverfahrenmüssen dementsprechend gerüstet sein. Weiterhin sollen die Indexe �skalierbar� sein(d.h. die Indexierung auch sehr groÿer Mengen an Daten darf kein Problem dar-stellen). Aufgrund der Vielzahl der zu indexierenden Objekte, wären wenige, mehroder weniger universelle Indexe �praktisch�.Abschlieÿen wird dieses Kapitel eine zusammenfassende Bewertung und die (Vor-)

Auswahl eines oder weniger Indexverfahren.

4.1 Klassische Zugri�smethoden

Zunächst erfolgt eine Betrachtung klassischer Zugri�sverfahren, da diese sich überallwiederspiegeln. Soweit nicht anders angegeben, dienten für diesen Abschnitt dieBücher von Theo Härder und Erhard Rahm [HR01] sowie von Heuer und Saake[HS99] als Referenz.

4.1.1 Allgemeines / Klassi�kation

Generell unterscheidet man drei Möglichkeiten des Zugri�s auf Datensätze: Scan,Direkter, wahlfreier Zugri� und sortiert fortlaufender Zugri�.Ein �Scan� bedeutet, daÿ alle Datensätze hintereinander gelesen werden (und auf

eventuelle Kriterien überprüft) werden. Möchte man nur wenige bestimmte Daten-sätze, Teilbereiche oder die Datensätze in einer bestimmten Reihenfolge verarbei-ten, so ist die �Scan�-Methode i.d.R. zu aufwendig. Wünschenswert ist ein wahlfreierZugri� oder auch, die Datensätze nach einem bestimmten Kriterium sortiert zu er-halten. Verschiedene Verfahren wurden entwickelt, um solch einen Zugri� � mitgeringem Aufwand � zu gewährleisten.Die Abbildung 4.1 zeigt die Klassi�kation der Zugri�sverfahren für (eindimensio-

nale) Schlüssel (nach [HR01]). Gleichzeitig sind im unteren Teil geeignete Speiche-rungsstrukturen entsprechend zugeordnet; diese sollen im Folgenden kurz charakte-risiert werden.

43

4 Zugri�smethoden

physischfortlaufend

logischfortlaufend

Vergleichvon

Schlüssel−teilen

Vergleichdes

ganzenSchlüssels

kollisions−freie−Satz−

zuordnung

Kollisions−behandlung

mit Überlauf−bereichen

baumstrukturierterVergleich formationsverfahren

variable Trans−fortlaufenderVergleich

konstante Trans−formationsverfahren

Kollisionsbe−handlung durch

dynamischeErweiterung

Zugriffsverfahren füreindimensionale Schlüssel

bäume

BinäreSuch−

bäume

Mehr−weg−

Digital−bäume

statischeHash−Bereiche

dynamischeHash−BereicheListen

Sequentielle GeketteteListen

Organisationsformender Speicherungsstrukturen

sequentiell baumstrukturiert gestreut

Schlüsselvergleich Schlüsseltransformation

Abbildung 4.1: Klassi�kation der Verfahren für (eindimensionalen) Schlüsselzugri�aus [HR01]

Seitenzugri�e auf den Sekundärspeicher stellen mit Abstand die höchsten Kostender verwendeten Operationen dar. Deshalb ist ihnen besonderes Augenmerk zuschenken. Für die Kostencharakterisierung werden folgende Symbole verwendet:

Symbol BedeutungN Gesamtanzahl der Datensätzeb Anzahl der Sätze pro Seite

Sequentielle Dateiorganisation

Die Nutzung von sequentiellen Dateien ist für moderne Systeme und bei entspre-chenden Datenmengen nicht mehr haltbar, da Such und/oder Veränderungsopera-tionen unvertretbar hoch sind.

4.1.2 Baumstrukturierte Zugri�spfade

4.1.2.1 Binäre Suchbäume

Binäre Suchbäume benötigen die wenigsten Vergleiche, um einen Schlüssel in ei-nem Baum zu lokalisieren. Sie sind auf Vergleiche hin optimiert, nicht jedoch fürden Zugri� auf externe Speicherstrukturen (keine Berücksichtigung der Seitenstruk-tur!). Somit empfehlen sie sich ausschlieÿlich für Hauptspeicher-Implementierungen,was sie für das Ziel der Verwaltung gegebenenfalls auch sehr groÿer Datenmengendisquali�ziert.

44


k v . k v .

k v . k v .k v . k v .

k v . k v .

k v . k v .

k v . k v .

}} Blattknoten

interne Knoten

Abbildung 4.2: B-Baum

4.1.2.2 Mehrwegbäume

Wie alle Bäume unterstützen die Mehrwegbäume sowohl �wahlfreien� als auch sor-tiert sequentiellen Zugri� auf die Datensätze. Darüber hinaus sind sie jedoch speziellfür Seitenstrukturen (die Verwaltung von Daten auf dem sekundären Speicher) kon-zipiert. Der bekannteste Vertreter ist der B-Baum [BM72] (siehe Abb. 4.2) mit sei-nen Varianten, welcher sich als die Standard-Zugri�struktur in Datenbanksystemenschlechthin herauskristallisiert hat.Die wesentlichen Eigenschaften eines B-Baum sind:

• der Baum ist vollständig balanciert (d.h., jeder Weg von der Wurzel zu einemBlatt hat die gleiche Länge k),

• eine Seite darf höchstens voll belegt sein,

• eine Seite muss mindestens halbvoll sein.

Wie schon erwähnt, ist es oberstes Ziel, die Anzahl der Seitenzugri�e zu minimieren.Zum einen geschieht das durch einen möglichst hohen Füllgrad der Seiten. Durch dieoben zuletzt genannte Eigenschaft wird eine Seitenauslastung von 50% garantiert,im Durchschnitt wird bei zufälligem Einfügen und Löschen eine Auslastung vonca. 69% erreicht. Werden die Daten vorsortiert und dann eingefügt, werden sogarnahezu 100% erreicht (und eine ständige Umstrukturierung des Baumes vermieden).Zum anderen wird die Anzahl der Zugri�e fast aller Operationen durch die Höhe

des Baumes bestimmt. Je geringer die Höhe, desto weniger Zugri�e sind nötig.Folglich zielen verschiedene Erweiterungen des B-Baumes auf eine Reduzierung derHöhe.

k .. k . k .

k v k v k v

k .. k . k . k .. k . k .

} Blattknoten

} interneKnoten

k .. k . k .

k v k v k vk v k v k v ...

Abbildung 4.3: B+-Baum

45

4 Zugri�smethoden

B+-Baum

Die meistgenutzte Variante des B-Baumes ist wohl der B+-Baum (siehe Abb. 4.3),oft ungenau1 auch als B∗-Baum bezeichnet (z.B. in [HR01]). Gegenüber dem B-Baum werden die originalen Schlüssel und zugehörige Daten (bzw. Zeiger auf diese)nur in den Blättern des Baumes gespeichert. In den inneren Knoten des Baumeswerden nur Referenzschlüssel gespeichert, die einzig und allein der Navigation imBaum dienen. Die Folge sind wesentlich kleinere Einträge in den inneren Knoten;die Verzweigung wird stark erhöht und damit die Höhe des Baumes reduziert.Es existieren zahlreiche Erweiterungen und Verbesserungen; hier seien nur einige

wenige erwähnt: Der B∗-Baum sorgt für eine Mindestauslastung der Seiten von66,7%. Die Prä�x-/Su�x-Komprimierung verspricht eine starke Reduzierung derdurchschnittlichen Schlüssellänge bei Zeichenketten-Schlüsseln. Ähnliches versuchtder Prä�x-B-Baum von Bayer [BU], welcher auch wesentlich gröÿere Maximal-Schlüssellängen erlaubt. Beide Varianten gestalten sich jedoch wesentlich komplexerdurch eine notwendige variable Gröÿe der Einträge.

4.1.2.3 Digitalbäume

Digitalbäume speichern Werte über einem festen Alphabet, welches den Verzwei-gungsgrad jedes Knoten bestimmt. Werden z.B. nur die Groÿbuchstaben A-Z zuge-lassen, so hat jeder Knoten maximal 26 Kinder.Der Schlüssel wird nicht komplett verglichen, sondern jeweils nach aufeinanderfol-

genden Teilen, so daÿ von einem bestimmten inneren Knoten aus nur noch Schlüsselmit demselben Prä�x erreichbar sind (siehe Abb. 4.4). Entsprechend hängt die Formdes Baumes stark von der konkreten Schlüsselmenge ab; sie besitzen kein explizitesBalancierungskriterium!

ANFORDERUNG

ANFRAGE

AUTOR

DOKUMENT

BIBLIOGRAPIE

CDATA

’N’

’U’

’F’’O’

’R’

’O’

’C’’D’

’B’

’A’

DATENRETRIEVAL’A’

Abbildung 4.4: Skizze eines Digital-Baumes über dem Alphabet A..Z

Tries

Die klassische Form der Digitalbäume ist der Trie (vom englischen Wort �retrieval�abgeleitet). Ein Trie nach obigem Schema speichert in jedem Knoten einen Buch-staben eines Schlüssels ab. Jeder Knoten könnte so durch ein Array fester Länge1s.a. [Com79]; D. Knuth[Knu73] de�nierte den B∗-Baum wie im folgenden Absatz angegeben

46


(hier: 26) dargestellt werden. Jedes Feld des Arrays enthält einen Zeiger auf einenweiteren Knoten oder auf einen Datensatz. Die Buchstaben brauchen nicht mitabgespeichert zu werden, da sie ja in jedem Knoten gleich sind.Da die Schlüsselverteilung selten perfekt gleichmäÿig ist, werden viele Felder der

Arrays nicht genutzt. Dies kann schlechte Speicherplatzausnutzung als auch evtl.unnötige Vergleiche zur Folge haben, wenn z.B. einige aufeinanderfolgende Knotennur ein Kind besitzen (siehe Abb. 4.5).

INDEXSEQUENTIELL

’I’ ’N’ ’D’ ’E’ ’X’INDEXIERUNGSMETHODE

INDEXIERUNG

’S’

’E’ ’R’ ’U’’N’’G’

’S’

DATENRETRIEVAL

’D’’A’ ’T’ ’E’

’U’

DATUM

’I’

Abbildung 4.5: Trie, teilweise zur Liste entartet

INDEXSEQUENTIELL

DATENRETRIEVAL

’E’

’U’2’D’

’I’4

0

’S’’S’

’I’ 5INDEXIERUNGSMETHODE

INDEXIERUNG

DATUM

Abbildung 4.6: Patricia-Baum, äquivalent zum Trie in Abb. 4.5

Patricia-Bäume

Den Nachteil, daÿ Teile von Bäumen zu Listen entarten und so unnötige Vergleicheauslösen, behebt eine Weiterentwicklung der Tries: die Patricia-Bäume2. Abb. 4.6zeigt, wie solche Listen vermieden werden. Dazu enthält jeder Knoten die Anzahlvon Zeichen, welche übersprungen werden können, da sie für die Unterscheidungirrelevant sind. Da jedoch beim Navigieren durch den Baum Stellen übersprungenwerden, muÿ der im Blatt abgespeicherte Schlüssel noch einmal mit dem Suchwortverglichen werden.

4.1.3 Hash-Verfahren

Bei Hash-Verfahren wird die Menge der Datensätze auf eine Anzahl von buckets(�Eimer�) � z.B. eine Seite des sekundären Speichers � aufgeteilt. Das Au�ndeneines Datensatzes erfolgt durch eine Transformation des Schlüssels auf die Nummerdes buckets, welcher den Datensatz enthält.2Patricia steht für �Practical Algorithm To Retrieve Information Coded In Alphanumeric�

47

4 Zugri�smethoden

VV

VV

9

Document

V V V V V V V V V

VVVVVV

VV

author

book

section

2

4

6

V V V V V V V V V

VVVVVV

VV

VV

V V

9

Document

author

book

section

2

4

6

.

.

.

.(a)Eingebettete Verweislisten (b) verkettete Verweislisten

Abbildung 4.7: Eingebettete und separat gespeicherte Verweislisten (nach [HR01])

Wünschenswert wäre hierbei eine kollisionsfreie, gleichmäÿige Verteilung der Da-tensätze über alle buckets. Dreh- und Angelpunkt ist hierbei die Güte der Trans-formationsfunktion bezüglich der Schlüsseldomäne sowie die Behandlung einer evtl.auftretenden Kollision bzw. eines bucket-Überlaufs.Verschiedenste statische und dynamische Hash-Verfahren wurden hierfür ent-

wickelt. Statische Verfahren sind meist einfacher; dynamische kommen besser mitwachsenden oder schrumpfenden Datenbeständen zurecht. Sie sichern hohe Aus-lastung des Speicherplatzes unabhängig vom Wachstum der Schlüsselmenge undvermeiden Reorganisationen mit vollständigem Rehashing.Nachteile des Hashing sind:

• Sequentiell sortierte Verarbeitung der Datensätze sehr teuer,• sehr schwierig, Anwendungs-unabhängige Hashverfahren bereit zu stellen,• u.U. hohe Einfügekosten (�Domino-E�ekt�),• u.U. Reorganisation.

4.1.4 Sekundäre Zugri�spfade

Bisher wurde der Einfachheit halber angenommen, daÿ die Suche nach einem Schlüs-sel auf maximal einen Datensatz führt, wie dies bei Primärschlüsseln der Fall ist. Inden zu entwerfenden Indexen wird es meist nötig sein, daÿ ein Schlüssel auf beliebigviele Datensätze verweisen können muÿ (man denke z.B. an einen Element(namens)-Index). Diese Art von Schlüsseln wird als Sekundärschlüssel bezeichnet.

4.1.4.1 Verweis- bzw. Invertierte Listen

Zu jedem Schlüssel(wert) muÿ also eine Liste der betre�enden Datensätze � oderbesser: mit Verweisen auf diese � gespeichert werden. I.d.R. liegen die Datensätzeschon in irgendeiner Form auf dem sekundären Speicher, so daÿ Verweise vorzu-ziehen sind, um hohe Redundanz zu vermeiden. Abbildung 4.7 zeigt die beidengebräuchlichsten Implementierungs-Formen solcher Verweislisten.

4.1.4.2 Bitlisten

Die Verweise lassen sich auch als Bitlisten implementieren. Dazu wird für jedenSchlüsselwert eine Bitliste der Länge N benötigt3. Für jeden Datensatz, der das3N ist die Anzahl aller Datensätze, s.o.

48


Schlüsselkriterium erfüllt, wird das zugehörige Bit in der Bitliste auf '1' gesetzt. Beider Suche sind die sich quali�zierenden Datensätze und auch ihr genauer Speicherortsehr schnell � und ohne weitere Hilfsmittel � ermittelt.Bit-Operationen sind sehr e�zient. Zusätzlich können heutige Prozessoren 32

bzw. 64 Bit gleichzeitig verarbeiten. Kann eine Anfrage durch mehrere Bitlisten-Sekundärindexe unterstützt werden, so sind Mengenoperationen (Union, Durch-schnitt etc.) besonders schnell durchführbar.Gegen Bitlisten spricht in erster Linie der hohe Speicherbedarf. Verschiedene

Komprimierungstechniken wurden entwickelt, um dies zu verbessern. Ein weite-res Problem besteht darin, daÿ das Einfügen und Löschen von Datensätzen sehraufwendig werden bzw. eine Reorganisation des Indexes erforderlich machen kann.

4.1.5 Mehrdimensionale Zugri�spfade

Stellt eine Anfrage Bedingungen an mehrere Attribute eines Datensatzes/-objektes,so gibt es mit den bisher vorgestellten Indexen folgende mögliche Vorgehensweisen:

1. Nutzung eines Indexes für ein Attribut und anschlieÿendes Testen der sichquali�zierenden Datensätze auf Erfüllung der restlichen Bedingungen,

2. Falls für jedes (angefragte) Attribut ein Index zur Verfügung steht: Nutzungder Indexe zum Erlangen der Satzverweise und anschlieÿender Schnittmen-genbildung über den einzelnen Satzverweis-Mengen,

3. Mischung zwischen 1) und 2).

Bei allen Vorgehensweisen werden mehr oder weniger viele Daten (oder Satzver-weise) geladen, die letztlich in der Ergebnismenge nicht auftauchen. Ideal wäre eineinzelner Index, welcher mehrere Attribute berücksichtigt.Eine Vorgehensweise wäre, einzelne Attribute zu verketten (Bsp.: A1, A2) und

darüber einen Index aufzubauen. Dieser Index würde sehr e�ektiv Anfragen un-terstützen, welche Bedingungen an beide Attribute stellen � aber eben nur genausolche Anfragen. Anfragen, in denen A1 nicht vorkommt, werden sehr ine�ektiv.Sollen mehrere Kombinationen von Attributen in Anfragen durch solch einen Indexunterstützt werden, müÿten selbst bei sehr wenigen Attributen zahlreiche Indexeaufgebaut werden. Ein sehr hohes Maÿ an Speicherverbrauch, Redundanz und hoheÄnderungskosten wären die Folge.In den vergangenen Jahren wurde viel in die Entwicklung von mehrdimensionalen

Zugri�spfaden investiert und es entstanden unzählige Vorschläge. O. Günther undV. Gaede untersuchten für eine Übersicht über Indexe allein für räumliche Datenfast 200 Literaturstellen[GG98]. Keiner der vorgestellten Indexe hat sich jedoch inirgendeinem Sinne den anderen als grundsätzlich überlegen erwiesen. Alle haben ihreStärken und Schwächen entsprechend bestimmter Umfeldbedingungen. So existierenviele Spezialiserungen, aber keine allgemein gültige gute Lösung.In diesem Lichte versteht man das starke Bestreben, mehrdimensionale Objekte

linear einzubetten (z.B. über z-Ordnung[OM84], Gray-Codierung[Fal88] und Hil-bert's Kurve[Jag90]) und im erprobten B+-Baum zu speichern. Eine solche Abbil-dung ist jedoch schwierig, da mehrdimensionale Objekte keine natürliche Ordnungbesitzen.

49

4 Zugri�smethoden

E 30 72

45 90F

NO

NO

y x yA

C 30

NWSW

AC

B

D

E F

x

B

D

70 40

2560 50

15

NW

65

Abbildung 4.8: Quadranten-Baum

Typische Probleme mehrdimensionaler Indexe sind:• Sie benötigen oft sehr komplexe Wartungs-Algorithmen (so z.B. beim k-d-B-Baum, Grid File; R+-Baum: komplexe Such- und Wartungsalgorithmen; dasmehrdimensionale Hashing benötigt eine sehr komplexe Abbildungsfunktion),

• Bei Ungleichverteilung der Daten bzw. ungünstiger Einfügereihenfolge ber-gen sie oft eine Gefahr der Entartung (Quadranten-Baum, k-d-B-Baum, dasGrid File) (Bsp. siehe Abb. 4.8, bei R-Baum: keine Entartung, doch starkeVerschlechterung der Suchleistung),

• Probleme bei der Speicherplatz-Ausnutzung (beim k-d-B-Baum, mehrdimen-sionalen Hashing, Grid File (Unterlauf-Behandlung stark eingeschränkt)),

• Speicherplatzbedarf (generell hoch, z.B. R+-Baum; beim Grid File wächst das�Directory� überlinear).

Auÿerdem haben noch nicht alle ihre Praxistauglichkeit nachgewiesen (siehe [HR01]).Ihre Stärken liegen eher in starken Spezialisierungen für bestimmte Anwendungen,denn im Bereitstellen einer guten, allgemein einsetzbaren Variante.Aufgrund der genannten Probleme wird vom Einsatz solcher Indexe vorerst ab-

gesehen. Wenn in Zukunft detaillierte Statistiken die Notwendigkeit für einen be-stimmten, spezialisierten mehrdimsionalen Index herausstellt, kann hierüber neuentschieden werden.

4.2 Zugri�smethoden für Texte

Ein groÿer Teil der elementaren Anfragen bezieht sich auf den Inhalt der Dokumente� v.a. auf die Suche nach Zeichenfolgen, Wörtern und Phrasen. Entsprechend darfeine Betrachtung von Index-Methoden für Texte hier nicht fehlen.Eine viel beachtete Variante der Textsuche ist die Muster Suche (Pattern

matching), so z.B.1. Suche mit bestimmter Anzahl erlaubter Fehler,2. Suche mit regulären Ausdrücken.

Die Muster- als auch Prä�x-, Su�x- und Teilzeichenketten-Suche könnte für dieÄhnlichkeitssuche interessant sein, weshalb sie in die Betrachtungen mit einbezogenwerden.

50


Scan

Um noch vorzustellende Index-Verfahren besser einschätzen zu können, sei derSpeicher- und Zeitbedarf der direkten Suche auf dem Originaltext hier kurz zu-sammengefaÿt. Ausführliche Details �nden sich in [Fuh97, Kapitel 10], [BYN99,Kapitel 8.5] und [Bec98].

Verfahren Erläuterung SuchzeitNaives Vergleichen (NV) Vergleichen des Musters O(mn)

ab jeder Position

Knuth-Morris-Pratt (KMP) NV + Überspringen O(n)..O(2n)von Positionen

Boyer-Moore (BM) NV + Überspringen Ø: O(nlog(m)/m)von Positionen tworst : O(nm)

BenutzteSymbole Bedeutung

M Musterm |M| (Länge des Musters)N Textn |Text| (Länge des Textes)Ø durchschnittlich

tworst (Suchzeit) im schlechtesten Fall

4.2.1 Wort-Indexe

Der Wort- (bzw. Begri�s-) Index ist wohl die älteste Indexierungsmethode über-haupt. Klassisch wurden Schlüsselworte/Begri�e Dokumenten zugeordnet, heute isteine Volltext-Indexierung mit vorangehender Text-Normalisierung (siehe Abschnitte2.2.2, 2.2.3) gebräuchlicher.

4.2.1.1 Invertierte Listen/Dateien

Invertierte Listen/Dateien4 (Inverted Lists/Files) sind laut Gonzalo Navarro[BYN99] die beste Methode zum Aufbau eines Wort-Indexes für groÿe Datenbe-stände. Für den Aufbau des Indexes wird zuerst eine Vokabular-Liste erstellt undanschlieÿend zu jedem Eintrag die Vorkommen im Text in einer Liste festgehalten.Der Aufwand hierfür liegt bei tIndex−Aufbau ≤ O(N).Diese Vorgehensweise ist analog zu den Verweislisten (siehe Abschnitt 4.1.4, Abb.

4.7), hier zeigen die Verweise jedoch auf die Dokumente, in denen die Wörtervorkommen. Die Position der Wörter im Dokument kann dem Index hinzugefügtwerden. Andernfalls ist nach dem Index-Zugri� noch das Dokument zu durchsuchen,um die genaue Position zu ermitteln.4Im folgenden nur als Invertierte Listen bezeichnet

51

4 Zugri�smethoden

Vorteile sind die einfache Implementation, eine sehr e�ziente Suche sowie eineeinfache Handhabung von Synonymen (z.B. via Normalisierung, siehe 2.2.3).

Speicherbedarf N. Fuhr gibt in [Fuh97] den Speicherbedarf mit 10-100% von|N| an. Baeza-Yates geht davon aus, daÿ sehr häu�g vorkommende Wörter ohneSuchwert (�stopwords�, siehe Abschnitt 2.2.3) von der Indexierung ausgenommenwerden. Damit beträgt der Speicherbedarf nach [BYN99]:

• MV okabular = O(Nβ) | β=0..1 (0.4..0.6 in der Praxis) für das Vokabular und

• MPos_Liste = 30− 40%|N | für die Verweisliste (also O(N)).

Implementierungen:

Die Kosten für Änderung bzw. Reorganisation sind abhängig von der konkretenImplementation. Im Prinzip sind alle oben erwähnten Zugri�smethoden einsetzbar,welche die Suche in der Vokabular-Liste beschleunigen. So z.B.:

• Sortierte Listen Ungeeignet, da Änderungsoperationen zu teuer (s.o.).

• B-Bäume B-Bäume bieten viele positive Eigenschaften (siehe Abschnitt 4.1).Die Suchzeit für einen direkten Zugri� hat eine Komplexität von O(logN),Bereichssuche und sortiert fortlaufender Zugri� ist möglich.

• Tries und Hashing bieten beide eine Suchzeit von O(m). Hashing erlaubtjedoch keine Pre�x- und Bereichsanfragen.

Realisierung Phrasen- & Nähe-Suche

Eine Realisierung von Phrasen- und Nähe-Suche mit Hilfe von Invertierten Listenist möglich durch:

1. Sammeln der Positionen aller Terme,

2. Test auf Phrasen / Nähe durch Vergleich der einzelnen Positionen.

Die Suchzeit beträgt dabei t = O(N0.4..0.8).

In sehr begrenztem Maÿe lassen Invertierte Listen auch eine Zeichenketten-Suchezu. Ein Scan über dem Vokabular ermöglicht eine Prä�x-, Su�x- oder Teilstring-Suche innerhalb der indexierten Wörter und dies zu günstigen Kosten, da|Vokabular| � |N|. Dies wird ine�zient, sobald die Such-Zeichenkette über Wort-grenzen hinweg verläuft.

52


Suche nach... SuchzeitWörtern O(logN) / O(logm)Bereichssuche(Wörter) O(logN) / O(logm)Prä�x, Su�xTeilstring O(logN) / O(logm) + Suche im Vokabular5Phrasen O(N0.4..0.8)Nähe O(N0.4..0.8)Zeichenfolgen - (nur innerhalb von Wörtern!)Mustern O(logN) / O(logm) + Suche im Vokabular5mit Fehlern O(logN) / O(logm) + Suche im Vokabular5

Navarro & Baeza-Yates ermittelten auf einer Sun-UltraSparc-1 mit 167 Mhz und64MB Ram folgende Praxis-Werte(siehe [BYN99, 8.6.3]):

Gröÿe |n| Anfrage Zeit in s250MB komplexer regulärer Ausdruck 0,8..3250MB 1 erlaubter Fehler > 8250MB 2 erlaubte Fehler > 20

4.2.1.2 Signature Files

Das Konzept der Signature Files (Signatur-Dateien) ist wort-orientiert. Jedes zuindexierende Wort wird auf eine Bitmask (Bit-Folge mit fester Länge B) � einesogenannte Signatur � abgebildet. Dies geschieht meist durch eine Hash-Funktion.Weiterhin wird der Text in Blöcke von b Wörtern unterteilt. Auch jeder Block erhälteine Bitmask, welche durch ODER-Verknüpfung der Bitmasks aller enthaltenenWörter gebildet wird.Für eine Anfrage wird das Suchwort ebenfalls in Such-Bitmask umgewandelt.

Diese Such-Bitmask wird mit jeder Block-Bitmask verglichen (falls das Suchwortim Block vorkommt, müssen alle �1� bits der Such-Bitmask in der Block-Bitmaskgesetzt sein).Verfahrensbedingt kann es vorkommen, daÿ die erforderlichen �1�-bits gesetzt

sind, das Suchwort aber nicht im Block enthalten ist (sogenannte �false drops�).Deshalb ist ein anschlieÿender Vergleich des Blockes mit dem Suchwort notwendig.Bei optimaler Block- und Bitmask-Länge beträgt die Wahrscheinlichkeit l für falsedrops ≈ 0.046% (laut [BYN99]: (1/2ln(2))B/b = 1/2l).

Vorteile: sind der sehr einfache Indexaufbau und ein unproblematisches Einfügun-gen von neuen Daten. Die verwendeten Bit-Operationen sind hardware-orientiertund eine Verarbeitung so extrem schnell. Auch der Speicherbedarf ist gering:≈ 10..20% |N|.

Nachteile: Eine Suche entspricht einem sequentiellen Scan über den Index, d.h.die Suchzeit ist direkt abhängig von |N| (linear!). Entsprechend empfehlen sich5geringer Aufwand, da Vokabular � |N|

53

4 Zugri�smethoden

Signature Files nur für nicht zu groÿe Texte! Phrasen können über mehrere Blöckeverteilt sein. Solche Phrasen mittels Signature Files zu �nden, ist sehr aufwendig. 6

Suche nach... SuchzeitWörtern sehr schnell, trotzdem: O(N)Bereichssuche(Wörter) -Phrasen Sehr aufwendig, wenn Phrase über Blockgrenze gehtNähe O(N)Zeichenfolgen - (nur innerhalb von Wörtern!)Mustern aufwendigmit Fehlern aufwendig

4.2.2 Zeichenketten-Suche

Bisherige Methoden boten nur wort-orientierten Zugri�. Entsprechend den ausgear-beiteten Anforderungen ist jedoch auch der e�ziente Zugri� auf Zeichenfolgen undPhrasen zu untersuchen.

4.2.2.1 Su�x Bäume & Felder

Su�x-Bäume und Felder (Su�x Trees & Arrays) bieten die Möglichkeit, auchZeichenfolgen zu indexieren. Dazu wird ein Trie (siehe Abschnitt 4.1.2.3) übersämtlichen Su�xen eines Textes aufgebaut, welcher analog zum Patricia-Baum zumSu�x-Baum kompakti�ziert wird.Falls alle Zeichenfolgen indexiert werden ist eine sehr e�ektive Wort-, Zeichenket-

ten- und Phrasensuche sowie weitere, spezialisierte Anfragen (z.B.: Finde längstenTeilstring, welcher mehrmals auftritt, häu�gster Teilstring mit Länge l etc., sieheu.a. [BYN99]) möglich:

Suchzeit SuchzeitSuche nach... Su�x-Tree Su�x-Arraybeliebiger Zeichenkette(schlieÿt die Suche nachWörtern, Pre�x, Su�x,Teilstrings und Phrasenmit ein)

O(logn) O(nlogn)

Bereichs-Anfragen O(logn) O(nlogn)Mustern(Reguläre Ausdrücke) O(nαpolylog(n)) | 0 < α < 1 abhängig vom

reg. Ausdruck.

Die Indexierung aller Textpositionen hat jedoch einen immens hohen Speicherver-brauch zur Folge (ca. das 10-20fache des Original-Textes).6Es existieren Varianten und Erweiterungen zu den Signature Files, wie Bitscheiben SignatureFiles und sogar S-Bäume. Dem geneigten Leser sei als weiterführende Literatur [Fuh97] und[Bec98] empfohlen.

54

4.3 Zugri�smethoden für Dokument-Strukturen

Su�x Arrays bieten die gleiche Funktionalität wie Su�x-Bäume, benötigen je-doch wesentlich weniger Speicher (ca. das 4fache des Original-Textes). Dazu werdeneinfach die Zeiger aus den Blättern des Su�x-Baumes in einem Array gespeichert.Bei der Suche ist jeweils für jeden Vergleich ein Zugri� auf den Originaltext erfor-derlich!

Nachteile der Su�x-Arrays sind der schwierigere Aufbau, schwierige Wartbarkeitund die Tatsache, daÿ der Originaltext bei der Suche verfügbar sein muÿ. Auÿerdemhat der Index-Aufbau eine Komplexität von O(n2log(M)/M), falls der Text nichtin den Hauptspeicher(M) paÿt! Damit ist der Indexaufbau 5-10 mal langsamer alsbei Invertierten Listen. Das Einfügen eines Textstückes n' hat eine Komplexität vonO(nn' log(M)/M).

4.2.2.2 PAT Bäume & Felder (PAT Trees & Arrays)

Um den Speicherbedarf von Su�x Bäumen und Feldern zu begrenzen, muÿ dieAnzahl der zu indexierenden Su�xe eingeschränkt werden. Dabei muÿ beachtetwerden, daÿ die Funktionalität des Indexes nicht unverhältnismäÿig sinkt. Eine Lö-sung wäre hier die De�nition von Index-Termen und die anschlieÿende Indexierungaller PAT-Phrasen (siehe Abschnitt 3.1.3, [ST94]) als Su�x-Baum.Werden z.B. nur die Wörter eines Textes indexiert, hat der Su�x-Baum noch

einen Speicherbedarf von 120..240% des Originaltextes, ein Array nur noch ca.40%. PAT-Arrays sind sekundärspeicher-geeignet, die Suche ist etwas teuerer alsbeim Baum: 2log2n− 1 Vergleiche, 4log2n Plattenzugri�e.

Speicherverbrauch Zeit für IndexaufbauSu�x-Bäume M=120..240% |N| bei Wort-Indexierung tCons = O(N)Su�x-Felder M≈40% |N| bei Wort-Indexierung tCons = O(NlogN)


Gegenüber den klassischen und Text-Indexen sind Zugri�smethoden für Dokument-Strukturen ein sehr junges Forschungsgebiet. Viele Modelle zur Behandlung semi-strukturierter Dokumente (SGML und XML im besonderen) gehen überhaupt nichtauf Indexe ein. Andere wiederum widmen sich der Speicherung von Dokumenten inRDBMS bzw. OODBMS (wie z.B. [SYU99] u.a.) und nutzen einfach deren Indexe.Weiterhin �ossen viele interessante Ideen und besondere Behandlungsweisen von

Datenmodellen und Anfragesystemen/-sprachen für semi-strukturierte Daten schonin die Ausarbeitung der Anforderungen (Kapitel 3) ein. So werden im Folgendennur Ansätze betrachtet, welche explizit auch auf die Indexierung eingehen.

4.3.1 Erweiterung IR-Indexe um Struktur-Information

Im traditionellen TR/IR wurden (Schlüssel-)Wort-Indexe für Dokumente angelegt.Hierbei wird die Struktur eines Dokumentes in keiner Weise berücksichtigt. Wirdein Wort in einem bestimmten Element/Unterstruktur gesucht, so müssen alle Do-kumente, welche der Index quali�ziert, komplett geladen werden. Anschlieÿend wird

55

4 Zugri�smethoden

in jedem Dokument geprüft, ob das Wort auch in der gewünschten Unterstruktur� und nicht irgendwo anders � vorkommt.Dies kann mit invertierten Listen für jedes Element bzw. jeden Pfad umgangen

werden, wie Autoren vieler Systeme erkannt haben. Z.B. präsentieren und untersu-chen Lee, Yoo und Yoon in [LYYB77] invertierte Listen für Schlüsselwörter mitverschiedener Verweis-Granularität (z.B.: Invertierte Listen für alle Blattkno-ten, nur für Root-Knoten; mit/ohne Replikation etc.) und bewerten Speicherver-brauch und Zugri�szeit.In [CGM90] wird neben dem ganzheitlichen Schlüsselwort-Index auch die Mög-

lichkeit einer hierarchischen Clusterung (mehrere Teil-Indexe) � mit und ohneReplikation � sowie deren Leistung untersucht. Der Artikel unterstreicht, daÿ dieWahl hierbei stark von der Art der Anfragen und vom Platz abhängig ist, den derIndex einnehmen darf. Verteilte Indexe mit Replikation versprechen eine bessereLeistung, beanspruchen aber auch sehr viel Speicherplatz. Auch kann das Durchsu-chen vieler kleiner Indexe bei allgemeineren Anfragen die Anfragezeit stark erhöhen.Ein Schlüsselwort-Index in Form einer Signatur-Hierarchie (jeweils entspre-

chend der Struktur-Hierarchie der Dokumente) wird in [CA98] beschrieben. Dabeispiegeln sich Vorkommen von Schlüsselwörtern in bestimmten Elementen sowohl inderen Signaturen als auch in den Signaturen aller Vorfahren wider. Vorteil ist einschneller Test der � im Verhältnis wenigen � Signaturen in den höheren Ebenen.Nur, wo sich eine Signatur quali�ziert, ist ein Abstieg in die Unterstruktur not-wendig. Dies verspricht eine sehr schnelle Anfragebearbeitung, weiterhin heben dieAutoren den einfachen Aufbau und den geringen Speicherbedarf hervor. Verände-rungsoperationen sind jedoch relativ aufwendig und die Auswahl der Schlüsselwörtersoll (noch?) durch menschliche Mithilfe erfolgen. Auch eignen sich Signatur-Dateiennicht für sehr umfangreiche Datenmengen (s.o.).Meuss und Strohmeier präsentieren in [MS99] eine Erweiterung für Wort-Indexe

um einen �Kontext-Filter�. Jedem Index-Eintrag wird dabei eine Bitfolge festerLänge zugeordnet, in der jedes Bit einem bestimmten Elementtypen (Elemente miteinem bestimmten Namen) zugeordnet ist. Für das Element, welches das indexierteWort umschlieÿt, und alle seine Vorfahren (in der Dokument-Hierarchie) wird daszugehörige Bit in der Bitfolge auf '1' gesetzt. Somit ist eine Wort-Suche in Ele-menten und Unterstrukturen e�ektiv möglich (Ermitteln der Wortvorkommen undFiltern). Um den Speicherbedarf zu begrenzen, müssen die Bitfolgen auf bestimmteElementtypen beschränkt werden. Dies erfolgt zum einen anhand von Statistiken(�Selektivität�) und zum anderen manuell.

4.3.2 Spezielle Struktur-Indexe

4.3.2.1 Indexe für Markup

Eine verbreitete Variante ist das Anlegen von Indexen für Markup: Z.B. wird in[DSDA] ein Lexikon + Invertierte Liste für die Abbildung Markup − Objekt 7−→(Dokumentnummer, Position) angelegt. Das Modell geht jedoch � wie sehr vieleandere � von statischen Daten (d.h., sehr seltenen Änderungen) aus.eXist[M+] bildet Element(namen) auf Knoten seiner internen Baum-Darstellung

der XML-Dokumente ab. eXist geht jedoch genauso von einer mehr oder weniger

56


8 9

3

1

14 15 16

6

2

5

Abbildung 4.9: Vergabe von UIDs zu jedem Knoten nach [LYYB77]

statischen Datenbasis aus, eine Änderung bereits eingefügter Dokumente ist nichtmöglich.Auch Tamino[Sch] gibt an, Elementtypen (Elemente mit gleichem Namen) zu

indexieren.

4.3.2.2 Numerierungs-Schemata

Lee, Yoo und Yoon präsentieren �eindeutige Element Identi�katoren� (unique ele-ment ID's) (UIDs)[LYYB77] eine Möglichkeit der Abbildung von Elementen aufID's, welche überzeugende Vorteile bietet:

• Pfade (Labelfolgen) können sehr speicherfreundlich abgebildet werden und• Eltern und Kindknoten sind direkt aus der Element-ID errechenbar. Dadurchbesteht keine Notwendigkeit mehr, diese Information als Zeiger o.ä. abzuspei-chern.

Dazu wird der gesamte Dokument-Baum als Baum mit einem maximalen Verzwei-gungsgrad k betrachtet. Hat ein Knoten weniger Kinder, so werden sie mit �virtu-ellen� (nicht real existierenden) Knoten aufgefüllt und die Knoten durchnumeriert.Abb. 4.9 zeigt eine Beispielnumerierung für k = 3.Dieses Verfahren setzt jedoch eine statische Datenbasis voraus. Würde ein Kno-

ten hinzugefügt, so daÿ sich k erhöht, müÿten sämtliche Strukturen komplett neuaufgebaut werden.Zur Erhöhung der Funktionalität schlagen Shin, Jang und Jin in BUS[SJJ] eine

Erweiterung der UID um Dokument-ID, Ebene (in der Dokumenthierarchie) undElement-Typ vor und benennen sie General Element ID (GID). Weiterhin wirdder Index komprimiert (er wäre sonst gröÿer als die Original-Daten). Ein Prototypwurde implementiert, welcher relativ performante Tests absolvierte.

4.3.3 Pfad-Indexe

Jedes XML-Dokument kann als DOM-Baum dargestellt werden und stellt somitschon einen (hierarchischen) Zugri�spfad dar. Aufgrund des groÿen Umfang � undder Tatsache, daÿ mit der Suche immer beim Root-Element begonnen werden muÿ� eignet sich dieser jedoch kaum für e�ziente Strukturanfragen.Eine invertierte Liste der Label-Folgen (Pfade) bietet mehr Möglichkeiten, benö-

tigt jedoch sehr viel Speicher.

57

4 Zugri�smethoden

4.3.3.1 DataGuides & Co.

Im Rahmen des Lore-Projektes[MAG+97] wurden DataGuides[GW97], [MWA+98]entwickelt, deren Ziel eine möglichst kompakte Zusammenfassung aller Label-Folgen(ohne Informationsverlust!) ist: Hierzu wird jede eindeutige Label-Folge exakt ein-mal im DataGuide abgebildet, unabhängig davon, wie oft sie im Original-Dokumentvorkommt.In den Knoten werden Verweise auf die Knoten abgelegt, welche über den Pfad

erreichbar sind. Abb. 4.10 und 4.11 zeigen ein Beispiel-Dokument und das zugehörigeDataguide. Mit Hilfe dieser Datenstruktur lassen sich mit einem Zugri� sofort alleKnoten aus�ndig machen, welche über einen speziellen Pfad erreichbar sind.

6

5

11

2 3 4

7 8 9 10 12 13 14

sectionsection ref section section

titletitle

chapter chapter chapter appendix

title figuresection

1

Abbildung 4.10: XML-Dokument als (OEM-)Baum in Lore

16 17

18 19 20 21

figureref section

title

chapter appendix

15

Abbildung 4.11: DataGuide für das XML-Dokument in Abb. 4.10

ToXin [FR01] erweitert diesen Ansatz um einen passenden Werte-Index undzusätzliche Einstiegspunkte in den Dataguide-Graphen (Sie reklamieren, daÿ beimDataguide immer von dem �root�-Knoten aus gesucht werden muÿ).

4.3.3.2 PAT-Index über normalem und reversem Pfad

In [YYU99a] wird ein reverser Pfad (Reverse Path) als Umkehrung von �norma-len� Pfaden eingeführt. Ein reverser Pfad spezi�ziert eine Element-Label-Folge voneinem spezi�schen Element zur Wurzel (des Dokumentes). Z.B. lautet der reversePfad für /book/section/title 7: title\section\book\.Eine Invertierte Liste über den reversen Pfaden bietet e�ektiven Zugri� (siehe

Abb. 4.12). Auch Anfragen wie //title � sonst relativ aufwendig zu ermitteln �7zweites �title�-Element aus dem Beispiel-Dokument, siehe Abb. 2.2 und 2.3

58


author\book\ <doc-id><pos> ...figure\section\book\ <doc-id><pos> ...figure\section\section\book\ <doc-id><pos> ...para\section\book\ <doc-id><pos> ...para\section\section\book\ <doc-id><pos> ...published\title\book\ <doc-id><pos> ...section\book\ <doc-id><pos> ...title\book\ <doc-id><pos> ...title\section\book\ <doc-id><pos> ...title\section\section\book\ <doc-id><pos> ...

Abbildung 4.12: �Reverser Pfad�-Index für Dokument in Abb.2.3

<book><section><title>Motivation<title><section><book><section><title>Motivation<title><section><book><title>Motivation<title><section><book>Motivation<title><section><book><title><section><book><section><book><book>

Abbildung 4.13: PAT-Phrasen über normalem und reversem Pfad

sind so in nur einem Zugri� gelöst. Der Textinhalt von (Blatt-)Knoten kann miteinbezogen werden � wie z.B.: "Motivation"\title\section\book\. Dann bietetder Index e�ektiven Zugri� auf alle Pfade und Inhalt eines Dokumentes als auchkostengünstige (exakte) Textsuche in Elementen.

Weiterhin präsentieren Yamamoto, Yoshikawa und Uemura einen Index über denPAT-Phrasen aller Pfade in der Form: <Pfad><Textinhalt><reverser Pfad>, ge-nannt �Normal-Reverse-Path�(NRP)-Index. Abb. 4.13 zeigt die PAT-Phrasen über<book><section><title>Motivation<title><section><book>. Dieser Ansatzbietet viele gute Ideen und Suchmöglichkeiten, die Gröÿe des Indexes dürfte jedochbeträchtliche Ausmaÿe annehmen.

4.3.3.3 Abstraktion

Die Möglichkeit der Abstraktion (im Sinne von Vereinfachung/Zusammenfassung)von Dokument-Struktur und -Inhalt wird in [CCCX00] diskutiert. Dabei sind ver-schiedene Ebenen der Abstraktion möglich. Beispielsweise für die Dokumentstruk-tur: Vom Aufbau eines Indexes über die komplette Dokument-Hierarchie überdas Zusammenfassen bestimmter Elemente oder Pfade bis zur Reduktion auf dasDokument-(Wurzel-)Element. Höhere Abstraktion bedeutet natürlich weniger Platz-bedarf für den Index und schnellere Anfragebearbeitung. Jedoch geht auch mehrund mehr Information (im Index) verloren. Die Wahl besteht zwischen verschiede-nen Stufen der Detailliertheit versus Speicherplatz (für den Index). Nachteilig istdie notwendige manuelle De�nition der Abstraktionsfunktionen für die Dokumente.

59

4 Zugri�smethoden

U

Dieser Teil desBaumes mußangepaßt werden

keine Ände−rungen nötig

Abbildung 4.14: Mittels der Relative Region Coordinates ist bei einem Update von�U� nur ein Teil des Indexes betro�en.

4.3.4 Problem: Update

Fast alle Ansätze zur Indexierung von �strukturierten Dokumenten� (und auchTexten) gehen von mehr oder weniger statischen Datenbeständen aus. Denn eineVeränderung von Daten birgt ein Problem für den Index: Ein Einfügen nur einesZeichens zieht i.d.R. ein Update eines groÿen Teiles des Indexes nach sich � wennnicht sogar einen kompletten Neu-Aufbau.[KYU01] adressiert dieses Problem und schlägt anstatt von absoluten Koordina-

ten die Nutzung von Relative Region Coordinates (relative Bereichskoordina-ten) vor: Dabei werden Positionen nur relativ zum Eltern-Knoten angegeben. Beieinem Update ist so nur ein begrenzter Teil des Indexes betro�en (siehe Abb. 4.14).Bei entsprechender Clusterung des Indexes kann dieser (zu ändernde) Teil minimiertwerden.Diese Idee stand Pate bei der Einführung der �O�sets� in den ASTP .

4.4 Bewertung

Die Eignung der betrachteten Indexverfahren für die Arbeit kann wie folgt zusam-mengefaÿt werden:

Klassische Zugri�smethoden

Sequentielle Organisationsformen, der binäre Suchbaum und mehrdimensionale In-dexe disquali�zierten sich schon im Vorfeld (s.o.).

Hashing bietet einen sehr schnellen Zugri� auf einen einzelnen indexierten Da-tensatz. Eine sequentiell sortierte Verarbeitung der Datensätze ist dagegen sehrteuer � jedoch für die geplanten Indexe wünschenswert. Anwendungs-unabhängigeHashverfahren entsprechender Qualität bereit zu stellen gestaltet sich meist als sehrschwierig. Da aber beliebige (wohlgeformte) XML-Dokumente gespeichert werdensollen, stellt dies ein Problem dar. Hinzu kommen u.U. hohe Einfüge- (�Domino-E�ekt�) und Reorganisation-Kosten. Viele schwerwiegende Punkte, welche gegeneine Verwendung von Hashing für die zu entwerfenden Indexe sprechen.

60

4.4 Bewertung

Tries haben einen hohen Speicherbedarf und oft eine extrem schlechte Speicher-ausnutzung. Die geforderte Skalierbarkeit ist so nicht gegeben.

Patricia-Bäume sind nicht Sekundärspeicher-geeignet und können bei Ungleich-verteilung der Daten bzw. ungünstiger Einfüge-Reihenfolge entarten. Auÿerdemsind sie inexakte Filter; d.h., es ist ein Zugri� auf den Originaltext zur Kontrollejeder Fundstelle erforderlich. Damit sind sie für die zu entwerfenden Indexe unge-eignet.

Bitlisten haben einen hohen Speicherbedarf. Auch emp�ehlt sich ihre Verwendungerst bei einer Selektivität pro Attributwert von > 10% (siehe [HR01]). Die Forderungnach der e�zienten Unterstützung von Änderungsoperationen wird durch die hohenKosten für das Entfernen von Datensätzen und Reorganisation verletzt.

B-Baum (insbesondere seine Variante, der B+-Baum) bietet nicht immer das be-ste, aber ein gutes Zeitverhalten sowohl bei �nd, insert und remove (mit Garantieeiner Maximal-Komplexität für den �schlechtesten Fall�) und erfüllt damit auch dieForderung nach e�zienten Veränderungsoperationen. Neben dem gezielten Zugri�unterstützt er e�zient den sequentiell sortierten Durchlauf und die Bereichssuche.Weiterhin ist eine Prä�x-Suche möglich.Auch die Skalierbarkeit ist gegeben. Somit bietet er beste Voraussetzungen, wie

auch seine extensive Nutzung in sehr vielen DBMS etc. beweist. Selbst aktuelleImplementierungen (wie z.B. das XML-DBMS eXist[M+]) greifen auf ihn zurück.

Zugri�smethoden für Texte

Su�x- und PAT- Bäume/Felder: Hier ist der Aufbau und Änderung sehr teu-er, falls der Text nicht in Hauptspeicher paÿt! E�ziente Veränderungsoperationenfür die angestrebten Dokumentgröÿen sind so nicht gegeben. Weiterhin kann derSpeicherbedarf immens hoch werden. Die Suchzeitkomplexität ist die gleiche wie beikomprimierten Invertierten Listen, jedoch ist der Speicherbedarf letzterer wesentlichgünstiger.Neben den genannten Nachteilen muÿ bei den Su�x-Arrays der Originaltext bei

der Suche verfügbar sein. PAT-Arrays sind Sekundärspeicher-geeignet; die Suche istjedoch etwas teuerer als beim Baum: (2log2n−1) Vergleiche, 4log2n Plattenzugri�e(siehe [Fuh97]).

Signature �les erlauben per Bit-Operationen eine sehr e�ziente Suche, dennochist die Komplexität linear. Somit eignen sie sich nicht für groÿe Datenmengen �dies war jedoch eine unserer Forderungen (s.o.).

Invertierte Listen bieten eine einfache Implementation, sehr e�ziente Suche (nachWörtern) und mäÿigen Speicherbedarf. Sie werden (immer noch) von vielen als besteVariante angesehen (siehe u.a. [BYN99]). Die Skalierbarkeit ist gegeben, die Kostenfür Änderungsoperationen hängen von der konkreten Implementierung ab, sind aberi.d.R. gering. Somit empfehlen sie sich (mindestens für einen Text-Index).

61

4 Zugri�smethoden

Zugri�smethoden für Dokument-Strukturen

Die meisten Ansätze greifen auf Invertierte Listen zurück. Um die Dokumentstruk-tur mit zu berücksichtigen, werden teilweise Wort-Indexe für alle / einen Teil derKnoten angelegt. Ein hoher Aufwand, der sich nur in bestimmten Situationen �rech-net�. So sind solche Indexe z.B. für allgemeine Suchanfragen teuer, da viele kleineIndex-Dateien zu durchsuchen sind. Besser erscheint hier eine Kombination vonallgemeinem Text-Index und einem Struktur-Index (wie im folgenden Kapitel vor-geschlagen).Der gröÿte Nachteil fast aller Vorschläge liegt jedoch darin, daÿ sie von einer sta-

tischen Datenbasis ausgehen (So leider auch die sehr interessante Möglichkeit derBerechnung von Kind-/Eltern-/Vor-/Nachfahre-Beziehung anhand speziell konstru-ierter Element-IDs). Die e�ektive Unterstützung von Veränderungen an der Daten-basis ist jedoch eines der Ziele des AST/TAP -Modells � so müssen auch die Indexeentsprechend ausgelegt sein.Weiterhin benötigen viele Ansätze manuelle Hilfe bzw. Eingri�e (z.B.: [MS99],

[CCCX00], [CA98], u.a.).Die Dataguides und der NRP-PAT-Index bieten sehr interessante Ansätze. Er-

stere bieten jedoch keine eigene exakte Index-Methode (Speicherung in ODBMS);bei letzteren könnte die Gröÿe des Indexes beträchtliche Ausmaÿe annehmen. Auchbildet der ASTP schon einen Groÿteil des Indexes ab. Wenn später Statistiken überdie konkreten Anfragen vorliegen, wäre ein reverser ASTP vielleicht zu überdenken.Die Idee der �Relative Region Coordinates� zur Minimierung des Aufwandes �oÿ

schon in den ASTP ein. Bei ähnlichen Problemen und Gegebenheiten sollte dieNutzung auch im Index in Betracht gezogen werden.

Auswahl

Nach ausgiebiger Betrachtung fällt die Wahl eindeutig zugunsten des B+-Baumes.Zusätzlich zur Erfüllung aller Anforderungen ist er auch noch universell (in Bezugauf Schlüssel und Werte-Datentyp) und läÿt sich für alle zu entwerfenden Indexe(und auch intern) nutzen. Der zu verwendende B+-Baumes muÿ jedoch auf dieSpeicherung mehrerer Werte ausgelegt sein.Für Text-(Wort-)Indexe stellen Invertierte Listen die beste Methode dar. Die

Suche im Vokabular kann durch beliebige (klassische) Zugri�sverfahren e�ektiviertwerden. Der B+-Baum mit seinen positiven Eigenschaften bietet sich hier an.

62

5 Entwurf

In Kapitel 3 wurden die zu unterstützenden Anfragen ausgearbeitet; Kapitel 4 wid-mete sich der Betrachtung und Auswahl von Indexverfahren. Dieses Kapitel wirduntersuchen, ob und wie die Anforderungen am besten umgesetzt werden können.Umsetzungsideen werden vorgestellt, eine Leistungsbetrachtung durchgeführt undkonkrete Indexe mit Blick auf das AST/TAP -Modell entworfen. Anschlieÿend wer-den einige besonders wichtige Indexe im Detail diskutiert.

5.1 Revision der Anforderungen

Dieser Abschnitt befaÿt sich mit der Umsetzung der in Kapitel 3 erarbeiteten Anfor-derungen in konkrete Indexe. Die jeweilige Machbarkeit/E�zienz sowie notwendigeFunktionalität soll betrachtet werden.

5.1.1 Inhalts - Anfragen

Begonnen wird mit der Betrachtung einer möglichen Indexierung des Textinhaltes.

5.1.1.1 Lexikalische Suche nach Zeichen

Die Indexierung aller Zeichenfolgen eines Textes würde einen immens groÿen In-dex zur Folge haben (Zur Erinnerung aus Abschnitt 4.2.2: Die Realisierung einesSu�x-Trees würde das 10-20fache, die eines Su�x Arrays ca. das vierfache des Spei-cherplatzes des Originaltextes beanspruchen). Somit fällt die Entscheidung ganzeindeutig gegen einen Index für Zeichenfolgen.Durch den im Folgenden dargestellten Wort-Index kann jedoch ein Groÿteil der

Funktionalität abgebildet werden: Prä�x-, Su�x-, Teilstring-Suche sind möglich undmit geringem zusätzlichen Mehraufwand auch Phrasensuche.

5.1.1.2 Lexikalische Suche nach Wörtern

Die Indexierung von Wörtern bzw. Index-Termen1 ist im Information Retrievaldie verbreiteste, am besten erforschte und wohl einzig ökonomische Methode derIndexierung von (groÿen) Texten. In Abschnitt 4.2 wurde herausgearbeitet, daÿInvertierte Listen (auf den Index Termen des Textes) die beste Methode hierfürdarstellen, auch Baeza-Yates, Ribeiro Neto & Navarro kommen in [BYN99] zudiesem Schluÿ.1im Folgenden der Einfachheit halber nur als Wort bezeichnet

63

5 Entwurf

�Wort 7−→ TextSurrogat� versus �Wort 7−→ Node-ID�

Der Zweck des Indexes besteht darin, für ein Wort möglichst e�zient eine Listealler Positionen zu erhalten, an denen dieses Wort im Text vorkommt. Die intui-tive Idee wäre entsprechend, zu jedem Wort eine Liste der Positionen (bzw. derTextSurrogate, siehe Abschnitt 2.3.2 AST/TA) zu speichern.Dies würde jedoch einen enormen Aufwand bei Änderungen am Text implizieren.

Wird nur ein Byte am Beginn des Dokumentes eingefügt, müssen sämtliche Text-Surrogate im Index geändert werden. Selbst wenn nur ein kleiner Teil des XML-Dokumentes betro�en ist, wird dies schnell eine sehr teure Operation, da der Indexnach dem Vokabular und nicht nach Text-Positionen geclustert ist.Eine Alternative ist die jeweilige Speicherung der Node-ID des ASTP -Knotens,

in dessen Text-Segment das Wort vorkommt (Eine Node-ID bezeichnet eindeutigeinen Knoten im ASTP ; für jeden Knoten wiederum ist dort der Anfag und dieLänge des zugehörigen Textsegmentes im TextArray gespeichert). Je nach Bedarfkann die Position(O�set) in diesem Text-Segment dem Index hinzugefügt werden.Somit reduziert sich die Notwendigkeit eines Updates auf die � im Vergleich zuobigem sehr seltene � Situation, in der ein Wort innerhalb diese Text-Segmentesverschoben wird.

Funktionen

Folgende Funktionen soll der Index anbieten:

• Suche�nd(Wort) 7−→ (Node-ID, O�set) sucht alle Vorkommen des Wortes �Wort�

und gibt für jeden �Tre�er� die Node-ID des umschlieÿenden Elementessowie die Position (O�set) innerhalb des Elementes zurück. Die Längedes Wortes ist aus der Anfrage ermittelbar (und bei jedem Vorkommendes gleichen Wortes logischerweise gleich).

�ndInElem(Wort, ElemName) 7−→ (Node-ID, O�set) Wie ��nd�, die Suchewird jedoch auf Element-Knoten mit dem Namen �ElemName� einge-schränkt.

�ndInRegion(Wort, From, To) 7−→ (Node-ID, O�set) Wie ��nd�, die Suchewird jedoch auf einen Bereich des TextArrays eingeschränkt (von Posi-tion �From� bis �To�).

• WartunginsertWord(Wort, NodeID, O�set) 7−→ bool Fügt die Informationen über

ein (neues) Wort in den Index ein.removeWord(Wort, NodeID, O�set) 7−→ bool Entfernt die Informationen

über ein Wort aus dem Index.

Text-Normalisierung

Die Nicht-Indexierung von sehr häu�g vorkommenden Wörtern kann die Index-gröÿe stark senken ohne die Suchfunktionalität nennenswert einzuschränken (Text-Normalisierung, siehe Abschitte 2.2.3, 4.2.1.1, [BYN99] u.a.).

64


Weiterhin kann die Anwendung einer weiteren Text-Normalisierung zur Suchzeitdie Funktionalität erhöhen (s.u.: Ähnlichkeit, semantische Verhältnismäÿigkeit). Diezweite Text-Normalisierung sollte den Index nicht verändern, um sowohl exakte alsauch (evtl. verschiedene) �normalisierte� Suchen auf dem Index zu erlauben.Da eine Text-Normalisierung jedoch immer anwendungsabhängig ist, sollten beide

Varianten frei de�nierbar sein.

5.1.1.3 Lexikalische Suche nach Wortfolgen/Phrasen

Über den Wort-Index läÿt sich auch die Suche nach Wortfolgen relativ e�zient wiefolgt umsetzen:

1. Benutzung des Wort-Indexes als Vor�lter. Angenommen wird, das im Wort-Index die Node-ID sowie die Position(�O�set�) im zugehörigen Text-Segmentgespeichert wurde.

2. Test auf Aufeinanderfolgen der Wörter. Dies kann ohne Zugri� auf den Texterfolgen, da nur die absoluten Text-Positionen der möglichen Kandidaten füreinen Test benötigt werden. Diese sind aus dem TextSurrogat des Knotens(Node-ID) und dem �O�set� einfach ermittelt. Da der Text im TextArraydahingegen normalisiert wurde, daÿ alle Folgen von �whitespaces� auf einwhitespace reduziert wurden, muÿ gelten:

Wort1 folgt Wort2 , falls gilt: Ende(Wort1) + 1 = Anfang(Wort2)

Dies gilt auch über � selbst mehrere � Elementgrenzen hinweg!

5.1.1.4 Erweiterungen

Nähe Über den Wort-Index enthält man einfach die Positionen der Wort-Vorkom-men im Text. Somit sind Abstände auf Grundlage der Einheit �Zeichen� direkttestbar. Bei der Benutzung anderer Einheiten (wie �Wörter�, �Sätze�, �Kapitel�etc.) ist ein Filter aufgrund des Wort-Indexes und anschlieÿender Test aufdem Originaltext notwendig. Bis auf Ausnahmen sollte dies jedoch wesentliche�ektiver sein als ein Scan des gesamten Textes.

Häu�gkeit von Wörtern/Phrasen Die Häu�gkeit vonWörtern wird direkt imWort-Index gespeichert und ist so sehr e�ektiv ermittelbar. Funktionen wie�AT LEAST / MOST� aus IRQL u.ä. können so direkt unterstützt werden.Die Ermittlung der Häu�gkeit von Phrasen setzt eine komplette Ermittlungder Phrasen nach obigem Algorithmus und anschlieÿender Zählung voraus.

Ähnlichkeit wie �Soundex�, ähnliche Schreibweise, Tippfehler, Synonyme etc. kön-nen meist durch eine Text-Normalisierung e�ektiv behandelt werden (sieheAbschnitt 2.2.3). Auch wenn es einige Normalisierungs-Techniken gibt, wel-che sehr breit anwendbar sind, sollte eine Text-Normalisierung immer auf dieAnwendung abgestimmt werden. Um sie �exibel und für jede Anfrage passendzu gestalten, wird die Ausführung einer frei de�nierbaren Text-Normalisierungzur Suchzeit empfohlen. Der (schon de�nierte) allgemein verwendbare Wort-Index kann und sollte hierfür unverändert als Grundlage dienen, um jeglichenInformationsverlust auszuschlieÿen.

65

5 Entwurf

semantische Verhältnismäÿigkeit ist eine sehr wünschenswerte, jedoch auch sehrschwierig umzusetzende Funktionalität. Hier bedarf es noch viel eingehen-der Forschung, um diese auch auf groÿen Datenbasen und ohne menschlicheMithilfe umzusetzen. Die Verwendung von Thesauri und Ontologien im IR-Bereich bietet vielversprechende Ansätze im Informations-Retrieval-Bereich.Über die schon angesprochene Text-Normalisierung könnte man solche Erfah-rungen nutzen.[HP] macht einen weiteren Vorschlag, welcher sehr einfach umzusetzen istund den �Such-Komfort� stark erhöht: Die Aufhebung der Unterscheidungzwischen Element und Attribut (für die Dauer der Suche). Bsp.: Eine Jahres-zahl soll in �year� gefunden werden, unabhängig davon, ob es sich bei �year�um ein Element oder Attribut handelt. Die Lösung besteht einfach in dergleichzeitigen Suche nach Elementen und Attributen.

5.1.2 Struktur - Anfragen

5.1.2.1 Suche nach Elementen

Der e�ziente Zugri� auf alle Elemente mit dem gleichen Namen kann sehr einfachdurch einen direkten (Sekundär-)Index mit folgender Abbildung unterstützt werden:

Name 7−→ Node− ID

Eine Node-ID adressiert einen Knoten in der ASTP -Datenstruktur eindeutig undbietet direkten Zugri� auf ihn. Dieser Index soll im Abschnitt 5.2 noch genaueruntersucht werden.

5.1.2.2 Suche nach Attributen

Ein Attribut-(Namen-)Index kann in gleicher Weise wie der Element-(Namen-)Indexentworfen werden. Die Abbildung

Name 7−→ Node− ID

paÿt hervorragend. Die Präsentation des Ergebnisses als Menge von Node-IDs bietetviele Vorteile:

• Der ASTP bietet über die Node-ID direkten Zugri� auf das Element, zu demdas Attribut gehört, und damit auf:

� Attribut-Wert(e),� Element-Namen etc.

• Es ist möglich, Mengenoperationen mit anderen Zwischenergebnissen durch-zuführen.

• Indirekt über den ASTP sind Eltern-, Geschwister-, Kind-Knoten etc. erreich-bar.

66


5.1.2.3 Pfad - Anfragen

Der ASTP bildet die logische Struktur komplett und kompakt ab. Somit kann ergut als Index für allgemeine Pfad-Anfragen genutzt werden. Sollte er sich widerErwarten in der Praxis nicht als e�ektiv genug erweisen, wäre eine Ergänzung etwaim Sinne von Dataguides, Numerierungs-Schemata (siehe 4.3.3.1, 4.3.2.2) oder einreverser ASTP , analog den Vorschlägen in [YYU99b] (s.a. 4.3.3.2), in Betracht zuziehen.Unter den Pfad-Anfragen wurden in Kapitel 3 folgende Pfad-Anfragen als beson-

ders wichtig klassi�ziert:

�Enthaltensein�-Beziehung (Inklusion) Um diese Art von Anfragen noch e�zienterzu unterstützen, soll ein Inklusions-Index entworfen werden. Abschnitt 5.3geht hierauf im Detail ein.

direkte Eltern-/Kind-Beziehungen Auch hier bietet sich der ASTP als Index an.Ausgehend von einem beliebigen Knoten kann auf den Vater und alle Kindere�zient zugegri�en werden.

5.1.2.4 Behandlung von Reihenfolge / Position

Im ASTP existieren auf das erste und letzte Kind jedes Knotens explizite Zeiger;alle Knoten anderer Positionen lassen sich mit geringem Aufwand au�nden. Somitist kein extra Index notwendig.

5.1.2.5 Namensraum-Index

Wird für einen Knoten ein Namensraum angegeben (im Folgenden �NR-Wurzel-Knoten� genannt), so gehören alle Kinder zu diesem Namensraum, so lange fürUnter-Knoten kein extra Namensraum angegeben wird. Entsprechend würde esausreichen, wenn für alle �NR-Wurzel-Knoten� eine Abbildung

Namensraum− URI 7−→ (Namensraum− Prefix,Node− ID)

aufgebaut wird. Dann gilt: ↪→ Knoten k ε NS, falls Knoten k zum Unterbaumvon �NR-Wurzel-Knoten� r gehört ∧ zwischen k und r kein weiterer �NR-Wurzel-Knoten� existiert.Mögliche Anfragen sind unterteilbar in:

1. Suche nach bestimmten Elementen E in einem bestimmten Namensraum,2. Suche nach bestimmten Wörtern/Phrasen W in einem bestimmten Namens-

raum,3. Suche aller Elemente in einem bestimmten Namensraum.

Für 1. und 2. existiert folgende e�ziente Lösung:a) Ermittle die TextSurrogate für alle E bzw. W über den Element- bzw. Text-

Index.b) Liegen die TextSurrogate zwischen �NR-Wurzel-Knoten�-Anfang und -Ende,

so gehört E bzw. W zum Namensraum.

67

5 Entwurf

Für Anfragen von Typ 3 wird zuerst der �NR-Wurzel-Knoten� im ASTP überseine Node-ID lokalisiert. Alle Nachfahren dieses Knotens � über den ASTP direktermittelbar � gehören zum Ergebnis.Bei beiden Vorgehensweisen müssen eventuell eingeschlossene weitere Namens-

räume beachtet werden und vom Ergebnis nötigenfalls subtrahiert werden.Falls sich die Suche nach Namensräumen als sehr Zeit-kritisch herausstellt, ist ggf.

eine Indexierung aller zu einem Namensraum gehörenden Knoten zu überdenken.

5.1.2.6 Werte-basierter Index für Attribute

Werte-basiert bedeutet, daÿ der Inhalt immer als ganze, atomare Einheit betrach-tet wird (siehe Abschnitt 3.3). Es wäre jedoch eine ausgiebige statistische Studieinteressant, ob es e�ektiver ist, die Attribut-Werte als eine atomare Einheit zuindexieren oder einen Wort-Index aufzubauen (wie für den Inhalt der Elemente).Letzteres erscheint einfacher (Nachnutzung schon vorhandener Routinen) und soll-te eher einen Funktionalitätsgewinn denn -verlust darstellen: eine Suche auch nacheinzelnen Worten ist so möglich.

5.1.2.7 Kommentare

Kommentare enthalten � obwohl sie formal zur Struktur eines Dokumentes zählen� Text-Inhalt. Entsprechend wäre ein Text-Index auf Kommentaren � analog zumWort-Index in 5.1.1.2 � angebracht. Falls für zweckmäÿig betrachtet, wäre auch hierdie Anwendung einer Text-Normalisierung sehr einfach möglich.

5.1.2.8 Processing Instructions

Sollte ein Index für Processing Instructions als notwendig bzw. vorteilhaft betrachtetwerden, emp�ehlt sich folgende Behandlung:• Namens-Index über die targets: target 7−→ NodeID,• Text-Index über den Inhalt (�instruction/content�): Wort 7−→ NodeID.

5.1.2.9 Referenzen-Index

Wie schon oben erwähnt, unterscheiden sich Referenzen (gemeint sind �IDRef�s)nur semantisch von normalen Attributen. Entsprechend sind sie im Attribut-Indexgut aufgehoben.

5.1.2.10 Entity-Index

Die Vorschläge aus der Spezi�kation des AST/TA [SC] wurden schon in Abschnitt3.5 diskutiert. Der Vorschlag kann als einfache Abbildung von

Entity −Name 7−→ TextSurrogat

realisiert werden. Zu beachten ist jedoch, daÿ im Falle von Änderungen am Textder Index aktuell gehalten werden muÿ, was als sehr aufwendig betrachtet wird (s.a.5.1.1.2).

68


5.1.2.11 CData-Sections-Index

Um eine CDATA Section vollständig zu bestimmen, genügt die Angabe von Beginnund Länge (im TextArray). Demzufolge wäre eine Liste der TextSurrogate allerCDATA Sections ausreichend für deren Lokalisation. Wie beim Entity-Index ist derAufwand für die Aufrechterhaltung der Aktualität zu berücksichtigen.

5.1.3 Behandlung von Anfragen auf Inhalt & Struktur

Es folgt eine Betrachtung der möglichen Index-Unterstützung von kombiniertenAnfragen.

5.1.3.1 Textsuche in Elementen

Für die Textsuche in Elementen bieten sich folgende Vorgehensweisen an:

Nutzung des Element-(Namens-)Index zur Ermittlung aller Knoten mit demgewünschten Namen und anschlieÿendes Durchsuchen des zu jedem Knotengehörigen Text-Segmentes nach dem zu suchenden Text. Dies ist die aufwen-digste Suche, bietet sich aber an, falls nur eine kleine Anzahl von Knoten sichquali�ziert und die Textsuche komplex ist.

Nutzung des Wort-Index zur Ermittlung der Vorkommen des gesuchten Textes.Anschlieÿend müÿte für jede ermittelte Node-ID getestet werden, ob der Kno-ten den gewünschten Namen trägt. Auch dies kann sehr aufwendig werden,falls sehr viele Vorkommen ermittelt werden.

Kombination von Wort- & Element-(Namens-)Index bietet gute Chancen mit fol-gendem Vorgehen:

1. Ermitteln aller TextSurrogate (Positionen des Vorkommens + Länge) fürden gesuchten Text

2. Ermitteln aller Knoten, die den gesuchten Element-Namen tragen undderen TextSurrogate

3. Bildung des Durchschnittes über beiden Mengen.

�Erweiterter� Wort-Index Die Verweislisten des Wort-Indexes könnten jeweils nachdem Element-Namen der abgespeicherten Node-ID geclustert werden (sieheBsp. in Abb. 5.1). Das wäre die schnellste Methode für diese Art von Anfragen,setzt aber grundsätzlich einen erhöhten Aufwand für die Wartung des Wort-Indexes (Einfügen, Löschen, Ändern) voraus.

Die beiden letzten Varianten bieten die besten Aussichten. Eine statistische Unter-suchung wäre interessant, ob der Nutzen den zusätzlichen Aufwand bei der letztenVariante rechtfertigt. Für die vorletzte Variante spricht die sehr einfache Umsetzungbei erwarteten guten Ergebnissen.

69

5 Entwurf

authordocument

index

......

(Label: figure)(Label: section)

(Label: section)

(18,2),(27,3),(1,7) ,(12,4),(1,8) ,(23,9),(2,34),(1,1),

(Label: section)

(Label: section)(Label: section)(Label: title)

...(Label: title)

Verweisliste(Node−IDs, Elementnamen)

VokabularWort−Index

Abbildung 5.1: Wort-Index, nach Element(Namen) geclustert

5.1.3.2 Textsuche in Unterstrukturen

Auch hier bieten sich die ersten beiden Vorgehensweisen aus dem gerade geschlos-senen Abschnitt an. Eine dritte Variante verspricht jedoch eine einfachere undkostengünstigere Lösung:

Der ASTP ist eine Baumstruktur. Somit hat jede Unterstruktur genau ein zuge-höriges, fortlaufendes Text-Segment mit einer Anfangs- und End-Position. Kommtein Wort in diesem Text vor, so müssen sein Anfang und sein Ende innerhalb desText-Segmentes der Unterstruktur liegen. Die Text-Positionen für jedes Wort sindaus dem Wort-Index (und weniger Zugri�e auf den ASTP) e�ektiv ermittelbar.

5.1.3.3 Werte-basierter Index (für Elemente)

Werte-basierte Anfragen betrachten den Inhalt immer als atomare, ganze Einheit(siehe Abschnitt 3.3). Der Text-Inhalt von Elementen stellt typischerweise jedocheine gröÿere Einheit dar, der Inhalt wird sich selten exakt wiederholen. Somiterschlieÿt sich nicht die Zweckmäÿigkeit einer solchen Indexierung. Ein Wort-Index(s.o.) wird als die bessere Variante angesehen. Falls eine exakte Übereinstimmung/Suche gefordert wird, kann der Wort-Index immer noch als Vor�lter genutzt undein anschlieÿender Test auf dem Original-Text durchgeführt werden.

5.1.3.4 Kopplung Text- und Struktur-Suche

Um Text- und Struktur-Komponenten e�ektiv miteinander zu verknüpfen, ist einegemeinsame Adressierungsbasis notwendig. Beim AST/TAP ist dies das TextSurro-gat � ähnlich zur �Region� in Proximal Nodes[NBY97]. Bei Zugri� über den ASTPsind die TextSurrogate sofort verfügbar. Auch alle hier vorgestellten Indexe liefernauf eine Anfrage entsprechende TextSurogate oder eine Menge von Knoten-IDs,über welche sich die TextSurrogate kostengünstig aus dem ASTP ermitteln lassen.Somit ist eine e�ektive Kopplung gegeben.

70

5.2 Element-(Namen-)Index

5.2 Element-(Namen-)Index

Im folgenden soll im Detail auf den vorgeschlagenen Element-(Namen-)Index(Name 7−→ Node− ID) eingegangen werden.

5.2.1 Datenstruktur: Variante des B+-Baumes

Als Datenstruktur wurde der B+-Baum (s.a. Abschnitt 4.1.2.2) gewählt, da erfolgende positiven Eigenschaften bietet:

• garantierte maximale Zeitkomplexität sowohl für �nd als auch für insert/remove,

• unterstützt e�zient:

� direkten Zugri� auf Schlüssel,� inklusive Prä�x-Suche,� sortierter Durchlauf,

• garantierte Speicherauslastung (50-100%).

Ein �normaler� B+-Baum speichert pro Schlüssel nur einen Wert. Sind mehrereWerte (hier: Verweise) pro Schlüssel abzuspeichern, so müÿte für jeden Wert derSchlüssel erneut gespeichert werden. Tritt dies häu�ger, beeinträchtigt die hoheRedundanz die E�zienz des Indexes. O�ensichtlich treten jedoch Elemente gleichenNamens recht häu�g mehrmals auf.Die Literatur zu Inverted Files emp�ehlt eine extra Datei für Verweise. Der

Aufwand � extra Datei für Verweise, Verweise mit Seitennummer & Position fürjeden Schlüsseleintrag, extra Seiten-Management für Verweisdatei etc. � erscheintzu hoch, falls sehr lange Verweislisten nicht die Regel sind. Weiterhin sind die zuspeichernden Einträge relativ klein; so wurde eine Speicherung im Baum überdacht.Es wurde eine Erweiterung für den B+-Baum entworfen, welche die Speicherung

von einem bis beliebig vielen Werten (hier: Verweisen) pro Schlüssel zuläÿt: derMulValTree (siehe Abb. 5.2, Details s.a. 6.1).

avg. ..document element ..4author book 1 23chapter

style. . .beta document.

avg. ..document element ..4author book 1 23chapter

style. . .beta document.interneKnoten

}Blattknoten

}

Abbildung 5.2: MulValTree

71

5 Entwurf

5.2.2 Kostenbetrachtung

Sei N die Gesamtanzahl der Einträge und b die durchschnittliche Anzahl von Ein-trägen pro Seite, so ergeben sich folgende Gröÿen:

• �nd : O(logb(N)) (Seitenzugri�e)

• insert: O(logb(N)) + 0..O(logb(N)) (bei notw. Aufteilen)

• remove: O(logb(N)) + 0..O(logb(N)) (bei notw. Mischen)

• Speicherbedarf:∑(|ElementNamen|) + N × |NID| + AnzahlElementNamen × |1Zeiger|

5.2.3 Funktionen

Folgende Funktionen sollen vom Index angeboten werden:

• Suche:

- �ndNodesOfElemName(Name, resultCount) 7−→ NodeID: sucht alleElement-Knoten mit dem Namen �Name� und füllt ein Array mit derenNodeIDs. �resultCount� spezi�ziert die Anzahl der gefundenen Elemente.

• Wartung:

- insertElem(Name, NodeID) 7−→ bool: Fügt die Informationen über einen(neuen) Element-Knoten in den Index ein,

- updateElem(Name, oldNodeID, newNodeID) 7−→ bool: Ändert die Node-ID eines Element-Knotens im Index,

- removeElem(Name, NodeID) 7−→ bool: Entfernt die Informationen übereinen Element-Knoten aus dem Index.

5.3 Inklusions-Index

Gesucht wird ein e�ektiver Zugri� für XPath-Ausdrücke der folgenden Form:ELEM1//ELEM2. D.h., es werden alle Elemente �ELEM2� gesucht, welche innerhalbeines Elementes ELEM1 vorkommen. ELEM1 und ELEM2 stellen hierbei beliebige Ele-mentnamen dar, z.B.: DOC und AUTHOR.

5.3.1 Naiver Ansatz

Ein XML-Dokument kann als Baum betrachtet werden (siehe auch Abbildung 5.3).Der naive Ansatz besteht darin, alle DOC-Elemente herauszusuchen und zu prüfen,ob sich in ihren Unterbäumen AUTHOR-Elemente be�nden (siehe Algorithmus 1). DerASTP bietet hier schon eine gute Optimierung, da er die Baumstruktur kompaktabbildet. Im ungünstigen Falle müssen wir jedoch den kompletten ASTP traversie-ren, evtl. sogar Teile mehrmals.

72


Algorithmus 5.1: naives Suchen elem1//elem2(1) Ausgehend vom Root−Element, suche alle Elementknoten mit dem

Namen <Elem1> und bilde die Menge M1(2) Für jedes Element e1 in M1:

überprüfe , ob im Unterbaum von e1ein Element e2 mit Namen <elem2> existiert.Falls e2 existiert → M2 = M2 ⋃ e2

(3) M2 enthält alle gesuchten Elementknoten <Elem2>

Referenz-Aufwand Seitenzugri�e (auf den externen Speicher) stellen mit Abstanddie teuerste Operation dar. Ein Traversieren im ASTP führt schnell zum La-den sämtlicher Seiten des ASTPs (Ein Laden des Original-Dokumentes isti.d.R. wesentlich teurer! s.o.). Somit sei der Referenz-Aufwand als das Ladensämtlicher ASTP -Seiten (im Folgenden der Kürze halber nur als �Seiten� be-zeichnet) de�niert. Dies ist sehr optimistisch geschätzt, da oft Teile mehrmalsgelesen und folglich neu geladen werden müssen.

5.3.2 Ausnutzen der TextSurogate

Mit dem Konzept der TextSurrogate (ähnlich den �regions� in [NBY97]) erö�netsich jedoch noch eine andere Möglichkeit: Man stelle sich ein XML-Dokument alseinen fortlaufenden String vor:<DOC><HDR>...<AUTHOR>Chamberlin</AUTHOR></HDR>...</DOC>0 5 14 327 <- TextSurrogateAnhand der TextSurrogate können wir sofort feststellen, ob ein Element in einem

anderen enthalten ist. Von Vorteil ist, daÿ die TextSurrogate schon direkt im ASTPgespeichert sind (siehe Abbildung 5.3).

author (0,13)

(0,3489)

doc (14,48)

(9,4) (26,30)(58,6)

author (41,9)

author (14,12)

(62,86)

Abbildung 5.3: Der AST für ein XML-Dokument enthält direkt die TextSurrogatefür jedes Element

5.3.3 Direkter Index: Element-Name → TextSurrogat

Bei direkter Speicherung des TextSurrogates im Index müÿte ein Eintrag enthalten:

73

5 Entwurf

Algorithmus 5.2: Suchen elem1//elem2 via ElementIndex(1) L1 ←Suche Node−IDs aller Elementknoten mit dem Namen <Elem1>

(nutze Element−Index)(2) L2 ←Suche Node−IDs aller Elementknoten mit dem Namen <Elem2>

(nutze Element−Index)(3) Auslesen der TextSurrogate für alle Node−IDs in L1 und L2

(optimiert auf minimale Seitenzugri�e durch Clustern der Node−IDs nachSeitennummern)

(4) Test auf Inklusion anhand der ermittelten TextSurrogate(z.B. mittels �ndElemIncludedInElem bzw. �ndElemContainingElem)

Elementnamen (xx Byte)Node-ID (6 Byte)TextSurrogat (16 Byte)

Nachteile:• Index-Gröÿe Bei einem XML-Dokument von 1,5 MB (ca. 30.000 Elemente)wären das allein 660 KByte (ohne Elementnamen), das entspräche fast derHälfte des Original-Dokumentes!

• enormer Update-Aufwand Wird nur ein Byte am Beginn des Dokumenteseingefügt, müssen sämtliche TextSurrogate im Index geändert werden. Selbstwenn nur ein kleiner Teil des XML-Dokumentes betro�en ist, wird dies schnelleine sehr teure Operation, da der Element-Index nach Element-Namen geclu-stert ist und nie nach Dokument-Reihenfolge.

5.3.4 Nutzung Element-Index: Element-Name → Node-ID

Algorithmus 2 zeigt einen Inklusions-Test unter N(achn)utzung des Element-Index.Die Vorteile liegen auf der Hand:• Nachnutzung Element-Namens-Index: die Abbildung Node-ID → TextSurro-gat ist durch einfachen Zugri� auf den Knoten möglich,

• keinerlei Notwendigkeit, die TextSurrogate zu aktualisieren.

Der konkrete Test auf Inklusion ist abhängig von der Ergebnismenge, die bereit-gestellt werden soll. Algorithmus 3 berechnet alle Vorkommen von Elem2 (in XPath:Elem1 // Elem2), 4 alle Vorkommen von Elem1 (d.h.: Elem1//[ Elem2 ]). Dabeigelte:

a ⊃ i ⇔ start(a) ≤ start(i) ∧ ende(i) ≤ ende(a)

5.3.5 Kostenbetrachtung

Um die TextSurrogate zu erhalten, ist ein zusätzlicher Seitenzugri� erforderlich. Esexistieren zwei Fälle:

1. Die Elementnamen klassi�zieren nur wenige Elemente. Dann sind auch nurwenige zusätzliche Seitenzugri�e erforderlich.

74


Algorithmus 5.3: �ndElemIncludedInElem (elem1 // elem2){L1 , L2 siehe Algorithmus 2 }

result ←{}FOR ∀ i in L2 DO

IF ∃ a in L1 | a ⊃ i THENresult ←result ∪ i

ENDEND

Algorithmus 5.4: �ndElemContainingElem (elem1[ //elem2 ]){L1 , L2 siehe Algorithmus 2 }

result ←{}FOR ∀ a in L1 DO

IF ∃ i in L2 | a ⊃ i THENresult ←result ∪ a

ENDEND

2. Es klassi�zieren sich viele Elementknoten (über ihre Node-ID). In der Node-ID ist die Seitennummer enthalten, auf welcher Seite im ASTP sich der Nodebe�ndet. So ist eine Clusterung der Nodes nach Seiten möglich, und die Text-Surrogate aller Nodes einer Seite können gleichzeitig gelesen werden. Auf keineSeite des ASTP braucht doppelt zugegri�en werden.

Im ungünstigsten Fall ist die Anzahl der Seitenzugri�e genau so hoch wie imoptimistisch geschätzten Referenz-Aufwand (s.o.) plus dem geringen Aufwand fürden Zugri� im Element-Index ( O(logk(N)) ). Im Durchschnitt sollte die Anzahl derSeitenzugri�e jedoch weit darunter liegen. Exakt ist die Ersparnis schwer erfaÿbar,da sie stark von den angefragten Element-Namen, deren Vorkommen und Verteilungim Dokument/ASTP abhängig ist.

Aufwand des Listen-Vergleichs

Der Vergleich der TextSurrogate der ermittelten (und vorge�lterten) Kandidatenist letzlich noch O(M×N

2 )2. Die beiden Listen der TextSurrogate sollten jedochin den Hauptspeicher passen, wo ein quadratischer Vergleich vorerst vertretbarist. Abschnitt 5.3.6 stellt eine Verbesserung des Algorithmus 4 auf O(Mlog(N))vor (diese Variante wurde auch implementiert). Zusätzliche Optimierungen sinddenkbar.Durch die Nachnutzung Elementindex benötigt der Inklusions-Index weder zu-

sätzlichen Speicher noch Wartung (insert/remove/update).2M = Anzahl der Elem1, N = Anzahl der Elem2

75

5 Entwurf

5.3.6 Optimierung Inklusionstest

Der Algorithmus 4 � Test auf //elem1[ //elem2 ] � kann optimiert werden. Esgilt:

elem1 ⊃ elem2 ⇔ start(elem1) ≤ start(elem2) ∧ ende(elem2) ≤ ende(elem1)

76


1

2 3 4

Seite des pAST

<author>−Element

<doc>−Element

XML−ElementpAST:

Abbildung 5.4: Die Hierachie der Elemente bestimmt die Seitenhierarchie des ASTP

Da in einem wohlgeformten XML-Dokument Elemente niemals überlappen sondernnur ineinander verschachtelt oder nebeneinander liegen können, gilt auÿerdem:

start(elem1) < start(elem2) < ende(elem1) ⇒start(elem1) < ende(elem2) < ende(elem1)

Daraus folgt: start(elem1) ≤ start(elem2) ≤ ende(elem1) ⇒ elem1 ⊃ elem2

Somit ist die Suche, ob ein Element elem1 irgendein Element aus einer Menge vonelem2's enthält, auf eine Dimension (den Start-Positionen der elem2's) reduzierbar.Für einen Test reicht eine binäre Suche auf der � sortierten � Liste der Start-Positionen der elem2's. Die Komplexität reduziert sich auf M × log(N) plus N ×log(N) für das Sortieren der elem2-Liste.

5.3.7 Weitere Optimierung: Seitenhierarchie als Vor�lter

Die Struktur der Seiten des ASTP ist abhängig von der Struktur der Element-Knoten im ASTP (siehe Abb. 5.4): Existiert ein Pfad von einem Knoten K1 zu einemKnoten K2, so existiert auch ein Pfad der zugehörigen Seiten in der Seitenhierarchie(Ein Beispiel: Die Seitenhierarchie für das einzelne author-Element auf ASTP -Seite13 in Abb. 5.5 lautet: 1-2-5-9-13).Die Seitenhierarchie enthält so wertvolle Information für Optimierungen. Sei

ein Element a auf Seite A gegeben. Ein Element d kann nur dann Element aumschlieÿen, falls es auf einer Seite des Pfades von A zur Wurzel des ASTP liegt.

<doc>−Element<author>−Element

Seite des pAST

pAST:

2 3

4

5 8

9

7

1

6

10 11 12

13 14

Abbildung 5.5: ASTP : Seitenhierarchie & Beispiel-Verteilung von Elementen mit be-stimmten Namen

77

5 Entwurf

Algorithmus 5.5: Containing - Vor�lter{ Geg.: NIDs von <Elem2>, ermittelt per Element−index .In der NID ist die Seite( des ASTP) enthalten, auf welcherdas Element gespeichert ist.}L1 − sortierte Liste der TextSurrogate der <Elem1>−ElementeLS2 = alle Seiten , auf denen ein <Elem2> vorkommtP2 =

FOR ALL s2 IN LS2P = Ermittle alle Seiten auf dem Pfad zur Wurzel

(Nutzung Page-Dictionary des ASTP )P2 = P2

⋃P

END /∗ for ∗/FOR ALL e1 IN L1:

IF 6 ∃ Seite s ε P2, welche e1 enthält.THEN Lösche e1 aus M1END

END /∗ for ∗/.

Betrachten wir die Element-Verteilung in Abb. 5.5. Das author-Element auf Seite13 kann kein umschlieÿendes doc-Element haben, da auf den Seiten 1,2,5,9 und 13kein doc-Element existiert. Es ist nicht nötig, nur eine einzelne Seite zu laden!Weitere Einsparungen: um die author-Elemente auf Seite 14 auf umschlieÿende

doc-Elemente zu testen, muss einzig Seite 14 und Seite 3 laden werden! Auch dasLaden der Seiten 1, 8 und 11 kann entfallen. Den Algorithmus für die beschriebeneOptimierung zeigt 5.

5.4 Zusammenfassung

Text-Indexe Eine Zeichenindexierung wurde als zu aufwendig eingeschätzt. DieWahl �el zugunsten eines Wort-Indexes, welcher eine im Information Retrieval-Bereich sehr gebräuchliche Variante darstellt und auch einfach zu implementierenist.Die Vorkommen von Wörtern und deren Anzahl sind über diesen Index sehr

e�ektiv ermittelbar. Die Suche nach Phrasen und deren Anzahl benötigt nur einengeringen Mehraufwand.Die Anwendung von frei de�nierbaren Text-Normalisierungen wird empfohlen.

Zum einen läÿt sich so die Indexgröÿe stark einschränken, zum anderen die Funktio-nalität erhöhen (Unterstützung von Ähnlichkeit, semantische Verhältnismäÿigkeit).

Struktur-Indexe Die wichtigsten Komponenten stellen hier die Element- und Attri-but-Indexe dar, welche die Namen auf entsprechende Node-ID(s) abbilden.Anfragen bezüglich Reihenfolge und Position als auch (allgemeine) Pfade und

direkte Eltern/Kind-Beziehung sind über den ASTP e�zient lösbar und bedürfenso keines Indexes. E�zientere Algorithmen wurden für die Inklusionsbeziehungen

78

5.4 Zusammenfassung

von Elementen entworfen, welche ohne eigene Datenbasis auskommen und daherkeinerlei Wartung benötigen.Für die Inhalte von Attributen, Kommentaren, Processing Instructions wird eine

jeweilige Instanzierung des oben vorgeschlagenen Wort-Indexes empfohlen. Auch fürKommentare und Attributwerte wäre die Anwendung einer Text-Normalisierung zurSuchzeit denkbar.Für Namensräume ist eine Abbildung Namensraum−URI 7−→ (Namensraum−

Prefix,Node− IDdesWurzelknotens) vorgesehen; für Verarbeitungsanweisungeneine Abbildung Ziel 7−→ Node− ID implementierbar.Um die Originale der im AST/TAP gespeicherten Dokumente wiederherzustellen,

werden die Textpositionen von Entitities und CData Sections benötigt. Für ersterewird eine Abbildung Entity−Name 7−→ TextSurrogat benötigt, für letztere reichteine Liste der TextPositionen.

Kombinationen Für ASTP , TAP und alle vorgestellten Indexe existiert eine ge-meinsame Adressierungsbasis: die TextSurrogate. So ist nicht nur die Textsuchein Elementen und Unterstrukturen über die Kopplung von zwei Indexen e�ektivlösbar. Auch diverse andere Kombinationen der vorgestellten Indexe untereinanderbzw. mit ASTP oder TAP sind möglich.Zu überdenken ist die Notwendigkeit eines Entity- und CData-Section-Index

aufgrund des hohen Aufwandes bei Veränderungen sowie die Zweckmäÿigkeit einesClusterns des Wort-Indexes nach Elementnamen (siehe 5.1.3.1) nach Vorliegen vonausführlichen Statistiken.

Entwurfsergebnis

Alle vorgestellten Indexe lassen sich mit Hilfe des erweiterten B+-Baumes realisie-ren. Eine e�ektive Kopplung der Indexe untereinander und mit ASTP und TAP istdurch die gemeinsame Adressierungsbasis der TextSurrogate gegeben.Die Indexgröÿe ist gering. Der Element-Index nahm in den Tests (s.u.) weniger

als ein 1/3 des Orig-Dokumentes ein (normalerweise wesentlich gröÿer).Die Forderung nach der Unterstützung e�ektiver Veränderungsoperationen wird

durch die Struktur (B+-Baum), die geringe Anzahl und die geringe Gröÿe der Indexeunterstützt.

79

5 Entwurf

80

6 Realisierung

6.1 Implementation

Im Rahmen des AST/TA-Projektes sollte der Element-Index und der Pfad Indexexemplarisch implementiert werden. Die Implementation erfolgte in C/C++.

6.1.1 Genutzte Datenstruktur

Als zugrundeliegende Datenstruktur wurde der MulValTree gewählt, eine Variantedes B+-Baumes (Gründe siehe Abschnitt 5.2). Abb. 5.2 auf Seite 71 skizziert einensolchen Baum.

6.1.1.1 Interna

In dem Baum soll es möglich sein, pro Schlüssel ein bis beliebig viele Werte abzu-speichern. Dadurch werden Einträge variabler Länge in den Blattknoten � nur hierwerden Werte gespeichert1 � benötigt. Abb. 6.1 zeigt den internen Aufbau einessolchen Blatt-Knotens.

(free space )

Key1 ValCountHeader ValCount ValCountKey2 Key3 Val−

Count

Key4

......

... Key2−Values Key1−Values

Abbildung 6.1: Blatt-Knoten: Einträge teilen sich in einen Teil mit fester und einenTeil variabler Länge.

Um dennoch einen schnellen, direkten Zugri� � für eine binäre Suche o.ä. � aufdie Schlüssel zu gewähren, wurde der variable Teil vom festen Teil getrennt (s.a.Empfehlung in [HR01] und [Mar00]). Auch kann so ein weiterer Wert zu einemschon existierenden Schlüssel hinzugefügt werden, ohne daÿ irgendein fester Teileines Eintrags verschoben werden muÿ.Da beliebig viele Werte möglich sein sollen, kann es vorkommen, daÿ nicht alle

Werte auf eine Seite passen. Hierzu wurden Überlaufseiten vorgesehen, welche ih-rerseits wieder eine Überlaufseite zugewiesen bekommen können. Entsprechend ist1siehe De�nition B+-Baum, Abschnitt 4.1.2.2

81

6 Realisierung

die Anzahl der Werte pro Schlüssel praktisch nur durch den Plattenplatz und demFassungsvermögen des Werte-Zählers beschränkt. Implementiert wurde der Zählerals �unsigned int�; dies erlaubt die Speicherung von bis zu 4.294.967.295 Werten proSchlüssel.

6.1.1.2 Funktionen auf dem Baum

Der Baum bietet die üblichen Funktionen:

• create(): Erstellen eines (leeren) Baumes.• open(): Ö�nen des �Baumes� (genauer: der Datei).• close(): Schlieÿen des �Baumes� (genauer: der Datei)• find( key ): Finden der Werte zu einem angegebenen Schlüssel �key�.• insert( key, value ): Einfügen von (key, value) in den Baum (falls nochnicht vorhanden).

• remove( key, value ): Entfernen von (key, value) aus den Baum (fallsvorhanden).

• print( outStream ): Ausgabe des Inhaltes der Knoten des Baumes undeiner Statistik über Anzahl der genutzten Seiten und Speicherausnutzung (fürdebug-Zwecke).

6.1.2 Code-Nachnutzung

Die gesamte Implementation des Baumes erfolgte als Template; Parameter sind die(beiden) Datentypen für Schlüssel und Werte. Dadurch kann durch einfache Instan-zierung die gesamte Baum-Funktionalität für beliebige Datentypen als Schlüssel undWert realisiert werden, ohne eine Zeile des Codes zu ändern.Die Datentypen müssen folgenden Anforderungen genügen:

• Für den Datentyp des Schlüssels muÿ der Operator �<� und �=� de�niert sein,• Für den Datentyp des Wertes muÿ der Operator �=� de�niert sein,• Beide Datentypen müssen eine feste (und mit sizeof() korrekt abfragbare)Gröÿe besitzen.

6.1.3 Element-Index

Auf Basis des Baum-Templates läÿt sich nun leicht der Element-(Namens-)Indexrealisieren. XML selbst birgt jedoch ein Problem, das schnell übersehen wird: Ele-mentnamen besitzen keine feste Maximal-Länge, sie können (theoretisch) unendlichlang sein.Um dieses Problem zu umgehen, wurde die Maximal-Länge der Elementnamen

(für die Implementation des Indexes) auf 64 Zeichen (�unsigned char�) begrenzt. EinDatentyp �XMLName� wurde angelegt, welcher die Begrenzung beachtet und dieoben geforderten Operatoren bereitstellt.

82

6.1 Implementation

Der Index stellt folgende Funktionen bereit:

• SucheNodeIDArray* findNodesOfElemName( Name, resultCount ) Sucht alleElement-Knoten mit dem Namen �Name� und füllt das Array mit deren Node-IDs. �resultCount� gibt Auskunft über die Anzahl der gefundenen Elemente.

• Wartung

� bool insertElem( Name, NodeID ): Fügt Information über einen (neu-en) ElementKnoten in den Index ein (falls noch nicht vorhanden),

� bool updateElem( Name, oldNodeID, newNodeID ):Ändert die Node-ID eines Element-Knotens im Index,

� bool removeElem( Name, NodeID ): Entfernt die Informationen übereinen ElementKnoten aus dem Index (falls existent),

� print( outStream ): Ausgabe des Index-Inhaltes (für debug-Zwecke)inklusive einer Statistik über Anzahl der genutzten Seiten und Speicher-ausnutzung.

6.1.4 Pfad-Index

Wie im Entwurf (Abschnitt 5.3) diskutiert, wird für den Pfad-Index keine eigeneDatenbasis aufgebaut, sondern der Element-Index (nach)genutzt. Dies hat zusätz-lich den Vorteil, daÿ keinerlei Wartung des Indexes nötig ist. Implementiert wurdendie oben vorgestellten Algorithmen 2 und 3. Anstelle von Algorithmus 4 wurde diein 5.3.6 vorgestellte Optimierung implementiert.Die bereitgestellten Such - Funktionen sind:

• NodeInfoVector findElemContainingElem( ElemName1, ElemName2 ):�ndet alle Element-Knoten mit Namen �ElemName1�, welche einen Element-Knoten mit Namen �ElemName2� enthalten.

• NodeInfoVector findElemIncludedInElem( ElemName1, ElemName2 ):dito reverse.

Der NodeInfoVector enthält für jeden (gefundenen) Knoten die Node-ID sowie seinTextSurrogat.

6.1.5 Integration in den AST/TAP

Im Projekt wurde ein Unterverzeichnis und Namensraum �Index� angelegt, welchesalle zu den implementierten Indexen gehörigen Source-Dateien enthält.Die zentrale XEE-Kon�guration (steuerbar über Kommandozeilen-Parameter)

wird genutzt, um Parameter � wie Seitengröÿe, Anzahl der Pu�erseiten, die Aus-führlichkeit von Ausgaben über statt�ndende Aktionen/Ergebnisse etc. � zu beein-�ussen. So bewirkt zum Beispiel ein Setzen des Parameters �DocumentPrintLevel�

83

6 Realisierung

auf einen Wert von 4 oder höher die Ausgabe des kompletten Element-Indexes in-klusive Statistik wie Seitenauslastung etc. als auch zusätzliche Ausgaben währenddes Tests des Pfad-Indexes.Die Funktionen des Indexes wurden in den (weiteren) XEE-Quellcode integriert

werden. Dabei wurde Wert darauf gelegt, notwendige Anpassungen so gering wiemöglich zu halten; sie beschränken sich auf folgende Punkte:

• Die Indexe werden in der Klasse pAST::Document instanziert und mit diesergeö�net und geschlossen. So stehen alle Funktionen des Element- und Pfad-Indexes zur Verfügung, solange �Document� geö�net ist.

• Die Funktion pAST::FileLoader::loadFile() wurde entsprechend erwei-tert, daÿ während des Ladens eines Dokumentes gleichzeitig der Index �gefüllt�wird.

• Ein Ändern der Node-ID im ASTP (pAST::NodePool::updateAddress) be-wirkt eine gleichzeitige Anpassung des Element-Indexes. Damit Aktualitätgesichert. Der Pfad-Index benötigt keinerlei Wartungsoperationen, da er aufden Element-Index zurückgreift und keine eigene Datenbasis besitzt.

• Zu pAST::Document wurden folgende Funktionen hinzugefügt:� Node* getNode(Node::ID nodeID): Lädt den zu Node-ID gehörendenKnoten und gibt das (neu gescha�ene) Node-Objekt zurück.

� XEE::Config* getConfig(): Gibt einen Zeiger auf die XEE-Kon�gura-tion zurück.

� getElementIndex(): Gibt einen Zeiger auf den (zum Document gehö-renden) Element-Index zurück über den die entsprechenden Funktionenaufgerufen werden können.

� getPathIndex(): Gibt einen Zeiger auf das Pfad-Index-Objekt zurück,über welches deren Funktionen aufgerufen werden können.

6.1.6 Schwierigkeiten

Die Einarbeitung in das � doch ziemlich komplexe � Projekt erforderte einigenZeitaufwand. Es war das erste Projekt des Autors dieser Gröÿe und gab Gelegenheitfür viele Erfahrungen, von denen er in Zukunft pro�tieren kann.Da es sich um ein Projekt in Entwicklung handelte, war auch ab und zu auf

Änderungen in der Struktur oder API zu reagieren; nicht immer war die Struktur desProjektes konsistent. Gelegentlich wurde viel Zeit für die Fehlersuche verbraucht,deren Ursache letztlich auf einen anderen Teil des Projektes zurückzuführen war.Sehr hilfreich waren die �Programmierrichtlinien� und wichtige Information auf

der Projekt-Webseite, um deren Aktualität der Projektleiter bemüht war.

6.1.7 Weitere Indexe

Durch die Universalität und Nachnutzbarkeit des Template können genau so einfachwie der Element-Index auch Attribut- und Wort-Indexe, Indexe für Targets derProcessing Instructions etc. erstellt werden.

84

6.2 Analyse & Test

6.2 Analyse & Test

Im Folgenden werden kritische Teile der Implementation betrachtet sowie die durch-geführten Tests erläutert und deren Ergebnisse zusammengefaÿt. Zu jeder Klassewurde eine Test-Prozedur �unittest()� implementiert, welche die angebotene Funk-tionalität testet.

6.2.1 Kostenrelevante Eigenschaften des Baumes

Höhe des Baumes Die Länge der Pfade vom Knoten zur Wurzel ist für jeden Blatt-Knoten gleich! Dies kann zugesichert werden, da ein Aufteilen (Split) einesKnoten immer den Weg zur Wurzel nach oben propagiert wird. Falls eine neueEbene in den Baum eingefügt werden muÿ, geschieht dies an der Wurzel unddamit für alle Unterbäume gleichzeitig. Das Vorgehen beim Mischen (Merge)ist analog.

Füllgrad der Knoten Für die internen Knoten wird der von B-Bäumen bekannteFüllgrad von 50..100% durch dieselben Beschränkungen beim Aufteilen undMischen eines Knotens eingehalten.Für die Blattknoten ist dies schwieriger, da hier mit Einträgen variabler Längehantiert wird, was das exakte Teilen �in der Mitte� eines Knotens oft unmög-lich macht. Die implementierten Aufteilungs- und Misch-Algorithmen versu-chen jedoch, dem Ideal (siehe interne Knoten) möglichst nahe zu kommen.Ein Sonderfall könnte auftreten, falls von drei benachbarten Blatt-Knoten diebeiden äuÿeren überlaufen. Dann ist eine Minderbelegung der mittleren Seitein besonderen Fällen möglich.Die Praxistests ergaben gute Werte für die Seitenauslastung: Z.B. durchweg59,5 bis 100% für die Blattknoten. Die einzelnen Werte sind aus den Tabellen6.1 und 6.2 (Seite 86) ersichtlich.Auch Belegung der internen Knoten ist für gröÿere Mengen von Daten gut (58-82%). Bei kleinerem Umfang der Datenmenge � und damit Nutzung wenigerinterner Seiten � kann es zu einer mehr oder weniger starken Minderbele-gung der Wurzel (wie auch im B-Baum zugelassen) kommen. Dies beein�uÿtaufgrund der geringen Gröÿe der Einträge die Gesamtbelegung stark.

6.2.2 Test MulValTree

Zum Test der Insert- und Remove-Methode des Baumes wurde je eine Datei mitTestdaten generiert. Getestet wurde mit diversen Gröÿenordnungen (κ = AnzahlTestdatensätze) und folgenden Datentypen als <Schlüssel>,<Wert>:• int, int• XMLName (64 unsigned char), int

Die Testdatei für das Einfügen enthielt κ zufällig generierte Schlüssel und Werte (derjeweiligen Datentypen). 2/3×κ dieser Werte wurden in die Testdatei für das Löschenübernommen, welche mit weiteren zufälligen Werten aufgefüllt wurde. Entsprechendmuÿten zwei Drittel der �Test-Lösch-Werte� ein erfolgreiches Löschen hervorrufen,bei dem weiteren Drittel muÿte das Löschen scheitern.

85

6 Realisierung

Für das Testen der Find-Methode und der Kontrolle für Insert und Remove wurdendie in den Baum eingefügten/gelöschten Daten parallel in ein STL-MultiMap einge-fügt/gelöscht. Anschlieÿend wurde getestet, ob die im STL-MultiMap verbliebenenEinträge auch wirklich im Baum enthalten waren. Um sicherzustellen, daÿ nichtweitere Einträge im Baum verblieben sind, wurde ein �nd eines schon erfolgreichgelöschten Eintrages aufgerufen, welcher fehlschlagen muÿte.

Anzahl der Belegung derSeiten Seiten in %

Beschreibung IS BS ÜS IS BS ÜS5.000 zufällige Werte für gleichenSchlüssel eingefügt, Seitengröÿe: 1024B.

0 1 19 - 100 98,79

1.707 (e�ektiv) wieder gelöscht: 0 1 13 - 100 92,545.000 zufällige Paare eingefügt, Seiten-gröÿe: 1024B.

1 32 0 25 65,22 -

3.487 (e�ektiv) wieder gelöscht: 1 12 0 9 62,84 -10.000 zufällige Paare eingefügt, Seiten-gröÿe: 512 Byte

5 131 0 42,4 67,65 -

6.666 (e�ektiv) wieder gelöscht: 1 52 0 82 67,2 -100.000 zufällige Paare eingefügt, Sei-tengröÿe: 512Byte

12 500 500 67,17 100 61,04

67.654 (e�ektiv) wieder gelöscht: 12 452 0 60,75 59,48 -100.000 zufällige Werte für gleichenSchlüssel eingefügt, Seitengröÿe: 1024B.

0 1 395 - 100 99,82

33.407 (e�ektiv) wieder gelöscht: 0 1 263 - 100 99,7

Tabelle 6.1: Zusammenfassung der Baum-Tests für die Datentypen int/int.

Anzahl der Belegung derSeiten Seiten in %

Beschreibung IS BS ÜS IS BS ÜS1.000 zufällige Paare eingefügt, Sei-tengröÿe: 1024Byte

12 111 0 67,5 64,07 -

665 (e�ektiv) wieder gelöscht: 6 38 0 47,33 62,55 -3.000 zufällige Paare eingefügt, Sei-tengröÿe: 1024Byte

29 260 0 65,9 67,13 -

1.995 (e�ektiv) wieder gelöscht: 11 96 0 64 63,88 -100.000 fortlaufende Werte für glei-chen Schlüssel eingefügt, Seitengrö-ÿe: 1024B.

0 1 395 - 100 99,83

66.777 (e�ektiv) wieder gelöscht: 0 1 131 - 100 99,53250.000 zufällige Paare eingefügt (e�ek-tiv 249.608), Seitengröÿe: 2048Byte

429 8392 162 68,2 68,39 87,8

98.967 (e�ektiv) wieder gelöscht: 338 5601 106 58,3 64,38 60,34500.000 zufällige Paare eingefügt (e�ek-tiv 499.212), Seitengröÿe: 2048Byte

820 15971 376 67,93 68,58 90,13

197.748 (e�ektiv) wieder gelöscht: 651 10850 216 58,62 63,43 84,1Tabelle 6.2: Zusammenfassung Tests auf dem Baum. Schlüssel: zufällig generierte

Zeichenkette zufälliger Länge, Wert: Ganzzahl.

86

6.2 Analyse & Test

Die Tabellen 6.1 und 6.2 zeigen eine Zusammenfassung der Tests auf dem Baum.Folgende Abkürzungen wurden verwendet: IS = Interne Seiten, BS = Blatt(knoten)-Seiten, ÜS = Überlaufseiten.

6.2.3 Gröÿe Element-Index

Nach erfolgreichem Test des Baumes und der Integration des Element-Indexes inden ASTP konnten endlich echte XML-Dokumente (mit Umweg über den ASTP)in den Index �eingefügt� werden.

Erste Test mittels von xmlgen.Linux generierten XML-Dokumenten und den Wer-ken von Shakespeare in XML[Bos99] ergaben eine Gröÿe des Element-Indexes von12,8 bis 30% gegenüber dem Orignaldokument, siehe Information des Dateisystems:

(Bytes)116095 Jan 14 16:50 0.001.xml35840 Mar 17 15:10 0.001.xml.Index.ElementIndex

211612 Jan 14 16:50 0.002.xml53248 Mar 17 17:25 0.002.xml.Index.ElementIndex

1161615 Jan 14 16:48 0.01.xml191488 Mar 17 16:19 0.01.xml.Index.ElementIndex

288735 Jul 15 1999 hamlet.xml61440 Mar 29 11:04 hamlet.xml.Index.ElementIndex

257474 Jul 15 1999 othello.xml58368 Mar 29 10:50 othello.xml.Index.ElementIndex

Dies sind gute Werte, wenn auch die Tests noch nicht sehr umfangreich waren.Die Speicherauslastung könnte bei Indexen mit Zeichenkettenschlüssel sogar nochweiter optimiert werden, in dem man den Baum z.B. zum simple-pre�x-B-Baum(siehe [BU]) weiterentwickelt oder eine Prä�x-/Su�x-Komprimierung anwendet.

Die Abschätzung aller Indexe ergibt eine ungefähre Gröÿe von 60..75% des Ori-ginaldokumentes:

Element-∼ 22%Attribut-∼ (Annahme: Anzahl Attribute � Anzahl Elemente) 4%PI-target-∼ 1%Namensraum-∼ (vage Schätzung) 1..5%Entity-, CData-Section-∼ (vage Schätzung) 1..5%

Wort-Indexe für Inhalt, Kommentare, Verarbeitungsanweisungenund Attribute (Statistik, s.a. Abschnitt 4.2.1.1)

30..40%

87

6 Realisierung

section

title

para

section

titlepara

section

title...

titleauthor

published

para

section

title

section

subsection

para

title

subtitle

book

...

...

figure

section

......

...

...

...

Abbildung 6.2: Struktur-Skizze des XML-Test-Dokumentes

6.2.4 Analyse Pfad-Index

Bei Erstellung der Testdokumente und Sichtung der ersten Ergebnisse �el auf, daÿder Inklusionstest allein anhand der TextSurrogate nicht in allen Fällen lösbar ist.Der Grund dafür ist, daÿ im ASTP direkt ineinander geschachtelte Elemente aufdieselben TextSurrogate abgebildet werden. Ein Beispiel: Die TextSurrogate für<a><b><c></c></b></a> lauten jeweils: (0,0). Somit ist allein an den TextSurroga-ten nicht erkennbar, welches Element Nachfahre von wem ist.Für eine exakte Entscheidung ist ein Rückgri� auf den ASTP notwendig. Für

das (mögliche) innere Element ist zu testen, ob es einen entsprechenden Vorfahrenbesitzt. Da ein Test von einem bestimmten Element hin zur Dokument-Wurzelverläuft, ist die Anzahl der Schritte durch die maximale Länge eines Pfades imASTP begrenzt. Somit stellt die Behandlung � des in der Praxis sicher seltenen �Sonderfalles kein Problem dar.

6.2.5 Test Pfad-Index

Für den Funktionstest des Pfad-Indexes wurde das Beispiel-Dokument (siehe Abb.2.2, 2.3, S. 17�) erweitert. Eine Skizze ist in Abbildung 6.2 zu sehen, das vollständi-ge Dokument in Anhang A.2. Je ein mittels xmlgen.Linux[Sch02] zufällig generiertesXML-Dokument von 1MByte und 5MByte Gröÿe diente als Grundlage für die letz-ten zwei Testfälle. Jeweils ein Test auf �Suche alle A, welche I enthalten� sowie�Suche alle I mit �einem Vorfahren� A� wurde für folgende Elemente A, I durch-geführt (Die konkrete Testanfrage in XPath-Syntax wird jeweils abschlieÿend inSchreibmaschinenschrift angegeben):

1. I ist Nachfahre von A//book//section, //book[ //section ]

2. I ist (direkt) Kind von A//book/author, //book[ /author ]

88

6.2 Analyse & Test

3. I ist einziges Kind von A ohne weitere Einschlüsse, → d.h. beide habendie gleichen TextSurrogate im ASTP . Hierbei ist eine Extra-Behandlung desSonderfalles (s.o.) notwendig.//subsection/para, //subsection[ /para ]

4. Inverser Test zu 3., d.h. trotz gleicher Surrogate muÿ der Index erkennen, daÿI nicht in A enthalten ist.//para/subsection, //para[ /subsection ]

5. I und A haben die gleichen TextSurrogate, auf dem Pfad zwischen beiden exi-stieren jedoch andere Elemente (mit denselben TextSurrogaten). Dieserfordert mehrere Zugri�e auf den AST.//section//subtitle, //section[ //subtitle ]

6. Inverser Test zu 5., d.h. trotz gleicher Surrogate muÿ der Index erkennen, daÿI nicht in A enthalten ist.//subtitle//section, //subtitle[ //section ]

7. Ein Nachfahre von A ist über sehr viele �Generationsstufen� hinweg zu erken-nen.//Regions//Text, //Regions[ //Text ]

8. Nachfahren von mehreren A's sind in einem sehr groÿen Dokument zu �nden.//listitem//Text, //listitem[ //Text ]

Alle bis auf zwei Teil-Anfragen wurden vom Pfad-Index korrekt beantwortet. Beiden zwei Fehl-Antworten konnte nach eingehender Untersuchung festgestellt werden,daÿ sie durch ein im ASTP gespeichertes falsches TextSurrogat verursacht wurden.

89

6 Realisierung

90

7 Resüme / Ausblick

Fazit

Ziel war die Ausarbeitung von Art und Umfang optimaler XML-Indexe (im all-gemeinen) und deren Implementierung für AST/TAP � einer neuartigen, vielver-sprechenden Datenstruktur zur nativen Speicherung von XML-Dokumenten � imbesonderen.Für ein besseres Verständnis wurden zunächst einige Grundlagen � wie XML als

Vertreter der semi-strukturierten Daten, das XEE-Projekt mit seiner AST/TAP -Datenstruktur u.a. � vorgestellt. Daten-Retrieval (DR) und Informations-Retrieval(IR) wurden als ein�uÿreiche Themengebiete identi�ziert. Arbeiten beider Richtun-gen nennen heute Anfragen auf Struktur und Anfragen auf Inhalt als die beidenwichtigen Bereiche in Bezug auf semi-strukturierten Daten, jedoch aus unterschied-lichen Sichtweisen. Um Klarheit zu scha�en, wurden DR und IR mit Struktur- undInhaltsanfragen zueinander ins Verhältnis gesetzt und klassische Retrieval-Bereicheeingeordnet. Die gleichwertige Unterstützung von Inhalts- und Struktur-Anfragenwurde als eines der Hauptziele herausgearbeitet. Viele Modelle/Systeme behauptendies von sich, jedoch überwiegt i.d.R. der eine oder andere Bereich.Nach der Klassi�zierung galt es, die elementaren Anfragetypen der einzelnen Be-

reiche zu identi�zieren, welche durch Indexe unterstützt werden sollen. Hierzu er-folgte eine tiefgehende Analyse der Herangehensweise relevanter Modelle und Ar-beiten auf diesem Gebiet, spezieller Anforderungen des AST/TAP -Modells, eigenerIdeen und Vorschläge sowie Forderungen von Gremien wie dem W3C. Dabei wurdenauch einige Anforderungen entdeckt, die fast ausschlieÿlich in relevanten Arbeitenvernachlässigt werden. Die Ergebnisse faÿt Abschnitt 3.6 in einer Übersicht überelementare Anfragetypen zusammen.Nach Betrachtung der wichtigsten klassischen und relevanten Index-Verfahren

und ihrer Eignung für die zu entwerfenden Indexe wurde die Machbarkeit und Not-wendigkeit einzelner Indexe für die jeweiligen einzelnen Anforderungen abgeschätzt.Für die Inhalts-basierten Anfragen wird ein Wort-Index als geeignet angesehen,

wie er in IR-Systemen gebräuchlich ist. Die Suche nach Wörtern, Phrasen, Anzahlvon Vorkommen, Nähe, Reihenfolge etc. kann mit diesem einfachen Index e�ektivunterstützt werden. Eine Text-Normalisierung (zur Suchzeit angewandt) bietet wei-tere Funktionalität. Da diese auf die jeweilige Anwendung abgestimmt werden muÿ,ist sie frei de�nierbar zu gestalten.Ein Teil der Struktur-Anfragen kann � wie erwartet � schon e�zient durch den

ASTP unterstützt werden. Für alle weiteren Anfragen wurden Indexe entworfenbzw. die mögliche N(achn)utzung anderer, hier schon vorgestellter Indexe erläutert.

91

7 Resüme / Ausblick

Zwei Indexe wurden im Detail inklusive Kostenbetrachtung und Vorstellung vonOptimierungsmöglichkeiten diskutiert: Der Element(-Namen)-Index als Beispiel fürviele andere Indexe nach gleichem Schema und der Inklusions-Index als kritischerIndex mit interessanter Lösung.Die Indexe besitzen � zusammen mit dem ASTP und TAP � alle eine gemein-

same Adressierungsbasis: die TextSurrogate. Somit ist eine e�ektive Kopplung allerKomponenten gegeben. Neben Vollständigkeit wurde auf Skalierbarkeit und die ef-�ziente Unterstützung von Veränderungsoperationen von Anfang an Wert gelegt.Dafür sprechen die Struktur, die begrenzte Anzahl und die relativ geringe Gröÿeder Indexe.Für den AST/TAP wurden der Pfad-Index und der Element-Index � exempla-

risch für die anderen Indexe � implementiert und in das XEE-Projekt integriert.Die durchgeführten Tests belegen die korrekte Funktion der Indexe, eine gute Spei-cherauslastung und versprechen geringen Speicherbedarf. Als zugrundeliegende Da-tenstruktur wurde ein erweiterter B+-Baum komplett als Template implementiert.Somit ist eine sehr einfache Nachnutzung und Implementierung beliebiger weitererIndexe möglich.

Ausblick

Unmittelbar nächstes Ziel ist die Instanzierung der restlichen Indexe nach demSchema des Element-Indexes.Die E�zienz von Indexen ist sehr stark abhängig von dem, was konkret angefragt

wird. Zukünftige, ausführliche Statistiken scha�en so die Grundlage für � sicherlichviele � Verbesserungen. Eine erste Idee zur Optimierung ist die Fortentwicklung desMulValTree zu einer Variante des simple-Pre�x-B-Baumes[BU]. Dieser versprichteine bessere Speicherplatzausnutzung und behebt die noch notwendige Längen-Beschränkung für Zeichenketten-Schlüssel. Auch ein noch schnelleres Mapping derNode-ID → Surrogate (durch den ASTP) wäre wünschenswert.Die bisherige Arbeit gründet sich hauptsächlich auf theoretische Betrachtungen,

Erfahrungen anderer Projekte und �Labor-Tests�. Gespannt blicken wir auf den Tag,an dem XEE � mit seinen neuen Indexen � sich in der Praxis beweisen wird.

92

A Beispiel-Dokumente

A.1 DTD für das XML-Dokument aus Abb. 2.2

<?xml version="1.0" encoding="UTF-8"?><!ELEMENT book (author, title, section+)><!ELEMENT section (title, paragraph+, section*, figure*)><!ELEMENT author (#PCDATA)><!ELEMENT figure EMPTY><!ATTLIST figureid ID #REQUIREDsource CDATA #REQUIRED

><!ELEMENT paragraph (#PCDATA | Ref)*><!ELEMENT published EMPTY><!ATTLIST publishedyear CDATA #REQUIRED

><!ELEMENT title (#PCDATA | published)*><!ELEMENT Ref (#PCDATA)><!ATTLIST RefReference IDREF #REQUIRED

>

A.2 XML-Dokument für den Test des Pfad-Indexes(in Abschnitt 6.2.5)

<book><author>Karsten Luecke</author><title>

<published year="2003"/> Indexe fuer ein XML-Repository</title><section>

<title>Motivation</title><paragraph>Fuer die effiziente Verwaltung groÿer Sammlungen von

XML-Dokumenten werden effiziente Indexe benoetigt...</paragraph></section><section>

93

<subsection><subsubsection><paragraph>

<title><subtitle>in progress...</subtitle>

</title></paragraph>

</subsubsection></subsection>

</section><?psprinter pagebreak?><section>

<title>Grundlagen</title><paragraph>Ein paar Grundlagen ... </paragraph><section>

<title>XML</title><paragraph>XML ist ...</paragraph><section><title>Markup und logische Struktur</title><paragraph> ... <Ref Reference="struktur">Abbildung 1</Ref>

zeigt die logische Struktur eines XML-Dokumentes.</paragraph><figure id="struktur" source="xmldoc_struc.png"/>

</section><section>

<title>Physikal. Struktur</title><paragraph>Physikalisch gesehen bestehen ... </paragraph>

</section></section>

</section><section><title>Anforderungen</title><paragraph>Indexe unterstuetzen den effizienten...</paragraph><section>

<title>Anfragen: Inhalt</title><paragraph>Der folgende Abschnitt</paragraph><section>

<title>Suche nach Zeichenfolgen</title><paragraph>Das einfachste Modell... </paragraph>

</section><section>

<title>Suche nach Woertern</title><paragraph>Die wohl verbreiteste Art...</paragraph>

</section><section>

<title>Suche nach Phrasen</title><paragraph>Den Autoren von PAT...</paragraph>

</section>

94

A.2 XML-Dokument für den Test des Pfad-Indexes (in Abschnitt 6.2.5)

<section><title>Erweiterungen</title><paragraph>- ...</paragraph>

</section></section><section>

<title>Anfragen: Struktur</title><paragraph>Der folgende Abschnitt</paragraph><section><title>Suche nach Elementen</title>

</section><section><title>Suche nach Attributen</title>

</section><section><title>Pfad - Anfragen</title>

</section><section><title>Anfragen: Reihenfolge/Position</title>

</section><section><title>Anfragen: bezueglich Namespaces</title>


<title>Anfragen: Inhalt und Struktur</title><paragraph>Einen typischen Anfragetyp...</paragraph><section><title>Textsuche in Unterstrukturen</title>

</section><section><title>Wertebasierte Anfragen</title>

</section></section><section><title>Weitere Funktionalitaet</title><paragraph>Texttexttext...</paragraph>

</section><section><title>Besondere Anforderungen des AST/TA</title><paragraph>Texttexttext...</paragraph><section><title>Namespace-Index</title>

</section><section><title>Entity-Index</title>

</section><section><title>CData Section Index</title>

95



<title>Uebersicht Anforderungen</title><paragraph>Texttexttext...</paragraph><table/>


<title>Zugriffsmethoden</title><paragraph>Texttexttext...</paragraph>

</section></book>

96

Literaturverzeichnis

[BAK99] Böhm, Klemens ; Aberer, Karl ; Klas, Wolfgang: Building a HybridDatabase Application for Structured Documents. In: Multimedia Toolsand Applications, 1999, S. 65�90

[Bec98] Becker, Dr. P.: Information Retrieval: Datenstrukturen und al-gorithmische Grundlagen. www. 1998. � Vorlesungsskript,http://sunwww.informatik.uni-tuebingen.de/ becker/ir/

[BM72] Bayer, R. ; McCreight, C.: Organisation and Maintenance of LargeOrdered Indexes. In: Acta Informatica 1 (1972), Nr. 3, S. 173�179

[Böh95] Böhm, Klemens: Building a con�gurable Database Application forStructured Documents / GMD. 1995 ( 942). � Forschungsbericht

[Bos99] Bosak, Jon: The Plays of Shakespeare in XML. www. 1999. �http://www.oasis-open.org/cover/bosakShakespeare200.html

[Bos00] Bos, Bert: XML in 10 Points. www. 2000. � www.w3.org/XML

[BU] Bayer, Rudolf ; Unterauer, Karl. Pre�x B-trees

[BY] Baeza-Yates, Ricardo. An Extended Model for Full Text Databases

[BY92] Baeza-Yates, R. A.: Text retrieval: theory and practice. In: vanLeeuwen, J. (Hrsg.): Proceedings of the 12th IFIP World ComputerCongress. Madrid, Spain : North-Holland, 1992, S. 465�476

[BYN99] Baeza-Yates, R. ; Neto, Ribeiro: Modern Information Retrieval.Addison Wesley, 1999

[CA98] Chen, Yangjun ; Aberer, Karl: Layered Index Structures in Docu-ment Database Systems. In: Proceedings of the ACM CIKM Interna-tional Conference on Information and Knowledge Management, ACM,November 3-7 1998. � ISBN 1�58113�061�9, S. 406�413

[CCCX00] Chow, Jyh-Herng ; Cheng, Josephine ; Chang, Daniel ; Xu, Jane.Index Design for Structured Documents Based on Abstraction. 2000

[CFMR01] Chamberlin, Don ; Fankhauser, Peter ; Marchiori, Massimo ;Robie, Jonathan. XML Query Use Cases. June 2001

[CGM90] Clifton, Chris ; Garcia-Molina, Hector: Indexing in a hypertextdatabase. In: 16th VLDB Conference, 1990, S. 36�49

97


[Com79] Comer, Douglas: The Ubiquitous B-tree. In: Computing Surveys 11(1979), Juni, Nr. 2, S. 121�137

[DSDA] Dao, Tuong ; Sacks-Davis, Ron ; A.Thom, Janes. An IndexingScheme for Structered Documents and its Implementation

[Fal88] Faloutsos, C.: Gray-codes for partial match and range queries. In:IEEE Transactions on Software Engineering Bd. 14(10), 1988, S. 1381�1393

[Fer99] Ferber, Reginald: Data Mining und Information Retrieval. www.1999. � Vorlesungsskript, http://www.darmstadt.gmd.de/ ferber/dm-ir/vlcp/book_1.html

[FM96] Fourel, Franck ;Mulhem, Philippe. Modelling Multimedia StructeredDocuments: A Retrieval Oriented Appreach. April 4 1996

[FR01] Flavio Rizzolo, Alberto M. Indexing XML Data with ToXin. 2001

[Fuh97] Fuhr, Norbert: Information Retrieval, VL-Skript. Skript. 1997. �Skriptum Uni Trier

[Ges] Gesellschaft für Informatik (GI), Fachgruppe 2.5.4 bzw.

4.9.3, Information Retrieval: Ziele und Aufgaben der Fachgrup-pe �Information Retrieval�. www. � http://ls6-www.informatik.uni-dortmund.de/ir/fgir/mitgliedschaft/brochure2.html

[GG98] Gaede, Volker ; Günther, Oliver: Multidimensional access methods.In: ACM Computing Surveys 30 (1998), Nr. 2, S. 170�231

[GQ99] Grahan, Ian S. ; Quin, Liam: XML-Speci�cation Guide. Wiley Com-puter Publishing, 1999

[GW97] Goldman, R. ; Widom, J.: DataGuides: Enabling Query Formulati-on and Optimization in Semistructured Databases. In: Twenty-ThirdInternational Conference on Very Large Data Bases, 1997, S. 436�445

[HP] Heuer, Andreas ; Priebe, Denny. IRQL - Yet Another Language forQuerying Semi-Structered Data ? Paper

[HR01] Härder, Theo ; Rahm, Erhard: Datenbanksysteme - Konzepte undTechniken der Implementierung. 2. Springer-Verlag, 2001

[HS95] Heuer, Andreas ; Saake, Gunter: Datenbanken: Konzepte und Spra-chen. Bd. 1. Thomson Publishing, 1995

[HS99] Heuer, Andreas ; Saake, Gunter: Datenbanken: Implementierungs-techniken. Bd. 1. MITP-Verlag, 1999

[Jag90] Jagadish, H. V.: Linear Clustering of Objects with Multiple Atributes.In: Proceedings of the 1990 ACM SIGMOD International Conference onManagement of Data, ACM Press, May 23-25 1990, S. 332�342

[Knu73] Knuth, Donald E.: The Art of Computer Programming. Bd. 3: Sortingand Searching . . Addison-Wesley, 1973

98


[KR98] Kickinger, Günter ; Rosenauer, Andrea: Intelligent In-formation Retriaval. www. 1998. � Seminarvortrag,http://www.ifs.univie.ac.at/ gq/IIRW3.html

[KYU01] Kha, Dao D. ; Yoshikawa, Masatoshi ; Uemura, Shunsuke: An XMLIndexing Structure with Relative Region Coordinate. In: ICDE, 2001,S. 313�320

[Lü01] Lücke, Karsten: XML-Anfragesprachen. 01. Januar 2001. � Studien-arbeit an der Humboldt-Universität zu Berlin, Institut für Informatik

[LYYB77] Lee, Yong K. ; Yoo, Seong-Joon ; Yoon, Kyoungro ; Berra, P. B.:Index Structures for Structered Documents. In: ACM Transactions onDatabase Systems (TODS) Bd. 2, n.1, 1977, S. 11�26

[M+] Meier, Wolfgang M. et al.: eXist: Open Source XML Database. www.� http://exist-db.org/

[MAG+97] McHugh, J. ; Abiteboul, S. ; Goldman, R. ; Quass, D. ; Widom,J.: Lore: A database management system for semistructured data.In: SIGMOD Record (ACM Special Interest Group on Management ofData), 1997, S. 26(3):54�66

[Mar00] Marklein, Max: Speicherungstrukturen (im ProSeminar:Grundlagen von Informationssystemen). www. Nov. 2000.� http://www.informatik.uni-bonn.de/ tb/Lehre/ws00/psIS�/Folien/Marklein_f.ppt

[MS99] Meuss, Holger ; Strohmaier, Christian. Improving Index Structuresfor Structured Document Retrieval. 1999

[MWA+98] McHugh, J. ; Widom, J. ; Abiteboul, S. ; Luo, Q. ; Rajamaran,A. Indexing semistructured data. 1998

[NBY97] Navarro, Gonzalo ; Baeza-Yates, Ricardo A.: Proximal Nodes: AModel to Query Document Databases by Content and Structure. In:Information Systems 15 (1997), Nr. 4, S. 400�435

[OM84] Orenstein, Jack A. ; Merrett, T. H.: A Class of Data Structuresfor Associative Searching. In: Proceedings of the Third ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, April 2-4,1984, Waterloo, Ontario, Canada, ACM, 1984. � ISBN 0�89791�128�8,S. 181�190

[Rij79] van Rijsbergen, C. J.: Information Retrieval. But-terworths, London, 1979. � Also available on-line athttp://www.dcs.gla.ac.uk/Keith/Preface.html

[S+] Scheffner, Dieter et al.: Project Overview: XML Query Exe-cution Engine (XEE). www. � http://www.dbis.informatik.hu-berlin.de/research/XML/xee.html

[SC] Scheffner, Dieter ; Conrad, Rainer: Access Support Tree &TextArray: A Model for Physical Storage of XML Documents. �http://www.tu-chemnitz.de/informatik/webdb/016.pdf

99


[Sch] Schöning, Dr. H. Tamino � a DBMS designed for XML

[Sch01] Scheffner, Dieter: Access Support Tree & TextArray: Data Struc-tures for XML Document Storage / Humboldt-Universität zu Berlin.2001. � HUB-IB-157

[Sch02] Schmidt, Albrecht. An XML Benchmark Project: xmlgen. www. 2002

[SJJ] Shin, Dongwook ; Jang, Hyuncheol ; Jin, Honglan: BUS: An E�ectiveIndexing and Retrieval Scheme in Structered Documents.

[SM87] Salton, Gerard ; McGill, Michael J. Information Retrieval - Grund-legendes für Informationswissenschaftler. 1987

[ST94] Salminen, A. ; Tompa, F.: Pat expressions: an algebra for text search.In: Acta Linguista Hungarica41, 1994. � http://db.uwaterloo.ca/ fw-tompa/publications.html, S. 277�306

[SYU99] Shimura, Takeyuki ; Yoshikawa, Masatoshi ; Uemura, Shunsuke:Storage and Retrieval of XML Documents Using Object-RelationalDatabases. In: Database and Expert Systems Applications, 1999, S.206�217

[Tom97] Tompa, Frank W. Views of Text. 1997

[Ver01] Verity, Inc. Verity r© K2 Architecture. 2001

[W3C] W3C: XML. www. � www.w3.org/XML

[W3C00] W3C ; Fankhauser, Peter (Hrsg.) ; Marchiori, Massimo (Hrsg.) ;Robie, Jonathan (Hrsg.): XML Query Requirements. WWW. 01 2000.� http://www.w3.org/TR/xmlquery-req

[W3C01] W3C: XML Information Set. 24. Oktober 2001. � W3C Recommen-dation, http://www.w3.org/TR/xml-infoset/

[YYU99a] Yamamoto, Yohei ; Yoshikawa, Masatoshi ; Umeura, Shunsuke: OnIndices for XML Documents with Namespaces. In:Markup Technologies'99, 1999, S. 127 � 135

[YYU99b] Yamamoto, Yohei ; Yoshikawa, Masatoshi ; Umeura, Shunsuke: OnIndices Suitable for XML Documents with Namespaces. In: The SecondWorkshop on Internet Technology (WIT'99), 1999, S. 107 � 114

[ZMSD] Zobel, Justin ; Moffat, Alistair ; Sacks-Davis, Ron. An E�cientIndexing Technique for Full-Text Database Systems

100

Eidesstattliche Erlärung

Hiermit versichere ich, daÿ ich die vorliegende Diplomarbeit selbständig und nurunter Verwendung der angegebenen Quellen verfaÿt habe.Die Arbeit wurde bisher in gleicher oder ähnlicher Weise keiner anderen Prüfungs-behörde vorgelegt.

.........................................Berlin, den 31.März 2003

Verö�entlichungsklausel

Hiermit erkläre ich mein Einverständnis zur ö�entlichen Auslegung meiner Diplom-arbeit in der Bibliothek der Humboldt-Universität zu Berlin.

.........................................Berlin, den 31.März 2003

Humboldt-Universität zu Berlin · Letztlich sind konkrete Indexe für den AST/TA P1 zu...

Documents

Transcript of Humboldt-Universität zu Berlin · Letztlich sind konkrete Indexe für den AST/TA P1 zu...