- Fachgebiet Datenbanken und Informationssysteme

Universität Hannover
Institut für Informatik
Datenbanken und Informationssysteme
Prof. Dr. U. Lipeck
Diplomarbeit
Integration verteilter, heterogener
Informationsquellen zur Realisierung eines
föderierten Zeitschriften-Informationssystems
Verfasser
Betreuer
Prüfer
Zweitprüfer
: Christian Borgmann
: Prof. Dr. U. Lipeck
: Prof. Dr. U. Lipeck
:
Dr. Brüggemann
Datum : 11. Juli 2002
Aufgabenstellung
Institut für Informatik
Abteilung Datenbanken und Informationssysteme
Prof. Dr. U. Lipeck
Lange Laube 22
30159 Hannover
Tel.: +49 511 762 4950
Diplomarbeit
von
Herrn cand. mat. Christian Borgmann
Matrikel-Nr. : 1572883
Integration verteilter, heterogener Informationsquellen zur Realisierung
eines föderierten Zeitschriften-Informationssystems
Im Rahmen dieser Arbeit soll ein auf den Konzepten föderierter Datenbanken basierendes Informationssystem entwickelt werden, das Fachinformationen zu Zeitschriftenartikeln ausgewählter Publikationsorgane bereitstellt. Ziel ist es, eine Schnittstelle zu schaffen, die eine einheitliche und transparente Suche nach diesen Informationen in unterschiedlichen Quellen ermöglicht. Eine weitere Anforderung an
das System besteht darin, zu jeder Fachinformation eine Zugriffsmöglichkeit auf
den referenzierten Artikel, soweit bekannt, anzugeben. Das Informationssystem soll
verschiedene Datenquellen, wie beispielsweise relationale Datenbanken oder auch
Web-Sites, integrieren. Hierfür sind unterschiedliche Transformations- und Integrationsprozesse erforderlich. Diese sollen ausführlich erläutert und Lösungsansätze für
die in diesem Zusammenhang auftretenden Probleme präsentiert werden.
Bestätigung
Hiermit versichere ich, daß ich diese Arbeit selbständig verfaßt und keine anderen
als die angegebenen Quellen und Hilfsmittel benutzt habe.
Christian Borgmann (Hannover, d. 11. Juli 2002)
Zusammenfassung
Mit der zunehmenden Bedeutung der Informationstechnologie ist die Zahl der Publikationen in diesem Bereich stark gestiegen. Zu den bereits existierenden Arbeiten
kommen täglich neue Bücher, Fachzeitschriften, Tagungsberichte und andere Dokumente hinzu. Die Informationen zu all diesen Veröffentlichungen werden jedoch nicht
zentral verwaltet, sondern sind in vielen unterschiedlichen Quellen gespeichert. Dies
können Verlagsdatenbanken, Bibliothekskataloge, aber auch interne Datenbestände
institutioneller bzw. privater Einrichtungen sein. Die Suche nach Informationen zu
bestimmten Publikationen kann deshalb viel Arbeit und Zeit erfordern, da oft mehrere Informationsquellen genutzt werden müssen, um die gewünschten Daten zu erhalten. Die Distribution der Datenbestände beinhaltet aber noch weitere Probleme.
So liegen die Daten nicht nur verteilt, sondern auch in heterogener Form vor, d.h. ihre Darstellung variiert in Abhängigkeit der jeweiligen Informationsquelle. Zusätzlich
treten bei der Betrachtung verschiedener Datenbestände vielfach Redundanzen auf,
die zu einer Unübersichtlichkeit der gewonnenen Informationsmenge führen können.
Im Rahmen dieser Arbeit wird ein Ansatz zur Integration verteilter, heterogener
Informationsquellen unter dem Gesichtspunkt der Realisierung eines föderierten
Zeitschriften-Informationssystems vorgestellt. Die Integration erfolgt dabei in Anlehnung an die theoretischen Konzepte föderierter Datenbanksysteme und soll dem
Benutzer eine einheitliche Schnittstelle auf die gewünschten Daten zur Verfügung
stellen. Hierfür sind verschiedene Arbeitsschritte, basierend auf der 5-Ebenen-Schema-Architektur für föderierte Datenbanksysteme, erforderlich.
Da man in der Regel keine Zugriffsberechtigung für fremde Datenbanken besitzt,
müssen die benötigten Informationen zum Teil aus relevanten Web-Sites gewonnen werden. Diese Sites werden von den Verlagen bzw. verschiedenen BibliotheksServern zur Verfügung gestellt. Da diese Daten meistens nur in semi-strukturierter
Form vorliegen, müssen spezielle, möglichst adaptive Transformationsprozesse in
die bestehende Architektur integriert werden. Innerhalb des Zeitschriften-Informationssystems wurde für diese Aufgabe ein Web-Site Datenbanksystem entwickelt,
das auf den Konzepten hierarchischer Datenbanken basiert. Für die Extraktion von
Informationen aus den jeweiligen Web-Sites wird ein zu diesem Zweck entworfenes Data Retrieval System genutzt, das mit Hilfe einfach zu generierender Regeln
Web-Dokumente nach relevanten Informationen durchsucht.
Um die unterschiedlichen Datenquellen in eine einheitliche Darstellung zu transformieren, kommen sogenannte Wrapper zum Einsatz, während die eigentliche Integration durch ein als Mediator bezeichnetes Software-Modul realisiert wird. Insgesamt
ensteht somit ein Integrationsmodell, das sowohl traditionelle Datenbanksysteme,
als auch Inhalte semi-strukturierter Web-Sites zusammenfaßt.
Die praktische Umsetzung der vorgestellten theoretischen Aspekte erfolgt in der
Implementierung einer virtuellen Zeitschriftendatenbank (d.h., die Datenbank liegt
nicht permanent vor, sondern wird temporär generiert). Dabei wird die Menge der
verschiedenen Publikationen auf ausgewählte Fachzeitschriften eingeschränkt. Die
Implementierung erfolgt in der Programmiersprache JAVA, wobei der Zugriff auf
die Datenbanken mit Hilfe der JDBC-API realisiert wird.
Inhaltsverzeichnis
1 Einleitung
7
2 Grundlagen
10
2.1 Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.1
Datenmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.2
Datenunabhängigkeit und 3-Ebenen-Architektur . . . . . . .
12
2.1.3
Datenbank-Managementsysteme . . . . . . . . . . . . . . . .
13
2.1.4
Implementierung von Datenbanksystemen . . . . . . . . . . .
14
2.2 Das hierarchische Datenmodell . . . . . . . . . . . . . . . . . . . . .
15
2.2.1
Strukturierungskonzepte und Datenbank-Schema . . . . . . .
16
2.2.2
Schema-Diagramm und Datenbank-Zustand . . . . . . . . . .
17
2.2.3
Hierarchische Sequenz . . . . . . . . . . . . . . . . . . . . . .
18
2.3 Wrapper und Mediatoren . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.1
Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.2
Mediatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.4 Standard Generalized Markup Language . . . . . . . . . . . . . . . .
21
2.4.1
Markup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.4.2
Aufbau von SGML-Dokumenten . . . . . . . . . . . . . . . .
23
2.4.2.1
SGML-Deklaration . . . . . . . . . . . . . . . . . . .
24
2.4.2.2
Dokument Type Definition (DTD) . . . . . . . . . .
24
2.4.2.3
Dokumentinstanz . . . . . . . . . . . . . . . . . . .
25
3 Föderierte Datenbanksysteme
26
3.1 Klassifizierung von Datenbanksystemen . . . . . . . . . . . . . . . .
26
3.1.1
Unitäre Datenbanksysteme . . . . . . . . . . . . . . . . . . .
27
3.1.2
Multidatenbanksysteme . . . . . . . . . . . . . . . . . . . . .
28
3.2 Die 5-Ebenen-Schema-Architektur . . . . . . . . . . . . . . . . . . .
30
4
INHALTSVERZEICHNIS
4 Web-Sites als Datenbanken
4.1 Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1
5
32
33
Informationsstrukturanalyse . . . . . . . . . . . . . . . . . . .
33
4.1.1.1
Allgemeine Struktur von Web-Sites . . . . . . . . .
33
4.1.1.2
Spezifische Strukturen von Web-Sites . . . . . . . .
35
4.1.2
Web-Site Schema . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.1.3
Entwicklung des konzeptionellen Schemas . . . . . . . . . . .
39
4.1.4
Aufgaben des Web-Site Managementsystems . . . . . . . . .
40
4.2 Data Retrieval System . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2.1
Filtersystem . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.2.1.1
Reduktion des Dokuments . . . . . . . . . . . . . .
42
4.2.1.2
Gruppierung der Elemente . . . . . . . . . . . . . .
43
Extraktionssystem . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2.2.1
Extraktion relevanter Informationen . . . . . . . . .
48
4.2.2.2
Generierung einer XML-Datei . . . . . . . . . . . .
49
4.3 Implementierung des Web-Site DBS . . . . . . . . . . . . . . . . . .
52
4.2.2
4.3.1
Beispieldatenbank . . . . . . . . . . . . . . . . . . . . . . . .
52
4.3.2
Die 3-Schichten-Architektur des Web-Site DBS . . . . . . . .
53
4.3.3
Die Anfragesprache WS/QL . . . . . . . . . . . . . . . . . . .
54
4.3.3.1
Arbeitsumgebung . . . . . . . . . . . . . . . . . . .
54
4.3.3.2
Die GET Operationen . . . . . . . . . . . . . . . . .
55
4.3.3.3
Das Kommando GET PATH . . . . . . . . . . . . . .
56
4.3.3.4
Das Kommando GET NEXT WITHIN PARENT . . . .
57
4.3.4
XML-orientierte Schnittstelle . . . . . . . . . . . . . . . . . .
57
4.3.5
Pufferschnittstelle . . . . . . . . . . . . . . . . . . . . . . . .
58
4.3.6
Interne Satzschnittstelle . . . . . . . . . . . . . . . . . . . . .
59
4.3.7
Satzorientierte Schnittstelle . . . . . . . . . . . . . . . . . . .
60
5 Entwicklung des ZIS
5.1 Beschreibung der Komponentensysteme . . . . . . . . . . . . . . . .
62
63
5.1.1
ACM Digital Library . . . . . . . . . . . . . . . . . . . . . . .
63
5.1.2
DBLP Bibliographie-Server . . . . . . . . . . . . . . . . . . .
64
5.1.3
DBIS Literaturdatenbank . . . . . . . . . . . . . . . . . . . .
65
5.2 Entwicklung des Architekturmodells . . . . . . . . . . . . . . . . . .
68
5.2.1
Allgemeines Modell föderierter DBSe . . . . . . . . . . . . . .
68
5.2.2
Architekturmodell des ZIS . . . . . . . . . . . . . . . . . . . .
69
6
INHALTSVERZEICHNIS
5.3 Datenbank-Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1
Integrationsansatz . . . . . . . . . . . . . . . . . . . . . . . .
70
71
5.3.1.1
Identifikation durch den Dokumenttitel . . . . . . .
72
5.3.1.2
Identifikation durch den Publikationskontext . . . .
72
5.3.1.3
Identifikation durch das Tupel (Titel, Autoren) . . .
72
5.3.1.4
Identifikation durch den Benutzer . . . . . . . . . .
73
5.3.1.5
Identifikation von Artikeln innerhalb des ZIS . . . .
73
5.3.1.6
Integrationsansatz des ZIS . . . . . . . . . . . . . .
74
Entwicklung der Komponenten-/Exportschemata . . . . . . .
74
5.3.2.1
ACM Digital Library . . . . . . . . . . . . . . . . .
75
5.3.2.2
DBIS Literaturdatenbank . . . . . . . . . . . . . . .
76
5.3.2.3
DBLP Bibliographie-Server . . . . . . . . . . . . . .
78
Entwicklung des föderierten Schemas . . . . . . . . . . . . .
79
5.4 Anfragebearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.3.2
5.3.3
5.4.1
Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . .
81
5.4.2
Dynamische Modellerweiterung . . . . . . . . . . . . . . . . .
82
5.4.3
Aufbau und Funktionsweise der ZIS-Wrapper . . . . . . . . .
83
5.4.3.1
Wrapper für relationale Komponenten . . . . . . . .
84
5.4.3.2
Wrapper für Web-Site Datenbanksysteme . . . . . .
84
Aufbau und Funktionsweise des ZIS-Mediators . . . . . . . .
88
5.4.4.1
Anfrageübersetzer . . . . . . . . . . . . . . . . . . .
88
5.4.4.2
Ergebniskonverter . . . . . . . . . . . . . . . . . . .
90
5.4.4
5.4.5
Arbeitsdatenbank
. . . . . . . . . . . . . . . . . . . . . . . .
90
5.5 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
6 Zusammenfassung und Ausblick
93
Web-Site Schemata digitaler Bibliotheken
95
Abbildungsverzeichnis
100
Literaturverzeichnis
101
Kapitel 1
Einleitung
In der heutigen Zeit werden immer mehr Informationen jeglicher Art in elektronischer Form gespeichert und zur Verfügung gestellt. Dieser Trend basiert einerseits
auf der kontinuierlichen Weiterentwicklung physikalischer Speichermedien, die trotz
steigender Kapazität und verbesserter Performance zu ständig niedrigeren Preisen
erhältlich sind. Andererseits stellt die Informatik immer ausgefeiltere Konzepte zur
logischen Strukturierung von Informationen zur Verfügung. In erster Linie ist hierbei die Entwicklung von Datenbanksystemen mit den vielfältigen Möglichkeiten
zur Datenmanipulation bzw. -definition zu erwähnen. Neue Technologien, wie beispielsweise Multimedia-Datenbanken oder auch geographische Informationssysteme
(GIS), ergänzen dabei den Bereich der traditionellen Datenbanksysteme, die in den
meisten Fällen eine relationale oder hierarchische Struktur aufweisen und auch heute noch den überwiegenden Anteil der im Einsatz befindlichen Systeme darstellen.
Neben der ständig wachsenden Informationsmenge hat sich auch die Verfügbarkeit der Daten verändert. War vor einigen Jahren ausschließlich der lokale Zugriff
auf die Informationsbestände möglich, können heutzutage die an einem beliebigen
Ort gespeicherten Daten weltweit genutzt werden. Verantwortlich hierfür sind die
Entwicklungen in den Bereichen Telekommunikation und Netzwerk-Technologie. In
diesem Zusammenhang ist an erster Stelle die wachsende Popularität des Internet
und insbesondere des World Wide Web zu nennen. Diese Technologien ermöglichen den weltweiten Austausch von Informationen auf eine relativ einfache Art und
Weise.
Einhergehend mit dem stetigen Wachstum und der globalen Verfügbarkeit von Informationen ist allerdings auch der Aufwand der Informationsbeschaffung erheblich
größer geworden (Information Overflow ). Dies läßt sich sowohl durch die Distribution als auch durch die Heterogenität der zur Verfügung stehenden Informationen begründen. Der Begriff der Distribution verweist dabei auf die Tatsache, daß
die benötigten Informationen nicht zentral gespeichert, sondern in unterschiedlichen
Datenquellen vorliegen. Bei der Informationsbeschaffung müssen diese Datenquellen
also zuerst einmal lokalisiert und daraufhin separat in den Beschaffungsvorgang mit
einbezogen werden. Die Heterogenität bezieht sich einerseits auf die unterschiedliche Gestalt der Datenquellen, bei denen es sich um verschiedene Datenbanksysteme,
Web-Sites, ftp-Server oder ähnliches handeln kann. Andererseits können auch die
Informationen selbst in heterogener Form vorliegen. So kann die Darstellung von
Daten beispielsweise zwischen verschiedenen Kulturräumen variieren. Dabei können
sowohl linguistische Unterschiede als auch Differenzen bei der Formatierung von
Datums- und Zeitangaben bis hin zu den verschiedenen Währungseinheiten auftreten.
7
8
KAPITEL 1. EINLEITUNG
Daneben existieren noch weitere Schwierigkeiten bei der Informationsbeschaffung.
Zum einen kann es bei der Einbeziehung verschiedener Datenquellen, die ähnliche
Informationen anbieten, zu redundanten Ergebnissen kommen, die bei der Auswertung entsprechend zu berücksichtigen sind. Zum anderen wird die Bewertung
der Qualität einer Datenquelle hinsichtlich der benötigten Informationen in dem
immer undurchdringlicher werdenden Geflecht von Informationsquellen zunehmend
schwieriger.
Logische Informationsstrukturierung
Globale Vernetzung
Internet, WAN, etc.
Datenbanksysteme, Informationssysteme, XML, etc.
Physikalische Informationsspeicherung
Lokale Vernetzung
LAN, Intranet, etc.
Massenspeicher (Magnetplatten, CD−ROM, etc.)
Stetig wachsende
Informationsmenge
Bessere Verfügbarkeit
der Informationen
Wachsender Aufwand
der Informationsgewinnung
Distribution der Informationen
WWW, Datebanksysteme, etc.
Heterogenität
Sprache, Formatierung, etc.
Redundanzen
Qualität
Informationsgehalt der Daten
Aktualität
Suchmaschinen
Internetportale
Föderierte DBSe
Data Warehouses
Abbildung 1.1: Allgemeine Problematik der Informationsbeschaffung
Zur Lösung der dargestellten Probleme bei der Informationsbeschaffung sind in den
letzten Jahren viele Verfahren und Konzepte entwickelt worden. Im Bereich des
World Wide Web sind in diesem Zusammenhang beispielsweise lokale Suchdienste,
Meta-Suchmaschinen oder Internetportale zu erwähnen, die die Informationsbeschaffung bzw. Navigation innerhalb des Web erleichtern sollen. Daneben existieren
verschiedene Ansätze zur Integration verteilter, heterogener Datenbestände, mit
dem Ziel, eine transparente Sicht auf die zusammengefaßten Informationsquellen zu
schaffen. Beispielhaft sind in diesem Zusammenhang Data Warehouses und insbesondere föderierte Datenbanksysteme zu nennen. In Abb. 1.1 sind die dargestellten
Probleme und Lösungsansätze zusammengefaßt.
Im Rahmen dieser Arbeit soll nun basierend auf den Konzepten föderierter Datenbanksysteme gezeigt werden, wie die Integration unterschiedlicher Datenquellen
realisiert werden kann. Zu diesem Zweck erfolgt die Entwicklung eines ZeitschriftenInformationssystems, das dem Benutzer Informationen zu Fachzeitschriften aus dem
KAPITEL 1. EINLEITUNG
9
Bereich der Informatik zur Verfügung stellt. Das System umfaßt dabei verschiedene Datenquellen, wie z.B. traditionelle Datenbanksysteme oder auch Web-Sites.
In diesem Zusammenhang werden die bei der Integration auftretenden Probleme
ausführlich erläutert und geeignete Lösungsansätze vorgestellt.
Im Anschluß an die Einleitung erfolgt im zweiten Kapitel zunächst eine kurze
Einführung in die Themengebiete Datenbanksysteme, SGML sowie Wrapper und
Mediatoren. Dadurch soll das Verständnis der im weiteren Verlauf der Arbeit vorgestellten Konzepte insofern erleichtert werden, als daß sich auch der mit den jeweiligen Thematiken nur wenig vertraute Leser mit der Materie auseinandersetzen kann.
Das dritte Kapitel befaßt sich mit den theoretischen Konzepten föderierter Datenbanksysteme. Neben einer allgemeinen Klassifizierung existierender Datenbanksysteme werden die in diesem Zusammenhang grundlegenden Begriffe erläutert und
ein Architekturmodell für die Föderation vorgestellt. Auf die Aspekte des föderierten Datenbankentwurfs wird hierbei nicht näher eingegangen. Diese werden, soweit
benötigt, ausführlich bei der Entwicklung des Zeitschriften-Informationssystems
erläutert. Anschließend wird im vierten Kapitel eine Möglichkeit vorgestellt, WebSites in ein föderiertes Datenbanksystem zu integrieren. Dabei richtet sich das
Hauptaugenmerk zum einen auf die Gewinnung relevanter Daten aus einzelnen
Web-Pages und zum anderen auf die Verwaltung der dabei extrahierten Daten,
d.h. insbesondere die Möglichkeiten der Anfragebearbeitung. Die Entwicklung des
Zeitschriften-Informationssystems wird dann im fünften Kapitel ausführlich beschrieben. Dabei werden zunächst die beteiligten Datenquellen vorgestellt und ein
geeignetes Architekturmodell entworfen. Basierend auf diesem Modell erfolgt der
Datenbankentwurf, wobei Lösungsansätze für in diesem Zusammenhang auftretende
Probleme und ein als Integrationsansatz bezeichnetes Konzept vorgestellt werden.
Schließlich wird die Anfragebearbeitung innerhalb des Systems beschrieben. Das
letzte Kapitel faßt die in der Arbeit vorgestellten Konzepte kurz zusammen und
stellt mögliche Weiterentwicklungen des Systems vor.
Kapitel 2
Grundlagen
Bei der Beschreibung der im Rahmen dieser Arbeit entwickelten Systeme wird
auf verschiedene Themengebiete der Informatik Bezug genommen. In diesem Kapitel werden daher grundlegende Konzepte und Begriffe aus den einzelnen Themengebieten kurz vorgestellt. Abschnitt 2.1 befaßt sich mit der Thematik allgemeiner Datenbanksysteme, wobei insbesondere auf die Begriffe Datenmodell und
Datenschema eingegangen wird. Im Anschluß daran erfolgt die Beschreibung des
hierarchischen Datenmodells, dessen Konzepte die Grundlage bei der Entwicklung
des Web-Site Datenbanksystems darstellen. Eine Einführung in die theoretischen
Aspekte von Wrappern und Mediatoren, die die funktionalen Komponenten des
Zeitschriften-Informationssystems realisieren, wird in Abschnitt 2.3 gegeben. Abschließend wird unter Punkt 2.4. auf die Konzepte der Dokumentbeschreibungssprache SGML eingegangen. SGML kann als Obermenge der im Bereich des World Wide
Web hauptsächlich verwendeten Sprachen XML und HTML betrachtet werden. Die
Konzepte von Dokumentbeschreibungssprachen und insbesondere von XML bzw.
HTML werden bei der Extraktion von Informationen aus Web-basierten Dokumenten benötigt.
2.1
Datenbanksysteme
Eine Datenbank (database) stellt einen, abhängig von einem gegebenen Datenmodell
(data model ), einheitlich strukturierten Datenbestand dar. Zusammen mit einem
Datenbank-Managementsystem (database management system, DBMS) wird ein sogenanntes Datenbanksystem (database system, DBS) gebildet. Ausgehend von dieser
Definition werden im Anschluß die Termini Datenmodell und DBMS näher erläutert
sowie die 3-Ebenen-Architektur für DBSe vorgestellt. Die Erläuterungen basieren
dabei im wesentlichen auf den Darstellungen in [EN00, Dat00, Lip95, Vos00].
2.1.1
Datenmodelle
Ein Datenmodell besteht im allgemeinen aus einer Menge von Konzepten, mit denen sich die Struktur einer Datenbank beschreiben läßt. Mit Hilfe dieser Konzepte
läßt sich der für eine konkrete Anwendung benötigte Ausschnitt der realen Welt
(Mini-Welt) abstrakt modellieren. Gleichzeitig bleiben dem Benutzer die Details
der physischen Datenspeicherung verborgen (information hiding). Somit wird eine
systemunabhängige, intuitive Beschreibung der Datenbank ermöglicht.
10
KAPITEL 2. GRUNDLAGEN
11
Die Struktur einer Datenbank ist durch entsprechende Datentypen, den Beziehungen der Daten zueinander sowie spezielle Integritätsbedingungen festgelegt. Viele
Datenmodelle beinhalten außerdem eine Menge von Operationen zur Beschreibung
von Anfragen und Manipulationen der Datenbank. Beispielhaft seien hier Algebra
und Kalkül relationaler Datenbanken erwähnt.
Anhand des jeweiligen Abstraktionsgrads, d.h. in welchem Maße von der physischen
Speicherung der Daten abstrahiert wird, lassen sich Datenmodelle klassifizieren. Dabei erfolgt eine Einteilung in konzeptionelle (conceptual ), logische (representational )
und physische (physical ) Datenmodelle (vgl. Abbildung 2.1).
High Level
Conceptual Data Models
ER−Modell, EER−Modell, ...
Abstraktionsniveau
Representational Data Models
Relationen−Modell, Netzwerk−Modell, hierarchisches Modell, ...
Physical Data Models
Low Level
Abbildung 2.1: Klassifizierung von Datenmodellen
Den höchsten Abstraktionsgrad besitzen die konzeptionellen Datenmodelle. Diese
beschreiben die Struktur der Datenbank völlig unabhängig von der physischen Datenspeicherung. Verbreitete Modellierungskonzepte sind Entitäten (entities), Beziehungen (relationships) und Attribute (attributes). Entitäten repräsentieren Objekte
der realen Welt, die durch eine Menge von Attributen charakterisiert sind und in
Beziehung zu anderen Objekten stehen. Bekannteste Vertreter dieser Klasse sind das
ER- bzw. EER-Modell, die auch als semantische Datenmodelle bezeichnet werden.
Logische Datenmodelle ermöglichen einerseits eine abstrakte Beschreibung der Datenbankstruktur, andererseits basieren sie auf den logischen Datenstrukturen spezifischer Datenbanken. Dadurch wird eine direkte Implementierung gewährleistet.
Im Gegensatz zu den konzeptionellen Datenmodellen lassen sich komplexe Anwendungsstrukturen allerdings nur schwer modellieren. Die klassischen Datenmodelle,
also Relationen-Modell, Netzwerkmodell und hierarchisches Modell, sind die bekanntesten Vertreter der logischen Ebene.
Physische Datenmodelle beschreiben die interne Struktur einer Datenbank. Modellierungskonzepte wie Indexe, Suchbäume, Zugriffspfade etc. setzen direkt auf den
physischen Strukturen der Datenbank auf. Somit entsteht eine systemnahe Abstraktion der Datenbank.
Innerhalb des Datenmodells wird zwischen dem Datenbank-Schema (database schema) und dem Datenbank-Zustand (database state) unterschieden. Das Schema bildet das Informationsgerüst der Datenbank (Datenbeschreibung), während der Zustand den aktuellen Inhalt der Datenbank repräsentiert. In diesem Zusammenhang
12
KAPITEL 2. GRUNDLAGEN
wird auch von der Trennung zwischen Daten und Meta-Daten gesprochen. Viele
Datenmodelle beinhalten weiterhin bestimmte Konventionen zur graphischen Darstellung des Datenbank-Schemas (Schema-Diagramm). Die Objekte innerhalb eines
Schema-Diagramms werden als Schema-Konstrukte bezeichnet.
2.1.2
Datenunabhängigkeit und 3-Ebenen-Architektur
Eine wesentliche Charakteristik von DBSen ist die Forderung nach Datenunabhängigkeit (data independence). Dabei wird zwischen logischer und physischer Datenunabhängigkeit unterschieden:
Physische Datenunabhängigkeit
Dem Benutzer und den jeweiligen Anwendungsprogrammen soll eine transparente
Sicht auf die Datenbank zur Verfügung gestellt werden. Dadurch wird eine Stabilität der Benutzerschnittstelle gegen Änderungen der physischen Datenorganisation gewährleistet. So sollte es möglich sein, die interne Speicherung der Daten zu
verändern, ohne daß dies Konsequenzen für den Einsatz der mit dem DBS agierenden Anwendungsprogramme hat. Dies impliziert gleichzeitig, daß die Entwicklung
neuer Anwendungen unabhängig von konkreten Datenstrukturen, Zugriffspfaden
etc. realisiert werden kann.
Logische Datenunabhängigkeit
Ziel der logischen Datenunabhängigkeit ist es, den Benutzer und die Anwendungsprogramme von Erweiterungen bzw. Änderungen des Datenbank-Schemas abzuschirmen. So sollte die Integration neuer Objekttypen bzw. die Expansion bestehender Objekte durch Hinzufügen neuer Attribute ebenso keinen Einfluß auf existierende Anwendungsprogramme haben, wie auch die Umbenennung von Objekten
oder Attributen. In der Praxis ist eine vollständige logische Datenunabhängigkeit
im Bereich der Schema-Änderungen allerdings nur schwer zu realisieren.
External Schema 1
....
External Schema n
External Level
external/conceptual
mapping
Conceptual Schema
Conceptual Level
conceptual/internal
mapping
Internal Schema
Internal Level
internal/Storage
mapping
Stored Database
DBMS
Abbildung 2.2: 3-Ebenen-Architektur nach ANSI/SPARC
Ausgehend von der Forderung nach physischer und logischer Datenunabhängigkeit wurde die von ANSI/X3/SPARC standardisierte 3-Ebenen-Architektur für
DBSe entwickelt. Diese Architektur beinhaltet sowohl eine mehrstufige DatenbankDefinition, als auch eine hierarchische Strukturierung von DBMSen (vgl. Abbildung
2.2). Ausgehend von dem klassischen Datenbankentwurf werden die einzelnen Ebenen des Architekturmodells im folgenden näher beschrieben.
KAPITEL 2. GRUNDLAGEN
13
Durch die sogenannte Informationsbedarfsanalyse wird festgelegt, welche Anforderungen das DBS erfüllen soll und welche Daten dafür benötigt werden. Basierend auf
einem konzeptionellen und/oder repräsentativen Datenmodell wird daraufhin das
konzeptionelle Schema der Datenbank entwickelt. Dieses Schema bildet die konzeptionelle Ebene (conceptual level ) der ANSI/SPARC-Architektur. Somit beschreibt
das konzeptionelle Schema den gesamten Informationsgehalt der Datenbank und
die Details der physischen Speicherung der Daten bleiben aufgrund des verwendeten Datenmodells unberücksichtigt.
Im Anschluß an den konzeptionellen Entwurf erfolgt mit Hilfe eines physischen Datenmodells die Definition des internen Schemas. Dieses stellt die unterste Ebene der
ANSI/SPARC-Architektur dar, die als interne oder auch physische Ebene (internal/physical level ) bezeichnet wird. Das Schema beinhaltet die detaillierte Beschreibung der physischen Speicherstrukturen der Datenbank und bildet die Grundlage
bei der Implementierung des Datenbanksystems.
Ausgehend von dem konzeptionellen Schema werden den Benutzern bzw. den Anwendungsprogrammen unterschiedliche Sichten auf die Datenbank zur Verfügung
gestellt und somit die Gesamtstruktur der Datenbank verborgen. Hierfür werden
individuelle Schemata angelegt, die einen Teilausschnitt des konzeptionellen Schemas repräsentieren und/oder eine Umstrukturierung der Informationsdarstellung
beschreiben. Diese, als extern bezeichneten Schemata, bilden die externe Ebene
(external level ) der 3-Ebenen-Architektur. Obwohl das hierbei zugrunde liegende
Datenmodell unabhängig von dem des konzeptionellen Schemas gewählt werden
kann, wird hiervon bei existierenden DBSen selten Gebrauch gemacht.
2.1.3
Datenbank-Managementsysteme
Für die Verwaltung von Datenbanken ist das DBMS zuständig. Zu diesem Zweck
stellt das DBMS ein Softwaresystem zur Verfügung, das die Implementierung und
Verwaltung von Datenbanken gemäß einem gegebenen Datenmodell ermöglicht. Das
DBMS bildet außerdem die Schnittstelle zwischen Benutzer und Datenbank. Im
Verlauf der Entwicklung von DBSen hat sich ein spezielles Anforderungsprofil für
DBMS ergeben. Die grundlegeden Aufgaben existierender DBMS werden in [Cod82]
wie folgt beschrieben.
Integration
Das DBMS soll die einheitliche Verwaltung der Datenbank gewährleisten. Dies erfordert eine kontrollierte, nicht-redundante Datenhaltung des gesamten Datenbestands.
Operationen
Die Datenbankbenutzer müssen die Möglichkeit haben, den Datenbestand zu manipulieren, womit das Speichern, Suchen und Ändern von Daten gemeint ist. Zu
diesem Zweck muß das DBMS eine Menge von Operationen zur Verfügung stellen,
mit denen die Datenmanipulationen ausgeführt werden können.
Katalog
Das DBMS soll alle Informationen über die verwendeten Datenbank-Schemata bereitstellen. Dies geschieht mit Hilfe des Katalogs (data dictionary), in dem darüberhinaus noch weitere Verwaltungsinformationen, wie beispielsweise Zugriffsrechte,
Gruppenzugehörigkeiten oder ähnliches abgelegt werden.
Benutzersichten
Wie bereits bei der Beschreibung der 3-Ebenen-Architektur erwähnt, werden Benutzern unterschiedliche Sichten auf die Datenbank zur Verfügung gestellt. Das DBMS
ist für die korrekte Abbildung dieser externen Schemata auf das konzeptionelle Schema, d.h den Gesamtdatenbestand, verantwortlich.
KAPITEL 2. GRUNDLAGEN
14
Konsistenzüberwachung
Das DBMS ist dafür zuständig, daß Änderungen des Datenbestands die Integrität
der Datenbank nicht verletzen.
Datenschutz
Unautorisierte Zugriffe auf die Datenbank müssen vom DBMS ausgeschlossen werden. Dies umfaßt sowohl datenschutzrechtliche Aspekte personenbezogener Informationen (Datenschutzgesetz), als auch den Schutz unternehmensrelevanter Datenbestände (Werksspionage).
Transaktionen
Folgen von (zusammengehörigen) Datenbankänderungen werden zu logischen Funktionseinheiten (Transaktionen) zusammengefaßt. Das DBMS ist dafür verantwortlich, daß diese Transaktionen als Ganzes ausgeführt werden. Wurde eine Transaktion
erfolgreich abgeschlossen, so sind die Effekte der Datenmanipulationen permanent
in der Datenbank zu speichern. Tritt bei der Bearbeitung einer Transaktionen allerdings ein Fehler auf, müssen alle innerhalb der Transaktion zwischenzeitlich erfolgten Änderungen rückggängig gemacht werden. Dadurch wird die Integrität des
Datenbestands, ähnlich wie bei der Konsistenzüberwachung, gewährleistet.
Synchronisation
Konkurrierende Transaktionen verschiedener Benutzer müssen vom DBMS in geeigneter Weise synchronisiert werden, um Schreibkonflikte auf gemeinsam benutzten
Daten auszuschließen.
Datensicherung
Aufgabe der Datensicherung ist es, eine konsistente Rekonstruktion der Datenbank
nach Auftreten von Systemfehlern (z.B. Stromausfall) zu ermöglichen.
2.1.4
Implementierung von Datenbanksystemen
Heutzutage basiert die Implementierung der meisten DBSe auf einer Fünf-Schichten-Architektur [HR99], die in Abbildung 2.3 dargestellt ist. Jede Schicht stellt eine
Abstraktion der direkt unter ihr liegenden dar. Somit können die Details der physischen Datenspeicherung sukzessive verborgen werden, um schließlich eine intuitive
Sicht auf die zur Verfügung stehenden Daten zu ermöglichen. Jede Schicht stellt
eine Schnittstelle zur Verfügung, durch die die direkt darüberliegende Schicht auf
die zur Verfügung stehenden Prozeduren zugreifen kann.
Jedes externe Speichermedium besitzt eine Geräteschnittstelle zur Kommunikation mit der Außenwelt. Das Betriebssystem abstrahiert von den geräteabhängigen
Charakteristiken (Zylinder, Spuren, Sektoren, etc.) und stellt der übergeordneten
Schicht den Zugriff auf logische Speicherstrukturen (Dateien) zur Verfügung. Eine
Datei besteht ihrerseits aus einer Menge von adressierbaren Blöcken fester Länge,
die jeweils direkt, d.h als atomare Einheiten auf das externe Speichermedium abgebildet werden.
Um eine effiziente sowie flexible Speicherverwaltung zu ermöglichen, werden die
Objekte einer Datenbank (z.B. Relationen) nicht separat, sondern dateiübergreifend in sogenannten Segmenten gespeichert. Segmente bestehen aus einer Menge
von Seiten, die äquivalent zu den bereits erwähnten Blöcken einer Datei sind. Die
Zuordnung der Seiten zu den jeweiligen Blöcken ist Aufgabe der Pufferverwaltung,
die gleichzeitig für die Seitenersetzungsstrategie, d.h. das Ein- und Auslagern von
Seiten in den internen DB-Puffer, verantwortlich ist. An der Pufferschnittstelle stellt
sich die Datenbank demzufolge als Menge von direkt zugreifbaren Segmenten dar.
Das Speichersystem ist für die Abbildung interner Datensätze auf Seiten und Segmente verantwortlich. Dabei können unterschiedliche Techniken der Speicherstruk-
15
KAPITEL 2. GRUNDLAGEN
Benutzer
Anwendungsprogramme
Mengenorientierte DB−Schnittstelle
Datensystem
Logische
Datenstrukturen
Satzorientierte DB−Schnittstelle
Zugriffssystem
Logische
Zugriffspfad−
strukturen
Speichersystem
Speicherungs−
strukturen
Interne Satzschnittstelle
DB−Pufferschnittstelle
Pufferverwaltung
Seitenzuordnungs−
strukturen
Dateischnittstelle
Betriebssystem
Speicherzuordnungs−
strukturen
Geräteschnittstelle
Externe
Speichermedien
Abbildung 2.3: Fünf-Schichten-Modell
turierung zum Einsatz kommen. Die Speicherung erfolgt beispielsweise durch Indizierung und Implementierung von B*-Bäumen oder mit Hilfe von Hash-Funktionen.
Ziel dabei ist das schnelle Auffinden und Einfügen von Datensätzen, um eine möglichst hohe System-Performance zu garantieren.
Basierend auf den Strukturen des Speichersystems stellt das Zugriffssystem unterschiedliche Zugriffspfade zur Verfügung, die an der übergeordneten Schnittstelle
operativ genutzt werden können. Es wird im wesentlichen zwischen sequentiellen,
direkten und navigierenden Zugriffspfaden unterschieden. Die satzorientierte DBSchnittstelle abstrahiert somit von den Details der internen Speicherstrukturen und
realisiert einen prozeduralen Zugriff auf die Daten.
Das Datensystem schließlich verbirgt die satzorientierte Struktur der Daten, um
dem Benutzer eine intuitive Sicht auf den Datenbestand zu vermitteln. So kann mit
Hilfe von deklarativen Datenmanipulationssprachen, wie z.B. SQL, die Kommunikation zwischen Benutzer und DBS erfolgen. Darüberhinaus erfüllt das Datensystem
verschiedene Aufgaben bei der Bearbeitung von Anfragen und Änderungen der Datenbank. Dies sind u.a. Syntaxanalyse, Anfrageübersetzung und -optimierung, Synchronisation und Datensicherung.
Auf spezielle Aspekte der jeweiligen Schichten wird bei der Entwicklung eines DBMS
für HTML-basierte Web-Sites näher eingegangen. Einen vertiefenden Einblick in
die Konzepte und die Möglichkeiten der Realisierung einer 5-Schichten-Architektur
bieten [HR99] und [SH99].
2.2
Das hierarchische Datenmodell
Die Integration von Web-Sites in das ZIS erfolgt über ein hierarchisches Datenbanksystem. Daher soll im folgenden ein kurzer Überblick über die Konzepte des hierarchischen Datenmodells gegeben werden. Zu der Klasse der logischen Datenmodelle
gehörend, stellt das hierarchische Modell vereinfacht ausgedrückt ein reduziertes
Netzwerkmodell dar. Im Gegensatz zu dem relationalen oder auch dem ER-Modell
KAPITEL 2. GRUNDLAGEN
16
ist das hierarchische Datenmodell aus der Praxis heraus entstanden, so daß keine Referenzliteraur zu dieser Thematik existiert. Daher erfolgt die Darstellung der
grundlegenden Aspekte des hierarchischen Modells in Anlehnung an das von IBM
1968 entwickelte IMS-System [EN94, Ull82].
2.2.1
Strukturierungskonzepte und Datenbank-Schema
Das hierarchische Datenmodell bedient sich im wesentlichen zweier Konzepte zur
Strukturierung des Datenbestands: Record- und Parent-Child-Relationship-Typen.
Ein Record-Typ besitzt eine eindeutige Bezeichnung und definiert verschiedene Eigenschaften eines Objekts des zu abstrahierenden Weltausschnitts. So stellt zum
Beispiel PERSON (NAME:string, ALTER:integer, GESCHLECHT:char ) einen Record-Typ mit der Bezeichnung PERSON und den zugehörigen Attributen (data
items) NAME, ALTER und GESCHLECHT dar. Jedem Attribut wird ein bestimmter Datentyp, wie z.B. string, integer, char etc. zugeordnet. Die Deklaration
von Record- und Attributnamen sowie die Definition entsprechender Datentypen
stellen inhärente Integritätsbedingungen des hierarchischen Datenmodells dar.
Ein Parent-Child-Relationship-Typ (PCR-Typ) repräsentiert eine 1:n-Beziehung
zwischen verschiedenen Record-Typen. Dabei besteht die 1-wertige Seite aus dem
sogenannten Parent-Record-Typ, und die n-wertige aus einem Child-Record-Typen.
PCR-Typen besitzen keine direkte Bezeichnung. Der Bezug erfolgt durch die binäre
Notation des Paares Parent-Record- und Child-Record-Typ. Besitzt der Record-Typ
ARTIKEL beispielsweise AUTHOR und KEYWORDS als Child-Record-Typen, so
erfolgt die Definition der entsprechenden PCR-Typen durch (ARTIKEL, AUTHOR)
und (ARTIKEL, KEYWORDS ). Die Ausprägung eines PCR-Typs besteht aus einem Record des Parent-Record-Typs und einer gewissen Anzahl (0..n) von Records
des Child-Record-Typs.
Ein weiteres Strukturierungskonzept des hierarchischen Modells stellen die sogenannten virtuellen PCR-Typen dar, mit denen sich n:m-Beziehungen zwischen verschiedenen Record-Typen repräsentieren lassen. Auf dieses Konzept wird in diesem
Zusammenhang nicht näher eingegangen. Eine detaillierte Beschreibung dieser Methode ist unter anderem in [Ull82] oder [EN94] zu finden.
Ein hierarchisches Datenbank-Schema besteht aus einem oder mehreren hierarchischen Schemata, die ihrerseits wiederum aus einer Menge von Record- und PCRTypen gebildet werden. Bei der Modellierung der hierarchischen Schemata sind
folgende Konventionen einzuhalten:
1.
2.
3.
4.
5.
Genau ein Record-Typ fungiert nicht als Child eines PCR-Typs.
Dieser ausgezeichnete Typ wird als Wurzel (root) bezeichnet.
Jeder Record-Typ, mit Ausnahme der Wurzel, ist als Child an
genau einem PCR-Typ beteiligt.
Jeder Record-Typ kann in mehreren PCR-Typen als Parent fungieren.
Record-Typen, die in keinem PCR-Typ als Parent vorkommen,
werden als Blatt (leaf ) bezeichnet.
Besitzt ein Record-Typ mehr als ein Child, so sind diese, entsprechend der Reihenfolge in der sie definiert wurden, geordnet.
Hierarchische Datenbank-Schemata sind äquivalent zu den von der Graphentheorie
her bekannten Wäldern, die aus einem oder mehreren Bäumen bestehen. Dabei
symbolisieren die Record-Typen die Knoten und die PCR-Typen die Kanten eines
Baums.
17
KAPITEL 2. GRUNDLAGEN
2.2.2
Schema-Diagramm und Datenbank-Zustand
Das Schema-Diagramm des hierarchischen Modells weist eine baumartige Struktur
auf. Record-Typen werden dabei als Rechtecke dargestellt, in deren oberen Bereich
die Bezeichnung des Record-Typs und in dessen unterem Bereich die zugehörigen
Attribute angeordnet sind. Die Datentypen werden im Schema-Diagramm nicht
explizit erwähnt. PCR-Typen werden durch eine Verbindungslinie zwischen ParentRecord- und Child-Record-Typen symbolisiert. In Abbildung 2.4 ist das Diagramm
eines bestimmten Datenbank-Schemas beispielhaft dargestellt. Dabei besitzt jeder
Record-Typ einen sogenannten Typ-Indikator (z.B. ’AR’), dessen Funktion bei der
Beschreibung von hierarchischen Zustandsbäumen erläutert wird.
(a)
Record−Typen : JOURNAL(NAME:string)
ARTICLE(TITLE:string, PAGE:integer, URL:string)
AUTHOR(NAME:string)
KEYWORDS(WORD:string)
PCR−Typen:
(JOURNAL, RECORD)
(ARTICLE, AUTHOR)
(ARTICLE, KEYWORDS)
(b)
J
AR
A
TITLE
AUTHOR
NAME
JOURNAL
NAME
ARTICLE
PAGE
URL
K
KEYWORDS
WORD
Abbildung 2.4: Hierarchisches Datenbank-Schema (a) und Schema-Diagramm (b)
Bei der Ausprägung eines hierarchischen Schemas entsteht eine Menge von sogenannten Zustandsbäumen. Die Wurzel jedes Zustandsbaums wird dabei von einem
Record des Root-Record-Typs gebildet. Von ihr zweigen alle Records der zu der
Wurzel gehörenden Child-Record-Typen ab. Jeder dieser Records kann wiederum als
Parent in einem oder mehreren PCR-Typen fungieren. Erneut zweigen alle ChildRecords der jeweiligen PCR-Typen von diesen Parent-Records ab. Der Vorgang
wiederholt sich solange, bis alle als Blätter definierten Record-Typen erreicht sind.
J ComputerWorld
AR XML
A Smith
K Markup
AR Databases
K SGML
A Dillon
K Schema
K SQL
AR JAVA
K JDBC
A Gape
K class
Abbildung 2.5: Zustandsbaum einer hierarchischen Ausprägung
K method
18
KAPITEL 2. GRUNDLAGEN
In Abb. 2.5 ist ein Zustandsbaum des in Abbildung 2.4 dargestellten DatenbankSchemas zu sehen. In diesem Zusammenhang wird auch die Funktion der bereits
angesprochenen Typ-Indikatoren deutlich. Besitzt ein Record-Typ nämlich mehrere Child-Record-Typen, so können innerhalb des Zustandsbaums die Typen der
jeweiligen Child-Records anhand dieser Indikatoren identifiziert werden.
2.2.3
Hierarchische Sequenz
Im vorausgegangenen Abschnitt wurde die Ausprägung einer hierarchischen Datenbank in Form von Zustandsbäumen beschrieben. Die Frage ist nun, wie solche
Zustandsbäume gespeichert werden können. Eine einfache Methode ist durch die
sogenannte hierarchische Sequenz gegeben. Dabei werden alle Datensätze des Zustandsbaums entsprechend ihrer Reihenfolge in einem Preorder -Durchlauf linear
gespeichert. In Abb. 2.6 ist die hierarchische Sequenz des im vorherigen Abschnitt
gezeigten Zustandsbaums dargestellt.
J
AR
A
K
K
AR
A
K
K
K
AR
A
K
K
ComputerWorld
XML
Smith
Markup
SGML
Databases
Dillon
Schema
SQL
JDBC
JAVA
Gape
class
method
Abbildung 2.6: Hierarchische Sequenz eines Zustandsbaums
Die Funktion der Typ-Indikatoren bezieht sich hierbei nicht mehr ausschließlich auf
die Identifizierung von Child-Records unterschiedlicher Typen, sondern schließt die
Erkennung sämtlicher Datensätze mit ein.
2.3
Wrapper und Mediatoren
Die funktionalen Transformationskomponenten des ZIS werden durch Wrapper realisiert, während die Aufgaben der Integration von einen Mediator übernommen werden. In diesem Abschnitt werden die Eigenschaften von Wrappern und Mediatoren
erläutert und die bei der Transformation bzw. Integration enstehenden Aufgaben
beschrieben.
2.3.1
Wrapper
Als Wrapper werden Software-Module bezeichnet, die einzelne Datenquellen ein”
kapseln“ und dadurch deren Erscheinungsbild anderen Software-Komponenten gegenüber verändern [TRS97]. Der Einsatz von Wrappern kann aus unterschiedlichen
19
KAPITEL 2. GRUNDLAGEN
Gründen erfolgen. Einerseits, um die Handhabung“ der Datenquellen zu vereinfa”
chen bzw. ihre Funktionalität zu erweitern. Andererseits können verschiedene Datenquellen durch entsprechende Wrapper jeweils so eingekapselt“ werden, daß alle
”
ein einheitliches Erscheinungsbild aufweisen. Daraus folgt, daß beispielsweise ein
Anwendungsprogramm auf alle benötigten Quellen in der gleichen Form zugreifen
kann. Die Aufgabe von Wrappern besteht somit darin, das simulierte Erscheinungsbild auf die reellen Gegebenheiten der jeweiligen Datenquelle zu transformieren. In
Anlehnung an [TRS97] erfolgt im Anschluß eine kurze Beschreibung des Aufbaus
beliebiger Datenquellen.
Eine Datenquelle Q basiert auf einem Datenmodell M(Q). Ausgehend von diesem Modell existiert ein Schema S(M), das die Struktur des Datenbestands beschreibt. An der Schnittstelle stellt die Datenquelle eine Menge von Operationen
zur Verfügung, mit denen der Zugriff auf den Datenbestand erfolgt. In Abhängigkeit
von dem zugrunde liegenden Datenmodell kann es sich dabei entweder um einfache
Lese- und Schreiboperationen oder aber auch um eine deskriptive Anfragesprache,
wie z.B. SQL, handeln. Im folgenden wird die Menge der jeweiligen Operationen als
die Sprache L(M) der Datenquelle bezeichnet.
Datenquelle
E(L,S)
Sprache L(M)
A(E,S)
Schema S(M)
Datenmodell M(Q)
Abbildung 2.7: Logische Struktur von Datenquellen
In dem gegebenen Zusammenhang läßt sich der Ablauf eines Zugriffs auf eine beliebige Datenquelle, wie in Abb. 2.7 dargestellt, beschreiben. Eine Software-Komponente, z.B. ein Anwendungsprogramm, generiert in Abhängigkeit von L(M) und
unter Berücksichtigung des Schemas S(M) eine Eingabe E(L,S) und übergibt diese
an der entsprechenden Schnittstelle an die Datenquelle weiter. Die Struktur der daraus entstehenden Ausgabe A(E,S) hängt dabei wiederum von dem der Datenquelle
zugrunde liegenden Schema ab.
Ein Wrapper kann eine Datenquelle nun dahingehend einkapseln“, daß sich de”
ren grundlegenden Eigenschaften (Datenmodell, Schema, Sprache) aus Sicht der
anderen Software-Komponenten in einer modifizierten Form darstellen. Dabei werden Anfragen nicht mehr direkt an die reell existierende Datenquelle, sondern an
die durch den Wrapper simulierte Datenstruktur gerichtet, die ebenso die Formatierung der Ausgabe bestimmt. Die Einkapselung“ einer Datenquelle wird durch
”
verschiedene Ein- und Ausgabetransformationen innerhalb des Wrappers realisiert.
Im wesentlichen können zwei Arten von Transformationen unterschieden werden
[Wel96]. Zum einen die generischen Transformationen, bei denen der Funktionsumfang der Sprache L(M) modifiziert bzw. erweitert wird. Zum anderen die Quellenspezifischen Transformationen, die sich ihrerseits wiederum in Schema- bzw. Datenmodell-Transformationen unterteilen lassen.
In Abb. 2.8 ist der Ablauf einer generische Transformation dargestellt. Eine Anfrage
E(L*,S) in der durch den Wrapper zur Verfügung gestellten Sprache L*(M) wird
20
KAPITEL 2. GRUNDLAGEN
Wrapper
E(L*,S)
E(L,S)
Datenquelle
A(E,S)
A(E,S)
Abbildung 2.8: Generische Transformation
in eine Eingabe E(L,S) transformiert, die von der zugehörigen Quelle interpretiert
und verarbeitet werden kann. Der Wrapper basiert hierbei auf dem gleichen Schema S(M) wie die Datenquelle Q, wodurch keine Transformation der Ergebnismenge
A(E,S) erforderlich wird. Beispielhaft sei in diesem Zusammenhang die Transformation von Anfragen in SQL3 auf SQL-Anfragen an ein Oracle DBS erwähnt.
Wrapper
E(L,S*)
E(L,S)
Datenquelle
A(E,S*)
A(E,S)
Abbildung 2.9: Schema-Transformation
Bei der Schema-Transformation wird eine Anfrage E(L,S*), die für das durch den
Wrapper simulierte Schema S* generiert wurde, auf eine Anfrage E(L,S) abgebildet, die auf dem Schema S der originären Datenquelle basiert. Das Anfrageergebnis A(E,S) muß dann wiederum in eine Ausgabe A(E,S*) umgewandelt werden.
Der Ablauf einer Schema-Transformation wird in Abb. 2.9 gezeigt. Es sei darauf hingewiesen, daß ein Wrapper selbstverständlich auch generische und SchemaTransformation gleichzeitig ausführen kann.
Wrapper
E(L*(M*),
S*(M*))
E(L(M),S(M))
Datenquelle
A(E,S*(M*))
A(E,S(M))
Abbildung 2.10: Datenmodell-Transformation
Soll durch den Wrapper ein anderes Datenmodell simuliert werden, ändern sich automatisch die anderen Eigenschaften der Datenquelle, da diese von dem gegebenen
Modell abhängig sind. Bei einer Datenmodell-Transformation müssen daher sowohl
die Sprache L*(M*) auf L(M), als auch das Schema S*(M*) auf S(M) bezüglich der
Datenmodelle M* und M abgebildet werden. Abbildung 2.10 beschreibt die dabei
durchzuführenden Transformationsschritte.
21
KAPITEL 2. GRUNDLAGEN
2.3.2
Mediatoren
A mediator is a software module that exploits encoded knowledge about certain sets or
”
subsets of data to create information for a higher layer of application“
Gio Wiederhold, 1992
Ein Mediator vereint heterogene Datenquellen und stellt den jeweiligen Anwendungsprogrammen eine einheitliche Schnittstelle auf den Datenbestand zur Verfügung. Im Rahmen dieser Arbeit bezieht sich Heterogenität dabei nicht auf Unterschiede in den Datenmodellen, da davon ausgegangen wird, daß die Homogenisierung der jeweiligen Modelle durch den Einsatz von Wrappern erreicht wird und
somit keine Aufgabe des Mediators darstellt. Ausgehend von dieser Charakterisierung können Mediatoren, wie in Abb. 2.11 ersichtlich, als eine Vermittlungsschicht
(mediation layer ) zwischen den Anwendungen und den unterschiedlichen Datenbeständen betrachtet werden [Wie92]. Abbildung 2.11 beinhaltet bereits die den
Datenquellen übergeordneten Wrapper.
Application 0
....
Application M
Application Layer
Mediator
Mediation Layer
Wrapper 0
Wrapper 1
....
....
Source 0
Source 1
Wrapper N
Data Source Layer
Source N
Abbildung 2.11: Allgemeine Mediator-Architektur
Durch den Einsatz eines Mediators wird die Unabhängigkeit der Applikationen von
den zugrunde liegenden Datenquellen gewährleistet. Damit die Anwendungsprogramme die benötigten Daten in einer geeigneten Form (syntaktisch und semantisch) erhalten, muß der Mediator eine Vielzahl von Funktionen bereit stellen. Dies
sind unter anderem die Lokalisierung von und der Zugriff auf Daten der verschiedenen Quellen sowie die Konvertierung der Daten in ein einheitliches Format. Beispielhaft sei hierbei die Umwandlung von Preisangaben in eine gemeinsame Währung
erwähnt. Weiterhin müssen die Schema-Konstrukte der unterschiedlichen Datenquellen insofern angeglichen werden, als daß Objekte, die den gleichen Sachverhalt
darstellen, auch als solche interpretiert werden. Aufgabe des Mediators ist es also,
die Abstraktionsebenen der verschiedenen Datenquellen dahingehend anzugleichen,
daß eine Datenintegration ermöglicht wird.
2.4
Standard Generalized Markup Language
Neben verschiedenen Datenbanken werden auch Web-Sites als Medium digitaler
Bibliotheken in das ZIS integriert. Diese Web-Sites basieren auf der Dokumentbeschreibungssprache HTML, die eine SGML-Anwendung darstellt. Daneben werden
22
KAPITEL 2. GRUNDLAGEN
bei der Entwicklung eines Web-Site DBS verschiedene Konzepte der Sprache XML
verwendet. Vereinfacht ausgedrückt läßt sich sagen, daß XML nichts anderes als eine
reduzierte Version von SGML darstellt [Lob98]. Aufgrund der engen Beziehung von
HTML und XML zu SGML werden im folgenden die wesentlichen Konzepte von
SGML vorgestellt, die allerdings ebenso für XML gelten. Um die Verständlichkeit
dieser Konzepte zu erleichtern, wird zu Beginn die Funktionsweise von Markup, einem grundlegenden Bestandteil von SGML, erläutert. Die folgenden Ausführungen
basieren im wesentlichen auf den Darstellungen in [Gol90, Bry88, Wil99].
2.4.1
Markup
Dokumente bestehen aus verschiedenen Elementen, auch Informationseinheiten genannt, die in ihrer Gesamtheit einen Text logisch strukturieren. Ein einfaches Beispiel soll diesen Zusammenhang verdeutlichen. Ein Buch wird durch die Elemente Titel, Verfasser, Überschrift, Kapitel, Abschnitt und Paragraph in dem Sinne
strukturiert, daß ein Kapitel durch eine Überschrift eingeleitet wird und mehrere
Abschnitte enthält, die wiederum aus mehreren Paragraphen bestehen. Dadurch
entsteht eine hierarchische Dokumentstruktur, wie in Abb. 2.12 zu erkennen.
Buch
Titel
Verfasser
Überschrift
Überschrift
Kapitel 1
Abschnitt 1
Paragraph 1
...
Kapitel 2
Abschnitt 2
...
Paragraph 2
Kapitel n
Abschnitt n
...
Paragraph n
Abbildung 2.12: Dokumentstruktur eines Buches
Im allgemeinen werden die Informationseinheiten eines Dokuments implizit durch
Unterschiede in der Darstellung oder Positionierung der entsprechenden Textsegmente kenntlich gemacht. So kann eine Überschrift beispielsweise fettgedruckt sowie durch eine Leerzeile vom nachfolgenden Text getrennt ausgegeben, und dadurch als Überschrift-Element identifiziert werden. Für den weltweiten Austausch
von Dokumenten in elektronischer Form besitzt diese Art der Kennzeichnung von
Informationseinheiten jedoch zu wenig Aussagekraft, um eine eindeutige Identifizierung der jeweiligen Textelemente zu gewährleisten. Deshalb werden zusätzlich
zu dem eigentlichen Text explizit Anweisungen in das Dokument integriert, die bei
der Interpretation zur Strukturierung und Formatierung des Textes genutzt werden
können. Diese Anweisungen werden, in Anlehnung an die Tätigkeit eines Editors,
als Markup bezeichnet.
Für die korrekte Interpretation eines mit Anweisungen versehenen Dokuments muß
die Unterscheidung zwischen originärem Text und Markup möglich sein. Aus diesem
Grund werden bestimmte Zeichen oder Zeichenketten definiert, um Anfang und
Ende eines Markup eindeutig identifizieren zu können. Diese Begrenzungszeichen
KAPITEL 2. GRUNDLAGEN
23
(delimiter ) dürfen natürlich im eigentlichen Text nicht vorhanden sein, bzw. müssen
mit Hilfe von Sonderzeichen verschlüsselt werden.
Ein Markup bildet zusammen mit den dazugehörigen Begrenzungszeichen ein Tag.
Um ein Element eines Dokuments auszuzeichnen wird ein Tag-Paar benötigt. Ein
StartTag, das den Anfang des Elements definiert, und ein EndTag. Soll beispielsweise ein Textsegment einem Überschrift-Element zugeordnet werden, so kann dies
folgendermaßen geschehen:
[HEADLINE] Dies ist eine Überschrift [/HEADLINE]
Das StartTag besteht hierbei aus dem Elementnamen HEADLINE sowie den Begrenzungszeichen [ und ]. Im Vergleich dazu unterscheidet sich das EndTag nur durch
das öffnende Begrenzungszeichen [/. Bei der Formatierung des Dokuments wird,
sofern die Semantik des Elements bekannt ist, das markierte Textsegment als Überschrift interpretiert und den stylistischen Einstellungen entsprechend dargestellt.
Der Begriff der Semantik von Elementen wird im weiteren Verlauf der Ausführungen noch näher erläutert. In einigen Fällen wird das Ende eines Elements implizit
durch den Beginn eines nachfolgenden ausgezeichnet. So endet beispielsweise das
Überschrift-Element automatisch mit dem Beginn des folgenden Textes. In diesem
Fall kann eine Vereinbarung getroffen werden, die es erlaubt, solche Elemente nicht
explizit durch ein EndTag schließen zu müssen. Diese optionale Begrenzung einer
Informationseinheit wird als minimalisiertes Markup bezeichnet.
Durch die explizite Auszeichnung der unterschiedlichen Elemente erfolgt die Abtrennung des Inhalts eines Dokuments von seiner Layout-spezifischen Darstellung.
Hieraus ergibt sich ein wesentlicher Vorteil gegenüber der herkömmlichen impliziten
Auszeichnung von Textsegmenten. Zum einen wird der Verfasser eines Dokuments
von zeitintensiven Formatierungsaufgaben entbunden und kann sich vollständig auf
die inhaltliche Gestaltung des Textes konzentrieren. Zum anderen kann der Leser
das Dokument seinen individuellen Wünschen entsprechend formatieren.
In anderen Bereichen wiederum wird eine unveränderliche Darstellung spezieller
Textelemente angestrebt, wie dies z.B. im Bereich der Corporate Identity der Fall
ist. Auch dafür kann Markup genutzt werden. Eine entsprechende Anweisung könnte wie folgt aussehen:
[ITALIC] Dieser Text wird kursiv dargestellt [/ITALIC]
Dadurch wird der Interpreter ausdrücklich dazu aufgefordert, das Textsegment in
Kursiv-Schrift zu formatieren. Weiterhin ist zu erwähnen, daß Elementen auch Attribute zugeordnet werden können, die im StartTag des Elements definiert werden.
[HEADLINE font=arial] Text in Arial-Schrift [/HEADLINE]
In diesem Beispiel ist font ein Attribut von HEADLINE mit dem Wert arial. Aufgrund dieser Angabe wird das Überschrift-Element in der Schriftart Arial dargestellt.
Damit sind die zur Zeit am häufigsten benutzten Arten von Markup vorgestellt
worden. Dies sind zum einen Generalized Markup Instruktionen, wie beispielsweise
HEADLINE, die die Elemente eines Dokuments auszeichnen, und zum anderen Specific
Markup Instruktionen (z.B. ITALIC), durch die explizit Einfluß auf die Formatierung
des Textes genommen werden kann.
2.4.2
Aufbau von SGML-Dokumenten
Im Jahre 1986 wurde die Standard Generalized Markup Language (SGML), ein System zur Definition von Markup-Sprachen, als internationaler Standard ISO 8879
KAPITEL 2. GRUNDLAGEN
24
verabschiedet. SGML ist demzufolge keine in allen Einzelheiten festgelegte Sprache, sondern stellt ein abstraktes, formales Regelwerk zur Verfügung, welches erst
von einer auf SGML basierenden Anwendung konkretisiert wird [Lob98]. Hauptziel
bei der Entwicklung von SGML war die Aufteilung von Informationen in logisch
strukturierten Inhalt auf der einen und Layout-spezifische Aspekte auf der anderen
Seite. Dieses Ziel ist durch den Einsatz von Markup realisiert worden. Innerhalb
des SGML-Standards existieren allerdings keine Regeln für die Präsentation eines
Dokuments.
Jede auf SGML basierende Sprache wird als eine SGML-Anwendung bezeichnet. Die
bekannteste SGML-Anwendung ist zweifellos HTML. Jedes Dokument einer SGMLAnwendung besteht im wesentlichen aus drei Teilen: der Deklaration, der Definition
des Dokumenttyps (document type definition, DTD) und der Dokumentinstanz. Die
im folgenden vorgestellten Beispiele und Erläuterungen können keinen vollständigen
Einblick in die vielfältigen und häufig komplexen Möglichkeiten, die der SGMLStandard offeriert, gewähren. Ziel ist es vielmehr, ein gewisses Verständnis für die
Konzepte, auf denen SGML basiert, zu vermitteln.
2.4.2.1
SGML-Deklaration
Die SGML-Deklaration stellt den wichtigsten Bestandteil eines SGML-Dokuments
dar. Neben der Angabe bestimmter Parameter, beispielsweise ob die Anwendung
minimalisiertes Markup unterstützen soll, wird durch die Deklaration die Syntax
sowohl der DTD, als auch der Dokumentinstanzen definiert. Die Syntax bestimmt
den zu verwendenden Zeichensatz, die Form der Begrenzungszeichen und vieles
mehr. Ohne diese Angaben wäre die korrekte Interpretation eines Dokuments nicht
möglich. Zusammen mit SGML wurde eine Standard-Syntax, die sogenannte Reference Concrete Syntax, zur Verfügung gestellt. Diese wird automatisch genutzt,
falls innerhalb der SGML-Deklaration keine andere Syntax spezifiziert ist.
2.4.2.2
Dokument Type Definition (DTD)
Durch die DTD wird die Struktur eines SGML-Dokuments bestimmt. Zusätzlich
zu den Element-Definitionen werden abstrakte Regeln formuliert, die angeben, auf
welche Weise die Elemente miteinander kombiniert werden dürfen. In diesem Zusammenhang wird zwischen Daten-, Container- sowie leeren Elementen unterschieden. Ein einfaches Beispiel einer DTD, basierend auf der SGML Standard-Syntax,
soll die Eigenschaften der verschiedenen Element-Typen verdeutlichen. Dabei werden alle Element-Definitionen durch das Begrenzungszeichen <! gefolgt von dem
Schlüsselwort ELEMENT geöffnet und mit > geschlossen.
!ELEMENT
!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<
<
Buch
Kapitel
Abschnitt
Verfasser
Paragraph
Überschrift
Titel
Vorname
Nachname
Unbekannt
(Titel?, Verfasser, Kapitel+) >
(Überschrift, Abschnitt+)>
(Überschrift, Paragraph+)>
((Vorname*, Nachname) | Unbekannt) >
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
KAPITEL 2. GRUNDLAGEN
25
Daten-Elemente, die durch die Zuweisung des Schlüsselworts #PCDATA innerhalb
der Element-Definition gekennzeichnet werden, enthalten unmittelbar die konkreten
Textinformationen. So stellen Paragraph, Überschrift, Titel, Vorname und Nachname im gezeigten Beispiel die Daten-Elemente des Dokuments dar.
Durch das Schlüsselwort EMPTY werden leere Elemente identifiziert. Sie zeichnen sich
dadurch aus, daß sie kein EndTag besitzen und werden hauptsächlich zur Strukturierung eines Dokuments verwendet. So fungiert Unbekannt in der oben beschriebenen
DTD alternativ zum Namen des Verfassers als nicht triviale Informationseinheit, da
durch die Existenz dieses Elements die logische Struktur des Textes aufrecht erhalten werden kann. Außerdem können leere Elemente als Anweisungen zum Einfügen
verschiedener Objekte, wie z.B. Abbildungen, benutzt werden.
Container-Elemente schließlich bestehen entweder aus Daten- bzw. leeren Elementen und/oder weiteren Container-Elementen. Informationseinheiten dieses Typs,
werden durch die Zuweisung eines Inhaltmodells (content model ), das eine spezielle Syntax besitzt, beschrieben. Das Element Buch beispielsweise beginnt optional
(Fragezeichen ?) mit dem Titel, gefolgt von dem Verfasser und einem oder mehreren Kapiteln (Additionszeichen +). Die genaue Syntax des Inhaltmodells, das
auch noch Möglichkeiten zur Inklusion und Exklusion bestimmter Element-Typen
bereitstellt, wird in [Gol90] ausführlich beschrieben.
Wie bereits erwähnt, können Elementen auch verschiedene Attribute zugeordnet
werden. Dies geschieht ebenfalls innerhalb der DTD. Eine Attribut-Definition wird
mit dem Begrenzungszeichen <! und dem Schlüsselwort ATTLIST eingeleitet. Danach
werden die Namen der Elemente, denen dieses Attribut zugeordnet werden soll,
angegeben. Schließlich folgen Attributname, -Typ und -Status.
<
!ATTLIST Person geschlecht (m|f) #REQUIRED >
In diesem Fall wird geschlecht als Attribut des Elements Person definiert. Dabei
kann der Wert von geschlecht entweder m (male) oder f (female) sein. Durch
das Schlüsselwort #REQUIRED erhält das Attribut den Status erforderlich“, was
”
bedeutet, daß dieses Attribut beim Element person immer mit einem Wert versehen
sein muß. Weitere Möglichkeiten für den Attributstatus sind #IMPLIED oder #FIXED.
2.4.2.3
Dokumentinstanz
Dokumente, die die gleiche DTD besitzen, also auf der gleichen Struktur basieren,
bilden eine Dokumentklasse. Jedes Dokument einer speziellen Dokumentklasse wird
als Instanz dieser Klasse bezeichnet.
Wichtig ist die Unterscheidung zwischen den Begriffen SGML-Anwendung, Dokumentklasse und Dokumentinstanz. Eine SGML-Anwendung stellt die Konkretisierung des SGML-Regelwerks dar. Dieses wird durch die SGML-Deklaration erreicht.
Jede Anwendung wiederum definiert verschiedene Dokumentklassen, d.h. stellt bestimmte Strukturen zur Verfügung, auf denen die jeweiligen Dokumente der Anwendung basieren. Diese Strukturen werden in der Dokument Type Definition festgelegt.
Das eigentliche Dokument wird dann als Instanz einer Dokumentklasse bezeichnet.
Folgende Problematik beinhaltet SGML: Auch wenn die Syntax eines Dokuments
bekannt ist, so bleibt die Semantik der Elemente unbekannt. Existiert zum Beispiel
ein Element mit dem Namen H1, so weiß der Leser noch nicht, wie er H1 zu interpretieren hat. Erst wenn global festgelegt ist, daß H1 eine Überschrift darstellen
soll, kann das Element korrekt interpretiert werden. Es ist also für die korrekte Darstellung mit Markup versehener Dokumente von allergrößter Bedeutung, daß der
Interpreter die Semantik der entsprechenden Elemente kennt.
Kapitel 3
Föderierte
Datenbanksysteme
In der bisherigen Arbeit wurde ein DBS als ein System einer oder mehrerer Datenbanken und einem dazugehörigen DBMS betrachtet. Diese Definition wird nun
dahingehend erweitert, daß der Zusammenschluß verschiedener DBSe wiederum ein
logisches System, ein sogenanntes Multidatenbanksystem (multidatabase system)
darstellt. Im Gegensatz dazu werden DBSe, bei denen die Verwaltung des Datenbestands auf ein dediziertes DBMS ausgerichtet ist, in dieser Arbeit als unitäre DBSe
bezeichnet. Dabei kann es sich sowohl um zentrale, als auch auch verteilte DBSe
handeln. Bei verteilten DBSen kommen zwar mehrere DBMSe zum Einsatz, diese
sind jedoch alle einem ausgezeichneten DBMS untergeordnet. Es bleibt anzumerken, daß die in Abschnitt 2.1.3 beschriebenen Anforderungen an DBMSe für alle
Arten von DBSen gelten.
Ein Föderiertes Datenbanksystem (fedrated database system) ist ein spezielles MultiDBS und stellt Konzepte für die Integration verteilter, heterogener DBSe zur Verfügung. Ziel ist es, einen einheitlichen sowie für den Benutzer transparenten Zugriff
auf die unterschiedlichen Datenbestände (Komponentensysteme) zu ermöglichen.
Dabei bleibt im Gegensatz zu anderen Multi-DBS-Architekturen die Autonomie
der an der Föderation beteiligten Komponentensysteme erhalten.
Im folgenden wird zunächst eine Klassifizierung von DBSen im allgemeinen sowie von Multi-DBSen im besonderen vorgestellt. Es sei darauf hingewiesen, daß in
der fachspezifischen Literatur unterschiedliche Vorstellungen darüber existieren, wie
die Termini verteilte DBSe, Multi-DBSe und föderierte DBSe zu definieren bzw.
anderen DBSen gegenüber abzugrenzen sind. Diese Arbeit folgt im wesentlichen
der in [Con97] dargestellten Terminologie. Schließlich wird eine Referenzarchitektur
für föderierte DBSe, die sogenannte 5-Ebenen-Schema-Architektur, vorgestellt. Auf
Aspekte des föderierten Datenbankentwurfs wird in diesem Zusammenhang nicht
eingegangen. Bestimmte Konzepte werden bei der Entwicklung des ZeitschriftenInformationssystems vorgestellt, ansonsten wird auf die entsprechende Fachliteratur, wie z.B. [Con97], verwiesen.
3.1
Klassifizierung von Datenbanksystemen
Bei der Klassifizierung verschiedener Arten von DBSen erfolgt, wie eingehend erwähnt, zunächst eine Unterteilung in unitäre und Multi-DBSe. Je nachdem, ob der
26
27
KAPITEL 3. FÖDERIERTE DATENBANKSYSTEME
Datenbestand auf einem lokalen Rechner oder auf mehreren miteinander vernetzten
Rechnern gespeichert ist, werden unitäre DBSe in zentrale bzw. verteilte Systeme
gegliedert. Multi-DBSe werden anhand ihrer Charakteristik in Bezug auf Distribution, Heterogenität und Autonomie klassifiziert. In Abbildung 3.1 wird nur zwischen
föderierten und nicht-föderierten Multi-DBSen unterschieden, eine genauere Klassifizierung erfolgt bei der Beschreibung von Multi-DBSen.
Datenbanksysteme
unitäre DBSe
verteilteDBSe
Multidatenbanksysteme
zentrale DBSe
nicht−föderierte MultiDBSe
föderierte MultiDBSe
parallele DBSe
lose gekoppelt
eng gekoppelt
einfache
Föderation
mehrfache
Föderation
Abbildung 3.1: Klassifikation von Datenbanksystemen
3.1.1
Unitäre Datenbanksysteme
Nachdem im zweiten Kapitel bereits die Konzepte zentraler DBSe eingehend erläutert und die Drei-Ebenen-Archiktektur als Grundlage solcher Systeme vorgestellt
wurde, soll in diesem Abschnitt ein Einblick in den Aufbau verteilter DBSe geschaffen werden.
Durch die Entwicklungen im Bereich der Netzwerktechnologie wurde die Möglichkeit
geschaffen, auf unterschiedlichen Rechnern Anwendungen auszuführen, die auf einen
gemeinsamen Datenbestand zugreifen. Werden diese Daten zentral gespeichert, kann
es bei größeren Systemen aufgrund der Prozeßsynchronisation zu Engpässen bei der
Anfrage- und Transaktionsbearbeitung kommen. Um die dabei auftretenden Performanceverluste zu umgehen, wird der Datenbestand auf mehreren Rechnern verteilt
und eventuell repliziert gespeichert, so daß nun nicht mehr nur ein einzelnes Rechnersystem mit der Prozeßbearbeitung belastet wird. Die Verteilung bezieht sich
dabei sowohl auf die Partionierung des Datenbestandes in mehrere logisch zusammenhängende Datenbanken, als auch auf die verteilte Speicherung eines einzelnen
Gesamtschemas.
Verteilte Datenbanksysteme werden wie bereits erwähnt von mehreren DBMSen verwaltet, die einem dedizierten DBMS untergeordnet sind. Die DBMSe stellen somit
ihrerseits ein verteiltes System dar [CP84]. Kernforderung bei der Implementierung
eines verteilten Systems ist es, eine transparente Sicht auf den Datenbestand zu
gewährleisten. Das bedeutet, daß es für den Benutzer keinen Unterschied macht, ob
er mit einem zentralen oder einem verteilten DBS arbeitet und somit auch keine
Kenntnisse darüber benötigt, wo die für ihn relevanten Daten gespeichert sind.
28
KAPITEL 3. FÖDERIERTE DATENBANKSYSTEME
Grundlage verteilter DBSe bildet die 4-Ebenen-Architektur (vgl. Abbildung 3.2), die
eine Weiterentwicklung der ANSI/SPARC-Architektur zentraler DBSe darstellt. Jeder der an dem verteilten System beteiligten DB-Knoten besitzt auf lokaler Ebene
sowohl ein internes, als auch ein konzeptionelles Schema. Diese Schemata sind dabei
von dem globalen konzeptionellen Schema abgeleitet worden, so daß dem Benutzer
eine transparente Sicht auf das verteilte DBS zur Verfügung steht. In diesem Zusammenhang wird der wesentliche Unterschied zwischen verteilten und Multi-DBSen
deutlich. Während bei Multi-DBSen die lokalen Schemata zu einem globalen Schema zusammengefaßt werden (bottom-up Strategie), wird im Bereich verteilter DBSe
ein globales Schema auf mehrere lokale Schemata verteilt (top-down Strategie).
External Schema 1
....
External Schema n
Conceptual Schema
Local
Conceptual Schema
Local
Conceptual Schema
....
Local
Conceptual Schema
Local
Internal Schema
Local
Internal Schema
....
Local
Internal Schema
Abbildung 3.2: Referenzarchitektur für verteilte Datenbanksysteme
Parallele DBSe stellen eine Spezialisierung verteilter DBSe dar [Con97]. Durch die
Anwendung von Konzepten der Parallelrechner-Technologie soll eine PerformanceSteigerung im Bereich der Anfrage- und Transaktionsberarbeitung erreicht werden.
Nähere Informationen zu parallelen DBSen lassen sich in [Vos00] finden.
3.1.2
Multidatenbanksysteme
Multi-DBSe bilden einen Zusammenschluß verschiedener DBSe, die innnerhalb der
Vereinigung als Komponentendatenbanksysteme (KDBSe) bezeichnet werden. Anhand der Verteilung, der Heterogenität und der Autonomie der KDBSe läßt sich
eine Klassifizierung von Multi-DBSen, wie in Abbildung 3.3 dargestellt, vornehmen
[ÖV91].
Distribution
Der Grad der Distribution eines Datenbanksystems richtet sich nach der physischen und funktionalen Verteilung der KDBSe. So können die Datenbestände nur
auf einem einzigen Rechner, d.h zentral, oder aber auf mehreren Rechnern verteilt
gespeichert sein bzw. verwaltet werden.
Heterogenität
Bei dem Zusammenschluß verschiedener DBSe können unterschiedliche Heterogenitäten auftreten. Zum einen besteht die Möglichkeit, daß den jeweiligen Datenbanken verschiedene Datenmodelle zugrunde liegen, andererseits können gleiche
Schema-Konstrukte unterschiedlich interpretiert werden (semantische Heterogenität).
29
KAPITEL 3. FÖDERIERTE DATENBANKSYSTEME
Autonomie
Bei der Autonomie eines Datenbanksystems wird zwischen Entwurfs-, Kommunikations- und Ausführungsautonomie unterschieden. Die am Zusammenschluß beteiligten DBSe können zum einen unabhängig voneinander entworfen worden sein (Entwurfsautonomie). Weiterhin ist entscheidend, inwieweit ein System eigenständig
über die Teilnahme am Zusammenschluß bestimmen kann (Kommunikationsautonomie). Schließlich wird unterschieden, in welchem Maße ein System selbst über
die Ausführung von Anwendungsprogrammen entscheiden darf (Ausführungsautonomie).
Distribution
verteilte
homogene MDBS
verteilte
heterogene MDBS
logisch integrierte
homogene MDBS
verteilte
föderierte MDBS
verteilte heterogene
föderierte MDBS
homogene
föderierte MDBS
Autonomie
heterogene
integrierte MDBS
heterogene
föderierte MDBS
Heterogenität
Abbildung 3.3: Klassifizierung von Multidatenbanksystemen
Föderierte DBSe sind Multi-DBSe, deren KDBSe einen hohen Grad an Autonomie besitzen. Aufgrund weiterer charakteristischer Merkmale lassen sich föderierte
DBSe weiter unterteilen. Zuerst wird zwischen lose und eng gekoppelten Systemen
unterschieden. Bei lose gekoppelten föderierten DBSen erfolgt die Zusammenstellung der an der Föderation teilnehmenden KDBSe durch den Benutzer. Dabei muß
er wissen, wie er auf die Datenbestände der einzelnen Systeme zugreifen kann und
inwiefern die Daten verschiedener KDBSe zueinander kompatibel sind. Dadurch
wird ein hohes Maß an Flexibilität erreicht.
Ein eng gekoppeltes föderiertes DBS wird im Gegensatz dazu durch einen Administrator zusammengestellt und verwaltet. Dazu muß er die lokalen DatenbankSchemata in ein globales Schema integrieren, um dem Benutzer eine transparente
Sicht auf die Föderation zu ermöglichen. In einem eng gekoppelten System besitzt
der Benutzer keine Möglichkeit selber zu bestimmen, auf welche Daten er zugreifen
kann. Allerdings werden ihm dafür sämtliche Verwaltungaufgaben vom Administrator abgenommen. Bei eng gekoppelten Systemen wird weiterhin unterschieden, ob
nur eines oder gegebenenfalls mehrere föderierte Schemata entwickelt und bereit
gestellt werden. Analog dazu wird von einfacher bzw. mehrfacher Föderation gesprochen. An dieser Stelle sei vorab erwähnt, daß es sich bei der Implementierung
des ZIS um ein eng gekoppeltes, einfach föderiertes DBS handelt.
30
KAPITEL 3. FÖDERIERTE DATENBANKSYSTEME
3.2
Die 5-Ebenen-Schema-Architektur
In der Literatur werden drei Referenzarchitekturen für föderierte DBSe vorgestellt.
Neben der Import-/Exportschema-Architektur sowie der Multidatenbank-Architektur wird ebenso die 5-Ebenen-Schema-Architektur in diesem Zusammenhang
erwähnt, auf der das Zeitschriften-Informationssystem basiert. Aus diesem Grund
folgt im Anschluß eine genaue Beschreibung der in der 5-Ebenen-Schema-Architektur enthaltenen Konzepte.
Wie bereits erwähnt, besteht ein föderiertes DBS aus verschiedenen, heterogenen
Komponentensystemen. Charakteristisch für die 5-Ebenen-Schema-Architektur im
Vergleich zu den zwei anderen Referenzarchitekturen ist die Existenz eines globalen
Schemas, wie in Abb. 3.4 zu erkennen. Die Komponentensysteme werden innerhalb
der Architektur durch die lokalen Schemata beschrieben. Hierbei sind die lokalen
Schemata genau die konzeptionellen, also implementierungsunabhängigen Schemata der Komponentensysteme. Aufgrund der Heterogenität der an der Föderation
beteiligten Systeme können diese Schemata durchaus auf unterschiedlichen Datenmodellen beruhen.
Externes Schema
....
Externes Schema
Föderiertes Schema
Export−Schema
Export−Schema
....
Export−Schema
Komponenten−
Schema
Komponenten−
Schema
....
Komponenten−
Schema
Lokales Schema
Lokales Schema
....
Lokales Schema
Abbildung 3.4: 5-Ebenen-Schema-Architektur
Um die Heterogenität der Datenmodelle zu eliminieren, erfolgt eine DatenmodellTransformation von den lokalen hin zu den Komponenten-Schemata. Das bedeutet, daß jedes Komponenten-Schema die gleichen Informationen wie das zugrunde
liegende lokale Schema enthält, jedoch in einem für alle Komponenten-Schemata
homogenen Datenmodell. Das hierbei verwendete Modell ist gleichzeitig Grundlage für das föderierte Schema, so daß weitere Transformationen vermieden werden
können.
Die nächste Ebene der Architektur bilden die Export-Schemata. Jedes ExportSchema beschreibt den der Föderation zur Verfügung stehenden Ausschnitt der
jeweiligen Komponentensysteme. Auf Daten, die im Export-Schema nicht definiert
sind, kann das föderierte DBS also nicht zugreifen. Die Export-Schemata basieren
auf dem gleichen Datenmodell wie die Komponenten-Schemata.
KAPITEL 3. FÖDERIERTE DATENBANKSYSTEME
31
Das auch als global bezeichnete, föderierte Schema stellt den Zusammenschluß aller von den an der Föderation beteiligten Komponentensystemen zur Verfügung
gestellten Export-Schemata dar. Bei diesem Zusammenschluß können unterschiedliche Integrationsprobleme auftauchen, die durch geeignete Verfahren gelöst werden
müssen. Beim Entwurf des ZIS wird auf einige dieser Probleme und ihre Lösungsmöglichkeiten näher eingegangen. Wie bereits erwähnt, basiert das globale Schema
auf dem homogenen Datenmodell der Komponenten-Schemata.
Für Anwendungen, die global auf das föderierte DBS zugreifen, können von der
Föderation externe Schemata zur Verfügung gestellt werden. Diese besitzen die
gleiche Funktion wie die in der ANSI/SPARC-Architektur vorhandenen externen
Schemata. Das heißt, jedes externe Schema bildet eine für eine bestimmte Anwendung definierte Schnittstelle, die die Daten des föderierten Schemas in einer für die
Anwendung geeigneten Form bereitstellt. Dabei können unterschiedliche Datenmodelle zum Einsatz kommen.
Abschließend bleibt vor allem in Hinblick auf die Implementierung des ZIS zu
erwähnen daß die Abbildungen vom lokalen zum Komponenten-Schema und davon
weiter zum Export-Schema zu einer Abbildung zusammengefaßt werden können, da
die Unterscheidung zwischen Komponenten- und Export-Schema lediglich formalen
Charakter besitzt. Durch diese Unterscheidung kann nämlich eine strikte Trennung
der architekturbedingten Transformationsprozesse erreicht werden. So erfolgt zwischen lokalem und Komponenten-Schema die Datenmodelltransformation, während
zwischen Komponenten- und Export-Schema eine Filteroperation innerhalb des gleichen Datenmodells erfolgt.
Kapitel 4
Web-Sites als Datenbanken
Um Web-Sites in föderierte DBSe zu integrieren, muß eine Möglichkeit geschaffen
werden, Anfragen an diese Sites zu generieren und die Ergebnismenge in das Datenschema des föderierten DBS zu transformieren. Die Aufgabe der Anfragebearbeitung
kann dabei durch den Einsatz von einem zu diesem Zweck entwickelten Wrapper
gelöst werden. Wrapper weisen allerdings eine meist monolithische Struktur auf und
können somit nur schwer modifiziert bzw. erweitert werden. Daher wird im Rahmen dieser Arbeit ein anderer Ansatz verfolgt und statt eines Wrapper ein Web-Site
Datenbanksystem (WSDBS) entwickelt, das mit Hilfe eines Web-Site ManagementSystems (WSMS) die Integration der entsprechenden Datensätze ermöglicht. Im
Zusammenhang mit dem Zeitschrifteninformations-System wird somit jeder WebSite als eine hierarchische Datenbank aufgefaßt.
Prinzipiell stellt dieser Ansatz kein Problem dar, da Web-Sites analog zu Datenbanken eine große Menge von Daten beinhalten und zur Verfügung stellen. Unterschiede bestehen jedoch in der Bereitstellung und Verwaltung der jeweiligen Informationen. Während in einem DBS die Daten strukturiert gespeichert und von
einem DBMS verwaltet werden, liegen die Daten HMTL-basierter Web-Sites nur
in semi-strukturierter Form vor, so daß ein einheitlicher Zugriff auf die jeweiligen
Datenbestände erheblich schwieriger als bei regulären DBSen zu realisieren ist.
Durch die Entwicklung eines WSDBS wird die einheitliche Betrachtung der vorgestellten Konzepte und des Entwurfs föderierter DBSe ermöglicht und eine transparente sowie strukturierte Sicht auf die Datenquelle geschaffen. Ein weiterer Vorteil
liegt darin, daß das WSDBS sehr leicht modifiziert werden kann. Im folgenden
werden nun die der Entwicklung eines WSDBS zugrunde liegenden Konzepte vorgestellt.
Abschnitt 4.1 befaßt sich mit dem konzeptionellen Entwurf eines WSDBS. In diesem Zusammenhang wird insbesondere auf die charakteristischen Strukturen von
Web-Sites eingegangen und der Datenbankentwurf am Beispiel der ACM Digital Library vorgestellt. Anschließend erfolgt die Beschreibung des Data Retrieval Systems
(DRS), das für die Extraktion relevanter Informationen HTML-basierter Dokumente verantwortlich ist (4.2). Dabei werden die extrahierten Daten an der Schnittstelle
des DRS in Form einer XML-Datei zur Verfügung gestellt. Zum Abschluß des Kapitels erfolgt dann unter Punkt 4.3 eine ausführliche Darstellung der der Implementierung des WSDBS zugrunde liegenden Konzepte. Unter anderem wird in diesem
Zusammenhang auch die Anfragesprache WS/QL vorgestellt.
32
KAPITEL 4. WEB-SITES ALS DATENBANKEN
4.1
33
Datenbankentwurf
Beim klassischen Datenbankentwurf wird durch die Informationsbedarfsanalyse festgelegt, welche Daten in der zu implementierenden Datenbank gespeichert werden
sollen und wie diese untereinander in Beziehung stehen. Ein WSDBS basiert im
Gegensatz dazu auf einer vorgegebenen, unveränderlichen Menge von Informationen. Das bedeutet, daß die Datenbankinhalte bereits vor der Implementierung des
WSDBS durch den Web-Site definiert wurden und vom WSMS nicht mehr erweitert
oder geändert werden können. Statt der Informationsbedarfsanalyse erfolgt daher
eine in dieser Arbeit als Informationsstrukturanalyse bezeichnete Untersuchung des
dem WSDBS zugrunde liegenden Web-Site. Hierauf basierend wird anschließend das
Web-Site-Schema erstellt, welches als Grundlage für die Entwicklung des konzeptionellen Datenbank-Schemas dient. Beide Schemata werden bei der Implementierung
des WSDBS benötigt, so daß die korrekte Unterscheidung zwischen Web-Site- und
Datenbank-Schema für das Verständnis der in diesem Zusammenhang vorgestellten
Konzepte signifikant ist.
Im folgenden werden die grundlegenden Aspekte der Informationsstrukturanalyse
sowie die Eigenschaften eines sich daraus ergebenen Web-Site-Schemas beschrieben. Im Anschluß daran wird gezeigt, wie das Datenbank-Schema unter Berücksichtigung des zugrunde liegenden Web-Site-Schemas entwickelt werden kann. Die
Aufgaben des WSMS in Anlehnung an die von Codd definierten Funktionen allgemeiner DBMS, wie in 2.3 beschrieben, werden am Ende des Abschnitts vorgestellt.
4.1.1
Informationsstrukturanalyse
Die Informationsstrukturanalyse beschreibt die strukturellen Eigenschaften sowie
die zur Verfügung stehenden Informationen des zu integrierenden Web-Site. Dabei
erfolgt die Analyse des Datenbestands ’per Hand’, durch die stichprobenartige Navigation innerhalb des Web-Site. In diesem Zusammenhang müssen vor allem zwei
wesentliche Aspekte der strukturellen Beschaffenheit von Web-Sites beachtet werden. Hierbei handelt es sich einerseits um die allgemeine sowie andererseits um die
spezielle Struktur von Web-Sites.
4.1.1.1
Allgemeine Struktur von Web-Sites
Ein Web-Site besteht im wesentlichen aus einer Menge von Hypermedia-Dokumenten zusätzlich optionaler Objekte, wie z.B. Bild-, Ton- oder Videodateien. Charakteristisch für Hypermedia-Dokumente, die in der heutigen Zeit vorwiegend auf
der Beschreibungssprache HTML basieren, ist der Einsatz sogenannter Verweise
(hyperlinks), die einen bequemen Zugriff auf andere Objekte ermöglichen.
Objekt
extern
Web−Site
extern
global
aktuell
lokal extern
aktuell
_
lokal intern
Abbildung 4.1: Klassifikation von Hyperlinks
KAPITEL 4. WEB-SITES ALS DATENBANKEN
34
DokumentTypeDefinition : "ACM Digital Library""
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Digital Library
PublicationType
Publication
PubDetails
Volume
Issue
Article
Details
Type Name
PubName
ISSN
Description
NumberOfVolume
NumberOfIssue
Year
Month
Title
Author
Pages
Abstract
Keyword
URLFullText
(PublicationType+)>
(TypeName, Publication+)>
(PubName, PubDetails)>
(ISSN, Description?, Volume+)>
(NumberOfVolume, Issue+)>
(NumberOfIssue, (Year,Month)?, Article+)>
(Title, Author+, Pages, Details)>
(Abstract?, Keyword*, URLFullText)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Abbildung 4.2: Struktur des ACM Digital Library Web-Site
Ausgehend von dieser Charakterisierung wird, wie in Abb. 4.1 dargestellt, zwischen
lokalen und globalen auf der einen sowie internen und externen Verweisen auf der
anderen Seite unterschieden. Lokale Verweise beziehen sich auf Dokumente bzw.
Multimedia-Dateien des aktuellen Web-Site, während Referenzen auf Objekte anderer Web-Sites als global bezeichnet werden. Wird auf eine Textstelle innerhalb
des gleichen Dokuments Bezug genommen, so wird von einem internen Verweis
gesprochen, wohingegen der externe ein anderes Objekt des aktuellen Web-Site referenziert. Für die Informationsstrukturanalyse sind lediglich die lokalen externen
Verweise von Interesse, die im weiteren Verauf vereinfacht als Querverweise bezeichnet werden.
Mit Hilfe von Querverweisen wird ein navigierender Zugriff auf die Objekte eines
Web-Site ermöglicht. Ein speziell ausgezeichnetes Dokument, die sogenannte Homepage, ist dabei von besonderer Bedeutung, da es den Startpunkt für die Navigation
darstellt. Alle anderen Objekte des Web-Site sind von der Homepage aus durch
einen oder sukzessiven Einsatz mehrerer Querverweise zu erreichen.
Aus mathematischer Sicht stellt ein Web-Site somit einen endlichen, gerichteten
Multigraphen dar, wobei die Dokumente die Knoten- und die Querverweise die
Kantenmenge des Graphen bilden. Werden Mehrfachkanten zu einer einzelnen zusammengefaßt, entsteht ein endlicher Digraph, der aufgrund der Eigenschaft der
Homepage sogar ein Wurzelgraph ist. Somit besitzt jeder Web-Site wenigstens zwei
aufspannende Bäume, was sich durch den Einsatz der als Breiten- bzw. Tiefensuche
bezeichneten Algorithmen beweisen läßt (vgl. [Güt92]).
Durch die graphentheoretischen Überlegungen wurde gezeigt, daß jeder Web-Site
unterschiedliche hierarchische Strukturen enthält. Aufgabe der Informationsstrukturanalyse ist nun, eine für die Anwendung geeignete hierarchische Darstellung des
Web-Site zu erkennen und für die nachfolgenden Entwurfsphasen zu dokumentieren.
Die hierarchische Beschreibung des Web-Site kann dabei anhand einer Document
Type Definition (DTD) basierend auf der SGML Standard-Syntax erfolgen. Die
KAPITEL 4. WEB-SITES ALS DATENBANKEN
35
Struktur einer solchen DTD wurde unter Punkt 2.4.2 detailliert dargestellt. Abbildung 4.2 beschreibt die DTD der ACM Digital Library 1 .
4.1.1.2
Spezifische Strukturen von Web-Sites
In vielen Fällen werden Dokumente insofern zusammengefaßt, daß sie die gleichen
Inhalt- und Layout-spezifischen Strukturen besitzen. Das bedeutet, daß Informationen in eine für diese Dokumente charakteristische Schablone (Template) integriert
werden. Überwiegend kommen Schablonen bei dynamisch erzeugten Dokumenten
zum Einsatz. Hierbei wird, ausgehend von einer bestimmten Anfrage, ein auf der
Schablone basierendes Dokument generiert, das die zu dieser Anfrage passenden
Informationen enthält. Natürlich können Schablonen auch in statisch erzeugten Dokumenten zum Einsatz kommen, um beispielsweise ein einheitliches und leicht zu
modifizierendes Layout zu realisieren.
Ein einfaches Beispiel soll die Konzepte der Dokument-Generierung und insbesondere die Funktionalität von Schablonen verdeutlichen. Ein Web-Client (i.a. ein Browser) sendet zusammen mit dem URL eine Anfrage an den Web-Server. Dieser leitet
die Anfrage über eine Schnittstelle an die ausgewählte Anwendung (z.B. eine Datenbank) weiter. Der die Schnittstelle realisierende Prozess integriert das Anfrageergebnis in die dafür vorgesehene Schablone und stellt das so generierte Dokument dem
Web-Server zur Verfügung. Die Struktur des Dokuments bleibt dabei unabhängig
vom Umfang des Anfrageergebnisses erhalten.
Template−Klasse
enthaltene Elemente
DigitalLibrary
PublicationType, TypeName
Publications
Publication, PubName
PublicationDetails
PubDetails, ISSN, Description
PublicationReleases
Volume, NumberOfVolume, Issue,
NumberOfIssue, Year, Month
TableOfContents
Article, Title, Author, Pages
DetailsOfArticle
Details, Abstract, Keyword, URLFullText
Abbildung 4.3: Template-Klassen des ACM Digital Library Web-Site
Aufgabe der Informationsstrukturanalyse ist es, die auf der gleichen Schablone basierenden Dokumente zu erkennen und zu einer Template-Klasse zusammenzufassen. Jedes dieser Dokumente stellt dann eine Instanz der entsprechenden TemplateKlasse dar. Die Template-Klassen der ACMDigital Library, zusammen mit den jeweils darin enthaltenen Elementen, sind in Abb. 4.3 aufgeführt.
4.1.2
Web-Site Schema
Nachdem die Informationsstrukturanalyse durchgeführt wurde, kann anhand der
dabei ermittelten strukturellen Informationen ein Web-Site-Schema erstellt werden. Dieses besteht aus den unterschiedlichen Template-Klassen, die entsprechend
1 http://portal.acm.org/dl.cfm
KAPITEL 4. WEB-SITES ALS DATENBANKEN
36
der durch die Strukturanalyse definierten Hierarchie angeordnet sind. Es sei darauf
hingewiesen, daß auch noch andere Schemata existieren können, was allerdings für
die weiteren Überlegungen nicht von Bedeutung ist. Jede Template-Klasse besitzt
einen eindeutigen Namen sowie eine DTD, die die Struktur dieser Klasse beschreibt.
Für die Entwicklung des Web-Site-Schemas müssen nun noch gewisse Modifikationen erfolgen, um den Übergang von einer Template-Klasse in eine andere zu modellieren.
Template−Klasse : "PublicationReleases"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Volume
NumberOfVolume
Issue
NumberOfIssue
Year
Month
(NumberOfVolume, Issue+)>
(#PCDATA)>
(NumberOfIssue, (Year,Month)?, Article+)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Template−Klasse : "TableOfContents"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Article
Title
Author
Pages
(Title, Author+, Pages, Details)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Abbildung 4.4: Zwei Template-Klassen der ACM Digital Library
Abb. 4.4 zeigt zwei Template-Klassen der ACM Digital Library zusammen mit den
in diesen Klassen enthaltenen Element-Deklarationen. Die Template-Klasse ’PublicationReleases’ beispielsweise beinhaltet ein Container-Element ISSUE, das wiederum aus den Daten-Elementen NUMBEROFISSUE sowie optional YEAR und MONTH
besteht. Wie zu erkennen ist, existiert jedoch noch ein weiteres Element in dem Inhaltmodell von ISSUE, nämlich ARTICLE. Dieses wird erst in der Klasse ’TableOfContents’ deklariert. Somit erfolgt explizit ein Querverweis von ’PublicationReleases’
nach ’TableOfContents’. Diese Querverweise sind für die Struktur des Web-Site von
großer Bedeutung und müssen dementsprechend in das Schema integriert werden.
Dies kann auf folgende Weise geschehen:
1. Ein neues Element mit dem Namen HYPERLINK und den Attributen URL und
TEMPLATE-KLASSE wird innerhalb der Template-Klasse neu deklariert.
2. Die enthaltenen expliziten Querverweise werden innerhalb des Inhaltmodells
durch das Element HYPERLINK ersetzt.
3. Die Kardinalitäten der jeweiligen Referenzobjekte werden explizit im Schema
angegeben (s. hierarchisches Datenmodell).
Nach Durchführung dieser Modifikationen kann das Web-Site-Schema erstellt werden. Das Schema für die ACM Digital Library ist in Abb. 4.5 dargestellt. Hierbei
sind die eingefügten HYPERLINK Elemente deutlich zu erkennen. Abschließend sei
noch erwähnt, daß anders als in diesem Beispiel auch mehrere Klassen auf einer
Hierarchie-Ebene existieren können.
37
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Template−Klasse : "DigitalLibrary"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Digital Library
PublicationType
Type Name
HyperLink
HyperLink
(PublicationType+)>
(TypeName, HyperLink)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
#REQUIRED
#REQUIRED>
Template−Klasse : "Publications"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Publication
PubName
HyperLink
HyperLink
(PubName, HyperLink)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
#REQUIRED
#REQUIRED>
1
Template−Klasse : "PublicationDetails"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
PubDetails
ISSN
Description
HyperLink
HyperLink
(ISSN, Description?, HyperLink)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "PublicationReleases"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Volume
NumberOfVolume
Issue
NumberOfIssue
Year
Month
HyperLink
HyperLink
(NumberOfVolume, Issue+)>
(#PCDATA)>
(NumberOfIssue, (Year,Month)?, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "TableOfContents"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Article
Title
Author
Pages
HyperLink
HyperLink
(Title, Author+, Pages, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
1
Template−Klasse : "DetailsOfArticle"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Details
Abstract
Keyword
URLFullText
(Abstract?, Keyword*, URLFullText)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Abbildung 4.5: Web-Site-Schema der ACM Digital Library
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Abbildung 4.6: Browser-Darstellung einer Instanz von ’Publications’
Abbildung 4.7: Browser-Darstellung einer Instanz von ’PublicationDetails’
38
KAPITEL 4. WEB-SITES ALS DATENBANKEN
4.1.3
39
Entwicklung des konzeptionellen Schemas
Im Anschluß an die Definition des Web-Site-Schemas erfolgt die Erstellung des konzeptionellen Schemas des WSDBS, basierend auf dem hierarchischen Datenmodell.
Dabei werden Container-Elemente als Record-Typen definiert, sowie die DatenElemente innerhalb eines Containers als entsprechende Attribute dieses RecordTyps. Die Elemente HYPERLINK werden als Referenzen auf die entsprechenden
Child-Record-Typen interpretiert und stellen somit keine Attribute der jeweiligen
Record-Typen dar.
Ein anderer Fall ergibt sich, wenn innerhalb von Container-Elementen das mehrfache Auftreten von Daten-Elementen erlaubt wird. So kann das in der TemplateKlasse ’TableOfContents’ deklarierte Element ARTICLE mehrere Daten-Elemente
des in derselben Klasse liegenden Typs AUTHOR enthalten. In dem hierarchischen
Datenmodell ist die Existenz mehrwertiger Attribute jedoch nicht erlaubt. Aus diesem Grund müssen Klassen, in denen solche Konstruktionen auftreten, durch mehrere Record-Typen definiert werden. Im folgenden wird der Aufbau des konzeptionellen Schemas des WSDBS für die ACM Digital Library, basierend auf dem im
vorhergehenden Abschnitt definierten Web-Site-Schema, detailliert erläutert.
Die Elemente PUBLICATIONTYPE, PUBLICATION, PUBDETAILS, VOLUME und ISSUE
werden direkt auf die entsprechenden Record-Typen abgebildet, da kein mehrfaches
Auftreten von Daten-Elementen innerhalb dieser Container definiert ist. Bei der
Abbildung von Elementen auf einen Record-Typ erfolgen gewisse Modifikationen.
Zum einen werden die Record-Typen mit kompakteren Namen bezeichnet, um die
spätere Handhabung der Datenbank zu erleichtern. Zum anderen werden den DatenElementen konkrete Daten-Typen wie z.B String, Integer etc. zugeordnet. Mit diesen
Überlegungen lassen sich die erwähnten Elemente wie folgt als Record-Typen gemäß
dem hierarchischen Modell definieren:
PubType(TypeName:String)
Publication(PubName:String)
PubDetails(ISSN:Integer, Description:String, CurIssue:String)
PubVolume(Volume:Integer)
PubIssue(Issue:Integer)
Einen besonderen Fall stellt das Element DIGITALLIBRARY dar, da es keine DatenElemente definiert. Es bildet die oberste Hierarchieebene und wird im konzeptionellen Schema als Root-Record der Datenbank verwendet.
DigitalLibrary()
Die Container-Elemente ARTICLE und DETAILS müssen aufgrund der im Vorfeld
getätigten Überlegungen durch mehrere Record-Typen modelliert werden. In der
Klasse ’TableOfContents’ beispielsweise kann das Container-Element ARTICLE mehrere Elemente des Typs AUTHOR enthalten. Es bietet sich demnach an, jeweils einen
eigenen Record-Typ für ARTICLE bzw. AUTHOR zu definieren. Die restlichen Elemente lassen sich auf die gleiche Weise durch unterschiedliche Record-Typen modellieren. Daraus ergibt sich:
Article(Title:String, Pages:String)
Author(Name:String)
Details(Abstract:String, URLFullText:URL)
Keywords(Word:String)
In Abbildung 4.8 ist das Schema-Diagramm des oben angegebenen konzeptionellen
Schemas der ACM Digital Library zu sehen. Dabei sind die zu einer TemplateKlasse gehörenden Record-Typen durch einen gemeinsamen grauen Hintergrund
zusammengefaßt.
40
KAPITEL 4. WEB-SITES ALS DATENBANKEN
DigitalLibrary
PubType
TypeName
Publication
PubName
1
PubDetails
Description
ISSN
CurIssue
PubVolume
Volume
PubIssue
Year
Issue
Month
Article
Title
1
Details
Abstract
URLFullText
Pages
Author
Name
Keyword
Word
Abbildung 4.8: Konzeptionelles Schema des ACM Digital Library Web-Site
4.1.4
Aufgaben des Web-Site Managementsystems
In Abschnitt 2.1.3 wurden die Aufgaben bestehender DBMSe beschrieben. Nicht
alle diese Anforderungen müssen bei der Entwicklung des WSMS berücksichtigt
werden, da einerseits nur der lesende Zugriff auf einen Web-Site möglich ist, andererseits bestimmte Aufgaben dem jeweiligen Betreiber des Site obliegen. Unter
Berücksichtigung dieser Einschränkungen müssen folgende Funktionen vom WSMS
zur Verfügung gestellt werden.
Integration
Um dem Benutzer eine transparente Sicht auf den Datenbestand zu ermöglichen,
müssen die für die Anwendung relevanten Daten des Web-Site in einer einheitlichen Form dargestellt werden. Dies geschieht durch die Transformation der HTMLbasierten Dokumente in Segmente, die die dem konzeptionellen Schema entsprechenden Datensätze enthalten.
Operationen
Der Benutzer muß die Möglichkeit besitzen, strukturiert nach Informationen innerhalb des Web-Site zu suchen. D.h., daß das WSMS bestimmte Operationen bereitstellen muß, mit deren Hilfe verschiedene Anfragen an die Datenbank“ gerichtet
”
werden können. In Abhängigkeit spezieller Suchkriterien werden dann die entsprechenen Daten als Anfrageergebnis ausgegeben. Zu diesem Zweck wird die Web-Site
Query Language (WS/QL) vom WSMS zur Verfügung gestellt, auf die innerhalb
des Abschnitts über die Implementierung eines WSDBS näher eingegangen wird.
41
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Obwohl auch eine Implementierung von Benutzersichten und die Bereitstellung eines Katalogs durch das WSMS ermöglicht werden könnte, wird aufgrund der Tatsache, daß nur der Föderierungsdienst auf die Daten zugreift und i.a. nicht einzelne
Benutzer, in diesem Zusammenhang darauf verzichtet.
4.2
Data Retrieval System
Die Struktur der im Rahmen dieser Arbeit betrachteten Web-Sites läßt sich, wie im
vorhergehenden Abschnitt gezeigt, durch eine Menge von hierarchisch angeordneten
Template-Klassen beschreiben. Dabei werden alle Instanzen einer Klasse mit Hilfe
einer vordefinierten HTML-Schablone generiert. Das heißt, daß Datenbankinhalte
entsprechend einer Benutzeranforderung in die jeweils zugrunde liegende Schablone integriert werden, und dadurch das gewünschte HTML-Dokument erzeugt wird.
Ist der HTML-Code der Schablone bekannt, lassen sich einfache Regeln in Form
von regulären Ausdrücken definieren, um die integrierten Daten zu extrahieren. Im
allgemeinen steht der Code der verwendeten Schablone jedoch nicht explizit zur
Verfügung, sondern muß anhand des Quelltextes einer Dokumentinstanz ermittelt
werden. Dies kann besonders bei umfangreichen Dokumenten eine aufwendige und
zudem fehleranfällige Aufgabe darstellen. Aus diesem Grund ist im Rahmen dieser
Arbeit ein Datengewinnungssystem (Data Retrieval System, DRS) entwickelt worden, das mit Hilfe von strukturerhaltenen Quelltext-Transformationen und einfach
zu definierenden Regeln die Extraktion relevanter Informationen aus den entsprechenden HTML-Dokumenten ermöglicht.
XML Datei
Template−Klasse
Crib−Datei
XML Generator
Extraktionssystem
Extractor
Gruppierung
Filtersystem
Konfigurationsdatei
Reduktion
HTML−Dokument
Abbildung 4.9: Data Retrieval System
Der prinzipielle Aufbau des DRS ist in Abb. 4.9 dargestellt. Wie zu erkennen,
besteht das System aus zwei Software-Modulen. Das erste Modul (Filtersystem)
transformiert eine Dokumentinstanz durch eine Reihe von Reduktions- und Simplifikationsschritten in eine vereinfachte Darstellung, die im weiteren Verlauf als
Dokumentgerüst bezeichnet wird. Zu erwähnen ist in diesem Zusammenhang die
Tatsache, daß bei der Umformung sämtliche relevanten Informationen unverändert
erhalten bleiben. Welche Reduktionen bzw. Simplifikationen zum Einsatz kommen,
KAPITEL 4. WEB-SITES ALS DATENBANKEN
42
wird in einer speziellen Konfigurationsdatei festgelegt. Es sei darauf hingewiesen,
daß hierbei jede Template-Klasse eine individuelle Konfigurationsdatei nutzen kann.
Das zweite Modul (Extraktionssystem) ist für die Datengewinnung verantwortlich.
Dazu werden verschiedene Regeln definiert, die auf dem Dokumentgerüst basieren
und somit relativ leicht zu formulieren sind. Die Regeln orientieren sich an der
Struktur der entsprechenden Template-Klasse und werden in einer Crib-Datei zusammengefaßt. Die gewonnenen Daten werden an der Schnittstelle des DRS in Form
einer XML-Datei zur Verfügung gestellt. Die Struktur dieser Datei wird durch die
jeweilige Template-Klasse bestimmt.
4.2.1
Filtersystem
Das Filtersystem des DRS besteht konzeptionell aus zwei verschiedenen Stufen, die
bei der Implementierung unter dem Gesichtspunkt der Leistungssteigerung in einem einzelnen Filter integriert sind. Die weiteren Ausführungen basieren auf dem
konzeptionellen Modell, um ein besseres Verständnis der jeweiligen Aufgaben und
Möglichkeiten zu vermitteln. Die erste Stufe ist für die Reduktion des HTML-Codes
des Dokuments verantwortlich, während die zweite Stufe die Elemente des reduzierten Dokuments in bestimmten Gruppen zusammenfaßt und dadurch eine vereinfachte Darstellung des Dokuments ermöglicht. Während das Dokument nach der
Reduktion noch in jedem Browser darstellbar ist, kann das Dokument nach den
Simplifikationen nicht mehr dargestellt werden. Dies ist jedoch nicht von Bedeutung, da einzig und allein wichtig ist, daß das Dokument vom Extraktionssystem
korrekt interpretiert werden kann.
4.2.1.1
Reduktion des Dokuments
Aufgabe der ersten Filterstufe ist die Reduktion der HTML-Dokumente, die im professionellen Bereich häufig sehr umfangreich gestaltet sind und nicht selten aus mehr
als 5000 Zeilen HTML-Code bestehen. Diese Reduktion erfolgt durch die Elimination unterschiedlicher Objekte, die für die Extraktion der benötigten Informationen
nicht benötigt werden. In der Terminologie des DRS werden mit dem Begriff Objekt
unterschiedliche Konstrukte eines auf HTML basierenden Dokuments bezeichnet.
Dies sind Elemente, Attribute, Kommentare, Sonderzeichen sowie EndTags. Welche
Objekte vom System gelöscht werden sollen, wird durch eine Konfigurationsdatei,
die dem Filter bei Ausführung übergeben wird, spezifiziert. Das DRS stellt verschiedene vordefinierte Konfigurationsdateien zur Verfügung, um eine gewisse Flexibilität bei der Bearbeitung von Dokumenten unterschiedlicher Template-Klassen
zu gewährleisten und den Benutzer von aufwendigen administrativen Aufgaben zu
entbinden. Gleichzeitig besteht selbstverständlich auch die Möglichkeit, individuelle
Konfigurationen zu erstellen. Im folgenden werden die verschiedenen Objekte mit
ihrem jeweiligen Eliminationspotential beschrieben.
Elemente
Innerhalb der Reduktionsphase ist es möglich, betimmte Elemente vollständig aus
einem HTML-Dokument zu entfernen. Das bedeutet, daß der gesamte Code zwischen StartTag und EndTag eines Elements gelöscht wird. Die entsprechenden Tags
werden in diesem Zusammenhang ebenfalls entfernt. Da HTML minimalisiertes
Markup unterstützt, ist es nur erschwert möglich, Elemente zu eliminieren, die ein
optionales EndTag besitzen. Im Gegensatz dazu können leere Elemente, die überhaupt kein abschliessendes Tag besitzen, ohne Einschränkungen entfernt werden.
Elemente, die für die Strukturierung von Informationen in HTML-Dokumenten digitaler Bibliotheken nicht zwingend benötigt werden, sind beispielsweise Applets,
KAPITEL 4. WEB-SITES ALS DATENBANKEN
43
Formulare, Skripte, Images oder ähnliche Objekte.
Kommentare
Ist die eindeutige Identifikation benötigter Informationen eines HTML-Dokuments
nicht bzw. nur erschwert möglich, können die im entsprechenden Dokument existierenden Kommentare zur Extraktion herangezogen werden. Aus Gründen der
Stabilität des DRS gegenüber textuellen Änderungen sollte von dieser Möglichkeit
allerdings nur in Ausnahmefällen Gebrauch gemacht werden. In der Regel wird die
Elimination dieser Objekte empfohlen, da sie für die Datengewinnung im Normalfall
keine Rolle spielen.
Sonderzeichen
Designer von HTML-Dokumenten benutzen häufig Sonderzeichen, um das Layout
einer Web-Page zu verbessern. Diese Zeichen haben in den meisten Fällen keinen informativen Charakter und sollten somit aus dem Dokument entfernt werden. Wird
das Entfernen von diesen Objekten durch die Konfigurationsdatei gestattet, werden
alle Textsegmente, die ausschließlich aus Sonderzeichen bestehen, aus dem Dokument gelöscht.
Attribute
Die meisten Attribute von HTML-Elementen werden bei der Informationsgewinnung nicht benötigt, da sie häufig zu Präsentationszwecken verwendet werden oder
die Interaktion mit dem Web-Site unterstützen. Zwingend erforderlich ist in den
meisten Fällen nur das Attribut HREF des ’Anchor’-Elements, das die URL eines
Verweises enthält. Andere Attribute, wie z.B. CLASS, NAME oder ID, können ähnlich wie Kommentare zur eindeutigen Identifikation von Informationen herangezogen werden. In der Konfigurationsdatei des DRS werden alle Attribute, die nicht
gelöscht werden sollen, aufgeführt. Die restlichen werden aus dem HTML-Code entfernt.
End-Tags
Wie schon mehrfach erwähnt, unterstützt HTML minimalisiertes Markup. D.h., die
Angabe des EndTag ist bei einigen Elementen optional. Bei der maschinellen Erstellung von HTML-Dokumenten werden in der Regel auch optionale EndTags in
den HTML-Code integriert. In diesem Fall sollten die entsprechenden Tags in Hinblick auf die Erkennung von Informationsstrukturen im Dokument erhalten bleiben. Manchmal wird allerdings minimalisiertes Markup genutzt, beispielsweise bei
vielen handgeschriebenen HTML-Dokumenten. In solchen Fällen sollten optionale
EndTags gelöscht werden, um Probleme bei der Identifizierung von Informationen
zu vermeiden.
Abschließend sei noch einmal darauf hingewiesen, daß sämtliche zu löschenden Objekte in einer Konfigurationsdatei spezifiziert werden. Die obigen Ausführungen stellen lediglich Empfehlungen dar und können jederzeit den individuellen Bedürfnissen
angepaßt werden. Ziel der ersten Filterstufe ist einzig und allein eine Reduktion von
HTML-Code, um die Struktur von inhärenten Informationen besser erkennen und
diese somit leichter extrahieren zu können.
4.2.1.2
Gruppierung der Elemente
Während der zweiten Phase des Filtersystems erfolgt eine Gruppierung von HTMLElementen. Auch diese Einteilung von Elementen in unterschiedliche und disjunkte
Gruppen erfolgt in der Konfigurationsdatei des Filtersystems. Neben den bereits
erwähnten vorgefertigten Dateien des DRS, können wiederum individuelle Konfigurationen erstellt werden. Dabei erfolgt zuerst die Definition der verschiedenen
Gruppen und im Anschluß daran die Zuordnung der Elemente zu genau einer dieser Gruppen. Die Konfigurationsdateien des DRS basieren alle auf der durch die
44
KAPITEL 4. WEB-SITES ALS DATENBANKEN
HTML−Document
TopLevelElements
HeadElements
BodyElements
FrameElements
StandardElements
BlockLevelElements
GenericBlockElem.
TableElements
FormElements
ListElements
HeadingsEtc
InlineElements
PhraseElements
FontStyleElements
SpecialInlineElem.
Abbildung 4.10: HTML-Element-Klassifikation
KAPITEL 4. WEB-SITES ALS DATENBANKEN
45
Abbildung 4.11: Dokumentinstanz der ACM Digital Library
HTML-Spezifikation implizit gegebenen Gruppierung von Elementen, die in Abb.
4.10 dargestellt ist.
Ziel der Gruppierung ist einerseits wiederum das Erkennen der Dokumentstruktur,
um die Definition von Regeln zur Informationsgewinnung zu erleichtern. Andererseits soll dadurch die Stabilität des Extraktionsprozesses erhöht werden. Wird ein
Element innerhalb der HTML-Schablone durch ein anderes der gleichen Gruppe
ersetzt, wird die Funktionalität des DRS in keiner Weise eingeschränkt. Schließlich
werden noch redundante StartTags gleicher Gruppen sowie Elemente, die aufgrund
vorausgegangener Eliminationen keinen Inhalt mehr besitzen, gelöscht.
Zusammenfassend läßt sich sagen, daß durch die Reduktion eines HTML-Dokuments
mit Hilfe des Filtersystems eine surjektive, strukturerhaltene Abbildung realisiert
wird. Auf der Basis dieser Struktur können Regeln gebildet werden, mit denen
das Extraktionssystem die benötigten Informationen in einem HTML-Dokument
identifizieren kann. In der aktuellen Version des DRS erfolgt die Erstellung dieser
Regeln ’per Hand’. Es besteht jedoch die Möglichkeit, diese Regeln automatisch zu
generieren.
In Abb. 4.11 ist eine, von einem Browser interpretierte, Dokumentinstanz der
Template-Klasse ’TableOfContents’ des Web-Site der ACM Digital Library dargestellt. Der Quelltext dieses Dokuments besteht aus etwa 1000 Zeilen HTML-Code
und hat einen Umfang von knapp 20 kB. Nach der Überschrift ’Table of Contents’
sind die für das ZIS relevanten Daten zu finden, die entsprechend der Template-
46
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Name of the Group
Signature
Elements
AnchorElements
ACE
A
TopLevelElements
TLE
BODY
HEAD
HeadElements
HEL
BASE
META
ISINDEX
STYLE
GenericBlockLevelElements
GBE
ADDRESS
BLOCKQUOTE
H1
H2
H3
H4
H5
NOSCRIPT
P
PRE
ListElements
LST
DD
OL
TableElements
TAB
CAPTION
COL COLGROUP TABLE
TBODY TD TFOOT TH THEAD TR
FormElements
FRM
BUTTON
FIELDSET FORM
INPUT
LABEL LEGEND
OPTGROUP
OPTION
TEXTAREA SELECT
SpecialInlineElements
SIE
APPLET AREA BASEFONT
BDO
BR
FONT IFRAME
IMG
PARAM
MAP
OBJECT
Q
SCRIPT
SPAN
SUB
SUP
FontStyleElements
FSE
B
PhraseElements
PHE
ABBR
ACRONYM
CITE CODE
DFN
EM INS KBD
SAMP
STRONG
VAR
FrameElements
FRA
FRAME
DIR
UL
BIG
DL
I
S
HTML
LINK
TITLE
DT
LI
SMALL
FRAMESET
DIV
CENTER
H6
HR
MENU
STRIKE
TT
U
DEL
NOFRAMES
Abbildung 4.12: Gruppierung der HTML-Elemente
Klasse ’TableOfContents’ strukturiert sind. Alle davor angeordneten Informationen
werden vom ZIS nicht benötigt.
Um die Wirkungsweise und Fähigkeiten des Filtersystems zu verdeutlichen, soll die
Transformation des vorgestellten Dokuments beispielhaft aufgezeigt werden. Die
Gruppierung der Elemente ist in Abb. 4.12 zu erkennen. Zu löschende Elemente sind dabei durchgestrichen dargestellt. Kommentare sowie Sonderzeichen sollen
gelöscht werden. Von den Attributen werden nur NAME, HREF und ID in das Dokumentgerüst übernommen. Basierend auf dieser Konfiguration, ergibt sich die in
Abb. 4.13 dargestellte Datei. Die Elemente sind dabei durch entsprechende StartTags [++...] und EndTags [—...] gekennzeichnet, wobei in diesem Zusammenhang
minimalisiertes Markup genutzt wird. In der Abbildung läßt sich die Struktur des
Dokuments deutlich erkennen. Aus Gründen der Übersichtlichkeit wurden die originären Daten entweder durch ihre Elementnamen (TITLE, AUTHOR+, ...) dargestellt, sofern es sich um für das ZIS relevante Informationen handelt, sonst einfach
durch #PCDATA bzw. #DATA bei Attributen. Es sei darauf hingewiesen, daß die
Zeilennummern nicht Bestandteil des originären Dokuments sind. Die gestrichelten
bzw. gepunkteten Linien sind lediglich zur besseren Überschaubarkeit in das Dokument eingefügt worden und müssen bei der Definition von Extraktionsregeln nicht
beachtet werden.
KAPITEL 4. WEB-SITES ALS DATENBANKEN
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
[++TLE]
[++HEL]
[++TLE]
[++GBE]
[++ACE]
[++TAB]
[++ACE]
[++TAB]
[++ACE]
[++TAB]
[++ACE]
[++TAB]
[++ACE]
[++TAB]
[++ACE]
[++TAB]
[++SIE]
[++TAB]
[++SIE]
[++TAB]
[++GBE]
[++TAB]
[++SIE]
[++ACE]
[++SIE]
[++SIE]
[++TAB]
[++SIE]
[++TAB]
[++GBE]
[++TAB]
[++ACE]
[++SIE]
[++SIE]
[++FSE]
[++ACE]
[++TAB]
[++ACE]
[++SIE]
[++SIE]
[++FSE]
[++ACE]
[++TAB]
[++ACE]
[++SIE]
[++SIE]
[++FSE]
[++ACE]
[++TAB]
[++ACE]
[++GBE]
[++SIE]
47
.......................................................
#PCDATA [--HEL]
.......................................................
=======================================================
($name #data) [--ACE]
.......................................................
($href #data) [--ACE]
.......................................................
($href #data) [++SIE] #PCDATA [--ACE]
.......................................................
($href #data) [++SIE] #PCDATA [--ACE]
.......................................................
($href #data) [++SIE] #PCDATA [--ACE]
.......................................................
($href #data) [++SIE] #PCDATA [--ACE]
.......................................................
#PCDATA [--SIE]
.......................................................
#PCDATA [--SIE]
.......................................................
=======================================================
.......................................................
[++ACE] ($href #data) #PCDATA [--ACE] [--SIE]
($href #data) [++SIE] #PCDATA [--ACE]
#PCDATA
.......................................................
#PCDATA [--SIE]
.......................................................
=======================================================
.......................................................
($href #HYPERLINK) [++PHE] #TITLE [--PHE] [--ACE]
#AUTHOR+
#PAGES [--FSE]
($href #data) [++SIE] #PCDATA [--ACE]
.......................................................
($href #HYPERLINK) [++PHE] #TITLE [--PHE] [--ACE]
#AUTHOR+
#PAGES [--FSE]
($href #data) [++SIE] #PCDATA [--ACE]
.......................................................
($href #HYPERLINK) [++PHE] #TITLE [--PHE] [--ACE]
#AUTHOR+
#PAGES [--FSE]
($href #data) [++SIE] #PCDATA [--ACE]
.......................................................
($href #data) [--ACE]
=======================================================
Abbildung 4.13: Dokumentgerüst
KAPITEL 4. WEB-SITES ALS DATENBANKEN
4.2.2
48
Extraktionssystem
Ähnlich wie das Filtersystem besteht das Extraktionssystem aus zwei logischen
Stufen, die allerdings bei der Implementierung zusammengefaßt worden sind. Die
erste Stufe ist für die Extraktion der durch die Template-Klasse definierten Daten
zuständig, während die zweite Stufe aus diesen Daten entsprechend der Struktur
der Template-Klasse eine XML-Datei generiert. Im folgenden sollen die Funktionen der einzelnen Stufen näher beschrieben werden. Alle in diesem Zusammenhang
verwendeten Beispiele beziehen sich auf das im vorhergehenden Abschnitt gezeigte
Dokumentgerüst der Instanz einer Template-Klasse der ACM Digital Library.
4.2.2.1
Extraktion relevanter Informationen
Die Extraktion der relevanten Daten des Dokumentgerüsts verläuft in Anlehnung
an die in [MMK99] vorgestellten Konzepte zur Informationsgewinnung aus allgemeinen HTML-Dokumenten. Dabei beziehen sich die entsprechenden Funktionen
in [MMK99] auf originäre HTML-Texte und nicht auf die durch das Filtersystem
erzeugten Gerüste. Trotzdem lassen sich die Konzepte auf die im Rahmen dieser Arbeit verwendeten Dokumentgerüste transformieren, da es sich bei diesen ebenfalls,
ähnlich zu SGML, um mit Markup versehene Dokumente handelt.
Jedes Dokumentgerüst besteht aus einer Menge von Token. Bei einem Token kann
es sich in diesem Zusammenhang um ein Tag, eine Zeichenkette, um ein einzelnes
Zeichen, einen numerischen Ausdruck oder ähnliches handeln. Eine Gruppe aufeinanderfolgender Token wird innerhalb des DRS als Crib, also eine Art Anhaltspunkt
bezeichnet 2 . Um die zu extrahierenden Informationen innerhalb des Dokumentgerüsts zu identifizieren, wird nun jedem der in der Template-Klasse definierten
Elemente ein StartCrib und ein EndCrib zugeordnet. Mit Hilfe dieser Cribs können
dann die benötigten Daten aus dem Dokumentgerüst extrahiert werden. In dem in
Abb. 4.13 dargestellten Gerüst könnten beipielsweise [++PHE] als StartCrib und
[—PHE] als EndCrib des Elements TITLE definiert werden.
Um die korrekte Extraktion der Daten zu ermöglichen, müssen bei der Definition
von Cribs bestimmte Konventionen eingehalten werden. Zum einen ist es erforderlich, daß die StartCribs von Elementen, die in der gleichen Umgebung definiert sind,
unterschieden werden können, d.h. sie müssen eindeutig sein. Die Umgebung bezieht
sich hierbei auf die hierarchische Anordnung der in der DTD enthaltenen Elemente
(Elemente, die einen gemeinsamen Parent besitzen, liegen in der gleichen Umgebung). Die Elemente TITLE und PAGES beispielsweise liegen in der durch ARTICLE
definierten Umgebung. EndCribs dagegen müssen keine Eindeutigkeit aufweisen,
da bei der Extraktion aus dem Kontext hervorgeht, welchen Elementen sie zugeordnet sind. Gleichzeitig kann jeder EndCrib wiederum als StartCrib eines anderen
oder auch des gleichen Elements fungieren. In Abb. 4.14 sind Crib-Definitionen des
im Vorfeld beschriebenen Dokumentgerüsts dargestellt. Dabei wurde die TemplateKlasse um das zusätzliche Element BLOCK ergänzt. Dieses, nur bei der Extraktion
benötigte Element, dient als Container für alle ARTICLE Elemente. Dadurch kann
der Extraktionsvorgang auf den Teil des Dokumentgerüsts eingeschränkt werden
werden, in dem die relevanten Informationen enthalten sind.
Sind die Cribs entsprechend den vorgestellten Konventionen definiert worden, können die relevanten Informationen mit Hilfe eines Scanners, der das Dokumentgerüst sequentiell durchläuft, extrahiert werden. In diesem Zusammenhang ist zu
2 Der Begriff Crib wurde bei der Enigma-Dechiffrierung von den englischen Kryptonanalytikern
aus Bletchley Park, zu denen auch Alan Turing gehörte, verwendet.
(vgl. Simon Singh, Geheime Botschaften, Carl Hanser Verlag 1999)
49
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Element
StartCrib
EndCrib
Rule
Block
[++GBE] [++TAB] [++ACE]
[++GBE]
R1
R2
Article
[++TAB] [++ACE] ($href #data) [++PHE]
[++TAB]
R3
R4
Title
[++PHE]
[−−PHE]
R5
R6
Author+
[−−ACE] [++SIE]
[++SIE]
R7
R8
Pages
[++FSE]
[−−FSE]
R9
R10
HyperLink
[++TAB] [++ACE] ($href
[++PHE]
R11
R12
Abbildung 4.14: Crib-Definitionen für die Klasse ’TableOfContents’
erwähnen, daß bei der erfolgreichen Identifikation eines Crib der Scanvorgang an
dessen Anfang fortgesetzt wird. Dieser Umstand scheint auf den ersten Blick ziemlich sinnlos, da der Scanner nach dem ersten gefundenen Crib in eine Endlosschleife
zu geraten scheint. Dies ist jedoch nicht der Fall, da sich der Scanner zu jedem
Zeitpunkt des Durchlaufs in einem eindeutigen Zustand befindet. Wird ein Crib erfolgreich identifiziert, ändert sich infolge dessen auch der Zustand des Scanners. Ein
Beispiel soll diesen Zusammenhang verdeutlichen. Zu Beginn des Vorgangs sucht
der Scanner nach dem StartCrib des obersten Elements der (durch die DTD der
Template-Klasse definierten) Hierachiebene. Innnerhalb der betrachten TemplateKlasse handelt es sich dabei um das im nachhinein ergänzte Elemente BLOCK. Wird
das StartCrib dieses Elements vom Extraktionssystem identifiziert, ändert sich der
Zustand des Scanners dahingehend, daß sich das System nun in einer anderen Umgebung befindet und demzufolge die Tokenfolge des StartCrib von BLOCK anders
interpretiert wird. Das Zustandsdiagramm des Scanners für das in diesem Zusammenhang verwendete Beispiel ist in Abb. 4.15 dargestellt.
4.2.2.2
Generierung einer XML-Datei
Die extrahierten Informationen werden als XML-Datei an der Schnittstelle des DRS
zur Verfügung gestellt. Die Struktur dieser Datei wird dabei durch die zugrunde
liegende Template-Klasse bestimmt. Zusätzlich werden bei der Generierung mehrwertige Elemente, wie z.B. AUTHOR+, in atomare Einheiten zerlegt. In Abb. 4.16
ist die aus dem im Vorfeld beschriebenen Beispiel generierte XML-Datei dargestellt.
Dabei wird allerdings nur die Dokumentinstanz berücksichtigt, und die zugehörige
DTD nicht mit aufgeführt.
50
KAPITEL 4. WEB-SITES ALS DATENBANKEN
other
S3
other
R5
other
R1
S0
R6
other
R8
R3
S1
R4
S2
R9
R10
R12
R2
S7
S4
R7
other
S5
R11
S6
other
S0
S1
S2
S3
Anfangszustand
Block
Article
Title
S4
S5
S6
S7
Author+
Pages
HyperLink
Endzustand
Abbildung 4.15: Zustandsdiagramm des Scanners für die Klasse ’TableOfContents’
KAPITEL 4. WEB-SITES ALS DATENBANKEN
<Article>
<Title>
Logical models of argument
</Title>
<Author>
Carlos Ivan Chesnevar
</Author>
<Author>
Ana Gabriela Maguitman
</Author>
<Author>
Ronald Prescott Loui
</Author>
<Pages>
337-383
</Pages>
<HyperLink
Template-Klasse="DetailsOfArticle"
URL="...">
</Article>
<Article>
<Title>
Extracting usability information from user interface events
</Title>
<Author>
David M. Hilbert
</Author>
<Author>
David F. Redmiles
</Author>
<Pages>
384-421
</Pages>
<HyperLink
Template-Klasse="DetailsOfArticle"
URL="...">
</Article>
<Article>
<Title>
The state of the art in distributed query processing
</Title>
<Author>
Donald Kossmann
</Author>
<HyperLink
Template-Klasse="DetailsOfArticle"
URL="...">
</Article>
Abbildung 4.16: XML-Datei
51
KAPITEL 4. WEB-SITES ALS DATENBANKEN
4.3
52
Implementierung des Web-Site DBS
Der folgende Abschnitt beschreibt die der Implementierung des WSDBS zugrunde liegenden Konzepte. Hierbei wird zunächst eine Beispieldatenbank vorgestellt,
anhand derer die Konzepte im weiteren Verlauf verdeutlicht werden sollen. Darauf
folgend wird die 3-Schichten-Architektur des WSDBS beschrieben und im Anschluß
daran die Funktionsweise der Anfragesprache WS/QL erläutert. Schließlich werden
die einzelnen Schnittstellen sowie die sie realisierenden Schichten besprochen.
4.3.1
Beispieldatenbank
Anhand einfacher Beispiele sollen die bei der Implementierung des WSDBS verwendeten Konzepte verdeutlicht werden. Um eine einheitliche Betrachtungsweise
zu ermöglichen, basieren diese Beispiele alle auf einem einfachen Web-Site, der die
hierarchischen Strukturen der Bundesliga beschreibt und die imaginäre Adresse
www.example.liga.de besitzt.
Auf der Homepage (www.example.liga.de/index.html ) sind die der Liga angehörenden Vereine aufgeführt. Jeder dieser Vereine besteht aus einem oder mehreren Trainern, einer Menge von Spielern und spielt in einem(!) eigenen Stadion. Ein Spieler
wiederum kann auf verschiedenen Positionen eingesetzt werden. Der Web-Site besitzt das in Abb. 4.17 dargestellte Schema.
Template−Klasse : "Bundesliga"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Bundesliga (Verein+)>
(VName, HyperLink, HyperLink, Stadion)>
Verein
(#PCDATA)>
Vname
(SName, Kapazität)>
Stadion
(#PCDATA)>
SName
(#PCDATA)>
Kapzität
HyperLink
EMPTY>
HyperLink
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "Trainer"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Trainer
Vorname
Name
Alter
(Vorname, Name, Alter?)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Template−Klasse : "Mannschaft"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Spieler
Vorname
Name
Alter
Position
(Vorname, Name, Alter, Position+)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Abbildung 4.17: Schema des Bundesliga Web-Site
53
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Aus dem Web-Site-Schema kann nun das konzeptionelle Schema des WSDBS entwickelt werden. Dabei werden Container-Elemente durch entsprechende RecordTypen dargestellt, während die Daten-Elemente die Atrribute der jeweiligen Typen
beschreiben. Besitzt jedoch ein Container-Element ein mehrfaches Daten-Element,
wie in diesem Beispiel SPIELER das Element POSITION, so muß dieser Zusammenhang durch mehrere Record-Typen modelliert werden, da mehrwertige Attribute
nicht Bestandteil des hierarchischen Datenmodells sind. Das konzeptionelle Schema
des Bundesliga Web-Site wird in Abb. 4.18 gezeigt.
Bundesliga
Verein
Name
Vorname
Trainer
Name
1
Stadion
Name
Kapazität
Alter
Vorname
Spieler
Name
Alter
Position
PosName
Abbildung 4.18: Konzeptionelles Schema des Bundesliga Web-Site
4.3.2
Die 3-Schichten-Architektur des Web-Site DBS
In Abschnitt 2.1.4 wurde die Fünf-Schichten-Architektur als allgemeine Grundlage
für die Implementierung von DBSen vorgestellt. Auf dieser Architektur basierend
erfolgt die Entwicklung des WSDBS. Dabei werden zum einen die Aufgaben des Betriebssystems mit der dazugehörigen Dateischnittstelle vom Data Retrieval System
übernommen, das allerdings nicht zum WSDBS gehört, sondern nur eine XMLorientierte Schnittstelle für die Kommunikation mit dem WSDBS zur Verfügung
stellt. WSDBS und DRS sind jedoch nicht vollständig voneinander unabhängig, da
beide die gleiche Template-Tabelle beinhalten müssen, um eine fehlerfreie Kommunikation zu gewährleisten. Zum anderen dient die satzorientierte Schnittstelle
in hierarchischen DBSen als Anwendungsprogrammierschnittstelle [HR99], so daß
das Datensystem und die mengenorientierte Schnittstelle bei der Implementierung
des WSDBS keine Berücksichtigung finden. Ausgehend von diesen Überlegungen
liegt der Implementierung des WSDBS die in Abb. 4.19 dargestellte 3-SchichtenArchitektur zugrunde.
Das Data Retrieval System extrahiert die relevanten Informationen der Dokumente
eines Web-Site und generiert aus den jeweiligen Daten ein XML-Dokument, das an
der XML-orientierten Schnittstelle für das WSDBS bereitgestellt wird. Das Puffersystem hat zwei Aufgaben zu erfüllen. Die erste besteht darin, die Daten eines
XML-Dokuments in formatierte Datensätze zu überführen und diese auf ein oder
mehrere Segmente abzubilden. An der Pufferschnittstelle stellt sich die Datenbank
dann als Ganzes in Form einer Menge von Segementen dar. Aufgrund der Tatsache, daß jedoch nur ein Teil dieser Menge temporär im Puffersystem gehalten wird,
54
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Benutzer/
Anwendung
Satzorientierte Schnittstelle
Zugriffssystem
Web−Site DBS
Interne Satzschnittstelle
Speichersystem
Pufferschnittstelle
Puffersystem
XML−orientierte Schnittstelle
DRS
Web−Site Schnittstelle
Web−Site
Abbildung 4.19: 3-Schichten-Architektur des WSDBS
müssen bei Bedarf neue Segemente generiert bzw. vorhandene gelöscht werden. Somit liegt die zweite Aufgabe des Puffersystems in der Bereitstellung angeforderter
Segmente. Die interne Satzschnittstelle bietet eine monolithische Sicht auf den Datenbestand. Der übergeordneten Schicht wird somit ein einheitlicher Zugriff auf die
Datenbank zur Verfügung gestellt, ohne daß Kenntnisse darüber existieren müssen,
in welchen Segementen die entsprechenden Datensätze tatsächlich zu finden sind.
Die korrekte Abbildung der Gesamtmenge von Datensätzen auf die jeweiligen Segmente wird dabei vom Speichersystem übernommen. Die Kommunikation mit der
’Außenwelt’ wird schließlich durch die satzorientierte Schnittstelle realisiert. Dabei
wird mit WS/QL eine einfache Anfragesprache zur Verfügung gestellt, die es dem
Benutzer bzw. einer Anwendung erlaubt, einzelne Datensätze aus der Datenbank
zu extrahieren.
4.3.3
Die Anfragesprache WS/QL
Der Zugriff auf die Datenbank erfolgt durch die Anfragesprache WS/QL (WebSite Query Language), die auf den Konzepten der für das IMS-System von IBM
entwickelten Sprache DL/I basiert und die an der satzorientierten Schnittstelle zur
Verfügung gestellten Datenstrukturen und Operationen vereint. Jede Operation in
WS/QL liefert als Ergebnis maximal ein Record des entsprechenen Typs. Somit
gehört WS/QL zu den sogenannten record-at-a-time Sprachen. Aus diesem Grund
werden die Operationen in eine Wirtssprache (host language) eingebettet, so daß
Anfragen, die als Ergebnis beliebig viele Records eines bestimmten Typs liefern,
generiert werden können. In den folgenden Beispielen wird JAVA als Wirtssprache
genutzt, da auch die Implementierung des WSDBS in dieser Sprache erfolgt. Die
Ausführungen basieren auf den Darstellungen von [EN94] und [Ull82].
4.3.3.1
Arbeitsumgebung
Jede Anfrage in WS/QL liest ein Record und schreibt dieses in ein dafür vorgesehenes Feld innerhalb der Arbeitsumgebung (user work area, UWA). In der UWA
KAPITEL 4. WEB-SITES ALS DATENBANKEN
55
besitzt jeder Record-Typ ein eigenes Feld. Abbildung 4.20 zeigt die in JAVA als
Klassen realisierten UWA-Felder für die Bundesliga Datenbank. Daneben werden
noch die Variablen CurrentRecord, CurrentParentRecord und CurrentRecordType
innerhalb des UWA zur Verfügung gestellt, die einen Zeiger auf den jeweils aktuellen
Record, ParentRecord bzw. RecordType darstellen. Dadurch wird ermöglicht, daß
Teilanfragen nicht jedesmal von der Wurzel der Hierarchie aus starten müssen.
class Verein
{ String
Name ; }
class Trainer
{ String
String
int
Vorname ;
Name ;
Alter ; }
class Spieler
{ String
String
int
Vorname ;
Name ;
Alter ; }
class Stadion
{ String
int
Name ;
Kapazität ; }
class Position { String
PosName ; }
Abbildung 4.20: Record-Typen als JAVA-Klassen innerhalb der UWA
Die Programmierung komplexer Anfragen, die auf einer record-at-a-time Sprache
basieren, erfordert die ständige Interaktion zwischen dem Programm und dem WebSite Managementsystem. Zu diesem Zweck wird nach jeder Ausführung eines Kommandos eine Statusinformation an das Programm übergeben. Dies wird durch eine
Statusvariable, die als DB Status bezeichnet wird, realisiert. In den folgenden Beispielen soll DB Status=0 eine erfolgreiche Ausführung des Kommandos anzeigen.
Die Struktur, auf denen die Operationen in diesem Zusammenhang agieren, stellt
die hierarchische Sequenz der Ausprägungen der Datenbank dar.
Die Operationen von WS/QL sollen im folgenden erläutert und exemplarisch vorgestellt werden. Obwohl bei der Implementierung des WSDBS als JAVA-Methoden
realisiert, werden die Operationen in einer SQL ähnlichen Syntax dargestellt, um
das Verständnis ihrer Funktionalität zu erleichtern.
4.3.3.2
Die GET Operationen
Die grundlegende Operation von WS/QL ist das Kommando GET. Dabei werden
von WS/QL zwei Variationen dieses Kommandos zur Verfügung gestellt.
GET FIRST <record type name> [ WHERE <condition > ]
GET NEXT <record type name> [ WHERE <condition > ]
Der Unterschied dieser Kommandos besteht darin, daß GET FIRST jedesmal am Anfang der hierarchischen Sequenz die Suche startet, während GET NEXT von dem
aktuellen Record, wie in der Variablen CurrentRecord spezifiziert, beginnt. Beide Kommandos durchlaufen die hierarchische Sequenz solange, bis sie ein Record
des spezifizierten Record-Typs, der die angegebenen Bedingungen erfüllt, gefunden
haben. War die Suche erfolgreich, wird dieses Record in das im UWA spezifizierte Feld geschrieben und die Statusinformation ’erfolgreich’ (DB Status=0) an das
Programm weitergegeben.
KAPITEL 4. WEB-SITES ALS DATENBANKEN
56
Folgendes Kommando sucht den ersten Spieler (innerhalb der hierarchischen Sequenz), der den Nachnamen Müller hat:
GET FIRST Spieler WHERE Name == ’Müller’ ;
Das Kommando durchläuft nun nacheinander die Datensätze der hierarchische Sequenz. Wird ein Record des Record-Typs ’Spieler’ gefunden, der die Bedingung
Nachname = ’Müller’ erfüllt, wird der Record in das dafür vorgesehene Feld der
UWA geschrieben und die Statusinformation ’Suche erfolgreich’ an das Wirtsprogramm zurückgegeben. Existiert kein solcher Spieler, wird die Statusinformation
’Suche erfolglos’ (z.B. DB Status=-1) ausgegeben.
Sollen nun alle Records des Typs Spieler, die den Nachnamen ’Müller’ tragen, gefunden werden, so muß mit Hilfe der Wirtssprache eine Wiederholungsanweisung
konstruiert werden, in die das Kommando GET NEXT eingebettet wird. Dies könnte
wie folgt aussehen:
GET FIRST Spieler WHERE Name == ’Müller’ ;
while (DB STATUS == 0) {
System.out.println(Spieler.Vorname, Spieler.Name) ;
GET NEXT Spieler WHERE Name == ’Müller’ ;
}
Das Programm veranlaßt durch das Kommando GET FIRST die Suche nach dem
ersten Spieler mit dem Nachnamen ’Müller’. Ist ein solcher Spieler gefunden worden, wird die Variable CurrentRecord auf den gefundenen Record gesetzt und GET
NEXT sucht ab diesem Record in der hierarchischen Sequenz nach dem nächsten
Spieler, der die Bedingung erfüllt. Wiederum wird CurrentRecord aktualisiert und
der nächste Spieler gesucht, usw.
4.3.3.3
Das Kommando GET PATH
Um Anfragen zu generieren, die Record-Typen unterschiedlicher Hierarchieebenen
miteinbeziehen, stellt WS/QL das Kommando GET PATH zur Verfügung, das folgende Syntax besitzt:
GET ( FIRST | NEXT ) PATH <HierarchicalPath>
[ WHERE <condition> ]
’HierarchicalPath’ ist dabei eine Liste von Record-Typen, die von der Wurzel beginnend einen Pfad innerhalb des hierarchischen Schemas beschreiben. In dem BeispielSchema sind z.B. ’Bundesliga, Verein, Spieler’ oder ’Bundesliga, Verein, Stadion’
reguläre Pfade. In der Bedingungsliste können dabei Bedingungen an verschiedene
Record-Typen geknüpft werden. Aus diesem Grund müssen vor den Attributen noch
die Record-Typ-Namen angegeben werden. Werden z.B. alle Spieler des Hamburger
SV gesucht, die den Vornamen ’Holger’ haben, könnte die Anfrage so aussehen:
GET FIRST PATH Bundesliga, Verein, Spieler
WHERE Verein.Name == ’Hamburger SV’ AND Spieler.Vorname == ’Holger’;
while (DB STATUS == 0) {
System.out.println(Spieler.Vorname, Spieler.Name)
GET NEXT PATH Bundesliga, Verein, Spieler
WHERE Verein.Name == ’Hamburger SV’ AND
Spieler.Vorname == ’Holger’;
}
Eine Besonderheit des GET PATH Kommandos ist, daß alle Records entlang des
Pfads in die entsprechenden Felder der UWA geschrieben werden. Dadurch ist die
KAPITEL 4. WEB-SITES ALS DATENBANKEN
57
Ausgabe übergeordneter Records möglich. Eine Anfrage ’Finde den in der hierarchischen Sequenz zuerst vorkommenden Verein, der einen Trainer beschäftigt, der
älter ist als 60 Jahre’ kann so aussehen:
GET FIRST PATH Bundesliga, Verein, Trainer
WHERE Trainer.Alter > 60 ;
System.out.println(Verein.Name) ;
4.3.3.4
Das Kommando GET NEXT WITHIN PARENT
Um alle Records eines bestimmten Typs zu suchen, die den gleichen Record als
Vorgänger haben, wird das Kommando GET NEXT WITHIN PARENT benutzt, das
folgende Syntax besitzt:
GET NEXT <descendant record type name>
WITHIN PARENT [ <parent record type name> ]
[ WHERE <condition> ]
Der ’descendant type’ muß kein Child-Record-Typ des CurrentParent Record-Typs
sein, sondern kann einen beliebigen nachfolgenden Record-Typ darstellen. Handelt
es sich jedoch um einen direkten Nachfolger, also einen Child-Record des CurrentRecord, so kann die Angabe des ’parent record type name’ weggelassen werden. Ein
Beispiel soll die Wirkungsweise des Kommandos verdeutlichen. Hierbei werden alle
Spieler von ’Schalke04’ ausgegeben.
GET FIRST Verein WHERE Name == ’Schalke 04’;
GET NEXT Spieler WITHIN PARENT;
while (DB STATUS == 0) {
System.out.println(Spieler.Vorname, Spieler.Name)
GET NEXT Spieler WITHIN PARENT Verein ;
}
4.3.4
XML-orientierte Schnittstelle
Das WSDBS setzt direkt auf dem DRS, das für die Gewinnung der in dem Web-Site
gespeicherten Daten verantwortlich ist, auf. Die Verbindung erfolgt an der durch das
DRS zur Verfügung gestellten, XML-orientierten Schnittstelle. Die Kommunikation zwischen dem DRS und der untersten Schicht des WSDBS, in diesem Fall dem
Puffersystem, verläuft dabei nach dem in Abb. 4.21 dargestellten Prinzip. Voraussetzung dafür ist, daß sowohl WSMS, als auch DRS mit derselben Template-Tabelle
arbeiten, die die DTD jeder Klasse enthält.
Wird ein neues XML-Dokument vom WSDBS benötigt, so übergibt das Puffersystem die URL und die dazugehörige Template-Klasse an das DRS. Dieses lädt
das durch die URL spezifizierte Web-Site-Dokument und generiert in Abhängigkeit der jeweiligen Template-Klasse das entsprechende XML-Dokument. Alle für
das WSDBS relevanten Informationen sind in diesem Dokument enthalten. Als relevant werden dabei sowohl die gemäß dem gegebenen Schema definierten Daten als
auch strukturelle Informationen, wie z.B. im Dokument enthaltene Querverweise,
betrachtet.
Zunächst erscheint die Generierung und die darauf folgende Interpretation von
XML-Dokumenten als überflüssig, da das DRS die gewonnenen Daten umgehend
in formatierte Datensätze überführen und an das Puffersystem weiterleiten könnte.
In diesem Fall wäre es jedoch angebracht, das DRS als Bestandteil des WSDBS zu
58
KAPITEL 4. WEB-SITES ALS DATENBANKEN
Puffersystem
URL
Template−Klasse
XML−orientierte Schnittstelle
XML Datei
DRS
Web−Site Schnittstelle
WWW
Abbildung 4.21: Die XML-orientierte Schnittstelle
betrachten. Im Rahmen dieser Arbeit soll allerdings kein unveränderliches Modell
zur Anfragebearbeitung von Web-Site-Inhalten aufgestellt, sondern Möglichkeiten
zur Lösung dieser Problematik gezeigt werden. Durch die Generierung von XMLDateien aus den jeweiligen Dokumenten des Web-Site erhält das WSDBS einen modularen Charakter und kann ohne Einfluß auf das DRS durch alternative Lösungen
der Anfragebearbeitung, wie z.B. XQuery, ersetzt werden. In dieser Arbeit wird
allerdings der Einsatz eines WSDBS aufgrund der im Vorfeld genannten Gründe
vorgezogen.
4.3.5
Pufferschnittstelle
Bevor auf die Konzepte und Eigenschaften der Pufferschnittstelle detailliert eingegangen wird, erfolgt vorab eine Beschreibung darüber, nach welchem Schema die
einzelnen Datensätze in Segmente aufgeteilt werden. Ein Segment besteht aus allen
Records eines bestimmten Record-Typs, die den gleichen Parent-Record besitzen.
Um diesen Zusammenhang zu verdeutlichen, ist in Abb. 4.22 eine Ausprägung des
Bundesliga Web-Site mit der Einteilung in entsprechende Segmente dargestellt.
Bundesliga
FC Bayern
Hitzfeld
Segment
Elber
Hamburger SV
Kahn
... Scholl
Segment
....
Hannover 96
Segment
OlympiaStadion
Segment
Torwart
Segment
Abbildung 4.22: Einteilung der Datensätze in Segmente
Die Pufferschnittstelle stellt dem übergeordneten Speichersystem eine Sicht auf alle Segmente der Datenbank zur Verfügung. Daneben werden gewisse Operationen
59
KAPITEL 4. WEB-SITES ALS DATENBANKEN
bereitgestellt, die dem Speichersystem ermöglichen, auf die gewünschten Segmente
zugreifen zu können.
Bei der Beschreibung des konzeptionellen Datenbank-Schemas wurde gezeigt, daß
jede Template-Klasse durch ein oder mehrere Record-Typen modelliert wird. Die
an der XML-orientierten Schnittstelle zur Verfügung gestellten Dokumente basieren
aber gerade auf den Template-Klassen des Web-Site-Schemas. Demnach können diese Dokumente ebenfalls Daten unterschiedlicher Record-Typen enthalten. Jedes Segment wiederum besteht ausschließlich aus Records eines einzigen Record-Typs. Somit besteht eine Aufgabe des Puffersystems darin, die jeweiligen XML-Dokumente
in ein bzw. mehrere Segmente zu transformieren.
Für die Transformation der XML-Dokumente in verschiedene Segmente stellt das
Puffersystem eine Methode zur Verfügung, die, ähnlich der Funktionsweise eines
Scanners, ein Dokument sequentiell durchläuft und die Daten-Elemente den jeweils
passenden Segmenten zuordnet. Wird an der internen Satzschnittstelle ein Segment
angefordert, das gegenwärtig nicht im Puffer gespeichert ist, wird die URL des
Dokuments, das dieses Segement enthält, aus der Segment-Tabelle ermittelt, und
durch das DRS die entprechende XML-Datei generiert.
Neben der Interpretation der jeweiligen XML-Dokumente besteht die Aufgabe des
Puffersystems darin, eine bestimmte Menge von Segmenten in einem Puffer zu halten und bei Bedarf gegebenenfalls durch neue zu ersetzen. Der Puffer wird aus
einer gewissen Anzahl von Blöcken gebildet. Dabei repräsentiert jeder Block eine
Template-Klasse des Web-Site-Schemas. Der Puffer besteht also aus genausoviel
Blöcken wie Template-Klassen im Web-Site-Schema existieren. Die in einem Block
enthaltenen Segmente sind demzufolge genau die Segmente, die bei der Interpretation eines XML-Dokuments, das auf der gleichen Template-Klasse wie der Block
beruht, generiert werden. Es befindet sich also entweder eine oder keine Instanz der
jeweiligen Template-Klassen im Puffer.
4.3.6
Interne Satzschnittstelle
Die interne Satzschnittelle stellt der über ihr liegenden Ebene eine Sicht auf den
gesamten Datenbestand in Form einer Menge von Datensätzen zur Verfügung. Die
einzelnen Sätze sind durch Zeiger so miteinander verbunden, daß eine PreorderDarstellung der hierarchischen Ausprägung der Datenbank generiert wird. Diese
Form der Datenspeicherung wird als Zeigernetzwerk bezeichnet.
Bundesliga
FC Bayern
Hitzfeld
Elber
Hamburger SV
Kahn
... Scholl
....
Hannover 96
OlympiaStadion
Abbildung 4.23: Speicherung der Datensätze
Es existieren zwei Methoden zur Implementierung von Zeigernetzwerken. Die erste
wird durch als Preorder-Threads bezeichnete Zeiger realisiert, wobei jeder Datensatz genau einen Zeiger enthält. Im Rahmen dieser Arbeit wird jedoch die zweite
KAPITEL 4. WEB-SITES ALS DATENBANKEN
60
Methode verwendet, bei der jedem Datensatz zwei Zeiger zugeordnet werden. Dies
führt gegenüber den Preorder-Threads in Hinblick auf die Anfragebearbeitung zu
einer Steigerung der Performance.
Der erste, als leftmostchild bezeichnete Zeiger referenziert den in der hierarchischen
Sequenz als erstes auftretenden Child-Record des aktuellen Datensatzes, wohingegen der rightsibling Zeiger auf den in der gleichen Hierarchie-Ebene liegenden Nachfolger des aktuellen Datensatzes verweist, sofern beide den selben Parent-Record
besitzen. Diese Art der Datensatzspeicherung ist in Abb. 4.23 zu erkennen.
Folgende Operationen werden vom Speichersystem an der internen Satzschnittstelle
zur Verfügung gestellt:
scanLmC()
scanRsb()
up()
get(x )
test(cond)
4.3.7
Liefert einen Zeiger auf den leftmostchild des aktuellen Record
Liefert einen Zeiger auf den rightsibling
des aktuellen Record
Liefert einen Zeiger auf den Parent des
aktuellen Record
schreibt den Record auf den x verweist
in das entsprechende Feld der UWA.
Testet den aktuellen Datensatz hinsichtlich einer Bedingung
Satzorientierte Schnittstelle
Die satzorientierte Schnittstelle stellt die in der Anfragesprache WS/QL vereinten Operationen und Datenstrukturen zur Verfügung. Realisiert wird sie durch das
Zugriffssystem, das die Zugriffsstrukturen für das Speichersystem bereitstellt. Dabei wird für jedes Kommando von WS/QL ein auf den Operationen der internen
Satzschnittstelle basierender Ausführungsalgorithmus implementiert.
TotalScan() {
CurrentRecord = root ;
x = scanLmC() ;
if (x != nil) {
CurrentRecord = get(x) ;
while (CurrentRecord != root) {
x = scanLmC() ;
if (x != nil)
CurrentRecord = get(x) ;
else {
x = scanRsb() ;
if (x!= nil)
CurrentRecord = get(x) ;
else {
while ((x == nil) && (CurrentRecord != root)) {
x = up() ;
CurrentRecord = get(x) ;
x = scanRsb() ; }
if (x!= nil)
CurrentRecord = get(x) ; } } } } }
Abbildung 4.24: Vollständiger Durchlauf der gesamten Ausprägung
KAPITEL 4. WEB-SITES ALS DATENBANKEN
61
In diesem Zusammenhang wird nun zunächst ein Algorithmus vorgestellt, der die
gesamte Datenbank“ einmal vollständig durchläuft (Abb. 4.24). Auf diesem basie”
ren alle weiteren, für die Implementierung von WS/QL benötigten, Algorithmen.
Als Beispiel für einen Ausführungsalgorithmus des WSDBS ist in Abb. 4.25 die
Implementierung des Kommandos GET FIRST dargestellt. Die Änderungen bzw.
Ergänzungen gegenüber dem vollständigen Durchlauf sind dabei durch einen grauen Hintergrund kenntlich gemacht. Der Ausführungsalgorithmus des Kommandos
GET NEXT ist dabei mit dem hier dargestellten fast identisch. Der wesentliche Unterschied besteht darin, daß die Variable CurrentRecord zu Beginn der Prozedur nicht
auf ’root’ zurückgesetzt wird und somit jeweils vom aktuellen Record aus startet.
GetFirst(<record type name>, <condition>) {
CurrentRecord = root ;
x = scanLmC() ;
if (x != nil) {
CurrentRecord = get(x) ;
if (CurrentRecordType == <record type name>)
success = test(<condition>) ;
while ((CurrentRecord != root) && (success != true)) {
x = scanLmC() ;
if (x != nil) {
CurrentRecord = get(x) ;
if (CurrentRecordType == <record type name>)
success = test(<condition>) ;
} else {
x = scanRsb() ;
if (x!= nil) {
CurrentRecord = get(x) ;
if (CurrentRecordType == <record type name>)
success = test(<condition>) ;
} else {
while ((x == nil) && (CurrentRecord != root)) {
x = up() ;
CurrentRecord = get(x) ;
x = scanRsb() ; }
if (x!= nil) {
CurrentRecord = get(x) ;
if (CurrentRecordType == <record type name>)
success = test(<condition>) ; } } } } } }
Abbildung 4.25: Implementierung des Kommandos GET FIRST
Kapitel 5
Entwicklung des ZIS
In Anlehnung an die theoretischen Konzepte föderierter DBSe sowie unter Einbeziehung von Web-Site DBSen wird in diesem Kapitel die Entwicklung eines Zeitschriften-Informationssystems (ZIS) ausführlich erläutert. Das ZIS integriert Datenbestände heterogener Quellen, wie beispielsweise relationale DBSe oder auch
Web-Sites, die im Rahmen dieser Arbeit allerdings als hierarchische DBSe aufgefaßt
werden. Besonders hervorzuheben hierbei ist die Tatsache, daß das ZIS nur lesenden
Zugriff auf die jeweiligen Datenquellen besitzt und somit Aspekte der Transaktionsverarbeitung, Konsistenzüberwachung, etc. nicht beachtet werden müssen.
Ziel bei der Entwicklung des ZIS ist es, dem Benutzer die Möglichkeit zu bieten, in
unterschiedlichen Quellen nach Informationen über Zeitschriftenartikel zu suchen
und somit die Literaturrecherche zu erleichtern. Dabei wird, sofern bekannt, zu
jedem gefundenen Artikel angegeben, wo der vollständige Text zu finden ist. Diese
Angabe kann entweder ein Hyperlink auf ein entsprechendes Web-Dokument oder
auch der Standort der gedruckten Ausgabe innerhalb einer Bibliothek sein.
Anfragen können mit Hilfe von SQL-ähnlichen SELECT-FROM-WHERE Operationen
an das ZIS gerichtet werden. Der Funktionsumfang dieser Operationen ist allerdings
im Vergleich zu SQL stark eingeschränkt, da die Bearbeitung komplexer Anfragen
in Hinblick auf die Transaktionskosten bei der Integration von Web-Sites zu starken
Performance-Einbußen führen würde. Um dem Benutzer dennoch die Möglichkeit
einer differenzierten Recherche zu offerieren, können die Ergebnisse der jeweiligen
Anfragen in einer Arbeitsdatenbank gespeichert werden, die abhängig von dem verwendeten DBMS vielfältige Bearbeitungsmöglichkeiten zur Verfügung stellt.
Der konzeptionelle Ansatz zur Integration verteilter, heterogener Informationsquellen beinhaltet fünf verschiedene Entwurfsphasen, die jeweils aufeinander aufbauen.
In der ersten Phase erfolgt die Informations-Selektion. Hierbei wird zunächst festgestellt, welche möglichen Quellen für die Föderation zur Verfügung stehen. Daran
anschließend erfolgt die Auswahl der zu integrierenden Datenbestände. Zu jeder selektierten Quelle wird dabei eine Beschreibung angefertigt, in der festgehalten wird,
wo die Quelle zu finden ist, wer deren Anbieter ist, um was für eine Art von Datenbestand es sich handelt (lokale Datenbank, Web-Site, etc. ), wie das konzeptionelle
Schema aussieht und welche Besonderheiten beachtet werden müssen. Abschnitt 5.1
befaßt sich mit der Informations-Selektion für das ZIS.
Die zweite Entwurfsphase stellt die Informations-Modellierung dar. Dabei erfolgt
die Entwicklung eines für die Integration geeigneten Architekturmodells sowie eine detaillierte Beschreibung der innerhalb des Modells verwendeten Schemata. Das
62
KAPITEL 5. ENTWICKLUNG DES ZIS
63
dem ZIS zugrunde liegende Architekturmodell basiert auf der 5-Ebenen-SchemaArchitektur für föderierte DBSe und wird in Abschnitt 5.2 beschrieben. Ausgehend von diesem Modell erfolgt die Entwicklung eines föderierten Schemas. Dabei
werden zunächst die lokalen Schemata der Komponentensysteme durch verschiedene Schema-Transformationen in für die Integration geeignete Export-Schemata
überführt, aus denen das föderierte Schema entwickelt wird (Schema-Integration).
Die jeweiligen Transformations- und Integrationsschritte sowie die daraus entstehenden Schemata sind Gegenstand von Abschnitt 5.3.
Wurde bisher von einem statischen Modell ausgegangen, erfolgt nun durch den
Einsatz funktionaler Komponenten eine dynamische Modellerweiterung. Die dritte
Entwurfsphase beschreibt somit die für die Föderation notwendigen Transformationsprozesse, während die für die Integration verwendeten Funktionen innerhalb
der darauf folgenden Phase festgelegt werden (Integrationsprozesse). Unter dem
Aspekt der Anfragebearbeitung erfolgt in Abschnitt 5.4 die Beschreibung dieser
beiden Entwurfsphasen, die beim ZIS durch verschiedene Wrapper, sowie einen Mediator realisiert werden. Weiterhin wird die durch das ZIS zur Verfügung gestellte
Benutzerschnittstelle ausführlich erläutert.
Die letzte Entwurfsphase behandelt die Aspekte der Administration. Darunter fallen Themen wie beispielsweise die Integration zusätzlicher Datenquellen (Extensibilität), Instandhaltung des bestehenden Systems, Modifizierung der verwendeten
funktionalen Komponenten etc. Die Aspekte der Administration des ZIS werden in
Abschnitt 5.5 vorgestellt.
5.1
Beschreibung der Komponentensysteme
Im Rahmen dieser Arbeit wird ein Prototyp des ZIS vorgestellt, der drei unterschiedliche Komponentensysteme integriert. Dabei handelt es sich um ein relationales
DBS und zwei Web-Sites. Anhand dieser Systeme sollen alle für das ZIS benötigten Konzepte beispielhaft dargestellt werden. Die Komponentensysteme wurden so
ausgewählt, daß ein möglichst großer Bereich von Datenquellen, die für das ZIS
in Betracht kommen können, abgedeckt wird. Online-Bibliotheken verschiedener
Verlage werden durch die ACM Digital Library repräsentiert. Stellvertretend für
das Angebot von Bibliographie-Servern, die Informationen über Artikel verschiedener Verlage beinhalten, steht der DBLP-Server der Universität Trier. Mit Hilfe
der Bibliotheks-Datenbank der Abteilung Datenbanken und Informationssysteme
(DBIS) der Universität Hannover, werden die bei der Integration relationaler DBSe
verwendeten Konzepte vorgestellt.
5.1.1
ACM Digital Library
Gegründet im Jahre 1947, stellt die Association for Computing Machinery (ACM )
heutzutage die größte Vereinigung im Bereich der Informationstechnologie dar.
ACM ist verantwortlich für die Veröffentlichung einer Vielzahl von angesehenen
Zeitschriften und Tagungsbänden aus dem Bereich der Informatik. Diese Veröffentlichungen wurden digitalisiert und in der ACM Digital Library zusammengefaßt.
Zur Zeit umfaßt die ACM Digital Library mehr als 70000 Artikel aus Zeitschriften
bzw. Tagungsbänden.
Zu jedem Artikel stellt die Digital Library eine bestimmte Menge an Informationen
zur Verfügung. Die bibliographische Referenz beinhaltet dabei den Titel, den oder
KAPITEL 5. ENTWICKLUNG DES ZIS
64
die Autor(en), die jeweilige Publikation zusammen mit Band- und Heftnummer sowie die Seitenzahlen eines Artikels. Schlüsselwörter sowie die Eingliederung in das
ACM Computing Classification System sind unter dem Begriff index terms zusammengefaßt. Dabei sei darauf hingewiesen, daß die Klassifizierung der Artikel nicht
in das Web-Site-Schema übernommen wurde, da dies eine ACM -spezifische Besonderheit darstellt und von anderen Bibliotheken kaum verwendet wird, so daß diese
Information in Hinblick auf das ZIS nicht von Bedeutung ist. Weiterhin wird für die
meisten Artikel eine Zusammenfassung angegeben sowie ein Querverweis zu dem
jeweiligen Volltext offeriert. Dieser kann aber nur betrachtet bzw. heruntergeladen
werden, sofern man die entsprechenden Zugriffsrechte besitzt.
Das Web-Site-Schema ebenso wie das konzeptionelle Schema der ACM Digital Library wurden in Abschnitt 4.1 ausführlich dargestellt, so daß in diesem Zusammenhang
auf eine nochmalige Beschreibung der Schemata verzichtet wird.
5.1.2
DBLP Bibliographie-Server
Seit 1994 wird an der Universität Trier der Web-Server Digital Bibliography & Library Project 1 (DBLP) betrieben. Der DBLP-Server bietet hauptsächlich bibliographische Informationen zu Zeitschriften und Tagungsbänden aus dem Bereich der
Informatik an. Zum gegenwärtigen Zeitpunkt sind mehr als 250000 Artikel auf dem
Bibliographie-Server erfaßt.
Ziel bei der Entwicklung des DBLP-Server war es, einen leichten Zugang zu aktuellen und qualitativ hochwertigen Fachinformationen zu schaffen und somit die
bestehenden Schwierigkeiten bei der Literaturrecherche zu beseitigen. Im Gegensatz
zu Büchern werden Einzelarbeiten aus Zeitschriften oder Tagungsbänden nicht in
den von den Bibliotheken zur Verfügung gestellten Katalogen aufgeführt. Somit muß
in diesem Zusammenhang auf andere Informationsquellen zurückgegriffen werden.
Aus unterschiedlichen Gründen werden diese Quellen jedoch relativ selten genutzt.
Eine CD-ROM-Recherche beispielsweise erfordert einen hohen Arbeitsaufwand und
kann in den meisten Fällen nicht vom Arbeitsplatz aus durchgeführt werden. Erschwerend kommt hinzu, daß neue Arbeiten erst nach einer gewissen Zeit in den
Datenbestand aufgenommen werden und demzufolge die Aktualität der Informationsquellen nur bedingt gewährleistet werden kann.
Im Gegensatz dazu kann der DBLP Bibliographie-Server von jedem mit dem Internet verbundenen Arbeitsplatz genutzt werden. Dabei werden Informationen zu
Einzelarbeiten aus Zeitschriften oder Tagungsbänden verschiedener Verlage angeboten. Zu vielen Arbeiten existiert ein Verweis auf die entsprechende Online-Version,
die somit bequem auf den eigenen Rechner geladen werden kann, vorausgesetzt,
man besitzt die dazu notwendigen Zugriffsrechte des Anbieters.
In Abb. 5.1 ist das Web-Site-Schema des DBLP Bibliographie-Server dargestellt.
Die erste Template-Klasse ListOfAllJournals“ beinhaltet die erfaßten Zeitschrif”
ten, die entsprechend ihrer Zugehörigkeit zu unterschiedlichen Verlagen zusammengefaßt sind. Zu jeder dieser Publikationen existiert ein Querverweis auf die Klasse
PublicationStreams“, in der die verschiedenen Jahrgänge bzw. Volumes der ent”
sprechenden Zeitschriften aufgeführt sind. Die jeweiligen Ausgaben eines Volumes,
zusammen mit den in ihnen enthaltenen Artikeln, werden durch die Template-Klasse
TableOfContents“ repräsentiert. Zu jedem Artikel ist dabei der Titel, der oder die
”
Autor(en), die Angabe der Seitenzahlen und gegebenfalls ein Querverweis auf den
Volltext angeführt.
1 http://www.informatik.uni-trier.de/
ley/db/journals/
65
KAPITEL 5. ENTWICKLUNG DES ZIS
Template−Klasse : "ListOfAllJournals"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Publisher
Publication
Name
HyperLink
HyperLink
(Name, Publication+)>
(Name, HyperLink)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
#REQUIRED
#REQUIRED>
Template−Klasse : "PublicationStreams"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
PubRelYear
PubRelVolume
Year
Volume
HyperLink
HyperLink
(Year, PubRelVolume+)>
(Volume, HyperLink)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
#REQUIRED
#REQUIRED>
Template−Klasse : "TableOfContents"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
PubRelIssue
Article
Author
Title
Pages
URLFullText
Name
(Issue, Article+)>
(Title, Author+, Pages, URLFullText)>
(Name+)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Abbildung 5.1: Web-Site-Schema des DBLP-Server
Zusätzlich existiert zu jedem Autor ein Querverweis zu einer Seite, auf der alle
Publikationen des jeweiligen Autors aufgeführt sind. Dieses Konzept wird im WebSite-Schema nicht modelliert, da diese Informationen mit Hilfe von WS/QL generiert werden können. Ein anderes Konzept der DBLP-Datenbank ist ebenfalls nicht
im Web-Site-Schema enthalten, wobei in diesem Falle technische Gründe dafür verantwortlich sind. Einige Artikel besitzen einen globalen Verweis auf eine sogenannte
Citation Page, auf der unter anderem eine Zusammenfassung, Schlüsselwörter, Referenzliteratur u.ä. angegeben sind. Diese Seiten befinden sich jedoch in den WebSites der entsprechenden Verlage. Zum einen müsste also für jeden Verlag eine eigene
Template-Klasse in Bezug auf die Citation Page generiert werden, zum anderen sind
globale Verweise bei der Modellierung von Web-Site-Schemata im Rahmen dieser
Arbeit überhaupt nicht vorgesehen.
Zusammenfassend läßt sich also sagen, daß es sich bei dem DBLP-Server aus Sicht
des ZIS um ein System handelt, das nur das absolute Minimum an Informationen
(Autoren, Titel, Publikationskontext) zu den jeweiligen Artikeln bereitstellt, aber
aufgrund der Vielzahl der erfaßten Artikel als ein sinnvolles Komponentensystem
für das ZIS betrachtet werden kann. Das konzeptionelle Schema dieser Komponente
ist in Abb. 5.2 dargestellt. Hierbei werden Record-Typen, die die gleiche TemplateKlasse referenzieren, durch einen grauen Hintergrund zusammengefaßt.
5.1.3
DBIS Literaturdatenbank
Die Abteilung Datenbanken und Informationssysteme (DBIS) der Universität Hannover betreibt eine Forschungsliteraturdatenbank FLIT, in der unterschiedliche Dokumentarten, wie z.B. Bücher, Diplomarbeiten, Handbücher oder Zeitschriftenarti-
66
KAPITEL 5. ENTWICKLUNG DES ZIS
Publisher
Name
Publication
Name
PubRelYear
Year
PubRelVolume
Volume
PubRelIssue
Issue
Title
Article
Pages
URLFullText
Author
Name
Abbildung 5.2: Konzeptionelles Schema des DBLP-Server
kel, erfaßt werden. Das Schema der FLIT ist in Abb. 5.3 dargestellt, wobei auf die
Angabe der Datentypen verzichtet wurde, da diese aus dem jeweiligen Kontext zu
erkennen sind. Im folgenden erfolgt nun eine kurze Beschreibung der verschiedenen
Tabellen der FLIT-Datenbank.
In der Relation L DOKTYP sind die von der Datenbank verwalteten Dokumenttypen
in Form von Kurzbezeichnungen, wie beispielsweise ’book’, ’master’, ’article’ oder
’manual’, gespeichert. Eine genaue Beschreibung der jeweiligen Bezeichnungen erfolgt optional durch das Attribut EXPL. Analog dazu sind in der Tabelle L MONAT
Kurzbezeichnungen der Monatsnamen zusammen mit den entsprechenden Monaten
gespeichert.
Die wichtigste Relation der FLIT-Datenbank wird durch die Tabelle DOKUMENT
repräsentiert. Jedes in dieser Tabelle erfaßte Dokument besitzt eine eindeutige Dokumentnummer, dargestellt durch das Attribut DOKNR, das darüber hinaus als
Primär-Schlüssel der Tabelle fungiert. Weitere nicht-optionale Attribute sind TITEL, DOKTYP und ERFDATUM. DOKTYP referenziert gleichzeitg die im Vorfeld
beschriebene Relation L DOKTYP. Die Attribute DOKTYPERG, ANMERKUNG, VERWENDUNG und INTERNANMERKUNG bieten die Möglichkeit, jedes erfaßte Dokument mit zusätzlichen Angaben zu versehen.
Zu jedem Dokument werden in Abhängigkeit des jeweiligen Typs bestimmte Eigenschaften gespeichert. Für einen Zeitschriftenartikel sind dabei z.B. die Attribute
ZEITSCHRREIHE, BAND, NUMMER bzw. SEITE von Bedeutung, während bei Büchern
Angaben zu VERLAG, ORT, AUFLAGE und ISBNNR signifikant sind. Weiterhin besitzen sowohl Bücher, als auch Zeitschriften ein Erscheinungsjahr (JAHR) sowie letztere
zusätzlich einen Erscheinungsmonat (MONAT).
Ein für alle Dokumente wichtiges Atrribut stellt AUTOREN dar. Der Datentyp dieses Attributs ist eine Zeichenkette, die die Namen der jeweiligen Autoren enthält.
Existieren zu einem Dokument mehrere Autoren, so sind diese entweder durch ein
’,’ oder ein ’/’ voneinander getrennt. Wichtig hierbei ist, zu erkennen, daß es sich
67
KAPITEL 5. ENTWICKLUNG DES ZIS
DOKUMENT
DokNr
Titel
Jahr
Monat
DokTyp
DokTypErg
Kuerzel
Herausgegeben
ZeitschrReihe
Band
Nummer
Seite
Verlag
Ort
Auflage
InDok
InstOrg
Anzahl
Sprache
Anmerkung
Autoren
Verwendung
Standort
Deskriptoren
ErfDatum
CR_Klassifikation
Signatur
InventarNr
ISBNNr
InternAnmerkung
Vorversion
SCHLAGWORT
NOT NULL
NOT NULL
DokNr
NamKuerz
Schlagwort
Gewicht
NOT NULL
NOT NULL
NOT NULL
L_MONAT
Monat
Expl
NOT NULL
L_DOKTYP
DokTyp
Expl
NOT NULL
NOT NULL
Abbildung 5.3: Relationen-Schema der DBIS-Datenbank
bei AUTOREN eigentlich um ein mehrwertiges Attribut handelt, das aber aufgrund
der Tatsache, daß das relationale Datenmodell diese Art von Attributen nicht unterstützt, in der beschriebenen Form modelliert wird.
Viele der in der FLIT gespeicherten Dokumente sind in gedruckter Form in der
Abteilung DBIS vorhanden, manche davon sogar mehrfach. Wieviele Exemplare
existieren, wird durch das Attribut ANZAHL ausgedrückt. Eine Null bedeutet dabei,
daß ein Dokument nicht in gedruckter Form in der Abteilung vorhanden ist. Wo die
vorhandenen Exemplare zu finden sind, wird durch das Attribut STANDORT festgelegt. Hierbei handelt es sich wieder um ein als atomar modelliertes mehrwertiges
Attribut, analog zu AUTOREN. Für die in gedruckter Form vorliegenden Dokumente
können weitere abteilungsinterne Angaben wie SIGNATUR oder INVENTARNR gespeichert werden. Das Attribut INDOK ist genauso wie VORVERSION eine Referenz auf
DOKNR der gleichen Tabelle und verweist auf das Dokument, in dem der aktuelle
Text enthalten ist (bzw. auf die vorhergehende Version). So sind Tagungberichte
z.B. in einem Tagungsband enthalten. Bei Zeitschriftenartikeln wird diese Angabe jedoch nicht vorgenommen sondern die den Artikel enthaltene Zeitschrift direkt
durch den Publikationskontext repräsentiert.
In der Tabelle SCHLAGWORT schließlich sind zu jedem Dokument verschiedene
Schlagwörter gespeichert, die den Inhalt der jeweiligen Texte grob kennzeichnen
sollen. Der Primär-Schlüssel wird durch die Attribute SCHLAGWORT und DOKNR
gebildet, wobei DOKNR gleichzeitig eine Referenz auf die Tabelle DOKUMENT darstellt. GEWICHT ordnet jedem Schlagwort eine bestimmte Gewichtung zu.
KAPITEL 5. ENTWICKLUNG DES ZIS
5.2
68
Entwicklung des Architekturmodells
Nachdem im vorhergehenden Abschnitt die Selektion verschiedener Komponentensysteme beschrieben wurde, wird nun ein allgemeines Architekturmodell für das
ZIS entwickelt. Allgemein bedeutet in diesem Fall, daß es nicht auf die im Vorfeld selektierten Datenquellen beschränkt ist, sondern in Hinblick auf die Extensibilität des ZIS weitere Komponentensysteme mieinschließt. Die Entwicklung der
ZIS-Architektur erfolgt dabei in Anlehnung an die 5-Ebenen-Schema-Architektur
für föderierte DBSe und die ANSI/SPARC-Architektur, auf der die Komponentensysteme basieren.
Zunächst wird nun ein allgemeines Architekturmodell für die Integration verteilter,
heterogener Datenquellen vorgestellt. Darauf aufbauend erfolgt die Entwicklung der
ZIS-Architektur. Die funktionalen Komponenten des ZIS sind nicht Bestandteil des
Architekturmodells und werden in diesem Zusammenhang somit nicht behandelt.
Eine Beschreibung der Aufgaben und Funktionsweise dieser Komponenten erfolgt
in Abschnitt 5.4.
5.2.1
Allgemeines Modell föderierter DBSe
Wie bereits erwähnt, basieren die Komponentensysteme auf der ANSI/SPARCArchitektur. Diese werden nun auf die Art und Weise in die 5-Ebenen-SchemaArchitektur für föderierte DBSe integriert, daß jeweils bestimmte Schemata der
unterschiedlichen Modelle einander zugeordnet werden können. So entsprechen die
konzeptionellen ANSI/SPARC-Schemata den lokalen Schemata des föderierten Modells.
Im Gegensatz dazu lassen sich für die externen Schemata auf den ersten Blick
keine entsprechenden Zuordnungen in der 5-Ebenen-Schema-Architektur erkennen.
Jedoch können die Komponenten-Schemata lediglich als Zwischenschritt betrachtet werden, um eine Trennung der verschiedenen Transformationsprozesse, die die
lokalen in die Export-Schemata überführen, zu erreichen. In der ANSI/SPARCArchitektur sind diese Prozesse in dem Übergang vom konzeptionellen zu einem
externen Schema zusammengefaßt. Somit lassen sich die externen Schemata den
Export-Schemata der 5-Ebenen-Schema-Architektur zuordnen. In Abbildung 5.4 ist
die Integration der ANSI/SPARC-Architektur in das föderierte Modell dargestellt.
In diesem Zusammenhang wird bereits auf die externen Schemata der 5-EbenenSchema-Architektur verzichtet, da diese vom ZIS nicht zur Verfügung gestellt werden.
Wie in Abb. 5.4 zu erkennen, setzen die lokalen Schemata direkt auf den internen
Schemata der jeweiligen Datenquellen auf. Es wird davon ausgegangen, daß diese
auf unterschiedlichen Datenmodellen basieren und somit für die Integration homogenisiert werden müssen. Diese Homogenisierung erfolgt zwischen den lokalen und
den Komponenten-Schemata. Innerhalb der dargestellten Architektur werden keine
konkreten Datenmodelle angegeben. Diese Spezialisierung erfolgt erst bei der Entwicklung der ZIS-Architektur. Ebenso werden die Zugriffsmöglichkeiten auf die jeweiligen Datenbestände nicht näher erläutert, sondern lediglich davon ausgegangen,
daß es sich dabei um separate Datenbanken handelt, wobei auch die zu integrierenden Web-Sites als Datenbanken aufgefaßt werden. Deutlich zu erkennen ist dagegen
die Trennung zwischen Transformations- und Integrationsprozessen.
69
KAPITEL 5. ENTWICKLUNG DES ZIS
Föderiertes Schema
ExportSchema
(extern)
ExportSchema
(extern)
Integration
....
ExportSchema
(extern)
Transformation
Komponenten
Schema
Komponenten
Schema
....
Komponenten
Schema
homogene
Datenmodelle
Lokales Schema
(konzeptionell)
Lokales Schema
(konzeptionell)
....
Lokales Schema
(konzeptionell)
heterogene
Datenmodelle
Internes Schema
Internes Schema
....
Internes Schema
DBMS
KomponentenDB
DBMS
KomponentenDB
HTML/XML
KomponentenDB
heterogene
Datenquellen
Abbildung 5.4: Allgemeines Modell föderierter DBSe
5.2.2
Architekturmodell des ZIS
Ausgehend von dem zuvor beschriebenen Architekturmodell erfolgt nun die sukzessive Konkretisierung der dabei verwendeten Konzepte, mit dem Ziel der Entwicklung einer Architektur für das ZIS. Das daraus entstehende Modell ist in Abb. 5.5
dargestellt.
Die in das ZIS zu intergrierenden Datenquellen können entweder strukturiert oder
auch semi-strukturiert sein. Ein Datenbestand wird als semi-strukturiert bezeichnet,
wenn die gewünschten Informationen mit Hilfe einer formalen Grammatik extrahiert werden können [MMK99]. DBSe repräsentieren dabei die strukturierten Datenquellen, während die der Föderation zugehörigen Web-Sites als semi-strukturiert
betrachtet werden.
DBSe beinhalten ein DBMS, das den Benutzern eine Datendefinitionssprache (data
definition language, DDL) sowie eine Datenmanipulationssprache ( data manipulation language, DML) zur Verfügung stellt. Da das ZIS nur lesenden Zugriff auf
die Komponentensysteme besitzt, ist in diesem Zusammenhang hauptsächlich die
DML von Interesse, die die Möglichkeit bietet, Anfragen an die entsprechenden
Datenbestände zu richten. Als DDL von Web-Sites können HTML bzw. XML aufgefaßt werden. Nicht vorhanden ist allerdings eine DML. Aus diesem Grund wurde
im vorhergehenden Kapitel das WSMS entwickelt, das mit WS/QL als DML eine
Möglichkeit bietet, Anfragen an die jeweiligen Web-Sites zu stellen. Somit können
alle Komponentensysteme als reguläre DBSe aufgefaßt werden, die der Föderation
in Form der DML eine Anfrageschnittstelle zur Verfügung stellen.
Jeder Datenbestand basiert somit auf einem eigenen logischen Datenmodell. Dabei
kann es sich, wie im Falle des WSDBS, um ein hierarchisches Modell handeln, wohingegen die von vornherein als DBSe implementierten Quellen relationalen oder
auch objekt-orientierten Charakter besitzen können. Obwohl im Rahmen dieser Arbeit nicht näher auf die Integration objekt-orientierter DBSe eingegangen wird, sind
sie in Hinblick auf die Erweiterbarkeit des ZIS dennoch Bestandteil der Architektur.
Mit Hilfe von entsprechenden Datenmodell-Transformationen (DMT) werden alle Datenbestände auf ein einheitliches Datenmodell abgebildet, so daß die Ebene
70
KAPITEL 5. ENTWICKLUNG DES ZIS
Föderiertes Schema
ExportSchema
(extern)
relational
Filter
Komponenten
Schema
relational
DMT
Lokales Schema
(konzeptionell)
objekt−orient.
DBMS
ExportSchema
(extern)
relational
Filter
....
Komponenten
Schema
....
Lokales Schema
(konzeptionell)
DMT
Lokales Schema
(konzeptionell)
hierarchisch
DBMS
strukturierte
KomponentenDB
strukturierte
KomponentenDB
Datenbank
relational
homogene
Datenmodelle
DMT
relational
Internes Schema
ExportSchema
(extern)
relational
Filter
Komponenten
Schema
Internes Schema
Datenbank
....
relational
heterogene
Datenmodelle
WSMS
....
Internes Schema
Web−Site
semi−strukturierte
KomponentenDB
heterogene
Datenquellen
Abbildung 5.5: Architekturmodell des ZIS
der Komponentenschemata einen in Bezug auf das jeweils zugrunde liegende Datenmodell homogenen Charakter aufweist. Als globales Modell für das ZIS wird
das relationale Datenmodell verwendet. Der Grund hierfür liegt einerseits darin,
daß hauptsächlich relationale und hierarchische DBSe in das ZIS integriert werden,
andererseits existiert mit SQL eine weit verbreitete DML für das relationale Datenmodell. Obwohl das ZIS nur eine vereinfachte Form von SQL zur Verfügung stellt,
wird dem SQL-erfahrenen Benutzer dadurch ein intuitiver Zugriff auf das System
ermöglicht.
Die auf dem globalen Datenmodell basierenden Schemata werden nun dahingehend modifiziert, daß nur noch der der Föderation zur Verfügung gestellte Ausschnitt zu sehen ist. Formal ausgedrückt heißt das, daß mit Hilfe von Filterungen und/oder Schema-Modifikationen die Komponentensysteme auf entsprechende
Export-Schemata abgebildet werden, die dann in das föderierte System integriert
werden können.
Das föderierte Schema basiert auf dem durch die Komponenten-Schemata realisierten globalen Datenmodell und umfaßt alle in den Export-Schemata vorkommenden
Konzepte. Der Zugriff auf die Föderation erfolgt durch SQL-ähnliche Anfragen. Die
Anfragebearbeitung und die dabei verwendeten funktionalen Komponenten sind Bestandteil von Abschnitt 5.4. Im folgenden werden nun, ausgehend von den bereits
vorgestellten Komponentensystemen, die für die Föderierung benötigten Schemata
ausführlich beschrieben.
5.3
Datenbank-Entwurf
In Anlehnung an den allgemeinen Entwurf föderierter Datenbanken [Con97] wird
im folgenden der Entwurf des dem ZIS zugrunde liegenden DBS vorgestellt. Wesentlich hierbei ist die Integration der verschiedenen Komponenten-DBSe, die dadurch
ermöglicht wird, daß zunächst deren lokalen Schemata mittels spezieller Transformationen in eine, bezogen auf das Datenmodell, homogene Form überführt werden
(Datenmodell-Transformation). Die daraus entstehenden Komponenten-Schemata
KAPITEL 5. ENTWICKLUNG DES ZIS
71
werden dann in die der Integration zur Verfügung gestellten Export-Schemata überführt. Im Gegensatz zu dem durch die 5-Ebenen-Schema-Architektur beschriebenen
Ansatz, werden die dabei durchzuführenden Transformationen im Rahmen dieser
Arbeit insofern erweitert, daß die Export-Schemata nicht nur den der Föderation
zur Verfügung gestellten Ausschnitt der Komponenten-Schemata darstellen, sondern gleichzeitig eine Modifikation der Komponenten-Schemata gemäß eines vordefinierten Integrationsansatzes realisieren. Somit handelt es sich nicht mehr nur
um eine reine Filterung, sondern um eine möglicherweise umfangreiche SchemaModifikation.
Warum ein solcher Integrationsansatz bei der Entwicklung des ZIS sinnvoll ist und
wie dieser im konkreten Fall aussieht, wird unter Punkt 5.3.1 beschrieben. Im Anschluß daran erfolgt die Entwicklung der Komponenten- und Export-Schemata der
dem Prototyp des ZIS zugrunde liegenden Datenquellen. Punkt 5.3.3 behandelt
dann den Entwurf des föderierten Datenbank-Schemas, basierend auf den ExportSchemata der jeweiligen Komponentensysteme.
5.3.1
Integrationsansatz
Das ZIS stellt einen Spezialfall föderierter DBSe dar. Gemäß den in [BLN86] vorgestellten Integrationsanforderungen müssen alle Schema-Konstrukte der zu integrierenden Export-Schemata in dem daraus resultierenden föderierten Schema enthalten
sein. Somit kann jedes Export-Schema als Subschema des föderierten Schemas aufgefaßt werden. Im Falle des ZIS ist nun der Durchschnitt aller dieser Subschemata
nicht leer, sondern beinhaltet ein für das ZIS wesentliches Konzept. Bevor mit der
Definition des Integrationansatzes fortgefahren wird, soll dieses Konzept kurz vorgestellt und der beschriebene Zusammenhang der Subschemata verdeutlicht werden.
Jedes Textdokument besteht aus einem Titel, einer nicht-leeren Menge von Autoren
und dem eigentlichen Text. Im folgenden werden Textdokumente in Hinblick auf das
ZIS als Artikel bezeichnet. Diese sind in einem oder mehreren Publikationsorgan(en)
(Zeitschrift, Tagungsband, o.ä.) veröffentlicht. Jedes dieser Publikationsorgane besteht aus einer Menge von Publikationsausgaben (issues), aufgeteilt in chronologisch
aufeinanderfolgende Bände (volumes). Innerhalb eines Bandes besitzt jede Ausgabe
eine eindeutige Nummer. Dieser Zusammenhang, möglicherweise jedesmal auf eine
andere Art modelliert, ist Bestandteil jeder Datenquelle des ZIS und demzufolge
auch im föderierten Schema enthalten.
Um die spätere Integration so weit wie möglich zu erleichtern, wird nun ein als Integrationsansatz bezeichnetes Schema entwickelt, welches den beschriebenen Ausschnitt der realen Welt modelliert und als Grundlage für die Entwicklung der
Export-Schemata der jeweiligen Komponentensysteme dient. Das bedeutet, daß im
Idealfall jedes Export-Schema den Integrationsansatz als Teilschema beinhaltet. Das
integrierte Schema umfaßt dann neben dem Integrationsansatz alle übrigen in wenigstens einem der Export-Schemata vorkommenden Konstrukte. Im folgenden wird
die Entwicklung des Integrationsansatzes für das ZIS beschrieben und die dabei
auftretenden Probleme erläutert. Hierbei wird ein weiterer Vorteil der Definition
eines Integrationsansatzes ersichtlich. Die Probleme bei der Modellierung des oben
dargestellten Ausschnitts der realen Welt können im Vorfeld der unterschiedlichen
Schema-Transformationen global gelöst bzw. behandelt werden und müssen nicht
bei jedem lokalen System erneut beachtet werden.
Bei der Modellierung des Integrationsansatzes für das ZIS exisitiert die Problematik, daß die eindeutige Identifikation von Artikeln nicht explizit vorhanden ist,
beispielsweise durch eine weltweit eindeutige Dokumentnummer. Es muß also eine
KAPITEL 5. ENTWICKLUNG DES ZIS
72
Methode gefunden werden, die die Identifikation von Artikeln innerhalb des ZIS
gewährleistet. Einige mögliche Identifikations-Methoden sowie ihre Verwendbarkeit
in Hinblick auf das ZIS werden im folgenden kurz vorgestellt.
5.3.1.1
Identifikation durch den Dokumenttitel
Eine Möglichkeit, Artikel innerhalb des ZIS als unterschiedlich bzw. identisch zu
erkennen, besteht darin, den Dokumenttitel als Identifikationsgrundlage zu verwenden. Diese Methode ist allerdings wenig hilfreich, da einerseits unterschiedliche
Artikel den gleichen Titel haben können (Homonyme), andererseits verschiedene
Titel dasselbe Dokument referenzieren können (Synonyme). Synonyme entstehenden dabei vorwiegend durch inkorrekte Daten in den jeweiligen Datenbanken, die
beispielsweise durch Rechtschreibfehler verursacht worden sind.
5.3.1.2
Identifikation durch den Publikationskontext
Eine andere Möglichkeit, Artikel zu identifizieren, ist durch den Publikationskontext (Publikationsname, Band, Ausgabe, Seiten) gegeben. Hierbei können Artikel
unabhängig vom Dokumenttitel unterschieden werden. Allerdings zieht diese Art
der Identifizierung neue Probleme nach sich. Zum einen gilt für den Namen einer
Zeitschrift das gleiche wie für den Dokumenttitel eines Artikels (Homonyme, Synonyme), zum anderen könnten schon minimale Abweichungen bei der Angabe der
Seitenzahlen dazu führen, daß das System gleiche Artikel als unterschiedlich identifiziert. Zeitschriften besitzen zwar analog zu den ISBN-Nummern von Büchern
eine ISSN-Nummer, die eine eindeutige Identifikation ermöglicht, allerdings wird
diese nicht durchgängig verwendet bzw. angegeben und ist somit nicht als Identifikationsargument ausreichend. Synonyme Publikationsnamen können mit Hilfe einer
Synonym-Tabelle homogenisiert werden, wobei aber beachtet werden muß, daß die
Implementierung bzw. Erweiterung einer solchen Tabelle, gerade bei der Einbindung
neuer Komponentensysteme, einen nicht unerheblichen Arbeitsaufwand darstellt.
Der wesentlichste Nachteil dieser Methode besteht allerdings darin, daß gleiche Artikel, die in unterschiedlichen Publikationskontexten veröffentlicht sind, nicht als
identisch identifiziert werden können.
Neben diesen allgemeinen Hindernissen ensteht ein weiteres Problem in Hinblick auf
das ZIS, das auf dem relationalen Datenmodell basiert. Der Publikationskontext
würde in diesem Zusammenhang als Primär-Schlüssel einer Tabelle A fungieren.
Eine Tabelle B, die einen A einschließenden Beziehungstyp repräsentiert, würde
mittels eines Fremd-Schüssels den Primär-Schlüssel von A referenzieren. Da der
Publikationskontext aus einer nicht geringen Menge von Attributen besteht, würden
Anfragen, die B mit einbeziehen, recht umfangreich gestaltet werden müssen.
5.3.1.3
Identifikation durch das Tupel (Titel, Autoren)
Zusätzlich zum Dokumenttitel die nicht-leere Menge der Autorennamen als Identifikationsgrundlage hinzuzuziehen, beschreibt eine weitere Möglichkeit, Artikel zu
unterscheiden. Hierbei tritt in erster Linie das Problem auf, daß mehrwertige Attribute von vielen Datenmodellen (insbesondere vom relationalen Modell) nicht unterstützt werden, so daß die Bildung eines Schlüssels, der den Dokumenttitel und
die Autorennamen umfaßt, nicht ohne weiteres möglich ist. Gelöst werden könnte
dieses Problem dadurch, daß die Menge der Autorennamen zu einem String zusammengefaßt und dadurch ein einwertiges Attribut generiert werden würde. In
KAPITEL 5. ENTWICKLUNG DES ZIS
73
der Forschungsliteratur-Datenbank der Abteilung DBIS wird die Menge der Autorennamen auf diese Weise als atomares Attribut gespeichert. Wiederum besteht
allerdings das Problem, daß die Angabe der Autorennamen nicht immer eindeutig
ist. So könnte beispielsweise der Name ’Ramez Elmasri’ als ’Elmasri, R.’, ’Elmasri’,
’R. Elmasri’, ’Elmasri, Ramez’ in den verschieden Datenquellen gespeichert sein.
Andererseits ist es möglich, daß die Menge der Co-Autoren nicht vollständig erfaßt
ist. Insgesamt stellt diese Möglichkeit also keine zufriedenstellende Alternative für
die Identifikation von Zeitschriftenartikeln dar.
5.3.1.4
Identifikation durch den Benutzer
Nachdem gezeigt wurde, daß die Identifikation von Zeitschriftenartikeln nicht eindeutig gewährleistet werden kann, bietet sich als letzte Möglichkeit an, diese Identifikation vollständig dem Benutzer zu überlassen. Hierbei besteht allerdings die Problematik, den gegebenen Sachverhalt korrekt zu modellieren, da viele Datenmodelle
die Angabe eines eindeutigen Schlüssels fordern, um Objekte des gleichen Objekttyps zu unterscheiden und die Implementierung von Beziehungstypen ermöglichen
zu können. Bei der Identifikation durch den Benutzer existiert jedoch gerade keine Identifikationsgrundlage, die als Schlüssel eines Objekttyps verwendet werden
könnte.
In Hinblick auf das relationale ZIS könnte das Problem dadurch gelöst werden,
daß alle Attribute einer einzigen Tabelle zugeordnet werden und somit keine einen
Beziehungstyp repräsentierenden Tabellen benötigt würden. In diesem Fall könnte
der Schlüssel aus allen Attributen der singulären Tabelle zusammengesetzt sein. Da
es sich beim ZIS im wesentlichen (mit Ausnahme der Arbeitsdatenbank) um eine
logische Implementierung handelt, ist dieser Ansatz durchaus überlegenswert, aber
zum einen nicht sehr elegant und zum andern in Hinblick auf die Formulierung von
Anfragen nicht sehr benutzerfreundlich.
Eine andere Möglichkeit besteht darin, daß jede Datenquelle für jeden gespeicherten
Artikel eine innerhalb dieser Quelle eindeutige Dokumentnummer generiert. Um bei
der Integration Überschneidungen zu verhindern und gleichzeitig die Verwendung
dieser Dokumentnummern als globalen Schlüssel zu ermöglichen, müssen die Mengen, die jeweils alle Dokumentnummern einer Datenquelle enthalten, disjunkt sein.
Mit Hilfe der Dokumentnummer als Schlüssel können dann Beziehungen zwischen
Objekten modelliert werden.
5.3.1.5
Identifikation von Artikeln innerhalb des ZIS
Die Identifikation von Zeitschriftennamen wird innerhalb des ZIS durch den Einsatz
einer Synonym-Tabelle realisiert, wohingegen die Identifikation von Artikeln, wie beschrieben, dem Benutzer überlassen wird. Dabei wird zu jedem Artikel eine global
eindeutige Nummer generiert, wobei jedem Komponentensystem eine bestimmte
Menge möglicher Dokumentnummern zugeordnet wird, so daß keine Überschneidungen innerhalb des ZIS entstehen können. Sind solche Nummern innerhalb einer
Datenquelle bereits integriert (z.B. bei der DBIS Forschungsliteratur-Datenbank),
so muß die Menge dieser Nummern gegebenfalls auf die durch die Föderation zugewiesene Menge abgebildet werden. Mit der inversen Abbildung der globalen auf die
lokalen Dokumentnummern lassen sich dann die entsprechenden Artikel aus dem
Komponentensystem extrahieren. Sind hingegen keine Dokumentnummern innerhalb einer Datenquelle vorhanden, wie beispielsweise bei einem WSDBS, so werden
diese bei jeder Anfrage durch das ZIS neu generiert. Eine eindeutige Abbildung der
74
KAPITEL 5. ENTWICKLUNG DES ZIS
globalen auf die imaginären lokalen Dokumentnummern ist in diesem Fall natürlich
nicht möglich.
Zusammenfassend läßt sich also feststellen, daß gleiche Artikel aus unterschiedlichen
Quellen bzw. unterschiedlichen Publikationen vom ZIS nicht als identisch identifiziert werden können und somit eine Duplikatbildung in den Anfrageergebnissen
möglich ist. Der Benutzer kann aber mit Hilfe entsprechender Anfragen an die Arbeitsdatenbank solche Duplikate erkennen und gegebenenfalls eliminieren.
5.3.1.6
Integrationsansatz des ZIS
Nachdem die Identifikation von Artikeln innerhalb des ZIS ausführlich dargestellt
wurde, kann nun der am Anfang des Abschnitts beschriebene Ausschnitt der realen
Welt modelliert und als Integrationsansatz bei der Entwicklung der Komponentenund Export-Schemata genutzt werden. Da das föderierte Schema des ZIS auf dem
relationalen Datenmodell basiert, wird der Integrationsansatz auch durch dieses
Modell beschrieben.
ARTICLE
DokNr
Title
PUBRELEASE
NOT NULL
NOT NULL
AUTHOR
DokNr
Name
DokNr
PubName
Volume
Issue
Pages
Year
Month
NOT NULL
NOT NULL
PUBLICATION
PubName NOT NULL
NOT NULL
NOT NULL
Abbildung 5.6: Integrationsansatz des ZIS
In Abb. 5.6 ist das Schema-Diagramm des Integrationsansatzes dargestellt. Die Tabelle ARTICLE besteht aus dem Attribut DOKNR, das die globale Dokumentnummer
repräsentiert und somit als Primär-Schlüssel fungiert, sowie dem DokumenttitelAttribut TITLE. In der Tabelle PUBLICATION sind die Namen der verschiedenen
Publikationen gespeichert, wohingegen AUTHOR zu jedem Dokument die entsprechenden Autoren enthält. Das Attribut DOKNR stellt hierbei eine Referenz auf die
Tabelle ARTICLE dar. Schließlich modelliert die Tabelle PUBRELEASE eine Beziehung zwischen ARTICLE und PUBLICATION unter Hinzuziehung weiterer Attribute,
wie z.B. VOLUME oder ISSUE. Dieses Schema wird im folgenden bei der Entwicklung
der Export-Schemata als Modellierungsgrundlage verwendet und dabei versucht,
den dargestellten Zusammenhang so gut wie möglich nachzubilden.
5.3.2
Entwicklung der Komponenten-/Exportschemata
Die Entwicklung der Komponenten- bzw. Export-Schemata verläuft in Abhhängigkeit der zugrunde liegenden Datenquelle auf unterschiedliche Art und Weise. So
entfällt bei den relationalen DBSen die Datenmodell-Transformation, die die lokalen Schemata in ein einheitliches Modell überführen soll, da das globale Datenmodell des ZIS ebenfalls relational ist. Auf der anderen Seite werden die hierarchischen WSDBSe unmittelbar in die der Integration zur Verfügung stehenden
75
KAPITEL 5. ENTWICKLUNG DES ZIS
Export-Schemata transformiert. Diese Vorgehensweise entspricht dabei nicht der in
dem ZIS-Architekturmodell enthaltenen strikten Trennung zwischen DatenmodellTransformation und Schema-Modifikation. Allerdings wurde diese Trennung bereits bei der Beschreibung der 5-Ebenen-Schema-Architektur als eine rein technische Konstruktion betrachtet, die lediglich die unterschiedlichen Transformationsverfahren verdeutlichen soll. Da keine eindeutige Abbildung vom hierachischen in
das relationale Modell existiert, würde es einen unnötigen Arbeitsaufwand darstellen, die Schema-Modifikation nicht parallel zur Datenmodell-Transformation durchzuführen. Es sei jedoch darauf hingewiesen, daß diese Parallelisierung nicht für jede
Datenquelle sinnvoll sein muß.
Die Entwicklung der Export-Schemata im Falle der hierarchischen Datenbanken innerhalb des ZIS wird dabei wie folgt durchgeführt. Zuerst werden die einem lokalen
Schema zugrunde liegenden Konzepte unter Berücksichtigung des Integrationsansatzes auf das ER-Modell abgebildet. Danach wird das dabei entstandene Schema
gemäß den existierenden Überführungsregeln in ein relationales Schema transformiert, welches dann der Föderation als Export-Schema zur Verfügung gestellt wird.
Abschließend bleibt festzuhalten, daß für die unterschiedlichen Schema-Transformationen keine allgemeingültigen Verfahrensweisen exisitieren und es dem jeweiligen Systemadministrator obliegt, korrekte Abbildungen zu entwickeln, ohne daß
semantische Differenzen zu Tage treten. Im Anschluß wird nun die Entwicklung der
Export-Schemata der in dem Prototyp des ZIS enthaltenen Komponentensysteme
beschrieben.
5.3.2.1
ACM Digital Library
Am Beispiel des WSDBS der ACM Digital Library sollen alle für die Entwicklung des
Export-Schemas notwendigen Transformationsansätze ausführlich erläutert werden.
Die hierbei angewendeten Verfahren können dann als Grundlage für andere in das
ZIS zu integrierende WSDBSe dienen.
Zunächst wird das auf dem hierarchischen Datenmodell basierende konzeptionelle Schema des WSDBS in das ER-Modell überführt. Dabei wird als erstes jeder
Record-Typ in einen entspechenden Entity-Typen transformiert und jeder ParentChild-Relationship-Typ auf einen Relationship-Typ des ER-Modells abgebildet. Die
an einer Beziehung beteiligten Objekte besitzen dabei die durch das hierarchische
Schema implizit bzw. explizit definierten Kardinalitäten. Auf eine graphische Darstellung des Schemas wird aus Trivialitätsgründen verzichtet.
Im Anschluß an diese als 1:1 zu betrachtende Transformation werden nun bestimmte, in Beziehung zueinander stehende Entity-Typen in Hinblick auf den durch den
Integrationsansatz definierten Sachverhalt zusammengefaßt, wobei die Semantik des
Schemas jedoch nicht verletzt werden darf. Im Falle des zuvor entworfenen ERSchemas können folgende Entity-Typen zusammengefaßt werden.
PUBTYPE, PUBLICATION, PUBDETAILS
PUBVOLUME, PUBISSUE
ARTICLE, DETAILS
7−→
7−→
7−→
PUBLICATION
PUBRELEASE
ARTICLE
Bei diesen Zusammenfassungen bleibt die Semantik erhalten, da es sich bei den
jeweiligen Beziehungen ausschließlich um solche vom Typ 1:n oder 1:1 handelt. Das
dadurch entstehende ER-Schema ist in Abb. 5.7 dargestellt, wobei in dieser Phase
auf die korrekte Einhaltung der Regeln des ER-Modells insofern verzichtet wird, als
daß nicht zwingend für jeden Entity-Typ ein Schlüssel definiert sein muß.
76
KAPITEL 5. ENTWICKLUNG DES ZIS
URLFullText
Abstract
Name
AUTHOR
AA
AK
ARTICLE
Title
KEYWORDS
Word
Pages
AP
Month
Volume
PUBRELEASE
Issue
Year
PP
CurIssue
DokType
PUBLICATION
ISSN
Descr.
PubName
Abbildung 5.7: Modellierung des lokalen Schemas im ER-Modell (I)
Wie in Abbildung 5.7 zu erkennen, besitzen die Relationship-Typen PP und AP keine
Attribute. In diesem Fall kann die indirekte Beziehung zwischen PUBLICATION und
ARTICLE auf die Art und Weise als eine direkte Beziehung modelliert werden, indem
der Entity-Typ PUBRELEASE in einen Relationship-Typ transformiert wird und AP
und PP aus dem Schema entfernt werden. Abschließend werden noch zwei Änderungen in Hinblick auf den Integrationsansatz durchgeführt. Zum einen wird, wie
im Vorfeld ausführlich erläutert, das Attribut DOKNR als Schlüssel des Entity-Typs
PUBLICATION in das Schema integriert und zum anderen wird das Attribut PAGES
von ARTICLE dem zuvor modellierten Relationship-Typ PUBRELEASE zugeordnet.
Wie die Dokumentnummer generiert wird und wie die Übersetzung einer relationalen Anfrage in eine WS/QL-Anfrage erfolgt, wird in Abschnitt 5.4 beschrieben.
Zum jetzigen Zeitpunkt wird einfach davon ausgegangen, daß ein solches Attribut
neu hinzugefügt werden kann, ohne daß Probleme jedweder Art auftreten.
Das so entwickelte ER-Schema ist in Abb. 5.8 zu erkennen. Unter Berücksichtigung
der, für die Transformation von ER- in relationale Schemata geltenden, allgemeinen
Regeln erfolgt zum Abschluß die Transformation in das relationale Schema, das
gleichzeitig das Export-Schema des Komponentensystems der ACM Digital Library
darstellt und in Abb. 5.9 zu sehen ist.
5.3.2.2
DBIS Literaturdatenbank
Wie bereits erwähnt, muß im Falle von relationalen Komponentensystemen innerhalb des ZIS keine Datenmodell-Transformation durchgeführt werden. Somit wird
bei der DBIS-Datenbank ausschließlich eine Schema-Modifikation durchgeführt, die
eine Filterung im Sinne der 5-Ebenen-Schema-Architektur miteinschließt.
Zunächst wird der Bereich der Filterung betrachtet. Die Frage hierbei ist, welche
Konzepte, d.h. in diesem Fall welche Relationen bzw. Attribute, sollen dem ZIS
zur Verfügung gestellt werden, oder umgekehrt ausgedrückt, welche Informationen
werden vom ZIS benötigt. In Hinblick auf den Integrationsansatz sind die darin
enthaltenen Meta-Daten, sofern sie Bestandteil der FLIT sind, absolut notwendig.
Demgegenüber kann auf die internen Informationen, wie diverse Anmerkungen oder
77
KAPITEL 5. ENTWICKLUNG DES ZIS
Abstract
Name
AUTHOR
AA
URLFullText
AK
ARTICLE
Title
KEYWORDS
Word
DokNr
Volume
Month
PUB
RELEASE
Issue
Year
Pages
CurIssue
DokType
PUBLICATION
ISSN
PubName
Descr.
Abbildung 5.8: Modellierung des lokalen Schemas im ER-Modell (II)
KEYWORDS
ARTICLE
AUTHOR
DokNr
Word
DokNr
NOT NULL
Title
NOT NULL
Abstract
URLFullText
DokNr
Name
NOT NULL
NOT NULL
NOT NULL
NOT NULL
PUBRELEASE
DokNr
PubName
Volume
Issue
Pages
Year
Month
NOT NULL
NOT NULL
PUBLICATION
PubName NOT NULL
DokType
CurIssue
ISSN
Description
Abbildung 5.9: Export-Schema der ACM Digital Library
Signaturen ebenso verzichtet werden, wie auf Angaben zur Auflage etc. Wichtig ist
wiederum die Information über den Standort innerhalb der Abteilung. Grundsätzlich läßt sich sagen, daß prinzipiell alle Konzepte der FLIT in das ZIS einfließen
können, dies würde aber zur Unübersichtlichkeit des Systems führen, vor allem unter dem Gesichtspunkt, daß die Möglichkeit besteht, weitere Quellen in das ZIS zu
integrieren.
Abschließend soll noch eine Eigenschaft der DBIS-Datenbank näher betrachtet werden. Zum einen die Beziehung zwischen dem Attribut MONAT und der Tabelle
L MONAT. Wie bereits bei der Beschreibung des lokalen Schemas erwähnt, werden
in der Tabelle DOKUMENT die Monatsnamen in Form von Abkürzungen, wie bspw.
’Dez’, ’Jan’ etc. gespeichert. In der Tabelle L MONAT ist jedoch für jede Abkürzung
unter dem Attribut EXPL der vollständige Name des entsprechenden Monats gespeichert. In dem Export-Schema der Datenbank soll nun der volle Name repräsentiert
werden, so daß alle Daten des Attributs MONAT durch die entsprechenden Einträge
des Attributs EXPL der Tabelle L MONAT ersetzt werden müssen.
78
KAPITEL 5. ENTWICKLUNG DES ZIS
KEYWORD
DokNr
Word
ARTICLE
NOT NULL
NOT NULL
DokNr
NOT NULL
NOT NULL
Title
Autoren
Standort
Language
PUBRELEASE
DokNr
PubName
Volume
Issue
Pages
Year
Month
NOT NULL
NOT NULL
PUBLICATION
PubName
DokType
Publisher
NOT NULL
Abbildung 5.10: Export-Schema der DBIS-Datenbank
In der Abb. 5.10 ist das Export-Schema der DBIS-Datenbank dargestellt. Dabei sind
die Attribut- bzw. Tabellennamen des lokalen Schemas durch die Bezeichnungen des
Integrationsansatzes ersetzt worden.
5.3.2.3
DBLP Bibliographie-Server
Die Entwicklung des Exportschemas des DBLP Bibliographie-Servers verläuft analog zu der der ACM Digital Library und soll in diesem Zusammenhang nicht mehr
ausführlich besprochen werden. Abb. 5.11 zeigt das entwickelte Export-Schema.
ARTICLE
AUTHOR
DokNr
NOT NULL
Title
NOT NULL
URLFullText
DokNr
Name
NOT NULL
NOT NULL
PUBRELEASE
DokNr
PubName
Volume
Issue
Pages
Year
NOT NULL
NOT NULL
PUBLICATION
PubName NOT NULL
Publisher
Abbildung 5.11: Export-Schema des DBLP Bibliographie-Server
KAPITEL 5. ENTWICKLUNG DES ZIS
5.3.3
79
Entwicklung des föderierten Schemas
Nachdem die Export-Schemata der an dem Prototyp des ZIS beteiligten Komponentensysteme vorgestellt wurden, kann nun mit der Entwicklung des föderierten
Schemas begonnen werden. In diesem Zusammenhang spielt der Integrationsansatz
keine Rolle mehr. Durch den Integrationsansatz wurde allerdings erreicht, und zu
diesem Zweck wurde er ja auch eingeführt, daß die jeweiligen Export-Schemata
starke Ähnlichkeiten aufweisen und die Integration somit erleichtert werden kann.
Zunächst werden nun im Rahmen einer Vorintegrationsphase die Unterschiede bzw.
Gemeinsamkeiten der jeweiligen Export-Schemata bestimmt. Übereinstimmungen
in den Schemata werden dabei durch sogenannte Inter-Schema-Korrespondenzen
festgehalten. In [Con97] werden verschiedene Lösungsansätze zur Schema-Integration vorgestellt, unter anderem auch die zusicherungsbasierte Integration, bei der die
Inter-Schema-Korrespondenzen durch sogenannte Zusicherungen formuliert werden.
Für diese Formulierungen wird ein spezielles Modell, das sogenannte Generische
Datenmodell (GDM) genutzt, das mit wenigen Modellierungskonzepten auskommt
und die Aufgaben, die bei der Integration entstehen, erleichtern soll. Dieses Modell
wird hauptsächlich zur Auflösung von strukturellen Konflikten benötigt.
Wie bereits erwähnt, stellt das ZIS einen Sonderfall föderierter DBSe dar. Das bedeutet in erster Linie, daß keine Informationen aus den verschiedenen lokalen Schemata miteinander verknüpft werden, sondern die Informationen lediglich zusammengefaßt werden, um dem Benutzer eine einheitliche Sicht auf die verschiedenen
Datenquellen zu offerieren, ohne daß diese Informationen untereinander in Beziehung stehen. Durch den Integrationsansatz wurde weiterhin gewährleistet, daß die
Export-Schemata in ähnlicher Weise modelliert sind und somit keine umfangreichen
Schema-Änderungen erfolgen müssen. Aus diesen Gründen wird im Rahmen dieser
Arbeit auf den Einsatz von formalen Integrationsmethoden, wie bspw. der zusicherungsbasierten Integration verzichtet, da die Beschreibung und Aufbereitung des
formellen Kontextes in keinem Verhältnis zur Lösung der vorhandenen Probleme
stehen würde.
Im folgenden soll nun die Integration der lokalen Schemata beschrieben werden. Dazu wird eine, wie in [Con97] erläutert, gewichtete Integrationsstrategie verwendet.
Dies hat einerseits den Vorteil, daß im nachhinein zu integrierende Datenquellen
in das System eingebunden werden können, ohne daß alle Komponentensysteme
erneut in den Integrationsvorgang miteinbezogen werden müssen, wie es z.B. bei
einer One-Shot-Integrationsstrategie der Fall wäre. Andererseits lassen sich die bei
der Integration jeweils zu lösenden Probleme einfacher beschreiben. Zuerst werden
nun die Export-Schemata der ACM Digital Library (Abb. 5.9) und des DBLP Bibliographie Server (Abb. 5.11) integriert.
Man erkennt, daß die Tabellen AUTHOR sowie PUBRELEASE der jeweiligen Systeme
einander genau entsprechen. Die Tabelle PUBLICATION enthält bei ACM neben den
mit DBLP gemeinsamen Attributen PUBNAME und ISSN zusätzlich die Attribute
CURISSUE, DOKTYPE und DESCRIPTION. Diese Attribute können ohne Probleme in
die Tabelle aufgenommen werden, wobei sie als optionale Attribute zu betrachten
sind, da DBLP diese Attribute nicht enthält und somit auch keine Daten bezüglich
dieser Attribute liefern kann. Die Werte des Attributs PUBNAME müssen, wie im
Vorfeld besprochen, gemäß einer Synonym-Tabelle angeglichen werden. Die Tabelle
PUBLICATION der DBLP enthält das Attribut PUBLISHER, das bei ACM nicht zu
finden ist. Dieses Attribut enthält den Namen des Verlags, in der die Publikation
veröffentlicht wurde. Dabei handelt es sich im Falle der ACM um ein sogenanntes
implizites Attribut, denn es ist insofern in der ACM Digital Library enthalten, als
daß jede Publikation dieser Datenquelle von der ACM veröffentlicht wurde und es
80
KAPITEL 5. ENTWICKLUNG DES ZIS
somit kein Problem darstellt, dieses Attribut bei der Anfragebearbeitung zu generieren. Im nächsten Abschnitt wird ausführlicher auf die Behandlung impliziter Attribute eingegangen. Primär-Schlüssel dieser Tabelle ist das Attribut PUBNAME, das
aufgrund der Synonym-Tabelle die Eindeutigkeit garantiert. Die jeweiligen Tabellen
ARTICLE sind bis auf das Attribut ABSTRACT, das in der ACM zusätzlich enthalten ist, äquivalent zueinander. Nun besitzt die Digital Library noch eine zusätzliche
Tabelle, nämlich KEYWORDS. Diese Tabelle besitzt einen Fremd-Schlüssel, der das
Attribut DOKNR der Tabelle ARTICLE referenziert. Die Aufnahme dieser Tabelle in
das föderierte Schema verursacht somit keine syntaktischen oder semantischen Probleme. Das somit entstandene Schema wird im weiteren Verlauf als Teilintegration
bezeichnet.
KEYWORDS
ARTICLE
AUTHOR
DokNr
Word
DokNr
NOT NULL
Title
NOT NULL
Abstract
Source
Language
DokNr
Name
NOT NULL
NOT NULL
NOT NULL
NOT NULL
PUBRELEASE
DokNr
PubName
Volume
Issue
Pages
Year
Month
NOT NULL
NOT NULL
PUBLICATION
PubName NOT NULL
DokType
CurIssue
ISSN
Description
Publisher
Abbildung 5.12: Föderiertes Schema des ZIS
Die Teilintegration wird nun zusammen mit dem Export-Schema der DBIS-Datenbank in das Schema des Zeitschriften-Informationssystems integriert. Dabei muß,
und das ist in diesem Zusammenhang wesentlich, das Attribut AUTOREN im föderierten Schema gemäß der Teilintegration als Tabelle modelliert werden, wobei das
Attribut NAME jeweils nur einen Autorennamen enthält. Wie diese Aufgabe durch
das ZIS gelöst wird, wird ebenfalls im nächsten Kapitel beschrieben. Im übrigen
wird die Teilintegration nur um einige Attribute ergänzt, die als einzige Bedingung
haben, daß sie optionalen Charakter besitzen, da diese Attribute nicht von den anderen Komponentensystemen unterstützt werden. Das vollständige föderierte Schema
des ZIS ist in Abbildung 5.12 dargestellt.
5.4
Anfragebearbeitung
Nachdem im vorhergehenden Abschnitt das föderierte Schema des ZIS entwickelt
wurde, erfolgt nun unter dem Gesichtspunkt der Anfragebearbeitung die dynamische Modellerweiterung der unter Punkt 5.2.2 vorgestellten ZIS-Architektur. Das
bedeutet, daß die für die Bearbeitung von Benutzeranfragen erforderlichen funktionalen Komponenten, die die verschiedenen Transformations- und Integrationsprozesse realisieren, in das System integriert werden.
Bevor jedoch die Beschreibung der funktionalen Komponenten erfolgt, wird ein kurzer Überblick über die an der Benutzerschnittstelle durch das ZIS zur Verfügung
81
KAPITEL 5. ENTWICKLUNG DES ZIS
gestellten Funktionen gegeben. Hierbei handelt es sich im wesentlichen um eine
eingeschränkte Form der Anfragesprache SQL. Daran anschließend erfolgt die Einbindung der zur Anfragebearbeitung benötigten funktionalen Komponenten in die
Architektur des ZIS. In diesem Zusammenhang werden zwei Gruppen von Komponenten unterschieden. Die Transformationsprozesse werden von Wrappern realisiert, die die Datenquellen einkapseln“ und deren Erscheinungsbild in Hinblick
”
auf das jeweilige Export-Schema verändern. Die Aufgaben der Integration dagegen werden von einem Mediator übernommen, dessen Funktionsweise Gegenstand
von Abschnitt 5.4.4 ist. Abschließend erfolgt die Beschreibung der mit dem ZIS
verbundenen Arbeitsdatenbank.
5.4.1
Benutzerschnittstelle
Durch die vom ZIS zur Verfügung gestellte Schnittstelle wird dem Benutzer die
Möglichkeit geboten, Anfragen in einer SQL-ähnlichen Form an das föderierte DBS
zu richten. Diese Anfragen werden dann jeweils in einer gemäß dem Export-Schema
modifizierten Form durch das ZIS an die Komponentensysteme weitergeleitet. Die
Ausgabe der Anfrageergebnisse kann dabei je nach Wunsch des Benutzers in eine Arbeitsdatenbank und/oder die jeweilige Standardausgabe geschrieben werden.
Unter Punkt 5.4.5 werden die Möglichkeiten der Arbeitsdatenbank näher erläutert.
Bei den von der Benutzerschnittstelle akzeptierten Anweisungen handelt es sich
um einfache SQL-Anfragen der Art SELECT-FROM-WHERE, wobei die dabei zur
Verfügung stehenden Argumente weiteren Restriktionen unterliegen. Im folgenden
werden die durch das ZIS implementierten Anfragemöglichkeiten ausführlich beschrieben.
Im wesentlichen läßt sich sagen, daß es sich bei den ZIS-Anfragen um sogenannte
select-project-join queries handelt. Dabei besitzt jede Anfrage die folgende Form 2
(Optionale Komponenten sind in Klammern [ ] dargestellt).
SELECT
FROM
[ WHERE
[ STORE | ADD ]
attribute list>
table list >
<condition > ]
<
<
Die aus der Datenbank zu extrahierenden Attribute werden durch das Argument
<attribute list> beschrieben, wohingegen die für die Ausführung der Anfrage benötigten Relationen durch das Argument <table list> bestimmt werden. Die optionalen
Argumente STORE bzw. ADD beeinflussen den Ausgabeort der Ergebnisse. Nähere
Informationen hierzu erfolgen bei der Beschreibung der Arbeitsdatenbank des ZIS.
Optional ist ebenfalls die Angabe von Auswahlbedingungen durch das Schlüsselwort WHERE. In diesem Zusammenhang werden auch die Einschränkungen deutlich, denen die ZIS-Anfragen im Vergleich zu allgemeinen SELECT-FROM-WHERE
Anweisungen unterliegen. Jede Auswahlbedingung muß innerhalb des ZIS folgender
Grammatik genügen:
condition >
selection>
<comp op>
<join>
<
<
::= <condition> AND <condition> | <selection> | <join>
::= ATTRIBUTE NAME <comp op> CONSTANT VALUE
::= = | != | > | < | >= | <= | LIKE
::= PRIMARY KEY ATT = FOREIGN KEY ATT
Die erste Restriktion im Bereich der Auswahlbedingung ist dadurch gegeben, daß die
verschiedenen Bedingungen nur durch ein logisches AND verknüpft werden dürfen.
2 Beim Prototypen des ZIS sind die Anfragen als JAVA-Methoden realisiert, wobei die Argumente beim Programmaufruf übergeben werden. Damit entfallen Aufgaben wie lexikalische oder
syntaktische Analyse, wie sie bei allgemeinen SQL-Anfragen benötigt werden.
KAPITEL 5. ENTWICKLUNG DES ZIS
82
Es ist aber mit Hilfe der Arbeitsdatenbank möglich, beliebige OR-Verknüpfungen zu
simulieren. Auf diese Möglichkeit wird bei der Beschreibung der Arbeitsdatenbank
näher eingegangen.
Wie zu erkennen, handelt es sich bei der Auswahlbedingung <join> im Sinne der
relationalen Algebra um einen als Equijoin bezeichneten Verbund zweier Tabellen. Dabei dürfen an einem <join> lediglich ein Primär-Schlüssel sowie der diesen
Schlüssel refenzierende Fremd-Schlüssel einer anderen Tabelle beteiligt sein. Somit
läßt sich feststellen, daß ein <join> einzig und allein zu dem Zweck genutzt werden
kann, unterschiedliche Tabellen vollständig miteinander zu verknüpfen.
Als Vergleichsoperator läßt sich der für SQL typische LIKE-Operator einsetzen, der
es gestattet, lediglich Teile einer Zeichenkette in eine Vergleichsoperation miteinzubeziehen. Im Gegensatz zu SQL darf allerdings nur das ’%’-Zeichen verwendet
werden, das als Platzhalter für beliebig lange Zeichenketten steht.
5.4.2
Dynamische Modellerweiterung
Unter Punkt 5.2.2 wurde das dem ZIS zugrunde liegende Architekturmodell beschrieben und im weiteren Verlauf die Schemata der verschiedenen Ebenen entwickelt. Dabei blieb unberücksichtigt, durch welche Funktionen die dabei entstandenen Transfomationen sowie die Integration der unterschiedlichen Schemata bei
der Anfragebearbeitung realisiert werden. Aus diesem Grund wird nun die vorgestellte Architektur um die funktionalen Systemomponenten erweitert, wie in Abb.
5.13 dargestellt.
Die bei der Integration der Komponentensysteme zu bewältigenden Aufgaben werden von einem Mediator übernommen. Im Bereich des ZIS liegt dessen Hauptaufgabe darin, eine globale Anfrage in verschiedene Teilanfragen gemäß den jeweiligen
Export-Schemata zu transformieren. Dabei können aufgrund der speziellen Art der
durch das ZIS implementierten Föderation viele bei allgemeinen föderierten DBSen
erforderlichen Konzepte unberücksichtigt bleiben. Auf diesen Gesichtspunkt wird
bei der Beschreibung des Mediator näher eingegangen.
Um die durch den Mediator an die Export-Schemata gerichteten (modifizierten)
Anfragen auf die lokalen Schemata der Komponentensysteme abzubilden und die
dabei entstehenden Ergebnismengen wieder rückzutransformieren, erfolgt der Einsatz von Wrappern. Durch die Wrapper werden die Datenquellen insofern einge”
kapselt“ als daß sich die Komponentensysteme der Föderation gegenüber nur noch
in Form ihrer Export-Schemata darstellen. Jeder Wrapper führt dabei die anfallenden Transformationen als Einheit“ durch. Somit ist für jede Datenquelle nur
”
ein Wrapper erforderlich, was bei der getrennten Ausführung der unterschiedlichen
Transformationen nicht der Fall wäre.
Schließlich ist in Abbildung 5.13 noch eine Arbeitsdatenbank in das System integriert. Diese Arbeitsdatenbank steht mit dem ZIS insofern in Verbindung, als daß
Anfrageergebnisse zum Zweck der späteren Nachbearbeitung in dieser Datenbank
gespeichert werden können. Die Arbeitsdatenbank wird dabei von einem dedizierten
DBMS verwaltet und hat keinen Einfluß auf das ZIS. Das konzeptionelle Schema
der Arbeitsdatenbank ist äquivalent zu dem föderierten Schema des ZIS. Anfragen
an die Arbeitsdatenbank können nicht innerhalb des ZIS gestellt werden, sondern
müssen direkt an das verwaltende DBMS gerichtet werden. In diesem Zusammenhang kann die Arbeitsdatenbank wiederum als ein spezielles Komponenten-DBS des
ZIS betrachtet werden.
83
KAPITEL 5. ENTWICKLUNG DES ZIS
Anwendung
Benutzer
Föderiertes
Schema
DBMS
Arbeits−DB
Mediator
Föderiertes Schema
Wrapper 1
Wrapper i
Wrapper n
ExportSchema
(extern)
ExportSchema
(extern)
....
ExportSchema
(extern)
Komponenten
Schema
Komponenten
Schema
....
Komponenten
Schema
Lokales Schema
(konzeptionell)
Lokales Schema
(konzeptionell)
....
Lokales Schema
(konzeptionell)
relational
relational
obj.−orient.
DBMS
relational
relational
relational
Internes Schema
strukturierte
KomponentenDB
strukturierte
KomponentenDB
Datenbank
Datenbank
relational
hierarchisch
DBMS
Internes Schema
relational
WSMS
....
Internes Schema
Web−Site
semi−strukturierte
KomponentenDB
Abbildung 5.13: Dynamische Modellerweiterung
5.4.3
Aufbau und Funktionsweise der ZIS-Wrapper
Wie bereits im Vorfeld erwähnt, werden die bei der Anfragebearbeitung durchzuführenden Transformationsprozesse innerhalb der Komponentensysteme von als
Wrappern bezeichneten Software-Komponenten des ZIS realisiert. Dabei muß jeder
Wrapper im wesentlichen zwei Aufgaben erfüllen: Zum einen müssen die in Hinblick
auf die Export-Schemata generierten Anfragen in für die lokalen Schemata verständliche Anfragen umgewandelt werden. Zum anderen müssen die von den lokalen
Schemata ausgegebenen Ergebnisse in die Form der Export-Schemata transformiert
werden. Unterschiedliche Transformationen, wie Schema-Modifikationen oder auch
Datenmodell-Transformationen, werden dabei von den Wrappern als Ganzes durchgeführt.
Innerhalb des ZIS können zwei Arten von Wrappern unterschieden werden. Einerseits die bei den relationalen Datenbanksystemen zum Einsatz kommenden Wrapper, sowie andererseits die für die WSDBSe zur Verfügung gestellten SoftwareKomponenten. Die der jeweiligen Gruppe angehörigen Wrapper weisen untereinander starke Gemeinsamkeiten in Bezug auf ihren Aufbau und ihre Funktionsweise
auf. Für jede dieser Gruppen sollen daher im folgenden die wichtigsten Eigenschaften dargestellt werden.
KAPITEL 5. ENTWICKLUNG DES ZIS
5.4.3.1
84
Wrapper für relationale Komponenten
Bei der Integration relationaler Komponentensysteme können die für die Transformation in die Export-Schemata benötigten Wrapper durch Sicht-Definitionen implementiert werden, die von den meisten relationalen DBSen zur Verfügung gestellt
werden. Sichten (views) entsprechen dabei den in der ANSI/SPARC-Architektur
enthaltenen externen Schemata und stellen eine logische Modifikation der durch das
konzeptionelle Schema definierten Datenbank dar. Die in diesem Zusammenhang
benötigten Transformationsprozesse werden durch das zugrunde liegende DBMS
realisiert, so daß das ZIS keine entsprechenden Software-Komponenten zur Verfügung stellen muß.
Im Falle der DBIS Forschungsliteratur-Datenbank, die auf einem Oracle-System
basiert, wird eine Sicht als eine virtuelle Tabelle betrachtet, die durch Attribute
anderer Tabellen realisiert wird. Die Definition erfolgt dabei mit Hilfe von SQLAnfragen, die die für eine Sicht benötigten Attribute aus den anderen im System
existierenden Tabellen bzw. im Vorfeld definierten Sichten herausfiltert. In diesem
Zusammenhang wird also das externe Schema durch eine Menge unterschiedlicher
Sichten gebildet. Diese Beschreibung weicht von der zu Beginn erfolgten Definition des Sicht-Begriffes als eine Menge von Relationen ab. Diese Unterscheidung ist
jedoch für die weiteren Überlegungen bedeutungslos.
Die Problematik bei den Sicht-Definitionen besteht darin, die in den Export-Schemata enthaltenen Integritäts-Bedingungen, wie z.B. Primär-Schlüssel, durch entsprechende SQL-Anfragen korrekt darzustellen. In den meisten Fällen können zu
diesem Zweck bereits bestehende Sichten in die Anfrage mit eingebunden werden, um so eine logische Vernetzung der verschiedenen Sichten zu erreichen. Eine Fremd-Schlüssel-Bedingung könnte z.B. durch ein SELECT DISTINCT auf den
Primär-Schlüssel der referenzierten Sicht realisiert werden. Dazu ist es erforderlich,
daß die den Primär-Schlüssel enthaltene Sicht bereits existiert. Die Reihenfolge der
Sicht-Definitionen kann also in Hinblick auf die korrekte Abbildung des ExportSchemas von Bedeutung sein. Es sei angemerkt, daß im Rahmen dieser Arbeit kein
Beweis dafür erbracht wird, daß die Export-Schemata grundsätzlich mit Hilfe von
Sichten implementiert werden können. Sollte eine entsprechende Implementierung
nicht möglich sein oder das DBS keine Sicht-Definitionen zur Verfügung stellen,
so müßte die Realisierung der funktionalen Transformations-Komponenten durch
den Einsatz von Software-Modulen, ähnlich zu den bei den WSDBSen verwendeten
Wrappern, vom ZIS gewährleistet werden.
Abschließend stellt sich die Frage, ob die in einer Föderation vorausgesetzte Autonomie der Komponentensysteme durch die Definition von Sichten verletzt wird, da
die Implementierung innerhalb der entsprechenden DBSe erfolgt und nicht durch
den Föderierungsdienst realisiert wird. Da aber zum einen die Export-Schemata
innerhalb der 5-Ebenen-Schema-Architektur als externe Schemata der Komponentensysteme betrachtet werden können und zum anderen Sicht-Definitionen keinen
Einfluß auf die lokale Funktionalität der an der Föderation beteiligten Systeme haben, wird im Rahmen dieser Arbeit die Autonomie als gewährleistet angesehen. Im
folgenden sollen nun die für das Export-Schema der DBIS-Datenbank verwendeten
Sicht-Definitionen vorgestellt werden (Abb. 5.14).
5.4.3.2
Wrapper für Web-Site Datenbanksysteme
Die Transformation des lokalen Schemas eines WSDBS in das für die Integration geeignete Export-Schema wird im Falle des ZIS durch den Einsatz eines sogenannten Translation-Wrapper realisiert. Jeder Translation-Wrapper vereint dabei
KAPITEL 5. ENTWICKLUNG DES ZIS
(1.)
CREATE VIEW
PUBLICATION (PubName, DokType, Publisher)
AS SELECT DISTINCT ZeitschrReihe, DokTyp, Verlag
FROM
DOKUMENT
WHERE
ZeitschrReihe IS NOT NULL
AND DokTyp = ’article’ ;
(2.)
CREATE VIEW
ARTICLE (DokNr, Title, Source, Language)
AS SELECT DISTINCT DokNr, Titel, Source, Sprache
FROM
DOKUMENT
WHERE
DokTyp = ’article’
AND ZeitschrReihe IN (SELECT PubName
FROM
PUBLICATION ) ;
(3.)
CREATE VIEW
(4.)
CREATE VIEW
KEYWORDS (DokNr, Word)
AS SELECT DISTINCT DokNr, Schlagwort
FROM
SCHLAGWORT
WHERE
DokNr
IN (SELECT DokNr
FROM
ARTICLE ) ;
85
PUBRELEASE (DokNr, PubName, Volume,
Issue, Pages, Year, Month)
AS SELECT DISTINCT A.DokNr, P.PubName, Band, Nummer,
Seite, Jahr, Expl
FROM
ARTICLE A, PUBLICATION P,
DOKUMENT D, L_MONAT M
A.DokNr = D.DokNr
WHERE
AND D.ZeitschrReihe = P.PubName
AND D.Monat = M.Monat ;
Abbildung 5.14: Sicht-Definitionen DBIS-Literatur-DB
die bei Datenmodell-Transformation und Schema-Modifikation durchzuführenden
Umwandlungen und übersetzt die in SQL formulierten Anfragen an das ExportSchema in entsprechende WS/QL-Anfragen, mit denen auf das jeweilige WSDBS
zugegriffen werden kann. Um eine korrekte Anfrageübersetzung zu gewährleisten,
enhält jeder Translation-Wrapper eine Translation-Table und eine gemäß dem lokalen Schema des zugrunde liegenden Web-Site zu konstruierende WS/QL-Schablone.
In der Translation-Table sind sämtliche Attribute des Export-Schemas zusammen
mit den jeweiligen Relationen sowie die dazu in Beziehung stehenden Objekte innerhalb des lokalen Schemas gespeichert. Mit Hilfe der von WS/QL zur Verfügung
gestellten Kommandos kann für jeden Web-Site eine allgemeine Schablone konstruiert werden, die eine einfache Anfrageübersetzung ermöglicht.
Bevor die Anfrageübersetzung am Beipiel des DBLP Bibliographie-Servers detailliert vorgestellt wird, muß noch eine für den weiteren Verlauf wichtige Vereinbarung getroffen werden. Unter Punkt 2.2.1 wurde ein hierarchisches DatenbankSchema als eine Menge hierarchischer Schemata beschrieben, ähnlich einem von
der Graphentheorie her bekannten Wald, der aus mehreren Bäumen besteht. Jede Ausprägung eines hierarchischen Schemas besteht wiederum aus mehreren Zustandsbäumen. Um die Anfrageübersetzung zu erleichtern, soll nun jedes hierarchische Datenbank-Schema, als auch dessen Ausprägung, als ein einzelner Baum be-
86
KAPITEL 5. ENTWICKLUNG DES ZIS
trachtet werden. Zu diesem Zweck erfolgt der Einsatz eines virtuellen Root-Records,
dessen Child-Records von den Root-Records aller bei der Ausprägung des hierarchischen Datenbank-Schemas entstehenden Zustandsbäumen gebildet werden. Somit
stellt sich jedes WSDBS als eine zusammenhängende Datenbank dar.
Durch die getroffene Vereinbarung können nun die in den SQL-Anfragen vorkommenden join conditions bei der Anfragebearbeitung als überflüssig betrachtet werden. Da diese conditions innerhalb des ZIS lediglich zur Verknüpfung von Tabellen
über Schlüssel-Attribute dienen, werden sie im Falle der hierarchischen Datenbanken, aufgrund der Tatsache, daß nun alle Records innerhalb eines Zustandsbaums
zu lokalisieren sind, nicht benötigt.
EXPORT−SCHEMA
Table
Attribut
ARTICLE
ARTICLE
ARTICLE
AUTHOR
AUTHOR
PUBLICATION
PUBLICATION
PUBRELEASE
PUBRELEASE
PUBRELEASE
PUBRELEASE
PUBRELEASE
PUBRELEASE
DokNr
Title
URLFullText
DokNr
Name
PubName
Publisher
DokNr
PubName
Volume
Issue
Pages
Year
LOCAL−SCHEMA
Attribute
RecordType
Level
No.
Title
URLFullText
ARTICLE
ARTICLE
6
6
1
1
Name
Name
Name
AUTHOR
PUBLICATION
PUBLISHER
7
2
1
1
1
1
Name
Volume
Issue
Pages
Year
PUBLICATION
PUBRELVOLUME
PUBRELISSUE
ARTICLE
PUBRELYEAR
2
4
5
6
3
1
1
1
1
1
Abbildung 5.15: Translation-Table des DBIS-Wrapper
Im folgenden wird nun am Beispiel des DBLP Bibliographie-Server die Entwicklung
eines Translation-Wrapper vorgestellt. In Abb. 5.15 ist die Translation-Table von
diesem Wrapper abgebildet. Als Grundlage hierbei wurden die im Vorfeld beschriebenen Schemata des DBLP-Server verwendet (Export-Schema: Abb. 5.10, lokales
Schema: 5.3). Generierte Attribute, wie beispielsweise DokNr, besitzen kein entsprechendes Gegenstück innerhalb des lokalen Schemas. Solche Attribute können somit
nicht ohne weiteres in den Übersetzungsvorgang miteingebunden werden. Da generierte Attribute innerhalb einer WHERE-Klausel nur in join conditions vorkommen
und diese, wie oben beschrieben, bei der Anfrageübersetzung nicht beachtet werden,
ist in diesem Zusammenhang lediglich das Auftreten solcher Attribute in einer SELECT-Klausel von Interesse. In einem solchen Fall kann ausgehend von einem dem
Komponentensystem zugewiesenen Startwert durch sukzessive Inkrementierung die
Generierung des Attributs erfolgen. Diese Vorgehensweise wird im weiteren Verlauf
noch durch ein Beispiel verdeutlicht. Angaben zu der Hierachieebene (level ) oder
dem Platz (No) werden für die Generierung korrekter WS/QL-Anfragen benötigt.
So kann beispielsweise mit Hilfe der Hierarchieebene der Pfad eines GET PATHKommandos bestimmt werden.
Eine mögliche WS/QL-Schablone des Translation-Wrapper der DBLP-Datenbank
ist in Abb. 5.16 dargestellt. Dabei folgen die verwendeten Begriffe der Syntax allgemeiner ZIS-Anfragen. Es sei darauf hingewiesen, daß der Gesichtspunkt der Performance bei der Entwicklung der Schablone nur eine untergeordnete Rolle gespielt
KAPITEL 5. ENTWICKLUNG DES ZIS
87
GET FIRST PATH DBLP, ..., [LNR]
WHERE <condition*> ;
while ( DB_STATUS== 0) {
System.out.println( <attribute list> ) ;
GET NEXT PATH DBLP, ..., [LNR]
WHERE <condition*> ;
}
Abbildung 5.16: WS/QL-Schablone für den DBLP-Server
hat und möglicherweise andere Schablone existieren die eine bessere Performance
aufweisen. Aufgrund der besseren Verständlichkeit ist jedoch diese Schablone bevorzugt worden.
Die Angabe des Pfades besteht dabei einerseits aus dem Root-Record, in diesem
Falle der virtuellen Wurzel DBLP, und reicht bis zur tiefsten Hierarchieebene (Last
Needed Record, LNR), die innerhalb der SQL-Anfrage benötigt wird. Der Ausdruck
<condition*> bezieht sich auf die von der Syntax einer ZIS-Anfrage her bekannte
<condition> bei der existierende join conditions allerdings eliminiert wurden. Abschließend soll nun beispielhaft die Übersetzung einer ZIS- in eine WS/QL-Anfrage
dargestellt werden (Abb. 5.17).
SELECT
FROM
WHERE
AND
AND
AND
DokNr, Title
ARTICLE A, PUBRELEASE R
A.DokNr = R.DokNr
Volume = ’20’
Issue = ’4’
PubName = ’ACM Computing Surveys’ ;
Int DokNr = 1000000 ; /* Initialisierung des zu generierenden Attributs
GET FIRST PATH
DBLP, PUBLISHER, PUBLICATION,
PUBRELYEAR, PUBRELVOLUME,
PUBRELISSUE, ARTICLE
WHERE
Volume = ’20’
AND Issue = ’4’
AND PubName = ’ACM Computing Surveys’ ;
while ( DB_STATUS== 0) {
System.out.println(DokNr++, ARTICLE.Title) ;
GET NEXT PATH DBLP, PUBLISHER, PUBLICATION,
PUBRELYEAR, PUBRELVOLUME,
PUBRELISSUE, ARTICLE
WHERE
Volume = ’20’
AND Issue = ’4’
AND PubName = ’ACM Computing Surveys’ ;
}
Abbildung 5.17: Beispiel für eine Transformation
88
KAPITEL 5. ENTWICKLUNG DES ZIS
5.4.4
Aufbau und Funktionsweise des ZIS-Mediators
Nachdem die Transformationsprozesse zwischen den lokalen sowie den Export-Schemata ausführlich erläutert wurden, erfolgt nun die Beschreibung des Integrationsprozesses. Die in diesem Zusammenhang zu bewältigenden Aufgaben werden wie
bereits erwähnt von einem Mediator übernommen. Dabei muß der Mediator im
wesentlichen zwei Funktionen erfüllen: Dies ist zum einen die Übersetzung einer
globalen Anfrage in entsprechend den jeweiligen Export-Schemata geeignete Teilanfragen. Zum anderen müssen die von den Komponentensystemen zurückgegebenen
Ergebnisse gemäß dem globalen Schema umgewandelt werden. In Hinblick auf das
ZIS muß dabei eine wesentliche Eigenschaft beachtet werden. Teilanfragen stehen
in keinerlei Beziehung zueinander, d.h., daß jede Teilanfrage autonom ausgeführt
werden kann. Daraus folgt gleichzeitig, daß die jeweiligen Anfrageergebnisse nicht
miteinander verknüpft werden müssen. Aufgrund dieser Tatsache kann auf die Generierung sogenannter Postprocessing-Anfragen, wie beispielsweise in [Con97] beschrieben, verzichtet werden. Der Mediator besitzt demnach den in Abb. 5.18 dargestellten Aufbau.
GA
GE = GE1 + GE2 + ... + GN n
MEDIATOR
GE 1
GA
AÜ
GE 2
GE 3
GA
EK
AÜ
KON 1
...
EK
Konnektor
Anfrage−Übersetzer
Ergebnis−Konverter
EK
KON n
KSE 2
KSA 2
KON =
AÜ
=
EK
=
AÜ
KON 2
KSE 1
KSA 1
GA
KSE n
KSA n
GA
GE
KSA
KSE
=
=
=
=
Globale Anfrage
Globales Ergebnis
Komponentensystem−Anfrage
Komponentensystem−Ergebnis
Abbildung 5.18: Aufbau des ZIS-Mediators
Für jedes Komponentensystem existiert ein als Konnektor bezeichnetes SoftwareModul. Jeder Konnektor wiederum besteht aus zwei Komponenten: einem Übersetzer und einem Konverter. Dem Übersetzer obliegt dabei die Aufgabe, die globale
Anfrage in eine in Hinblick auf das jeweilige Komponentensystem geeignete Teilanfrage zu übersetzen, während der Konverter jedes Anfrageergebnis in die globale
Darstellung umwandelt. Im folgenden werden die dabei zu lösenden Probleme beschrieben und anhand eines Beispiels verdeutlicht.
5.4.4.1
Anfrageübersetzer
Bei der Übersetzung einer globalen Anfrage in eine für die jeweiligen Komponentensysteme geeignete Form müssen unterschiedliche Probleme gelöst werden. Dazu
KAPITEL 5. ENTWICKLUNG DES ZIS
89
gehört z.B. die Behandlung impliziter Attribute bzw. von in den jeweiligen Schemata unterschiedlich modellierten Objekten. Viele Konflikte, wie beispielsweise die
unterschiedliche Benennung semantisch äquivalenter Konstrukte, konnten allerdings
bereits im Vorfeld durch die Definition des Integrationsansatzes gelöst werden. Auf
die Behandlung möglicher Konflikte im Rahmen des ZIS wird im Anschluß kurz
eingegangen.
Implizite Attribute
Manche Relationen innerhalb des globalen Schemas können Attribute enthalten, die
in bestimmten Komponentensystemen nur implizit vorhanden sind. Für das Komponentensystem der ACM Digital Library ist beispielsweise PUBLISHER aus der
Relation PUBLICATION ein implizites Attribut, da jeder in der Datenbank enthaltene Artikel von der ACM veröffentlicht wurde. Bei der Anfrageübersetzung können
sämtliche Verweise auf solche Attribute gelöscht werden, müssen aber bei der Umwandlung der Ergebnismenge durch den Konverter wieder integriert werden.
Attribute in unterschiedlichen Relationen
Ist ein Attribut des föderierten Schemas innerhalb eines Komponentensystems einer
anderen Relation zugeordnet, so muß die globale Anfrage insofern modifiziert werden, als daß gegebenenfalls die entsprechende Relation durch ein join in die Anfrage
miteingeliedert werden muß. Durch den Integrationsansatz sollten solche Konflikte in den meisten Fällen bereits im voraus gelöst worden sein, so daß in diesem
Zusammenhang nicht näher auf die Konfliktbehebung eingegangen wird.
Relationen als Attribute modelliert
Ein anderer Konflikt entsteht dadurch, wenn eine Relation bzw. ein Teil einer Relation innerhalb bestimmter Komponentensysteme als mehrwertiges“ Attribut mo”
delliert ist. Beispielhaft sei hierbei das Attribut AUTOREN der DBIS LiteraturDatenbank erwähnt. In diesem Fall müssen mehrere Modifikationen durchgeführt
werden. Zum einen müssen Attribute bzw. Relationen in der Anfrage entsprechend
angeglichen werden. Zum anderen müssen gegebenenfalls Vergleichsoperatoren innerhalb von Bedingungen geändert werden. Wird z.B. nach einem bestimmten Autor
mittels des Gleichheitsoperators gesucht, so muß dieser bei der Anfrageübersetzung
in einen LIKE-Operator umgewandelt werden, da das Attribut nun nicht mehr nur
aus einem, sondern aus mehreren Autoren besteht und demzufolge eine Gleichheitsabfrage zu einem leeren Ergebnis führen würde.
Fehlende Attribute
Ist ein Attribut innerhalb eines Komponentensystems nicht vorhanden, so können
innerhalb einer Anfrage jegliche Verweise auf dieses Attribut bei der Übersetzung
einfach gelöscht werden. Dabei entsteht jedoch folgende Problematik: Werden z.B.
Artikel in Hinblick auf ein bestimmtes Schlüsselwort gesucht, so führt die Eliminierung aller Verweise auf das entsprechende Attribut während der Übersetzung dazu,
daß, da nun der Bedingungsteil der Anfrage leer ist, alle in dem Komponentensystem gespeicherten Datensätze ausgegeben werden. Die globale Ergebnismenge
wäre dadurch in Bezug auf die Anfrage wenig aussagekräftig. In diesem Falle erscheint es sinnvoller, das entsprechende Komponentensystem bei der Anfrage nicht
zu berücksichtigen. Andererseits kann eine globale Anfrage, bei der mehrere Bedingungen durch ein logisches AND verknüpft sind, auch nach der Eliminierung einer
dieser Bedingungen noch brauchbare Ergebnisse liefern, obwohl auch in diesem Fall
die globale Anfrage keine völlig korrekte Ergebnismenge liefern würde. Hierbei ist
zu entscheiden, ob die Ungenauigkeit der Ergebnismenge in Hinblick auf die Trefferquote billigend in Kauf genommen wird oder ob das Komponentensystem bei der
Anfragebearbeitung unberücksichtigt bleiben soll, um eine exakte Ergebnismenge
KAPITEL 5. ENTWICKLUNG DES ZIS
90
zu gewährleisten. Eine allgemeine Lösungsmöglichkeit ist in diesem Zusammenhang
nicht gegeben. Innerhalb des ZIS wird der Ansatz verfolgt, daß, falls eine Bedingung ein Attribut enthält, welches in dem Komponentensystem nicht existiert, und
diese Bedingung die einzige innerhalb der Anfrage ist, das Komponentensystem
nicht in die Anfragebearbeitung mit eingeschlossen wird. Existieren jedoch weitere
Bedingungen, so wird das System in die Anfragebearbeitung integriert.
5.4.4.2
Ergebniskonverter
Der Konverter bildet praktisch die Umkehrfunktion des Übersetzers. D.h., daß die
von den Komponentensystemen zurückgegebenen Ergebnismengen wieder in eine
Darstellung gemäß dem globalen Schema umgewandelt werden müssen. Dabei sind
in diesem Zusammenhang nur noch die Inhalte der SELECT- und FROM-Klauseln von
Bedeutung. Die Rückumwandlung der bei der Anfrageübersetzung gelösten Konflikte soll im Anschluß kurz erläutert werden.
Der Konverter muß gewährleisten, daß implizite Attribute bei der Umwandlung
der Ergebnismenge korrekt in diese integriert werden. Dazu muß jeder Datensatz
durch die impliziten Attribute erweitert werden. Wurde eine Tabelle bzw. ein Teil
einer Tabelle in dem Export-Schema eines Komponentensystems als Attribut modelliert, so muß der Konverter nun dafür sorgen, daß das Ergebnis wieder in die
Darstellung des globalen Schemas überführt wird. Attribute, die in einem Komponentensystem nicht enthalten sind, werden innerhalb der Ergebnismenge mit dem
Wert #UNKNOWN belegt, um dem Benutzer, der im Normalfall keine Kenntnisse
über die Struktur der Komponentensysteme besitzt, die korrekte Interpretation der
Ergebnisse zu ermöglichen. Schließlich muß der Konverter noch dafür sorgen, daß
Attribute, für die das ZIS eine Synonym-Tabelle bereitstellt, entsprechend umgewandelt werden. Abbildung 5.19 zeigt ein Beispiel für eine Anfrageübersetzung.
5.4.5
Arbeitsdatenbank
Wie bereits erwähnt, gestattet das ZIS bei der Anfrageformulierung nur einen eingeschränkten Funktionsumfang. Um aber dem Benutzer dennoch die Möglichkeit
komplexer Anfragen zu offerieren, können die Anfrageergebnisse in einer relationalen Arbeitsdatenbank gespeichert werden. Auf diese Datenbank kann dann durch
das zugrunde liegende DBMS zugegriffen werden. Das ZIS stellt dem Benutzer dabei verschiedene Optionen für die Integration der Arbeitsdatenbank zur Verfügung.
Bei der Nutzung der Arbeitsdatenbank ist darauf zu achten, daß sämtliche PrimärSchlüssel des globalen Schemas in der SELECT-Anweisung der Anfrage vorhanden
sind, um dem System die Einhaltung der Integrationsbedingungen zu ermöglichen.
Im Unterschied zu gewöhnlichen SQL-Anfragen ist es beim ZIS durch Angabe eines
optionalen Arguments möglich, die Ausgabe der Ergebnismenge umzuleiten. Ohne
Angabe eines der Schlüsselwörter STORE bzw. ADD wird die Ergebnismenge lediglich in die Standardausgabe geschrieben. Bei Angabe von STORE dagegen wird die
Ergebnismenge zusätzlich in der Arbeitsdatenbank gespeichert. Dabei wird bei jeder Anfrage die Arbeitsdatenbank neu initialisiert und somit deren aktueller Inhalt
gelöscht. Durch die Angabe von ADD kann im Gegensatz zu STORE diese Initialisierung verhindert und somit die Ergebnismengen verschiedener Anfragen gemeinsam
in der Arbeitsdatenbank gespeichert werden.
Dadurch kann beispielsweise eine durch das ZIS nicht unterstützte OR-Anfrage auf
die Art generiert werden, daß die Menge der Auswahlbedingungen geteilt und Anfragen mit jeweils einer dieser Teilbedingungen sukzessive ausgeführt werden. Mittels
91
KAPITEL 5. ENTWICKLUNG DES ZIS
Title, Name, Abstract
ARTICLE A, PUBRELEASE R,
AUTHOR W
A.DokNr = R.DokNr
W.DokNr = A.DokNr
Volume = ’20’
Issue = ’4’
PubName =
’ACM Computing Surveys’ ;
SELECT
FROM
WHERE
AND
AND
AND
AND
Anfrage an das ZIS, basierend auf dem
globalen Schema.
Die Anfrage muß nun zunächst so umge−
formt werden, daß die als Attribut model−
lierte Tabelle korrekt erfaßt wird.
Title, Name, Abstract, Autoren
ARTICLE A, PUBRELEASE R,
AUTHOR W
A.DokNr = R.DokNr
W.DokNr = A.DokNr
Volume = ’20’
Issue = ’4’
PubName =
’ACM Computing Surveys’ ;
SELECT
FROM
WHERE
AND
AND
AND
AND
Das Attribut AUTOREN steht für die Anfrage
des Attributs NAME der Tabelle AUTHOR
In der DBIS−Datenbank nicht existierende
Objekte sind durchgestrichen dargestellt.
Objekte, die in der DBIS−Datenbank nicht
vorkommen, werden aus der Anfrage ge−
löscht.
Title, Autoren
ARTICLE A, PUBRELEASE R
A.DokNr = R.DokNr
Volume = ’20’
Issue = ’4’
PubName =
’ACM Computing Surveys’ ;
SELECT
FROM
WHERE
AND
AND
AND
Generierte Anfrage an die DBIS−Datenbank
gemäß dem zugrunde liegenden Export−
Schema.
Anfragebearbeitung
Title
Autoren
xyz
abc
uvw
Schmidt
Meyer/Müller
Schulze, Brand
Anfrageergebnis in Bezug auf das Export−
Schema der DBIS−Datenbank
Das Attribut AUTOREN muß wieder als Ta−
belle modelliert werden. Das in der DBIS−
Datenbank nicht enthaltene Attribut AB−
STRACT muß in das Ergebnis integriert
werden und mit dem Wert #UNKNOWN
belegt werden.
Title
Name
Abstract
xyz
abc
abc
uvw
uvw
Schmidt
Meyer
Müller
Schulze
Brand
#UNKNOWN
#UNKNOWN
#UNKNOWN
#UNKNOWN
#UNKNOWN
Anfrageergebnis der DBIS−Datenbank, ba−
sierend auf dem globalen Schema.
Abbildung 5.19: Beispiel Anfrageübersetzung (DBIS-Datenbank)
KAPITEL 5. ENTWICKLUNG DES ZIS
92
ADD können die Anfrageergebnisse dann nacheinander in die Datenbank geschrieben werden. Dabei kann es aber zu folgendem Konflikt kommen. Da die WSDBSe
bei jeder Anfrage die als Primär-Schlüssel fungierenden Dokumentnummern neu
generieren, kann es in diesem Fall zu Duplikatbildungen kommen. Die Lösung eines
solchen Konflikts muß der Benutzer bei der Arbeit mit der generierten Datenbank
berücksichtigen.
5.5
Administration
Im bisherigen Verlauf der Ausführungen wurde bereits mehrfach auf die administrativen Aufgaben und insbesondere die Möglichkeiten der Extensibilität eingegangen.
Aus diesem Grund wird in diesem Abschnitt lediglich eine kurze Zusammenfassung
der dargestellten Gesichtspunkte gegeben.
Durch den Integrationsansatz sowie die verwendete Integrationsstrategie läßt sich
das ZIS relativ einfach um weitere Komponentensysteme erweitern. Dies liegt zum
einen daran, daß bei der Einbindung neuer Quellen keine Modifikation bestehender
Komponentensysteme erfolgen muß, zum anderen können die existierenden funktionalen Komponenten als Grundlage bei der Entwicklung neuer Wrapper bzw.
Konnektoren genutzt werden. Weiterhin besitzt das ZIS, wie im Vorfeld beschrieben, einen modularen Charakter, so daß Änderungen bestimmter Eigenschaften des
Systems durch die Modifikation weniger Module realisiert werden können.
Zur Instandhaltung des Systems läßt sich sagen, daß Modifikationen nur dann
zwingend erforderlich sind, wenn die lokalen Schemata der Komponentensysteme
verändert werden. Welche Module in diesem Fall den neuen Bedingungen angepaßt
werden müßten, hängt von Art und Umfang der erfolgten Schema-Modifikationen
ab. Bei geringfügigen Änderungen wäre die Anpassung der jeweiligen Wrapper Module ausreichend, wohingegen bei umfangreichen Schema-Modifikationen gleichzeitg ein erneuter Datenbank-Entwurf und damit einhergehend die Anpassung vieler
Software-Module nötig sein könnte. Da der Integrationsansatz jedoch unabhängig
von den Komponentensystemen entwickelt wurde, und das System indirekt auf diesem Ansatz basiert, ist es als wahrscheinlich zu bezeichnen, daß nur leichte Modifikationen in den Modulen erforderlich wären.
Kapitel 6
Zusammenfassung und
Ausblick
Im Rahmen dieser Arbeit wurde ein Zeitschriften-Informationssystem entwickelt,
das auf den Konzepten föderierter Datenbanksysteme basiert und dem Benutzer
die Möglichkeit bietet, mit Hilfe von SQL-ähnlichen Anfragen Informationen über
Zeitschriftenartikel zu erhalten. Bei der Anfragebearbeitung werden unterschiedliche
Datenquellen berücksichtigt. Dabei handelt es sich einerseits um traditionelle Datenbanksysteme, wie beispielsweise die relationale Forschungsliteratur-Datenbank
der Abteilung Datenbanken und Informationssysteme. Andererseits werden WebSites ausgewählter Verlage sowie ein Bibliographie-Server in das System integriert.
Zur Integration der Web-Sites wurde ein spezielles Web-Site Datenbanksystem konzipiert, das eine hierarchische Struktur besitzt und für die Verwaltung von genau
einem Web-Site verantwortlich ist. Das Datenbanksystem stellt eine Schnittstelle
zur Verfügung, die es ermöglicht, Anfragen an den Web-Site zu richten, wobei keine
Kenntnisse über den internen Aufbau des Site erforderlich sind. Für die Informationsgewinnung semi-strukturierter Daten wird das zu diesem Zweck entworfene Data
Retrieval System eingesetzt. Die Extraktion erfolgt dabei mit Hilfe einfach zu formulierender Regeln, durch die die relevanten Daten innerhalb des Dokuments identifiziert werden können. Um die Extraktion der Daten effizient und vor allem stabil
gegenüber Änderungen der Quelltexte zu machen sowie gleichzeitig die einfache Definition von Extraktionsregeln zu ermöglichen, wird innerhalb des Data Retrieval
Systems ein spezieller Dokumentfilter verwendet. Dieser transformiert den HTMLCode der Web-Pages in eine vereinfachte Darstellung, ohne dabei die Struktur oder
den für die Integration relevanten Informationsgehalt der Dokumente zu verändern.
Somit kann das Data Retrieval System als Alternative im Bereich der Extraktion semi-strukturierter Daten betrachtet werden. Darüber hinaus wurde durch die
Implementierung der Web-Site Datenbanksysteme die einheitliche Betrachtung der
Konzepte föderierter Datenbanken ermöglicht, da diese die direkte Integration von
Web-Sites nicht unterstützen.
Die bei der Integration der Datenquellen in das Zeitschriften-Informationssystem
zu bewältigenden Aufgaben wurden durch den Einsatz von Wrappern und einem
Mediator realisiert. Die Wrapper sind dabei so konzipiert, daß sie innerhalb der unterschiedlichen Klassen von Datenbanksystemen (relational, hierarchisch, etc.) einen
adaptiven Charakter aufweisen. Im Rahmen dieser Arbeit wurden Wrapper für relationale und hierarchische Datenbanken vorgestellt. Die Integration zusätzlicher
Datenquellen, die einer dieser Klassen angehören, ist durch die einfache Adaption
der bestehenden Konzepte möglich. Dies gilt in gleichem Maße für den Mediator,
93
KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK
94
der für jede Datenquelle einen dedizierten Konnektor zur Verfügung stellt. Innerhalb der Arbeit wurde gezeigt, wie diese Konnektoren konstruiert werden können.
Zwar lassen sich Konnektoren im Gegensatz zu den Wrappern nicht in verschiedene Klassen zusammenfassen, doch durch das zugrunde liegende Konzept wird eine
einfache Integration zusätzlicher Datenquellen ermöglicht. Dies läßt sich dadurch
erklären, daß aufgrund der Autonomie der Konnektoren bestehende Systemkomponenten bei einer Erweiterung nicht modifiziert werden müssen. Anhand der beschriebenen Erweiterungsmöglichkeiten ist zu erkennen, daß die Entwicklung des
Zeitschriften-Informationssystems insbesondere unter dem Gesichtspunkt der Modularität erfolgt ist. Dadurch wird der einfache Austausch bzw. die Modifikation einzelner Module ohne eine Beeinträchtigung des Gesamtsystems gewährleistet. Somit
läßt sich das System, aufbauend auf den in dieser Arbeit vorgestellten Konzepten,
sukzessive verbesssern.
Da das Hauptaugenmerk dieser Arbeit auf dem System in seiner Gesamtheit gelegen hat, sind Aspekte der Performance, Benutzerfreundlichkeit bzw. Komplexität
in den Hintergrund gerückt worden. Dadurch ergeben sich für das ZeitschriftenInformationssystem eine Reihe möglicher Weiterentwicklungen. In erster Linie ist
in diesem Zusammenhang der Gesichtspunkt der Anfragebearbeitung zu erwähnen.
So wurden z.B. Aspekte der Anfrageoptimierung im Rahmen dieser Arbeit nicht
beachtet. Weiterhin wurden die Möglichkeiten bei der Anfrageformulierung im Vergleich zu SQL stark eingeschränkt, so daß beispielsweise geschachtelte Anfragen
nicht vom System untertützt werden. Allerdings muß gleichzeitig die Frage gestellt werden, inwieweit eine vollständige SQL-Funktionalität für das ZeitschriftenInformationssystem benötigt wird. Wie auch immer, Verbesserungen im Bereich
der Anfragebearbeitung stellen eine sinnvolle Weiterentwicklung des Systems dar.
Es muß allerdings darauf hingewiesen werden, daß eine Funktionserweiterung der
Anfragesprache die Modifikation bestehender Konnektoren miteinschließt. Eine andere Möglichkeit der Weiterentwicklung des Systems stellt sich im Bereich des Data
Retrieval Systems. So erfolgt die Definition von Extraktionsregeln im Rahmen dieser Arbeit auf manuelle Art und Weise. Es ist allerdings aufgrund der einfachen
Struktur der durch den Filter erzeugten Dokumente möglich, diese Regeln halbautomatisch zu erzeugen. In diesem Zusammenhang wäre auch die Entwicklung einer
graphischen Benutzeroberfläche vorteilhaft. Dabei könnte gleichzeitig eine menügesteuerte Konfiguration der Dokumentfilter realisiert werden.
Zusammenfassend läßt sich feststellen, daß das Zeitschriften-Informationssystem
einen logisch strukturierten Ansatz zur Integration verteilter, heterogener Datenquellen darstellt. Die in diesem Zusammenhang vorgestellten Konzepte lassen sich
dabei ohne weiteres auf andere Anwendungsbereiche übertragen. Gleichzeitig können einige der in dieser Arbeit entwickelten Konzepte separat in anderen Projekten
genutzt werden. An erster Stelle ist hierbei das Data Retrieval System zu erwähnen,
aber auch das Konzept des Integrationsansatzes stellt eine sinnvolle Ergänzung im
Bereich föderierter Datenbanksysteme dar.
Web−Site Schemata
digitaler
Bibliotheken
Kluwer
IEEE
Elsevier
Springer
95
Kluwer Online
http://www.wkap.nl/kluweronline/onlinejournals/
Dezember 2001
Template−Klasse : "KluwerOnline"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
KluwerOnline
Publication
PubName
Publisher
HyperLink
HyperLink
(Publication+)>
(PubName, Publisher, HyperLink)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "PublicationReleases"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Volume
NumberOfVolume
Issue
NumberOfIssue
Year
Month
HyperLink
HyperLink
(NumberOfVolume, Issue+)>
(#PCDATA)>
(NumberOfIssue, (Year,Month)?, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "TableOfContents"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Article
Title
Author
Pages
HyperLink
HyperLink
(Title, Author+, Pages, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
1
Template−Klasse : "DetailsOfArticle"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Details
ISSN
Abstract
Keyword
URLFullText
(ISSN?, Abstract?, Keyword*, URLFullText)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
96
Springer LINK Computer Science Online Library
http://link/springer.de/ol/csol/index.html
Dezember 2001
Template−Klasse : "OnlineLibrary"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Online Library
Publication
HyperLink
HyperLink
(Publication+)>
(PubName, HyperLink)>
EMPTY>
Template CDATA #REQUIRED
URL
CDATA #REQUIRED>
1
Template−Klasse : "ISSN"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
ISSN
ISSN_Print
ISSN_Electr
HyperLink
HyperLink
(ISSN_Print, ISSN_Electr)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template CDATA #REQUIRED
CDATA #REQUIRED>
URL
1
Template−Klasse : "PublicationDescription"
<!ELEMENT
<!ELEMENT
PubDesc
Description
(Description)>
(#PCDATA)>
Template−Klasse : "PublicationReleases"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
R_Year
Year
Releases
Volume
Issue
HyperLink
HyperLink
(Year, Releases+)>
(#PCDATA)>
(Volume, Issue)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "TableOfContents"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Article
Title
Author
Pages
HyperLink
HyperLink
(Title, Author+, Pages, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template CDATA #REQUIRED
CDATA #REQUIRED>
URL
1
Template−Klasse : "DetailsOfArticle"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Details
Abstract
Keyword
URLFullText
97
(Abstract?, Keyword*, URLFullText)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
IEEE Digital Library
http://computer.org/publications/dlib
Februar 2002
Template−Klasse : "DigitalLibrary"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Digital Library
PublicationType
Type Name
HyperLink
HyperLink
(PublicationType+)>
(TypeName, HyperLink)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
#REQUIRED
#REQUIRED>
Template−Klasse : "Publications"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
(PubName, HyperLink)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
Publication
PubName
HyperLink
HyperLink
#REQUIRED
#REQUIRED>
Template−Klasse : "PublicationReleases"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Volume
NumberOfVolume
Issue
NumberOfIssue
Year
Month
HyperLink
HyperLink
(NumberOfVolume, Issue+)>
(#PCDATA)>
(NumberOfIssue, (Year,Month)?, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "TableOfContents"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Article
Title
Author
Pages
URLhtml
URLpdf
HyperLink
HyperLink
(Title, Author+, Pages, URLhtml, URlpdf, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "Abstract"
<!ELEMENT
<!ELEMENT
Abstract
AbstrContent
98
(AbstrContent)>
(#PCDATA)>
Elsevier Science Online
http://ww1.elsevier.nl/inca/tree/?prod=J&key=SSAC
Dezember 2001
Template−Klasse : "ElsevierScienceOnline"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
OnlineLibrary
Publication
PubName
HyperLink
HyperLink
(Publication+)>
(PubName, HyperLink)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
#REQUIRED
#REQUIRED>
1
Template−Klasse : "PublicationDescription"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
PubDescription
ISSN
Description
HyperLink
HyperLink
(ISSN, Description?, HyperLink)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "PublicationReleaseYear"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
PubRelYear
R_Year
HyperLink
HyperLink
(R_Year)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA
URL
CDATA
#REQUIRED
#REQUIRED>
Template−Klasse : "PublicationReleases"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Release
NrOfVolume
NrOfIssue
Month
HyperLink
HyperLink
(NrOfVolume, NrOfIssue, Month?)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
Template−Klasse : "TableOfContents"
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
Article
Title
Author
Pages
URLText
HyperLink
HyperLink
(Title, Author+, Pages, URLText, HyperLink)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
EMPTY>
Template−Klasse CDATA #REQUIRED
URL
CDATA #REQUIRED>
1
Template−Klasse : "Abstract"
<!ELEMENT
<!ELEMENT
Abstract
AbstrContent
99
(AbstrContent)>
(#PCDATA)>
Abbildungsverzeichnis
1.1 Allgemeine Problematik der Informationsbeschaffung . . . . . . . . .
8
2.1 Klassifizierung von Datenmodellen . . . . . . . . . . . . . . . . . . .
11
2.2 3-Ebenen-Architektur nach ANSI/SPARC . . . . . . . . . . . . . . .
12
2.3 Fünf-Schichten-Modell . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4 Schema und Schema-Diagramm einer hierarchischen Datenbank . . .
17
2.5 Zustandsbaum einer hierarchischen Ausprägung . . . . . . . . . . . .
17
2.6 Hierarchische Sequenz eines Zustandsbaums . . . . . . . . . . . . . .
18
2.7 Logische Struktur von Datenquellen . . . . . . . . . . . . . . . . . .
19
2.8 Generische Transformation . . . . . . . . . . . . . . . . . . . . . . .
20
2.9 Schema-Transformation . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.10 Datenmodell-Transformation . . . . . . . . . . . . . . . . . . . . . .
20
2.11 Allgemeine Mediator-Architektur . . . . . . . . . . . . . . . . . . . .
21
2.12 Dokumentstruktur eines Buches . . . . . . . . . . . . . . . . . . . . .
22
3.1 Klassifikation von Datenbanksystemen . . . . . . . . . . . . . . . . .
27
3.2 Referenzarchitektur für verteilte Datenbanksysteme . . . . . . . . . .
28
3.3 Klassifizierung von Multidatenbanksystemen . . . . . . . . . . . . . .
29
3.4 5-Ebenen-Schema-Architektur . . . . . . . . . . . . . . . . . . . . . .
30
4.1 Klassifikation von Hyperlinks . . . . . . . . . . . . . . . . . . . . . .
33
4.2 Struktur des ACM Digital Library Web-Site . . . . . . . . . . . . . .
34
4.3 Template-Klassen des ACM Digital Library Web-Site . . . . . . . . .
35
4.4 Zwei Template-Klassen der ACM Digital Library . . . . . . . . . . .
36
4.5 Web-Site-Schema der ACM Digital Library . . . . . . . . . . . . . .
37
4.6 Browser-Darstellung einer Instanz von ’Publications’ . . . . . . . . .
38
4.7 Browser-Darstellung einer Instanz von ’PublicationDetails’ . . . . . .
38
4.8 Konzeptionelles Schema des ACM Digital Library Web-Site . . . . .
40
4.9 Data Retrieval System . . . . . . . . . . . . . . . . . . . . . . . . . .
41
100
101
ABBILDUNGSVERZEICHNIS
4.10 HTML-Element-Klassifikation . . . . . . . . . . . . . . . . . . . . . .
44
4.11 Dokumentinstanz der ACM Digital Library . . . . . . . . . . . . . .
45
4.12 Gruppierung der HTML-Elemente . . . . . . . . . . . . . . . . . . .
46
4.13 Dokumentgerüst . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.14 Crib-Definitionen für die Klasse ’TableOfContents’ . . . . . . . . . .
49
4.15 Zustandsdiagramm des Scanners für die Klasse ’TableOfContents’ . .
50
4.16 XML-Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.17 Schema des Bundesliga Web-Site . . . . . . . . . . . . . . . . . . . .
52
4.18 Konzeptionelles Schema des Bundesliga Web-Site . . . . . . . . . . .
53
4.19 3-Schichten-Architektur des WSDBS . . . . . . . . . . . . . . . . . .
54
4.20 Record-Typen als JAVA-Klassen innerhalb der UWA . . . . . . . . .
55
4.21 Die XML-orientierte Schnittstelle . . . . . . . . . . . . . . . . . . . .
58
4.22 Einteilung der Datensätze in Segmente . . . . . . . . . . . . . . . . .
58
4.23 Speicherung der Datensätze . . . . . . . . . . . . . . . . . . . . . . .
59
4.24 Vollständiger Durchlauf der gesamten Ausprägung . . . . . . . . . .
60
4.25 Implementierung des Kommandos GET FIRST . . . . . . . . . . . . .
61
5.1 Web-Site-Schema des DBLP-Server . . . . . . . . . . . . . . . . . . .
65
5.2 Konzeptionelles Schema des DBLP-Server . . . . . . . . . . . . . . .
66
5.3 Relationen-Schema der DBIS-Datenbank . . . . . . . . . . . . . . . .
67
5.4 Allgemeines Modell föderierter DBSe . . . . . . . . . . . . . . . . . .
69
5.5 Architekturmodell des ZIS . . . . . . . . . . . . . . . . . . . . . . . .
70
5.6 Integrationsansatz des ZIS . . . . . . . . . . . . . . . . . . . . . . . .
74
5.7 Modellierung des lokalen Schemas im ER-Modell (I) . . . . . . . . .
76
5.8 Modellierung des lokalen Schemas im ER-Modell (II) . . . . . . . . .
77
5.9 Export-Schema der ACM Digital Library
. . . . . . . . . . . . . . .
77
5.10 Export-Schema der DBIS-Datenbank . . . . . . . . . . . . . . . . . .
78
5.11 Export-Schema des DBLP Bibliographie-Server . . . . . . . . . . . .
78
5.12 Föderiertes Schema des ZIS . . . . . . . . . . . . . . . . . . . . . . .
80
5.13 Dynamische Modellerweiterung . . . . . . . . . . . . . . . . . . . . .
83
5.14 Sicht-Definitionen DBIS-Literatur-DB . . . . . . . . . . . . . . . . .
85
5.15 Translation-Table des DBIS-Wrapper . . . . . . . . . . . . . . . . . .
86
5.16 WS/QL-Schablone für den DBLP-Server . . . . . . . . . . . . . . . .
87
5.17 Beispiel für eine Transformation . . . . . . . . . . . . . . . . . . . .
87
5.18 Aufbau des ZIS-Mediators . . . . . . . . . . . . . . . . . . . . . . . .
88
5.19 Beispiel Anfrageübersetzung (DBIS-Datenbank) . . . . . . . . . . . .
91
Literaturverzeichnis
[BLN86]
C. Batini, M. Lenzerini, S.B. Navathe. A Comparative Analysis of
Methodologies for Database Schema Integration. ACM Computing
Surveys, 18(4):323-364, 1986.
[Bry88]
M. Bryan. SGML: An Author’s Guide to the Standard Generalized
Markup Language. Addison-Wesley, 1988.
[Cod82]
E.F. Codd. Relational Database: A Practical Foundation for Productivity. Communications of the ACM, 25(2):109-117, 1982.
[Con97]
S. Conrad. Föderierte Datenbanksysteme: Konzepte der Datenintegration. Springer-Verlag, Berlin, 1997.
[CP84]
S. Ceri, G. Pelagatti. Distributed Databases - Principles and Systems. McGraw-Hill, 1984.
[Dat00]
C.J. Date. An Introduction to Database Systems. Addison Wesley
Longman, 7. Auflage, 2000.
[EN94]
R. Elmasri, S.B. Navathe. Fundamentals of Database Systems.
Addison-Wesley, 2. Auflage, 1994.
[EN00]
R. Elmasri, S.B. Navathe. Fundamentals of Database Systems.
Addison-Wesley, 3. Auflage, 2000.
[Gol90]
C.F. Goldfarb. The SGML Handbook. Oxford University Press, Oxford, 1990.
[Güt92]
R.H. Güting. Datenstrukturen und Algorithmen. B.G. Teubner,
Stuttgart, 1992.
[HR99]
T. Härder, E. Rahm. Datenbanksysteme: Konzepte und Techniken
der Implementierung. Springer-Verlag, 1999.
[Lip95]
U. Lipeck. Datenbanksysteme I - Vorlesung WS 1995/96. Institut
für Informatik, Universität Hannover, 1995.
[Lob98]
H. Lobin. Informationsmodellierung in XML und SGML. SpringerVerlag, 1998.
[MMK99]
I. Muslea, S. Minton, C. Knoblock. A Hierarchical Approach to
Wrapper Induction. Proceedings of the 3rd Annual Conference on
Autonomous Agents, Seattle, Washington, United States, 190-197,
1999.
[ÖV91]
T.Özsu, P. Valduriez. Principles of Distributed Database Systems.
Prentice-Hall, Eaglewood Cliffs, New Jersey, 1991.
102
LITERATURVERZEICHNIS
103
[SH99]
G. Saake, A. Heuer. Datenbanken: Implementierungstechniken.
MITP-Verlag, Bonn, 1999.
[TRS97]
M. Tork Roth, P.Schwarz. Don’t Scrap It, Wrap It! A Wrapper Architecture for Legacy Data Sources. Proceedings, 23rd International
Conference, VLDB, Athens, Greece, 266-275, 1997.
[Ull82]
J.D. Ullmann. Principles of Database Systems. Computer Science
Press, 1982.
[Vos00]
G. Vossen. Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. Oldenbourg Verlag, München, 4.Auflage, 2000.
[Wel96]
D. Wells. Wrappers. Object Services and Consulting, Inc.,
http://www.objs.com/survey/wrap.htm, 1996.
[Wie92]
G. Wiederhold. Mediators in the Architecture of Future Information
Systems. IEEE Computer, 25(3):38-49, 1992.
[Wil99]
E. Wilde. Wilde’s WWW - Technical Foundations on the World
Wide Web. Springer-Verlag, Berlin, 1990.