Plangenerierung zur Anfrageauswertung in nativen XML-Datenbankverwaltungssystemen

Technische Universität Kaiserslautern Fachbereich Informatik AG Datenbanken und Informationssysteme Prof. Dr.-Ing. Dr. h. c. Theo Härder Plangenerierung zur Anfrageauswertung in nativen XML-Datenbankverwaltungssystemen Diplomarbeit im Studiengang Angewandte Informatik vorgelegt von Andreas Matthias Weiner Betreuer: Prof. Dr.-Ing. Dr. h. c. Theo Härder Dipl.-Inf. Christian Mathis Tag der Ausgabe: 30. Januar 2007 Tag der Abgabe: 29. Juli 2007

Ich versichere hiermit, dass ich die vorliegende Diplomarbeit mit dem Thema Plangenerierung zur Anfrageauswertung in nativen XML-Datenbankverwaltungssystemen selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen wurden, habe ich durch die Angabe der Quelle, auch der benutzten Sekundärliteratur, als Entlehnung kenntlich gemacht. Kaiserslautern, den 22. Juli 2007 Andreas Matthias Weiner

Danksagung An dieser Stelle möchte ich mich bei allen Menschen ganz herzlich bedanken, die ihren Beitrag zum Gelingen dieser Diplomarbeit geleistet haben. Mein besonderer Dank gebührt Herrn Prof. Dr.-Ing. Dr. h. c. Theo Härder für die Bereitstellung der Räumlichkeiten und der geeigneten Infrastruktur sowie für die Begutachtung dieser Arbeit. Ferner danke ich ganz herzlich Herrn Dipl-Inf. Christian Mathis für die Übernahme des Zweitgutachtens und für die hervorragende Betreuung dieser Arbeit. Ein ganz besonderes Dankeschön gilt meinen Eltern, die mir dieses Studium ermöglicht haben sowie meiner Familie, die mir jederzeit eine moralische Stütze war. Schließlich bedanke ich mich ganz herzlich bei meinem Kommilitonen Herrn Sebastian Bächle für die vielen fachlichen Ratschläge und Diskussionen sowie für die Freundschaft, die sich während des Studiums entwickelt hat.

Inhaltsverzeichnis Abbildungsverzeichnis v 1 Einleitung 1 1.1 Motivation........................................ 1 1.2 Zielsetzung der Arbeit.................................. 2 1.3 Die Test-Umgebung................................... 2 1.4 Gliederung der Arbeit.................................. 4 2 Anfrageverarbeitung in Datenbanksystemen 5 2.1 Grundlagen der Anfrageverarbeitung.......................... 5 2.2 Die drei Phasen der Anfrageverarbeitung....................... 7 2.2.1 Anfrageanalyse.................................. 7 2.2.2 Anfrageoptimierung............................... 8 2.2.3 Anfrageausführung................................ 10 2.3 Verfahren zur Plangenerierung............................. 10 2.3.1 Dynamische Programmierung.......................... 11 2.3.2 Probabilistische Verfahren zur Plangenerierung................ 11 2.4 Zusammenfassung.................................... 14 3 Grundlagen der XML-Anfragesprache XQuery 15 3.1 XML-Grundlagen..................................... 15 3.1.1 Der Aufbau eines XML-Dokuments....................... 15 3.1.2 Wohlgeformte und gültige XML-Dokumente.................. 17 3.1.3 Document Type Definition (DTD) und XML Schema............ 17 3.2 Die Anfragesprache XQuery............................... 19 3.2.1 Das XQuery/XPath-Datenmodell........................ 19 3.2.2 Auswertungskontext............................... 21 3.2.3 Pfadausdrücke in XQuery/XPath........................ 21 3.2.4 FLWOR-Ausdrücke in XQuery......................... 26 3.2.5 Anwendungsfälle für XQuery.......................... 31 3.3 Zusammenfassung.................................... 31 4 Grundlagen der logischen XML-Algebra NAL STJ 33 4.1 Einführung in die Natix-Algebra (NAL)........................ 33 4.1.1 Grundlagen der Natix-Algebra......................... 33 4.1.2 Die Operatoren der Natix-Algebra....................... 34 4.1.3 Abbildung von XPath-Ausdrücken auf Operatoren der Natix-Algebra... 35 4.2 Die logische Algebra NAL STJ.............................. 38 4.2.1 Die Operatoren von NAL STJ.......................... 38 i

ii Inhaltsverzeichnis 4.2.2 Einführung des logischen strukturellen Verbundes in die Natix-Algebra... 40 4.2.3 Entschachtelung von Algebra-Ausdrücken................... 41 4.2.4 Regeln zur Anfragerestrukturierung...................... 43 4.3 Zusammenfassung.................................... 44 5 Pfadverarbeitungsoperatoren und Indexstrukturen 45 5.1 Pfadverarbeitungsoperatoren.............................. 45 5.1.1 Structural-Join-Algorithmen........................... 46 5.1.2 Holistic-Twig-Join-Algorithmen......................... 48 5.2 Indexstrukturen...................................... 50 5.2.1 Pfad-Indexstrukturen.............................. 50 5.2.2 Element-Indexstrukturen............................ 51 5.2.3 Text/Attribut-Indexstrukturen......................... 52 5.2.4 Hybrid-Indexstrukturen............................. 52 5.3 Zusammenfassung.................................... 53 6 Entwurf eines XML-Anfragegraphmodells 55 6.1 Das XAGM-Darstellungsschema............................. 55 6.1.1 Der Tupel-ADT des XML-Anfragegraphmodells................ 56 6.1.2 Beispiele für Anfragegraphen im XML-Anfragegraphmodell......... 58 6.1.3 Abbildung von NAL STJ -Ausdrücken auf Operatoren des XAGM...... 60 6.2 Regeln zur Anfragerestrukturierung........................... 67 6.2.1 Fusion von Join-Operatoren........................... 68 6.2.2 Fusion von Join- und Outer-Join-Operatoren................. 69 6.2.3 Fusion von Select-Operatoren.......................... 71 6.2.4 Fusion von Join- und Select-Operatoren.................... 72 6.2.5 Select-Node-Access-Fusion............................ 74 6.2.6 Verschiebung von Prädikaten und Projektionen................ 75 6.2.7 Verschiebung von Join-Operatoren....................... 77 6.3 Regeln zur Anfragetransformation........................... 79 6.3.1 Kommutativität der Join-Operatoren...................... 79 6.3.2 Assoziativität der Join-Operatoren....................... 80 6.3.3 Auflösen eines komplexen Join-Operators................... 82 6.4 Anfrageausführungspläne im XML-Anfragegraphmodell............... 87 6.4.1 Der Aufbau des Anfrageausführungsplans................... 87 6.4.2 Abbildung der XAGM-Tupeloperatoren auf entsprechende Planoperatoren. 89 6.5 Beispiele.......................................... 95 6.5.1 Beispielhafte Optimierung einer XPath-Anfrage................ 95 6.5.2 Beispielhafte Optimierung einer XQuery-Anfrage............... 96 6.6 Zusammenfassung.................................... 100 7 Entwurf einer Komponente zur Anfrageauswertung 103 7.1 Die Architektur der Anfrageauswertungskomponente................. 103 7.1.1 Die Rewriter-Komponente............................ 104 7.1.2 Die Aufgaben des Plangenerators........................ 107 7.2 Entwurf und Implementierung des Mustererkenners.................. 108 7.2.1 Die Architektur des Mustererkenners...................... 108 7.2.2 Der Ablauf des Mustererkennungsprozesses.................. 109 7.2.3 Implementierung eines Musters......................... 113 7.3 Zusammenfassung.................................... 114

Inhaltsverzeichnis iii 8 Zusammenfassung und Ausblick 117 A Restrukturierungsregeln 119 B Assoziativitätsregeln für binäre Join-Operatoren 125 B.1 Nur descendant-achsen................................. 126 B.2 Nur child-achsen..................................... 129 B.3 Eine descendant-achse und eine child-achse...................... 132 B.4 Eine child-achse und eine descendant-achse...................... 135 Literaturverzeichnis 139

iv Inhaltsverzeichnis

Abbildungsverzeichnis 1.1 Die Architektur des XML Transaction Coordinator.................. 3 2.1 Übersicht der verschiedenen Klassen von Anfragegraphen.............. 6 2.2 Die Schritte der Anfrageverarbeitung.......................... 7 2.3 Regelkreis der Anfragetransformation......................... 9 2.4 Suchstrategien für die Plangenerierung......................... 10 3.1 XML-Beispieldokument................................. 16 3.2 Die Struktur eines Vorwärtsschrittes.......................... 22 3.3 Die Struktur eines Rückwärtsschrittes......................... 22 3.4 Die wichtigsten Achsen in Pfadausdrücken im Überblick............... 23 3.5 Die Struktur eines Prädikats............................... 24 3.6 Der Aufbau eines FLWOR-Ausdrucks......................... 26 3.7 Die Struktur einer for-klausel............................. 27 3.8 Die Struktur einer let-klausel............................. 28 3.9 Die Struktur einer where-klausel............................ 29 3.10 Die Struktur der order by-klausel........................... 30 4.1 Die kanonische Übersetzung eines Pfadausdrucks................... 35 5.1 Beispiel eines Twig-Anfragemusters........................... 45 5.2 Auszeichnung eines XML-Dokuments mit der Tripel-Nummerierung........ 47 6.1 Generalisierungshierarchie der Tupeloperatoren des XAGM............. 56 6.2 Übersicht der Datenstrukturen des Tupel-ADT im XAGM.............. 57 6.3 Beispiel eines Anfragegraphen im XAGM....................... 58 6.4 XAGM-Anfragegraph mit Unteranfrage........................ 59 6.5 Abbildung von Dokument- und Knotenzugriffen.................... 61 6.6 Abbildung des strukturellen Verbundes......................... 61 6.7 Spezialisierung des Join-Operators........................... 62 6.8 Ersetzung eines Join-Tupeloperators durch einen Semi-Join-Tupeloperator..... 63 6.9 Beispiel Outer-Join-Operator.............................. 63 6.10 Korrekte Auswertung von Achsenschritten in return-klauseln........... 65 6.11 Abbildung von einfachen Selektionen.......................... 65 6.12 Abbildung von Selektionen mit Zugriff auf positionale Prädikate.......... 66 6.13 Abbildung der Gruppierung und der Aggregation................... 66 6.14 Die drei Sequenzoperatoren des XML-Anfragegraphmodells............. 67 6.15 Der Aufbau des Sort-Operators............................. 67 6.16 Verschmelzung von zwei Join-Operatoren....................... 69 v

vi Abbildungsverzeichnis 6.17 Verschmelzung eines Semi-Join-Operators und eines Left-Outer-Join-Operators.. 70 6.18 Verschmelzung eines Left-Outer-Join-Operators und eines Semi-Join-Operators.. 70 6.19 Verschmelzung von zwei Left-Outer-Join-Operatoren................. 71 6.20 Verschmelzung von zwei Select-Operatoren...................... 72 6.21 Verschmelzung eines Select- und eines Join-Operators................ 73 6.22 Verschmelzung eines Join- und eines Select-Operators................ 74 6.23 Verschmelzung eines Select- und eines Node-Access-Operators............ 75 6.24 Verschiebung eines Select-Operators.......................... 76 6.25 Verschiebung eines Join-Operators mit following-achse................ 78 6.26 Vertauschung der Verbund-Partner eines einfachen Join-Operators......... 79 6.27 Beispiel für eine Assoziativitätsregel mit dem Ausgabeknoten A........... 81 6.28 Twig-Anfragemuster................................... 84 6.29 Anfragegraph zum Twig-Anfragemuster........................ 84 6.30 Anfragegraph nach der Aufspaltung des komplexen Join-Operators......... 85 6.31 Anfragegraph nach der Einführung des Join-Operators mit strukturellem self- Prädikat.......................................... 85 6.32 Anfragegraph nach der Aufspaltung des linken Verbundpartners........... 86 6.33 Anfragegraph nach der Einführung von zwei Join-Operatoren mit strukturellem self-prädikat....................................... 87 6.34 Generalisierungshierarchie der Planoperatoren..................... 88 6.35 Beispiel eines Anfrageausführungsplans......................... 89 6.36 Abbildung von Select-Tupeloperatoren auf Select-Planoperatoren.......... 90 6.37 Verschiedene Abbildungsvarianten für einen Access-Tupeloperator......... 91 6.38 Abbildung des Group-By-Tupeloperators auf den Group-By-Planoperator..... 91 6.39 Abbildung des Sort-Tupeloperators auf den entsprechenden Planoperator..... 91 6.40 Abbildungen des Sequenz-Tupeloperators auf den Sequenz-Planoperator...... 92 6.41 Übersicht der Auswertungsmethoden für einen binären Join-Planoperator..... 92 6.42 Abbildung eines Join-Tupeloperators auf den entsprechenden Join-Planoperator.. 93 6.43 Abbildung eines Join-Tupeloperators auf einen Access-Planoperator........ 94 6.44 Auswertungsvarianten eines Join-Tupeloperators mit strukturellem self-prädikat. 94 6.45 Abbildung eines komplexen Outer-Join-Tupeloperators auf zwei Join-Planoperatoren 95 6.46 Anfragegraph vor und nach Beginn der Restrukturierungsphase........... 95 6.47 Anfrageausführungspläne in Abhängigkeit von der Verfügbarkeit eines Pfad-Indexes 96 6.48 Anfragegraph vor der Restrukturierungsphase..................... 97 6.49 Anfragegraph vor und nach der ersten Restrukturierung............... 98 6.50 Restrukturierung des Anfragegraphen......................... 99 6.51 Anfrageausführungsplan................................. 100 7.1 Architektur der Komponente zur Anfrageauswertung................. 103 7.2 Der Ablauf des Rewriting-Prozesses.......................... 104 7.3 Die Architektur des Mustererkenners.......................... 108 7.4 Beispiel-Baum mit zwei Mustern und drei Treffern.................. 109 7.5 Ablauf der Mustererkennung.............................. 110 7.6 Beispiel-Baum und Muster mit zwei Treffern..................... 112

Die Technik von heute ist das Brot von morgen die Wissenschaft von heute ist die Technik von morgen. Kapitel 1 Richard von Weizsäcker ( 1920) Einleitung 1.1 Motivation Die Extensible Markup Language (XML) hat sich seit der ersten W3C Recommendation 1 im Jahre 1998 zu einem De-facto-Standard für die Repräsentation und zum Austausch von strukturierten und semistrukturierten Daten entwickelt. Die Ursprünge dieser Sprache liegen bereits weit zurück. Einer ihrer Vorgänger die Standard Generalized Markup Language (SGML) wurde bereits in den 70er Jahren des vergangenen Jahrhunderts vorgestellt [HM02]. Heute existiert für Geschäftsobjekte nahezu jeder Branche eine standardisierte XML-Repräsentation, die den Datenaustausch zwischen und innerhalb von Unternehmen erleichtern soll. Mit der Einführung von Web Services [ACKM04] und serviceorientierten Architekturen [DJMZ05], bei denen XML-Nachrichten ausgetauscht werden, eröffnet sich ein weiterer Anwendungsbereich der Sprache XML. Viele Anwendungsbereiche benötigen effiziente Verfahren zur Bearbeitung und Verwaltung sowie zur Durchsuchung von XML-Dokumenten. Obwohl XML ursprünglich als Datenaustauschformat gedacht war, wird aus diesem Grund seit einiger Zeit nach Möglichkeiten gesucht, um XML-Dokumente effizient zu speichern und zu verwalten. Relationale Datenbankverwaltungssysteme (RDBVS) bilden seit Jahren eine zuverlässige Basis für die Speicherung und Verwaltung von großen Datenbeständen [HR01, EN04]. Da XML- Dokumente eine Baumstruktur aufweisen, ist deren Speicherung in relationalen Datenbanksystemen nicht ohne Probleme möglich. Deshalb ist gegebenenfalls die Aufteilung des Dokuments auf eine Vielzahl von Tabellen erforderlich. Diese Aufteilung erschwert die Transaktionsisolation in RDBVS in erheblichem Maße [HH07]. Ebenso schwierig gestaltet sich der direkte Zugriff mit Hilfe einer XML-Anfragesprache (vgl. ebd.). Um eine ständige und teuere Übersetzung zwischen dem Relationenmodell auf der einen Seite und der XML-Repräsentation auf der anderen Seite zu vermeiden, werden so genannte native XML- Datenbankverwaltungssysteme (XDBVS) als vielversprechende Alternative vorgeschlagen [HH07]. Diese Systeme bieten den Vorteil, dass sie XML-Dokumente derart speichern können, dass diese ihre hierarchische Struktur beibehalten. Durch die ordnungserhaltende Speicherung erwartet man, dass Anfragen mit einer XML-Anfragesprache wie zum Beispiel XQuery [W3C07c] schneller beantwortet werden können, als dies mit Hilfe eines RDBVS möglich wäre, da hier der Umweg über das Relationenmodell nicht notwendig ist. Im Gegensatz zur Anfrageverarbeitung in relationalen Datenbankverwaltungssystemen gestaltet sich die Anfrageauswertung auf XML-Dokumenten deutlich komplizierter. Die höhere Komplexität hat einerseits ihren Ursprung im XML-Datenmodell und wird andererseits durch die äußerst 1 Vgl. http://www.w3.org/tr/1998/rec-xml-19980210 1

2 Kapitel 1. Einleitung komplexe Anfragesprache XQuery bedingt. Die aktuelle Forschung auf diesem Gebiet lässt sich grob in zwei Klassen einteilen: Zum einen gibt es Forschungsvorhaben, die sich mit der Entwicklung von effizienten physischen Pfadverarbeitungsoperatoren (engl. Path Processing Operators) beschäftigen. Als prominente Vertreter dieser Ansätze lassen sich die Structural-Join-Algorithmen von Al-Khalifa et al. [AKJP + 02] und die Holistic-Twig-Join-Algorithmen von Bruno et al. [BKS02] nennen. Auf der anderen Seite existieren viele Ansätze, die sich dem Problem der Anfrageoptimierung von der logischen Seite nähern, indem logische Algebren vorgestellt werden, mit deren Hilfe eine algebraische Optimierung der Anfrage durchgeführt werden kann. Dabei lassen sich baumbasierte Algebren wie zum Beispiel TAX von Jagadish et al. [JLST01] beziehungsweise TLC von Paparizos et al. [PWLJ04] und tupelbasierte Algebren wie zum Beispiel NAL von Brantner et al. [BHKM05] unterscheiden [Mat07b]. Zwischen diesen beiden Forschungsbereichen gibt es derzeit nur sehr wenige Berührungspunkte. Für die erfolgreiche Entwicklung eines kostenbasierten Anfrageoptimierers müssen diese beiden Bereiche aber eng zusammenarbeiten. Erste Ansätze zur Zusammenführung dieser Bereiche wurden von Mathis mit NAL STJ [Mat07b] und von Michiels et al. [MMS07] vorgestellt. Bei der tupelbasierten Algebra NAL STJ wird ein physischer Structural-Join-Operator als logischer Operator in die Algebra eingeführt. Dagegen wird beim Ansatz von Michiels et al. ein physischer Operator zur Verarbeitung von Baummustern (engl. tree pattern) in die logische Algebra integriert. Mit diesen Ansätzen wurde eine Brücke zwischen der logischen und der physischen Ebene der Anfrageverarbeitung geschlagen und der Weg für eine kostenbasierte Optimierung von XQuery/XPath-Anfragen bereitet. Im nächsten Schritt muss dieser Weg weiter gefestigt werden, so dass ein durchgängiger Prozess beschrieben werden kann, beginnend beim Empfang und der Übersetzung der Anfrage, über die kostenbasierte Anfrageoptimierung reichend, bis hin zu einem fertigen Anfrageausführungsplan. 1.2 Zielsetzung der Arbeit In dieser Arbeit werden Konzepte zur Anfrageauswertung in nativen XML-Datenbankverwaltungssystemen untersucht. Das Hauptaugenmerk liegt dabei auf der Plangenerierung. Der Plangenerator bildet eine der Hauptkomponenten eines kostenbasierten Anfrageoptimierers. Dieser bewertet die ihm vorliegenden Anfragepläne anhand von statistischen Informationen und wählt den günstigsten Plan zur Ausführung aus. Dazu wird ein XML-Anfragegraphmodell (XAGM) als neue Interndarstellung einer XQuery/XPath-Anfrage vorgestellt, das die Ideen von Mathis [Mat07b] und Michiels et al. [MMS07] hinsichtlich der Einbettung von physischen Operatoren in die logische Algebra aufgreift und erweitert. Das XAGM bildet die Grundlage für die Optimierungsphase der Anfrageverarbeitung in nativen XML-Datenbankverwaltungssystemen, bei der eine Anfragerestrukturierung und -transformation durchgeführt wird. Für das XAGM sollen eine Reihe von Restrukturierungsregeln definiert werden, die eine algebraische Optimierung der Anfragen unter Berücksichtigung von Implementierungsaspekten wie zum Beispiel der Verfügbarkeit von n-wege-verbund-operatoren ermöglichen. Des Weiteren sollen Regeln zur nicht-algebraischen Optimierung von Anfragegraphen definiert werden, wie zum Beispiel zur Vertauschung der Verbundreihenfolgen. Anschließend soll eine Abbildung der logischen Operatoren des XAGM auf physische Planoperatoren beschrieben werden. 1.3 Die Test-Umgebung An der Technischen Universität Kaiserslautern wird derzeit der XML Transaction Coordinator (XTC) als Prototyp eines nativen XML-Datenbankverwaltungssystems entwickelt [Hau06, HH07].

1.3. Die Test-Umgebung 3 Abbildung 1.1: Die Architektur des XML Transaction Coordinator In Abbildung 1.1 ist die Architektur des XTC-Server dargestellt [HH07]. Der Aufbau orientiert sich am Schichtenmodell für datenunabhängige Datenbanksysteme, das von Härder und Reuter vorgeschlagen wurde [HR83a]. Die untersten beiden Schichten werden durch die so genannten File Services und die Propagation Control gebildet. Diese beiden Schichten sind für die Verwaltung des Externspeichers und der Datenbank-Puffer zuständig, dabei werden bewährte und effiziente Verfahren aus dem Bereich der relationalen Datenbanksysteme wiederverwendet [HH07]. Da für die Datenbank-Puffer eine Vielzahl an Verdrängungsstrategien zur Verfügung stehen, kann abhängig von der aktuellen Arbeitslast des Systems ein geeignetes Verfahren ausgewählt werden (vgl. ebd.). Der Transaction Manager ist für die Transaktionsverwaltung zuständig. Er ermöglicht das physiologische Logging von Datenbank-Operationen, um die Wiederherstellung eines konsistenten Systemzustandes nach einem Crash zu gestatten (vgl. ebd.). Die unteren beiden Schichten sind insgesamt für die Sicherstellung der Atomarität und der Dauerhaftigkeit des ACID-Paradigmas [HR83b] zuständig. Im Gegensatz dazu muss die Sicherstellung der Konsistenz und der Isolation auf höheren Ebenen des Schichtenmodells erfolgen. Die dritte Schicht bilden die so genannten Access Services, die für die satzorientierte Verarbeitung zuständig sind. In dieser Schicht befinden sich verschiedene Indexstrukturen wie zum Beispiel der so genannte Dokument-Index oder der Element-Index, die für den effizienten Zugriff auf ein XML-Dokument beziehungsweise auf dessen Element-Knoten zuständig sind [HH07]. In der vierten Schicht des XTC-Server werden Operationen für die knotenorientierte Verarbeitung zur Verfügung gestellt, so dass die fünf DOM-Achsen (parent, previous-sibling, followingsibling, first-child und last-child) zur Navigation verwendet werden können. Auf dieser Ebene befindet sich auch der Lock Manager, der für die Transaktionsisolation zuständig ist und bei einer

4 Kapitel 1. Einleitung nebenläufigen Verarbeitung mehrerer Transaktionen einen logischen Einbenutzerbetrieb gewährleistet (vgl. ebd. und [HR01]). Für die vorliegende Arbeit ist die fünfte Schicht des XTC-Server die so genannten XML Processing Services von großem Interesse. In dieser Schicht befindet sich die Komponente zur Auswertung von XQuery/XPath-Anfragen. Der XML-Manager stellt verschiedene Schnittstellen zum Zugriff und zur Verarbeitung von XML-Dokumenten zur Verfügung, wie zum Beispiel SAX, DOM, XPath und XQuery [HH07]. Schließlich können Anwendungsprogramme mit Hilfe der Interface Services über verschiedene Schnittstellen auf XML-Dokumente zugreifen und diese auch teilweise verändern (vgl. ebd.). 1.4 Gliederung der Arbeit Kapitel 2 stellt die Grundlagen der Anfrageverarbeitung in Datenbanksystemen vor. Die dort eingeführten Konzepte (zum Beispiel die Plangenerierung) können sowohl bei der Anfrageverarbeitung in relationalen Datenbankverwaltungssystemen als auch in nativen XML-Datenbankverwaltungssystemen eingesetzt werden. Kapitel 3 beschreibt die Grundlagen der XML-Anfragesprache XQuery. Der erste Teil stellt zunächst das XML-Datenmodell vor und führt grundlegende Begriffe ein, wie zum Beispiel die Wohlgeformtheit eines XML-Dokuments. Danach wird die XML-Anfragesprache XQuery und das zugehörige Datenmodell beschrieben. Abschließend geht Kapitel 3 auf die verschiedenen Anwendungsbereiche von XQuery ein. Kapitel 4 gibt einen Überblick über die logische Natix-Algebra (NAL) und ihre Erweiterung NAL STJ. Im ersten Teil wird beschrieben, wie sich XQuery/XPath-Ausdrücke in eine entsprechende NAL-Repräsentation übersetzen lassen. Der zweite Teil zeigt, wie ein logischer struktureller Verbund in die Natix-Algebra eingeführt werden kann und welche Konsequenzen sich dadurch für die Anfrageverarbeitung ergeben. In Kapitel 5 werden die zwei großen Klassen von physischen Pfadverarbeitungsoperatoren Structural-Join- und Holistic-Twig-Join-Operatoren sowie vier verschiedene Klassen von XML- Indexstrukturen vorgestellt. Aufbauend auf den beiden vorhergehenden Kapiteln 4 und 5 diskutiert Kapitel 6 das XML- Anfragegraphmodell (XAGM) als Vermittler zwischen der logischen und der physischen Ebene der Anfrageverarbeitung. Dazu beschreibt zunächst der erste Teil das XAGM-Datenmodell. Anschließend wird gezeigt, wie sich NAL STJ -Ausdrücke auf eine Folge von XAGM-Operatoren abbilden lassen. Nach der Definition von Regeln zur Restrukturierung von XAGM-Anfragegraphen diskutiert der letzte Teil, wie sich diese mit Hilfe einer Folge von physischen Planoperatoren auswerten lassen. Kapitel 7 skizziert den Aufbau einer Komponente zur Anfrageauswertung für die in Abschnitt 1.3 beschriebene Test-Umgebung. Ferner wird ein generischer Mustererkenner vorgestellt, mit dessen Hilfe sich die verschiedenen Transformationen effizient realisieren lassen, die während der Anfrageverarbeitung durchgeführt werden müssen. Dabei wird die Voraussetzung für die Anwendbarkeit einer Regel deklarativ durch ein Baummuster beschrieben, so dass der Entwickler lediglich die eigentliche Transformation durch geeigneten Programmcode prozedural beschreiben muss. Kapitel 8 fasst den Inhalt dieser Diplomarbeit zusammen und gibt einen Ausblick auf die zukünftige Arbeit in diesem Bereich.

Kapitel 2 Plant das Schwierige da, wo es noch leicht ist. Tut das Große da, wo es noch klein ist. Alles Schwere auf Erden beginnt stets als Leichtes. Alles Große auf Erden beginnt stets als Kleines. Laotse (6. Jhd. v. Chr) Anfrageverarbeitung in Datenbanksystemen In diesem Kapitel werden die Grundlagen der Anfrageverarbeitung in Datenbanksystemen vorgestellt. Zunächst beschreibt Abschnitt 2.1 die Konzepte, die sowohl relationale als auch native XML-Datenbanksysteme gemeinsam haben. In Abschnitt 2.2 werden die drei Phasen der Anfrageverarbeitung (Analyse, Optimierung und Codegenerierung) betrachtet. Abschließend beschreibt Abschnitt 2.3 die verschiedenen Verfahren zur Plangenerierung. 2.1 Grundlagen der Anfrageverarbeitung Die Komponente zur Anfrageverarbeitung gehört zu den wichtigsten Bestandteilen moderner Datenbanksysteme, deren Güte unmittelbaren Einfluss auf die Leistungsfähigkeit des gesamten Datenbanksystems hat [JK84, KRB85]. Betrachtet man das von Härder und Reuter vorgeschlagene Schichtenmodell für datenunabhängige Datenbanksysteme [HR83a], so lässt sich die Anfrageverarbeitung der Schicht der logischen Datenstrukturen zuordnen [HR01]. Die Komponente zur Anfrageverarbeitung sieht sich mit komplexen Anfragen im Sinne von Graefe [Gra93] konfrontiert. Darunter versteht man Anfragen, die zur Auswertung einer Vielzahl verschiedener Algorithmen bedürfen und auf sehr großen Datenbeständen ausgewertet werden müssen. Ferner bildet die Anfrageverarbeitung die Brücke zwischen den Anfragesprachen wie zum Beispiel SQL bei relationalen Datenbanksystemen und XQuery/XPath bei nativen XML- Datenbanksystemen und den Schichten unterhalb der logischen Datenstrukturen bis hin zum Dateisystem [Gra93, HR01]. Bei der Anfrageverarbeitung lassen sich grob zwei Aufgaben unterscheiden: Anfrageoptimierung (engl. query optimization) und Anfrageausführung (engl. query execution). Dabei übersetzt der Anfrageoptimierer eine Anfrage in mehreren Schritten in eine Reihe von physischen Planoperatoren, die anschließend von der Komponente zur Anfrageausführung ausgeführt werden. Das Ziel der Anfrageoptimierung ist das Auffinden eines Anfrageausführungsplans (engl. query execution plan), der die wichtigsten Leistungsmaße (zum Beispiel E/A-Aufwand oder Antwortzeit des Systems) minimiert [Gra93]. Eine vollständige Komponente zur Anfrageverarbeitung besteht aus einer Sammlung von Operatoren und Verfahren, die zur Auswertung von komplexen Anfragen herangezogen werden können. Zusammengenommen bilden diese so genannten Planoperatoren die physische Algebra des Datenbanksystems, welche äquivalent zur logischen Algebra ist. Die logische Algebra orientiert sich deutlich stärker am Datenmodell des Datenbanksystems und bestimmt, welche Anfragen damit ausgedrückt werden können. Im Gegensatz dazu ist die physische Algebra systemspezifisch; das 5

6 Kapitel 2. Anfrageverarbeitung in Datenbanksystemen bedeutet, dass verschiedene Datenbanksysteme, die sich auf das gleiche Datenmodell stützen, zwar über die gleiche logische Algebra verfügen können, sich aber unterschiedlicher physischer Algebren bedienen können. Ein weiterer wichtiger Unterschied zwischen logischen und physischen Algebren ist die Tatsache, dass Auswertungsalgorithmen nur physischen Operatoren zugeordnet sind, so dass nur für physische Operatoren Kostenfunktionen ermittelt werden können [Gra93]. Bei der Abbildung von logischen auf physische Operatoren lassen sich vier Fälle unterscheiden [Gra93]: Erstens kann ein physischer Operator mehrere logische Operatoren implementieren. Zum Beispiel könnte ein physischer Join-Operator zusätzlich Projektionen und Selektionen unterstützen. Zweitens kann ein physischer Operator nur einen Teil eines logischen Operators implementieren. So deckt ein physischer Operator zur Duplikateliminierung nur die zweite Hälfte eines logischen Projektionsoperators ab. Drittens gibt es physische Operatoren, die nicht in der logischen Algebra existieren. So ist ein Sortierungsoperator in der Relationenalgebra nicht vorhanden, da deren Operatoren auf Mengen arbeiten, auf denen per Definition keine Ordnungsrelation definiert ist. Viertens gibt es Eigenschaften von logischen Operatoren, die für physische Operatoren nur teilweise oder gar nicht gelten. Beispielsweise sind Mengenoperationen wie die Vereinigung oder der Durchschnitt aus Sicht der logischen Algebra vollständig symmetrisch und kommutativ. Aus Implementierungssicht der physischen Algebra werden beide Eingaben aber nicht zwingend gleichbehandelt [Gra93]. Das Ziel der Anfrageverarbeitung ist die Abbildung von logischen auf physische Operatoren. Die Komponente zur Anfrageausführung ist für die Ausführung der physischen Operatoren und für die Kommunikation zwischen diesen Operatoren sowie für die Koordination unter den Operatoren zuständig. Bei der Implementierung von physischen Operatoren lassen sich drei Basis-Funktionen unterscheiden, die jeder Operator zur Verfügung stellt: Zunächst initialisiert die open-funktion den Operator. Anschließend liefert der Operator mittels der next-funktion die Anfrageergebnisse zurück. Nachdem keine Ergebnisse mehr erzeugt werden können, wird der Operator mit Hilfe der close-funktion außer Dienst gestellt [Gra93]. (a) Linkstiefer Anfragegraph (b) Buschiger Anfragegraph (c) Rechtstiefer Anfragegraph Abbildung 2.1: Übersicht der verschiedenen Klassen von Anfragegraphen Da es sich bei Anfragegraphen um Algebra-Ausdrücke handelt, können diese als Bäume dargestellt werden. Dabei lassen sich drei prototypische Formen von Anfragebäumen unterscheiden, die zur Klassifizierung der Anfrageausführungskomponente benutzt werden können [GD87]. In Abbildung 2.1 sind die drei verschiedenen Varianten dargestellt [Gra93]: Linkstiefe Anfragegraphen (engl. left-deep plans) und rechtstiefe Anfragegraphen (engl. right-deep plans) unterscheiden sich grundsätzlich voneinander, da beispielsweise Join-Algorithmen die beiden Eingabeströme auf unterschiedliche Art und Weise verwenden. Zum Beispiel iteriert die äußere Schleife des Nested- Loops-Join-Algorithmus [BE76] über die Eingabe (linkes Kind) und die innere Schleife iteriert über die andere Eingabe. Die Klasse der buschigen Anfragegraphen (engl. bushy plans) umfasst sowohl links- als auch rechtstiefe Anfragegraphen. Der Anfrageoptimierer des ersten relationalen Datenbanksystems System R gestattete nur die Verarbeitung von linkstiefen Bäumen [ABC + 76, Gra93],

2.2. Die drei Phasen der Anfrageverarbeitung 7 so dass bei diesem System das Verfahren der dynamischen Programmierung [CLRS01] zur Plangenerierung eingesetzt werden konnte. Zwischen der Verwendung von linkstiefen und buschigen Anfragegraphen besteht ein Spannungsverhältnis zwischen der Einschränkung des Suchraums des Anfrageoptimierers und einer höheren Flexibilität beziehungsweise Effizienz bei einigen Anfragen [Gra93]. 2.2 Die drei Phasen der Anfrageverarbeitung Abbildung 2.2: Die Schritte der Anfrageverarbeitung Nach Mitschang werden während der Anfrageverarbeitung drei Phasen durchlaufen [Mit95]: Analyse, Optimierung und Codegenerierung. Abbildung 2.2 zeigt die einzelnen Schritte der drei Phasen im zeitlichen Verlauf [Mit95]. 2.2.1 Anfrageanalyse Während der Anfrageanalyse wird zunächst eine lexikalische und syntaktische Analyse durchgeführt. Dabei wird die Anfrage, die als Zeichenkette vorliegt, hinsichtlich der syntaktischen Korrektheit untersucht [Mit95, HR01]. Die semantische Analyse überprüft anschließend, ob alle referenzierten Objekte (zum Beispiel das XML-Dokument, gegen das die Anfrage ausgewertet werden soll) und Attribute vorhanden sind. Außerdem werden die vom Benutzer übergebenen Namen auf

8 Kapitel 2. Anfrageverarbeitung in Datenbanksystemen eine interne Namensrepräsentation abgebildet [HR01]. Der nächste Schritt der Analysephase bildet die Zugriffs- und Integritätskontrolle, in der möglichst früh die zur Anfrageauswertung benötigten Zugriffsrechte des Anwenders überprüft werden. Bei der Standardisierung werden die Selektionsprädikate einer Anfrage entweder in die disjunktive oder die konjunktive Normalform überführt [JK84]. Um die Anfrageauswertung zu beschleunigen, werden während der Vereinfachungsphase redundante Ausdrücke in Selektionsprädikaten entfernt. Außerdem können hier bereits nichterfüllbare Prädikate identifiziert werden, so dass die Anfrageauswertung sofort abgebrochen werden kann, wenn festgestellt wird, dass die Anfrage kein Ergebnis liefert [HR01]. Das Ergebnis der Analysephase ist ein Anfragegraph (engl. query graph), der als Eingabe für den Anfrageoptimierer dient [Mit95, HR01]. 2.2.2 Anfrageoptimierung Bei der Anfrageoptimierung lassen sich zwei Arten von Ansätzen unterscheiden: Top-down- und Bottom-up-Ansätze [JK84]. Im Bereich der relationalen Datenbanksysteme wurden zu Beginn der Forschungsaktivitäten in diesem Bereich Bottom-up-Ansätze verfolgt. Dabei wurden zunächst effiziente Implementierungen wichtiger Operatoren und Auswertungsstrategien für interessante Teilklassen von Anfragen erforscht. Es zeigte sich allerdings sehr schnell, dass dieses Vorgehen Systeme mit unzureichender Leistungsfähigkeit hervorbrachte [JK84]. Aus diesem Grund verfolgt man seit einigen Jahren einen Top-down-Ansatz, der sich in vier Phasen unterteilen lässt [JK84]: 1. Entwicklung einer Interndarstellung, auf die Anfragen leicht abgebildet werden können 2. Anwendung von logischen Transformationen zur Standardisierung, Vereinfachung und Anfragerestrukturierung 3. Abbildung der transformierten Anfrage auf eine Menge von Anfrageausführungsplänen 4. Berechnung der Kosten für jeden Anfrageausführungsplan und Ausführung des günstigsten Anfrageausführungsplans. Ibaraki und Kameda [IK84] haben bereits 1984 gezeigt, dass es sich bei der Anfrageoptimierung um ein NP-vollständiges Problem handelt. Außerdem sind selten zuverlässige statistische Daten über die Datenbanken vorhanden, so dass bei der Anfrageoptimierung auf verschiedene Heuristiken zurückgegriffen werden muss [JK84]. Bedeutende Ansätze zur Anfrageoptimierung [SAC + 79] lassen sich bis zum ersten relationalen Datenbanksystem System R [ABC + 76] zurückverfolgen, welches bereits in den frühen 70er Jahren des vergangenen Jahrhunderts im Almaden-Forschungslabor der Firma IBM entwickelt wurde [Cha98]. Nach erfolgreichem Abschluss der Analysephase (vgl. Abschnitt 2.2.1) könnte aus dem Anfragegraphen ein beliebiger gültiger Anfrageausführungsplan abgeleitet werden. Dieses Vorgehen hat den entscheidenden Nachteil, dass bei diesem Vorgehen oft ungünstige Operatorfolgen entstehen, die insgesamt zu einer ineffizienten Anfrageauswertung führen [HR01]. Aus diesem Grund werden vor der eigentlichen Erzeugung des Anfrageausführungsplans eine Reihe von Transformationen durchgeführt (vgl. ebd.). Währen der Optimierungsphase werden folgende Schritte durchlaufen: Anfragerestrukturierung und Anfragetransformation [Mit95, HR01]. Während der Anfragerestrukturierungsphase wird eine so genannte algebraische Optimierung durchgeführt. Dabei werden eine Reihe von Heuristiken angewendet, um zum Beispiel eine auf logischer Ebene möglichst günstige Operatorreihenfolge oder eine Minimierung der Größe von Zwischenergebnissen zu erreichen. Nachfolgend werden beispielhaft einige Heuristiken zur Anfragerestrukturierung aufgeführt [HR01]: