Universität Konstanz FB Informatik und Informationswissenschaft Master-Studiengang Information Engineering

Transkript

1 Universität Konstanz FB Informatik und Informationswissenschaft Master-Studiengang Information Engineering Masterarbeit Client-/Server-Architektur in XML Datenbanken zur Erlangung des akademischen Grades eines Master of Science (M.Sc.) Studienfach: Information Engineering Schwerpunkt: Computer Science Themengebiet: Angewandte Informatik von Andreas Weiler (560182) Erstgutachter: Prof. Dr. Marc H. Scholl Zweitgutachter: Prof. Dr. Daniel A. Keim Betreuer: Christian Grün Einreichung: 03. August 2010

2 Zusammenfassung Diese Masterarbeit beschreibt die theoretischen Konzepte und die daraus resultierende Implementierung einer Client-Server Architektur für ein natives XML-Datenbanksystem. Hierbei wird das dieser Arbeit zu Grunde liegende XML-Datenbanksystem BaseX um eine Client-Server Architektur erweitert. Die Entwicklung einer Client-Server Architektur für ein Datenbanksystem ist sehr wichtig, da hierdurch die Einsatzmöglichkeiten des Systems enorm erhöht werden. Beispielsweise können die Dienste das Datenbanksystem von überall und von beliebig vielen Benutzern gleichzeitig durch diese Erweiterung verwendet werden. In der Arbeit werden der grundlegende Aufbau von Server und Client und der Ablauf der Kommunikation zwischen den Clients und dem Server beschrieben. Weiterhin werden die Konzepte des Transaktionsmanagements, Datenmanagement und des Benutzermanagements, welches unerlässliche Komponenten einer Client-Server Architektur sind, dargestellt. Des Weiteren wird ein Überblick über verwandte Arbeiten und mögliche Erweiterungen für das entwickelte Client-Server Modell gegeben. Abstract This master thesis describes the theoretical concepts and the resulting implementation of a client-server architecture for a native xml database system. In this context the underlying xml database system BaseX will be extended with a client-server architecture. The development of a client-server architecture for a database system is very important, because the possible field of application will be enhanced considerably. As an example, the services of the database system can be used from any location and from several users parallely with this extension. In this work the basic design of the server and the client and the communication process between the clients and the server will be described. Furthermore the concepts of transaction management, data management and user management, which are essential components of a client-server architecture, will be demonstrated. In addition an overview about related work and potential extensions for the developed client-server model will be given.

3 Danksagung Die vorliegende Masterarbeit ist am Fachbereich Informatik und Informationswissenschaft am Lehrstuhl der Arbeitsgruppe Datenbanken & Informationssysteme an der Universität Konstanz entstanden. Für die Ermöglichung dieser Arbeit bedanke ich mich recht herzlich bei Herrn Prof. Dr. Marc H. Scholl und allen weiteren Teammitgliedern der Arbeitsgruppe, welche mir mit ihren Ratschlägen weitergeholfen haben. Mein besonderer Dank gilt hierbei vor allem Christian Grün für seine intensive Betreuung während der Durchführung des Master-Projektes und der Erstellung der Masterarbeit. Durch seine hervorragenden Hilfestellungen und Ideen konnte ich viele Probleme lösen und neue Konzepte für das Thema erarbeiten. Des Weiteren möchte ich mich bei Herrn Prof. Dr. Marc H. Scholl und bei Herrn Prof. Dr. Daniel A. Keim für die Bewertung dieser Masterarbeit und die Abnahme des Kolloquiums über die Masterarbeit bedanken. Besonderer Dank gebührt meiner Familie, die mir das Studium ermöglichte und mich während der Studienzeit immer unterstützte. Weiterhin möchte ich mich ganz besonders bei Corinna Gegner für den liebevollen Rückhalt während meines Studiums bedanken. VIELEN DANK.

4

5 Inhaltsverzeichnis 1 Einführung Motivation und Ziel Aufbau der Arbeit Grundlagen Einführung in XML-Datenbanken Vergleich XML-Datenbank und relationale Datenbank Datenstrukturen Abfragesprachen weitere Funktionalitäten Einführung in BaseX Client-Server Modell Einführung Anforderungen an das Client-Server Modell Server Aufbau des Servers Prozessausführung Client Aufbau des Clients Client-Server Kommunikation Nachrichtenaustausch der Standardausführung Nachrichtenaustausch bei der Ergebnisabfrage mittels Iterator Transaktionsmanagement Definition einer Transaktion Transaktionseigenschaften Atomarität Konsistenz Isolation Dauerhaftigkeit i

6 Inhaltsverzeichnis ii 4.3 Nebenläufigkeitskontrolle Sperrprotokoll Prozesslock Probleme der Nebenläufigkeit Datenlock Datenmanagement Grundlagen der Datenhaltung Datenpool Arbeitsweise Datensicherheit Import und Export von Daten Benutzer- & Rechtemanagement Benutzerarten Berechtigungen Authentifizierungsmechanismus Logging Verwandte Arbeiten Überblick XML-Datenbanken exist Sedna Qizx Zusammenfassung Performance & Erweiterungen Performance Vorgehensweise Ergebnisse Erweiterungen Grafische Benutzeroberfläche zur Verwaltung des Servers Benachrichtigungstrigger Rollback Abschluss 85 Literaturverzeichnis 87 Abbildungsverzeichnis 92 Tabellenverzeichnis 93

7 Kapitel 1 Einführung 1.1 Motivation und Ziel In der Welt der Informationstechnologie haben sich die relationalen Datenbanksysteme seit langer Zeit als meist verbreitete Datenbanksysteme durchgesetzt und werden nur selten durch andere Datenbanken ersetzt. So werden auch in der heutigen Zeit für den Einsatz und die Verwendung von Datenbanken immer noch hauptsächlich relationale Datenbanksysteme verwendet. Trotz der zunehmenden Verbreitung und Beliebtheit von XML-Daten [B08] als Austauschund Speicherformat, hat sich der Gebrauch von XML-Datenbanken noch nicht richtig in der Datenbankwelt etabliert. Die stetig wachsende Anzahl von Daten in XML-Format und das damit einhergehende Wachstum der Datenmengen, veranlasst jedoch immer mehr Benutzer auf XML-Datenbanken für die Datenhaltung in ihren Systemen umzusteigen. Die Größe von vielen XML-Dokumenten 1 wächst mit der Zeit auf einige Gigabyte an Datenvolumen an, so dass diese nicht mehr mit den normalen Texteditoren bzw. XML-Editoren bearbeitet werden können. Weiterhin ist es mit gewöhnlichen XML-Editoren im Gegensatz zu XML Datenbanksystemen nicht möglich, Abfragen oder Updates mit Hilfe einer Abfragesprache auf Basis der XML-Dokumente durchzuführen. Mit XML-Datenbanksystemen können hierbei sehr komplexe und intensive Analysen und Modifizierungen der XML- Dokumente ausgeführt werden. In relationalen Datenbanksystemen hat sich der Einsatz des Systems in einer Client- Server Architektur zum Standard entwickelt. So verwendet man bei all diesen Systemen 2 einen zentralen Datenbankserver, zu welchem man sich mit den diversen Clients verbinden kann. Diese Einsatzmöglichkeit sollte somit auch in XML-Datenbanken vorhanden sein, um den Standard der gewohnten Datenbanksysteme einzuhalten. 1 Ein Beispiel hierfür ist die gesamte Datenansammlung von Wikipedia im XML-Format mit ca. 7GB an Datenvolumen (siehe Juli 2010) 2 z.b. die Datenbanksysteme DB2 von IBM (siehe Juli 2010) oder 11g von Oracle (siehe Juli 2010) 1

8 1 Einführung 2 Das dieser Arbeit zu Grunde liegende native XML-Datenbanksystem BaseX [HGS09] wurde standardmäßig ohne Server und Clients als Standalone -Software im lokalen Modus verwendet. Diese Arbeit beschreibt nun die Entwicklung und Verwendung des XML- Datenbanksystems BaseX im Client-Server Modus. Da keine Client-Server Architektur in BaseX vorhanden war, gab dies genügend Motivation die Entwicklung einer Client-Server Architektur für eine XML-Datenbank durchzuführen. Durch den Anreiz XML-Datenbanken auf einen ähnlichen oder sogar höheren Standpunkt wie relationale Datenbanken anzuheben wurde diese Motivation noch zusätzlich verstärkt. Der Gebrauch der Abfragesprache XQuery [B07] und die aktuell abgeschlossene Entwicklung der standardisierten Datenmanipulation in XML-Datenbanken mittels XQuery Update [C09] erhöhen die Einsatzmöglichkeiten und den Standpunkt von XML-Datenbanken enorm. Die hieraus erfolgte Einführung von XQuery Update in das Datenbanksystem BaseX erschwerte zwar zunehmend die Implementation des Transaktionsmanagements, erhöhte aber auch die Wichtigkeit einer Client-Server Architektur für XML Datenbanken. Die klassischen in relationalen Datenbanken eingesetzten Nebenläufigkeitskontrollen sind für semi-strukturierte Daten, welche in XML-Datenbanken vorkommen, nicht einsetzbar und unzulänglich. Hierfür stehen neue Konzepte bereit, welche an die Zwecke von XML-Datenbanken angepasst wurden. Da durch die XQuery Update Schnittstelle Updates auf XML-Datenbanken vereinheitlicht werden und das Arbeiten mit den XML Datenbanken deutlich vereinfacht wird, wird die Benutzerzahl von XML-Datenbanken in der Zukunft deutlich ansteigen. Ziel dieser Arbeit ist es die Entwicklung für eine stabile, zuverlässige, sichere und in der Praxis einsetzbare Client-Server Architektur zu beschreiben und die Umsetzung der dahinter stehenden theoretischen Konzepte zu erläutern. Hierbei traten in den verschiedensten Bereichen Problemstellungen auf, welche durch die erarbeiteten Konzepte gelöst wurden. Die verschiedenen Bereiche umfassen den Aufbau des Servers und des Clients, den Ablauf der Client-Server Kommunikation und die Konzeption des Transaktions-, Datenund Benutzermanagements. Die direkte Umsetzung der theoretisch erarbeiteten Konzepte, machte es möglich direkt auf Probleme und Fehlerquellen zu reagieren und diese somit bei der Entstehung zu lösen. Dies hat den Vorteil, dass alle in dieser Arbeit vorgestellten Lösungen in einer praktischen Anwendung verwendet und somit stets aufs Neue getestet werden. Die erarbeiteten und in BaseX umgesetzten Konzepte sind allgemeingültig und können in anderen XML- Datenbanken problemlos eingesetzt werden. 1.2 Aufbau der Arbeit Zu Beginn dieser Arbeit wird eine Einführung in die Thematik von XML-Datenbanken gegeben und die Definition von nativen XML-Datenbanken aufgezeigt. Anschließend wird

9 1 Einführung 3 ein Vergleich zwischen relationalen Datenbanken und nativen XML-Datenbanken dargestellt. Weiterhin wird das dieser Arbeit und der entstandenen Client-Server Architektur zu Grunde liegende native XML-Datenbanksystem BaseX vorgestellt. Anschließend werden die Komponenten der Client-Server Architektur (siehe Kapitel 3) detailliert beschrieben und ihre Zusammenhänge verdeutlicht. Die verwendete zweistufige Architektur [Abt07, S. 10 f.] besteht aus den zwei Ebenen Server und Client. Diese Architektur kann prinzipiell in drei Schichten [Abt07, S. 5] eingeteilt werden. Die drei Schichten bestehen aus der Datenhaltung, Verarbeitung und der Präsentation. Auf der Seite des Servers, welche in Kapitel 3.3 beschrieben wird, befinden sich die Datenhaltung der Datenbanken und die Verarbeitung der Prozesse. Die Schicht der Verarbeitung beinhaltet die gesamte Prozessausführung, welche im Abschnitt detailliert beschrieben wird, und die Bereitstellung der Ergebnisse für die Clients. Die Seite des Clients (siehe Kapitel 3.4) hat die Aufgaben die Anfragen an den Server zu senden und bei Erhalt die Ergebnisse in der Schicht der Präsentation darzustellen. Für den fehlerfreien Betrieb der Verarbeitung der Transaktionen ist das im darauf folgenden Kapitel 4 geschilderte Transaktionsmanagement verantwortlich. Hierbei werden die Definition und die Eigenschaften von Transaktionen erläutert. Weiterhin werden der aktuell eingesetzte Mechanismus zur Nebenläufigkeitskontrolle und Probleme der Nebenläufigkeit von Transaktionen aufgezeigt. Abschließend werden verschiedene Lösungen für weitere Kontrollen zur Nebenläufigkeit präsentiert. Die dritte und letzte Schicht beschreibt die Datenhaltung. Diese Schicht wird durch das Datenmanagement (siehe Kapitel 5) realisiert. Hierdurch wird der Zugriff auf die Datenbanken, welche bei den verschiedensten Transaktionen verwendet werden, gewährleistet und sicher verwaltet. Als weiteres Feature der Client-Server Architektur ist ein weit reichendes Benutzer- und Rechtemanagement (siehe Kapitel 6) integriert, welches eine problemlose Zugriffsverwaltung auf die Datenbanken und die Authentifizierung beim Einloggen am Server bietet. Weiterhin wird hierdurch die Autorisierung der Benutzer über ihre Berechtigungen bei der Ausführung einer der zahlreichen Dienste, welche vom Server angeboten werden, durchgeführt. Im darauf folgenden Kapitel 7 werden verwandte Arbeiten in nativen XML-Datenbanken vorgestellt und auf die Funktionalitäten mit Hinsicht auf die Client-Server Architektur überprüft. Mit dem Belastungstest im Abschnitt 8.1 wird die Leistungsfähigkeit des Client-Server Systems mit einer hohen Anzahl von Clients in BaseX veranschaulicht. Zum Abschluss der Arbeit werden nützliche Erweiterungen für die Client-Server Architektur in XML- Datenbanken dargestellt und die Arbeit mit dem letzten Kapitel abgeschlossen.

10 Kapitel 2 Grundlagen Dieses Kapitel gibt eine Einführung in den Begriff der XML-Datenbanken und erläutert hierbei insbesondere die Eigenschaften und Definition einer nativen XML-Datenbank. Weiterhin wird eine Abgrenzung zu relationalen Datenbanken und die Unterschiede zwischen den beiden Datenbanktypen dargestellt. Im letzten Abschnitt des Kapitels wird das der Client-Server Architektur zu Grunde liegende native XML-Datenbanksystem BaseX vorgestellt. 2.1 Einführung in XML-Datenbanken Die Bezeichnung XML-Datenbank steht als Überbegriff für alle Arten von Datenbanken, welche mit Daten in Form von XML-Dokumenten arbeiten können. Diese Datenbanken müssen die Möglichkeit haben im ersten Schritt XML-Dokumente zu verarbeiten und diese dann für weitere Schritte, wie Abfragen und Updates zur Bearbeitung bereit zu stellen. Den Übergriff kann man hierbei in zwei Unterformen der Datenbanken aufgliedern. Zum einen können XML-Dokumente in XML-fähige Datenbanksysteme in deren eigene Speicherstruktur gespeichert und zur weiteren Verarbeitung bereitgestellt werden. Bei der zweiten Form können die XML-Daten direkt in native XML-Datenbanken eingelesen und in ihrer ursprünglichen Form in einer eigens dafür definierten Datenstruktur gespeichert werden. Diese beiden Varianten werden im Folgenden näher erläutert: XML-fähiges Datenbanksystem [S04, S. 11 ff.]: Hierbei handelt es sich um ein relationales oder objektorientiertes Datenbanksystem, welches die Möglichkeit bietet XML-Daten auf das vorhandene Datenmodell abzubilden und dadurch in der Datenbank zu speichern. Das Datenbanksystem speichert somit nur die im XML-Dokument vorhandenen Daten im Datenbank eigenen Schema ab. Hierdurch kann eine Wiederherstellung des original XML-Dokuments nicht garantiert werden kann. Aus diesem Grund wird diese Form der Speicherung von XML-Daten als Daten-orientiert bezeichnet. native XML-Datenbank [S04, S. 17 ff.]: Bei dieser Datenbankform wird das XML Datenmodell direkt verwendet und die Daten des XML-Dokumentes mitsamt ihrer Struktur in der Datenbank gespeichert. Hierdurch ist die Wiederherstellung des 4

11 2 Grundlagen 5 original XML-Dokumentes problemlos möglich. Die verschiedenen nativen XML-Datenbanksysteme bieten hierbei ihre eigenen Strukturen für die Speicherung der XML-Daten an. Im Gegensatz zu den XML-fähigen Datenbanksystemen sind diese Datenbanken als Dokument-orientiert anzusehen. In dieser Arbeit wird der Einsatz einer Client-Server Architektur in einer nativen XML- Datenbank vorgestellt, weswegen die Definition von diesem Begriff im Weiteren noch detaillierter erläutert wird. Native XML-Datenbanken zeichnen sich weiterhin formal durch die folgenden drei Kriterien 1 aus: Eine native XML-Datenbank definiert ein logisches Modell für ein XML-Dokument. Dieses Modell wird für die Speicherung der Dokumente und den Datenzugriff auf die Dokumente benutzt. Als grundlegende Speichereinheit wird bei einer nativen XML-Datenbank ein XML- Dokument verwendet. Dies gleicht der Verwendung einer Zeile in einer Tabelle als grundlegende Speichereinheit in einer relationalen Datenbank. Für die native XML-Datenbank wird kein spezielles zu Grunde liegendes physisches Speichermodell vorausgesetzt. Eine native XML-Datenbank kann beispielsweise auf einer relationale, hierarchischen oder objektorientierten Datenbank aufgebaut sein. Weiterhin ist es möglich ein eigenes Speichermodell zu benutzen. Das dieser Arbeit zu Grunde liegende Datenbanksystem BaseX ist zu den nativen XML- Datenbanken zu zählen. BaseX verwendet ein eigenes Speichermodell für die Datenhaltung der XML-Dokumente. Mit diesem Modell werden die Struktur und die Daten des XML- Dokuments in der Datenbank gespeichert. Der Datenzugriff wird ebenfalls über dieses Modell realisiert. Weiterhin ist BaseX vollkommen darauf ausgerichtet XML-Dokumente in Datenbanken zu speichern, um diese zur weiteren Bearbeitung bereit zu stellen. In der weiteren Arbeit wird aufgrund der besseren Lesbarkeit auf die Bezeichnung native verzichtet und der Begriff XML-Datenbank verwendet. 2.2 Vergleich XML-Datenbank und relationale Datenbank Zwischen XML-Datenbanken und relationalen Datenbanken gibt es grundlegende Unterschiede, welche sich in die Bereiche der Datenstrukturen und Abfragesprachen einteilen lassen. Da es sich bei relationalen Datenbanken um traditionelle und seit langer Zeit 1 Die drei Kriterien sind von der Initiative XML:DB [The10] definiert und festgelegt.

12 2 Grundlagen 6 bewährte Systeme handelt sind hierbei viele Funktionen vorhanden, welche auch in XML- Datenbanken Verwendung finden können. Diese Funktionen werden im Abschluss dieses Abschnitts weiter erläutert Datenstrukturen Wie aus dem zweiten Kriterium aus der vorhergehenden Definition ersichtlich wird, sind die grundlegenden Datenstrukturen ein Hauptunterschied zwischen XML-Datenbanken und relationalen Datenbanken. Das Datenmodell einer relationalen Datenbank besteht aus Tabellen mit Zeilen und Spalten. Diese Tabellen können durch Schlüsselbeziehungen (Primär- zu Fremdschlüssel) miteinander in Verbindung gebracht werden. In XML-Datenbanken hingegen werden XML-Dokumente direkt in die definierte Speicherstruktur eingelesen und ihre native Form erhalten. Der Aufbau eines XML-Dokuments ist immer hierarchisch und die Struktur wird mit Elementen, Unterelementen und in den Elementen enthaltenen Attributen dargestellt. Diese Struktur gleicht einer Baumstruktur mit einer Wurzel, Unterbäumen und Blättern. Beziehungen zwischen den Elementen können bei XML-Dokumenten durch ihre Struktur oder durch eine dazugehörige DTD-Datei 2 definiert werden. Da es sich beim XML-Datenmodell um eine hierarchische Struktur handelt, ist die Reihenfolge der Elemente sehr wichtig. Hierbei können ineinander verschachtelte Elemente jeglicher Tiefe vorhanden sein. Bei relationalen Datenbanken müssen solch verschachtelte Elemente extra zerlegt und mittels Fremdschlüsselbeziehungen neu verknüpft werden. Dies bringt Vorteile für eine wichtige Variante der Datenmodellierung, die so genannte n:m -Beziehung 3, mit sich. Da eine Wiederholung von Elementen innerhalb eines anderen Elements unbeschränkt erlaubt ist, ist diese Variante der Datenmodellierung in XML-Dokumenten problemlos möglich. Hierbei gibt es mehrere verschiedene Varianten. Man kann z.b. wie in Abbildung 2.1 dargestellt, die Elemente wiederholt im Elternelement speichern und somit die Zuweisung herstellen. In relationalen Datenbanken muss für eine n:m -Beziehung eine extra Tabelle (siehe Abbildung 2.1) angelegt werden. Mit Hilfe dieser Tabelle werden dann aus der n:m Beziehung, zwei 1:n Beziehungen erstellt und die gewünschten Verbindungen modelliert. Weiterhin muss ein Element in einem XML-Dokument nicht immer die gleichen Elemente in den darunterliegenden Ebenen enthalten, diese Möglichkeit von Alternativen gibt es bei relationalen Datenbanken nicht, da jede Zeile in einer Tabelle stets die gleichen Spalten 2 Eine DTD definiert die Struktur eines XML-Dokumentes anhand verschiedener Regeln. [LBK01, S. 551 ff.] 3 Eine n:m -Beziehung stellt eine Beziehung zwischen zwei Tabellen dar, die auf beiden Seiten beliebig viele Zuordnungen von Datensätzen zulässt. So kann z.b. eine Vorlesung von beliebig vielen Studenten besucht werden und der Student beliebig viele Vorlesungen besuchen.

13 2 Grundlagen 7 besitzen muss. Die aufgezeigten Unterschiede lassen erkennen, dass das relationale Datenmodell sehr viel strenger definiert ist als die Struktur von XML-Dokumenten. Mit XML-Dokumenten ist die Freiheit der Datenmodellierung sehr viel höher als in relationalen Datenbanken. Dies hat wiederum zur Folge, dass bei Updates auf die XML-Datenbanken, die Integritätsbedingungen der Daten nur mit Einbeziehung der DTD gewährleistet werden können. In relationalen Datenbanken werden bei jedem Update die Bedingungen der Schlüsselbeziehungen überprüft und somit die Konsistenz der Daten erhalten. Weiterhin werden in relationalen Datenbanken für jede Spalte der verschiedenen Tabellen die gültigen Datentypen, wie z.b. Integer, Text usw., definiert. Dies ist in XML-Dokumenten ebenfalls nur durch die Definition in einer DTD-Datei möglich. 1'> 1'/> 2'/> 3'/> </Vorlesung> 2'> 1'/> 2'/> </Vorlesung> 1'> 1'/> 2'/> </Student>... Abbildung 2.1: Beispiel für eine n:m Beziehung in XML und in einer relationalen Datenbank Abfragesprachen Ein weiterer Unterschied sind die verwendeten Abfragesprachen der beiden Datenbanken. Während bei relationalen Datenbanken standardmäßig SQL [Wie08, S. 19 ff.] ( Structured Query Language ) zum Einsatz kommt, wird bei XML-Datenbanken auf die Abfragesprache XQuery gesetzt. XQuery ( XML Query Language ) ist eine komplexe Abfragesprache, welche aus den Pfadausdrücken von XPath 4 und weitergehenden Funktionen, wie der Volltextsuche und Updates besteht. 4 XPath [CD99] ( XML Path Language ) ist eine Abfragesprache auf XML-Dokumente, welche durch Pfadausdrücke Teile eines XML-Dokumentes adressiert.

14 2 Grundlagen 8 Anhand der Pfadausdrücke von XPath kann auf eine schnelle und einfache Art und Weise die Baumstruktur eines XML-Dokumentes durchlaufen und abgefragt werden. Hierbei wird die XML-Baumstruktur in verschiedene Achsen 5 eingeteilt und über deren Kennwörter angesprochen. Im Gegensatz zu SQL, was explizit für den Einsatz mit Datenbanken entwickelt ist und somit eine eingebaute Datenbanklogik besitzt, ist dies in XQuery nicht der Fall. Mit SQL kann man z.b. direkt Datenbanken erstellen und diese mit Daten füllen. In einem XML-Datenbanksystem müssen somit die ganzen Funktionalitäten für die Datenbanklogik zusätzlich entwickelt und mit speziellen Befehlen definiert werden. Durch die große Vielfalt von XQuery und das Ziel auch XML-Daten in relationalen Datenbanken mit XQuery abzufragen, haben immer mehr Datenbanksysteme, wie Oracle [M04, S. 192 ff.] und IBM [M04, S. 206 ff.] XQuery in ihren Systemen schon integriert oder sind gerade dabei eine XQuery Implementation in ihren Systemen zu integrieren. Während SQL nur auf strukturierte Daten angewendet werden kann, können mit XQuery Abfragen und Veränderungen auf semi-strukturierte Daten durchgeführt werden. XQuery Ausdrücke besitzen hierbei die so genannte FLWOR -Form ( For-Let-Where-OrderBy- Return ). Diese ähnelt der Syntax von SQL, mit der Abfragen über die Select-From-Where Klausel formuliert werden. XQuery bietet im Gegensatz zu SQL die Möglichkeit eigene Funktionen zu definieren und diese auch rekursiv aufzurufen. Hierdurch ergeben sich für den Benutzer viel mehr Variationen und Einsatzmöglichkeiten, der mehr als hundert in XQuery vordefinierten Funktionen (siehe [Bru08, S. 87 ff.]) in den Abfragen als mit SQL. XQuery bietet somit Funktionalitäten an, welche die meisten Funktionen von SQL abdecken und diese sogar übertreffen [Bru08, S. 127]. Der nächste Unterschied sind die verwendeten Updatekonzepte der beiden Datenbankformen. Während in relationalen Datenbanken, die Updateschnittstelle standardmäßig durch SQL gegeben ist, war in XML-Datenbanken bis zur Entwicklung von XQuery Update kein standardisiertes Updatekonzept vorhanden. Hierdurch musste man bei der Entwicklung von XML-Datenbanken eigene Update Verfahren definieren und umsetzen. Die Einführung von XQuery Update erreichte es ein standardisiertes Konzept für Updates in XML-Datenbanken einzuführen. Durch diese Einführung wurde ein großer Nachteil gegenüber relationalen Datenbanken beseitigt. Die erweiterten Funktionen und der Einsatz von XQuery auf semi-strukturierte Daten macht XQuery zu einer sehr komplexen Abfrage- und Updatesprache auf Datenbanken weitere Funktionalitäten Im Gegensatz zu relationalen Datenbanksystemen gibt es in XML-Datenbanken keine festgelegten Konzepte für weitere Funktionalitäten des Datenbanksystems, wie z.b. das 5 z.b. Ancestor, Descendant oder Child (siehe Juli 2010)

15 2 Grundlagen 9 Transkations- oder das Benutzermanagement. Relationale Datenbanksysteme besitzen ausgereifte Transaktionskonzepte, welche die Nebenläufigkeit von Transaktionen durch verschiedene Mechanismen regeln. Hierbei werden, je nach Granularität einzelne Datenbanken, Tabellen oder Zellen gesperrt, um die Nebenläufigkeit möglichst hoch zu halten. Die Variabilität der Strukturen von XML-Dokumenten und die Komplexität der damit einhergehenden XQuery Anfragen wirken sich schwerwiegend auf die Transaktionskonzepte in XML-Datenbanken aus. Hierbei ist eine effiziente Sperrung der verschiedenen Datenobjekten nur sehr schwer zu realisieren. Aus diesem Grund sind in BaseX die in Kapitel 4 beschriebenen Konzepte im Einsatz. Weitere Bestandteile von relationalen Datenbanksystemen sind das Benutzermanagement und das Logging. Beide Funktionen müssen im Kontext der Client-Server Architektur auch in einer XML-Datenbank vorhanden sein. In relationalen Datenbanksystemen ist das Benutzermanagement durch die verschiedenen Befehle von SQL schon standardmäßig enthalten. Im Gegensatz hierzu bietet XQuery solche Funktionen auf Grund der fehlenden Datenbanklogik nicht. Aus diesem Grund muss hierfür ein eigen entwickeltes Benutzermanagement (siehe Kapitel 6), welches auf die Bedürfnisse von XML-Datenbanken angepasst ist, nötig. Weiterhin ist das Mitschreiben der Serveraktivitäten (Logging) ist für die Protokollierung in einer XML-Datenbank ebenso wichtig wie in relationalen Datenbanken. 2.3 Einführung in BaseX Das Forschungsprojekt BaseX [G10] wird von der Arbeitsgruppe Datenbanken & Informationssysteme 6 an der Universität Konstanz unter der Leitung von Prof. Dr. Marc H. Scholl und Christian Grün entwickelt. Bei BaseX handelt es sich um eine native XML-Datenbank, welche seit März 2007 als Open Source Software bereitgestellt wird. Hieraus resultiert eine ständig wachsende Anzahl von Benutzern, welche durch ihre Beiträge in der Open Source Gemeinschaft 7 zur Entwicklung von BaseX beitragen. BaseX ist vollständig in Java programmiert und bringt somit den Vorteil der Platzformunabhängigkeit mit sich. Durch die Verwendung von Java kann BaseX auf den gängigsten Plattformen bzw. Betriebssystemen verwendet werden. Für den Einsatz von BaseX sind keine Installationsoder Konfigurationsarbeiten zu verrichten und so kann es direkt gestartet werden. Dies ist für die Ausführung des Programms als Client-Server Modell ebenfalls gewährleistet. Ein wichtiges Merkmal von BaseX ist die Unterstützung von sehr großen XML-Dokumenten für die Erstellung von Datenbanken. Hierbei wurden in BaseX schon Datenbanken aus 6 siehe Juli siehe Juli 2010

16 2 Grundlagen 10 XML-Dokumenten mit einer Größe von bis zu 55 GB erstellt. Des Weiteren ist der effiziente XQuery und XPath Prozessor eine der wichtigsten Komponenten von BaseX. Hierdurch können sehr schnelle Abfragen bzw. Updates auf die erstellten Datenbanken ausgeführt werde. Der XQuery/XPath Prozessor unterstützt die neuesten Volltext [AY10] und Update Empfehlungen des W3C 8. Die Unterstützung von XQuery Update erweitert BaseX um einen wichtigen Standard, welcher zu einem vollwertigen Datenbanksystem unweigerlich hinzu gehört. Hierdurch werden standardisierte Updates auf die Datenbanken ermöglicht. Durch den Einsatz von XPath Pfadausdrücken in XQuery Update Anfragen können somit sehr komplexe und nützliche Aktualisierungen auf die Datenbanken vorgenommen werden. Weiterhin ist ein interaktives Frontend vorhanden, welches die Daten in einer Baumstruktur, in einer Treemap [HGS07], Tabelle oder einem Scatterplot darstellen kann. Jede dieser Visualisierungen hat ihre eigenen Stärken und somit ergänzen sie sich zu einem perfekten Analysewerkzeug für die in den Datenbanken gespeicherten XML-Daten. Durch die hohe Komplexität der Visualisierungen ist es jedoch im derzeitigen Stand nicht möglich das Frontend für die Interaktion mit dem Server zu verbinden. Somit wurde das Frontend nicht in die Client-Server Architektur miteinbezogen. Für die Administration des Servers ist in das Hauptfrontend eine Option eingebettet, welche einen Dialog zur Verwaltung des Servers öffnet. In diesem Dialog wird dem Benutzer die Möglichkeit gegeben die Verwaltung des Servers, ohne die dazu nötigen Befehle zu kennen, durchzuführen. Um dies in Zukunft unabhängig vom Hauptfrontend in BaseX ausführen zu können ist ein eigenständiges Frontend (siehe 8.2.1) in der Entwicklung, in welchem die schon entwickelten Komponenten in einer kompakten Struktur für die Benutzer bereitgestellt wird. In diesem Frontend gibt es zudem die Möglichkeit Abfragen und Updates auf die verschiedenen Datenbanken auszuführen, um somit auch die Interaktion mit den Daten zu unterstützen. 8 Das World Wide Web Consortium (kurz: W3C), legt standardisierte Techniken fest, welche im World Wide Web eingehalten werden sollen (siehe Juli 2010). Beispiele hierfür sind XQuery und XPath.

17 Kapitel 3 Client-Server Modell Diese Kapitel gibt einen Überblick über das Client-Server Modell, welches im XML- Datenbanksystem BaseX eingesetzt wird. Zu Beginn werden die wesentlichen Ziele des Client-Server Modells und ihre Umsetzung dargestellt. Nachfolgend wird der Aufbau und die Funktionsweise des Servers beschrieben. Daran anschließend folgt eine detaillierte Beschreibung des Ablaufs einer Prozessausführung auf dem Server, und zum Abschluss des Kapitels werden der Aufbau des Clients und die verschiedenen, zwischen dem Server und dem Client, ablaufenden Kommunikationsformen dargestellt. 3.1 Einführung Ein Client-Server Modell kann auf verschiedene Arten aufgebaut werden. Bei allen Varianten gibt es aber stets zwei Hauptkomponenten, den Server und den Client. In Abbildung 3.1 sind die drei logischen Ebenen (User Interface, Application, Database) des Client-Server Modells auf die Komponenten aufgeteilt dargestellt. Das Backend mit der kompletten Implementierung des Datenbanksystems befindet sich auf der Serverseite des Client-Server Modells. Man bezeichnet dies als eine zentralisierte Client-Server Architektur [TS06, S.36]. Der Server beinhaltet in diesem Fall die Prozessausführung und die Datenhaltung. Diese beiden Funktionalitäten sind somit zentral am Server vorhanden und können von den Clients von überall und zu jeder Zeit verwendet werden. Abbildung 3.1: Organisation der logischen Ebenen auf Client-Server Quelle: Angelehnt an [TS06, S. 41] 11

18 3 Client-Server Modell Anforderungen an das Client-Server Modell Eine Anforderung an das Client-Server Modell ist die Bereitstellung [TS06, S. 3] und Verwendbarkeit der Daten. Die Datenbereitstellung soll hierbei schnell und effektiv an mehrere Benutzer möglich sein. Dies wird in BaseX durch den in Kapitel 5.2 beschriebenen Datenpool erreicht. Die zentrale Datenhaltung vereinfacht es den Benutzern gemeinschaftlich dieselben Datenbanken zu verwenden und gewährleistet den Benutzern, immer auf dem aktuellsten Stand der Daten zu arbeiten. Da jede Datenbank nur einmal gespeichert werden muss, wird zudem eine Einsparung an Speicherplatzbedarf erreicht. Des Weiteren ist durch die zentrale Speicherung eine redundante Datenhaltung ausgeschlossen. Die Benutzerverwaltung liefert zudem eine zuverlässige Zugriffskontrolle auf die Datenbanken. Ein weiteres Kriterium, welches an eine Client-Server Architektur gestellt wird, ist das Erreichen der Verteilungstransparenz [TS06, S. 4], welche besagt, dass die Verteilung des Systems für die einzelnen Clients nicht sichtbar sein soll. Hierbei sind vor allem die Zugriffstransparenz und die Ortstransparenz von großer Wichtigkeit. Die Zugriffstransparenz besagt, dass der Zugriff auf die vom Server angebotenen Dienste und Daten auf die gleiche Weise erfolgen soll, wie wenn die Dienste und Daten lokal vorhanden wären. Die Ausführung der Anfragen und die Zugriffe auf die Daten erfolgt von den Clients mit den gleichen Befehlen wie in der lokalen Variante des Programms. Für den Client ist es somit transparent, dass die Anfragen an den Server übermittelt, dort ausgeführt und die Ergebnisse vom Server zurück an den Client geliefert und diesem bereit gestellt werden. Bei der Ortstransparenz wird der Ort der Datenhaltung verdeckt und die Datenbanken werden mit einem definierten Datenbankname angesprochen. Diese Transparenz bringt den Vorteil mit sich, dass Datenbanken auf dem Server verschoben werden können und dies keine Maßnahmen auf den Zugriff durch die Clients hat, da der Datenbankname immer noch derselbe ist. In BaseX wird hierfür ein zentraler Ordner definiert, in dem alle Datenbanken gespeichert werden. Dieser Ordner kann frei auf der Festplatte gewählt werden und ist für die Clients nicht ersichtlich. Des Weiteren wird der Pfad zum Quelldokument der Datenbank nur dem Administrator, bzw. einem für die Datenbank berechtigten Benutzer angezeigt. Unberechtigte Benutzer können somit keine Informationen über die Quelldokumente der Datenbanken erhalten. Ein weiterer Typ von Transparenz ist die Nebenläufigkeitstransparenz, welche es verhindert, dass die einzelnen Clients bemerken, dass andere Clients parallel zu ihnen auf die Daten zugreifen. Die Clients greifen so auf die Daten zu, als hätten sie alleinigen Zugriff auf diese. Diese Transparenz wird durch die Eigenschaft der Isolation (siehe 4.2.3) gewährleistet. Das Ziel der Offenheit des Systems [TS06, S. 7] besagt, dass die vom Server angebotenen Dienste fest definiert sein müssen und durch einfache Erweiterungen weitere Dienste am Server hinzugefügt werden können. Für diesen Zweck ist es sinnvoll eine Funktion anzubieten, welche alle ausführbaren Dienste auflistet.

19 3 Client-Server Modell 13 Hierdurch erhält jeder Benutzer einen Überblick über die Dienste, welche er am Server in Anspruch nehmen kann. Erweiterungen können durch zusätzliche Implementierungen in den Programmcode des Servers eingefügt werden. An den Clients müssen keine Veränderungen vorgenommen werden und somit beschränkt sich die Softwareaktualisierung auf die Serverseite. Die Änderungen bzw. Erweiterungen der Dienste des Servers stehen den Clients sofort zur Verfügung und können dadurch direkt verwendet werden. Neben der Verteilungstransparenz ist die Skalierbarkeit eines Client-Server Modells ein wichtiges Kriterium, welches erfüllt werden muss. Die Skalierbarkeit besagt, dass das System mit beliebig vielen und beliebig großen Datenbanken, wie auch einer beliebigen Anzahl von Clients existieren kann, ohne dass dafür Anpassungen am System vorgenommen werden müssen. Hierbei sollte das System trotz erhöhter Auslastung eine gute Performance aufweisen. Dies wird durch die folgenden zwei in diesem Kontext wichtigen Unterkriterien [Haa08, S.13 ff.] beschrieben. Größe: Die Skalierbarkeit der Größe wird durch zentrale Dienste und zentrale Daten erschwert. Durch das zentrale Anbieten der Dienste am Server kann es zu Engpässen, bei gleichzeitiger Benutzung von vielen Clients kommen. Dies wird durch das Konzept verhindert, dass die einzelnen Clients jeweils einen eigenen Thread am Server besitzen und in diesem die Dienste ausgeführt werden. Somit gibt es hierbei keine Probleme bei der Skalierbarkeit. Wie im Kapitel 8.1 zu erkennen ist kann der Server problemlos 500 Clients gleichzeitig bedienen. Das Anbieten von zentralen Daten kann ebenfalls sehr schnell zu Engpässen bei der Verarbeitung führen. In Kapitel 8.1 ist zu erkennen ist, dass das System trotz zentraler Datenhaltung die Ausführung der Anfragen von beliebig vielen Clients in effizienter Zeit durchführt. Die Abarbeitung von Abfragen auf die gleichen Datenbanken sind hierbei von der Festplatte und der Java Virtual Machine, welche die Abarbeitung der aktiven Threads steuert, abhängig. Geographie: Die Skalierbarkeit bezüglich der Geographie beschreibt, dass die Kommunikation von entfernten Rechnern langsamer ist als die lokale Kommunikation. Durch die Verwendung einer Socket-Kommunikation zwischen Client und Server ist hierfür alleine die Internetverbindung ausschlaggebend. Auf dem Server ist ein Leseund Schreibkonzept im Einsatz, welches durch direkte Weitergabe (ohne Zwischenspeichern) der Nachrichten eine höchstmögliche Verarbeitungsperformance garantiert. Die Clients wurden in dieser Hinsicht ebenfalls weitestgehend optimiert. 3.3 Server Als Server bezeichnet man ein Programm, mit welchem in einem Netzwerk verschiedene Dienste angeboten werden. Diese Dienste können nach Start des Servers von den jeweiligen

20 3 Client-Server Modell 14 Clients in Anspruch genommen werden. Hierbei kann der Server im Regelfall mehrere Clients gleichzeitig bedienen. Der Server stellt den Clients die folgenden Dienste (siehe Tabelle 6.1) zur Verfügung: Ausführung von XQuery: Zur Ausführung einer XQuery Abfrage muss immer der folgende Befehl an den Server gesendet werden: XQUERY [query] Die eigentliche Abfrage wird hierbei im query -Teil des Befehls definiert und kann in zwei Kategorien eingeteilt werden: Abfragen von Daten: Mit Hilfe des XQuery-Befehls kann auf verschiedenste Art und Weise Daten aus den am Datenbanksystem registrierten Datenbanken ausgelesen werden. So können z.b. einzelne Elemente oder ganze Dokumentteile mit einer Abfrage extrahiert werden. Weiterhin bietet der Server neben den standardmäßigen XQuery und XPath Befehlen auch die Möglichkeit, mittels der neu entwickelten Volltextfunktionalität von XQuery, eine komplexe Volltextsuche auf die Datenbank auszuführen und die entsprechenden Ergebnisse zurückzuliefern. Des Weiteren gibt es in BaseX implementierungsspezifische Erweiterungen der Funktionalität von XQuery. Diese können durch die Angabe des Prefix basex: mit anschließendem Funktionsname in XQuery Anfragen verwendet werden. Ein Beispiel hierfür ist die basex:read(file) Funktion, welche eine Datei einliest und die enthaltene Zeichenkette entweder zur weiteren Verarbeitung in der Anfrage oder als Ergebnis bereitstellt. Datenveränderungen: Durch das neu eingeführte XQuery Update Konzept können die Daten der am Server registrierten Datenbanken auf vielfältigste Art und Weise modifiziert werden. Die Hauptfunktionen bestehen hierbei aus den folgenden Updatemöglichkeiten: Insert, Delete, Replace und Rename. Diese Funktionen können sowohl auf Elemente, wie auch Attribute der XML-Daten angewendet werden. Weiterhin kann man weitere Optionen wie z.b. insertbefore oder insertintoas- First bei den Funktionen verwenden. So kann man z.b. in einer Transaktion Elemente an einer Stelle bestimmten löschen und andere Elemente an anderen Stellen gleichzeitig hinzufügen. Weitere Systemfunktionen: Die weiteren Systemfunktionen werden nicht durch XQuery abgedeckt und sind somit speziell für das Datenbanksystem entwickelt. Diese werden ebenfalls durch das senden eines Befehls 1 an den Server ausgeführt. Hierunter fallen die Verwaltung (Erstellen und Löschen) von Datenbanken, die Verwaltung der Benutzer und ihrer Berechtigungen und die Erstellung von Indexstrukturen. 1 Liste mit allen verfügbaren Befehlen siehe Tabelle 6.1 oder Juli 2010

21 3 Client-Server Modell 15 Durch die erstellten Indexstrukturen (z.b. Volltext-Index oder Attribut-Index) werden XQuery Abfragen, welche bei ihrer Ausführung auf einen Index zugreifen können, beschleunigt. Die Struktur der Datenbanken kann zudem durch einen Aufruf des Optimize -Befehls neu erstellt werden. Dies wird gegebenenfalls notwendig, falls nach einigen Updates die Datenbankstruktur zwar noch korrekt ist, sich aber nicht mehr in einem optimalen Zustand befindet. Im Folgenden wird als Beispiel der create -Befehl näher erläutert: CREATE [DB COLL FS INDEX USER] [...] Mit dem create -Befehl kann man je nach Angabe eine Datenbank, eine Collection, eine Dateisystem-Datenbank, einen Index oder einen Benutzer erstellen. Hierbei werden je nach Optionswahl noch weitere Parameter, wie Dateiname oder Benutzername und Passwort benötigt. Diese angebotenen Dienste und der Fakt, dass alle Datenbanken auf dem Server gehalten und für die Clients bereitgestellt werden, definieren den Server zu einem Datenbankserver. Der Datenbankserver hat die Aufgabe, die komplette Abarbeitung aller Anfragen inklusive der damit verbundenen Datenbankzugriffe zu verwalten und zu steuern. Hierbei ist es wichtig, dass die Steuerung effizient und effektiv abläuft. Die Effizienz definiert sich durch die schnellstmögliche Abarbeitung aller Anfragen am Server. Durch den Betrieb als Multithreaded-Server [TS06, S. 77 ff.] wird ein höchstmöglicher Nutzungsgrad des Servers erreicht. Hierbei wird der Server in einem Hauptthread 2 ausgeführt und für jeden verbundenen Client wird ein extra Thread erstellt. Alle verbundenen Clients sind somit voneinander unabhängig und können bestimmte Dienste in Anspruch nehmen ohne auf andere Clients warten zu müssen. Die Effektivität definiert sich durch die fehler- und konfliktfreie Verarbeitung aller Anfragen. Durch die gegebene Effizienz muss für die Effektivität ebenfalls ein akkurates Verfahren eingesetzt werden. Hierfür wird eine geeignete Kontrolle der Nebenläufigkeit (siehe 4.3) verwendet, um Konflikte bei den Datenzugriffen und den damit einhergehenden fehlerhaften Ausführungen der Anfragen zu vermeiden. Weiterhin wird durch die Überprüfung aller möglichen Fehlerquellen, welche durch Anfragen und Befehle von einem Client ausgehen können, sichergestellt, dass die Clients den Server niemals zum Absturz oder Stillstand bringen können. Das Client-Server Modell wird im derzeitigen Stand mit dem Request/Response -Mechanismus [S. 310][MBW08], welcher der Standardvariante des Client-Pull -Modus (siehe auch 8.2.2) gleicht, betrieben. Dieser stellt eine auftragsorientierte synchrone Kommunikationsform [S. 310 f.][mbw08] dar. Der Server ist hierbei solange passiv, bis ein Client aktiv wird und eine Anfrage an den Server sendet. Durch den Kommunikationsbeginn des Clients wird 2 Thread: Ein Thread ermöglicht die nebenläufige Ausführung weiterer Prozesse neben dem Hauptprogramm

22 3 Client-Server Modell 16 der Server aktiviert und leitet die weiteren Schritte für die Verarbeitung der Anfrage ein. Ein Server kann somit niemals von sich aus Kontakt mit den Clients aufnehmen. Dies hat den Nachteil, dass ein Client somit erst bei dem Versuch der Kontaktaufnahme bemerkt, ob der Server noch erreichbar ist oder nicht. Ein Vorteil hierbei ist jedoch, dass auf den Clients kein extra Thread laufen muss, welcher den Eingangsstrom überwacht und auf ankommende Nachrichten des Servers überprüft. Hierdurch kann der Programmcode der Clients einfach und kompakt gehalten werden. Eine Kommunikationsform, in welcher der Server auch Daten direkt an die Clients versenden kann ohne einen Request zu empfangen wird im Abschnitt beschrieben. Ein Server wird meistens im Service Mode betrieben, welcher sich im Hintergrund des Systems befindet und somit für den Benutzer nicht sichtbar ist. Eine direkte Verwaltung des Servers ist hiermit aber nicht möglich. Um eine möglichst hohe Flexibilität für den Einsatz des Servers zu gewährleisten steht in BaseX die Auswahl zwischen zwei Servermodi zur Verfügung. Bei der interaktiven Variante des Servers können Befehle direkt in die Konsole des Servers eingegeben und ausgeführt werden Aufbau des Servers Der Server ist, wie das zu Grunde liegende Datenbanksystem BaseX, in Java entwickelt und ist zusätzlich zur lokalen Variante von BaseX in das Gesamtsystem eingepasst. Eine Instanz des Servers besteht aus mehreren Komponenten. Der Aufbau des Servers und das Zusammenspiel der verschiedenen Komponenten ist in Abbildung 3.2 dargestellt. Beim Start des Servers wird ein Server-Socket erstellt, welcher auf eingehende Verbindungen von Clients wartet. Weiterhin wird ein Kontext erstellt, welcher die Hauptkomponente des Servers darstellt. In diesem Kontext werden die gesamten Komponenten initialisiert und somit der Hauptkontext erstellt. Die verbundenen Clients erhalten einen davon erbenden Unterkontext, welcher den Zugriff auf die Komponenten des Hauptkontexts ermöglicht. Die Methoden der einzelnen Komponenten können somit zentral über den Kontext aufgerufen werden. Nachfolgend werden die Komponente beschrieben, welche über den Kontext verwaltet werden: Properties (Eigenschaften der Instanz): In der Properties-Klasse werden die Attribute wie Port, Host für den Server und weitere Einstellungen der Client-Instanzen festgelegt und gespeichert. Die weiteren Einstellungen bestehen aus verschiedenen Optionen, wie z.b. der automatischen Erstellung der verschiedenen Indexstrukturen (Text Index, Attribut Index etc.) oder der Sprachoption, welche auf verschiedenste Sprachen (Englisch, Deutsch, Italienisch etc.) eingestellt werden kann. Die Einstellungen können während der Verwendung jedes Clients geändert und an die jeweiligen Bedürfnissen angepasst werden. Datenpool: Der Datenpool (siehe 5.2) ist für die Organisation aller Zugriffe auf die am System vorhandenen Datenbanken zuständig. Er dient somit als zentraler

23 3 Client-Server Modell 17 Zugriffspunkt für alle durch die Clients eintreffenden Datenabfragen auf die am Datenbanksystem registrierten Datenbanken. Sessions (Client-Server Verbindungen): In der Sessions-Klasse werden alle Client- Server Verbindungen gespeichert und verwaltet. Bei der Anmeldung eines Client wird der jeweilige ServerProzess der Sessions-Liste hinzugefügt und bei der Abmeldung wieder aus der Liste entfernt. Der Administrator hat mit der Liste der Sessions stets einen guten Überblick über alle am Server angemeldeten Clients und kann diese direkt aus der Liste entfernen, um somit gezielt Clients am Server abzumelden. Monitor: Der Monitor (siehe 4.3.2) ist für die Steuerung der nebenläufigen Transaktionsausführung zuständig und wird von jedem auszuführenden Befehl durchlaufen. Users: Mit der Users-Klasse werden alle am Server registrierten Benutzer und ihre Berechtigungen verwaltet (siehe 6). Log: Der Server und die aktiven ServerProzesse haben einen gemeinsamen Zugriff auf eine Log-Klasse, mit der die empfangenen Anfragen und die damit verbundene Ausführung des Prozess auf dem Server in eine Protokolldatei (siehe 6.4) geschrieben werden. Für jede Verbindung von einem Client zum Server wird ein ServerProzess (Thread des Clients am Server) erstellt, in der die Kommunikation zwischen Client und Server und die Befehlsausführung auf dem Server durchgeführt wird. Ein Server kann hierbei beliebig viele Verbindungen zu einem Client haben. Ein ServerProzess kann jedoch nie ohne einen laufenden Server existieren. Als Datenreferenz ( Data ) wird im Kontext des ServerProzesses stets die geöffnete Datenbank des Clients gesetzt. Falls keine Datenbank geöffnet ist, bleibt die Datenreferenz leer und alle Abfragen ohne Dokument-Referenz werden mit einer Fehlermeldung abgebrochen. Bei der Instanziierung eines ServerProzesses wird in der Kontext-Klasse eine neue Properties- Klasse erstellt um die jeweiligen eigenen Eigenschaften des Clients zu verwalten. So kann jeder Client seine eigene Konfiguration erstellen und speichern. In jedem Kontext wird als Attribut der angemeldete Benutzer gesetzt, um somit die Verwaltung der Zugriffe zu erleichtern, da die Überprüfung der Berechtigungen stets nur auf diesen Eintrag zurückgreifen muss. Als Benutzer im Kontext des Servers ist immer der Root-Administrator standardmäßig konfiguriert. Im ServerProzess wird bei der Befehlsausführung zwischen der standardmäßigen ( standard- Methode ) Durchführung und der iterativen ( iterate-methode ) Ergebnisabfrage unterschieden. Dies wird je nach erhaltener Anfrage vom Client am Server ausgewählt und gestartet. In einem ServerProzess können hierbei mehrere iterative Abfragen ( QueryProzess ) gleichzeitig bestehen. Die zugehörige Identifikationsnummer für die Verwaltung der Anfragen mit iterativer Ergebnisabfrage wird bei Erstellung des ServerProzesses mit null initialisiert und bei jeder ankommenden Anfrage um eins erhöht. So ist diese Nummer stets eindeutig

24 3 Client-Server Modell 18 und die Identifikation des richtigen QueryProzesses für die Anfrage immer gewährleistet. Alle aktiven QueryProzesse werden in einer Liste im zugehörigen ServerProzess verwaltet. Beim Beenden einer Anfrage oder einer Zeitüberschreitung wird der QueryProzess aus der Liste entfernt und ist somit vom Client nicht mehr erreichbar. Abbildung 3.2: Klassendiagramm mit den Komponenten des Servers Prozessausführung Bei der Ausführung der am Server ankommenden Befehle werden mehrere Schichten sequentiell nacheinander durchlaufen. Hierbei gibt es je nach Befehl mehrere Verarbei-

25 3 Client-Server Modell 19 tungsschritte, welche zu einem Gesamtprozess zusammengefasst werden. In Abbildung 3.3 sind Beispiele für die Ausführung eines create und eines xquery Befehls dargestellt. Die Befehle können hierbei in verschiedene Gruppen eingeteilt werden. Bei einem Befehl der Gruppe mit Datenbankoperation, wie die Erstellung einer Datenbank, die Veränderung oder die Abfrage von Daten, wird auf die dazu benötigten Daten über die IO-Schicht zugegriffen bzw. neue Daten über der IO-Schicht geschrieben. Die Datenbanken, welche durch die IO-Schicht angesprochen werden, besitzen hierbei jeweils eine Instanz von Meta- Daten, welche aus wichtigen Informationen über die Datenbank bestehen. Die einzelnen Schichten und die Komponenten der Verarbeitungsschritte werden im Folgenden beschrieben: Commandparser: Dieser Parser analysiert die am Server ankommende Nachricht und überprüft hierbei ob es sich um einen korrekten Befehl handelt. Falls dies der Fall ist wird der jeweilige Prozess erstellt und die damit einhergehenden weiteren Verarbeitungsschritte eingeleitet. Im Fehlerfall wird in dieser Schicht die Ausführung des Prozess abgebrochen und dies dem Client mit einer Fehlermeldung mitgeteilt. Autorisierung: Bei der Autorisierung werden die für die Ausführung benötigten Berechtigungen (siehe 6.2) mit denen für den Benutzer gesetzten Rechten verglichen. Falls die Rechte des Benutzers für die Ausführung nicht ausreichend sind, wird der Prozess hier abgebrochen und die entsprechende Fehlermeldung an den Client ausgegeben. Transaktionsmonitor: (siehe 4.3.2) In dieser Schicht wird überprüft, ob der Prozess sofort starten kann oder noch auf andere aktive oder weitere wartende Prozesse warten muss. Ausführungsschicht: Diese Schicht fasst die Komponenten, welche zur Ausführung des Prozesses benötigt werden zusammen. Diese werden im Folgenden näher beschrieben: Builder: Der Builder ist die grundlegende Instanz für das Erstellen von Datenbanken. Bei der Erstellung einer Datenbank werden mehrere Schritte durchlaufen. Als erstes wird das definierte XML-Dokument oder die angegebene XML-Zeichenkette mit dem XMLParser auf seine Gültigkeit hin analysiert. Hierbei wird mittels des XMLScanner die XML-Eingabe eingelesen und die einzelnen Bestandteile an den XMLParser übergeben. Nach dem Parsen wird die Datenbank mit den Daten vom XMLParser durch den Builder erstellt. Die Datenbanken können wahlweise temporär im Arbeitsspeicher ( Memdata ) gehalten oder auf die Festplatte ( Diskdata ) geschrieben werden. Das Speichern und der Zugriff auf die Datenbanken findet immer über die IO-Schicht statt. Der Zugang zu den Daten wird durch die verschiedenen Zugriffsmethoden der Dateninstanz durchgeführt. QueryProzessor: Der QueryProzessor ist für die korrekte Ausführung der XQuery Anfragen zuständig. Hierdurch wird die fehlerfreie Abarbeitung der Anfrageschritte (Updates und Lesezugriffe) gewährleistet. Vor Beginn der Ausführung

26 3 Client-Server Modell 20 wird ein QueryContext erstellt, über welchen die weiteren Verarbeitungsschritte ausgeführt werden. Als erster Schritt wird die Anfrage mit dem QueryParser auf ihre Korrektheit überprüft. Hierbei wird die Abfrage auf die komplette XQuery Syntax hin kontrolliert und bei einem Fehler nicht zur Ausführung frei gegeben. Anschließend wird die Anfrage kompiliert und optimiert. Bei der Kompilierung und Optimierung werden die verschiedenen Verarbeitungsschritte der Anfrage geordnet und bei Bedarf durch schnellere Anfrageausdrücke ersetzt, um die Ausführungszeit der Anfrage zu optimieren. Nach diesen Schritten beginnt die Auswertung der Anfrage und der Zugriff über die IO-Schicht auf die Datenbank um das Ergebnis abzufragen oder die veränderten Daten zu schreiben. Hieraus resultiert eine Ergebnisinstanz, welche dann in Form einer Zeichenkette an den Client zurückgegeben wird. Abbildung 3.3: Schichten und Komponenten der Prozessausführung am Server Quelle: Angelehnt an [WV01, S. 28] 3.4 Client Ein Client ist ein Programm, welches Dienste eines Servers in Anspruch nimmt und die daraus resultierenden Ergebnisse verarbeitet. In BaseX wird der Client als so genannter Thin Client [TS06, S.41 f.] betrieben, welcher drei Aufgaben übernimmt. Die Aufgaben

27 3 Client-Server Modell 21 bestehen aus der Definition der Anfrage, der Anfrageübermittlung an den Server und der anschließenden Ergebnisverarbeitung. Hierbei kann der Client durch verschiedene Implementationsarten realisiert werden. Jede Anwendung kann somit Clients für die eigenen Bedürfnisse konzipieren. Für den Einsatz mit dem im Datenbanksystem BaseX definierten Server führt ein Client standardmäßig immer den folgenden Arbeitsablauf aus: 1. Erstelle eine Verbindung zum Server mit Hostnamen und Port. Empfange den aktuellen Zeitstempel des Servers und sende den Benutzernamen inklusive der für die Authentifizierung am Server benötigten Kombination aus Passwort und Zeitstempel an den Server zurück. 2. Sende einen Befehl mit dem auszuführenden Dienst an den Server. 3. Erhalte bei erfolgreicher Ausführung das Ergebnis oder ansonsten die Fehlermeldung. 4. Schließe die Verbindung, oder fahre mit der Verwendung des Clients fort. Hierbei wird deutlich, wie der Client den Kontakt initiiert und dem Server die gesamte Verarbeitung überlässt. Nach der Ausführung der Anfrage wird der Client wieder aktiv und interpretiert die erhaltene Antwort. Dies ist als Standard definiert und so müssen alle Clients, welche Dienste des Servers in Anspruch nehmen wollen, diesen Standard einhalten. Die Ausführung einer XQuery Anfrage kann hierbei auf zwei Arten geschehen. Je nach Anwendungsszenario kann zwischen der Standardvariante (siehe Abbildung 3.8), in welcher das gesamte Ergebnis der Anfrage komplett auf einmal vom Server an den Client gesendet wird, oder der iterativen Variante ausgewählt werden. Durch das Senden eines Control-Codes als Anfangsbyte der Anfrage, kann der Client den Server dazu auffordern die iterative Variante der Ergebnisauslieferung durchzuführen. Hierbei bekommt der Client die einzelnen Ergebnisteile einzeln vom Server zurückgeliefert, bis er das gesamte Ergebnis erhalten hat. In Abbildung 3.9 ist dieses Szenario detailliert dargestellt. Um einen weit reichenden Einsatz des Servers zu ermöglichen, ist es wichtig Clients in verschiedenen Programmiersprachen anzubieten. So sind derzeitig Clients in zehn Programmiersprachen 3 vorhanden, welche alle nach dem definierten Standardschema arbeiten. Beispielsweise kann der Server somit durch die Implementierung eines Clients in PHP aus dem Webkontext 4 heraus angesprochen werden. Durch die Verwendung der verschiedenen Anfragevarianten können dann die erhaltenen Daten im Web bereit- und dargestellt werden. Implementierungen von Clients sind in allen Programmiersprachen möglich, welche über die Benutzung von Sockets verfügen. 3 aktuell implementierte Clientversionen: Java, Perl, Python, Ruby, PHP, C#, Visual Basic, Haskell, Rebol und Lisp 4 Beispiel siehe XQuery Live Demo

28 3 Client-Server Modell Aufbau des Clients Beim Start des Clients wird diesem der Host, Port, Benutzername und das Passwort übergeben. Mit dem Host und dem Port wird ein Socket erstellt, welcher für die Kommunikation einen Eingangs- wie auch einen Ausgangsstrom bereitstellt. Die Authentifizierung am Server wird mittels des Benutzernamen, des vom Server erhaltenen Zeitstempels und des Passworts durchgeführt. Falls dies erfolgreich ausgeführt werden konnte, startet die weitere Kommunikation mit dem Server. Im Fehlerfall wird an dieser Stelle abgebrochen und die Fehlermeldung ausgegeben. Das Klassendiagramm (Abbildung 3.4) stellt den fest definierten Aufbau eines Clients dar. Dieser Aufbau ist in allen implementieren Clients in den verschiedenen Programmiersprachen so umgesetzt und dies muss auch durch eventuelle Neuimplementierungen in anderen Programmiersprachen in dieser Form eingehalten werden. Andernfalls kann ein reibungsloser Ablauf bei der Kommunikation mit dem Server nicht garantiert werden. Für die standardmäßige Ausführung eines Befehls, muss die execute -Methode der Client- Klasse mit dem jeweiligen Befehl aufgerufen werden. Diese liefert dann bei erfolgreich durchgeführter Anfrage das Ergebnis bzw. bei fehlerhafter Anfrage die Fehlermeldung zurück. Eine weitere Methode der Anfrageausführung ist das Aufrufen der execute - Methode mit einem vordefinierten Ausgangsstrom. Hierbei wird das Ergebnis bzw. die Fehlermeldung direkt in den Ausgangsstrom geschrieben. Hierdurch wird ein nochmaliges Zwischenspeichern der Daten verhindert und somit die Ergebnisausgabe deutlich beschleunigt. Als Ausgangsstrom können hier z.b. die Standard Konsolenausgabe oder eine Datei, in welche die Daten dann geschrieben werden, definiert werden. Für die iterative Ergebnisabfrage, welche nur bei der Ausführung von XQuery Anfragen möglich ist, ist die Erstellung eines Query -Objekts notwendig. Dieses wird durch den Aufruf der query -Methode mit der auszuführenden XQuery Anfrage erstellt und dem Client zur Verwendung zurückgeliefert. Für das Query-Objekt wird am Server eine Identifikationsnummer erstellt, welche der Client empfängt und dieser Anfrage auf der Clientseite zuweist. Hierdurch können mehrere Query-Objekte am Client erstellt und verwendet werden. Durch die Erstellung eines Query-Objekts wird die Anfrage automatisch an den Server gesendet und die Anfrageverarbeitung gestartet. Das erste Teilergebnis wird hierdurch sofort vom Server an den Client gesendet. Dies hat den Vorteil, dass bei schreibenden Anfragen, welche nur ein leeres Ergebnis und keine Ergebnissequenz zurückliefern, die Ausführung sofort durchgeführt wird und nicht explizit auf den Aufruf einer weiteren Methode gewartet werden muss. Weiterhin wird somit das Standardkonzept des Iterators unterstützt, welches wie folgt definiert ist. Der Iterator, wird um die einzelnen Ergebnisteile der Anfrage zu erhalten, mittels der more -Methode auf das nächste Ergebnisteil bewegt und somit wird automatisch abgefragt, ob noch weitere Ergebnisteile am Server vorhanden sind. Die more -Methode sendet zur Identifikation der Anfrage am Server, die jeweilige Kennnummer des Query-

29 3 Client-Server Modell 23 Objekts als Startzeichen an den Server. Mit der next -Methode wird dann das jeweilige nächste Ergebnisteil zurückgeliefert. Um die Ausführung der Anfrage vorzeitig zu beenden, kann mittels der close -Methode das Query-Objekt geschlossen werden und somit die Ergebnisabfrage beendet werden. Abbildung 3.4: Klassendiagramm mit dem Aufbau eines standardmäßigen Clients 3.5 Client-Server Kommunikation Der Datenaustausch zwischen dem Server und den Clients basiert auf TCP/IP 5 -Sockets [Abt07, S. 106 ff.]. Als Sockets werden die Anschlüsse der Kommunikation auf der Serverwie auch der Clientseite bezeichnet. Der Aufbau der TCP-Verbindung wird wie in Abbildung 3.5 dargestellt durchgeführt. Auf der Seite des Servers wird ein so genannter Serversocket mit dem lokalen Hostnamen und einem definierten Port erstellt. Der Serversocket überprüft den Port auf eingehende Verbindungsanfragen und blockiert solange, bis sich ein Client mit dem Server verbindet. Bei einer eingehenden Verbindung werden die weiteren Schritte für diesen Client eingeleitet und der Serversocket versetzt sich wieder in den blockierenden Zustand. Auf der Clientseite wird ein Socket mit dem zu verbindenden Hostnamen und Port erstellt. 5 TCP/IP: Transmission Control Protocol/Internet Protocol [CDS74]: Verbindungsprotokoll für eine zuverlässige Kommunikation in verteilten Systemen.

30 3 Client-Server Modell 24 Hierdurch wird eine Verbindungsanfrage an den Server gesendet und bei erfolgreicher Kontaktaufnahme die Verbindung hergestellt. Für die weitere Kommunikation wird auf dem Server ein interner Socket, welcher einer Abzweigung des Serversockets ist, erstellt und dem Client zugewiesen. Hierbei wird ein Thread ( ServerProzess ) gestartet, welcher den Authentifizierungsprozess initialisiert. Bei erfolgreichem Login (siehe 6.3) erfolgt in diesem Thread und über den zugehörigen Socket dann die weitere Kommunikation zwischen dem Server und dem Client. Abbildung 3.5: Aufbau einer TCP-Verbindung zwischen einem Client und dem Server Quelle: [Abt07, S. 109] Für die Ausführung der Kommunikation gibt es zwei Interaktionsarten [Abt07, S. 9 f.]. In BaseX wird die synchrone Kommunikation (siehe Abbildung 3.6) eingesetzt. Die synchrone Kommunikation sieht vor, dass ein Client solange wartet bis er das Ergebnis seiner Anfrage vom Server zurück erhalten hat. Im Gegensatz hierzu kann bei der asynchronen Kommunikation der Client während der Wartezeit weiterarbeiten und erhält dann das Ergebnis vom Server, wenn es diesem vorliegt. Für dieses Szenario (siehe auch Abschnitt

31 3 Client-Server Modell ) müsste der Client als Multithreaded -Client konzipiert werden, da dieser in einem Thread auf den Eingangstrom des Servers reagieren müsste und in einem weiteren Thread weitere Arbeiten verrichten könnte. Da die Programmierung der Clients so einfach und kompakt wie möglich gehalten ist, ist diese Form der Clients im derzeitigen Stand nicht implementiert. Weiterhin ist die Implementation von Multithreaded Programmen nicht in allen Programmiersprachen auf einfache Art und Weise möglich. Abbildung 3.6: Synchrone Kommunikation zwischen einem Client und dem Server Quelle: [TS06, S. 37] Die gesamte Kommunikation zwischen dem Server und den Clients basiert auf Aufträgen, welche von den Clients an den Server gesendet werden. Diese Aufträge bestehen immer aus Nachrichten, welche die auszuführenden Aufgaben für den Server enthalten. Damit diese Kommunikation konfliktfrei abläuft, ist der Aufbau der Nachrichten fest definiert. Eine Nachricht kann aus mehreren Teilen bestehen. Jedes Teil wird durch den Einsatz des 0-Bytes 6 als Trennungs- bzw. Abschlusszeichen der einzelnen Teile der Nachrichten gekennzeichnet. Dies gewährleistet, dass beide Kommunikationsseiten stets erkennen, wenn ein Teil einer Nachricht vollständig gesendet wurde. Zusätzlich ist es für die Clients wichtig, um die einzelnen Nachrichtenteile durch die Identifikation des Trennungszeichen zu erkennen. Weiterhin werden so genannte Control-Codes als Markierung für die verschiedenen Ausführungsdetails und als Success-Flag, welches den Erfolg der Ausführung kennzeichnet, verwendet. Da bei der gegenseitigen Kommunikation zwischen Server und Client nur textuelle Daten ausgetauscht werden und keine Binärdaten, können die Control-Codes nie in versendeten Zeichenketten vorkommen. Somit kann die Überprüfung auf die Control-Codes auf beiden Kommunikationsseiten konfliktfrei durchgeführt werden. Dieses Konzept hat 6 Bei einem 0-Byte handelt es sich um ein Byte mit dem Wert 0, welches in allen gängigen Programmiersprachen verfügbar ist. Dieses Byte kann nie in gesendeten textuellen Anfragen bzw. Ergebnissen vorkommen und ist somit immer eindeutig identifizierbar.

32 3 Client-Server Modell 26 den Vorteil, dass hierdurch die Funktionalität des Servers nicht nur durch registrierte Befehle erweitert, sondern auch durch den Einsatz der Control-Codes noch weiter spezifiziert werden kann. So kann dies z.b. bei der Umsetzung des Benachrichtigungstrigger-Konzeptes (siehe 8.2.2) verwendet werden. Die Nachrichten können in zwei Typen unterschieden werden: Servernachricht: Eine Nachricht die vom Server gesendet wird besteht immer aus drei Teilen, welche durch den Einsatz des 0-Byte voneinander getrennt werden. Hierbei muss man zwischen korrekten und fehlerhaften Anfragen unterscheiden. Bei korrekt ausgeführten Anfragen besteht der erste Teil immer aus dem Ergebnis. Der zweite Teil kann optional aus Prozessinformationen bestehen oder leer bleiben. Die Prozessinformationen enthalten unter anderem die Ausführungszeiten der einzelnen Prozessschritte, die Anzahl der Ergebnisse, die gesamte Ausführungszeit und den benötigten Speicherbedarf der Ausführung. Den letzten Teil bildet das 0-Byte als Control-Code, welcher für die fehlerfreie Ausführung der Anfrage steht. Bei fehlerhaften Anfragen ist der Ergebnisteil immer leer. Der zweite Teil der Nachricht beinhaltet in diesem Fall die jeweilige Fehlermeldung vom Server. Den abschließenden Teil bildet ein 1-Byte, welches den Control-Code für eine fehlerhafte Ausführung darstellt. Bei der iterativen Methode muss hierbei das 1-Byte vor der Fehlermeldung gesendet werden, da es sich bei einem leeren Ergebnis auch um das Ende der Anfrage handeln könnte und somit danach überprüft werden muss, ob es sich um eine Fehlermeldung handelt. Diese Art von Fehlermeldung wird bei jedem am Server auftretenden Fehler vom Server an den Client versendet. Die verschiedenen Server-Nachrichten der Standard- und der iterativen Anfrageausführung sind in Abbildung 3.7 zusammengefasst dargestellt. Clientnachricht: Eine vom Client versendete Nachricht besteht standardmäßig immer nur aus einem Segment, welches den Befehl mit den benötigten Parametern und das abschließende 0-Byte beinhaltet. Das 0-Byte ist hierbei wiederum der Control- Code, welcher dem Server signalisiert, dass das gesamte Kommando empfangen wurde. Falls der Client die Ausführung der iterativen Ergebnisabfrage wählt, muss vor der XQuery Anfrage ein zusätzlicher Control-Code an den Server gesendet werden, damit dieser erkennt, welche Variante ausgeführt werden soll. Hierbei können nur XQuery Anfragen verwendet werden, da es bei den übrigen Befehlen nur die Standardausführung am Server gibt. Bei dieser Variante kann der Client entscheiden, ob das nächste Ergebnisteil angefragt, oder ob die Anfrageausführung beendet werden soll. Dies wird dem Server durch das Senden eines Control-Codes signalisiert. In Abbildung 3.7 sind die verschiedenen Nachrichtenvarianten, welche vom Client versendet werden, zusammengefasst dargestellt.

33 3 Client-Server Modell 27 Abbildung 3.7: Zusammenfassung der verschiedenen Datenströme zwischen Server und Client Das Versenden der Nachrichten auf beiden Seiten wird durch die von den Sockets bereitgestellten Eingangs- und Ausgangsströme ausgeführt. Jeder Socket bietet hierbei einen Datenstrom für das Abhören der eingehenden Nachrichten und einen Datenstrom für das Versenden der Nachrichten an. Da es beim Austausch der Nachrichten wichtig ist, immer einheitliche Zeichen in den Zeichenketten zu haben, werden alle Zeichenketten standardmäßig in UTF-8 7 kodiert versendet. Gründe hierfür sind, dass die UTF-8 Kodierung die Standardkodierung in Netzwerk- und Internetstreams ist und eine sehr kompakte Darstellung der Zeichenketten bietet. Weiterhin ist es wichtig, dass die Clients unabhängig von ihrem Betriebssystem und eingesetzter Programmiersprache stets dieselbe Darstellung der Daten (insbesondere Sonderzeichen) erhalten. Da die UTF-8 kodierten Zeichenketten von allen Systemen interpretiert werden können ist dies hierdurch gegeben. Bei Abschluss der Kommunikation zwischen einem Client und dem Server, meldet sich der Client beim Server ab und schließt somit auf seiner Seite den Socket. Die Abzweigung des Serversockets am Server wird ebenfalls geschlossen und der Client aus der Liste am Server entfernt. Die Socketverbindung wird also nur geschlossen, wenn der Server beendet wird, der Server die Verbindung zu einem Client abbricht oder der Client sich abmeldet. Dies hat den Vorteil, dass nicht für jede Anfrage eine neue Socketverbindung erstellt werden muss. Nachteilig kann sich auswirken, dass es sehr viele inaktive Clients an einem Server geben kann, welche alle eine Socketverbindung offen haben, aber keine Abfragen darüber senden. 7 UTF-8 steht für 8-Bit UCS Transformation Format. Hierbei handelt es sich um einen Standard bei der Verwendung von Unicode [GS08, S. 13 ff.].

34 3 Client-Server Modell Nachrichtenaustausch der Standardausführung Die Standardausführung des Nachrichtenaustauschs sieht vor, dass der Client stets das gesamte Ergebnis einer Anfrage auf einmal ausgeliefert bekommt. Dies ist zum Beispiel von Vorteil, wenn der Benutzer das Gesamtergebnis der Anfrage in einer Zeichenkette benötigt, um die Zeichenkette z.b. als neue XML-Datei abzuspeichern oder anderweitig zu verarbeiten. Bei dieser Ausführungsform wird nur zu Beginn der Ausführung die Anfrage auf ihre Korrektheit überprüft und dann entweder ausgeführt oder abgebrochen. In Abbildung 3.8 sind Beispiele für eine fehlerhafte und eine korrekte Ausführung zweier Anfragen dargestellt. Die Kommunikation zwischen Client und Server erfolgt immer mit den definierten Nachrichten. Der Ablauf der beiden Beispiele gestaltet sich wie folgt. Der Client mit der Nummer eins sendet eine korrekte XQuery Anfrage an den Server. Während der Server die erste Anfrage ausführt, sendet der Client mit der Nummer zwei eine fehlerhafte Anfrage an den Server. Anschließend antwortet der Server beiden Clients mit den aus der Ausführung resultierenden Nachrichten. Alle Nachrichten werden in der Abbildung in UTF-8 kodiert dargestellt. Die in grau markierten Bytes stellen die Endbytes der jeweiligen Zeichenketten der Nachrichten dar. Das in grün bzw. rot dargestellte Byte ist die Markierung für eine erfolgreiche bzw. fehlerhafte Ausführung der Anfrage. Die optionalen Prozessinformationen sind mit (PI) gekennzeichnet. Abbildung 3.8: Sequenzdiagramm einer erfolgreichen und einer fehlgeschlagenen Anfrage

35 3 Client-Server Modell Nachrichtenaustausch bei der Ergebnisabfrage mittels Iterator Die Variante der Ergebnisabfrage des Clients am Server mittels eines Iterators gibt dem Client die Möglichkeit, einzelne Teile des Gesamtergebnis der Anfrage getrennt voneinander vom Server zu empfangen. Durch den Iterator kann mit Hilfe eines Zeigers die Liste der Ergebnisse abgelaufen werden und diese der Reihenfolge nach am Client in Empfang genommen werden. Dies hat den Vorteil, dass der Client entscheiden kann wie viele Teile des Ergebnis empfangen werden sollen. Hierdurch kann sich die zu übertragende Datenmenge zwischen Client und Server deutlich verringern. Durch das Beenden der Anfrage des Clients wird dem Server signalisiert, dass er keine weiteren Ergebnisteile mehr an den Client senden muss und er die Anfrageausführung beenden kann. Weiterhin kann der Client entscheiden, welche Ergebnisteile für das Gesamtergebnis relevant sind und so die unerwünschten Ergebnisteile einfach nach Empfang ausschließen. Die Kommunikation einer erfolgreichen Anfrage zwischen dem Server und dem Client läuft hierbei nach dem definierten Schema ab, welches in Abbildung 3.9 dargestellt ist. Hierbei wird die Anfrage 1 to 2, welche zu zwei Ergebnisteilen führt, an den Server gesendet. Der Server erstellt für jede empfangene Anfrage mit iterativer Ergebnisausgabe einen QueryProzess, in welchem die Ausführung der Anfrage und die Bereitstellung der Ergebnisteile stattfindet. Für jeden QueryProzess wird eine Identifikationsnummer erstellt, welche diesen eindeutig identifiziert. Nach erfolgreichem Start der Anfrage am Server, wird die Nummer mit angehängtem Erfolgsbyte an den Client übertragen. Über die vom Server empfangene Identifikationsnummer der Anfrage kann der Client die weiteren Ergebnisteile beim Server anfragen. Die Ergebnisteile werden nach jeweiliger Anforderung vom Client nacheinander vom Server an den Client gesendet. Wenn am Server keine Ergebnisteile mehr vorhanden sind, sendet dieser ein leeres Ergebnis mit angehängtem Erfolgsbyte als Ende an den Client, um diesen über den Endzustand zu informieren. Dies ist notwendig, da es auch während der Durchführung einer Anfrage im iterativen Modus zu Problemen kommen kann und diese dann mit einer Fehlermeldung abgebrochen wird. Trotz anteilig richtiger Ergebnisse der Anfrage wird hierbei die komplette Anfrage von XQuery als fehlerhaft angesehen. Eine von Beginn an fehlerhafte Anfrage erhält vom Server nur die Fehlermeldung zurück. Bei beiden Fällen des Ausführungsabbruchs wird eine Fehlernachricht an den Client versendet, um diesen hierüber in Kenntnis zu versetzen. Ein Problem, welches während der Ausführung einer Anfrage auftritt wird im Folgenden Beispiel dargestellt: Anfrage: //x[text() = 123] Beispieldokument: <x> <y>123</y> // Integerwert: ok <y>123</y> // Integerwert: ok <y>abc</y> // String: Fehler, Anfrage wird beendet <y>123</y> // wird nicht erreicht </x>

36 3 Client-Server Modell 30 Hierbei werden nur die ersten beiden Ergebnisteile an den Client zurückgeliefert (siehe Kommentare im Beispieldokument) und bei der Überprüfung des dritten Knoten, da es sich bei diesem um keinen Integer-Wert handelt, abgebrochen. Ein weiteres Problem kann bei der Dauer des Abrufens der einzelnen Ergebnisteile entstehen. Hierbei könnte es passieren, dass ein Client den Server ewig blockiert, da er nicht alle Ergebnisteile vom Server sofort empfängt. Hierfür ist ein Zeitüberschreitungsmechanismus vorhanden, welcher die Kommunikation nach einer definierten Zeitspanne abbricht. Der Client erhält in diesem Fall bei der nächsten Anfrage nach einem Ergebnisteil einen Timeout -Fehler. Da solche Fälle abhängig von der individuellen Benutzung sind, ist der Zeitüberschreitungsmechanismus standardmäßig deaktiviert. Durch das Setzen der Zeitspanne in den Properties wird der Mechanismus am Server aktiviert und auf dem Server gespeichert. Die Zeitspanne wird nun für alle weiteren Abfragen verwendet bis sie wieder deaktiviert wird. Bei schreibenden Transaktionen gibt es in diesem Hinblick keine Konflikte, da diese keine Ergebnisse zurückliefern und somit in der Standardmethode, wie auch der iterativen Variante der Ergebnisauslieferung gleich abgearbeitet werden. Abbildung 3.9: Sequenzdiagramm einer erfolgreichen Anfrage mit iterativer Ergebnisabfrage

37 Kapitel 4 Transaktionsmanagement Dieses Kapitel beschreibt das theoretisch entwickelte und in der Praxis in BaseX eingesetzte Transaktionsmanagement. Als Vorbild sind hierbei die traditionellen relationalen Datenbanksysteme anzusehen. Die Anforderungen des Transaktionsmanagement sind jedoch an die Gegebenheiten von XML-Datenbanken (insbesondere BaseX) angepasst. Zu Beginn des Kapitels wird der Begriff Transaktion definiert und die Eigenschaften von Transaktionen beschrieben. Anschließend wird der Mechanismus der Nebenläufigkeitskontrolle mit der verwendeten Lockingvariante und dem entsprechenden Sperrprotokoll erläutert. Hierbei werden die bei der Nebenläufigkeitskontrolle auftretenden Probleme und Anomalien behandelt. Das Kapitel schließt mit der Beschreibung von alternativen Lockingvarianten, mit welcher eine erhöhte Parallelität der Anfragen am Server erreicht werden könnte. 4.1 Definition einer Transaktion Die Bezeichnung Transaktion ist ein Überbegriff für eine Sequenz von Aktionen, welche auf Daten von Datenbanken ausgeführt werden. Hierbei kann zwischen schreibenden und lesenden Aktionen unterschieden werden. Die verschiedenen Befehle von XQuery stellen bei XML-Datenbanken die Grundlage für Transaktionen dar. In XQuery Update umfasst eine Transaktion auf eine Datenbank stets eine lesende und eine schreibende Teilaktion. Der lesende Teil definiert das zu verändernde Objekt und der schreibende Teil die damit durchzuführende Änderung. Jeder am Server ankommende Befehl wird als eine Transaktion angesehen. XQuery arbeitet hierbei nach dem Prinzip, die komplette XQuery Anfrage immer als eine Gesamttransaktion zu betrachten. Der Beginn einer Transaktion wird stets mit dem Start der Ausführung auf dem Server gesetzt. Das Ende der Transaktion wird durch das Ende der Ergebnis- bzw. Fehlerübertragung vom Server an den Client bestätigt. Transaktionen mit XQuery können in zwei Arten unterschieden werden. Hierbei gibt es einzelne sowie zusammenhängende Transaktionen. Eine einzelne Transaktion besteht stets aus einer Schreib- und zwingend einer bzw. optional mehreren Leseaktionen. Die zusammenhängenden Transaktionen dagegen bestehen aus mehreren schreibenden Transaktionen (und Leseaktionen), welche nicht zwangsläufig miteinander in Verbindung stehen, 31

38 4 Transaktionsmanagement 32 aber dennoch in einer Anfrage vom Client an den Server gesendet werden. Diese werden ebenfalls zu einer Gesamttransaktion zusammengefasst. In den folgenden Beispielen werden die beiden Fälle der XQuery Anfragen näher erläutert: Einzelne Transaktion: insert node <xml>new</xml> into root() Dies ist eine einzelne Transaktion, welche die lesende Aktion (Auswahl des Wurzelelements) und die schreibende Aktion (Einfügen eines Knoten) auf ein Dokument ausführt. Zusammenhängende Transaktion: insert node <xml>new</xml> into root(), delete node root()/xml Hierbei werden das erste Update (Einfügen eines Knoten) und das zweite Update (Löschen eines Knoten) zu einem Gesamtprozess am Server zusammengefasst. D.h. der Transaktionsmonitor wird für die gesamte Anfrage nur einmal durchlaufen, so dass hierbei keine Konflikte auftreten können. Bei der Spezifikation von XQuery Update gibt es eine festgelegte Definition der Abarbeitung der Updateoperationen. Somit wird die Reihenfolge der einzelnen Aktualisierungsaktionen in der Anfrage nicht beibehalten, sondern nach der Definition von XQuery Update abgearbeitet. Bei einer Konkatenation von Transaktionen können keine schreibenden und lesenden Transaktionen vermischt werden. Dies bedeutet, dass wenn eine der Transaktionen als schreibend gekennzeichnet wird und somit kein Ergebnis zurückliefert alle in der Gesamttransaktion enthaltenen (mit Komma getrennten) Transaktionen auch schreibende Transaktionen sein müssen. XQuery lässt hierbei also keine Transaktionen zu, welche ein Update ausführen und zusätzlich in einem weiteren Transaktionsteil Werte als Ergebnis zurückliefern. Zusätzlich zu den Transaktionen, welche mit XQuery ausgeführt werden, gibt es noch weitere Datenbankfunktionen, welche als Transaktion angesehen werden (siehe Abbildung 6.1). Alle diese Datenbankfunktionen können durch die vom System definierten Befehle ausgeführt werden. Diese Befehle können nicht kombiniert werden und sind somit nur einzeln vom Client am Server aufrufbar. Bei der Analyse der Befehle am Server wird durch den CommandParser entschieden, um was für einen Befehl es sich handelt. Die diversen Befehle sind hierbei fest als schreibend oder lesend definiert. Bei der Analyse eines XQuery-Befehls wird die XQuery Abfrage auf die Schlüsselwörter von XQuery Update kontrolliert und bei Fund eines solchen als schreibend gekennzeichnet. Falls kein Schlüsselwort bei der Kontrolle der Abfrage gefunden wird, wird die Abfrage als lesend eingestuft. Diese Kennzeichnung ist für den weiteren Ablauf der Prozessausführung unerlässlich.

39 4 Transaktionsmanagement Transaktionseigenschaften Die vier grundlegenden Eigenschaften von Transaktionen in relationalen Datenbanksystemen sind Atomarität ( Atomicity ), Konsistenz ( Consistency ), Isolation und Dauerhaftigkeit ( Durability ) (kurz: ACID [LBK01, S ]). Diese Merkmale sollten auch durch das Transaktionsmanagement in XML-Datenbanken gewährleistet werden. In den weiteren Abschnitten werden die einzelnen Transaktionseigenschaften beschrieben und im Hinblick auf XML-Datenbanken bzw. BaseX näher erläutert Atomarität Die Eigenschaft der Atomarität besagt, dass eine Transaktion entweder komplett ausgeführt oder aber ohne Effekte an der Datenbank zu hinterlassen abgebrochen wird. Dies bedeutet, dass die Datenbank bei einem Abbruch der Transaktion oder einem Fehler bei der Ausführung wieder in den vorherigen Zustand zurückversetzt werden muss. Um die Eigenschaft der Atomarität zu gewährleisten sind in BaseX zwei Mechanismen integriert. Der erste Mechanismus ist dadurch definiert, dass Transaktionen auch dann bis zum Ende ausgeführt werden, wenn der jeweilige Client die Verbindung zum Server unterbricht. Der Client hat somit keine Möglichkeit eine schreibende Transaktion während der Ausführung abzubrechen, um somit durch die eventuell schon ausgeführten Updates einen inkonsistenten Datenbankzustand zu verursachen. Weiterhin ist das Beenden eines Servers nur lokal möglich, so dass ein Client auch diesen während einer Transaktion nicht stoppen kann. Ein Abbruch des Servers während einer Transaktion führt unweigerlich zu einem inkonsistenten Datenbestand. Eine Lösung hierfür ist es, ein so genanntes Rollback (siehe 8.2.3) zu implementieren, welches den alten Datenbankzustand, bei Abbruch einer Transaktion am Server, wieder herstellen kann. Diese Funktion ist in der aktuellen Version von BaseX noch nicht vorhanden, so dass die Atomarität für Extremfälle, wie einen Absturz des Servers oder sonstige Systemausfälle nicht gewährleistet werden kann. Eine weitere Funktion, welche zur Eigenschaft der Atomarität beiträgt, ist die Analyse der Transaktionen. Ankommende Anfragen werden hierbei am Server geparst und auf Fehler überprüft. Falls sich herausstellt, dass die Anfrage fehlerhaft ist wird die Transaktion erst gar nicht gestartet und vor der Ausführung mit der jeweiligen Fehlermeldung abgebrochen. Hierdurch wird verhindert, dass Transaktionen erst während der Ausführung auf Fehler bzw. Konflikte stoßen und abbrechen. Transaktionen werden somit im Normalfall immer vollständig abgearbeitet. Die Anfragesprache XQuery besitzt eine weitere Eigenschaft, welche zur Atomarität bei schreibenden Transaktionen beiträgt. Bei der Ausführung einer Transaktion, werden alle darin befindlichen Updates in eine Updateliste gespeichert. Diese werden zu einem definierten Zeitpunkt der Anfrageausführung alle auf einmal ausgeführt und die Datenbank somit atomar aktualisiert. Falls eine der in der Transaktion enthaltenen Updateoperationen fehlerhaft ist, wird die gesamte Ausführung der Transaktion verhindert.

40 4 Transaktionsmanagement Konsistenz Das Kriterium der Konsistenz beschreibt, dass eine Datenbank nach der Ausführung einer Transaktion wieder in einem konsistenten Zustand vorhanden sein muss. Diese Funktion wird wiederum durch die Analyse der Updateanfragen übernommen. Durch die Analyse werden nicht nur fehlerhafte Anfragen, sondern auch Anfragen, welche gegen die Wohlgeformtheit 1 eines XML-Dokumentes verstoßen herausgefiltert. Da die Transaktion vor der endgültigen Ausführung der Updates abgebrochen wird, kann es nie zu Verstößen gegen die Wohlgeformtheit in der XML-Datenbank kommen. Dies hat den Vorteil, dass bei jeder Transaktion nur der in der Abfrage definierte Teil überprüft und nicht die komplette Datenbank nach dem Update neu analysiert werden muss. Nachfolgend wird ein Beispiel dargestellt, bei dem wiederholt versucht wird an der selben Stelle in der Datenbank ein Attribut mit demselben Namen einzufügen: Beispieldokument: <xml>example</xml> XQuery Update 1: insert node attribute id{'1'} into root()/xml Ergebnis <xml id='1'>example</xml> XQuery Update 2: insert node attribute id{'2'} into root()/xml Ergebnis Duplicate attribute 'id'. Die Konsistenz wird in relationalen Datenbanken zusätzlich durch die Einhaltung von Integritätsbedingungen, welche durch die verschiedenen Schlüsselbeziehungen zwischen den einzelnen Tabellen entstehen, definiert. Dies kann in XML-Datenbanken nur durch explizites Einbinden von einer DTD in das XML-Dokument ermöglicht werden. Hierdurch könnte man das XML-Dokument nicht nur auf die Wohlgeformtheit, sondern auch auf die Gültigkeit 2 überprüfen. Zu diesem Zweck müsste der Parser mit dieser Funktion erweitert werden, so dass auch hier bei einer Transaktion nur der betroffene Teil überprüft werden müsste und nicht die gesamten Daten der Datenbank Isolation Parallel ausgeführte Transaktionen dürfen sich nicht gegenseitig beeinflussen und sollten jede für sich als einzelne aktive Transaktion angesehen werden. Der Einsatz des Prozesslock in BaseX verhindert es, dass schreibende Transaktionen parallel ausgeführt werden können. Dies bringt den Vorteil mit sich, dass Transaktionen bei ihrer Ausführung immer isoliert sind und so keine Konflikte entstehen können. Da alle Prozesse der verbundenen Clients in separaten Threads am Server ablaufen, sind die 1 wohlgeformtes XML [KM03, S. 38]: Für wohlgeformte XML-Dokumente bestehen definierte Regeln, welche nicht verletzt werden dürfen. So darf ein XML-Dokument beispielsweise nur genau ein Wurzelelement besitzen und ein Element darf nicht mehrere Attribute mit demselben Namen enthalten. 2 Ein gültiges XML-Dokument muss wohlgeformt sein und zusätzlich einer definierten DTD entsprechen.

41 4 Transaktionsmanagement 35 parallel ablaufenden Lesetransaktionen immer voneinander isoliert und bemerken weitere parallel ablaufende Transaktionen nicht. Durch diese Isolation werden z.b. Konflikte ausgeschlossen, welche durch Zugriffe auf Daten entstehen, welche gerade von anderen Transaktionen in Bearbeitung sind Dauerhaftigkeit Die Datenveränderungen einer Transaktion müssen dauerhaft in die Datenbank geschrieben werden. Während der Ausführung einer Transaktion werden neu entstandene Daten in die Datenbank auf die Festplatte geschrieben. Somit müssen nach der Ausführung keine Schreibprozesse mehr durchgeführt werden. Dies bedeutet, dass wenn der Server während der Ausführung nicht abgebrochen wird, die Daten der Transaktion auch komplett und dauerhaft in die Datenbank geschrieben werden. Da nur eine einzelne Transaktion zeitgleich ablaufen kann, können die veränderten Daten, bevor Sie in die Datenbank geschrieben werden, nicht noch einmal von einer anderen Transaktion verändert werden. Ansonsten würde dies im schlimmsten Fall zum Verlust der zuvor geschriebenen Daten führen. 4.3 Nebenläufigkeitskontrolle Die Kontrolle der Nebenläufigkeit ( Concurrency Control [GR92, S. 454]) beschreibt den Mechanismus, welcher zur sicheren und fehlerfreien Ausführung von parallel bzw. nacheinander am Server ankommenden Transaktionen eingesetzt wird. Hierbei dürfen keine Konflikte und Anomalien bei der Ausführung der jeweiligen Transaktionen entstehen. Da es bei der parallelen Ausführung von mehreren Threads in einem Programm zu beliebigen Abarbeitungen durch den Scheduler der Threads kommen kann, ist die Nebenläufigkeitskontrolle unentbehrlich für die Vermeidung der Anomalien. Die Nebenläufigkeitskontrolle überprüft für jede Transaktion, die einen Lese- oder Schreibzugriff auf eine Datenbank ausführen will, den Status des Sperrobjekts am System und entscheidet dadurch ob für die jeweilige Transaktion die Isolation gewährleistet ist. Falls dies der Fall ist, wird die Transaktion sofort gestartet. Ansonsten kommt die Transaktion in den Wartemodus und wartet somit auf ihre Ausführung. Dies führt dazu, dass in einem System an dem eine Vielzahl von Benutzern arbeitet, trotzdem jede einzelne Transaktion der Benutzer isoliert von den anderen abläuft. Im Weiteren werden die Begriffe Datenlock für das Sperren von Datenobjekten und Prozesslock für das Sperren von Transaktionen verwendet. Zu Beginn der Entwicklung der Client-Server Architektur war XQuery Update in BaseX noch nicht eingeführt. Für Aktualisierungen auf die Datenbanken wurde ein eigen definiertes Updatekonzept verwendet. Dieses Konzept schränkte die Möglichkeiten der Updates nur auf die aktuell geöffnete und im Kontext gesetzte Datenbank ein. Hierdurch konnten Updates nur auf eine Datenreferenz durchgeführt werden und somit die Nebenläufigkeitskontrolle mittels dieser Datenreferenz als Sperrobjekt mit dem Datenlock gewährleistet werden.

42 4 Transaktionsmanagement 36 Durch die Einführung von XQuery Update und die damit angestiegene Komplexität der Updateoperationen ist es nun möglich in Anfragen unendlich viele Datenbanken anzusprechen und Updates auf diese auszuführen. Updates, welche Zugriff auf mehrere Datenbanken nützen, können nicht mit einem einfachen Datenlock geschützt werden. Aus diesem Grund wurde der Mechanismus der Nebenläufigkeitskontrolle auf den Prozesslock umgestellt. Beim Konzept des Prozesslock wird anstatt der Datenobjekte als Sperrobjekt ein künstliches Sperrobjekt erstellt, mit welchem die Ausführung der einzelnen Prozesse kontrolliert wird. Dieses Verfahren hat den Vorteil, dass man auf die verwendeten Datenreferenzen keine Rücksicht nehmen muss und die Sicherheit der Transaktionen somit durch die Verwaltung eines einzigen Sperrobjekts gewährleistet werden kann. Der Nachteil ist, dass schreibende Prozesse nur noch hintereinander und nicht mehr parallel ausgeführt werden können. Dies fällt aber aufgrund der Schnelligkeit des XQuery Prozessors von BaseX und den heutigen Computern nur geringfügig ins Gewicht. Lesende Prozesse werden weiterhin parallel ausgeführt Sperrprotokoll Als meistgenutztes Sperrprotokoll hat sich das Strict Two Phase Locking (kurz: S2PL ) [WV01, S.143 f.] in Datenbanksystemen durchgesetzt. Bei diesem Protokoll gibt es zwei Phasen bei der Durchführung. In der ersten Phase werden die für die Ausführung benötigten Sperren des Prozesses gesetzt. Die zweite Phase hebt nach der Ausführung des Prozesses die Sperren wieder auf und gibt den kritischen Bereich für weitere Prozesse frei. Ein Objekt kann hierbei die in Abbildung 4.1 dargestellten Zustände einnehmen. Die beiden Zustände werden standardmäßig mit S für eine Lesesperre (shared lock) und X für eine Schreibsperre (exclusive Lock) gekennzeichnet. Abbildung 4.1: Potentielle Zustände eines Sperrobjekts Für die beiden Sperrmodi können entsprechend der definierten Regeln aus [LBK01, S. 454] folgende zusammengefasste Regeln bestimmt werden:

43 4 Transaktionsmanagement 37 Voraussetzung: Sei T S die Menge aller Transaktionen mit Leseabsicht auf das Objekt O und T X die Menge aller Transaktionen mit Schreibabsicht auf das Objekt O. Lesesperre S : Wenn eine Transaktion T T S die Sperre S auf das Objekt O besitzt, ist sie berechtigt O zu lesen. Weitere Transaktionen T T S sind gleichzeitig dazu berechtigt S zu halten und O zu lesen. Transaktionen der Menge T T X sind von der Ausführung ausgeschlossen, bis die Freigabe von O erteilt ist. Schreibsperre X : Wenn eine Transaktion T T X die Sperre X auf das Objekt O besitzt ist sie berechtigt das Objekt O zu verändern. Weitere Transaktionen T T S oder T T X sind von der Ausführung bis zur Freigabe von O ausgeschlossen. In der folgenden Tabelle 3 sind die Regeln zur Übersicht zusammengefasst dargestellt. Hierbei ist die Kompatibilität der gehaltenen und angeforderten Sperren in die Tabelle eingefügt. Während das + besagt, dass die Ausführung möglich ist, bezeichnet dass einen Konflikt zwischen den Sperren und somit wird der Prozess in den Wartemodus versetzt. angeforderter Lock S X Frei + + gehaltener Lock S + X Tabelle 4.1: Kompatibilitätstabelle von Transaktionssperren Die Regeln und die daraus resultierende Tabelle lassen erkennen, dass es bei diesem Protokoll zu ewig wartenden Schreibprozessen kommen kann. Solange kein aktiver Schreibprozess vorhanden ist, werden die ankommenden Leseprozesse ohne Rücksicht auf schon wartende Schreibprozesse gestartet. Hierdurch ist der Zugriff auf die aktuellsten Daten nicht mehr garantiert, da eventuelle wartende Updates nicht ausgeführt werden konnten. Aus diesen Gründen ist beim Verfahren des Prozesslock, in die Verwendung des Sperrprotokolls eine Warteliste eingepasst, welche gewährleistet, dass alle Prozesse gleich behandelt und ihrer Reihenfolge entsprechend ausgeführt werden. Dies entspricht dem FiFo-Prinzip ( First-In First-Out ), welches besagt, dass die ersten Prozesse, welche am Server ankommen auch die ersten Prozesse der Bearbeitungsreihenfolge sind. Das FiFo-Prinzip kann aber in einer Guppe von lesenden Prozessen nicht eingehalten werden, da diese in verschiedenen Threads laufen und sich somit gegenseitig überholen können. Des Weiteren haben die verschiedenen Lesetransak- 3 Quelle: vgl. [WV01, S. 131]

44 4 Transaktionsmanagement 38 tionen unterschiedliche Ausführungszeiten, so dass eine weniger komplexe Lesetransaktion vor einer schwierigeren Lesetransaktion beendet werden kann Prozesslock Bei dem Verfahren des Prozesslock werden die Prozesse solange gesperrt, bis sie ungestört ausgeführt werden können. Eine fehlerfreie Ausführung ist nur dann möglich, wenn sich jeweils nur ein Schreibprozess oder eine Gruppe von lesenden Prozessen im Bereich der Ausführung befindet. Zur Kontrolle dieser Kriterien wird ein Transaktionsmonitor eingesetzt, welcher die gesamten Prozessausführungen steuert und verwaltet. Dieser Monitor lässt immer nur einen Schreibprozess oder eine Gruppe von lesenden Prozessen miteinander in den kritischen Bereich der Ausführung eintreten. Eine Gruppe von lesenden Prozessen besteht immer aus sich nacheinander ununterbrochenen in der Reihenfolge befindlichen Leseprozessen. Die Leseprozesse können sich hierbei schon im Monitor befinden oder bei Eintreffen hinzugefügt werden. Da es beim Prozesslock keine Datenobjekte gibt, wird hierfür ein künstliches Sperrobjekt erstellt, welches die Zustände aus der Abbildung 4.1 einnehmen kann. Bei jedem in den Monitor kommenden Prozess wird der Zustand des Objekts überprüft und je nach Zustand des Objekts die weiteren Schritte eingeleitet. In Abbildung 4.2 wird die Abarbeitung der in den Monitor kommenden Prozesse detailliert dargestellt. Hierbei wird der gesamte Mechanismus, welcher vor und nach der Ausführung der durch den Monitor laufenden Transaktionen stattfindet, veranschaulicht. Die Abkürzungen TS und TX stehen hierbei für Transaktionen, welche eine geteilte Sperre (Lesetransaktion TS) oder eine exklusive Sperre (Schreibtransaktion TX) benötigen. Die dargestellten Rechtecke stellen Aktionen dar, welche nach den Entscheidungen (in Rautenform) ausgeführt werden. Die Entscheidungen führen nur zu einem positiven Ergebnis, wenn alle in der Raute enthaltenen Bedingungen erfüllt sind. Das Objekt state beschreibt den aktuellen Zustand des Sperrobjektes, welches zur Überprüfung verwendet wird. Das Objekt waiting stellt die Liste dar, welche zur Verwaltung der wartenden Transaktionen genutzt wird. Der in einer Ellipse dargestellte Start- bzw. Endpunkt des Monitors muss von allen Prozessen vor, bzw. nach deren Ausführung passiert werden. Am Ende einer Schreibtransaktion wird die nächste wartende Schreibtransaktion bzw. die nächste Lesetransaktion gestartet. Falls es sich hierbei um eine Lesetransaktion handelt, wird dieser Schritt für jede nächste Lesetransaktion in der Warteliste wiederholt. Falls nötig wird hierdurch eine ganze Gruppe von Lesetransaktionen gestartet. So bald in der Warteliste eine Schreibtransaktion an der Reihe ist wird die Aktivierung unterbrochen und gewartet bis alle Mitglieder der Gruppe der Lesetransaktionen beendet sind. Hierbei startet stets die letzte Lesetransaktionen einer Gruppe die eventuell vorhandene wartende Schreibtransaktion. An dieser Stelle kann es keine wartenden Lesetransaktionen geben, da diese ansonsten schon in der vorherigen Gruppe inkludiert gewesen wären. Durch diesen eingesetzten Algorithmus, der zusätzlich zur Überprüfung des Sperrobjekts, die Warteliste überprüft, wird die Verwaltung der eintreffenden und wartenden Prozesse

45 4 Transaktionsmanagement 39 fehlerfrei und fair durchgeführt. Die fortlaufende Abarbeitung der sich in der Warteliste befindlichen Transaktionen garantiert, dass ankommende Leseprozesse die wartenden Schreibprozesse nicht überholen können. Dies hätte zur Folge, dass Schreibprozesse im schlimmsten Fall ewig warten und somit niemals ausgeführt werden würden. Weiterhin wird durch den Einsatz des Monitors die Entstehung eines Deadlocks verhindert, da er die kritische Ressource immer nur einem Schreibprozess bzw. einer Gruppe von Leseprozessen zuteilt. Abbildung 4.2: Programmablauf der Kontrolle von Transaktionen im Monitor

46 4 Transaktionsmanagement Probleme der Nebenläufigkeit Durch Einsatz des Prozesslock können effektiv die in diesem Abschnitt erläuterten Probleme, welche bei der parallelen Ausführung von Transaktionen auftreten können, verhindert werden. Verhinderung von Transaktionsanomalien Bei der parallelen Ausführung von Transaktionen kann es bei den verschiedenen Kombinationen von Schreib- und Lesezugriffen auf eine Datenbank zu drei Problemen ( Lost Update, Dirty Read, Unrepeatable Read ) [GR92, S. 380 f.] kommen. Diese drei Probleme verstoßen alle gegen das Prinzip der Isolation und führen zu fehlerhaften Ausführungen bei den Transaktionen und den daraus resultierenden Ergebnissen. In Abbildung 4.3 sind die vier möglichen Kombinationen von Schreib- und Lesezugriffen der Transaktionen T 1 und T 2 auf ein Objekt o dargestellt. Während die ganz rechte Kombination zu keinen Problemen führt, kommt es bei den anderen drei zu den erwähnten Konflikten. Der Graph wird als zeitliche Abfolge der Aktionen von oben nach unten betrachtet. Verbindungen zwischen den Transaktionen stellen den sequentiellen Ablauf dar. So bedeutet ein Richtungspfeil von T 1 nach T 2 beispielsweise, dass die jeweilige Aktion von T 1 vor der Aktion von T 2 ausgeführt wurde. Abbildung 4.3: Entstehung der drei Probleme der Nebenläufigkeit Quelle: [GR92, S. 381] Im Weiteren werden die Abläufe der Probleme näher erläutert und mit Beispielen in XQuery Update mit Zugriff auf das folgende XML-Dokument veranschaulicht. Die Beispiele setzen voraus, dass die beiden Transaktionen T 1 und T 2 zeitgleich von zwei Clients an den Server gesendet und von diesem wie in Abbildung 4.3 dargestellt abgearbeitet werden. Beide Clients haben vor der Ausführung der Transaktionen die Datenbank mit dem Beispieldokument geöffnet, um darauf Zugriff zu haben.

47 4 Transaktionsmanagement 41 Beispieldokument: <bank> <account> <name>customer</name> <balance>2000</balance> </account> </bank> Lost Update: Diese Problem entsteht immer dann, wenn zwei Transaktionen Schreibprozesse auf das gleiche Objekt durchführen und hierbei sich ihre Abläufe kreuzen. Die Transaktionen T 1 und T 2 lesen beide das Objekt o in ihre lokale Variablen. Transaktion T 1 schreibt anschließend einen neuen Wert für o. Bevor die Transaktion T 1 ihren Prozess abschließt, überschreibt das Update von T 2 die Daten vom Update von T 1. Transaktion T 2 ignoriert somit den veränderten Wert von T 1 und dieser geht letztlich verloren. Beispiel: T 1: replace value of node //balance with //balance T 2: replace value of node //balance with //balance Der Kontostand wird von beiden Transaktionen gelesen, anschließend wird der Stand von T 1 um 1000 verringert. T 2 bemerkt dieses nicht und erhöht den ursprünglichen Kontostand um Somit beträgt der Kontostand am Ende der Transaktionen 4000, obwohl er nur 3000 betragen dürfte. Dirty Read: Die Transaktion T 2 schreibt ein Objekt, welches anschließend von der Transaktion T 1 gelesen wird. T 2 führt jedoch weitere Änderungen an dem Objekt durch, welche von T 1 nicht beachtet werden. Hierdurch hat T 1 aus einem inkonsistenten Datenbestand gelesen und somit fehlerhafte Daten als Ergebnis erhalten. Beispiel: T 1: //account[name = 'Customer2']/balance T 2: replace value of node //name with 'Customer2', replace value of node //balance with //balance Transaktion T 2 ändert den Namen des Kunden auf Customer2. Anschließend liest T 1 den Kontostand von Customer2 mit dem Wert von 2000 aus. Transaktion T 2 erhöht diesen jedoch mit einer weiteren Aktion um Dies bemerkt T1 nicht mehr und erhält den Kontostand 2000 als Ergebnis. Dies stellt ein falsches Ergebnis dar, da der Kontostand 3000 hätte betragen müssen. Unrepeatable Read: Dieses Problem tritt auf, wenn eine Transaktion in ihrem Ablauf Daten wiederholt ausliest, diese aber durch eine zweite Transaktion währenddessen verändert werden. Somit liest die erste Transaktion, bei der zweiten Leseoperation zwar aus einem konsistenten Datenbestand, jedoch liest sie nicht aus den selben Daten wie die erste Leseoperation.

48 4 Transaktionsmanagement 42 Beispiel: T 1: for $n in 1 to 2 return //account/name T 2: replace value of node //name with 'Customer2' Transaktion T 1 liest zweimal den Namen des Bankkunden aus. T 2 verändert dazwischen den Namen des Kunden und somit erhält die Transaktion T 1 zwei verschiedene Namen als Ergebnis. Verklemmungsverhinderung Eine Verklemmung ( Deadlock ) [LBK01, S. 457 f.] entsteht immer dann, wenn eine oder mehrere schreibende Transaktionen für ihre Ausführung Daten benötigen, welche durch weitere aktive Transaktionen gesperrt sind. Die Transaktionen blockieren sich gegenseitig und das komplette Programm wird zum Stillstand gezwungen. Durch den Einsatz von Prozesslocks wird die Entstehung einer Verklemmung verhindert, indem stets nur eine schreibende Transaktion aktiv ist. In Abbildung 4.4 ist die Entstehung eines Deadlocks anhand von Ablaufplänen, der im folgenden Beispiel verwendeten Anfragen dargestellt. Hier wird deutlich, dass durch einfache Abfragen, welche nur zwei Datenbanken beinhalten, das gesamte Programm stillgelegt werden kann. Das Ziel der Anfragen des Beispiels ist es, am Ende in beiden Datenbanken alle Studenten des Kurses zu speichern. Beispieldokument 1 (doc1): <course> <student> <name>student A</name> <grade>2.0</grade> </student> </course> Beispieldokument 2 (doc2): <course> <student> <name>student B</name> <grade>1.0</grade> </student> </course> Die Transaktionen lauten folgendermaßen: Transaktion 1 (T 1 ): Alle Studenten von doc1 werden in doc2 kopiert for $node in doc('doc1')//student return insert node $node into doc('doc2')//course Transaktion 2 (T 2 ): Alle Studenten von doc2 werden in doc1 kopiert for $node in doc('doc2')//student return insert node $node into doc('doc1')//course

49 4 Transaktionsmanagement 43 Die erste Transaktion (T 1 ) erhält Zugriff auf das Dokument doc1 (links im linken Teilbaum dargestellt). Währenddessen erhält die zweite Transaktion (T 2 ) Zugriff auf das Dokument doc2 (rechts im linken Teilbaum dargestellt). Anschließend benötigen beide Transaktionen die von der jeweils anderen Transaktion gesperrten Daten, um ihre Transaktion fortzusetzen. Da keine der beiden Transaktionen den Zugriff auf die benötigten Daten bekommt, entsteht ein Deadlock und das Programm wird zum Stillstand gezwungen. Die Stellen an denen der Konflikt auftritt sind in den beiden Teilbäumen rot umrandet. Abbildung 4.4: Darstellung der Entstehung eines Deadlock anhand von Ablaufplänen der Transaktionen Datenlock Mit Hilfe eines Datenlocks kann die Parallelität von schreibenden Anfragen und somit die Leistung des gesamten Datenbanksystems deutlich erhöht werden. Durch den Einsatz eines Datenlocks können die Probleme der Nebenläufigkeit effektiv verhindert und die parallele Abarbeitung der Transaktionen effizient gewährleistet werden. In XML-Datenbanken ist die Auswahl des Lockingmechanismus abhängig von dem verwendeten Update Konzept. So kann bei einfachen Updates, welche nur auf einzelne bzw. aktuell geöffnete Datenbanken gerichtet sind, ohne weiteres ein Datenlock eingesetzt werden. Hierbei muss der Monitor anstatt dem allgemeinen Lockingobjekt, die einzelnen Datenobjekte auf ihre Sperren prüfen und somit die Abarbeitung der Prozesse steuern.

50 4 Transaktionsmanagement 44 Der Datenlock, welcher in der Entwicklungsphase der Client-Server Architektur in BaseX kurzzeitig zum Einsatz kam, war so konzipiert, dass ganze Datenbanken gesperrt wurden. Im Gegensatz zum jetzigen Prozesslock waren mit dem Datenlock Updates auf die verschiedenen Datenbanken parallel möglich. Bei Updates auf gleiche Datenbanken wurden aber auch diese sequentiell ausgeführt. Hierbei ist zu erkennen, dass auch diese Form des Datenlocks schnell von parallelem zu sequentiellem Abarbeiten der Transaktionen wechselt. Die Verwendung von XQuery Update erhöht die Komplexität der Updates und bietet gleichzeitig die Möglichkeit unendlich viele Datenbanken in einem Update anzusprechen. Der Monitor würde beim Einsatz von Datenlocks im schlimmsten Fall, für eine einfache Transaktion über mehrere Datenbanken mehr Verwaltungsaufwand benötigen, als die Ausführung der Abfrage eigentlich selbst beansprucht. Die Nebenläufigkeit bei der Verwendung des Datenlocks in XML-Datenbanken, kann durch die Definition der Granularität der Datenobjekte, welche gesperrt werden, noch weiter erhöht werden. So können z.b. nur einzelne oder mehrere Teilbäume eines XML-Dokuments gesperrt werden und somit die anderen Teile des Dokuments für weitere Transaktionen frei bleiben. Für die Umsetzung eines solchen Konzepts muss man die gesamte Architektur und Zusammenhänge der XQuery Implementierung erweitern bzw. verändern. Eine wichtige Veränderung hierbei wäre es die Datenreferenzen, auf welche der Zugriff der Anfragen erfolgt, schon vor dem Ausführungsstart der Anfrage zu kennen und nicht erst während der Laufzeit. Einsetzbare Lockingmechanismen sind zum Beispiel die Sperrprotokolle Doc2PL, Node2PL, NO2PL OO2PL (siehe [HKM04] & [HKM03]) oder das Konzept des Sperrverfahrens mittels eines tadom-tree (siehe [HH03] & [HH04]). Während das Konzept des Lockings mit einem tadom-tree speziell für diese Struktur entwickelt wurde, sind die *2PL -Konzept allgemeingültig und können auf jede Repräsentationsstruktur von XML-Dokumenten angewendet werden. Bei diesen Sperrmechanismen steht das 2PL für Zwei-Phasen-Locking, was wiederum beschreibt, dass es eine Phase vor der Ausführung mit dem Setzen der Sperren und eine Phase nach der Ausführung mit der Freigabe der Sperren gibt. Für das tadom-tree Verfahren ist es nötig einen tadom-tree aus der für die Datenbank verwendeten Speicherstruktur erstellen zu können. Hierauf kann dann anschließend das Lockingverfahren eingesetzt werden. BaseX bietet durch die Implementation der XPath Achsen schon diverse Funktionalitäten an, um auf den Achsen zwischen den Knoten zu navigieren. Dies könnte bei den Varianten des tadom-tree oder des OO2PL eingesetzt werden. Doc2PL Bei dieser Variante des Sperrverfahrens werden die verschiedenen Sperrtypen in der Ebene der Dokumente gesetzt. Als Sperrtypen gibt es hierbei wiederum nur die Leseund die Schreibsperre, welche auf ganze Dokumente in der Datenbank gesetzt werden.

51 4 Transaktionsmanagement 45 Die Kompatibilität der Sperrtypen verhält sich hierbei ebenfalls wie in Abbildung 4.1 dargestellt. Ein Vorteil hierbei ist es, dass Updates auf verschieden Dokumente in der Datenbank parallel ausgeführt werden können und somit nicht aufeinander warten müssen. Nachteilig hieran wirkt sich aus, dass Datenbanken, welche nur aus einem Dokument bestehen, ebenfalls komplett gesperrt werden und keine Parallelität bei schreibenden Transaktionen zulassen. Weiterhin müsste man auch schon für dieses einfache Protokoll einen Mechanismus zur Verhinderung von Deadlocks implementieren, da diese auch hierbei schon auftreten könnten. Node2PL Bei diesem Protokoll werden die Elternknoten des zu lesenden bzw. schreibenden Knoten mit dem jeweiligen Sperrtyp belegt. So wird z.b., wie in Abbildung 4.5a dargestellt, bei einem Lesezugriff auf irgendeinen Kindknoten des Knoten P der Knoten P mit einer Lesesperre belegt. Bei einer schreibenden Transaktion wird der Knoten P mit einer Schreibsperre versehen. Bei der Sperre eines Elternknoten werden hierbei alle Kindknoten ebenfalls gesperrt und somit ein ganzer Unterbaum geblockt. NO2PL Dieses Protokoll sperrt alle Knoten, welche in direkter Verbindung mit dem zu lesenden bzw. schreibenden Knoten der Transaktion stehen. Ein Beispiel hierfür ist (siehe Abbildung 4.5a) das Einfügen eines neuen Kindknoten C0 vor dem Knoten C1. Für diese Transaktion werden eine exklusive Sperre für den Elternknoten P und eine exklusive Sperre für den Geschwisterknoten C1 gesetzt. Durch diese Sperren sind alle Wege gesperrt um zum Knoten C0 zu gelangen. Hierdurch wird im Gegensatz zum Node2PL nur die vom definierten Knoten aus erreichbaren Knoten gesperrt und somit eine höhere Parallelität erreicht, als bei der Sperrung eines ganzen Teilbaumes. OO2PL Während bei den beiden vorherigen Protokollen immer Knoten gesperrt werden, werden bei dieser Variante die Zeiger, welche die Referenzen zwischen den verschiedenen Knoten darstellen gesperrt. Jeder Knoten hat hierbei vier Zeiger, welche auf den ersten Kindknoten ( first child (A)), den letzten Kindknoten ( last child (Z)), den linken Nebenknoten ( left sibling (L)) oder den rechten Nebenknoten ( right sibling (R)) verweisen. Für die vier Zeiger werden jeweils ein exklusiver (MA, MZ, ML, MR) und ein geteilter (TA, TZ, TL, TR) Sperrtyp definiert. Der Buchstabe M steht hierbei für die exklusive und der Buchstabe T für die geteilte Sperre. Ein Beispiel für das Locking von OO2PL ist das Einfügen eines Knoten C12 zwischen den Knoten C1 und C2 in der Abbildung 4.5a. Hierbei würde eine Sperre MR auf C1 und eine Sperre M L auf C2 vergeben werden. Weitere Transaktionen könnten

52 4 Transaktionsmanagement 46 somit auf die weiteren Knoten zugreifen. Die Kompatibilitätsmatrix der verschiedenen Sperrtypen ist in Abbildung 4.5b dargestellt. Diese stellt die gehaltene Sperre (links) einer Transaktion T 1 und die angeforderte Sperre (oben) einer Transaktion T 2 dar. Hierbei zeigt ein + die Kompatibilität und ein einen Konflikt der beiden beteiligten Sperren an. So sind z.b. die exklusiven Sperren für das last child (MZ) und für das first Child (M A) miteinander kompatibel. Weiterhin gibt es keine Konflikte bei allen beteiligten Lesesperren. (a) Beispiele von *2PL (b) Kompatibilitätsmatrix von OO2PL Abbildung 4.5: Beispiel der *2PL und Kompatibilitätsmatrix von OO2PL Quelle: [HKM04, S. 3] Ein Vergleich [HKM03, S. 4] der verschiedenen Konzepte zeigt, dass Doc2PL die wenigsten Sperren erzeugt. Hierbei werden je nach Abfrage meistens nur eine Sperre für das angesprochene Dokument gesetzt. Bei den Varianten Node2PL und NO2PL wird meistens für jede Transaktion eine Sperre pro Knoten vergeben. Der Unterschied ist jedoch, dass Node2PL keine Knoten in der Ebene der Blattknoten (hier sind im Normalfall die meisten Knoten in einem XML-Dokument) sperrt. Beim OO2PL werden im maximal Fall vier Sperren pro Transaktion und Knoten vergeben. Locking mit dem tadom-tree Bei der Lockingvariante mit dem tadom-tree gibt es zwei unterschiedliche Konzepte. Zum einen werden die von der Abfrage oder dem Update verwendeten Knoten ( Node Locks ) der Datenbank vor dem Zugriff mit verschiedenen Sperren belegt. Zum anderen gibt es hierbei ebenfalls die Variante Navigationspfaden ( Navigation Locks ) im tadom-tree zu sperren. Die Sperren werden bei beiden Arten auf einem so genannten tadom-tree gesetzt, welcher auf der Form der DOM-Baumstruktur 4 eines XML-Dokumentes aufbaut. 4 DOM: Document Object Model, welches ein XML-Dokument in einer Baumstruktur beschreibt und jedem XML-Dokument zu Grunde liegt

53 4 Transaktionsmanagement 47 Node Locks Mit dem Konzept der Node Locks [HH04, S.5 ff.] ist es z.b. durchaus möglich einen Knoten n mit einer Lesesperre zu belegen und zeitgleich im Unterbaum des Knoten n Aktualisierungen auszuführen. Für diese Zwecke sind die folgenden Sperrtypen definiert: NR-Lock Lesesperre auf einen definierten Knoten ohne einen darunter liegenden Knoten zu sperren IX-Lock Sperre mit der Absicht an einer Stelle im Unterbaum des Knoten ein Update auszuführen, aber nicht auf einen direkten Kindknoten LR-Lock Lesesperre auf einen definierten Knoten und die direkt darunter liegenden Kindknoten SR-Lock Lesesperre auf einen definierten Knoten und den gesamten Unterbaum von diesem Knoten CX-Lock Schreibsperre auf einen definierten Knoten und den direkt darunter liegenden Kindknoten U-Lock Lesesperre auf einen definierten Knoten mit der Option, dies in eine Schreibsperre umzuwandeln X-Lock Schreibsperre auf einen definierten Knoten und den gesamten Unterbaum von diesem Knoten. Die Sperre impliziert zudem einen CX-Lock für den Elternknoten und IX-Locks für alle Knoten auf dem Pfad zur Wurzel des Dokuments. Die Kompatibilität der Sperren und ein Beispiel für den Einsatz der Sperren in einem XML-Dokument sind in Abbildung 4.6 dargestellt. Die Kompatibilitätstabelle und die hohe Anzahl an Sperren lässt hierbei direkt erkennen, wie komplex ein Sperrverfahren in XML-Datenbanken werden kann. Im Gegensatz zum Prozesslock, bei dem es zwei verschiedene Sperrtypen gibt, sind es bei der Node-Lock Variante sieben Sperrtypen. An der Kompatibilitätstabelle ist zu erkennen, dass z.b. der X-Lock keine Kompatibilität mit anderen Sperren aufweist. Das Beispiel des Node Lock läuft wie folgt ab. Die Transaktion T 1 erhält einen X-Lock (X 1 ) auf den Knoten Darcy um diesen zu verändern. Hierbei werden zusätzlich ein CX-Lock auf den Vaterknoten (CX 1 ) und weitere IX-Locks (IX 1 ) auf alle Vorgängerknoten bis zur Wurzel gesetzt. Der Lock-Manager führt dies für die vollständige Isolation der Transaktion eigenständig durch. Hierbei wird immer die beste Sperrkombination gewählt, um eine höchst mögliche Parallelität zu ermöglichen. Gleichzeitig will die Transaktion T 2 den gesamten editor - Knoten löschen. Für diesen Zweck müsste die Transaktion einen X-Lock erhalten. Diesem

54 4 Transaktionsmanagement 48 kann jedoch nicht stattgegeben werden, da T 1 einen IX-Lock darauf besitzt. Die Transaktion T 2 kommt also in die Warteschlange (LRQ : X 2 ). Währenddessen erstellt Transaktion T 3 eine Liste mit allen Buchtiteln im Dokument. Hierfür erhält T 3 einen LR-Lock (LR 3 ) auf den bib -Knoten und NR-Locks (NR 3 ) für alle Knoten, welche auf dem Pfad zu den Buchtitel-Knoten liegen. Hierbei ist zu erkennen, dass der LR-Lock (LR 3 ) die Buch-Knoten nur im shared-mode sperrt und somit trotzdem Updates auf Knoten, welche tiefer im Baum liegen ermöglicht. Wenn die Transaktion T 2 nun den X-Lock für den editor -Knoten erhält, wird zugleich ein CX-Lock auf den Buch-Knoten und IX-Locks auf alle Knoten bis aufwärts bis zur Wurzel gesetzt. (a) Beispiel für tadom-tree Lock (b) Kompatibilitätsmatrix Abbildung 4.6: Beispiel und Kompatibilitätsmatrix von Node Lock in einem tadom-tree Quelle: [HH04, S. 6] Navigation Locks Das Konzept der Navigation Locks [HH04, S.9 f.] ähnelt dem des zuvor beschriebenen OO2PL. Hierbei werden ebenfalls Navigationspfade in der Baumstruktur gesperrt, um die Transaktionen, welche auf die Daten zugreifen voneinander zu isolieren. Die einzelnen Navigationskanten des Navigation Lock werden bei diesem Konzept zusätzlich zu den einzelnen Knoten, welche mit einem NR-Lock versehen werden gesperrt. In Abbildung 4.7c ist zu erkennen, dass der Navigation Lock die gleichen Navigationskanten wie das OO2PL verwendet. Im Gegensatz zu OO2PL definiert der Navigation Lock jedoch nur drei weitere Sperrtypen. Diese Sperren und ihre Kompatibilitätsmatrix sind in Abbildung 4.7b dargestellt. Der Navigation Lock definiert die Sperren wie folgt: ER-Lock Lesesperre auf eine Navigationskante, wie beispielsweise nextsibling EX-Lock Schreibsperre auf eine Navigationskante, welche für alle durch die Transaktion modifizierten Kanten gesetzt sein muss

55 4 Transaktionsmanagement 49 EU-Lock Lesesperre auf eine Navigationskante mit der Option, dies in eine Schreibsperre umzuwandeln Ein Beispiel für den Ablauf des Locking mit dem Navigation Lock ist in Abbildung 4.7a dargestellt. Die Sperren der einzelnen Knoten sind um eine bessere Übersicht zu gewährleisten nicht abgebildet. Die Transaktion T 1 liest hierbei im linken Teilbaum die Titel und den Autor der enthaltenen Bücher aus. Hierfür wird jeweils ein ER-Lock (ER 1 ) für eine Lesesperre der jeweiligen Kante gesetzt. Währenddessen will die Transaktion T 2 ein neues Buch in die XML-Datenbank einfügen. Um dies ausführen zu können muss ein EX-Lock (EX 2 ) auf die Geschwister- Kante des letzten <book>-knoten und auf die letzte Kind-Kante des <bib>-knoten gesetzt werden. Diese Sperren sind alle kompatibel mit den Sperren von Transaktion T 1 und somit kann der Knoten konfliktfrei eingefügt werden. (a) (b) (c) Abbildung 4.7: Beispiel, Kompatibilitätsmatrix und Kanten des Navigations Locks Quelle: [HH04, S. 9] Abschließend ist zu sagen, dass die Variante des Lockings mit dem tadom-tree nur sinnvoll in BaseX eingesetzt werden kann, wenn die Erstellung dieser Baumstruktur in effizienter Art und Weise durchgeführt werden kann. Bei den anderen vorgestellten Lockingvarianten muss man vor dem Einsatz entscheiden ob man eine möglichst hohe Parallelität der Transaktionen oder eine möglichst schnelle Sperrung und Freigabe der Ressourcen erreichen möchte. Auf alle Fälle ist in allen Variante darauf zu achten, dass keine Probleme bei der Nebenläufigkeit entstehen, um somit korrupte Datenbestände und den Stillstand des Programms zu verhindern.

56 Kapitel 5 Datenmanagement Dieses Kapitel gibt einen Überblick über das theoretische Konzept und die praktische Umsetzung der Verwaltung von Datenbanken in einem Datenbanksystem mit Client-Server Architektur. Da stets beliebig viele Clients mit den Datenbanken des Servers interagieren können ist es unerlässlich ein zuverlässiges und sicheres Verwaltungskonzept zu verwenden. Zu Beginn wird ein Überblick über die Grundlagen der Datenhaltung im Bezug auf XML-Datenbanken und BaseX gegeben. Anschließend wird der eingeführte Datenpool und dessen Funktionsweise detailliert beschrieben. Zum Abschluss wird die Import und Export Funktionalität von XML-Daten in einer XML-Datenbank dargestellt. 5.1 Grundlagen der Datenhaltung Die meisten nativen XML-Datenbanken haben ihre eigene Speicherstruktur für Datenbanken, doch die grundlegende Logik dahinter ist stets identisch. Eine Datenbank kann entweder aus einem einzelnen XML-Dokument oder aus Sammlungen von XML-Dokumenten (so genannte Collections ) bestehen. Eine Collection stellt hierbei einen fiktiven Ordner dar, in dem beliebig viele XML- Dokumente gespeichert werden können. Dies hat den Vorteil, dass man viele kleinere XML-Dokumente zu einer Datenbank zusammenfassen kann und somit eine übersichtliche Gliederung für eine große Anzahl von Dokumenten erhält. Um die Erstellung einer Collection zu erleichtern, kann man hierbei ganze Ordner mit XML-Dokumenten angeben und diese zu einer Datenbank zusammenfassen. Die einzelnen Dokumente werden dann zu einer Collection gebündelt und jedes einzelne erhält einen Wurzelknoten mit dem jeweiligen Dateiname für die spätere Identifizierung in der Collection. Weiterhin ist es möglich gepackte Archive direkt in Datenbanken einzulesen, ohne das darin enthaltene XML-Dokument zu extrahieren. Dies hat den Vorteil, dass z.b. ganze Sammlungen von XML-Dokumenten, welche in ein Archiv gepackt wurden, mit einem Befehl in eine Datenbank als Collection geladen werden können. Durch die Unterstützung von Collections kann man Updates auf Dokumentenebene und auf Knotenebene ausführen. Auf Dokumentenebene können mittels des Konzepts der Collections, Dokumente einer Datenbank hinzugefügt, oder aus einer Datenbank gelöscht werden. Auf Knotenebene können mittels XQuery Update beliebige Updateoperationen 50

57 5 Datenmanagement 51 vorgenommen werden. Die erstellten Datenbanken können auf zwei Arten verwendet werden. Durch die Benutzung der Dokumentfunktion von XQuery (fn:doc) in Anfragen können alle am Datenbanksystem vorhandenen Datenbanken mitsamt allen darin gespeicherten Daten in der Abfrage angesprochen werden. Die Datenbank wird bei Aufruf der Dokumentfunktion automatisch geöffnet und anschließend erfolgt der Datenzugriff. Die andere Art auf die Datenbanken zuzugreifen ist es eine Datenbank zu öffnen und diese ohne die Verwendung der Dokumentfunktion mit XQuery anzusprechen. Diese Datenbank wird als Datenreferenz im Kontext gesetzt und bei XQuery Anfragen ohne Dokumentfunktion automatisch angesprochen. Falls keine Datenbank geöffnet ist, kann nur mittels der Dokumentfunktion auf Daten der Datenbanken zugegriffen werden. Am Server des Datenbanksystems können also beliebig viele Datenbanken gleichzeitig geöffnet sein. Jeder Client kann jedoch immer nur eine Datenbank in seinem Kontext am Server geöffnet haben. Die Verwaltung der Datenbanken muss mit einem höchst möglichen Maß an Effektivität und Effizienz geschehen. Die Effektivität besteht darin, dass es zu keinen Problemen und Konflikten bei der Benutzung der verschiedenen Datenbanken durch die verbundenen Clients kommen darf. Des Weiteren muss die Effizienz durch schnelle Bereitstellung der Datenbanken vorhanden sein ohne den Betrieb des Client-Server Systems zu verlangsamen. Diese beiden Eigenschaften werden durch den im nächsten Abschnitt beschriebenen Datenpool garantiert. Im Klassendiagramm (siehe Abbildung 5.1) ist der Aufbau der Datenreferenz detailliert dargestellt. Mit dieser Datenreferenz ( Data ) erfolgt die Verwaltung der Datenbanken im Datenpool. Sie beinhaltet die eigentlichen Daten der Datenbank, wie aber auch dazugehörige Metadaten. In den Metadaten werden alle benötigten Informationen über die Datenbank gespeichert und zum Abruf bereit gehalten. Es gibt zwei Varianten von Datenreferenzen, welche beide die Hauptklasse ( Data ) weiter spezialisieren. Zum einen kann man Datenbanken im Hauptspeicher ( MemData ) und zum anderen auf der Festplatte ( DiskData ) erstellen. Da die Datenbanken, welche im Hauptspeicher erstellt werden, nur für den Ersteller verfügbar sind und andere Clients auf diese nicht zugreifen können, haben diese keine Relevanz für den Datenpool und sind somit in der Abbildung nur der Vollständigkeit halber erwähnt. Bei den Datenreferenzen im Datenpool handelt es sich immer um Datenbanken, welche sich auf der Festplatte befinden. Die Zugriffe hierauf erfolgen durch die Methoden der Dateninstanz und die damit verbundenen DataAccess -Klasse.

58 5 Datenmanagement 52 Abbildung 5.1: Klassendiagramm mit den Komponenten der Datenreferenz 5.2 Datenpool Der Datenpool ist die zentrale Komponente der Datenhaltung. Durch die zentrale Datenhaltung sind die Datenbanken jederzeit und überall verfügbar. Die Benutzer können sich somit sicher sein, immer auf die vom Server verwalteten Datenbanken zugreifen zu können und stets auf dem aktuellsten Stand der Daten zu sein. Somit gibt es bei den Datenbanken keine unterschiedlichen Versionen und die redundante Datenhaltung wird vermieden. Ein weiterer Vorteil der zentralen Datenhaltung ist es, dass Änderungen der Daten durch einen Benutzer sofort für alle anderen Benutzer sichtbar werden und somit keine fehlerhaften Daten in die Datenbanken gelangen können. Durch die zentrale Datenhaltung wird zudem die Datensicherheit vereinfacht und gewährleistet. Weiterhin ergibt sich durch die zentrale Speicherung ein guter Überblick über die gesamten geöffneten Datenbanken am System und die darauf stattfindenden Zugriffe. Bei dem Konzept des Datenpools werden alle aktuell geöffneten Datenbanken in einer Liste gespeichert. Zusätzlich dazu werden die jeweiligen gegenwärtigen Zugriffe auf die Datenbanken in einer weiteren Liste festgehalten. Dies hat den Vorteil, dass nur die aktuell relevanten Datenbanken im Datenpool verwaltet werden müssen und nicht alle am

59 5 Datenmanagement 53 Datenbanksystem vorhandenen Datenbanken. Der Datenpool wird bei jedem Befehl, welcher zur Öffnung oder Schließung einer Datenbank führt angesprochen. So wird z.b. auch beim Aufruf der doc() -Funktion von XQuery der Datenpool verwendet, um die benötigte Datenreferenz zu erhalten oder diese in den Datenpool hinzuzufügen. Dies ist nötig, damit alle am System vorhanden Möglichkeiten eine Datenbank zu öffnen auf dieselben Datenreferenzen zugreifen Arbeitsweise Der Datenpool besteht aus mehreren Methoden (siehe Abbildung 3.2, DataPool-Klasse), welche zur Verwaltung der Datenbanken beitragen. Im Folgenden werden die einzelnen Methoden näher beschrieben: pinned(name): Mit dieser Methode wird überprüft ob sich eine Datenreferenz mit dem definierten Namen im Datenpool befindet und das Ergebnis als boolescher Wert zurückgegeben. add(data): Diese Methode fügt dem Datenpool eine Datenreferenz hinzu und erhöht die Größe des Datenpools um eins. Weiterhin werden die Zugriffe auf die Datenreferenz auf 1 gesetzt. pin(name): Mit dieser Methode werden die Zugriffe auf die definierte Datenreferenz um eins erhöht und als Ergebnis die jeweilige Datenreferenz zurück geliefert. unpin(data): Diese Methode erniedrigt die Zugriffe auf die definierte Datenreferenz um eins. Falls es sich um den letzten Zugriff auf diese Datenreferenz handelt, wird diese automatisch aus dem Datenpool entfernt und die Größe des Datenpool um eins erniedrigt. info(): Durch diese Methode werden alle Informationen über die aktuell am Server geöffneten Datenbanken zurückgegeben. Die verschiedenen Befehle, welche auf eine Datenreferenz zugreifen, kommen alle in einer bestimmten Art und Weise mit dem Datenpool in Kontakt. So wird z.b. beim Open DB -Befehl zuerst mit Hilfe der pinned -Methode überprüft, ob die Datenreferenz mit dem entsprechenden Namen schon im Datenpool vorhanden ist oder nicht. Falls sich die Datenreferenz im Datenpool befindet wird der Zugriffszähler um eins erhöht und bei dem angefragten Client die vom Datenpool erhaltene Datenreferenz im Kontext gesetzt. Im anderen Fall wird die definierte Datenreferenz mit Hilfe der add -Methode dem Datenpool hinzugefügt und somit für weitere Clients bereitgestellt Datensicherheit Der Datenpool regelt nicht nur die Zugriffe auf die Datenreferenzen, sondern übernimmt durch seine Arbeitsweise auch die Aufgabe, die Daten vor ungewollten Nebeneffekten zu

60 5 Datenmanagement 54 schützen. Da die verbundenen Clients keine Kenntnis voneinander haben und somit keine Rücksicht aufeinander nehmen können, muss die Regulierung der Datensicherheit zentral im Server ablaufen. Hierbei sind vor allem zwei Anwendungsfälle zu beachten. Der erste Anwendungsfall ergibt sich daraus, dass ein Client eine Datenbank löschen will, welche durch einen anderen Client noch geöffnet ist. Durch den Datenpool werden die darin enthaltenen Datenbanken solange für die Löschung gesperrt, bis der Datenzugriffszähler nur noch einen Zugriff aufweist. Hierdurch wird gewährleistet, dass nur noch der Client mit der Absicht die Datenbank zu löschen, als alleiniger Client die Datenbank geöffnet hat und sie bei keinen anderen Clients aktuell mehr in Verwendung ist. Bei der Erstellung von Datenbanken ist es möglich bestehende Datenbanken mit dem selben Datenbanknamen zu überschreiben. Dies führt zum zweiten Anwendungsfall, bei dem die Datensicherheit durch den Datenpool gewährleistet sein muss. Auch in diesem Fall wird die Datenbank solange für Überschreibungen gesperrt, bis der Zugriffszähler auf die Datenreferenz nur noch 1 beträgt. 5.3 Import und Export von Daten Für die Erstellung der Datenbanken werden standardmäßig lokal am Server existierende XML-Dokumente verwendet. Bei der Verwendung einer Client-Server Architektur in Datenbanksystemen muss es aber auch für die Clients möglich sein, Datenbanken mit ihren lokalen XML-Dokumenten am Server zu erstellen. Für diesen Zweck werden ebenfalls definierte Befehle verwendet, welche die Erstellung von Datenbanken bzw. das Hinzufügen von Dokumenten zu Collections am Server mit lokal am Client vorhandenen XML-Dokumenten ermöglichen. Der Importmechanismus liest am Client das XML-Dokument ein und sendet den Inhalt dessen als XML-Zeichenkette über die Kommunikationsverbindung an den Server. Dieser empfängt den Befehl und die gesamte XML-Zeichenkette und leitet die weiteren Verarbeitungsschritte ein, welche für die Erstellung der Datenbank bzw. das Hinzufügen zu einer Collection nötig sind. Beim Import von Daten wird zwischen zwei Fällen unterschieden, welche im Weiteren näher erläutert werden: Import als Datenbank: Hierbei wird mit der vom Client gesendeten XML-Zeichenkette auf dem Server eine neue Datenbank erstellt. Als weiterer Parameter wird der definierte Datenbankname an den Server gesendet, um die Datenbank eindeutig zu benennen. Falls schon eine Datenbank mit dem Datenbankname existiert und diese aktuelle geöffnet ist wird die Ausführung mit einer Fehlermeldung abgebrochen. Wenn die Datenbank existiert aber nicht geöffnet ist wird diese mit den neuen Daten überschrieben. Der Befehl sieht hierbei folgendermaßen aus: create db [name] [xml input] Import in eine Collection: Mit dieser Funktionalität können zu einer aktuell am

61 5 Datenmanagement 55 Client geöffneten Collection weitere Dokumente hinzugefügt werden. Hierbei können zwei weitere optionale Parameter angegeben werden. Zusätzlich zur XML-Zeichenkette kann ebenfalls ein definierter Dokumentname an den Server übergeben werden. Hierdurch kann das das Dokument mit dem korrekten Namen in die Collection eingefügt werden. In Collections dürfen mehrere XML-Dokumente mit gleichem Namen auftreten, weshalb in diesem Fall hierauf kein Test durchgeführt werden muss. Hierbei ist aber darauf zu achten, dass der Name auch als Identifizierung der Dokumente verwendet wird und somit beim Entfernen von Dokumenten mit einem bestimmten Namen, alle Dokumente mit dem gleichen Namen aus der Collection gelöscht werden. Falls kein Name angegeben wird, wird der Dokumentname der Collection hierfür gesetzt. Zusätzlich zum Dokumentname kann optional die Zielposition in der Collection angegeben werden. Hierdurch kann man eine Ordnerstruktur in der XML-Datenbank schaffen, welche für weitere Verwendungszwecke und zur Übersicht sehr wichtig sein können. Der Befehl für das Hinzufügen von Dokumenten zu Collections gestaltet sich hierbei folgendermaßen: add (as [name]) (to [target]) [xml input] Da XML sehr häufig als universelles Austauschformat zwischen vielen Programmen verwendet wird, ist es zudem wichtig, den Clients die Möglichkeit zu geben, den gesamten Inhalt einer Datenbank in das XML-Format zu exportieren. Dies wird durch die in das Datenbanksystem eingebundene Exportfunktionalität gewährleistet. Mit dem Export Befehl wird am Server der gesamte Inhalt der spezifizierten Datenbank ausgelesen und in einem XML-Dokument oder einem Ordner mit den entsprechenden XML-Dokumenten einer Collection gespeichert. Diese Dokumente können dann für die weitere Verarbeitung oder den Datenaustausch verwendet werden. Mit diesem Konzept ist es so zum Beispiel möglich eine Collection zu erstellen, mehrere XML-Dokumente in die Collection zu importieren, Aktualisierungen auf die verschiedenen XML-Dokumente auszuführen und anschließend die gesamte Datenbank im erstellten Format wieder in XML-Dokumente zu exportieren. Hierbei werden die gesamten Strukturen, welche innerhalb der Datenbank erstellt wurden, in eine Ordnerstruktur auf der Festplatte überführt und somit erhalten. Für den Export der XML-Daten auf der Clientseite, kann dies durch verschiedene XQuery Abfragen durchgeführt werden. Auf diese Weise kann z.b. der Inhalt einer beliebigen Collection abgerufen und beim Client in eine Datei gespeichert werden. Falls die weitere Verarbeitung des XML-Dokumentes vorsieht, dass alle Dokumente einer Datenbank zu einem XML-Dokument zusammengefügt werden, kann dies ebenfalls mit einer XQuery Abfrage gelöst und auf der Seite des Clients die empfangene XML-Zeichenkette in eine Datei eingelesen werden. Somit kann man die verschiedensten XML-Dokumente zu einem großen XML-Dokument zusammenfügen.

62 Kapitel 6 Benutzer- & Rechtemanagement Das Benutzermanagement ist eine wichtige Komponente um die Mehrbenutzerfähigkeit eines Datenbanksystems in einer Client Server Umgebung zu gewährleisten. Zu Beginn des Kapitels werden die verschiedenen Benutzerarten des Benutzermanagement vorgestellt. Anschließend werden die definierten Berechtigungen und das hinter dem Rechtemanagement stehende Konzept erläutert. Zum Abschluss des Kapitels werden der Mechanismus, welcher zur sicheren Passwortübermittlung bei der Authentifizierung der Benutzer am Server verwendet wird und das Konzept des Logging beschrieben. 6.1 Benutzerarten Als vordefinierte Benutzerarten sind zwei verschiedene Typen vorhanden. Zum einen gibt es den Root-Administrator, welcher beim ersten Serverstart erstellt wird und stets den Namen Admin erhält. Zusätzlich zum Root-Administrator gibt es noch die normalen Administratornutzer, bei welchen im Gegensatz zum Root-Administrator die Berechtigungen auch wieder entfernt werden können. Neben den beiden Administratorvarianten gibt es noch die normalen Benutzer, welche als Standardnutzer bezeichnet werden. Bei der Erstellung eines Benutzers wird der definierte Benutzername mit den bestehenden Benutzern abgeglichen und bei Übereinstimmung mit einer Fehlermeldung abgebrochen. Vergebene Benutzernamen werden also für weitere Benutzer gesperrt und erst bei Löschung eines Benutzers wieder freigegeben. So kann man grundsätzlich zwischen drei Benutzerarten unterschieden: Administratornutzer ( Root ): Dieser Benutzer kann alle Funktionen des Datenbanksystems ausführen. Der Administrator hat die Möglichkeit den Zustand aller am System registrierten Benutzer einzusehen und zu kontrollieren. Weiterhin kann er eine Übersicht über die aktuell im System eingeloggten Benutzer erhalten, und diese bei eventuellem Bedarf manuell ausloggen um somit die Verbindung mit ihnen zu beenden. Für die Sicherheit des Systems gibt es einen vordefinierten Root-Administrator, welchem keine Rechte entzogen werden können oder das Passwort bzw. der Benutzername verändert werden kann. Dies ist nötig um abzusichern, dass zu jeder Zeit mindestens ein Administrator am System vorhanden ist um das System zu verwalten. Ein Administrator hat die Rechte den kompletten Server inklusive der Benutzer und 56

63 6 Benutzer- & Rechtemanagement 57 Datenbanken zu kontrollieren. So kann ein Administrator z.b. Standardnutzer zu Administratoren ernennen und umgekehrt. Administratornutzer: Wenn der Root-Administrator einen Standardnutzer zu einem Administrator ernennt, wird dieser zu einem normalen Adminstratornutzer. Diesem können im Gegensatz zum Root-Administrator alle Rechte auch wieder entzogen werden. Weiterhin überschreiben bei dieser Benutzerrolle die lokalen Rechte die globalen, so dass dieser Administratornutzer auch von Datenbanken ausgeschlossen werden kann. Standardnutzer: Bei der Erstellung eines Standardnutzers sind grundsätzlich die globalen Lese- und Schreibrechte gesetzt. Diese können durch weitere Einschränkungen bzw. Erweiterungen verändert werden. Lese- und Schreibrechte, welche lokal für die einzelnen Datenbanken vergeben werden, überschreiben für diese Datenbanken die globalen Rechte. Falls keine lokalen Rechte gesetzt sind, gelten die globalen Berechtigungen für den Standardnutzer. 6.2 Berechtigungen Das Rechtemanagement und die damit verbundenen verschiedenen Berechtigungen sind sehr wichtig, um den Zugriff auf die verschiedenen Datenbanken in einem Datenbanksystem zu kontrollieren. Hierdurch kann vor der Ausführung der Prozesse, anhand einer Autorisierung nachgeprüft werden, ob der jeweilige Benutzer den Befehl überhaupt ausführen darf. Weiterhin wird der Zugriff auf die bei der Ausführung des Befehls eventuell benötigten Datenbanken kontrolliert und nur bei ausreichender Berechtigung freigegeben. Um eine flexible Rechtevergabe zu gewährleisten, können globale und lokale Berechtigungen an die einzelnen Benutzer vergeben werden. Diese beiden Berechtigungsarten werden im Weiteren näher erläutert: Globale Berechtigungen: Diese Art von Berechtigungen sind für alle am Datenbanksystem vorhandenen Befehle und Datenbanken gültig. Die globalen Berechtigungen werden zentral im Datenbanksystem in einer Verwaltungsdatei gespeichert. In dieser Datei gibt es für jeden Benutzer einen Eintrag mit dem definierten Benutzernamen und den für diesen Benutzer gesetzten globalen Berechtigungen. Als globale Berechtigungen können Admin, Create, Write, Read und None gesetzt werden. Die Berechtigung Admin steht hierbei für die Eigenschaft, dass alle am System vorhandenen Befehle ausgeführt werden dürfen. Die Create Berechtigung besagt, dass hiermit die verschiedenen Arten der Datenbanken erstellt und gelöscht werden dürfen. Mit der Write Berechtigung darf in die Datenbanken geschrieben, die Datenbank optimiert und der Datenbank die verschiedenen Indexarten hinzugefügt und wieder gelöscht werden. Im Gegensatz hierzu berechtigt die Eigenschaft Read nur zum Öffnen und Lesen von Datenbanken. Die Berechtigung None kennzeichnet

64 6 Benutzer- & Rechtemanagement 58 einen Benutzer als berechtigungslos. Diese Eigenschaft berechtigt den Benutzer aber trotzdem XQuery Anfragen auszuführen, welche keine Daten referenzieren und somit keine Zugriffe auf die Datenbanken benötigen. Hierzu zählen beispielsweise die verschiedenen mathematischen Funktionen von XQuery. Weiterhin kann grundsätzlich ohne Berechtigung eine Veränderung der Eigenschaften (Properties) der Session mittels des Set -Befehls vorgenommen werden. Lokale Berechtigungen: Die lokalen Rechte bestehen aus Write, den beiden untergeordneten Rechten Read und None. Mit den lokalen Berechtigungen können dieselben Aktionen wie mit den globalen Berechtigungen, jedoch nur auf die dafür definierte Datenbank, ausgeführt werden. Lokale Berechtigungen sind nötig, falls die Rechte eines Benutzers bei einzelnen Datenbanken speziell angepasst werden müssen. Die lokalen Rechte überschreiben dann für den jeweiligen Benutzer und die definierte Datenbank die globalen Rechte des Benutzers. Die globalen Rechte sind somit nur noch für alle anderen Datenbanken am System gültig. Wenn keine lokalen Rechte für einen Benutzer gesetzt sind, werden immer die globalen Rechte berücksichtigt. So kann man z.b. einem Benutzer mit globalen Administrator-Rechten trotzdem alle Rechte für eine spezielle Datenbank nehmen, um ihn vom Zugriff darauf auszuschließen. Die lokalen Berechtigungen werden in den MetaDaten der jeweiligen Datenbanken gespeichert. Da für jede Datenbank grundsätzlich MetaDaten erstellt werden, wird hierdurch eine weitere zentrale Speicherung von Benutzerdaten und somit zusätzlicher Verwaltungsaufwand vermieden. Bei der Erstellung einer Datenbank sind keine lokalen Berechtigungen gesetzt. Abbildung 6.1: Berechtigungshierarchie des Rechtemanagements Wie in Abbildung 6.1 dargestellt ist, sind die am Datenbanksystem vorhandenen Berechtigungen hierarchisch aufgebaut. Die Admin-Berechtigung stellt hierbei das höchste Recht in der Hierarchie dar. In der Hierarchie folgend sind die Berechtigungen Create, Write, Read und None. In der Tabelle 6.1 ist eine Auflistung mit den in BaseX vorhandenen Befehlen dargestellt. In der Syntax Spalte ist die zur korrekten Ausführung des Befehls am Server nötige Form des Befehls abgebildet. Die Spalte mit der Überschrift Recht zeigt das für den jeweiligen Befehl mindestens benötigte Rechte an. Mit allen in der Hierarchie darüber liegenden

65 6 Benutzer- & Rechtemanagement 59 Rechten ist die Ausführung des Befehls ebenfalls möglich. Bei Write und Read muss entweder eine globale oder eine der Datenbank entsprechende lokale Berechtigung vorliegen, um diese Befehle ausführen zu können. Der XQuery-Befehl tritt in der Tabelle in dreifacher Form auf, da für jeden der drei Typen von XQuery Abfragen verschiedene Rechte benötigt werden. Die Hierarchie der Berechtigungen ist notwendig, um unnötige Kombinationen wie z.b. Admin und Read oder Write ohne Read für einen Benutzer zu vermeiden. Die Konstellation Write ohne Read wäre im Bezug auf Update Transaktionen mittels XQuery ohnehin unbrauchbar, da Update Transaktionen, durch ihren Aufbau von lesenden und schreibenden Teilen, nur mit Lese- und Schreibrechten ausgeführt werden können. Somit wird vermieden, dass ein Benutzer, nur Schreib- aber keine Leserechte hat und seine Transaktion nicht ausführen könnte. Mit diesem Konzept ist es möglich, den Benutzern nur Rechte für bestimmte Datenbanken zu geben. Weiterhin können die Benutzerarten durch das Setzten der Rechte erweitert oder eingeschränkt werden. Durch die verschiedenen Benutzerarten und die verschiedenen Berechtigungen kann der Administrator die Zugriffsrechte auf die Datenbanken und die Ausführungsrechte der einzelnen Datenbankfunktionen auf dem Server verwalten. Weiterhin kann der Administrator jederzeit den Status und die Aktionen der jeweiligen Benutzer überprüfen. So wird dem Administrator durch die Anzeige der Sessions ermöglicht, dass der er einen Überblick über alle mit dem Server verbundenen Benutzer einschließlich ihrer IP-Adresse und eventuell geöffneter Datenbank erhält. Um die Vergabe der Berechtigungen dem Administrator so einfach wie möglich zu machen, ist für das gesamte Rechtemanagement nur ein Befehl nötig. Dieser setzt sich wie folgt zusammen: GRANT [NONE READ WRITE CREATE ADMIN] (ON [DB]) TO [USER] Durch die Angabe der Datenbankoption können mit diesem Befehl die globalen, wie auch die lokalen Berechtigungen gesetzt werden. Bei der lokalen Rechtevergabe sind nur die ersten drei Berechtigungsoptionen möglich. Alle neu gesetzten Berechtigungen werden dann in die globale Berechtigungsdatei oder in die jeweiligen MetaDaten der Datenbank geschrieben. Für die Überprüfung der Berechtigungen am Server wird jede ankommende Anfrage analysiert und daraus bei fehlerfreier Analyse ein Prozess erstellt. Vor der Prozessausführung werden dann die jeweiligen Rechte des Benutzers mit den für die Ausführung des Prozesses benötigten Recht abgeglichen. Kommt es hierbei zu keiner Übereinstimmung, wird die Ausführung abgebrochen und eine entsprechende Fehlermeldung mit der benötigten Berechtigung an den Client ausgegeben. Hierdurch werden unerlaubte Prozessausführungen und die eventuell damit einhergehenden Datenzugriffe effektiv verhindert. Ein Sonderfall tritt hierbei bei den drei verschiedenen XQuery Abfragen auf, bei welchen erst während des Ausführungsprozesses überprüft wird, welche Datenbanken durch die Anfrage angesprochen werden. Falls eine Anfrage hierbei eine Datenbank enthält, auf welche der ausführende

66 6 Benutzer- & Rechtemanagement 60 Benutzer nicht die benötigten Rechte besitzt, wird die gesamte Ausführung mit einem Fehler beendet. Befehl Beschreibung Syntax Recht close Schließt aktuell geöffnete Datenbank CLOSE None exit Schließt das Programm EXIT None get Anzeigen eines Properties GET [option] None help Zeigt die komplette oder einzelne Hilfe an HELP ([command]) None password Ändern des eigenen Passworts PASSWORD [pw] None set Setzen eines Properties SET [option] ([value]) None xquery Führt eine XQuery Funktion ohne DB aus XQUERY [query] None info Zeigt Informationen über Datenbank INFO [DB INDEX TABLE] Read list Listet alle zugängliche Datenbanken auf LIST Read open Öffnet eine Datenbank OPEN [name] Read xquery Führt eine lesende Anfrage aus XQUERY [query] Read add Fügt Dokumente der Collection hinzu ADD [input] Write create index Erstellt den spezifizierten Index CREATE INDEX [...] Write delete Löscht ein Dokument aus Collection DELETE [name] Write drop index Löscht den spezifizierten Index DROP INDEX [...] Write optimize Optimiert die aktuelle Datenbankstruktur OPTIMIZE Write xquery Führt eine schreibende Anfrage aus XQUERY [query] Write alter db Benennt eine Datenbank um ALTER DB [name] [name] Create create db Erstellt eine Datenbank/Collection CREATE DB [name] Create create fs Erstellt eine Dateisystem Datenbank CREATE FS [name] [path] Create drop db Löscht eine Datenbank DROP DB [name] Create export Exportiert geöffnete Datenbank in XML EXPORT [path] Create alter user Änderung eines Benutzerpassworts ALTER USER [name] [pw] Admin create user Erstellt einen Benutzer CREATE USER [name] Admin drop user Löscht einen Benutzer DROP USER [name] Admin grant Teilt Berechtigungen zu GRANT [...] Admin kill Beendet eine Benutzersession KILL [name] Admin show Zeigt Server Informationen an SHOW [DB USERS SESSIONS] Admin Tabelle 6.1: Befehls- und Berechtigungstabelle in BaseX 6.3 Authentifizierungsmechanismus Der Authentifizierungsmechanismus beschreibt, wie sich die Benutzer am Server anmelden und hierdurch ihre Identität überprüft wird. Durch die Überprüfung können sich nur am Server registrierte Benutzer mit ihrem Client am Server einloggen. Hierbei ist es wichtig ein sicheres Passwortmanagement anzubieten, welches den Benutzern die nötige Sicherheit ihrer Daten bietet. Eine sichere Passwortverschlüsselung ist einer der wichtigsten Grundsätze bei Client

67 6 Benutzer- & Rechtemanagement 61 Server Systemen. Aus diesem Grund wird das Passwortverfahren cram-md5 1 [KCK97] als Authentifizierungsverfahren in BaseX verwendet. Damit das Passwort auf dem Server nicht in Klartext abgespeichert werden muss, ist eine leicht veränderte Form des cram-md5 Verfahrens in Benutzung. Diese abgeänderte Form speichert nur das md5-kodierte Passwort auf dem Server und verhindert somit, das mögliche Auslesen von Passwörtern im Klartext aus der Benutzerdatei auf dem Server. Das cram-md5 Authentifizierungsverfahren wird wie folgt durchgeführt: 1. Der Client sendet einen Login-Request an den Server. Der Server antwortet mit einem Zeitstempel, welcher aus dem aktuellen Wert des System-Timers in Nanosekunden besteht. Dieser Zeitstempel wird als String gesendet und bildet die so genannte Challenge dieses Verfahrens. 2. Der Client empfängt den Zeitstempel vom Server. Dann wird der im Client angegebene Benutzername an den Server gesendet. Danach sendet der Client den so genannten Response, bestehend aus einem md5-hash, welcher das Passwort und den Zeitstempel beinhaltet, an den Server. 3. Der Server erstellt nun einen md5-hash, aus dem zuvor von ihm gesendeten Zeitstempel und dem für den aktuellen Benutzer abgespeicherten md5-kodierten Passwort. Wenn dieser md5-hash mit der zuletzt empfangenen Zeichenkette übereinstimmt war die Authentifizierung erfolgreich und der Benutzer ist am Server eingeloggt. Anschließend sendet der Server eine Mitteilung über den Erfolg der Authentifizierung an den Client. Ein 0-Byte steht hier wiederum für die erfolgreiche und ein 1-Byte für die fehlgeschlagene Anmeldung am Server. Dieses Verfahren hat den Vorteil, dass somit niemals bei einer Anmeldung das alleinige Passwort an den Server übertragen wird und somit nicht abgefangen werden kann. Weiterhin wird durch die Übertragung des Zeitstempels sichergestellt, dass dieser auch vom sich anmeldenden Client zuvor erhalten wurde und somit in dessen Besitz übergegangen ist. Durch die Kombination des Passwortes mit dem aktuellen Zeitstempel ist dies eine ausreichend sichere Methode, um die auf den Server zugreifenden Benutzer zu authentifizieren. 6.4 Logging Als Logging wird das Aufzeichnen von bestimmten wichtigen Informationen auf einem Server bezeichnet. So werden in BaseX alle am Server ankommenden Befehle in einer Log-Datei gespeichert. Jeder Eintrag besteht aus dem Zeitpunkt, der IP-Adresse (mit Port) des Absenders, dem Befehl, einer Erfolgsmeldung und der benötigten Ausführungszeit. 1 cram-md5: Challenge-Response Authentication Mechanism, Message Digest 5

68 6 Benutzer- & Rechtemanagement 62 Die Log-Dateien werden nach ihrem Erstellungsdatum benannt und für jeden Tag neu geschrieben. So ist es sehr einfach eine zeitliche Übersicht über die Log-Aktivitäten zu bekommen. Der Administrator kann durch die Analyse der Log-Dateien die genaue Anzahl an Logins der verschiedenen Benutzer inklusive der Zeit dieser Logins einsehen. Folgendes Beispiel stellt einen Eintrag in einer Log-Datei dar: 16:00: [ :3920] LOGIN admin OK 16:00: [ :3920] XQUERY 1 to 10 OK ms 16:00: [ :3920] LOGOUT admin OK Die erste Zeile im Beispiel zeigt die IP-Adresse und den zugehörigen Benutzer nach erfolgreicher Anmeldung am Server an. Durch die Kombination von IP-Adresse und dem zugewiesenen Serverport, kann somit jeder weitere Befehl eindeutig einem Benutzer zugewiesen werden. In der zweiten Zeile ist somit erkennbar, dass der Benutzer admin den Befehl xquery 1 to 10 gesendet hat. Der Befehl wurde erfolgreich ausgeführt ( OK ) und benötigte die Zeit von ms. Im Falle, dass ein Befehl nicht ausgeführt werden konnte wird anstatt dem OK die Fehlermeldung in die Log-Datei geschrieben. Die Log-Dateien geben somit einen guten Überblick über die gesamten Befehle, welche an den Server geschickt wurden. Wenn man z.b. die Informationen besitzt, dass ein bestimmter Benutzer fehlerhafte oder ungewollte Daten in die Datenbank eingefügt hat, kann man mit der Übersicht der Log-Dateien, sehr einfach herausfinden, welche Daten dies waren und sie hierdurch eventuell wieder entfernen. Wenn man nur eine Uhrzeit bzw. ein Datum der Eintragung der falschen Daten in die Datenbank kennt, kann man hierbei ebenfalls mit Hilfe der Log-Dateien den Befehl und den Benutzer der Falscheintragung ermitteln. Weiterhin könnte auf der Basis der Log-Dateien die Funktionalität des Rollbacks (siehe 8.2.3) aufsetzen und somit die Grundlage für eine weitere wichtige Komponente des Transaktionsmanagements darstellen. Für diesen Zweck muss spezifiziert werden, welche Einträge in den Log-Dateien für das Rollback sinnvoll sind und effektiv genutzt werden können. Weiterhin müsste das Format der Einträge angepasst werden, um die automatische Verwendung für die Rückabwicklung von Transaktionen durchführen zu können. Hierfür könnten die Log-Dateien auch in einem definierten XML-Format gespeichert und somit für die weitere Verarbeitung bereitgestellt werden.

69 Kapitel 7 Verwandte Arbeiten Diese Kapitel gibt einen Überblick über verwandte Arbeiten in weiteren nativen XML- Datenbanksystemen. Hierbei werden drei dieser Vielzahl von Datenbanksystemen im Detail beschrieben. Weiterhin werden die vorhanden Funktionen von BaseX und den untersuchten XML-Datenbanksystemen in einer Übersichtstabelle zusammengefasst dargestellt. 7.1 Überblick XML-Datenbanken Durch die weite Verbreitung von XML-Daten und den weit reichenden Einsatz dieser Daten, ist die Verwendung von XML-Datenbanken aktueller denn je. Dies ist auch durch den Anstieg der Anzahl von nativen XML-Datenbanken, welche von den verschiedensten Organisationen entwickelt werden, zu erkennen. Hierunter fallen diverse Open-Source und freie Programme, wie aber auch kommerzielle Softwareprodukte. Eine bestehende Übersicht 1 listet aktuell 17 freie und 23 kommerzielle Systeme auf. Anhand der Liste ist zu erkennen, dass die meisten der aufgelisteten Datenbanksysteme eigene Strukturen für ihre Datenbanken verwenden. Weiterhin ist an den Details der aufgelisteten Datenbankprodukte zu sehen, dass manche schon sehr lange nicht mehr aktualisiert (z.b. Timber ) oder eingestellt wurden. Für einen gleichwertigen Vergleich werden in den weiteren Kapiteln nur freie Softwareprodukte untersucht, welche über eine Client-Server Architektur verfügen. Für diese Untersuchung 2 wurden exist, Sedna und Qizx ausgewählt. Hierbei werden die Produkte auf die Konzepte und Funktionen des Transaktionsmanagements, Backup & Restore und des Benutzer- und Rechtemanagements dargestellt. Die Funktion des Backup & Restore ist für Mehrbenutzersysteme sehr wichtig, da bei mehreren gleichzeitigen Benutzern an einem System öfters Backups der Datenbank gemacht werden sollten. Des Weiteren werden zusätzliche Funktionen der Programme beschrieben, welche sich ebenfalls als nützliche Funktionen in der Client-Server Architektur in BaseX erweisen würden. Um einen guten Gesamtüberblick über den Markt der XML-Datenbanken zu erhalten 1 siehe Juli Die Informationen über die Produkte wurden größtenteils aus den Webseiten oder Publikationen bzw. durch direkte Anfrage per von den Entwicklern erhalten 63

70 7 Verwandte Arbeiten 64 werden im Weiteren zwei kommerzielle XML-Datenbanken, welche einen großen Anteil am Markt einnehmen, vorgestellt. Mark Logic XML Server Der Mark Logic XML Server 3 ist laut eigener Aussage das führende Datenbanksystem bei der Verarbeitung von XML-Daten. Dieses Produkt wurde speziell für die Speicherung von Dokumenten entwickelt. Das Hauptziel hierbei ist es viele Dokumentarten in einem zentralen Server zu speichern und diese durch die Funktionalitäten von XQuery abzufragen oder mit Updates abzuändern. Das Datenbanksystem arbeitet mit einem Datenbankserver, welcher auf eine hohe Performance und Skalierbarkeit ausgelegt ist. Hierbei werden alle Abfragen auf Datenbanken jeglicher Größe (bis zu mehreren Terabytes) in kürzester Zeit beantwortet. Weiterhin bietet Mark Logic die vollständigste XQuery Implementierung auf dem derzeitigen Markt an. Der XML Server von Mark Logic bietet sämtliche Funktionalitäten von relationalen Datenbanken an. So gibt es ein Benutzermanagement inklusive Rollen und Gruppen, eine Backup und Wiederherstellungsfunktion von Datenbanken, ein ausgereiftes Transaktionsmanagement und ein Web-Frontend mit allen administrativen Funktionen. Weiterhin gibt es ein weiteres Web-Frontend mit dem die verschiedenen Möglichkeiten der XQuery Implementierung ausgeführt werden können. Alles in einem ist die XML-Datenbank von Mark Logic sicher eines der am meisten entwickelten und ausgereiften Systeme auf dem derzeitigen Markt der XML-Datenbanken. Für Updates auf die Daten wird jedoch anstatt XQuery Update ein eigens entwickeltes Konzept eingesetzt, bei dem mehr als zwanzig verschiedene Methoden für die Modifizierung der Daten verwendet werden. EMC Documentum xdb Beim Produkt von EMC Documentum mit dem Namen xdb 4 handelt es sich um eine native XML-Datenbank, welche aus dem früheren Softwareprodukt xhive entstanden ist. Das Datenbanksystem xdb wurde vollständig in Java implementiert und wird ebenfalls als Client-Server Umgebung betrieben. An einem Server können mehrere Datenbanken erstellt werden. Für den Zugriff auf die Datenbank verbindet man sich zu der definierten Datenbank auf dem jeweiligen Server und kann somit die Inhalte der Datenbank mit XQuery abrufen bzw. verändern. Im Gegensatz zu BaseX kann mit dieser Software nur stets eine Datenbank, in welcher sich mehrere Collections und Dokumente befinden können, geöffnet werden. Weiterhin können für jede einzelne Datenbank Gruppen und Benutzer angelegt werden, welche nur für diese Datenbank existieren. 3 siehe Juli siehe Juli 2010

71 7 Verwandte Arbeiten 65 Für eine gute Übersicht der Aktivitäten des Servers gibt es eine Statistik, welche die Anzahl der gesetzten Sperren und eine Auflistung der durchgeführten Transaktionen zeigt. Hierdurch ist zu erkennen, dass beim Transaktionsmanagement zwischen Lese-, Schreibund Updatesperren unterschieden wird. Des Weiteren ist eine Backup & Restore, sowie eine Rollback Funktionalität im Datenbanksystem enthalten. Abschließend ist zu sagen, dass diese native XML-Datenbank ebenfalls viele weitergehende Funktionalitäten anbietet, welche an die Funktionalitäten von relationalen Datenbanken angelehnt wurden. Weiterhin wirbt EMC mit einer hohen Parallelität bei konkurrierenden Schreib- und Lesetransaktionen, welche durch den Einsatz eines Snapshot-basierten Mechanismus für die Abarbeitung der Lesetransaktionen durchgesetzt wird. Für die Durchführung von Modifizierungen an den XML-Daten wird in xdb die gesamte Spezifikation von XQuery Update unterstützt exist Das native XML-Datenbanksystem exist 5 [Mei03] wird seit dem Jahr 2000 von einem Team um den Hauptentwickler Wolfgang Meier als Open-Source Software entwickelt. Als Programmiersprache wird bei diesem Projekt Java verwendet. Die gesamte Konfiguration aller Komponenten des Systems erfolgt über die Definition von XML-Dateien. Die Kommunikation zwischen den Clients und dem Server in exist wird über XMLRPC 6, WebDAV 7 und REST [Fie00] durchgeführt. Diese drei Kommunikationsarten laufen über eine HTTP Schnittstelle ab und verwenden fest definierte Nachrichtentypen. Diese Merkmale lassen erkennen, dass exist für den Einsatz im Web ausgelegt ist und mit Spezialisierung hierauf entwickelt wurde. Bei exist kann wiederum nur eine Verbindung zu einer Datenbank erstellt werden. In dieser Datenbank können dann verschiedene Ressourcen verwaltet werden. Eine Ressource stellt hierbei entweder ein XML-Dokument oder eine Collection in der Datenbank dar. Jede Ressource hat einen Besitzer, welcher standardmäßig dem Ersteller der Ressource gleicht. Weiterhin wird jeder Ressource eine Gruppe von Benutzern zugewiesen. Für die Abfrage der Daten wird die Abfragesprache XQuery in der Version 1.0 unterstützt. Im Gegensatz zu BaseX wird bei Updates das Konzept von XUpdate 8 [Leh01], welches ein Entwurf für einen Vorgänger von XQuery Update ist, verwendet. XUpdate hat sich im Gegensatz zu XQuery Update nie zu einem Standard entwickelt und ist somit deutlich veraltet. Das XUpdate Konzept wird in exist durch einige eigens definierte Update-Erweiterungen ergänzt. Die Updatekonzepte sollen in Zukunft, aber auch auf XQuery Update umgestellt werden. 5 siehe Juli siehe Juli siehe Juli siehe Juli 2010

72 7 Verwandte Arbeiten 66 Durch exist wird der Einsatz der XML Transformationssprache XSLT 9, mit welcher Transformationen (z.b. Konvertierung von XML in HTML) auf XML-Dokumente durchgeführt werden können, ermöglicht. Transaktionsmanagement Bei der Ausführung von Transaktionen verfügt exist über eine Rollback-Funktionalität, welche es ermöglicht abgebrochene Transaktionen rückgängig zu machen. Die Rollback- Funktionalität versetzt somit bei abgebrochenen Transaktionen die Datenbank in den Zustand, wie er vor dem Start der Transaktion war. Für das Konzept des Rollback und Wiederherstellen einer korrupten Datenbank nach einem Systemabsturz usw. wird in exist das Konzept des Journaling verwendet, mit welchem in einer Journal -Datei alle Datenbankoperationen gespeichert werden. Dies ist notwendig um die Übersicht über Transaktionen und Veränderungen der Datenbank zu behalten und die nötigen Informationen zu haben um eine Datenbank im Ernstfall wiederherstellen zu können oder fehlerhafte Transaktionen wieder rückgängig zu machen. Für die Isolation der Transaktionen wird in exist Locking auf Ressourcenebene durchgeführt. Das Locking sperrt also entweder Dokumente oder ganze Collections. Als Sperrtypen werden Read und Write verwendet, welche vor der Transaktion gesetzt und nach der Transaktion wieder freigegeben werden. Backup & Restore Als Funktionalität für das Wiederherstellen von Datenbanken gibt es in exist die Möglichkeit ganze Datenbanken oder einzelne Collections als Backup zu speichern, um diese über die Restorefunktion wieder einlesen zu können. Bei dieser Funktionalität wird ein Archiv im Zip-Format oder ein Ordner mit der ausgewählten Datenbank oder Collection erstellt. In diesem Archiv befinden sich die XML-Ressourcen in der hierarchischen Reihenfolge wie in der Datenbank und weitere Dateien, welche die angelegten Benutzer, Gruppen und Berechtigungen enthalten. Bei der Erstellung des Backups gibt es zwei Varianten. Die erste Variante kann durch einen Client als Hot Backup während die Datenbank weiter in Betrieb bleibt ausgeführt werden. Die zweite Variante ist ein Cold Backup auf der Serverseite, während dessen die Datenbank in einen sicheren Modus versetzt wird und somit während des Backups nicht mehr erreichbar ist. Dies hat den Nachteil, dass während des Backups keine Transaktionen auf die Datenbank gestartet werden können. Weiterhin kann ein Backup inkrementell durchgeführt werden, so dass nur die seit dem letzten Backup veränderten Ressource in das Archiv hinzugefügt werden. Bei einem Restore werden die im Archiv befindlichen Ressourcen zu den in der Datenbank vorhanden Ressourcen hinzugefügt. Falls es zu Namenskonflikten 9 siehe Juli 2010 (XSLT 1.0) & Juli 2010 (XSLT 2.0)

73 7 Verwandte Arbeiten 67 zwischen in der Datenbank bestehenden und im Backup vorhandenen Ressourcen kommt werden die in der Datenbank befindlichen Ressourcen durch den Restoreprozess mit den Ressourcen aus dem Archiv überschrieben. Benutzer- & Rechtemanagement Beim Benutzer- und Rechtemanagement orientiert sich exist an den Konzepten des Unix- Betriebssystem. Hierbei gibt es mit Administrator und Standardnutzer zwei Benutzertypen. Weiterhin können verschiedene Gruppen erstellt werden, zu welchen die einzelnen Benutzer dann zugewiesen werden können. Die Administratoren befinden sich alle in der dafür definierten Administratorengruppe. Für die Authentifizierung am Server wird das Passwort mittels MD5 kodiert versendet. Die angelegten Benutzer sind stets nur auf eine Datenbank registriert und müssen somit für jede weitere Datenbank neu erstellt werden. Im Gegensatz zu BaseX werden bei diesem Konzept nicht den einzelnen Benutzern Rechte für die Datenbanken gegeben, sondern die Rechte werden für die einzelnen Ressourcen vergeben. Die Ressourcen können mit Berechtigungen für die zugewiesene Gruppe, den besitzenden Benutzer (bzw. Ersteller) oder die restlichen Benutzer versehen werden. Die Berechtigungen bestehen hierbei aus Read, Create/Delete und Update. Mit der Berechtigung Read ist es möglich eine Ressource und alle darin enthaltenen Daten zu lesen. Die Berechtigung Create/Delete erlaubt eine Ressource zu löschen bzw. weitere XML-Dokumente oder Collections der Ressource hinzuzufügen. Mit der Update Berechtigung wird die Ausführung von XUpdate auf die jeweilige Ressource gestattet. Weitere Funktionen Eine weitere Funktionalität von exist ist es mit dem Scheduler die Ausführung von Prozessen zu planen und zu einer bestimmten Zeit auszuführen. Hierbei wird zwischen Startup- (Ausführung beim Start von exist), System- (keine weiteren Prozesse dürfen aktiv sein) und Userprozessen unterschieden. Die Besonderheit der Userprozesse ist es, dass man bei ihnen XQuery Transaktonen definieren kann, welche dann zu einem bestimmten Zeitpunkt ausgeführt werden. Im Zusammenspiel mit der Backupfunktion bietet der Scheduler den Vorteil, dass in bestimmten Zeitintervallen Backups der definierten Ressourcen erstellt werden können. Weiterhin unterstützt exist die Funktionalität von Triggern, mit denen Aktionen definiert werden, welche bei einem bestimmten Ereignis ausgelöst werden. Diese Funktionalität kann in exist mit der Definition von Triggern in XQuery oder Java verwendet werden. Beim Eintritt des definierten Ereignis wird beim Java-Trigger eine Java-Klasse gestartet und die darin befindlichen Methoden ausgeführt. Bei den XQuery-Triggern wird die definierte XQuery Abfrage ausgeführt. Die Trigger werden im XML-Format mit Ereignis, Triggertyp, und der zugehörigen Ressource definiert und in der Datenbank registriert. Zusammenfassend ist zu sagen, dass exist sehr viele Funktionalitäten von relationalen

74 7 Verwandte Arbeiten 68 Datenbanken übernommen hat und somit als gutes Beispiel für nützliche Funktionalitäten herangezogen werden kann. Insbesondere im Bereich des Recovery und Rollback, wie aber auch bei den Triggern ist exist ein sehr ausgereiftes System. Durch den Einsatz der drei Kommunikationsinterfaces ist man zwingend an die Verwendung dieser Formate gebunden. Des Weiteren ist zu Erwarten, dass die geplante Unterstützung von XQuery Update sicherlich einige Veränderungen in exist mit sich bringen wird Sedna Sedna 10 (siehe [T10] & [F06]) ist ein natives XML-Datenbanksystem, welches seit dem Jahr 2003 als Open-Source Software zur freien Verfügung für die Benutzer bereitgestellt wird. Das Projekt wird vom Institute for System Programming of the Russian Academy of Science unterstützt und durch das am Institut tätige MODIS Team seit dem Jahr 2003 entwickelt. Für die Implementierung des Systems werden hierbei die Programmiersprachen C und C++ verwendet. In Sedna wird ein eigens entwickelter Datenbankserver verwendet, welcher über TCP/IP Sockets mit den Clients kommuniziert. Hierfür wird ein eigen definiertes Kommunikationsprotokoll mit verschiedenen Nachrichten verwendet. Für die Kommunikation mit dem Server stehen hierbei Clients in den Programmiersprachen C/C++, Java, Python, Perl, C#, PHP, Delphi und Ruby zum Einsatz bereit. Für die Verarbeitung der XML-Daten wird in diesem Projekt XQuery 1.0 als Abfrageund XUpdate als Datenbearbeitungssprache eingesetzt. Transaktionsmanagement Jeder Client besitzt am Server eine Session in der Transaktionen ausgeführt werden können. Jeder Befehl eines Clients wird als eine Transaktion angesehen, wobei eine Transaktion auch mehrere Anweisungen enthalten kann. Transaktionen können von einem Client jedoch nur sequentiell gestartet werden. Dies bedeutet, dass eine Transaktion erst abgeschlossen sein muss bevor eine neue Transaktion gestartet werden kann. Für jede Transaktionen werden bei Sedna ebenfalls die ACID-Eigenschaften gewährleistet. Die Kontrolle der Nebenläufigkeit sperrt bei Sedna mittels S2PL komplette XML- Dokumente in der Datenbank. Hierdurch können Updates auf verschiedene XML-Dokumente in der Datenbank parallel ausgeführt werden. Bei der Verarbeitung der Transaktionen wird ebenfalls die Rollback-Funktionalität angeboten, welche fehlerhafte Transaktionen rückgängig machen kann. Hierbei erstellen die Transaktionen neue Versionen der Daten, welche erst nach erfolgreicher Bestätigung in die Datenbank geschrieben bzw. bei einem Fehler einfach verworfen werden. Weiterhin wird zu Erhöhung der Parallelität von lesenden Anfragen das Konzept des 10 siehe Juli 2010

75 7 Verwandte Arbeiten 69 Multiversioning [PK07] verwendet. Hierbei sind zeitgleich mehrere Versionen von Datenobjekten in zwei Snapshots im System aktiv. Die lesenden Transaktionen erhalten somit ihre benötigten Daten aus den für sie aktuellen Versionen aus den Snapshots zugeteilt. Der größte Vorteil solch eines Systems ist es, dass lesende Abfragen niemals geblockt werden und somit hierbei keine Wartezeit entsteht. Dem gegenüber steht jedoch ein großer Nachteil, welcher durch die Speicher- und Bereitstellung von mehreren Versionen der Datenobjekte entsteht. Hierdurch kann ein enormer Speicherbedarf anfallen. Die Recovery-Funktionalität, welche bei Systemabstürzen etc. zum Einsatz kommt, wird durch das Zusammenspiel eines persistenten Snapshots und dem Erstellen von Log-Dateien gewährleistet. Hierbei werden die Daten des letzten persistenten Snapshots mit den Einträgen der letzten erfolgreich durchgeführten Updatetransaktionen ergänzt und somit die Datenbank auf einen aktuellen und konsistenten Stand gebracht. Backup & Restore In Sedna kann auf zwei verschiedene Arten Backups erstellt und diese wieder in das System eingelesen werden. Hierfür wird als erste Methode die Import/Export Funktionalität angeboten. Mit Hilfe dieser Funktion kann der gesamte Inhalt und die dazugehörigen Metadaten der Datenbank ausgelesen und auf der Festplatte gespeichert werden. Durch die Import Funktion kann dieses Backup dann wieder in das System eingelesen werden. Bei dieser Variante gibt es den Nachteil, dass das Backup nicht aktualisiert werden kann und somit für jeden neuen Zeitpunkt ein komplettes neues Backup erstellt werden muss. Weiterhin gibt es die Möglichkeit ein Hot Backup durchzuführen, welches nach der ersten Erstellung inkrementell aktualisiert werden kann. Beim Hot Backup wird während der Laufzeit des Systems eine Kopie der Datenbank erstellt und alle zur Erstellungszeit bestätigten Transaktionen in das Backup eingeschlossen. Nach dem ersten Hot Backup kann dies immer wieder durch die inkrementelle Funktion aktualisiert werden. Dies geschieht durch die Übertragung der seit dem letzten Backup erneuerten Ressourcen und erspart somit die erneute Erstellung eines Gesamtbackups. Im Gegensatz zum ersten Verfahren bei dem Kopien der gespeicherten XML-Dokumente und der Metadaten erstellt und in einem Ordner abgelegt werden, wird bei dieser Methode eine Gesamtdatei (ähnlich einem Archiv) der Datenbank inklusive aller benötigten Informationen erstellt. Die Hot Backup Methode kann aber im Gegensatz zur Export Variante nur lokal ausgeführt werden. Weiterhin werden bei der Export-Methode alle Aktivitäten an der Datenbank blockiert bis das Backup erstellt wurde. Beim Hot Backup wird das Backup parallel zur Benutzung der Datenbank erstellt. Benutzer- & Rechtemanagement Das Benutzermanagement in Sedna ist wiederum auf die einzelnen Datenbanken beschränkt. Benutzer werden also für die einzelnen Datenbanken angelegt und sind nicht auf allen Datenbanken am Server registriert. Als Benutzerarten sind in Sedna der Administrator und

76 7 Verwandte Arbeiten 70 der Standardnutzer definiert. Bei der Erstellung einer neuen Datenbank wird immer ein Administrator erstellt, welcher ein vordefiniertes Passwort besitzt, um die Administration der Datenbank zu gewährleisten. Jedes Datenbankobjekt bekommt standardmäßig den Benutzer, welche das Objekt erstellt hat, als Besitzer zugewiesen. Als Berechtigungen gibt es zwölf verschiedene Arten (z.b. Load, Drop, Query Delete, Rename ). Diese verschiedenen Typen können an die Benutzer für bestimmte Ressourcen verteilt oder entzogen werden. Für die Bündelung von verschiedenen Berechtigungen können so genannte Roles angelegt werden, welche für alle darin definierten Berechtigungen stehen. Diese Roles können dann ebenfalls den Benutzern zugewiesen werden, so dass sie alle Berechtigungen der Roles erhalten. Weitere Funktionen Als weitere Funktionalität bietet Sedna die Möglichkeit XQuery Triggers zu definieren. Bei der Definition eines Triggers muss der auslösende Ereignis ( INSERT, DELETE und Replace ) der Zeitpunkt ( Before, After ), die betroffenen Daten und die auszuführende Aktion angegeben werden. Die Triggers können hierbei auf einzelne Knoten oder nur einmal für die gesamte Anweisung ausgeführt werden. Weiterhin wird die Funktionalität des Event-Log unterstützt, bei dem die wichtigsten Ereignisse in einer Datenbank mitgeschrieben werden. Bei dieser Funktionalität kann zwischen fünf Sicherheitseinstellungen gewählt werden, welche je nach Einstellung mehr oder weniger Details der Ereignisse in die Log-Datei schreiben. Abschließend kann zusammengefasst werden, dass Sedna ebenfalls über sehr viele Funktionalitäten von relationalen Datenbanken verfügt. Die Backup und Restore Möglichkeiten von Sedna sind sehr ausgereift und wären sicherlich auch im Kontext von BaseX sinnvoll. Durch den Einsatz von XUpdate für die Modifizierung der XML-Daten setzt Sedna allerdings immer noch ein veraltetes Konzept ein, welches es sicherlich zu erneuern gilt Qizx Das Softwareprodukt Qizx 11 wird kommerziell, frei und als Open-Source Version von der Firma XMLMind angeboten. Während die freie Version eine Beschränkung der Datenbankgröße auf 1 GB hat, gibt es bei der kommerziellen Version keine Einschränkungen. Die Open-Source Version von Qizx kann jedoch nicht als volle XML-Datenbank angesehen werden, da hierbei die XML-Dokumente nur temporär im Speicher gehalten werden und bei jedem Start die Datenbank neu erstellt werden muss. Für die folgende Darstellung wurde die freie Version von Qizx verwendet. Die Kommunikation des Clients mit dem Server wird in Qizx nur über die REST-Schnittstelle angeboten. Hierfür muss stets ein Servlet-Container, welcher als Empfänger und Versender der REST-Nachrichten dient 11 siehe Juli 2010

77 7 Verwandte Arbeiten 71 gestartet werden. Als Abfragesprache verwendet Qizx ebenfalls XQuery 1.0. Für die Modifizierung der XML-Daten wird jedoch im Gegensatz zu exist und Sedna, das Konzept von XQuery Update verwendet. Transaktionsmanagement Beim Transaktionsmanagement in Qizx muss der Benutzer manuell eine Sperre für das verwendete Dokument in der Datenbank setzen. Hierbei kann der Benutzer das Dokument, auf welches er zugreifen will, mit einer Schreibsperre versehen, um dies hiermit vor weiteren Zugriffen zu schützen. Falls die Sperre nicht gesetzt wird kann dies bei parallelen Modifizierungen von gleichen Dokumenten zu unberechenbaren Ergebnissen führen. Für die Wiederherstellung von Datenbanken, welche durch einen Systemabsturz etc. inkonsistent oder korrupt wurden, bietet Qizx die Funktionalität des Journaling an. Hierdurch wird die Sicherheit der Datenbank bei Eintreten von unvorhergesehenen Ereignissen gewährleistet. Backup & Restore In Qizx ist es möglich durch ein Hot Backup eine Kopie der Datenbank während der Laufzeit der Datenbank zu erstellen. Eine Restore Funktion ist nicht explizit vorhanden. Das erstellte Backup muss für ein Restore manuell in den Datenbankordner auf der Festplatte verschoben werden, um somit die darin enthaltenen Daten zu überschreiben. Hieran erkennt man, dass ein Hot Backup nur die Aufgabe übernimmt die vorhandenen Daten der Datenbank auf der Festplatte zu kopieren und diese dann als Backup bereit zu stellen. Benutzer- & Rechtemanagement Das Benutzermanagement in Qizx wird durch den Servlet-Container, welcher zusätzlich zum Qizx-Server gestartet wird, ermöglicht. Dies bedeutet, dass Qizx kein eigenes Benutzermanagement besitzt und nur die Rechte der im Servlet-Container definierten Benutzer verwaltet. Das Rechtemanagement wird in Qizx durch den Einsatz einer Access Control List (kurz: ACL) realisiert. Bei diesem Konzept gibt es zu Beginn keine Einschränkungen bei den Berechtigungen der Benutzer. Dies bedeutet, dass alle Benutzer alle Funktionen der Datenbank ausführen können. In der ACL werden dann die jeweiligen Einträge für die Benutzer auf die verschiedenen Datenobjekte erstellt und somit die Berechtigungen eingeschränkt. Die ACL besitzt ein fest definiertes Format für die Einträge und wird im XML-Format erstellt. Alle Berechtigungen, welche für ein Datenobjekt verteilt werden sind ebenfalls für die darunter liegenden Datenobjekte gültig. Falls für weiter unten in der Hierarchie liegende Datenobjekte eigene Berechtigungen vergeben werden, überschreiben diese hierfür die oberen Berechtigungen.

78 7 Verwandte Arbeiten 72 weitere Funktionalitäten Als weitere Funktionalität bietet Qizx die Möglichkeit XQuery Services auf dem Server zu definieren, welche dann durch die Clients am Server aufgerufen werden können. Hierbei werden Skripte mit XQuery Befehlen auf dem Server gespeichert, welche dann durch den Aufruf eines Clients gestartet werden. Die Entwickler von Qizx beschreiben sich selber als Query Engine und nicht als native XML-Datenbank. Aus diesem Grund wird bei diesem Programm nicht viel Wert auf das Transaktionsmanagement gelegt, sondern eher auf die effiziente Abarbeitung von lesenden Abfragen auf die Datenbank. Trotz dieser Eigenschaft unterstützt Qizx als einziges (neben BaseX) der untersuchten Open-Source Programme XQuery Update für die Modifizierung der XML-Daten. Hierbei muss jedoch manuell darauf geachtet werden, dass keine Konflikte oder Anomalien bei der Ausführung von parallelen Transaktionen entstehen. 7.2 Zusammenfassung In diesem Abschnitt wird eine Übersichtstabelle dargestellt, welche aus einer Gegenüberstellung der in den vorherigen Abschnitten beschriebenen nativen XML-Datenbanksysteme exist, Sedna und Qizx mit BaseX besteht. An der Tabelle wird deutlich in welchen Bereichen das Datenbanksystem BaseX noch weiter entwickelt werden muss und in welchen Bereichen es schon fortgeschrittener als andere native XML-Datenbanken ist. An den einzelnen Komponenten wird deutlich wie unterschiedlich die verschiedenen Ansätze der aufgezählten XML-Datenbanken sind. Neben BaseX ist Sedna das einzige Programm, welches eigene Nachrichten für die Kommunikation zwischen Client und Server anbietet. Die Varianten über fest definierte Protokolle (wie z.b. REST) setzen voraus, dass bei jedem Start des Datenbankserver im Voraus ein Web-Server gestartet wird, welcher die ankommenden Nachrichten an den Datenbankserver weiterleitet, bzw. abgehende Nachrichten an den Client versendet. Bei der Definition von eigenen Nachrichten muss jedoch gewährleistet werden, dass es hierbei zu keinen Konflikten und Fehlern beim Versenden der Nachrichten kommen kann. Beim Locking wird deutlich, dass kein Programm tiefere Sperren als auf der Dokumentenebene setzt. Weiterhin ist zu erkennen, dass kein Programm XQuery Update in Kombination mit automatischem Locking implementiert hat. Hierbei könnte BaseX das erste Programm werden, welches XQuery Update mit Locking in Dokumentenebene oder noch feinerer Granularität anbietet. Bei der Funktionalität des Recovery muss BaseX sicher noch weiter entwickelt werden, so dass die Datenbanken auf dem Server auch bei unerwarteten Ereignissen in einen konsistenten Zustand zurückversetzt werden können. Weiterhin ist der Einsatz von Triggern (siehe 8.2.2) sicher eine weitere Funktionalität, welche BaseX mit weiteren Einsatzmöglichkeiten versehen würde.

79 7 Verwandte Arbeiten 73 Für das Erstellen von Backups und die Funktionalität des Restore muss ebenfalls noch eine passende Variante für BaseX entwickelt werden. Am sinnvollsten erscheint hierbei die Hot Backup Methode, welche nach erster Erstellung eines Backups, eine inkrementelle Aktualisierung dessen ermöglicht. In BaseX könnte dies durch das Erstellen eines Archivs mit den Datenbankdaten und dazugehörigen Metadaten, wie Properties und Benutzerdaten, durchgeführt werden. Durch die Komprimierung in einem Archiv könnten so alle Daten in einem Order und einer reduzierten Dateigröße gespeichert werden. BaseX exist Sedna Qizx Client-API Startjahr Größe 2.5 MB 39.3 MB 3.6 MB 6.3 MB Programmiersprache Java Java C/C++ Java Version Release 6.1 April 2010 Release 1.4 Nov 2009 Release 3.3 März 2010 Release 4.0 Juni 2010 Kommunikation Java, C#, VB, PHP, Python, Perl, Ruby, Rebol, Lisp, Haskell eigene Nachrichten Java XMLRPC, WebDAV, REST C/C++, Java, Python, Perl, C#, PHP, Delphi, Ruby eigene Nachrichten Java REST Abfragen XQuery 1.0 XQuery 1.0 XQuery 1.0 XQuery 1.0 Updates XQuery Update XUpdate XUpdate XQuery Update Erweiterungen XQuery Fulltext Lucene Fulltext, XSLT 1.0 & 2.0 eigene Fulltext Funktionen XQuery Fulltext & Scripting, XSLT 1.0 & 2.0 Locking S2PL auf Prozessebene S2PL auf Ressourcenebene S2PL auf Dokumentenebene manuelles Write-Locking Backup & Export in XML (inkrementelles) (inkrementelles) Backup Restore Hot & Cold Backup, Restore Hot Backup, Restore, Import/Export Recovery nicht vorhanden Journaling Snapshot Journaling Triggers nicht vorhanden Java & XQuery XQuery nicht vorhanden Benutzermanagement Rechtemanagement weitere Funktionen Root-Admin, Admins, Standardnutzer lokale & globale Rechte für Benutzer iterative Abfrageausführung, Logging Root-Admin, Admins, Standardnutzer, Gruppen Rechte für Ressourcen Scheduler Root-Admin, Admins, Standardnutzer, Roles lokale Rechte für Benutzer Event Logging, Snapshots für Multiversioning durch Servlet-Container Rechte für Benutzer durch ACL XQuery Services Tabelle 7.1: Übersicht native XML-Datenbanksysteme: BaseX, exist, Sedna & Qizx

80 Kapitel 8 Performance & Erweiterungen Dieses Kapitel beginnt mit einem Abschnitt über Messungen zur Performance der Client- Server Architektur, welcher die Abarbeitung von verschiedenen XQuery Anfragen am Server darstellt um somit einen Überblick über die Ausführungszeiten der Anfragen gibt. Weiterhin werden in diesem Kapitel interessante Erweiterungen beschrieben, welche im Kontext der Client-Server Architektur in XML-Datenbanken zur Anwendung kommen könnten. Zu Beginn des Abschnitts wird die Entwicklung einer grafischen Benutzerschnittstelle dargestellt, mit welcher die Verwaltung und Benutzung der Client-Server Architektur für die Benutzer erleichtert und somit attraktiver gemacht werden könnte. Im zweiten Abschnitt des Kapitels wird das Konzept von Benachrichtigungstriggern vorgestellt, mit welchem bei bestimmten Aktionen die verschiedenen Clients automatisch vom Server informiert werden und so eine interaktive Kommunikation zwischen dem Server und den Clients möglich ist. Zum Abschluss des Kapitels wird die Funktionalität von Rollback beschrieben, mit welchem man die Atomarität bei Transaktionen vollständig garantieren könnte. 8.1 Performance In diesem Abschnitt wird die Durchführung von Testläufen am Server mit extremen Beispielen mit bis zu 500 Clients dargestellt. Hierbei soll die Grundtendenz der Ausführungszeiten bei großer Belastung des Servers dargestellt werden. Bei den verschiedenen Tests wurde die Anzahl der Clients und die Größe der verwendeten Datenbank stets erhöht. Durch die Messungen der Performance kann die Skalierbarkeit des Datenbanksystems überprüft und somit das Verhalten des Systems bei hoher Belastung durch viele Benutzer analysiert werden Vorgehensweise Für die Durchführung der Tests wurden verschiedene Testklassen in Java implementiert, mit welchen die Ausführung der Abfragen durch die Clients und die Zeitmessung der Tests durchgeführt wurde. Diese Testklassen wurden hierbei so implementiert, dass jeder Client in einem eigenen Thread startete und somit die Nebenläufigkeit der Clients auf einem Rechner simuliert werden konnte. Durch diese Implementierung trafen alle Abfragen der 74

81 8 Performance & Erweiterungen 75 Clients fast zeitgleich beim Server ein und es gab hierbei keine Verzögerungen. Die verschiedenen Tests wurden auf einem Testrechner ausgeführt, welcher über die nachfolgend dargestellte Konfiguration verfügte. Komponente Beschreibung Betriebssystem Linux - opensuse Bit Prozessor DualCore AMD Opteron Processor MHz Anzahl Prozessoren 8 RAM 128 GB Festplatte GB Java Version OpenJDK Runtime Environment Tabelle 8.1: Konfiguration des Testrechners für die Performancetests Für die diversen Tests wurden Datenbanken in verschiedenen Größen und mit verschiedenen Daten auf dem Datenbankserver erstellt. Da die Daten des XML Benchmarking Projekts XMark 1 für viele Tests im Bereich von XML-Datenbanken verwendet werden, wurden zwei Datenbanken ( xmark1, xmark2 ) mit Daten von XMark erstellt. Die verschiedenen Datenbanken sind in der folgenden Tabelle zusammengefasst dargestellt. Die Anzahl der Knoten gibt hierbei die Gesamtanzahl aller Elemente und Attribute in der Datenbank an. Die Dokumenthöhe stellt die maximale Anzahl an Unterelementen eines Elternelements dar. Datenbankname Beschreibung Größe Anzahl Knoten Dokumenthöhe factbook Geographiedaten 1.81 MB xmark1 Auktionsdaten 68 MB xmark2 Auktionsdaten 136 MB Tabelle 8.2: Verwendete Datenbanken bei den Performancetests Weiterhin wurden verschiedene XQuery Abfragen definiert, welche ähnliche Durchführungszeiten benötigen. Dies war nötig, um eine gute Darstellung der Ergebnisse in den Diagrammen zu ermöglichen. Weiterhin wurde hierbei darauf geachtet, dass die Abfragen keine Ergebnisse zurückliefern, da dies die Kommunikationszeit unnötig erhöht hätte. Für die Durchführung der Testfälle wurden folgende XQuery Abfragen verwendet: Query 1: for $n in 1 to where $n = 0 return $n Beschreibung: Durchlaufen einer Schleife von 1 bis ohne Datenbankzugriff. Query 2: for $a in //country for $b in //continent where $a = $b return $a Beschreibung: Abfrage von 231 Country -Knoten und Vergleich jedes Knoten mit 5 Continent -Knoten unter Benutzung der Datenbank factbook. 1 siehe Juli 2010

82 8 Performance & Erweiterungen 76 Query 3: for $a in //keyword where $a = 'Toys' return $a Beschreibung: Abfrage von Keyword -Knoten und Vergleich mit dem String Toys unter der Benutzung der Datenbank xmark1. Query 4: for $a in //keyword where $a = 'Music' return $a Beschreibung: Abfrage von Keyword -Knoten und Vergleich mit dem String Music unter der Benutzung der Datenbank xmark2. Für die Durchführung der Tests wurde der Server auf dem Testrechner gestartet. Hierbei wurde der Parameter 2 für eine erweiterte Speicherzuweisung der Java Virtual Machine (JVM) gesetzt. Um mögliche Verzögerungen bei der Kommunikation zwischen Server und den Clients zu umgehen wurden die Tests auf einem Rechner, der sich im selben Netzwerk befand, gestartet. Vor den Tests wurde die verwendete Datenbank von jedem Client in seinem Kontext geöffnet. Hierdurch war bei allen zugreifenden Clients die benötigte Datenreferenz schon geladen und somit kam es zu keinen Benachteiligungen. Damit die Systemauslastung bei allen Clients und Tests in etwa gleich ist, wurde vor jedem Test eine so genannte Warmlauf-Phase mit 100 Abfrageausführungen gestartet. Die Tests für die ersten beiden Diagramme (siehe 8.1 & 8.2) wurden zwanzig Mal und die Tests für die weiteren Diagramme (siehe 8.3 & 8.4) hundert Mal hintereinander ausgeführt. Für die Diagramme mit der Gesamtzeit wurde der Minimalwert der Ergebnisse als Endergebnis verwendet. Weiterhin wurde dieses Endergebnis durch die Anzahl der Clients dividiert, um hieraus die ungefähre durchschnittliche Ausführungszeit eines Clients zu erhalten. Bei den verschiedenen Tests wurde die Zeitmessung beim Start des ersten Clients begonnen und bei Beendigung des letzten Clients gestoppt Ergebnisse Das erste Diagramm (siehe Abbildung 8.1) stellt die Entwicklung der gesamten Abarbeitungszeit des Servers von einer stetig wachsenden Anzahl an Clients dar. Die Anzahl der Clients, welche die Anfrage an den Server sendeten, wurde bei diesem Test von 50 bis 500 erhöht. Auf der X-Achse des Diagramms ist die Anzahl der Clients und auf der Y-Achse die gesamte Abarbeitungszeit aller Clients abgetragen. Hierbei ist zu erkennen, dass die Laufzeit der Gesamtausführung aller Anfragen des jeweiligen Tests konstant im Verhältnis zur Anzahl der Clients ist. So braucht der Server zur Abarbeitung von 500 Clients mit der gleichen Anfrage circa die 10-fache Zeit der Abarbeitung von 50 Clients. Die durchschnittliche Abarbeitung (siehe Abbildung 8.2) eines Clients bleibt somit mit minimalen Abweichungen konstant. Durch das Testen mit verschiedenen Datenbankgrößen ist zu erkennen, dass das Verhältnis auch bei größeren Datenbanken, konstant bleibt. Das Ergebnis zeigt, dass der Server auch 2 -Xmx20000m für einen erweiterten Speicher von 20 GB

83 8 Performance & Erweiterungen 77 unter einer hohen Anzahl an Clients flüssig arbeitet und die Ergebnisse zuverlässig zurück liefert. Ein wichtiger Punkt hierbei ist jedoch stets die Schnelligkeit der Festplatte, welche die Ausführung der verschiedenen Datenzugriffe beeinflusst. Weiterhin kann es vorkommen, dass es bei der wiederholten Ausführung der gleichen Abfrage zu Caching-Effekten des Systems kommt und somit die Abfragen schneller ausgeführt werden, als wenn direkt von der Festplatte gelesen wird. Abbildung 8.1: Gesamtabarbeitung von 50 bis 500 Clients Abbildung 8.2: Durchschnittliche Abarbeitung eines Clients bei 50 bis 500 Clients Die weiteren Diagramme (siehe 8.3 & 8.4) stellen die Entwicklung der Ausführungszeiten bei einer Anzahl von einem bis zu zehn Clients dar. Hierbei ist zu erkennen, dass die Ergebnisse leichten Schwankungen ausgesetzt sind, welche durch Ungenauigkeiten bei den Messungen und durch das Verhalten der JVM zu erklären sind. Die JVM optimiert nach mehreren Aufrufen der gleichen Methoden die Ausführung, so dass die Anfragen nach einer gewissen Zeit schneller werden. Die Grundtendenz von guten Ausführungszeiten von mehreren Anfragen ist in diesen Diagrammen ebenfalls erkennbar. Bei größeren Datenbanken steigt die Ausführungszeit von parallelen Abfragen zuerst stärker an als bei kleineren Datenbanken. Dies lässt darauf schließen, dass die Verschlechterung der Ausführungszeiten vom Scheduling und der Dauer der diversen Festplattenzugriffe abhängig ist. Bei konkurrierenden Zugriffen auf ein gleiche Daten kann es durch den Random- Access, welcher ein ständiges springen zu verschiedenen Positionen der Festplatte darstellt, immer zu Zeitverzögerungen bei der Ausführung der Abfragen kommen. Da der Scheduler der JVM die Auswahl der aktiven Threads übernimmt und somit die Festplattenzugriffe

84 8 Performance & Erweiterungen 78 steuert kann es vorkommen, dass die Position auf der Festplatte stets verändert und somit die Ausführungszeit durch die Rivalität der Threads erhöht wird. Parallele Zugriffe auf Festplatten sind immer langsamer als einzelne Zugriffe. Abbildung 8.3: Gesamtabarbeitung von 1 bis 10 Clients Abbildung 8.4: Durchschnittliche Abarbeitung eines Clients bei 1 bis 10 Clients 8.2 Erweiterungen Grafische Benutzeroberfläche zur Verwaltung des Servers Bei den meisten Datenbanksystemen sind für die Verwaltung und Verwendung der Datenbankserver grafische Benutzeroberflächen vorhanden, welche die Arbeit mit den Servern erleichtern. Da dies auch für ein XML-Datenbanksystem sehr sinnvoll ist, wird in diesem Kapitel eine grafische Benutzeroberfläche beschrieben, welche zur Verwaltung und Verwendung von Servern im XML-Datenbanksystem BaseX verwendet werden kann. Mit den gleichen Komponenten könnte zusätzlich ein Frontend, welches im Web eingesetzt wird, entwickelt werden. Die grafische Benutzeroberfläche beinhaltet alle Funktionen, welche durch das Senden von Befehlen an den Server ausgeführt werden können. Durch die Benutzung der Oberfläche ist es für die Anwender möglich, den gesamten Funktionsumfang, ohne die spezifischen Befehle zu kennen, auszuführen. Um dies möglichst einfach zu halten, ist der Aufbau der Oberfläche übersichtlich und intuitiv gestaltet.

85 8 Performance & Erweiterungen 79 In Abbildung 8.5 ist eine zusammengefasste Darstellung des Verwaltungsprogramms zu sehen. Auf der linken Seite befindet sich die Hauptkomponente des Verwaltungsprogramms. In einer Baumstruktur sind alle Bestandteile der jeweiligen Server abgebildet. Zu dieser Baumstruktur können beliebig viele Serververbindungen hinzugefügt werden, wobei aber immer nur eine Verbindung zeitgleich aktiv sein kann. Durch das Verbinden mit einem Server in der Benutzeroberfläche wird eine Clientverbindung zum Server aufgebaut, über welche die gesamte weitere Interaktion mit dem Server abläuft. Bei jeder Aktion wird eine Nachricht mit dem jeweiligen Befehl an den Server gesendet. Anschließend empfängt der Client die textuelle Ausgabe des Servers und fügt diese passend in die jeweiligen Komponenten der Oberfläche ein. Der Aufbau der Baumstruktur ist wie folgt definiert. Die Serververbindung stellt stets den Wurzelknoten des jeweiligen Teilbaumes dar. Darunter sind die einzelnen am Server registrierten Datenbanken und die globalen Benutzereinstellungen ( Logins ), sowie die Aktivitätsübersicht des Servers angebracht. Bei den Datenbanken kann der gesamte Inhalt ( Content ), sowie die lokalen Benutzerrechte und die Datenbankeigenschaften angezeigt werden. Die Datenbankeigenschaften beinhalten z.b. die Anzahl von XML-Elementen und Attributen in der Datenbank. Weiterhin wird eine Pfadzusammenfassung der Datenbank, welche eine gute Übersicht über das Gesamtdokument gibt, in den Eigenschaften dargestellt. Der Inhalt der Datenbank wird wie in Abbildung 8.6a dargestellt, in einer dem XML-Format des Dokumentes entsprechender Darstellungsform abgebildet. Die lokalen und globalen Benutzereinstellungen (siehe Abbildung 8.6c) werden in einer Tabelle verwaltet. Bei den globalen Benutzereinstellungen sind zusätzlich die Optionen zum Erstellen und Löschen von Benutzern gegeben. Weiterhin ist es hierbei möglich das Passwort des Benutzers zu verändern. In der lokalen Variante wird nur die Tabelle abgebildet, in der die jeweiligen Berechtigungen verändert werden können. Da nicht alle globalen Benutzer lokale Rechte auf den Datenbanken besitzen, ist bei den lokalen Benutzereinstellungen zusätzlich ein Kombinationsfeld mit allen Benutzern und einem Add -Button für das Hinzufügen zu der jeweiligen Datenbank vorhanden. Der Root-Administrator wird in der globalen Tabelle als deaktiviert dargestellt, da bei diesem keine Berechtigungen verändert werden können. Da es aber möglich ist beim Root- Administrator das Passwort über den Alter -Button zu verändern, wird er trotzdem in der Benutzerliste der globalen Benutzer dargestellt. In den lokalen Tabellen der Datenbanken ist der Root-Administrator nicht vorhanden. Der Managementorder umfasst die drei Unterpunkte der Server Log-Dateien, der aktiven Sessions (siehe Abbildung 8.6b) und der Benachrichtigungstrigger. Bei den aktiven Sessions werden alle zum Server bestehenden Verbindungen und die am Server geöffneten Datenbanken angezeigt. Die Server Logs umfassen alle jemals am Server aufgezeichneten Log-Dateien. Der gerade aktuelle Mitschnitt der Aktivitäten wird hierbei mit Current gekennzeichnet und steht stets an erster Stelle. Alle Log-Dateien sind nach Datum sortiert in der Baumstruktur angeordnet. Im Menü der Benachrichtigungstrigger können diese verwaltet und verändert werden. Hierbei besteht die Möglichkeit neue Trigger zu erstellen,

86 8 Performance & Erweiterungen 80 die verschiedenen Clients den Triggern zuzuweisen bzw. abzuwählen und vorhandene Trigger zu löschen. In der rechten Seite werden in einer Karteireiterstruktur die verschiedenen geöffneten Elemente angeordnet. Hierdurch ist ein schnelles Umschalten durch die verschiedenen Komponenten möglich. Weiterhin ermöglicht diese Struktur, dass viele verschiedene Komponenten gleichzeitig geöffnet sein können und trotzdem eine gute Übersicht über das Gesamtprogramm erhalten bleibt. Dies ist in Abbildung 8.5 gut zu erkennen, da hier mehrere Komponenten geöffnet sind. Weiterhin ist hierbei das Fenster des Resultats der Anfrage dargestellt, welches sich auf zwei Komponenten, das Ergebnis und die Informationen, aufteilt. Bei den Informationen werden zum Beispiel die Ausführungszeit und die Anzahl der durch die Anfrage erzielten Ergebnisse abgebildet. Abbildung 8.5: Grafische Benutzeroberfläche zur Verwaltung des Servers

87 8 Performance & Erweiterungen 81 Über der Baum- und Karteireiterstruktur ist eine Werkzeugleiste mit Buttons angebracht, welche die Funktionen der Verbindungsverwaltung und die Erstellung, Speicherung und Ausführung von Anfragen beinhaltet. Mit dem Connection -Button öffnet sich ein Dialog in dem neue Serververbindungen erstellt und hinzugefügt oder vorhandene Verbindungen verändert und gelöscht werden können. Der New Query -Button der Werkzeugleiste öffnet im rechten Teil des Hauptfensters einen Karteireiter, in welchem dann die XQuery Abfrage formuliert werden kann. Für die Ausführung wird immer die im Kombinationsfeld ausgewählte Datenbank als Kontext Datenbank verwendet. Mit dem Execute -Button wird die Abfrage an den Server gesendet und das empfangene Ergebnis unter dem Abfragefenster im Textformat dargestellt. Durch die Karteireiter ist es möglich mehrere Anfragen gleichzeitig zu formulieren. Zum Server kann stets aber nur eine Abfrage gleichzeitig gesendet werden. (a) Inhalt (b) Aktive Sessions (c) Logins Abbildung 8.6: Drei Elemente der Karteireiterstruktur des Verwaltungsprogramms Benachrichtigungstrigger Als Trigger werden Schalter bezeichnet, welche bestimmte Ereignisse und die daraus resultierende Aktionen definieren. Ein Trigger löst also immer dann eine Aktion aus wenn ein zuvor definiertes Ereignis eingetreten ist. Hieraus wird ersichtlich, dass Trigger auf die verschiedenste Arten definiert und realisiert werden können. Im Kontext von relationalen