conference on Database Systems in Busines

School of Information Technology
Proceedings of the
Studierendenprogramm at the 12th GIconference on Database Systems in
Business, Technology, and Web (BTW)
March, 6 2007, Aachen, Germany
Hagen Höpfner (IU Bruchsal, Germany)
Stefan Conrad (Uni Düsseldorf, Germany)
Technical Report 01/2007
Bruchsal, February 2007
ISSN 1861-9231 (print version)
ISSN 1861-924X (online version)
Dr. Hagen Höpfner is Lecturer in Databases and Information Systems at the
International University in Germany.
Prof. Dr. Stefan Conrad holds the chair on Databases and Information Systems at the
Heinrich-Heine-Universität in Düsseldorf, Germany.
Contact: [email protected]
International University in Germany
School of Information Technology
Campus 3
D-76646 Bruchsal
Germany
http://www.i-u.de
I
Vorwort
Nach der erfolgreichen Etablierung eines Studierendenprogramm bei der 9. BTW 2001 in Oldenburg
wurde auch bei der 10. BTW 2003 in Leipzig und bei der 11. BTW in Karlsruhe Studierenden die
Möglichkeit gegeben, Forschungsluft zu schnuppern. Die 12. BTW-Konferenz liegt nun hinter uns, und
auch in ihrem Rahmen fand im März 2007 in Aachen ein Studierendenprogramm statt. Erneut wurde
Studierende die Möglichkeit geboten, über ihre Studien-, Diplom-, Projekt-, Bachelor-, Master- oder
Praktikumsarbeiten in einem 15 bis 20-minütigen Vortrag zu berichten. Kurzfassungen der vorgestellten
Arbeiten sind in dem hier vorliegenden Beitragsband gebündelt.
Deutschland ist Weltmeister! Ok, für den Titel im Fußball hat es 2006 nicht gereicht, aber im Handball waren unsere Jungs 2007 unschlagbar. Ähnlich sieht es mit der Nachwuchsförderung an Hochschulen aus. Dass sich unsere Studierenden im Datenbank- und Informationssystemeumfeld nicht verstecken
müssen, beweist die beachtliche Qualität der eingereichten Beiträge. Lothar Späth sagte einmal:
Wir müssen Professoren und Studenten wieder etwas abverlangen. Wir müssen vor allem
”
darauf achten, wieder Stürmer in und für diese Gesellschaft auszubilden und nicht allein
Schiedsrichter. Wir haben unzählige Schiedsrichter in der Wohlstandsgesellschaft ausgebildet, die jedem, auch in der internationalen Welt, die Spielregeln erläutern, ohne selber
spielen zu können.“
Dieser Beitragsband beweist, dass wir in Forschung und Lehre auf dem richtigen Weg sind, aber noch
lange nicht am Ziel. Das erste Studierendenprogramm in der Geschichte der BTW war ein zweitägiger
Workshop. In diesem Jahr mussten mehrere Beiträge, die inhaltlich gut bis ausgezeichnet waren, leider
aufgrund der Beschränkung auf einen Tag abgelehnt werden. Ob dieser Tatsache sollte für die Zukunft
noch mehr Platz für Studierendenbeiträge im Rahmen der BTW eingeplant werden.
Teile der angefallenen Kosten der Veranstaltung wurden von Sponsoren getragen. Somit war auch die
Teilnahme der Vortragenden beim Studierendenprogramm und an der Tagung selbst kostenlos möglich.
An dieser Stelle seien der Gesellschaft für Informatik (GI) e.V., dem Fachbereich Datenbanken und Informationssysteme (FB DBIS) der GI und Accenture für ihre finanzielle Unterstützung gedankt. Ein
herzliches Dankeschön geht auch an den dpunkt.verlag, welcher dem Studierendenprogramm erneut kostenlose Fachbücher gespendet hat.
Bruchsal, im Februar 2007
Hagen Höpfner
Organisations- und Programmkomitee
Stefan Conrad (Heinrich-Heine-Universität in Düsseldorf)
Hagen Höpfner (International University in Germany, Bruchsal)
INHALTSVERZEICHNIS
III
Inhaltsverzeichnis
Sadet Alčić
(Uni Düsseldorf / Prof. Dr. Stefan Conrad)
Konzeption und Implementierung einer Datenbank zur Speicherung, Verwaltung und Retrieval
von Bilddaten
1
Sebastian Bächle
(TU Kaiserslautern / Prof. Dr. Theo Härder)
Auftragsorientierte Kopplung von Produktdatenmanagement-Systemen
4
Andre Bolles
(Uni Oldenburg / Prof. Dr. Hans-Jürgen Appelrath)
Rettungswachdienste an Binnengewässern webbasiert und aktiv verwalten
7
Alexandru Caracas, Iulia Ion, Mihaela Ion
(IU Bruchsal / Dr. Hagen Höpfner)
Web Services and Data Caching for Java Mobile Clients
10
Mathias Detzner, Christian Beucker, Florian Sonennschein
(FH Düsseldorf / Prof. Dr.-Ing. Thomas Rakow)
Soccertrend
13
Tobias Exner
(Uni Jena / Prof. Dr. Klaus Küspert)
Techniken zur Approximation und Optimierung von Performancefunktionen
16
Christian Helmchen
(Uni Leipzig / Prof. Dr. Erhard Rahm)
Teiresias: Datenbank-basiertes Online-Wörterbuch für Griechisch
19
Bernhard Jäcksch
(TU Dresden / Prof. Dr.-Ing Wolfgang Lehner)
Integration von Stichprobenverfahren in ein rel. DBMS
22
Thomas Jörg
(TU Kaiserslautern / Prof. Dr.-Ing. Stefan Deßloch)
Regelbasiertes Visualisieren und Editieren beliebiger Graphen
25
Andreas Lübcke
(Uni Magdeburg / Prof. Dr. Gunter Saake, Dr. Eike Schallehn)
Self-Tuning für Bitmap-Index-Konfigurationen
28
Emmanuel Alexander Müller
(RWTH Aachen / Prof. Dr. Thomas Seidl)
Subspace Clustering für die Analyse von CGH Daten
31
Martin Richtarsky
(TU Ilmenau / Prof. Dr. Kai-Uwe Sattler)
CouPé: Ein Query Processor für UniStore
34
Gunnar Söllig
(Uni Rostock / Prof. Dr. Andreas Heuer)
Multidimensionale Indexierung in ORDBMS
37
Marcus Wenzel
(Uni Jena / Prof. Dr. Birgitta König-Ries)
Konzeption und prototypische Realisierung einer Portalanwendung zur föderierten Suche im
Online-Angebot einer Bibliothek
39
1
Konzeption und Implementierung einer Datenbank
zur Speicherung, Verwaltung und Retrieval von Bilddaten
Sadet Alčić
[email protected]
Lehrstuhl für Datenbanken und Informationssysteme
Institut für Informatik, Heinrich-Heine-Universität
D-40225 Düsseldorf, Germany
Betreuer: Prof. Dr. Stefan Conrad
Multimediale Daten bilden heutzutage einen wesentlichen Bestandteil der heutigen Informationsquellen und gewinnen in der Kommunikationswelt stetig an Bedeutung. Die rasante Entwicklung des Internets
und dessen Verfügbarkeit für jedermann, und die kostengünstige Hardware fordern diesen Prozess enorm.
Um weiterhin effizient in Datenbeständen suchen zu können, sind Verwaltungsmechanismen notwendig,
welche auf die Besonderheiten dieser neuen Medien ausgerichtet sind. Relationale Datenbanksysteme
sind prinzipiell in der Lage Objekte wie Bilder als Binary Large OBjects (BLOBs) zu speichern und zu
verwalten. Somit wäre eine exakte Suche basierend auf der Byterepräsentation der Bilder umsetzbar.
Beispielsweise bei Bildern kann jedoch in Abhängigkeit von verschiedenen Parametern die Byterepräsentation zweier, für den Menschen sehr ähnlicher Bilder, sich komplett unterscheiden, so dass eine exakte
Suche für viele Anwendungen ein zu scharfes Kriterium darstellen würde. Im Rahmen der Bachelorarbeit
[Alc05] werden unterschiedliche Ansatzweisen aus der Forschung zur Suche in Bildbeständen präsentiert
und diskutiert. Die Picture Storing Multimedia Database (PSMMDB) stellt das in dieser Arbeit entstandene Bildverwaltungssystem dar.
1
Suchparadigmen in Bilddatenbanken
Es gibt zahlreiche Strategien, um nach Bildern in Bilddatenbanken zu suchen. Sie unterscheiden sich
hauptsächlich in der Aufbereitung der Bilder zur Suche. Auf drei meist verwendete Mechanismen wollen
wir hier kurz eingehen.
Ein sehr primitiver Ansatz ist die Suche über die Struktur- oder Metadaten des Bildes, auch als
Metasuche [RHC97] bekannt. Dabei werden zu einem Bild auch dessen Metadaten, wie Dateiname,
Format, Höhe und Breite ermittelt und in der Datenbank abgelegt und stehen für die Spezifikation der
Suchanfrage zur Verfügung. Klarer Vorteil dieses Verfahrens ist die Einfachheit in der Implementierung
und seine effiziente Suche, denn die Strukturdaten von Bildern lassen sich ohne großen Aufwand ermitteln
und die Anfragebearbeitung erfolgt wie bisher basierend auf dem exakten Retrieval-Modell. Da Metadaten
jedoch im Wesentlichen die Struktur von Bildern beschreiben und somit eher inhaltsunabhängig sind, ist
ein auf diesen Ansatz basierendes System für die inhaltsbasierende Suche ungeeignet.
Als nächstes bietet sich ein Verfahren an, welches unter dem Begriff Stichwortsuche [HSWW03,
RHC97] bekannt ist. Hierbei wird jedes einzelne Bild in dem Datenbankbestand von einem Menschen
analysiert und durch Stichworte beschrieben (annotiert). Diese Annotationen liefern konzeptuelle Beschreibungen und ordnen die Bildaten somit zu high-level Konzepten zu, die wiederum für die Suche
auf semantischer Ebene verwendet werden. Diese Vorgehensweise liefert uns Verfahren, mit dem auch inhaltsbezogene Anfragen gestellt werden können, allerdings steht dem leider der hohe personelle Aufwand
gegenüber, welcher für großere Datenbankbestände kaum vorstellbar ist. Ein weiterer Nachteil ist die
Subjektivität des Menschen bei der Interprätation und die verschiedenen Abstraktionsebenen, in denen
die abgebildeten Objekte beschrieben werden können.
Als Konsequenz ist ein Verfahren notwendig, das inhaltsbezogene Informationen automatisch aus
dem Bild extrahiert und für die Suche bereitstellt. Damit leiten wir auch zum nächten Ansatz über,
dem Content Based Image Retrieval (CBIR) [FBF+ 94, RHC97, Hua99], welches mit Hilfe von
statistischen Methoden der Bildverarbeitung versucht, aus den Rohdaten des Bildes repräsentative Eigenschaften (Features), wie z.B. Farb-, Textur- oder Formeigenschaften, zu extrahieren und für die Suche
2
bereitzustellen. Ein großer Vorteil von CBIR ist die automatische Erschließung von inhaltsbezogenen Informationen. Wir haben uns in der Arbeit für diesen Ansatz entschieden, da er völlig ohne redaktionellen
Aufwand auskommt und dennoch den tatsächlichen Inhalt der Bilder in Betracht zieht.
2
Das implementierte System PSMMDB
Im Rahmen dieser Bachelorarbeit ist ein in Java implementiertes Image Retrieval System, das PSMMDB
(Picture Storing Multimedia Database) entstanden, welches den CBIR Ansatz verwendet und auf dem
Vektorraummodel (VRM) basiert. Das VRM zeichnet sich dadurch aus, dass die aus einem Bild extrahierten skalaren Merkmale zu einem Vektor eines endlich dimensionalen Vektorraums aufgefasst werden
und somit dieses Bild in ein wohldefiniertes System überführen. Die Ähnlichkeit bzw. die Unähnlichkeit
zwischen zwei Bildern entspricht dann dem durch eine in diesem Vektorraum definierten Distanzfunktion
ermittelten Abstand zwischen den Merkmalsvektoren dieser Bilder. Definitionsgemäß sind dann bei kleinem Abstand die Bilder sehr ähnlich und bei großem eher unähnlich, wobei die Qualität dieser Aussage
von den extrahierten Merkmalen abhängt. Vom System werden die Durchschnittswerte von Rot-, Grünund Blauanteil des Bildes und auch die Durchschnittswerte der Farbkomponenten des YUV Farbraums
extrahiert. Zusätzlich ermitteln wir die Histogramme von Bildern in den Farbkomponenten Rot, Grün
und Blau. Die Distanzfunktion kann zwischen den wichtigsten Ln -Normen variiert werden und auch
Merkmalsgewichtungen können explizit angegeben werden, wodurch die Relevanz einzelner Merkmale
zusätzlich spezifiziert wird. Abbildung 1 enthält eine schematische Darstellung der Komponenten von
PSMMDB.
Abbildung 1: PSMMDB Architektur
Den ersten Schritt stellt die Speicherung der Bilddaten in der Datenbank dar. Dazu werden die Merkmale der Bilder mittels des Java Advanced Imaging API [JAI] aus den Rohdaten des Bildes extrahiert
und in einem Vektor dargestellt, der zu der Byterepräsentation des Bildes in der Datenbank abgelegt
wird. Bei dem Query-by-Image-Ansatz (QBI) gibt der Benutzer dem System ein Anfragebild vor, welches ebenfalls zunächst durch die Merkmalsextraktion in einen Vektor überführt wird. Anschließend kann
die Distanz zwischen diesem Vektor und allen in der Datenbank gespeicherten Vektoren mit Hilfe der
gewählten Distanzfunktion ermittelt werden. Dem Benutzer werden die Retrievalergebnisse in aufsteigender Reihenfolge bezüglich des Abstandes zum Anfragebild (oder Relevanz) vorgestellt. In Abbildung 2
ist der Retrieval-Bereich des Systems dargestellt, der für die Anfragespezifizierung und die Ausgabe
der Ergebnisse zuständig ist. Eine weitere Möglichkeit Anfragen mit einem Bild zu stellen liefert uns
die Query-by-Histogramm-Methode. Hierbei kann der Benutzer eines der extrahierten Farbhistogramme
des Bildes wählen und damit die Anfrage starten. Dieses wird dann mit den entsprechenden Farbhistogrammen der Datenbankbilder verglichen und liefert ebenfalls eine nach Ähnlichkeit sortierte Liste
von Bildern. Die Kommunikation mit der Datenbank aus der Java Applikation erfolgt mittels des Java
Database Connectivity API [JDB].
3
Abbildung 2: Retrievaloberfläche von PSMMDB
3
Ausblick
Die PSMMDB liefert für ausgewählte Anwendungsbereiche bereits sehr gute Ergebnisse [Alc05]. Für
Benutzer, die kein passendes Anfragebild haben, empfiehlt sich die Anfrage mittels ausgesuchter Farbe
(Query-by-Color oder QBC). Möglich wäre zusätzlich die Verwendung von Relevance Feedback -Mechanismen [Roc71], bei denen das System dem Benutzer vorläufige Ergebnisse präsentiert und dieser bewertet
dann die Bilder einzeln. Diese Bewertung fließt dann in der erneuten Berechnung mit ein. Dadurch kann
das System sich schrittweise den Präferenzen des Benutzers anpassen. Eine Erweiterung der low-levelEigenschaften um weitere Textur- und Formmerkmale kann die Qualität der Ergebnisse noch wesentlich
steigern. Die Ähnlichkeitssuche erfolgt durch einen iterativen Durchlauf aller in der Datenbank enthaltenen Objekte. Mittels geeigneter Indexstrukturen kann die Suche noch effizienter implementiert werden.
Literatur
[Alc05]
Alcic, Sadet: Konzeption und Implementierung einer Datenbank zur Speicherung, Verwaltung und Retrieval von multimedialen Daten, Institut für Informatik, Universität Düsseldorf,
Bachelorarbeit, 2005
[FBF+ 94]
Faloutsos, Christos ; Barber, Ron ; Flickner, Myron ; Hafner, Jim ; Niblack, Wayne ;
Petkovic, Dragutin ; Equitz, William: Efficient and Effective Querying by Image Content.
In: Journal of Intelligent Information Systems 3 (1994), Nr. 3/4, S. 231–262
[HSWW03] Hollink, L. ; Schreiber, G. ; Wielemaker, J. ; Wielinga, B.: Semantic Annotation of Image Collections. In: Workshop on Knowledge Markup and Semantic Annotation,
KCAP’03, 2003
[Hua99]
Huang, J.: Image Indexing using Color Correlogramm. In: IEEE Int. Conf. on Computer
Vision and Pattern Recognition, 1999, S. 762–768
[JAI]
Java Advanced Imaging (JAI) API. – http://java.sun.com/products/java-media/jai
[JDB]
Java Database Connectivity (JDBC) API. – http://java.sun.com/javase/technologies/
database/index.jsp
[RHC97]
Rui, Yong ; Huang, Thomas S. ; Chang, Shih-Fu: Image Retrieval: Past, Present, and
Future. In: International Symposium on Multimedia Information Processing, 1997
[Roc71]
Rochhio, J. J. J.: Relevance Feedback in Information Retrival. Prentice Hall, Englewood
Cliffs, New Jersey, USA, 1971
4
Auftragsorientierte Kopplung von
Produktdatenmanagement-Systemen
Sebastian Bächle
AG Datenbanken und Informationssysteme
Fachbereich Informatik
Technische Universität Kaiserslautern, Germany
s [email protected]
1
Ausgangssituation
Die Aufgabe von Produktdatenmanagement-Systemen (PDMS) ist die Verwaltung von produktdefinierenden Daten und deren Integration in die Geschäftsprozesse eines Unternehmens.
Sie speichern alle Informationen, die in den einzelnen Phasen eines Produktlebens anfallen,
angefangen bei der Entwicklung, über die Produktion bis hin zur After-Sales-Phase.
Die Untersuchungen finden im Kontext des Produktdatenmanagements eines deutschen Automobilkonzerns statt. Aufgrund der unterschiedlichen Anforderungen der einzelnen Bereiche
wie z. B. CAD-Konstruktion oder E/E kommen dort mehrere, unterschiedliche PDMS zum
Einsatz, bei denen die Struktur und die Organisation der verwalteten Produktdaten auf das
jeweilige Einsatzgebiet zugeschnitten sind. Auf logischer Ebene existieren dabei aber Beziehungen zwischen diesen Daten, weshalb es notwendig ist, diese systemübergreifend Verknüpfen und
Austauschen zu können. Gerade bei übergeordneten Geschäftsprozessen wie z. B. der Konstruktionsfreigabe, bei denen die lückenlose Verfolgbarkeit aller Abhängigkeiten und die Absicherung
der Abläufe absolut geschäftkritisch sind, wird eine Kopplung der einzelnen PDMS benötigt.
Deshalb müssen geeignete Konzepte entwickelt werden, mit denen diese Daten prozessgerecht
und effizient ausgetauscht werden können, ohne jedoch die lokalen Prozesse innerhalb der Teilbereiche zu beeinträchtigen. Darüber hinaus muss die Kopplungslösung flexibel genug sein, um
schnell und damit kostengünstig auf sich ändernde Prozessanforderungen reagieren zu können.
2
Ziel der Arbeit
Bei der Kopplung von PDMS müssen komplexe Objekte und Strukturen übertragen werden
können, wobei deren Konzeption und Repräsentation jedoch von den bereichsspezifischen und
systeminternen Gegebenheiten bestimmt werden. Solche internen Eigenschaften gilt es möglichst
auszublenden und den Austausch auf die prozessrelevanten Informationen zu reduzieren. Diese
Arbeit betrachtet einen auftragsorientierten Ansatz zur Kopplung von PDMS, bei dem der Fokus
auf der Kapselung von lokalen Systemeigenschaften und der prozessgerechten Abbildung der
Daten liegt. Neben der Untersuchung der konzeptionellen Eignung dieses Ansatzes sollten auch
praktische Erfahrungen damit gesammelt werden. Deshalb wurde mit Hilfe eines entsprechenden
Frameworks ein Prototyp für ein realistisches Anwendungsszenario erstellt.
3
Probleme bei der PDMS-Kopplung
Die heutige Standardlösung für die lose Kopplung von Informationssystemen lautet Web Services
inklusive der vielfältigen Erweiterungen wie z. B. WS-Transactions und WS-Security. Im PDMSUmfeld sind Web Services alleine allerdings nicht ausreichend, da es sich dabei lediglich um eine
Technologie und nicht um ein Architekturkonzept handelt. Im Fokus stehen hier deshalb mit 5
der Datenabbildung und der Schnittstellengestaltung zwei konzeptionelle Fragestellungen, die im
PDMS-Umfeld nicht alleine durch den Einsatz der Technologie Web Services abgedeckt werden
können.
Mit Hilfe standardisierter XML-Schemata ist es möglich alle Daten eines PDMS als beliebig komplexe Produktstrukturen in einem universellen Format zur Verfügung zu stellen. Dennoch ist die Repräsentation in einem globalen Kodierungsschema für eine Kopplung noch nicht
ausreichend. Es fehlen die notwendigen Informationen zur prozessgerechten Abbildung der ausgetauschten Daten auf die einzelnen lokalen Datenmodelle. Jedem Konsumenten eines solchen
Web Service müsste daher zusätzliches Wissen über das lokale Datenmodell des Anbieters und
auch über die prozessgerechte Abbildung dieser Daten auf das eigene, lokale Datenmodell zur
Verfügung stehen. Darüber hinaus ist der Einsatz solcher Standardschemata aufgrund ihrer
generischen Konzeption mit einem höheren Entwicklungsaufwand verbunden, der sich jedoch
nicht immer auszahlt. Häufig werden nämlich nur Teilausschnitte der Produktstrukturen für
den Austausch benötigt.
Das zweite Problem ist die Gestaltung einer geeigneten Schnittstelle, die z. B. als Web Service
zur Verfügung gestellt werden soll. Ein typischer Ablauf im PDMS-Umfeld beginnt mit der Suche
eines bestimmten Objektes, von dem aus dann über die komplexen Produktstrukturen navigiert
wird. Eine Schnittstelle mit den elementaren Funktionen für die Suche und den navigierenden
Zugriff ist damit zwar sehr allgemein einsetzbar, allerdings auch potentiell ineffizient. Zudem
erfordert sie von den Konsumenten zusätzliches Wissen über die interne technische und fachliche Organisation der Daten des Anbieters. Eine Schnittstelle die komplexe Operationen und
Ergebnisse anbietet, ist im Gegensatz dazu effizienter und kann auch die internen Eigenschaften eines Systems besser verbergen. Die Operationen sind dann aber häufig so spezifisch, dass
Änderungen der Prozess-Anforderungen schnell einen hohen Anpassungsaufwand verursachen.
An diesen beiden Kritikpunkten setzt der auftragsorientierte Kopplungsansatz an. Jeder
von einem Prozess vorgesehene Datenaustausch wird dabei als Auftrag betrachtet, für den die
benötigten Daten individuell zusammengestellt und repräsentiert werden können. Der Ansatz
konzentriert sich auf die flexible Umsetzung von Standardaufgaben und die Kapselung der internen Systemeigenschaften.
4
Der auftragsorientierte Ansatz
Im auftragsorientierten Ansatz wird die Kopplungsaufgabe durch mehrere, so genannte Agenten
realisiert. Der Hersteller des verwendeten Frameworks bezeichnet es daher auch als agentenbasierten Ansatz. Um jedoch Verwechslungen mit verbreiteten Konzepten zu vermeiden, die
darunter proaktiv und kooperativ agierende Systemen verstehen, wurde an dieser Stelle zur
Abgrenzung bewusst die Bezeichnung auftragsorientierter Ansatz gewählt.
Im Gegensatz zu einer Hub-and-Spoke-Architektur wird im auftragsorientierten Ansatz das
für den Datentransfer notwendige Wissen verteilt. Ein Agent agiert dabei als Stellvertreter
jeweils eines PDMS, der mit den anderen Agenten nachrichtenbasiert über einen beliebigen
Kommunikationskanal Daten austauscht. Seine Aufgabe ist es, Arbeitsaufträge von anderen
Agenten anzunehmen, lokal zu bearbeiten und bei Bedarf ein Ergebnis zur Verfügung zu stellen.
Ein Arbeitsauftrag könnte beispielsweise das Auslesen und Filtern einer BOM (Bill of Materials)
sein.
Prinzipiell kann ein Agent alle PDMS-typischen Aufgaben unterstützen. Dazu gehören u. a.
das Lesen und Speichern von Produktdaten und Produktstrukturen, das Anlegen neuer Revisionen oder den Check-In bzw. Check-Out von Objekten. Das Ziel bei der Implementierung der
Agenten ist es nun, diese Auftragstypen soweit wie möglich zu parametrisieren. Dadurch können
viele, auch komplexe Szenarien trotz einer relativ kleinen Anzahl an implementierten Auftragstypen umgesetzt werden. Die notwendigen Informationen für einen konkreten Auftrag werden
als
6 spezifische Konfigurationen zur Verfügung gestellt. Bei dem verwendeten Framework kann
so z. B. mit nur einem einzigen Auftragstyp sowohl ein einzelnes Objekt als auch eine komplette
Produktstruktur ausgelesen bzw. gespeichert werden.
Für den Austausch zwischen zwei oder mehreren Agenten werden die Daten auf ein Austauschschema abgebildet, welches speziell auf die Anforderungen des jeweiligen Prozesses abgestimmt ist. Für jeden Auftrag existiert deshalb ein eigenes Export-Schema auf der Senderseite
und ein passendes Import-Schema auf der Empfängerseite (vgl. Abb. 1). Auf diese Weise können
die systemspezifischen Besonderheiten der PDMS verborgen werden. Außerdem muss nur ein auf
den Anwendungsfall eingeschränktes Austauschschema von der jeweils anderen Seite auf das lokale Schema abgebildet werden, wodurch die Flexibilität bei Änderungen erhöht wird.
Abbildung 1: Prinzip der auftragsorientierten PDMS-Kopplung
Ein Agent kommuniziert mit seinem lokalen PDMS über eine der angebotenen Erweiterungsschnittstellen, die im Allgemeinen einen sehr feingranularen Zugriff auf das System ermöglichen.
Um die Kommunikationskosten gering zu halten, sollte sich ein Agent deshalb möglichst nahe
bei dem PDMS befinden. Teure Operationsfolgen finden bei der Auftragsbearbeitung somit ausschließlich zwischen dem Agenten und dem PDMS statt und sind damit deutlich günstiger als
dies bei einer zentralisierten Lösung oder gar einer Punkt-zu-Punkt-Kopplung der Fall wäre.
Durch die nachrichtenbasierte Kommunikation eignet sich der Ansatz auch für einen weltweit
verteilten Einsatz.
Einfache zusätzliche Funktionen können im verwendeten Framework als anwendungsspezifische Erweiterung in einen Agenten integriert werden. Der Entwicklungsaufwand ist dabei in
der Regel deutlich geringer als eine alleinstehende Entwicklung. Ein weiterer Vorteil dieses Ansatzes ergibt sich dadurch, dass ein großer Teil der Anwendungslogik der Agenten wie z. B. die
Schema-Abbildung systemunabhängig realisiert werden kann. Systemspezifischer Code muss nur
noch für den Zugriff auf das konkrete PDMS bereitgestellt werden.
5
Ergebnisse
Die prototypische Implementierung des exemplarischen Anwendungsfalles wurde bei der Evaluierung erfolgreich umgesetzt. Der von dem Framework verfolgte konzeptionelle Ansatz erwies
sich dabei als sehr flexibel einsetzbar. Die Stärken des Ansatzes gegenüber reinen Punkt-ZuPunkt-Lösungen oder Hub-and-Spoke-Architekturen liegen in der lokalen Ausführung teurer
Operationsfolgen und in der Flexibilität, die durch die gute Kapselung der systemspezifischen
Datenmodelle erreicht wird. Ermöglicht werden diese Vorteile durch die Fokussierung auf die praxisrelevanten Funktionen im PDMS-Umfeld und die prozessorientierte Konfiguration des Datentransfers. Gleichzeitig wird diese Fokussierung dann zum Nachteil, wenn speziellere Funktionen
benötigt werden, die nicht über die parametrisierten Auftragstypen abgebildet werden können.
Diese müssen dann selbst implementiert und in die Agenten integriert werden.
Aus Platzgründen wurde an dieser Stelle die Betrachtung weiterer wichtiger Punkte wie z. B.
der Unterstützung von Transaktionen und durchgängiger Sicherheitskonzepte ausgelassen. Bei
der Realisierung des Prototyps zeigte sich jedoch gerade dort noch Verbesserungspotential.
7
Rettungswachdienste an Binnengewässern webbasiert und aktiv verwalten
Andre Bolles
Abteilung Informationssysteme
Prof. Dr. Hans-Jürgen Appelrath
Department für Informatik
Carl von Ossietzky Universität Oldenburg
[email protected]
Zusammenfassung der Arbeit
Ziel dieses Individuellen Projektes (3-fach Modul im 6. Semester des Studiengangs Informatik)
war die Identifikation und Implementierung von Möglichkeiten zur zeitbasierten asynchronen
und verschlüsselten Kommunikation eines aktiven Datenbanksystems mit einer Menge von Datenanalyseanwendungen. Das hier betrachtete Individuelle Projekt ergab sich aus dem Dissertationsvorhaben von Dipl.-Inform. Heiko Tapken, in welchem unter Anderem eine Umgebung entwickelt wird, die eine Integration von Analysen in verteilen Informationssystemen ermöglicht. In
diesem Individuellen Projekt sollten daher Möglichkeiten identifiziert werden, mit denen asynchron Ergebnisse von Analysen, die zu unterschiedlichen Zeitpunkten durchgeführt wurden,
verschlüsselt übertragen werden können, um sie in eine Gesamtanalyse einbetten zu können.
Zur größeren Anschaulichkeit wurde in dem Individuellen Projekt als Awendungsszenario eine
Webapplikation zur Verwaltung von Rettungswachdiensten an Binnengewässern der DeutschenLebens-Rettungs-Gesellschaft e. V. betrachtet und implementiert. Die Webapplikation sollte die
gleichen Anforderungen erfüllen, wie sie auch im genannten Dissertationsvorhaben auftreten.
Daher sollten Informationen in verschlüsselter Form gespeichert werden. Situationsbedingt sollten weiterhin in einem aktiven Oracle Datenbanksystem Nachrichten generiert und eine externe
Anwendung zur Verarbeitung dieser Nachrichten angestoßen werden. Für diese Funktionalität
wurde insbesondere auf sogenannte Oracle Streams Advanced Queues (s. [Foc05]) in Verbindung
mit einem Oracle Scheduler (s. [Fog05]) zurückgegriffen. Des Weiteren wurde die Möglichkeit der
Ausführung von Java-Code in einem Oracle Datenbanksystem mittels der Oracle Java Virtual
Machine Aurora (vgl. [IMSW05, Iye05, Rap05] genutzt.
Die Abbildung 1 zeigt speziell die Komponenten des realisierten Systems, welche für die Umsetzung der zeitbasierten asynchronen Kommunikation und der sicheren Datenspeicherung und
Datenübertragung benötigt werden.
Daten werden in dieser Webapplikation verschlüsselt in einem Oracle Datenbanksystem gespeichert. Dazu werden neu eingetragende Daten im Oracle Datenbanksystem mittels Java-Code, der
von der Oracle Java Virtual Machine ausgeführt wird, symmetrisch mit einer 256 Bit starken
AES-Verschlüsselung verschlüsselt. Diese Daten sind damit vor dem unberechtigten Auslesen
geschützt, so lange kein Zugriff auf den Schlüssel besteht.
In dem Oracle Datenbanksystem ist ein Oracle Scheduler aktiv, der situationsbedingt zu einem
selbstständig berechneten Zeitpunkt oder bei Eintritt eines anderen Ereignisses die Erzeugung
von Nachrichten mittels PL/SQL anstößt, die dann über eine Oracle Streams Advanced Queue
an eine externe Anwendung gesandt werden. Die Daten können dabei in verschlüsselter Form
aus der Datenbank ausgelesen werden. Der Empfang einer solchen Nachricht stößt dann eine externe Applikation an, die daraufhin beliebige Aktionen ausführen kann. Hier wurde der Versand
einer mit OpenPGP verschlüsselten Email realisiert.
Diese Architektur erlaubt also zunächst die verschlüsselte Speicherung von Daten in einem
Oracle Datenbanksystem ohne eine externe Applikation für die Verschlüsselung anstoßen zu
müssen. Des Weiteren wird eine asynchrone Kommunikation eines Oracle Datenbanksystems
mit einer externen Applikation ermöglicht. Das Besondere hieran ist, dass hier nicht wie oft in
8
Aktives Oracle
Datenbanksystem
Scheduler stößt zeitbasiert
PL/SQL-Code an, der
Nachrichten in eine Oracle
Streams Advanced Queue
schreibt
Einga
ten
n Da
be vo
Nutzer / externe Anwendung A
Oracle Scheduler
Aurora
K
Ora
cle S ommun
ik
trea
ms A ation üb
e
dva
nc ed r
Que
u
es
Externe Anwendung B
Ausführung von Java-Code
zur symmetrischen
Verschlüsselung zu
speichernder Daten
OpenPGP-Verschlüsselung
von Emails
Abbildung 1: Architektur des entwickelten Systems
anderen Applikationen eine externe Anwendung Anfragen an ein Datenbankmanagementsystem
sendet, sondern ein aktives Datenbanksystem eine externe Applikation anstößt. Damit wurde
mit der in diesem Individuellen Projekt realisierten Webapplikation beispielhaft gezeigt, wie die
Anforderungen umgesetzt werden können, die sich aus dem genannten Dissertationsvorhaben
ergeben. Der Einsatz von Oracle Streams Advanced Queues in Verbindung mit einem Oracle
Scheduler sowie der Oracle Java Virtual Machine kann es dort ermöglichen, dass einzelne verteilte Oracle Datenbanksysteme bei Abschluss von Teilanalysen selbstständig die Ergebnisse
in verschlüsselter Form an eine externe Applikation übertragen, die diese Ergebnisse in eine
Gesamtanalyse integriert.
9
Literatur
[Foc05]
R Streams Advanced Queuing User’s Guide and
Craig B. Foch.
Oracle
Reference 10g Release 2 (10.2).
Oracle Corporation, http://downloadeast.oracle.com/docs/cd/B19306 01/server.102/b14257.pdf,
zuletzt besucht: 13. März 2006, 2005.
[Fog05]
R
Steve
Fogel.
Oralce
Database
Administrator’s
Guide
10g
Release
2
(10.2).
Oracle
Corporation,
http://downloadeast.oracle.com/docs/cd/B19306 01/server.102/b14231.pdf,
zuletzt besucht: 24. März 2006, 2005.
[IMSW05] Venkatasubramaniam Iyer, Sheryl Maring, Rick Sapir und Michael Wiesenberg.
R Database Java Developer’s Guide 10g Release 2 (10.2). Oracle CorpoOracle
ration, http://download-east.oracle.com/docs/cd/B19306 01/java.102/b14187.pdf,
zuletzt besucht: 13. April 2006, 2005.
[Iye05]
R Database SQLJ Developer’s Guide and
Venkatasubramaniam Iyer.
Oracle
Reference 10g Release 2 (10.2).
Oracle Corporation, http://downloadeast.oracle.com/docs/cd/B19306 01/java.102/b16018.pdf,
zuletzt besucht: 24. April 2006, 2005.
[Rap05]
R
Denis Raphaely.
Oracle
Database PL/SQL Packages and Types Reference 10g Release 2 (10.2).
Oracle Corporation, http://downloadeast.oracle.com/docs/cd/B19306 01/appdev.102/b14258.pdf,
zuletzt besucht: 20. April 2006, 2005.
10
Web Services and Data Caching for Java Mobile Clients
Alexandru Caracas, Iulia Ion, Mihaela Ion
{alexandru.caracas|iulia.ion|mihaela.ion}@i-u.de
International University in Germany, 76646 Bruchsal, Germany
January 27, 2007
Abstract
Web services are becoming more and more pervasive and are used by a number of information system clients. However, mobile clients still have limited computing and network
resources. Mobile information systems require client side caching of data for various reasons. Caching issues are discussed in many scientific publications that mostly lack an usable
implementation. Nearly all mobile devices support Java’s mobile information device profile
(MIDP). This paper presents the implementation of real-time train schedule mobile application for MIDP-capable mobile phones using web services architecture and data caching.
1
Introduction and Related Work
Mobile information systems clients pose many challenges. One of these challenges is the wireless
connectivity which could be slow, expensive, or not widely available. Another issue is that mobile
devices have limited computational and memory resources. To alleviate these two problems we
propose mobile applications to have: a web services architecture to lessen computation and
memory requirements, and data caching to reduce network traffic.
Web services for mobile clients are scarcely discussed in literature and implementations for
mobile phones are nascent. There are several advantages of using a service oriented architecture:
loose coupling of services and adaptability for changes. There are many publications on caching,
hoarding or replicating data in mobile information systems. However, almost all of them lack an
usable implementation and evaluations are mostly of a purely scientific nature based on system
simulations. In this paper, we present the implementation of a Java-based train schedule mobile
application using web services as well as client side caching for storage and offline usage of data.
Our paper touches various research areas. The main two topics are web services for mobile
devices and client side data storage in mobile information system. Based on the classification of
replication, hoarding and caching in [4] one can identify major caching issues in our work. We
implicitly store data on the mobile client that is explicitly queried and reuse it.
There are some projects that aim to implement a similar system to our application presented
in Section 3. Deutsche Bahn offers a static solution for train schedules1 . Mobile users have the
possibility to download a personal schedule between two stations by specifying the start and
destination. However, there is no guarantee that the data is up to date, moreover the user is
presented only with the trains to one particular destination.
Another approach is by Actuan Mobile who offers the complete dynamic schedule for the
New Jersey Transit rail system. The application2 is offered both as a mobile browser solution
and J2ME application. The mobile application available for download offers extensive features.
However, the schedule information is obtained directly by querying on line servers for each
request using proprietary protocols.
1
2
http://persoenlicherfahrplan.bahn.de
http://www.actuanmobile.com/documentation/train\ schedule\ manual-online-version-v0\ 1.pdf
11
2
Caching and Web Services on Java Mobile Devices
In the following we briefly present how to access an information system server via web-services
from an MIDP-capable mobile device and introduce the Record Management Store (RMS) that
was used for caching data on the client.Web services are accessed from mobile devices (J2ME
clients) using the standard JSR 172: J2ME Web Services Specification [1]. The specification
provides two new capabilities to the J2ME platform: (a) access to remote SOAP/XML based
web services, and (b) parsing XML data.
Method invocation follows the syncronous request-response model of client-server interaction.
A mobile client invokes a request to a remote web service. The web service processes the
request and sends back the result. The client then receives the data. The JSR 172 stub and
runtime handle the encoding of the method and arguments, serialization, sending the request
and receiving the response, decoding, and de-serialization - transparent to the application.
The RMS provided by MIDP is ideal for storing data on the client. A record store is identified
by its name. A record store contains a number or records accessible by their index. A MIDlet
application can persistently store data using the provided framework. A more detailed description of the MIDP record management store is given in [2, 3]. Our Java caching implementation
address the following caching issues: coherency, replacement and look-up.
3
Mobile Train Application Architecture
The mobile application (see Figure 1(a)) connects to a web service to download the latest
schedules for a given station. The web service sends the schedule which is serialized as an XML
document which includes trains with their respective type, departure time, final destination, etc.
The web service is responsible for data consistency, updates and proper format. This transfers
the computation and storage intensive tasks to an ’always’ on-line server machine.
(a) Train schedule application architecture
(b) Train schedule data structure
Figure 1: Architecture and implementation details
The MIDlet application caches the data into the persistent storage of the Record Store. If
the user queries for the next trains for a given station, the application first checks whether the
information is already present in cache. If the information is cached and the schedule still upto-date the next departing trains are presented to the user. Otherwise, the MIDlet queries the
Web Service for the latest schedule for the given station and caches the received response.
Web services involve marshaling of XML documents. However, saving XML data on a
mobile phone is not feasible due to the limited amount of storage. Nevertheless, XML data is
hierarchical and can be mapped to the RMS while keeping an efficient index structure. The
pragmatic method is to map each binary serialized XML data record to a record and use the
name of the document as the key for the record store. Figure 1(b) graphically depicts the
data structure used for caching the train schedule information for two example train stations,
Bruchsal and Karlsruhe. Each of the train station is saved in a separate record store.
12
4
Evaluation
For measuring the performance of our application we used the mobile emulator present with
the J2ME Wireless Toolkit. The reason is that support for JSR 172 is nascent. Many devices,
especially mobile phones and smart phones lack the required implementation. The tests represent
the performance of the application for various parameters of the VM emulator speed and network
throughput emulation.
(a)
(b)
Figure 2: Cache performance
Figure 2(a) illustrates for various XML data sizes the response time for answering a query
if no caching is used. In fact, this means that all data needs to be accessed from the server.
Figure 2(b) shows the response time in case of a cache miss to the case of a cache hit. Answering
a query locally is much faster than receiving the data over network. It is interesting to see, that
the influence of the size of nearly requested data disappears if data can be provided locally.
5
Summary, Conclusions and Outlook
We presented a service oriented train schedule application using data caching for MIDP-capable
mobile device. We discussed the architecture and implementation, illustrated the cache related
issues and presented first evaluation results. This paper is only a first step in terms of caching
for mobile clients. Our implementation substituted nearly all caching issues that are currently
discussed in journals and on conferences by pragmatic approaches. Moreover, the web services
technology is currently not widely deployed and supported by Java mobile clients. Nevertheless,
the results show that web services and caching on mobile phones are indeed possible and have a
huge potential to support the integration on mobile devices into distributed information systems.
The next steps of our work are to investigate further the availability of web service specifications for mobile devices, and implement more efficient caching strategies as well as more
detailed evaluations.
References
[1] John Ellis and Mark Young. J2ME Web Services 1.0. Sun Microsystem, Inc., Santa Clara, CA, USA, final draft
edition, October 2003. Available at http://jcp.org/aboutJava/communityprocess/final/jsr172/index.
html.
[2] Soma Ghosh. J2ME record management store – Add data storage capacities to your MIDlet apps. Online
article at IBM developerWorks, May 2002. Available at http://www-128.ibm.com/developerworks/library/
wi-rms/.
[3] Eric Giguere. Databases and MIDP, Part 1: Understanding the Record Management System. Online article at
Sun Developer Network, February 2004. Available at http://developers.sun.com/techtopics/mobility/
midp/articles/databaserms/.
[4] Hagen Höpfner, Can Türker, and Birgitta König-Ries. Mobile Datenbanken und Informationssysteme —
Konzepte und Techniken. dpunkt.verlag, Heidelberg, Germany, July 2005. in German.
13
FH Düsseldorf, Fachbereich Medien
Soccertrend
Projekt Praktische Medieninformatik im Studiengang B. Sc. Medien und angewandte
Informationstechnologie an der FH Düsseldorf, Prof. Dr.-Ing. Thomas Rakow
Eine Zusammenfassung der Projektteilnehmer
Mathias Detzner , Christian Beucker und Florian Sonennschein
Aufgabenstellung
Die Aufgabe zum Thema "Publikationssysteme" war die Entwicklung einer datenbank-basierten
Website für die Prognose der Ergebnisse von Fußballspielen. Die Ergebnisse sollen nach einem festen
Schema berechnet werden und demnach auch begründet werden können.
Konzeption
Auf der Homepage des Fußballmagazins Kicker werden Vereinsergebnisse, Spieler, Spielernoten und
Spieltagsergebnisse publiziert. Die Schwierigkeit lag in der Beschaffung der Daten und deren Import
in die Datenbank, da es keinen direkten Zugriff auf die Datenbank des Kickers gab. Es musste also ein
Daten-Grabber entwickelt werden, der die Homepage des Kickers auslesen kann. Auf Grundlage
eines entsprechenden ER-Modells wurde die Datenbank entwickelt. Ein Prognostizierer sollte die
Berechnung der Spielergebnisse ausführen, deren Güte anhand einer Auswertung der historischen
Daten der letzten 5 Jahre optimiert werden sollte. Die Darstellung der Prognoseergebnisse und eine
einfache Benutzerführung sollte die Webanwendung übernehmen.
Systemarchitektur
Auf einem Apache-Webserver der FH-Düsseldorf wurden fünf Module installiert, die in PHP und
MySQL bzw. HTML mit passendem CSS implementiert wurden.
Datenbanksystem:
Bei der Umsetzung des ER-Modells in das Relationen-Modell der MySQL-Datenbank
entstehen aus den 5 Entities jeweils
5 Tabellen, die mit Ihren Attributen
WebWebFremd-Server
bestückt werden. Hierbei werden die
client
client
www.kicker.de
Normalformen eingehalten.
Daten-Grabber:
Der Grabber besteht aus PHPDateien, welche jeweils für eine der
Tabellen der Datenbank die Daten
beim Kicker auslesen. Der Grabber
sucht dabei auf den Seiten des
Kickers nach
Schlüsselinformationen und liest
dementsprechend den Quelltext ein.
HTML-Tags werden entfernt und
die bereinigten Daten werden
zusammen mit daraus berechneten
Aggregaten in die Datenbank
geschrieben. Per Cron-Job werden
die Daten alle 24 Stunden
aktualisiert.
Webclient
WWW
Internet
Firewall
Webanwendung
Prognostizierer
Daten-Grabber
Datenbanksystem
Auswerter
Web-Server
http://dbe.medien.fh-duesseldorf.de/fussball
14
Prognostizierer:
Der Prognostizierer errechnet die Ergebnisse eines Spieltags. Dabei nimmt er die einzelnen
Attribute der Mannschaft mit einer Gewichtung und erhält einen Vereinswert. Die Werte für
Heim- und Gastverein der entsprechenden Begegnungen werden voneinander subtrahiert. Die
Ergebnisse werden anschließend nach einem festen aus der Evaluierung gewonnenem System
(s. unten) Heimsiegen, Unentschieden und Niederlagen zugeordnet.
Auswerter:
Der Auswerter ist nun letztendlich da, um reales und prognostiziertes Ergebnis zu
vergleichen. In der Datenbank markiert er richtige und falsche Ergebnisse dementsprechend.
Webanwendung:
Die Webanwendung besteht aus der Startseite, der Ausgabeseite der Prognose mit einer
optionalen Seite für die Begründung aus Standardtextbausteinen, dem Impressum und dem
Making-off. Die Gestaltung ist CSS-basiert und W3C-konform.
Evaluierung
Bei den Testreihen gibt es zwei Stellschrauben an denen gedreht werden kann: Zum einen die
Gewichtungen der einzelnen Kriterien und zum anderen das System, das über die Anzahl an Siegen,
Unentschieden und Niederlagen entscheidet.
Die Systemtests führten zum einen zu dem Ergebnis, dass eine rein wertebezogene Prognose nicht
wirkungsvoll genug arbeitet. Hierbei lagen die Trefferwahrscheinlichkeiten nicht über 34,9%. Aus
diesem Grund wird für die Berechnung der Prognose ein zweistufiges System benutzt, d.h. es wird die
wertebezogene Prognose in ein vorgegebenes Verhältnis von Heimsiegen, Unentschieden und
Niederlagen an einem Spieltag zugeordnet. Die Testreihen ergaben beim 6-2-1-System die
bestmöglichste Trefferquote von 48,04%.
Um dieses Ergebnis noch zu verbessern, werden die Kriterien unterschiedlich gewichtet. Dazu
wurden die Kriterien einzeln angehoben bzw. herausgenommen und beobachtet, wie sich die
Trefferquote verhält. Je nach den Auswirkungen kommt man auf das optimale
Gewichtungsverhältnis. Wenn man jetzt optimale Kriterien und Gewichtungssystem zusammen führt,
erhält man eine – allerdings nur leicht erhöhte – Trefferwahrscheinlichkeit von 48,1%.
Die Schrittweisen Verbesserungen des Testverfahrens kann man in folgendem Diagramm sehen.
Maßstab ist der Zufallswert (Wert links), welcher sich aus völlig zufälligen Prognosen begründet, die
keinerlei System oder Kriterien folgen.
15
Verwandte Arbeiten
Forecast Pro ist ein Expertensystem für betriebswirtschaftliche Prognosen bzw.
Fundamentalanalysen, das Prognosen und Trends erstellt, die auf Zeitreihen basieren und mehrere
Schätzungsalgorithmen verwenden (z. B. gleitender Durchschnitt, exponentielle Glättung).
http://www.softguide.de/prog_f/pf_0051.htm
Das Fußballprognosesystem "fussballvorhersage.de" prognostiziert den jeweils nächsten
Bundesligaspieltag. Berechnungsgrundlage sind die gewonnenen, unentschiedenen oder verlorenen
Partien getrennt nach Heim- und Auswärtsspielen auf der Datenbasis der aktuellen Saison.
http://www.fussballvorhersage.de/auswertung_vorhersage.htm
Quotenberechnung bei Sportwetten beruhen auf einer vom Buchmacher zu leistenden
Wahrscheinlichkeitskomponente. Ein Algorithmus wird nur für die betriebswirtschaftlichen
Rentabilitätsberechnungen verwendet. http://www.wettbueros.net/wettinfos/
Soccertrend basiert auf einer großen Basis an Kriterien. Aus der Vergangenheit werden Gewichtung
der Kategorien und die Zuordnung auf Heimsiege, Unentscheiden und Auswärtssiegen hergeleitet.
http://www.soccertrend.de.vu
Fazit
Die beste theoretische Ausbildung nützt nichts, wenn man nicht die Möglichkeit hat diese in der
Praxis anzuwenden. Aus diesem Grund sind Projekte wie dieses für den Lernerfolg und die
Verbesserung der eigenen Fähigkeiten unbedingt notwendig. Auch wenn der Arbeitsaufwand für ein
Semester recht hoch bei einem Team von 3 Personen ist, so ist dennoch der Lernerfolg den dieses
Projekt gebracht hat, für alle Teilnehmer unbestreitbar groß. Neben den technischen Fähigkeiten
wurden auch die Projektarbeit verbessert und die Teamfähigkeit gesteigert.
Das Prognosesystem ist online und läuft seit mehreren Monaten reibungslos. Die Ergebnisse liegen im
erwarteten Bereich. Zu Problemen könnte es kommen, sobald sich das Layout der Kicker-Webseiten
ändert und der Grabber nicht mehr in der Lage wäre, die Daten zu finden. Auf Grund des erst kürzlich
geänderten Layouts und der freundlichen Genehmigung des Kickers kann man auch in Zukunft auf
sichere Prognosen hoffen. Bei Google findet man unter dem Stichwort „Soccertrend“ diese Homepage
bereits an erster Stelle!
16
Techniken zur Approximation und Optimierung von
Performancefunktionen
Tobias Exner
Lehrstuhl für Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Ernst-Abbe-Platz 2
07743 Jena
[email protected]
1 Einleitung und Motivation
Relationale Datenbanksysteme, wie IBM DB2, sind durch eine hohe systeminhärente Komplexität
und Konfigurationsvielfalt gekennzeichnet. Um den hohen an diese Systeme gestellten Anforderungen1 ,
wie Verfügbarkeit, Sicherheit, Integrität und Performance, gerecht zu werden, ist ein sehr großes Fachwissen der Datenbankadministratoren von Nöten. Das Verbessern der Systemkonfiguration sowohl vorab als auch im laufenden Betrieb wird durch die Administratoren meistens manuell vorgenommen und
erfolgt reaktiv, d.h. Änderungen der Systemkonfiguration werden erst vorgenommen, wenn ein Performanceproblem auftritt. Diese, auch als black art of database tuning“ [WMHZ02] bezeichnete Vorge”
hensweise ist zeitaufwendig, kostenintensiv und zudem sehr fehleranfällig.
Aus diesem Grund verfolgen Ansätze wie das Autonomic Computing [IBM06] das Ziel, die Bedienung und Administration von IT-Systemen zu vereinfachen und zu automatisieren. Im Rahmen eines Koorperationsprojekts2 wird am hiesigen Lehrstuhl eine Infrastruktur zur Automatisierung typischer
Datenbank-Tuning-Aufgaben entwickelt. Dieses Papier ist die Zusammenfassung einer Diplomarbeit, die
in Zusammenarbeit mit dem Institut für Angewandte Mathematik entsteht. Dabei wird die Möglichkeit
des Einsatzes von mathematischer Optimierung für das Performancetuning untersucht.
2 Optimierung von Performancefunktionen
Durch direkt steuerbare Effektoren (Konfigurationsparameter, Umgebungsvariablen etc.) kann ein
Datenbanksystem an eine dynamische Umgebung (Workload, Hardware) angepasst werden. Diese Effektoren haben Auswirkungen auf die Performance, wie beispielweise Antwortzeiten von SQL-Anfragen
oder die Buffer Pool Hit Ratio, und beeinflussen sich gegenseitig. Ziel administrativer Tätigkeiten ist
die Maximierung der Performance unter Berücksichtigung der Policies. In alternativen Ansätzen für
selbst-optimierende Komponenten wird bisher versucht, die Performance unter Verwendung von BestPractices-Methoden schrittweise zu verbessern [Ben03]. Eine weitere Möglichkeit besteht darin, ein
mathematisches Modell der Parameterabhängigkeiten zu entwickeln, mit dessen Hilfe dann eine zu maximierende Performancefunktion aufgestellt werden kann. Zur Laufzeit müsste dann diejenige Parameterbelegung berechnet werden, welche ein Optimum für die Performancefunktion liefert.
Für die Erarbeitung eines mathematischen Modells (Zielfunktion, Nebenbedingungen), soll der Einfluss von Parametern untereinander und auf die Performance genauer untersucht und in Form eines funktionalen Zusammenhangs beschrieben werden. Als Datenbankmanagementsystem wird IBM DB2 UDB
8.2 gewählt und eine Workload darauf simuliert. Gleichzeitig werden Werte von Sensoren (Kenngrößen
1
2
Diese werden in sogenannten Policies vereinbart.
Projektseite: http://www.informatik.uni-jena.de/dbis/dbat/index.html
17
der Performance) gemessen und abgespeichert. Die Effektoren werden nun schrittweise geändert und die
Simulation inklusive Datensammlung wird wiederholt. Aus den so gewonnen Daten sollen nun durch
(nichtlineare) Regressionsanalyse Funktionen ermittelt werden, die den Zusammenhang zwischen Effektoren und Sensoren widerspiegeln. Ein in [Gan06] entwickeltes Werkzeug automatisiert den Prozess
der Datensammlung und -speicherung. Da es in DB2 Hunderte konfigurierbarer Parameter gibt, wird sich
zunächst auf die Konfiguration des Buffer Pool Pools und des Lockings beschränkt. In [Ben03] wurden
ähnliche Messungen für eine Online Transaction Processing Workload (OLTP) durchgeführt, um u.a.
Performanceprobleme, die mit der Konfiguration des Buffer Pools zusammenhängen, zu erkennen. Als
Ausgangspunkt unserer Analyse dient ebenfalls eine feste OLTP Workload (TPC-C Standard Benchmark
[TPC06]), im Gegensatz zu [Ben03] sind aber mehrere variable Effektoren möglich, um Korrelationen
zwischen Effektoren zu erkennen.
Als erstes wurde die Konfiguration des Buffer Pools untersucht, indem die DB2-Konfigurationsparameter Buffer Pool Size3 und num iocleaners4 jeweils in einem festen Wertebereich geändert wurden.
Als Performancesensor wurde der Anteil asynchroner Schreiboperationen (das sind diejenigen Schreiboperationen, bei denen geänderte Seiten des Buffer Pools auf Festplatte durch Page Cleaner zurück
geschrieben werden) betrachtet. Es stellte sich heraus, dass dieser Anteil nicht von der Größe des Buffer
Pools abhängig ist. Für die Anzahl der Page Cleaner hingegen ergab sich ein Zusammenhang der Form
f (x) = a arctan(b x), wie Abbildung 1 zeigt. Je mehr Page Cleaner zur Verfügung stehen, desto mehr
100
Anteil asynchroner Schreiboperationen (in%)
90
f(x)
80
70
60
50
40
30
20
10
0
0
10
20
30
x . . . num_iocleaners
40
50
60
Abbildung 1: Anteil der asynchronen Schreiboperationen in Abhängigkeit von num iocleaners
geänderte Seiten des Buffer Pools können asynchron auf Platte geschrieben werden. Sind weniger Page
Cleaner vorhanden, gibt es in der Folge im Buffer Pool zu wenig freie Seiten. Daher müssen geänderte
Seiten unerwünschterweise synchron auf Platte geschrieben werden. Die Asynchronität der Schreiboperationen erhöht sich durch die Verwendung von zusätzlichen Page Cleanern. Jedoch kann mit immer
mehr Page Cleanern die Asynchronität natürlich nicht beliebig gesteigert werden, denn die Stärke des
Einflusses verringert sich und eine Sättigung stellt sich ein.
3 Ausblick und weitere Schwerpunkte
Im weiteren Verlauf der Arbeit sind Untersuchungen hinsichtlich des Sortings und Lockings vorgesehen. Dies beinhaltet z.B. die Frage, welche Abhängigkeit zwischen der Größe der Lockliste und
3
4
Die Buffer Pool Size gibt die Größe des Buffer Pools in Anzahl der Seiten an.
num iocleaners bestimmt die maximale Anzahl der Page Cleaner.
18
der Anzahl der auftretenden Sperreskalationen besteht. Da in der Realität dynamische Workloadtypen auftreten [WMHZ02], sind Untersuchungen unter verschiedenen Standard Benchmarks angedacht.
Möglicherweise lässt sich daraus eine Klassifikation der Performancefunktionen bezüglich der Workload
ableiten. Der Nutzen des Untersuchungsaufwandes, die mögliche Integrierbarkeit in eine selbst-optimierende Komponente und die Übertragbarkeit auf andere Datenbankmanagementsyteme sollen ebenfalls
analysiert werden. Anhand dieser Ergebnisse sollte dann abgeschätzt werden können, ob der gewählte
Ansatz, das Datenbank-Tuning unter Verwendung (nichtlinearer) Optimierungsprobleme vorzunehmen,
eine Verbesserung gegenüber den Best-Practices-Methoden darstellt.
Literatur
[Ben03]
Darcy G. Benoit. Automatic Diagnosis of Performance Problems in Database Management
Systems. Dissertation, Queens University, Kingston, Ontario, Canada, 2003.
[Gan06]
Kai Ganskow. Autonomic Database Performance Tuning: Systemmodellierung am Beispiel
von IBM DB2. Diplomarbeit, Friedrich-Schiller-Universität Jena, 2006.
[IBM06]
IBM.
An architectural blueprint for autonomic computing. White Paper, Juni 2006.
online, abgerufen am 06.09.2006: http://www03.ibm.com/autonomic/pdfs/AC Blueprint White Paper 4th.pdf.
[TPC06]
TPC Benchmark C Standard Specification Revision 5.7, April 2006.
[WMHZ02] Gerhard Weikum, Axel Mönkeberg, Christof Hasse und Peter Zabback. Self-tuning Database Technology and Information Services: from Wishful Thinking to Viable Engineering.
In Proceedings of 28th International Conference on Very Large Data Bases, Seiten 20–31,
2002.
19
Teiresias:
Datenbank-basiertes Online-Wörterbuch für Griechisch
Christian Helmchen
Kontakt: [email protected]
Universität Leipzig - Institut für Informatik - Abteilung Datenbanken
Im Web existieren zahlreiche Programme und Onlinewörterbücher für die Übersetzung ins Englische
bzw. aus dem Englischen. Doch wie sieht es mit anderen Sprachen aus? Welche Besonderheiten gilt
es zu beachten, wenn die Sprachen völlig unterschiedliche Buchstaben und Zeichensätze verwenden?
Und wie beeinflussen deren spezielle linguistische Eigenheiten die Suche im Wörterbuch? Diese
Fragen sollen am speziellen Beispiel der Sprachen Deutsch und Neugriechisch diskutiert werden. Das
Ergebnis der Untersuchungen fand seinen Ausdruck im datenbank-basierten Online-Wörterbuch
„Teiresias“:
http://teiresias.uni-leipzig.de/
Dabei sind besondere Anforderungen zu erfüllen:

Unterstützung verschiedensprachiger Zeichensätze bei Eingabe, Speicherung und Ausgabe der
Wörterbucheinträge

Problemangepasste Suchmöglichkeiten im Wörterbuch (fehlertolerant, phonetisch...)

Intuitive Benutzeroberfläche

Möglichst Standardsoftware
Außerdem sollen auch die Vorteile eines elektronischen Wörterbuches genutzt werden: hohe
Flexibilität durch verschiedene Suchmechanismen, Sortiermöglichkeiten und variable Darstellung der
Inhalte, schnelle Navigation mittels Hyperlinks und auch Interaktivität durch Kommentare und
Fragen zu Einträgen.
Architektur
Das Wörterbuch wurde als Client-Server-Anwendung realisiert. Der Anwender greift mit Hilfe eines
Web-Browsers darauf zu, während für die Autoren der Wörterbucheinträge eine eigene Software zur
Datenpflege zur Verfügung steht. Beiden Interfaces gemein ist eine intuitiv zu bedienende
Benutzeroberfläche. Sowohl beim Anwender als auch bei den Autoren sollen keine besonderen
Kenntnisse
der
Informatik
vorausgesetzt
werden.
Deshalb
wurden
unter
anderem
Umschaltmöglichkeiten zwischen den verschiedenen Zeichensätzen integriert, die unabhängig vom
Betriebssystem arbeiten. Die Autorensoftware wahrt zudem die Konsistenz der Daten durch
Plausibilitätsprüfungen und unterstützt den Autor durch Automatisierung verschiedener Teilprozesse
während der Dateneingabe.
20
Abbildung 1: Das Web-Frontend zur Suche im Wörterbuch
Zusätzlich zu den eigentlichen Daten, deren Aufbau an [1] angelehnt ist, wurde mit Data-WarehouseTechniken eine speziell auf die Anforderungen der Suche zugeschnittene Mischung aus
materialisierter View und Data-Mart realisiert. Diese Strukturen enthalten vorverarbeitete Daten, mit
denen die unten beschriebenen Suchverfahren performant umgesetzt werden.
Unicode-Unterstützung
Noch vor wenigen Jahren war die Verwendung unterschiedlicher Zeichensätze in Datenbanken und
Programmiersprachen ein Problem. Doch mit zunehmender Unicode-Unterstützung sollte dies der
Vergangenheit angehören: sowohl MySQL als DBMS, als auch PHP und Java zur Implementierung
der geforderten Funktionalität bieten, wie durch eigene Untersuchungen festgestellt wurde, heute eine
ausreichende Unterstützung des Unicode-Formates für viele gängige Sprachen, darunter auch für die
momentan geltende Schreibung des Neugriechischen. Im Detail sind beim Zusammenwirken
zwischen DBMS und Programmiersprache einige Besonderheiten zu beachten. Auch der Großteil der
getesteten Web-Browser kann mehrsprachige Texte korrekt darstellen, so dass die Verwendung
verschiedener Zeichensätze kein Problem mehr ist. Ältere Schreibweisen des Griechischen wurden
nicht näher untersucht - hier sind noch Probleme zu erwarten. Dies deutet sich bereits bei der
Verwendung von seltenen Sonderzeichen (z.B. Auslassungszeichen) oder altgriechischen Buchstaben
(z.B. als Zahlzeichen) an.
Suchverfahren
Für die Suche stehen dem Benutzer eine Reihe von Suchverfahren zur Verfügung, von der einfachen
Wortsuche über eine so genannte Stammsuche bis hin zur weitaus mächtigeren phonetischen Suche.
Stammsuche: Bei dieser Suche werden, im Gegensatz zur „echten“ Stammerkennung, die auch Vor-
21
und Nachsilben abtrennt, alle Flexionsendungen griechischer Wörter auf der Grundlage von [2], [4]
eliminiert. Die daraus resultierenden Zeichenketten bilden die Grundlage der Suche. Die Regeln,
nach denen die Endungen ermittelt werden, stehen dem System in Form von Beispiellisten zur
Verfügung, welche mit einem einfachen Texteditor beliebig ergänzt werden können. Ein
Sprachkundiger kann so leicht fehlende Formen durch Eingabe eines Beispieles hinzufügen.
Phonetische Suche: Die phonetische Suche ist die mächtigste und zugleich weitestgehend fehlertolerante Suchmethode. Ziel ist es, Wörter nicht nur an der Schreibweise, sondern auch an der
Aussprache zu erkennen, da für eine korrekte Schreibung oft tiefere Kenntnisse der Sprachgeschichte
notwendig sind. So gibt es z.B. für das Phonem i im Griechischen insgesamt 5 Schriftzeichen
(Grapheme) bzw. Zeichenfolgen (Details siehe [2]). Der Soundex-Algorithmus, der für die englische
Sprache entwickelt wurde, lässt sich für das Neugriechische jedoch leider nicht zufriedenstellend
anwenden. Die Ursache liegt unter anderem in der fehlenden Unterstützung für Grapheme, die
mehrere Phoneme repräsentieren (so entspricht „ψ“ der Folge „ps“). Deshalb wurde für das Wörterbuch auf Basis der Ausspracheregeln aus [2] ein eigenes zweistufiges phonetisches Such-verfahren
entwickelt [3]. Dabei steuert ein Regelinterpreter die phonetische Analyse eines Wortes. Dessen
Regeln lassen sich beliebig anpassen und erweitern. In der ersten Stufe werden unhörbare Varianten
(z.B. Doppelkonsonanten oder verschiedene Grapheme für ein Phonem) umgewandelt. In der zweiten
Stufe wird dann eine Reduktion auf ausgewählte Phonemklassen des Neugriechischen durchgeführt.
Dieses Vorgehen ist auch auf andere Sprachen und Alphabete übertragbar. Zur Demonstration der
Flexibilität wurden die Regeln so gestaltet, dass sich griechische Suchbegriffe mit lateinischen
Buchstaben, die dem vernommenen Klangbild im Deutschen entsprechen, eingeben lassen.
Zusammenfassung und Erweiterungen
Das vorgestellte Wörterbuch überwindet die Barriere zwischen verschiedenen Sprachen und
Zeichensätzen. Der aktuelle Stand der verfügbaren Datenbanken und Programmiersprachen erlaubt
die Realisierung komplexer mehrsprachiger Anwendungen im Web ohne grundsätzliche Probleme.
Sie können jedoch immer noch in Detailfragen, z.B. bei nicht weit verbreiteten Sprachen, auftreten.
Durch Hinzufügen weiterer Schnittstellen können auf Basis der vorliegenden Daten vielfältige
Anwendungen implementiert werden: Vokabeltrainer, Rechtschreibhilfen oder Wortschatzanalysen.
Die Datenstrukturen und Verfahren des Wörterbuches lassen sich auch bei ähnlich gelagerten
Aufgaben in anderen indogermanischen Sprachen einsetzen.
Literatur
[1] Lenk, H.: Vorlesung Lexikologie, Univ. Helsinki, 2003,
http://www.helsinki.fi/~lenk/mikrostruktur.htm (26.01.2007)
[2] Ruge, H.: Grammatik des Neugriechischen. Romiosini-Verlag, Köln, 2001
[3] Sosna, D.: Phonetische Suche in neugriechischen Texten, Univ. Leipzig, 2007,
http://lips.informatik.uni-leipzig.de/pub/2007-1
[4] Lexikon des Neugriechischen (griech.), Univ. Tessaloniki, 1999, ISBN 960-231-085-5
22
Integration von Stichprobenverfahren in ein rel.
DBMS
Bernhard Jäcksch
Decision-Support-Systeme verwenden oft große Datenmengen, was sich kritisch auf deren Interaktivität auswirkt. Stichproben sind ein geeignetes Mittel, um approximative Ergebnisse zu erhalten. Durch die wesentlich geringere Größe von Stichproben im Bezug auf
die Quelldaten, helfen sie, die Antwortzeiten für komplexe Anfragen zu minimieren. Zusätzlich sind Aussagen über den Fehler in Form von Konfidenzintervallen möglich. Um
die genannten Vorteile effizienter nutzbar zu machen, integriert Derby/S [2] stichprobenbasierte Anfragebearbeitung direkt in ein rel. DBMS. Basierend auf einem Framework mit
einer Plugin-Schnittstelle, soll eine einfache Integration neuer Stichprobenverfahren möglich werden. Im folgenden werden Anforderungen und Architektur des Frameworks und der
Schnittstelle skizziert und wichtige Implementationsdetails erläutert.
1 Einleitung
Stichproben können bspw. zur approximativen Anfragebearbeitung in großen Data-Warehouse-Systemen
eingesetzt werden. Häufig ist hier ein schnell verfügbares, approximiertes Anfrageergebnis einer zeitintensiven, exakten Berechnung vorzuziehen. Trotzdem gibt es derzeit kaum ein DBMS, das Stichproben
als grundsätzliche Datenobjekte unterstützt. Hier setzt Derby/S [2] an, dessen Ziel die vollständige Integration von Stichproben in ein relationales DBMS ist. Dabei wurde Apache Derby [1] als Grundlage
verwendet. Durch eine nahtlose SQL-Erweiterung gestaltet sich die Erzeugung und Verwendung von
materialisierten Stichproben denkbar einfach. Im aktuell vorliegenden Derby/S-Prototypen erfordert die
Implementierung neuer Stichprobenverfahren eine umfassende Einarbeitung in Derby und ist eng mit
Derby Interna verzahnt. Um das Problem der Integration neuer Verfahren in Derby/S wesentlich zu
vereinfachen, wird in dieser Arbeit ein Framework, als Abstraktionsschicht zwischen Derby und den
Stichprobenverfahren, vorgeschlagen (siehe Abb. 1(a)).
Die vorgeschlagene Modularisierung führt die grundlegenden Schritte zur Erzeugung, Wartung und Verwendung von Stichproben aus und bindet mittels einer Plugin-Schnittstelle neue Verfahren ein. Anhand
der näherungsweisen Anfrage in Listing 1 wird die Funktionsweise von Derby/S kurz illustriert. Die Anfrage wird direkt auf den Basistabellen formuliert, auch wenn ein approximatives Ergebnis gewünscht
ist. Dabei definiert SOME, dass das Ergebnis unvollständig sein kann. Die ~ vor dem Aggregat gibt an,
dass der Ergebniswert nicht exakt sein muss. Die Selektion von Stichproben und das Umschreiben der
näherungsweisen Anfrage werden automatisch von Derby/S vollzogen. Während der Erzeugung einer
Stichprobe lassen sich wichtige Merkmale parametrisieren, bspw. Größe oder Wartungsart. Dazu bietet
das System fein abgestufte Wartungsstrategien an und übernimmt die Verwaltung der Stichproben.
Abschnitt 2 geht zunächst auf Anforderungen an das Framework ein und in Abschnitt 3 wird kurz die
prinzipielle Architektur erläutert. In Abschnitt 4 wird zu einigen ausgewählten Implementierungsdetails
Stellung genommen und in Abschnitt 5 werden die Ergebnisse zusammengefasst.
2 Anforderungen
Aus den charakteristischen und repräsentativen Eigenschaften sowohl einfacher Verfahren wie Reservoirund Bernoulli-Sampling als auch einiger komplexerer Verfahren ergeben sich eine ganze Reihe verschiedener Merkmale, die von dem Framework und der Plugin-Schnittstelle unterstützt werden sollen.
Listing 2: umgeformte Anfrage
Listing 1: Approximative Anfrage
SELECT SOME YEAR(OrderDate),
2 ~SUM(Quantity * Price)
3 FROM Sales
4 GROUP BY YEAR(OrderDate)
1
SELECT YEAR(OrderDate),
2 AVG(Quantity * Price) * 100
3 FROM SP_Sales
4 GROUP BY YEAR(OrderDate)
1
23
Stichprobentabellen. Um z.B. obige Anfrage zu beantworten, könnte ein optimiertes Verfahren zum
Einsatz kommen, das neben einer einfachen Zufallsstichprobe, weitere statistische Informationen über
die Quelldaten vorhält. Diese Daten werden jeweils als eigene Entität gespeichert. Das Framework muss
also für die Stichprobenverfahren einfache Mittel bereitstellen, Entitäten anlegen und erweitern zu können.
Wartung. Um eine Stichprobe verwenden zu können, muss sie zuerst aus den Quelldaten erhoben werden. Die Plugin-Schnittstelle muss der Stichprobe die Quelldaten zur Verfügung stellen können. Auch
erlaubt Derby/S eine feinabgestimmte Wartung der im System befindlichen Stichproben. Die Schnittstelle sollte eine einfache Einbindung neuer Verfahren in die Wartungsmechanismen unterstützen.
Anfragebearbeitung. Neben Erzeugung und Wartung ist die Verwendung der Stichproben in approximativen Anfragen ein wichtiger Bestandteil von Derby/S. Um die obige Anfrage zu beantworten, könnte
eine 1% Stichprobe SP_Sales der Sales Tabelle zum Einsatz kommen. Diese würde dann wie in
Listing 2 umgeschrieben werden. Damit dieser Schritt transparent im System erfolgen kann, muss die
Plugin-Schnittstelle in der Lage sein, eine geeignete Stichprobe auszuwählen und das Verfahren beim
Umschreiben der Anfrage unterstützen.
3 Architektur
Im Folgenden wird auf wichtige Grundzüge der Architektur eingegangen, wobei sich an den im vorangegangenen Abschnitt beschriebenen Kriterien orientiert wird.
Logische und Physische Stichproben: Zentrales Element der Schnittstellenarchitektur ist die Aufteilung in logische und physische Stichproben. Eine logische Stichprobe fasst eine oder mehrere physische
Stichproben zusammen und ist für deren Verwaltung zuständig. Physische Stichproben verkörpern eine
konkrete Entität, in der die eigentlichen Daten hinterlegt sind. Die Hierarchiebeziehung zwischen logischer und physischer Stichprobe wurde im vorliegenden Framework noch um die Möglichkeit erweitert,
auch logische Stichproben miteinander kombinieren zu können. Abb. 1(b) zeigt bspw. eine geschichtete Stichprobe, die die Daten nach YEAR partitioniert. Für Datensätze mit YEAR <= 2000 wird eine
einfache Zufallsstichprobe verwendet, während für alle >= 2000 ein optimiertes Verfahren verwendet
wird, um ein genaueres Ergebnis zu erzielen.
Auswahlstrategien: Um wenige Spezialkenntnisse vorauszusetzen und den Administrationsaufwand
zu minimieren, soll Derby/S Entscheidungen über die Wahl des Stichprobenverfahrens und die korrekte
Umformung des Anfragebaumes selbst treffen. Um den Einsatz verschiedener Strategien nicht zu beschränken, wurden an diesen Stellen des Frameworks Strategy- und Factory-Muster eingesetzt. Diese
ermöglichen die einfache Erweiterbarkeit um neue und angepasste Strategien. Zusätzlich wurden bereits verschiedene Basisstrategien implementiert, die auch als Ausgangspunkt für neue Strategien dienen
können.
Stichprobenverwaltung: Für die Verwaltung und den Zugriff auf die im System verfügbaren Stichprobenverfahren existiert ein Repository, das jederzeit abrufbar ist. In diesem sind wichtige Eigenschaften aller Verfahren registriert und zugreifbar. Diese Informationen können von den im vorangegangenen
Abschnitt beschriebenen Strategien benutzt werden, beispielsweise um bei der Erstellung einer neuen
Stichprobe anhand der gegeben Parameter ein optimales Stichprobenverfahren auszuwählen. Zusätzlich
wurden neue Systemkataloge eingeführt, in denen die jeweiligen Parameter für die erstellten Stichproben
festgehalten sind.
Hilfsklassen: Zahlreiche grundlegende Funktionen, wie das Manipiulieren von Tabellen oder der Zugriff auf die Systemkataloge, werden von allen Stichprobenverfahren zur Erzeugung und Verwaltung der
Stichprobe benötigt. Da die Verfahren innerhalb der Datenbank implementiert werden, wird aus Efizienzlogische
Stichprobe 1
year < 2000
Derby
Framework
Schnittstelle zu Derby
logische
Stichprobe 2
B
physische
Stichprobe 1
E
= Stichprobe
A
X
= Verfahren
= gehört zu
year >= 2000
logische
Stichprobe 3
C
Eigene Verfahren
physische
Stichprobe 2
E
physische
Stichprobe 3
F
Plugin-Schnittstelle
(a) Schematische Ansicht der Erweiterung
(b) Beispielhierarchie kombinierter Stichproben
24
gründen nicht mit SQL-Befehlen, sondern direkt mit internen Strukturen gearbeitet. Um die Abstraktion
von Derby-internen Objekten beizubehalten, wurden verschiedene Hilfsobjekte eingeführt, die einen einfachen Umgang mit diesen erlauben.
4 Implementation
Im folgenden Abschnitt wird dokumentiert, wie die obigen Anforderungen und die Architektur im Derby/S Framework umgesetzt wurden.
Das Repository verwendet einen vorhandenen Modul-Mechanismus von Derby/S, wodurch es automatisch geladen wird und innerhalb der ganzen Datenbank zur Verfügung steht. Um die Auswahl von
Stichprobenverfahren nach bestimmten Eigenschaften zu ermöglichen, besitzt jedes Verfahren sog. Capabilities, die seine Funktionalität, bspw. die beherrschten Wartungssmethoden, widerspiegeln. Anhand
dieser kann das Repository nach Einträgen gefiltert werden, die die Vorgaben der Quellanfrage erfüllen.
Die Wartungstechniken für Stichproben in Derby/S wurden mittels dem in Derby bereits vorhandenen Triggermechanismus umgesetzt. Dabei werden auf den Quelltabellen Trigger definiert, die erfolgte
Aktualisierungen an die Stichprobenverfahren weiterleiten. Projektionen, Selektionen und Joins werden
dabei bereits berücksichtigt. Die Trigger werden vom Framework automatisch angelegt.
Die näherungsweise Anfragebearbeitung mittels Stichproben ist in Derby/S wie folgt realisiert: Derby
parst Anfragen nach der Eingabe in einen Baum, dessen Knoten einzelne Elemente der Anfrage repräsentieren. Um eine approximative Anfrage umzuschreiben, bietet die Plugin-Schnittstelle Möglichkeiten an,
vor der Weiterverarbeitung Teile des Baumes zu ersetzen. Beim Beispiel aus der Einleitung wird u.a. die
Quellrelation Sales, gegen die entsprechende Stichprobe ausgetauscht. Da sich die Änderungen der
Anfrage für jedes Stichprobenverfahren unterscheiden können, ist es vorgesehen, dass jedes Stichprobenverfahren ein Strategieobjekt zur Verfügung stellt, das einen gegebenen Anfragebaum entsprechend
umformen kann. Grundlegende Operationen werden dafür bereits zur Verfügung gestellt.
5 Zusammenfassung
Derby/S bietet eine umfassende Unterstützung von Stichprobenverfahren und deren Einsatz in näherungsweisen Anfragen. Zusammen mit der nahtlosen Integration in SQL und den feinstufig justierbaren
Wartungsoperationen sind Stichproben in Derby/S vollwertige Datenbankobjekte. Durch die vorgenommene Erweiterung um ein Modulkonzept bleibt Derby/S nicht auf wenige vorkonfigurierte Stichprobenverfahren beschränkt. Vielmehr können nahezu beliebige Verfahren über eine einheitliche Schnittstelle
implementiert und getestet werden.
Um die Einsatzmöglichkeiten von Derby/S zukünftig zu erweitern und die Plugin-Schnittstelle zu verbessern wird u.a. bereits parallel die Erhebung und Integration von Workload Informationen umgesetzt.
Diese können für eine zusätzliche Parametrisierung der Stichprobenverfahren oder etwa zur automatischen Erzeugung relevanter Stichproben eingesetzt werden.
Literatur
[1] A. S. Foundation. Apache db project. db.apache.org/derby, 2006.
[2] A. Klein, R. Gemulla, P. Rösch, and W. Lehner. Derby/s: A dbms for sample-based query answering.
In ACM Sigmod 06.
25
Regelbasiertes Visualisieren und Editieren
beliebiger Graphen
Thomas Jörg
[email protected]
1. Februar 2007
Zusammenfassung
Graphen sind eine flexible und ausdrucksmächtige Datenstruktur. Es gibt eine große Zahl
an Modellen und Notationen, die auf Graphen basieren: Bekannte Vertreter sind EntityRelationship-Diagramme zur Datenmodellierung, die Diagramme der UML-Familie zur Beschreibung des Verhaltens und der Struktur von Softwaresystemen oder RDF-Modelle zur
Darstellung von Metadaten. Mit zunehmender Größe sind Graphen ohne geeignete Werkzeuge kaum beherrschbar. Existierende Werkzeuge bleiben in der Regel auf eine konkrete
Sprache bzw. Notation beschränkt. Ziel der Diplomarbeit ist die Entwicklung eines Editors
für beliebige Graphmodelle, die in einem Standardformat vorliegen. Der Editor soll flexibel
an das zugrunde liegende Modell angepasst werden können.
1
Einleitung
Die aktuellen Forschungsprojekte der Arbeitsgruppe Heterogene Informationssysteme an der TU
Kaiserslautern verwenden Graphen zur Repräsentation von Daten und Metadaten. Diese Arbeit
beschreibt den zur Visualisierung und Manipulation dieser Modelle entwickelten Graph-Editor.
Zentrale Anforderung war jedoch, die Verarbeitung beliebiger Modelle zu ermöglichen, die als
gerichtete, markierte, attributierte Graphen vorliegen. Abbildung 1 stellt beispielhaft das Modell
einer Tabelle in einer relationalen Datenbank dar, die zur Speicherung von Kundendaten dient.
Ein Datensatz besteht aus Vor- und Nachnamen, sowie einer eindeutigen Kundennummer, die
gleichzeitig der Primärschlüssel der Tabelle ist.
has
Colu
mn
yKey
rimar
hasP
Table
name: Customer
PrimaryKey
m
o lu
sC
ha
has
Co
lu
n
Column
name: LastName
lu m
has
Typ
e
Co
Type
type: VARCHAR(255)
h as
mn
n
ha
sT
yp
e
Column
name: FirstName
Column
name: CNo
Type
type: INTEGER
e
yp
sT
ha
Abbildung 1: Beispielhaftes Graphmodell
Graphen neigen mit zunehmender Größe dazu, unübersichtlich zu werden. Abbildung 2 zeigt
eine alternative Darstellung des betrachteten Modells aus Abbildung 1. Offensichtlich erhöht
diese Art der Darstellung die Übersichtlichkeit deutlich.
26
Customer
CNo: INTEGER
FirstName: VARCHAR(255)
LastName: VARCHAR(255)
Abbildung 2: Bildschirmdarstellung
Der Editor erlaubt, die gewünschte Visualisierung durch so genannte Darstellungsregeln in
deklarativer Weise zu beschreiben. Der zugrunde liegende Graph, im Folgenden als Anwendungsmodell bezeichnet, wird anhand der Darstellungsregeln um ein so genanntes Darstellungsmodell
ergänzt (Abbildung 3). Das Darstellungsmodell ist ebenfalls ein Graph; den verwendeten Knotenund Kantentypen ist eine graphische Entsprechung zugeordnet, beispielsweise eine Box oder ein
Pfeil. Eigenschaften, wie Farbe, Schriftart oder die Bildschirmposition, werden durch Attribute
beschrieben. Das Darstellungsmodell lässt sich sehr einfach in eine entsprechende Bildschirmdarstellung überführen.
Neben der Visualisierung lässt sich auch die Möglichkeit zum Editieren beliebig anpassen.
Dazu werden so genannte Editieroperationen in deklarativer Weise angegeben.
Text
caption: Customer
font-weight: bold
table head
Text
caption: CuNo: INTEGER
icon: /icons/key.png
table row
Table
background-color: blue
border-width: 1,5pt
table
ow
row
table r
Text
caption:
LastName: VARCHAR(255)
Text
caption:
FirstName: VARCHAR(255)
Abbildung 3: Darstellungsmodell
2
Graphtransformation
Anwendungs- und Darstellungsmodell sind Graphen, die Umsetzung des Anwendungsmodells in
ein entsprechendes Darstellungsmodell ist somit eine Graphtransformation. Bisher gibt es keine
Implementierungen von Graphtransformationssystemen, die über das Stadium von Forschungsprototypen hinausgehen. Aus diesem Grund und in Anbetracht spezieller Anforderungen an
die Sprache zur Definition von Transformationsregeln, fiel die Entscheidung zu einer eigenen
Entwicklung. Sie setzt den algebraischen Ansatz der Graphtransformation [Ehr86, EKL90] um.
Zusätzlich werden Attributbedingungen [EPT04], sowie positive und negative Graphbedingungen berücksichtigt [Lam04]. Als Grundlage dient eine relationale Datenbank. Neben der Speicherung von Graphen wird diese zur Suche nach isomoprhen Teilgraphen verwendet; dies ist eine
zentrale Aufgabe im Graphtransformationsprozess. Das Teilgraph-Isomorphie-Problem ist NPvollständig, die Berechnungen sind daher äußerst aufwendig. Relationale Datenbanken erzielen
gerade bei großen Graphen1 gute Ergebnisse, sofern die zu suchenden Teilgraphen klein sind;
dies ist für Graphtransformationsregeln typischerweise der Fall.
Die Verwendung von Graphtransformationsregeln zum Aufbau des Darstellungsmodells bietet ein Höchstmaß an Flexibilität. Die Möglichkeiten gehen weit über eine formatierte Darstellung eines Graphen hinaus. Vielmehr kann die Struktur des Darstellungsmodells beliebig vom
Anwendungsmodell abweichen. Dies ermöglicht es, von der Komplexität des zugrunde liegenden
Graphen zu abstrahieren.
1
Getestet wurden Graphen mit 5000 bis 45000 Knoten und etwa der doppelten Anzahl an Kanten
27
3
Aktualisierung des Darstellungsgraphen
Eine Editieroperation wird durch eine Menge von Graphtransformationsregeln mit festgelegtem
Kontrollfluss realisiert; die verwendeten Kontrollstrukturen entsprechen denen, die [Göt88] im
Rahmen der Programmierten Graphgrammatiken vorschlägt.
Bei der Anwendung einer Editieroperation ist zu beachten, dass Anwendungs- und Darstellungsmodell nebeneinander existieren. Wird eines der Modelle geändert, muss sich dies im jeweils
anderen widerspiegeln. Der Benutzer interagiert mit dem Darstellungsmodell. Daraus ergibt sich
eine Problematik, die als Variante des bekannten View-Update-Problems gesehen werden kann.
Im Allgemeinen ist es nicht möglich eine Änderung am Darstellungsmodell auf das Anwendungsmodell zu übertragen. Daher werden Editieroperationen verwendet, um das Anwendungsmodell
direkt zu modifizieren. Das Darstellungsmodell muss daraufhin entsprechend aktualisiert werden. Es ist zu beachten, dass bestimmte Informationen im Darstellungsmodell gehalten werden,
die sich nicht aus dem Anwendungsmodell herleiten lassen und deren Manipulation keine Auswirkungen auf selbiges hat. Ein Beispiel ist die Bildschirmposition der Kundentabelle. Es muss
sichergestellt werden, dass derartige Informationen im Laufe der Aktualisierung nicht verloren
gehen. Man kann daher das Darstellungsmodell nicht einfach verwerfen und neu berechnen.
Jede Veränderung des Anwendungsmodells darf sich nur auf diejenigen Teile des Darstellungsmodells auswirken, die tatsächlich betroffen sind. Um diese Teile zu finden, muss nachvollzogen
werden, welche Darstellungsregeln zu Anfang auf die geänderten Teile des Anwendungsmodells
angewendet wurden. Potentiell von der Änderungsoperation betroffen sind nur solche Teile des
Darstellungsmodells, die aus eben diesen Regelanwendungen hervorgingen.
4
Zum Entwicklungsstand
Die Entwicklung des Editors ist weitgehend abgeschlossen. Es konnte gezeigt werden, dass relationale Datenbanken gut zur Transformation großer Graphen nach dem algebraischen Ansatz
geeignet sind. Weiterhin ist es gelungen, einen effizienten Ansatz zur selektiven Aktualisierung
des Darstellungsgraphen zu entwickeln.
Literatur
[Ehr86] Hartmut Ehrig. Tutorial introduction to the algebraic approach of graph grammars.
In Graph-Grammars and Their Application to Computer Science, pages 3–14, 1986.
[EKL90] Hartmut Ehrig, Martin Korff, and Michael Löwe. Tutorial introduction to the algebraic
approach of graph grammars based on double and single pushouts. In Graph-Grammars
and Their Application to Computer Science, pages 24–37, 1990.
[EPT04] Hartmut Ehrig, Ulrike Prange, and Gabriele Taentzer. Fundamental theory for typed
attributed graph transformation. Technical report, 2004.
[Göt88] Herbert Göttler. Graphgrammatiken in der Softwaretechnik: Theorie und Anwendungen, volume 178 of Informatik-Fachberichte. Springer, 1988.
[Lam04] Leen Lambers. A new version of gtxl: An exchange format for graph transformation
systems. In Workshop on Graph-Based Tools (GraBaTs) 2004 at Second International
Conference on Graph Transformation (ICGT 2004), 2004.
28
Self-Tuning für Bitmap-Index-Kongurationen
Andreas Lübcke
Institut für Technische und Betriebliche Informationssysteme
Otto-von-Guericke-Universität Magdeburg
1
Einführung
Als Teilgebiet des Self-Tunings in Datenbankmanegementsysteme wird das Ziel verfolgt, die
Index- oder Design Advisor [1, 6] der aktuellen DBMS so abzuändern, daÿ bezüglich der Indexkonguration ein sich selbst überwachendes und tunendes DBMS entsteht. Dabei sollen weitgehend
die bisherigen statischen Ansätze der Advisor genutzt werden, diese aber in einem dynamischen
und autonomen Kontext Verwendung nden. Die neu entstandenen Möglichkeiten sollen zu einer selbstständigen Anpassung an sich ändernde Rahmenbedingungen führen. Dies bezieht sich
sowohl auf die Daten selbst, auf deren Nutzung sowie alle relevanten Aspekte der Systemumgebung. Self-Tuning wird in aktuellen Ansätzen durch einen Regelkreis [5] aus der Überwachung von
Systemverhalten und -nutzung (Observation), der Vorhersage zukünftig gewinnbringender Systemeinstellungen (Prediction) und deren Umsetzung (Reaction) realisiert. Für das Self-Tuning von
Index-Kongurationen besteht dieser Regelkreis aus der Überwachung des aktuellen Workloads,
der Ableitung geeigneter Indexkandidaten [2] und gegebenfalls der Erzeugung der vielversprechendsten Kandidaten und dem Löschen weniger protabler Indexe [4]. Bei aktuellen Ansätzen
blieben Bitmap-Indexe [3] und deren Besonderheiten bisher unberücksichtigt und werden deshalb
im Rahmen des hier vorgestellten Diplomprojektes untersucht.
2
Grundlagen und Anforderungen
Bitmap-Indexe ersetzen für einzelne Schlüsselwerte Tupelidentikator-Listen durch Bitvektoren,
und sind deshalb besonders ezient, wenn nur wenige mögliche Schlüsselwerte existieren. Der
erste auällige Vorteil ist dabei der geringe Platzbedarf. Desweiteren können Bitvektoren leicht
logisch miteinander verknüpft werden, um komplexe Selektionsbedingungen auszuwerten. Aus
den genannten Gründen werden Bitmap-Indexe oft in Data Warehouse-Lösungen für die Indexierung von Dimensionsdaten verwendet. Ausserdem stellen Bitmap-Indexe als Verbund-Indexe
eine ideale Möglichkeit zur Berechnung von STAR-Joins dar. Der Aufbau von Bitmap-Indexen
bringt neben Vorteilen aber auch Nachteile, denn für Änderungsoperationen sind Matrixmodikationen nötig, welche aufwändig sind und Sperrkonikte wahrscheinlicher werden lassen.
Für das Self-Tuning von Bitmap-Index-Kongurationen ergeben sich im Vergleich zu herkömmlichen B-Baum-Indexen eine Reihe von neuen Anforderungen, die hier kurz diskutiert werden.
Wie gehabt basiert die Ableitung einer Index-Konguration auf der Überwachung von Workloads.
Jedoch ergeben sich bei der Auswertung einzelner Anfragen folgende Unterschiede.
•
r(R) sind lediglich Prädikate aus der WHEREKlausel relevant, welche die Form A = const aufweisen, wobei die Spalte A ∈ R eine
Attributwertskardinalitätbedingung card(dom(A))/card(r(R)) < maxSelectivity erfüllt,
d.h. A hat eine geringe Anzahl möglicher Werte im Vergleich zur Gröÿe der Relation.
•
Für Bitmap-Join-Indexe muss ein (innerer) Equi-Join
Für Bitmap-Indexe auf einer Relation
A2 ∈ S
r(R) ./A1 =A2 r(S) mit A1 ∈ R und
A3 ∈ S (Indexschlüs-
(Verbundattribute) erkannt werden, wobei eine weitere Spalte
sel) in der WHERE-Klausel existiert, für die die oben genannten Bedingungen zutreen.
Für die Erkennung der Join-Bedingung können in einem Data Warehouse gegebenfalls Dimensionsdenitionen herangezogen werden.
29
Observation
Prediction
Reaction
Für jede Anfrage Statistik
für Indexkandidaten:
- Indexempfehlungen
- Profit und Größe jedes
Indexkandidaten
- Kombinationen von
Indexkandidaten
Kontinuierliche
Kontrolle der Indexstatistiken
- entsteht günstigere
Indexkonfiguration
durch Austausch von
Indexen?
Erzeugen/Löschen von
Indexen zu geeignetem
Zeitpunkt
- vor/nach der Anfrage
- System Downtime
Abbildung 1: Regelkreis Index-Self-Tuning
•
Bitmap-Indexe sind besonders sinnvoll, wenn davon mehrere in einer Anfrage verwendet
und ihre Bit-Felder logisch kombiniert werden. Dies muss im Entscheidungsmodell entsprechen berücksichtigt werden.
•
Mehrspalten-Bitmap-Indexe sind möglich, aber durch die schlechtere Attributwertskardinalität und eingeschränkte Kombinierbarkeit meist nicht empfohlen, wodurch sich eine
Einschränkung des Suchraums ergibt.
•
Bitmap-Indexe haben auf Grund Ihrer geringeren Gröÿe meist ein besseren Verhältnis von
Nutzen zu Speicherverbrauch, weshalb die Integration mit dem Tuning anderer Indexstrukturen berücksichtig werden muss.
•
Bitmap-Indexe haben vergleichsweise geringe Erzeugungskosten, jedoch höhere Kosten bei
Updates. Dies muss in das Kostenmodell einiessen.
3
Ansätze zum autonomen Bitmap Index Tuning
Das prinzipielle Vorgehen beim Self-Tuning von Bitmap-Index-Kongurationen ist in Abb. 1
dargestellt. Generell werden die Indexkandidaten durch eine syntaktische Analyse von Anfragen
entsprechend den oben genannten Anforderungen ermittelt. Daraufhin werden diese Kandidaten
in den Systemtabellen erzeugt und für die eine What-If-Analyse (was wäre, wenn diese Index
existieren würden) dem Optimierer zur Verfügung gestellt.
Der aus der What-If-Analyse berechnete Gewinn von Indexkandidaten und bereits materialisierten Indexen gegenüber der Ausführung der Anfrage ohne Indexe wird für spätere Analyse
und Empfehlungen als Indextstatistiken gespeichert. Aufgrund der Kombinierbarkeit der BitmapIndexe stellt sich die Frage, ob diese jeweils einzeln gespeichert werden sollten, oder diese wiederum direkt in die Bewertung der Konguration eingehen. Auf dieser Basis muÿ ein angepaÿtes
Entscheidungsmodell gefunden werden, daÿ die Besonderheiten der Bitmap-Indexe berücksichtigt. Weiterhin muÿ anhand der Gröÿe des Indexpools und weiteren Parametern entschieden
werden, welche Konguration bestmöglich alle Parameter erfüllen kann. Dies kann durch einen
Greedy-Algorithmus oder Dynamic Programming geschehen. Abschlieÿend muÿ die Frage des
Erstellungszeitpunktes geklärt werden, denn werden die Bitmap-Indexe vor der Ausführung der
Anfrage erzeugt, dann führt dies zu einer verzögerten Ausführung. Hier muÿ betrachtet werden,
wie stark die Erzeugung der Kongurationen die Anfragezeiten beeinuÿt. Im Gegensatz dazu
können die Index-Kongurationen in der System Downtime oder Phasen geringer Auslastung
erzeugt werden, wodurch der Gewinn durch die neue Index-Konguration für die aktuelle Anfrage verloren geht. Für das Diplomvorhaben wird das DBMS Oracle 10g genutzt. Dessen Design
30
Advisor bietet bereits eine Unterstützung für Bitmap-Indexe an, jedoch werden keine VerbundIndexe unterstützt und Ziel der hier beschriebenen Arbeit ist die dynamische Unterstützung des
Self-Tuning von Bitmap-Indexen. Im Rahmen dieses Diplomvorhabens wird das Self-Tuning der
Bitmap-Indexe unabhängig von anderen Indexstrukturen in einem separaten Index-Pool behandelt.
Literatur
[1] S. Agrawal, S. Chaudhuri, L. Kollár, A. P. Marathe, V. R. Narasayya, and M. Syamala. Database
Tuning Advisor for Microsoft SQL Server 2005. In VLDB '04, pages 11101121, 2004.
[2] N. Bruno and S. Chaudhuri. To Tune or not to Tune? A Lightweight Physical Design Alerter. In
VLDB '06, pages 499510, 2006.
[3] C.-Y. Chan and Y. E. Ioannidis. Bitmap index design and evaluation. In SIGMOD '98: Proceedings
of the 1998 ACM SIGMOD international conference on Management of data, pages 355366, New
York, NY, USA, 1998. ACM Press.
[4] K. Sattler, E. Schallehn, and I. Geist. Autonomous Query-driven Index Tuning. In Proc. Int. Database
Engineering and Applications Symposium (IDEAS 2004), Coimbra, Portugal, pages 439448, July
2004.
[5] G. Weikum, C. Hasse, A. Moenkeberg, and P. Zabback. The COMFORT Automatic Tuning Project,
Invited Project Review. Information Systems, 19(5):381432, 1994.
[6] D. C. Zilio, J. Rao, S. Lightstone, G. M. Lohman, A. Storm, C. Garcia-Arellano, and S. Fadden. DB2
Design Advisor: Integrated Automatic Physical Database Design. In VLDB '04, pages 10871097,
2004.
31
Subspace Clustering für die Analyse von CGH Daten
Emmanuel Alexander Müller
[email protected]
Lehrstuhl für Datenmanagement und Exploration
Prof. Dr. Thomas Seidl
RWTH Aachen
Abstract: Durch Problemstellungen bei der Anwendung von traditionellen Clustering-Algorithmen auf hochdimensionalen Daten motiviert, wurde im Rahmen meiner Diplomarbeit ein
neues algorithmisches Konzept zum effizienten Subspace Clustering entwickelt. Eine mögliche
Anwendung dieses Konzeptes stellt die Analyse von CGH Daten dar. Durch Subspace Clustering ist es möglich, Gruppen von Patienten zu identifizieren, deren Genom charakteristische
Veränderungen in bestimmten Abschnitten der DNA aufweist. Durch Analyse der so identifizierten Gruppen können Hinweise auf Zusammenhänge zwischen den charakteristischen
Veränderungen und den Erkrankungen der Patienten erkannt werden.
Zuordnung: Data Mining, Clustering, hochdimensionale Daten, Comparative Genomic
Hybridization
Subspace Clustering
Heutzutage werden enorme Datenmengen zur Analyse von verschiedensten Sachverhalten herangezogen, sei es zur Analyse von Kundenverhalten im Einzelhandel oder Hochdurchsatzexperimenten in der Biologie um nur zwei Beispiele zu nennen. Dabei entstehen neue Problemstellungen, welche nur durch den Einsatz von effizienten Data Mining Verfahren gelöst werden
können. Clustering ist eines der hierzu verwendeten Verfahren, wie z.B. in DBSCAN [EKSX96]
umgesetzt. Clustering ist die automatische Gruppierung von Objekten. Objekte innerhalb einer Gruppe sollen möglichst ähnlich sein, während Objekte verschiedener Gruppen möglichst
unähnlich sein sollen. Jedoch gelingt es bei manchen Datensätzen, welche sich durch einen hochdimensionalen Datenraum auszeichnen, nicht mehr mit den bisher gebräuchlichen Clustering
Algorithmen gute Resultate zu erzielen. Dies liegt in der hohen Dimensionalität (Anzahl der Attribute) der verwendeten Objektbeschreibung begründet. Für traditionelle Clustering Verfahren
erscheinen aufgrund der hohen Dimensionalität die gegeben Daten als gleichverteilt, wodurch
keine Cluster zu erkennen sind. Irrelevante Dimensionen, in denen die Objekte einer Gruppe
stark streuen, sind dafür verantwortlich.
Eine Lösung für das hier beschriebene Problem scheint einfach. Die irrelevanten Dimensionen
sind auszublenden. Als Subspace Cluster (O, S) wird allgemein eine Objektmenge O zusammen
mit einer Auswahl von Dimensionen S bezeichnet. Der durch die Dimensionen in S gebildete Teilraum gibt dabei an, welches die relevanten Dimensionen für den durch die Objekte in
O gebildeten Cluster sind. Es lassen sich somit Cluster in unterschiedlichen Projektionen des
Datenraumes finden, wie erstmals in CLIQUE [AGGR98] vorgestellt. Diese Teilräume und die
darin enthaltenen Cluster zu identifizieren, ist die Aufgabenstellung für das Subspace Clustering.
Die naive Reduktion des Problems auf das traditionelle Clustering würde alle möglichen Teilräume
mit einem bestehenden Clustering Verfahren untersuchen. Wegen der exponentiellen Anzahl an
32
möglichen Teilräumen ist dies jedoch nicht effizient möglich. Im Rahmen meiner Diplomarbeit
wurde ein effizienter Subspace Clustering Algorithmus entwickelt, welcher auf erfolgreich angewendeten dichte-basierten Ansätzen aufbaut und diese durch eine statistisch fundierte Modellierung erweitert. Durch den Algorithmus wird die Vollständigkeit des Resultates gewährleistet,
im Gegensatz zu bestehenden Verfahren, welche nur durch ein approximatives Vorgehen eine
effiziente Berechnung erreichen. Durch Verwendung einer neuen Datenstruktur wird im eigenen
Algorithmus sowohl die Effizienz als auch die Vollständigkeit bei der Berechnung erzielt.
Subspace Clustering von CGH Daten
Subspace Clustering wurde im Rahmen der Diplomarbeit für die Analyse von CGH (comparative
genomic hybridization) Daten verwendet. Der untersuchte Datensatz besteht aus einer Menge
von CGH-Untersuchungen von verschieden Patienten, die an Krebs erkrankt sind. Die Daten
stammen von der Website Progenetix.net [BC01], welche solche Untersuchungen in einer Datenbank verwaltet und zur Forschung frei zur Verfügung stellt. Bei einer CGH-Untersuchung wird
das Genom auf veränderte Genomabschnitte untersucht. Es können dabei Vervielfältigungen
oder Deletionen von Abschnitten auf der DNA identifiziert werden. Eine solche Veränderung
weist auf das evtl. Vorkommen von Onkogenen (Zugewinn) bzw, Tumorsuppressorgenen (Verlust) in der betroffenen Region hin [LMC+ 06]. Es soll mit solchen Untersuchungen der Zusammenhang zwischen Mutationen in gewissen Regionen der DNA und verschiedenen Krebserkrankungen untersucht werden. Zu jedem Patienten liegen in dem verwendeten Datensatz für 862
Abschnitte des Genoms Messwerte zur Veränderung der DNA vor. Zusätzlich liegt zu jedem
Patienten eine Einteilung in eine Klasse von Krebserkrankungen vor.
Ziel ist es, eine Gruppierung der Patienten anhand der gegebenen CGH-Untersuchungen vorzunehmen. Eine Gruppe soll dabei eine für sie charakteristische Veränderung bestimmter Abschnitte der DNA aufweisen. Die für diese Gruppierungen durch das Subspace Clustering gewählten
Dimensionen (Abschnitte der DNA) werden dann, zusammen mit den in diesen Gruppen gefunden Krebserkrankungen, von Experten analysiert. Es kann dadurch ein Hinweis auf einen
Zusammenhang zwischen Mutationen in bestimmten Regionen des Genoms und den dabei auftretenden Krebserkrankungen erkannt werden.
Modellierung
Die Veränderungen in den 862 Abschnitten werden aggregiert für die 48 Chromosomenarme
betrachtet. Dabei werden Vervielfältigungen, Deletionen und keine Veränderungen oder keine
eindeutigen Veränderungen auf einem Chromosomenarm durch die diskreten Attributwerten 1,1 und 0 modelliert. Durch Subspace Clustering soll eine charakteristische Veränderung (1,-1)
auf bestimmten Chromosomenarmen identifiziert werden. Man ist dabei jedoch nicht an keinen
Veränderungen oder an nicht eindeutigen Veränderungen, wie sie der Wert 0 repräsentiert, interessiert. Relevante Informationen stellen in diesem Anwendungsfall also nur die Werte 1 und
-1 dar, der Wert 0 ist als irrelevant zu betrachten. Als irrelevant wird beim Subspace Clustering
eine Dimension mit starker Streuung der Daten angesehen. Man transformiert somit die Werte
in drei getrennt voneinander vorliegende Bereiche in einem kontinuierlichen Wertebereich. Der
Wert 0 wird dabei in einen Bereich, in welchem die Werte durch einen Zufallsgenerator gleichverteilt vorliegen, transformiert. Abbildung 1 verdeutlicht diese Transformation zweier Objekte
mit nur zwei Dimensionen. Es sind pro Dimension die drei Bereiche für die Werte -1,0,1 hervorgehoben, in die ein Objekt transformiert wird. In dem schraffierten Bereich können somit alle
Objekte mit Wert 1 in der ersten Dimension als Subspace Cluster erkannt werden.
33
-1
0
1
(1,0)
( -1 , 1 )
Abbildung 1: Transformation zweier 2D CGH-Objekte zur Identifikation als Subspace Cluster
Diskussion der Ergebnisse
Es wurden Subspace Cluster mit mindestens 20 Objekten (Patienten) im Datensatz gesucht.
Dabei wurden Cluster in bis zu 7-dimensionalen Teilräumen (Auwahl von relevanten Chromosomenarmen) gefunden, welche 1407 der 1823 Patienten beinhalten. Die identifizierten Subspace
Cluster stellen eine Gruppierung der Krankheitsbilder dar, wobei in den meisten Fällen innerhalb
einer Gruppe eine Krankheit den Cluster dominiert. Eine Auswahl von identifizierten Subspace
Clustern wurde manuell auf bekannte Zusammenhänge zwischen Mutationen und Erkrankungen untersucht. Dabei konnten schon bekannte Zusammenhänge durch das Clustering bestätigt
werden. Darüber hinaus könnte, durch weitere Analysen der gefundenen Subspace Cluster durch
Mediziner auf noch unbekannte Zusammenhänge zwischen Mutationen auf bestimmten Chromosomen und gewissen Krebserkrankungen geschlossen werden.
Danksagung
Mein besonderer Dank gilt Michael Baudis für die Bereitstellung und Aufarbeitung der in den
Untersuchungen verwendeten CGH Daten.
Literatur
[AGGR98] R. Agrawal, J. Gehrke, D. Gunopulos und P. Raghavan. Automatic subspace clustering of high dimensional data for data mining applications. In SIGMOD, Seiten
94–105, 1998.
[BC01]
M. Baudis und M. Cleary. Progenetix.net: an online repository for molecular cytogenetic aberration data. Bioinformatics, 17 (12):1228–1229, 2001.
[EKSX96] M. Ester, H.-P. Kriegel, J. Sander und X. Xu. A density-based algorithm for discovering clusters in large spatial databases. In KDD, Seiten 226–231, 1996.
[LMC+ 06] J. Liu, J. Mohammed, J. Carter, S. Ranka, T. Kahveci und M. Baudis. Distancebased clustering of CGH data. Bioinformatics, 22 (16):1971–1978, 2006.
34
CouPé: Ein Query Processor für UniStore
Martin Richtarsky
TU Ilmenau, Fachgebiet Datenbanken und Informationssysteme
1
Einleitung
Die im folgenden vorgestellte Diplomarbeit ist Teil von UniStore, einem Projekt zur Realisierung
einer massiv verteilten Universal Storage-Plattform zur Speicherung von strukturierten Daten
und Durchführung komplexer Anfragen. Der Verzicht auf zentrale Komponenten und der Einsatz einer P2P-Architektur ermöglichen eine Skalierung bis auf Internetgröße. Grundlage bildet
ein DHT-basiertes Overlay-Netzwerk, durch das Daten verteilt gespeichert und effizient extrahiert werden können. Angestrebt wird ein Datensystem, das durch Hinzunahme weiterer Peers
skaliert werden kann und eine Anfragebearbeitung, die auf den Funktionen des Overlays aufsetzt und komplexe, in einer deklarativen Sprache formulierte Anfragen effizient beantwortet.
Ein mögliches Einsatzgebiet sind Public Data Management-Systeme, die auf sehr umfangreichen
Daten arbeiten. Üblicherweise werden diese von mehreren Teilnehmern zur Verfügung gestellt
und können verschiedene Schemata aufweisen. Infrastrukturkosten sollen fair verteilt werden,
Lastverteilung und Ausfallsicherheit sind gewünscht. Beispiele für solche Systeme sind Datenbanken für das semantische Web, spezialisierte Suchmaschinen und Verzeichnisdienste. Um die
Skalierbarkeit zu gewährleisten, wird auf bestimmte DBMS-Features wie z.B. Transaktionen
verzichtet, was aufgrund der Profile der zu erwartenden Anwendungen zulässig ist.
Thema der Diplomarbeit ist die Realisierung und Evaluierung der Anfragebearbeitung. Auf
Basis der eng begrenzten Anfragemöglichkeiten der DHT und unter Berücksichtigung der Eigenschaften von P2P-Netzen muss ein geeigneter Ansatz für komplexe Anfragen gefunden werden. Wenn möglich, sind zur Effizienzsteigerung Overlay-Features zu nutzen. Weiterhin sind
Ähnlichkeits- und Operatoren auf Schemaebene umzusetzen, und die Skalierbarkeit muss unter
Beweis gestellt werden.
2
Grundlagen: P-Grid, Speicherung strukturierter Daten
Das verwendete Overlay-Netzwerk P-Grid [1] bietet im Gegensatz zu anderen Designs wie CAN
oder Chord zusätzlich Bereichsanfragen – es können effizient alle Daten extrahiert werden, die
unter einem Schlüssel mit einem bestimmten Präfix eingefügt wurden, auch wenn sie sich auf verschiedenen Peers befinden (eine präfixerhaltende Hashfunktion h muss eingesetzt werden). Dies
kann die Effizienz der Anfragebearbeitung erheblich steigern. In dieser Arbeit wird beispielhaft
von relationalen Daten ausgegangen. Jedes Tupel (OID, v1 , ..., vn ) einer Relation R(A1 , ..., An )
wird zunächst in n Tripel der Form (OID, Ai , vi ) (object identifier, attribute, value) aufgespalten, OID ist eine systemweit eindeutige ID. Jedes dieser Tripel wird nun in der DHT gespeichert,
wobei der Schlüssel jeweils durch Anwendung einer Hashfunktion auf Komponenten des Tripels
ermittelt wird. Dadurch entstehen Indexe, über die dann später auf die Daten zugegriffen werden
kann. Zwei mögliche Indexe sind:
OID-Index Die Tripel werden unter dem Schlüssel h(OID) abgelegt. Dadurch werden Tripel
eines Tupels auf demselben Peer gespeichert und ein Tupel kann durch das Kontaktieren eines
Peers schnell rekonstruiert werden.
35
VQL Query
VQL Parser
Logical
Query Plan
Optimizer/
Code Generator
Logical/Physical
Query Plan +
Strategies
Strategies
Execution Engine
Results
Operators
Abbildung 1: Architektur des Query Processors
Attribute-Value-Index In diesem Fall ist der Schlüssel die Konkatenation aus h(Ai ) und
h(vi ). Mit einer Bereichsanfrage auf h(Ai ) lässt sich so eine Spalte der Relation extrahieren,
Zugriffe auf bestimmte Werte sind ebenfalls möglich.
Weiterhin gibt es q-gram-Indexe [2] zur Unterstützung von Ähnlichkeitsanfragen auf Strings.
Es ist möglich, nur Teile einer Relation zu indexieren.
3
Architektur des Query Processors
Die Architektur ist in Abb. 1 dargestellt. Mit VQL existiert eine deklarative Anfragesprache,
die auf Tripelbasis arbeitet. Eine solche Anfrage wird zunächst an den bereits existierenden
VQL-Parser übergeben, der diese in einen logischen Anfrageplan umwandelt und algebraische
Umformungen durchführt. In der Optimierungs-/Codegenerierungsphase werden den logischen
Operatoren physische zugeordnet, die gleichzeitig ausführbaren Code repräsentieren. Die dabei
zu verwendenden Strategien müssen spezifiziert werden. Eine Optimierung im eigentlichen Sinne
war nicht Teil dieser Arbeit, kann aber an dieser Stelle leicht ergänzt werden – die derzeit manuelle Auswahl der Strategien wird dann von einer Kostenabschätzungskomponente übernommen.
Es ist möglich, logische Operatoren erst während der Bearbeitung der Anfrage zu substituieren,
was z.B. eine Einbeziehung von Statistiken auf den beteiligten Peers ermöglicht (adaptive query
processing). Dies ist in P2P-Systemen essenziell für eine erfolgreiche Optimierung. Die Execution
Engine bearbeitet den Plan unter Zuhilfenahme der Operatoren und liefert das Ergebnis.
4
Execution Engine
Als einfache Strategie zur Bearbeitung eines Anfrageplans bestehend aus physischen Operatoren wurde ein den Mutant Query Plans [3] vergleichbarer Ansatz gewählt: Operatoren des Plans
speichern Zwischenergebnisse und der komplette Plan wird durch das Netz gesandt. Die Abarbeitung erfolgt in Postorder-Reihenfolge. Dadurch wird jeder Operator erst dann bearbeitet,
wenn alle seine Kindoperatoren abgearbeitet sind, und die Verwendung der dort gespeicherten
Zwischenergebnisse ist möglich. Operatoren auf Blattebene extrahieren Daten direkt aus der
lokalen Datenbasis auf den entsprechenden Peers. Ein Operator bestimmt selbst, wann der Plan
an einen anderen Peer geschickt werden muss. Die Bearbeitung ist an der Wurzel beendet, und
die Ergebnisse werden an den Anfrager zurückgeschickt.
Da dieser naive Ansatz relativ ineffizient ist (keine Parallelität), wurde er um drei weitere
Strategien erweitert. Die ersten beiden realisieren Intra-Operator-, der dritte Inter-OperatorParallelität. In allen Fällen entstehen damit mehrere nebenläufige Pläne pro Anfrage, die aber
alle dieselbe Operatorstruktur aufweisen.
Bereichsanfragen Wenn auf die Daten eines Attributs zugegriffen wird, muss der Plan nacheinander an alle Peers geschickt werden, auf denen der entsprechende Attribute-Value-Index
gespeichert ist. Es ist aber auch möglich, hierfür eine Bereichsanfrage einzusetzen. In diesem
36
Fall wird nur eine Anfrage abgesetzt, und der Routing-Layer von P-Grid sorgt dafür, dass jeder
zuständige Peer eine Kopie des Plans erhält, die dann parallel weiterverarbeitet werden.
Plan Cloning Bei diesem Ansatz erfolgt die Duplizierung der Pläne in der Execution Engine
selbst, unter Kontrolle des gerade aktiven Operators. Dieser kann für jeden Plan ein eigenes Ziel
angeben und ihn zusätzlich modifizieren. Dadurch eröffnen sich weitreichende Möglichkeiten in
die Anfragebearbeitung einzugreifen. Intra-Operator-Parallelität ist nun auch für Operatoren
möglich, die Indexe nicht mit Bereichsanfragen ansprechen können (z.B. q-gram-Suche).
Parallele Bearbeitung von binären Operatoren Die Zweige der Operatoren werden parallel abgearbeitet.
In allen drei Fällen müssen die Pläne an einer geeigneten Stelle wieder zusammengeführt
werden. Dies ist notwendig für die Berechnung von blockierenden Operatoren (z.B. Sortierung)
und des Endergebnisses. Um Wartezeiten zu vermeiden, wird dafür Online Processing eingesetzt:
Anstatt auf alle parallelen Pläne zu warten, werden Teil(zwischen)ergebnisse schnellstmöglich
weiterverarbeitet, und es entstehen mehrere Versionen des Ergebnisses. Dadurch sind erste Antworten schnell verfügbar und werden dann sukzessive verfeinert.
5
Physische Operatoren
Zu jedem logischen Operator existieren mehrere Implementierungen, die sich in Eigenschaften
wie verwendete Indexe, Parallelität oder Bandbreitenbedarf unterscheiden. Die Datentypen Integer und String werden unterstützt. Die meisten Operatoren können sowohl auf die Werte als
auch auf die Attribute der Tripel angewendet werden (instance bzw. schema level). Neben den
üblichen Vergleichen wie <, >, ≤, ≥, =, 6= wurden Ähnlichkeitsoperationen (∼) zur Bearbeitung von mit Fehlern behafteten Daten realisiert. Die Zusammenführung von Datenbeständen
mit ähnlichen Schemata wird erleichtert durch Ähnlichkeitsjoins auf Schemaebene. Dazu wurden
Operatoren entwickelt, die auf q-gram-basierten Ähnlichkeitsindexen arbeiten. Das Best-EffortPrinzip wird angewendet: Wird ein benötigtes Datum nicht gefunden, werden nur die betroffenen
Tripel verworfen, alle übrigen bearbeitet und ein unter Umständen nicht vollständiges Ergebnis
generiert. Dies ist eine praktikable Lösung in Systemen, die keine Konsistenz gewährleisten.
6
Evaluierung
Die zwei wichtigsten Fragen sind hier: (1) Ist die vorgestellte Anfragebearbeitung in DHTs generell praxistauglich, skaliert sie? (2) Welche Operatoren sind für welche Situationen besonders geeignet? Dazu wurden bereits zahlreiche erfolgreiche Tests mit bis zu 35 Peers in LANs absolviert.
Die eigentliche Evaluierung wird momentan auf PlanetLab (www.planet-lab.org) durchgeführt,
um möglichst praxisnahe Bedingungen zu erhalten. Auch hier wurden mit ähnlichen Netzgrößen
bereits gute Erfahrungen gemacht. Es ist geplant, mit bis zu 200 Peers zu testen.
Literatur
[1] Karl Aberer. P-Grid: A self-organizing access structure for P2P information systems. In
CoopIS, 2001.
[2] Marcel Karnstedt, Kai-Uwe Sattler, Manfred Hauswirth, and Roman Schmidt. Similarity
Queries on Structured Data in Structured Overlays. In NetDB’06, 2006.
[3] Vassilis Papadimos and David Maier. Mutant Query Plans. Information & Software Technology, 44(4), 2002.
37
Multidimensionale Indexierung in ORDBMS
Verfasser:
betreut durch:
Gunnar Söllig, Universität Rostock, E-Mail: soellig(at)web.de
Lehrstuhl Datenbanken und Informationssysteme am Institut für
Informatik der Universität Rostock
Thema der Studienarbeit [1] waren für multidimensionale Indexierung geeignete Zugriffsstrukturen in ORDBMS. Diese werden insbesondere zur Ähnlichkeitssuche auf komplexen Datenstrukturen
benötigt. Praktische Einsatzgebiete finden sich etwa bei der inhaltsbasierten Suche in der MultimediaIndexierung, in CAD-Anwendungen und im Bereich des Data Mining zur Unterstützung von ClusteringAlgorithmen und OLAP. Die in herkömmlichen Datenbanksystemen vorhandenen Zugriffsstrukturen
sind für diese Zwecke nur sehr eingeschränkt einsetzbar.
Den Ausgangspunkt der Untersuchungen bildeten die in [2] vorgestellten Möglichkeiten der Erweiterung objektrelationaler Systeme, darunter die Methode des Generalized Search Tree [3] und das Relational Indexing. Das Indexverfahren des LSDh-Baumes nach A. Henrich, beschrieben in [4], wurde
mittels Relational Indexing umgesetzt und für das System IBM DB2 prototypisch implementiert. Es ist
eines der Verfahren, die vom sogenannten Curse of Dimensionality“ am wenigsten betroffen sind, und
”
erzielte in Leistungstests, insbesondere im direkten Vergleich mit R-baumbasierten Verfahren (Varianten
des X-Baumes), herausragende Ergebnisse. Seine interne Umsetzung lässt sich auf B-Bäume abbilden.
Das von Henrich et al. vorgestellte Paging-Konzept verteilt den Splitbaum des Indexes auf eine permanent im Speicher zu verwaltende Wurzelseite und weitere externe Verzeichnisseiten, falls die Größe
des bereitgestellten Hauptspeichers überschritten wird. Für die Umsetzung mittels Relational Indexing
werden die Knoten des Splitbaumes schemabezogen mit relationalen Tabellen in aus Knotennummer und
Splitinformationen bestehenden Tupeln abgelegt. Die gemeinsame Speicherung zusammengehöriger
Teilbäume auf derselben physischen Seite wird durch ein zusätzliches Attribut mit der Seitennummer
und einen Standardindex bezüglich dieses Attributes erreicht. Die Blattseiten des Indexes speichern die
indexierten Featurewerte und eine Zeilenkennung bezüglich der Nutzertabelle. Sie werden auf gleiche
Weise in relationalen Tabellen gespeichert, wobei die verwendeten Seitennummern sich in die Knotennummerierung des Splitbaumes einfügen, siehe dazu untenstehende Abbildung. Den Zusammenhang
zwischen Nutzertabellen und Indextabellen eines Schemas beinhaltet eine dritte Relation mit Metadaten. Dies sind Name der Nutzertabelle, Anzahl indexierter Dimensionen, interne Schlüsselnummer der
Tabelle, eingestellte Größen von Wurzel- und Verzeichnisseiten usw.
Das Relational Indexing Framework von IBM DB2 ist für die Implementation nicht geeignet, da es
beim Einfügen den Zugriff auf die Informationen des aktuell einzufügenden Datensatzes beschränkt. Die
Funktionalität des Indexes wird deshalb durch DB2 UDFs bereitgestellt, die als externe Funktionen einer
C++-basierten DLL registriert werden. Ihr Aufruf wird durch an die Nutzertabelle gebundene Trigger
initiiert. Die Registrierung der Funktionen, Triggererzeugung u.ä. erfolgt dabei weitgehend automatisch
(für ein System mit konzeptueller Schnittstelle für Extensible Indexing wäre die Deklarative Integration
gegeben). Die Implementation unterstützt sämtliche für den LSDh-Baum vorgesehenen Anfragearten,
neben der Punktanfrage (identity query) also Bereichsanfragen und zur Ähnlichkeitssuche sowohl - als
auch k -NNB-Anfragen, Ranking-Anfragen mit Einschränkungen. Partial-Match-Anfragen können durch
Bereichsabfragen simuliert werden. Dieselbe Indexinstanz kann Anfragen mit verschiedenen nutzerdefinierten Ähnlichkeitsmaßen unterstützen. Verwendbare Distanzmaße sind z.B. Euklidische Distanz (Metrik L2 ), Maximum-Metrik L1 und gewichtete Distanzfunktionen. Zukünftige mögliche Erweiterungen
wären die Speicherung von Coded Actual Data Regions, die Umsetzung einer Optimiererschnittstelle
und Maßnahmen zur Vermeidung der Baumdegeneration.
38
Abbildung 1: Nummerierung der Knoten und Seiten
Die Betrachtung hochdimensionaler Indexstrukturen wird in der derzeit laufenden Diplomarbeit fortgesetzt. Darin wird untersucht, welche Zugriffsverfahren für das Retrieval digitaler Bilder der INEXMultimediakollektion einsetzbar sind (Wikipedia-Bilder). Dies geschieht auf der Basis automatisch extrahierter Featurewerte. Am Beispiel des Oracle Datenbank Management Systems werden verschiedene
Mechanismen zur Integration nutzerdefinierter Zugriffsstrukturen untersucht und bezüglich der prototypischen Implementation ausgewählter Verfahren deren Effizienz evaluiert. Insbesondere wird die unmittelbare Umsetzung von Zugriffsverfahren basierend auf Standardindexen deren Anbindung an GiSTFrameworks gegenübergestellt.
Literatur
[1] Gunnar Söllig: Umsetzung von nutzerdefinierten Indexstrukturen in ORDBMS am Beispiel eines
Indexes für mehrdimensionale Datenstrukturen (Studienarbeit), Universität Rostock, 2006
[2] Hans-Peter Kriegel, Martin Pfeifle, Marco Pötke, Thomas Seidl: The Paradigm of Relational Indexing: A Survey; In LNI – Tagungsband der 10. BTW-Konferenz, Leipzig, 2003
[3] Joseph M. Hellerstein, Jeffrey F. Naughton, Avi Pfeffer: Generalized Search Trees for Database
Systems; In Proceedings 21st International Conference on VLDB, 1995
[4] Andreas Henrich: The LSDh-tree: An Access Structure for Feature Vectors; In Proceedings 14th
International Conference on Data Engineering, Orlando 1998
39
Konzeption und prototypische Realisierung einer Portalanwendung zur
föderierten Suche im Online-Angebot einer Bibliothek
Marcus Wenzel
Institut für Informatik
Friedrich-Schiller-Universität Jena
[email protected]
1
Motivation und Aufgabenstellung
Das elektronische Angebot einer Bibliothek stellt eine heterogene Menge vieler Informationsquellen dar. Diese
werden von Bibliotheken zum Teil lokal verwaltet und zum Teil stammen sie von externen Informationsanbietern
(z.B. anderen Bibliotheken oder Fachdatenbanken). Bei den elektronischen Informationen, die eine Bibliothek
ihren Nutzern zur Verfügung stellen möchte, handelt es sich zum einen um Verweise auf die bibliografischen
Daten des eigenen Bestandes, und zum anderen um digital verfügbare Dokumente (z.B. Artikel, Bücher, Bibliografien, Vorlesungsaufzeichnungen), die die Bibliothek online zur Nutzung anbietet. Diese Informationen sind
typischerweise in verschiedenen Katalog- bzw. Verwaltungssystemen abgelegt. Um eine effiziente und einfache
Recherche gewährleisten zu können, ist es notwendig, möglichst viele Quellsysteme in die Suche einzubeziehen. Im Auftrag der Thüringer Universitäts- und Landesbibliothek (ThULB) wird derzeit im Rahmen der hier
vorgestellten Diplomarbeit eine Anwendung entwickelt, die die föderierte Suche in ausgewählten Beständen der
Bibliothek zulässt. Es soll den verschiedenen Klassen von Bibliotheksnutzern (z.B. Studenten, wissenschaftlichen
Mitarbeitern, universitätsfremden Nutzern) zukünftig möglich sein, die in eine Suche einzubeziehenden Quellen
ihren Ansprüchen nach auszuwählen, interessante Einträge einer Ergebnismenge über die laufende Session hinaus
in einer persönlichen Literaturliste zu speichern oder zu exportieren und auf bereits benutzte Suchphrasen zurückzugreifen. Die Aufgaben der Authentifizierung und Personalisierung können mit Hilfe eines Portals besonders gut
umgesetzt werden. Um auf Änderungen der Quellsysteme flexibel reagieren zu können, ist es wichtig, das System
modular aufzubauen.
2
Existierende Produkte und Forschungsansätze
In den letzten Jahren ist im Bereich des Bibliothekswesens der Wunsch nach Integration ihrer verschiedenen
Informationsressourcen gestiegen. Dies betrifft sowohl die eigenen lokal vorhandenen Ressourcen als auch die
extern verwalteten Katalogsysteme anderer Informationsanbieter. So existieren seit einigen Jahren kommerzielle Systeme, die eine große Zahl von Katalogsystemen einbeziehen. Diese Syteme können unterschieden werden
in Portalsysteme, welche eine Bibliothek lokal auf ihren Servern installiert, und in Portalsysteme, zu denen der
Bibliothek die Nutzung gewährt wird und deren Administration vom Hersteller übernommen wird. Die ThULB
hat im Vorfeld des hier skizzierten Projekts zwei dieser Systeme getestet, “OCLC PICA iPort” [6] und OVID
“SearchSolver“[5]. Bei dem OCLC PICA iPort handelt es sich um ein lokal zu installierendes System, das Quellen über Z39.50 [3], SRU/ SRW und HTML/XML-Wrapper einbindet. Der OVID SearchSolver hingegen ist ein
System, das von der Firma OVID betreut wird. Es verfügt über ähnliche Konnektoren zu den Quellsystemen. Beide Systeme bieten jedoch nicht die Möglichkeit der Personalisierung der Suche an. Neben diesen kommerziellen
40
Systemen existieren sowohl Forschungansätze zu föderierter Suche, Sammlung und Aufbereitung der gefundenen
Informationen als auch freie Implementierungen von Konnektoren und Clients (z.B. Unicats [7], Old Dominion
University Digital Library Group [4] ). Für das Protokoll Z39.50 existieren mehrere Implementierungen von Clients, die zur Umsetzung eines Konnektors zu Z39.50-Quellsystemen genutzt werden können. Jzkit [2] ist eine
dieser Implementierungen. Zu den existierenden Implementierungen zählt auch ein Z39.50-Client zur föderierten
Suche in ausgwählten Z39.50 Katalogsystemen in Deutschland und weltweit [8].
3
Lösungsidee
Die existierenden Lösungen decken nur einen Teil der beschriebenen Anforderungen an ein zukünftig einzusetzendes System ab, deshalb wurde von Seiten der ThULB eine Eigenentwicklung initiiert. Die zu entwickelnde
Portal-Server
Portalanwendung
Login-Portlet
Portlet zur
Darbietung der
personalisierten
Funktionen
Fkt.
1
Fkt.
m
Portlet zur Darstellung der
Ergebnismenge
Suchanfrageportlet
Konnektor
zur
Zielsystem
-klasse 1
z.B.Z39.50
Quellsystemklasse 1
Datenbank
zur
Speicherung
persönl.
Daten
Quellsystem
a
z.B. OPAC
Quellsystem
b
Konnektor
zur
Zielsystem
-klasse 2
z.B. OAI
Quellsystemklasse 2
Quellsystem
c
z.B. MyCoreAnwendung
Quellsystem
d
Konnektor
zur
Zielsystem
-klasse n
z.B. HTML
Quellsystemklasse n
LDAP-Server
mit
Nutzerdaten
Quellsystem
k
Quellsystem
k+1
Abbildung 1. Architektur des zu entwickelnden Systems
Portalanwendung soll jederzeit um neue Konnektoren zu Informationsquellen erweiterbar sein, daher ist ein modularer Aufbau des Systems notwendig.
Abbildung 1 skizziert die Architektur des geplanten Systems: Die Portalanwendung ist aus vier Portlets aufgebaut: Dem Suchanfrageportlet, einem Portlet zur Darstellung der Ergebnismenge, einem Portlet, welches die
Funktionen der Personalisierung anbietet und dem dem Login-Portlet. Nachdem von der Bibliothek die Menge
der angebotenen Katalogsysteme nach Art der Schnittstellen klassifiziert wurde, werden für jede dieser Klassen
von Quellsystemen Konnektoren gesucht bzw., falls noch keine Konnektoren für spezielle Schnittstellen existieren,
erstellt. Im Suchportlet kann der Nutzer spezifizieren, wonach er sucht, dies kann durch Eingabe eines oder mehrerer Suchworte oder durch die Angabe bestimmter Eigenschaften, nach denen er sucht, wie z.B. ISBN, Titel, Autor
geschehen. Die Suche ist auch möglich, wenn der Nutzer sich nicht gegenüber dem Login-Portlet authentifiziert
hat, allerdings sollen bei einer anonymen Suche für die Bibliothek kostenpflichtige Quellsysteme nicht berücksich-
41
tigt werden. Hat der Bibliotheksnutzer seine Suchanfrage formuliert und dem Suchanfrageportlet übergeben, so
werden die Parameter der Suchanfragen an die angeschlossenen Konnektoren übergeben. Jeder Konnektor bildet
aus den Parametern eine für seine Zielsystemklasse angepasste Suchanfrage, verbindet sich mit den angeschlossenen Systemen dieser Klasse und sammelt die Ergebnisse. Ein Konnektor besteht aus einem Java-Treiber für
das Protokoll oder die Schnittstelle seiner Quellsystemklasse, einer Syntax zur Übersetzung der Parameter des
Suchanfragepotlets in eine Suchanweisung in der Sprache der Quellsysteme sowie einem Parser, der die Ergebnismenge von dem Schema der Quellsysteme in das globale Schema übersetzt. Das Darstellungs-Portlet zeigt die
empfangene Ergebnismenge seitenweise an und bietet die Möglichkeit, sie anhand der Attribute umzusortieren.
Der Nutzer kann aus dem Darstellungsportlet durch Anwählen von Checkboxen einzelne Titel in seine persönliche
Literaturliste übernehmen. Die Größe der Literaturliste ist abhängig von der Nutzerklasse, der er angehört. Alle
vom Benutzer gesammelten Daten werden in einer angebundenen Datenbank gespeichert.
Bei der Anmeldung eines Nutzers am Login-Portlet werden seine Angaben mit den Daten des LDAP-Servers der
ThULB, auf dem die Nutzerdaten gespeichert sind, abgeglichen. Sind die Angaben des Nutzers korrekt, so wird
eine eindeutige ID des Nutzers an das Personaliersierungsportlet gesendet. Erhält das Personalisierungsportlet eine
ID von dem Login-Portlet, so werden alle persönlichen Daten, die in der Personalisierungs-Datenbank abgelegt
sind, in das Portlet geladen und dem Nutzer zur Verfügung gestellt. Ähnlich wie das Suchportlet ist das Personalisierungsportlet auch um neue Funktionen erweiterbar. Das Personalisierungsportlet bietet z.B. einem Studenten
Kombinationen von speziellen Katalogsystemen, die an seiner Studienrichtung orientiert sind, für föderierte Suche an. Wählt ein Nutzer diese Option, werden die gewählten Parameter an das Suchportlet übermittelt und die
entsprechenden Konnektoren zu den ausgewählten Katalogsystemen geladen. Diese Art der Architektur soll eine
Weiterentwicklung während des Einsatzes des Systems und ein Hot-Plugin ermöglichen.
4
Realisierungsstand und -ausblick
Die Diplomarbeit begann am 01. November 2006 nach einer einmonatigen Einarbeitungsphase in der ThULB,
in deren Verlauf der IBM Websphere Portal Server V. 6.0 [1], auf dem die zu entwickelnde Portalanwendung
getestet werden soll, installiert wurde. Das hier vorgestellte Konzept resultiert aus einer Anforderungsanalyse,
die in den Monaten Oktober und November angestellt wurde. In den folgenden Monaten soll dieses Konzept auf
Realisierbarkeit überprüft und prototypisch umgesetzt werden. Der modulare Aufbau des Systems stellt sicher,
dass es auch über den Rahmen dieser Arbeit weiterentwickelt und erweitert werden kann. So werden in den
folgenden Monaten nicht alle Konnektoren und Funktionen der Personalisierung umgesetzt werden können. Ziel
ist es jedoch, Konnektoren und Funktionen zu erstellen, nach deren Beispiel möglichst einfach neue Zielsysteme
angeschlossen und Aufgabenfelder abgedeckt werden können.
Literatur
[1] IBM. Ibm websphere - software - deutschland, November 2006. http://www-306.ibm.com/software/de/websphere/.
[2] K. Integration. Knowledege integration website, November 2006. http://developer.k-int.com/projects.php?page=jzkit2.
[3] C. A. Lynch. The z39.50 information retrieval protocol: an overview and status report. SIGCOMM Comput. Commun.
Rev., 21(1):58–70, 1991.
[4] K. Maly, M. Zubair, V. Chilukamarri, and P. Kothari. Grid based federated digital library. In CF ’05: Proceedings of the
2nd conference on Computing frontiers, pages 97–105, New York, NY, USA, 2005. ACM Press.
[5] OVID.
Ovid searchsolver documentation, November 2006.
http://www.ovid.com/site/help /documentation/searchsolver.jsp.
[6] O. PICA. Oclc pica iport information site, November 2006. http://oclcpica.org/?id=1078.
[7] B. Schmitt. Benutzerprofile für die Anfrageverarbeitung in verteilten digitalen Bibliotheken. PhD thesis, Universität
Karlsruhe (TH), 2003.
[8] W. Schneider. Ein verteiltes bibliotheks-informationssystem auf basis des z39.50 protokolls. Master’s thesis, Technische
Universität Berlin Fachbereich Informatik, 1999.

Zugehörige Unterlagen

Wir haben drei Abbildungen für Wahrheitswerte wahr (w) und falsch

Firma: Anwendungsentwickler / Oracle Datenbank Administrator (w/m)

Datenbankprogrammierung (Oracle)

Werkstudent (m/w) für den Oracle Bereich gesucht! - IT

conference on Database Systems in Busines

Zugehörige Unterlagen

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können