In nahezu allen Unternehmen, Institutionen und Organisation hat die Informationstechnologie unaufhaltsam ihren Einzug gehalten. Dieser Trend wird auch in Zukunft weiter anhalten. Durch die ständige Erschließung neuer Möglichkeiten im Bereich der Datenverarbeitung entstehen jedoch immer größere und zuweilen auch unüberschaubarere Datenmengen, auf die zwar immer schneller zugegriffen werden kann, die immer schneller verarbeitet und transportiert werden können, aber auch immer komplexer, syntaktisch und semantisch verschiedener werden. Man denke nur an einen großen Weltkonzern wie Siemens. Hier liegen von den weltweit verteilten Zweigstellen und Tochterunternehmen Unmengen von Wirtschafts- und Statistikdaten sowie Marktdaten, Studien usw. vor, die in mühevoller Arbeit zu brauchbaren Informationen zusammengeführt und transformiert werden müssen.

Um mit solchen heterogenen Datenquellen arbeiten zu können, sind Methoden der Datenintegration nötig, die aber nicht nur die vorhanden Daten in einer bestimmten Weise zusammenfügen, sondern diese verarbeiten und in Wissen überführen, aufgrund dessen Entscheidungen getroffen werden können [Wi92]. Offensichtlich ist diese Art der Datenverarbeitung essentiell für jedes größere Unternehmen, jede größere Institution und Organisation. Dementsprechend groß ist der Bedarf an Systemen, die solche Vorgänge automatisieren können und gute Eigenschaften bezüglich Flexibilität und Erweiterbarkeit bieten. Das bedeutet insbesondere, dass ein System anpassbar an die individuellen Bedürfnisse ist.

Im folgenden betrachten wir deshalb den Ansatz der Mediatoren, die, zumindest ihrer Architektur nach, solche Dienste zu leisten vermögen. Wie es der Name vermuten lässt, stellen diese Systeme eine Art Vermittler zwischen den Datenquellen und den Anwendungen dar, der die Daten aufbereitet und in der gewünschten Form liefert. Wie weit eine solche Aufbereitung gehen kann oder gehen sollte ist a priori nicht festgelegt und wird Gegenstand eines der folgenden Kapitel sein.

Zunächst jedoch soll veranschaulicht werden, welche Probleme bei der Integration von heterogenem Datenmaterial auftreten können, bzw. mit welchen Problemen ein System der oben erwähnten Art konfrontiert sein wird.

1.1. Heterogene Datenquellen

Wo immer große Computer- und Informationssysteme eingesetzt werden, fallen fast zwangsläufig enorme Mengen an heterogenen Daten aller Art an. Solche Datenquellen können im besten Falle Datenbankmanagementsysteme (DBMS) verschiedener Ausprägung sein, aber auch z.B. Ansammlungen von Texten, die so gut wie keine Metadaten oder auch keine besondere Struktur besitzen (semi- oder unstrukturiert). Ebenso könnte man sich hier als einen Extremfall Bild- oder andere Multimediadatenbanken vorstellen.

Abstrahiert man nun von den Heterogenitäten, die auf unterschiedliche Herkunft bzw. unterschiedliche Hardware, Betriebsysteme, Kommunikationsprotokolle usw. und auch unterschiedliche Datenmodelle zurückzuführen sind, so ergeben sich dennoch eine Reihe von Problemen, die im folgenden analysiert werden sollen.

Nach [Wi92] lassen sich diese Probleme in zwei Kategorien einteilen. Zum einen treten Probleme auf, die sich schon bei Verwendung jeder einzelnen Datenquelle herausstellen und bei Benutzung von mehreren Datenquellen noch deutlicher hervortreten, nämlich mangelnde Abstraktion und zu große Datenmengen. Zum anderen treten bei der Kombinierung von mehreren Datenquellen Probleme auf, die mit mangelnder semantischer Übereinstimmung von Struktur und Repräsentation der Daten zu tun haben.

1.1.1. Abstraktion und Datenmenge

Die Datenmenge kann man durch eine geeignete Auswahl reduzieren (z.B. SELECT Statement). Allerdings ist eine solche Auswahl noch immer recht ungeeignet, wenn es darum geht, aus den vorhandenen Daten Wissen zu gewinnen, das z.B. als Entscheidungshilfe dienen soll. Die bekannten Aggregationsfunktionen wie MIN, MAX, SUM, COUNT, usw. sind hier ein Ansatz. Diese sind jedoch in vielen Fällen zu allgemein oder zu speziell, so dass damit nicht auf jedem Gebiet die gewünschte Informationsgewinnung möglich ist. Vielfältige Abstraktionsmethoden sind daher von Nöten, von denen einige im folgenden aufgeführt sind:

Granularisierung
Generalisierung
Zeitliche Abstraktion
Relative Abstraktion, z.B. relative Unterschiede (Tendenzen) eines Attributes
Ausnahmeerkennung
Pfadberechnung, z.B. aus Flugplänen Reisedauer und –kosten berechnen

Die Komplexität der genannten Methoden kann durchaus sehr hoch sein und übersteigt damit meist die Mächtigkeit der vorhandenen DBMS. Implementiert man dagegen diese Methoden in Anwendungsprogramme, so ist das Wissen darüber verborgen und kann nicht von anderen Anwendungen genutzt werden. Daraus ergibt sich u.a. die Forderung nach einer Mediator – Architektur.

1.1.2. Mangelnde Übereinstimmung

Wie bereits erwähnt wurde, gibt es bei Daten unterschiedlicher Herkunft grobe Konflikte (mismatch) in Struktur, Repräsentation und Semantik der vorliegenden Daten, die über reine Benennungsunterschiede weit hinausgehen.

Von einem Mediatorsystem sollten daher unter anderem folgende Konflikte bereinigt werden:

Schlüssel / Namen
Geltungsbereich
Abstraktionsgrad
Zeitliche Basis
Domänensemantik
Wertsemantik

Die genannten Punkte sind selbstverständlich nur ein Ausschnitt aus der Vielzahl von Problemen, die bei der Integration von heterogenen Datenquellen auftreten können. Des weiteren treten hier auch Redundanzen und Überlappungen auf, die ebenfalls zu vermeiden sind.

1.1.3. Strukturiertheit von Datenquellen

Es ist bereits angesprochen worden, dass Datenquellen nicht unbedingt strukturiert sein müssen oder oft auch nur eine abgeschwächte Strukturiertheit vorweisen. Man unterscheidet hier strukturierte, semistrukturierte (variable, nicht unabhängige Struktur) und unstrukturierte Daten. Es ist klar, dass aufz.B. unstrukturierten Daten von Haus aus keine typischen Datenbankanweisungen wie z.B. SELECT ausgeführt werden können. Dennoch ist es wichtig, dass auch solche Datenquellen in ein System integriert werden und in deskriptiver Weise angefordert werden können. Hier müssen deshalb Methoden des Information Retrieval angewendet werden, um auch solche Daten verarbeiten und in vereinheitlichter Weise für alle drei Typen ausgeben zu können.

1.2. Globale Anforderungen an Mediator – Architekturen

Aus allen oben genannten Punkten ergeben sich folgende Anforderungen an Mediator – Architekturen:

Deskriptive Anfragesprache. Anwender bzw. Anwendungen müssen beschreiben können, welche Informationen (aus heterogenen Datenquellen) sie benötigen und nicht wie diese zu beschaffen sind, das heißt, es wird eine deskriptive Anfragesprache benötigt. Dabei ist zu beachten, dass sowohl genaue als auch ungenaue Anfragen möglich sein müssen, da die darrunterliegenden Datenquellen u.U. keine genauen Anfragen zulassen.
Kombination und Korrelation der Datenquellen. Es muss möglich sein, die Daten der verschiedenen strukturierten, semistrukturierten und unstrukturierten Quellen zu kombinieren und zu korrelieren. Dabei sind die oben erwähnten Eigenschaften von heterogenen Daten zu berücksichtigen. Es sollten so weit wie möglich semantische Heterogenitäten und Redundanzen aufgelöst werden.
Abstraktion. Die Menge der Daten sollte durch geeignete Abstraktionen reduziert werden können.
Einheitliche Darstellung der Ergebnisse. Die Informationen, die das System zurückliefert, müssen in einer einheitlichen Weise dargestellt werden, unabhängig davon, welchen Ursprungs sie sind.

1.3. Überblick über Datenintegrationsmethoden

Schon seit geraumer Zeit gibt es eine Reihe von Ansätzen zur Datenintegration, die jeweils verschiedene Aspekte besonders hervorheben. Dazu zählen u.a. MOM, Publish/Subscribe – Systeme, TP – Monitore, Application Server, Data Warehouses, Föderierte DBMS usw. und schließlich auch Mediator - Architekturen. Nach [St99] lassen sich diese Systeme folgendermaßen klassifizieren:

Data Level

TP Monitor
Application Server

Data Federation System
Data Warehouse/Mart

Event Level

Message – Oriented Middleware (MOM)

Publish/Subscribe

Update

(Cross-System Consistency)

Read

(Unified Views)

Abbildung 1: Klassifizierung von Datenintegrationsmethoden nach [St99]

Die Kriterien, nach denen hier unterschieden wurde, sind zum einen die Ebene, auf welcher der Austausch der Daten stattfindet (Daten- oder Ereignis / Applikationsebene), zum anderen, ob im System die Erlangung von Informationen, das Lesen oder die Konsistenthaltung der Daten (Updates) im Vordergrund steht.

Mediator – Architekturen sollen, wie aus den vorherigen Ausführungen hervorgeht, in erster Linie zum Erlangen von Informationen dienen und sind deshalb unter Read einzuordnen. Es ist allerdings nicht zwangsläufig so, dass Updates auf einem solchen System unmöglich sind, jedoch ist das nicht die primäre Zielstellung solcher Systeme.

Da die Integration bei Mediator – Architekturen offensichtlich auf der Datenebene stattfindet (die Daten werden nicht über Nachrichtenaustausch zwischen Anwendungen zusammengeführt), ist hier eine Zuordnung zu eben dieser klar.

Eine weitere Möglichkeit der Klassifizierungen besteht nach [DD99] darin, zu unterscheiden zwischen Ansätzen, die die zugrundeliegenden Daten vollständig replizieren, also materialisiert sind, oder solchen, die die Daten virtuell integrieren, ohne diese vollständig zu replizieren:

Abbildung 2: Klassifizierung von Datenintegrationsmethoden nach [DD99]

Natürlich ist es wahrscheinlich, dass auch virtuelle Systeme Daten zu einem gewissen Maße replizieren, allerdings mit dem Unterschied, dass die Replizierung nur zu Optimierungszwecken dient, oder eine bestimmte Funktionalität erst ermöglicht. Mediator – Systeme, die offensichtlich virtuell integrierte Systeme sind, werden auch als Mediated Query Systems (MQS) bezeichnet, die Mediatoren als Implementierung benutzen.

2. Architektur und funktionelle Aspekte

In diesem Kapitel werden wir uns der Architektur von Mediator – Systemen zuwenden. Da dieses Gebiet noch relativ neu ist, ist auch die Architektur der vorhandenen Systeme nur bis zu einem gewissen Grad übereinstimmend. Dennoch sind gewisse Gemeinsamkeiten durch die globalen Anforderungen an solche Systeme vorgegeben. So ist es offensichtlich, dass die Verlagerung der geforderten Funktionalität auf die Anwendungs- oder Datenquellebene keinen Sinn macht. Deshalb wird im allgemeinen eine vermittelnde Schicht zwischen Anwender bzw. den Anwendungen und den Datenquellen eingeführt.

Abbildung 3: Mediator – Architektur

In der obigen Abbildung sehen wir die 3 – Schichten – Architektur von Mediator – Systemen. Anwendungsprogramme kommunizieren also über die Mediationsschicht mit den darunter liegenden Datenquellen, ohne unbedingt genaue Kenntnisse über deren Aufbau und Struktur haben zu müssen. Diese Schicht stellt also eine Art Middleware dar, die höhere Dienste anbietet („value added middleware“). Im folgenden werden wir uns den möglichen Aufbau der Mediationsschicht genauer ansehen.

2.1. Aufbau der Mediationsschicht

Es gibt im allgemeinen zwei Möglichkeiten für den Aufbau der Mediationsschicht. Zum einen kann die Funktionalität durch ein einziges zentrales System realisiert werden, zum anderen durch ein Netzwerk, bestehend aus einer Vielzahl von Komponenten, die untereinander kommunizieren. Hierbei könnte die Unterteilung der Module nach Aufgabenbereich oder Fachbereich bzw. Domäne erfolgen. Die letztere Art der Dezentralisierung impliziert spezialisierte Mediatoren, die bestimmte Eigenheiten eines Fachgebietes oder einer Domäne, in der die heterogenen Daten vorhanden sind, berücksichtigen. In jedem Falle bietet eine solche dezentralisierte Architektur höhere Flexibilität und Erweiterbarkeit, die natürlich voraussetzt, dass eine entsprechende Sprache zur Kommunikation zwischen den Komponenten existiert. Allerdings entsteht dadurch natürlich ein nicht zu unterschätzender Overhead, der bei einer zentralisierten Architektur nicht in dem Maße auftritt. Offensichtlich jedoch kann eine solche zentralisierte Architektur nicht die gesamte Vielfalt von Datenquellen mit ihrer strukturellen und semantischen Verschiedenheit aus genannten Gründen abdecken, so dass in einem solchen Falle i.a. mehrere verschiedene Systeme eingesetzt werden müssten, die dann aber eventuell nur wenig oder gar nicht miteinander kommunizieren können.

Unabhängig davon, ob eine zentralisierte oder dezentralisierte Architektur vorliegt, sind von dem MQS eine Reihe von Aufgaben zu erfüllen, die den in der folgenden Abbildung dargestellten grundlegenden Aufbau eines solchen Systems induzieren:

Abbildung 4: Aufbau der Mediationsschicht

Es ist nicht notwendigerweise so, dass sämtliche in der obigen Abbildung aufgeführten Funktionen und Komponenten in einem Mediator zu finden sind. Eine dezentralisierte Architektur ließe auch eine Verteilung dieser Komponenten auf verschiedene Systeme zu.

Offensichtlich besitzen nicht nur die inneren Komponenten (Query Processor, Metadaten – Repository usw.), sondern auch die beiden Schnittstellen eine nicht geringe Bedeutung. Die Informationen einheitlich anzufragen und darzustellen ist eines der Hauptprobleme bei der Gestaltung eines Systems.

2.2. Schnittstelle Anwendung – Mediator

Die Funktionalität, die ein Mediator den zugreifenden Anwendungen zur Verfügung stellt oder stellen sollte, ist sehr vielfältig. Deshalb ist es besonders wichtig, eine Schnittstelle zu definieren, die nicht nur die Funktionalität abdeckt, sondern auch garantiert, dass Anwendungen in einfacher Weise die Funktionen nutzen und deren Ergebnisse einheitlich auswerten können. Eine graphische Oberfläche steht hier nicht im Vordergrund, da Benutzer selten direkt, sondern über eine entsprechende Anwendung, die diese Aufgabe erledigen sollte, auf einen Mediator zugreifen werden.

Des weiteren sollten von Programmiersprachen bekannte Eigenschaften wie Vollständigkeit, Orthogonalität und Erweiterbarkeit berücksichtigt werden

2.2.1. Anfragesprache

Natürlich bietet sich bei den oben geforderten Eigenschaften der Schnittstelle die Einführung einer Anfragesprache an, denn die Definition statischer Schnittstellen (z.B. API) scheinen mit der Mächtigkeit des Informations – und Kontrollflusses überfordert zu sein.

Eine solche Sprache könnte ähnlich den Sprachen sein, die relationale oder objekt-orientierte Datenbanken bereitstellen, also z.B. SQL. Allerdings sind eine Reihe von Erweiterungen nötig, um folgende Dinge zu gewährleisten:

Unterstützung verschiedener Anfragetypen. Die Informationsbedürfnisse sind so verschieden wie die vorhandenen Datenquellen. Deshalb muss es neben den bekannten Datenbankanfragen (z.B. SQL) auch die Möglichkeit geben, vage oder ungenaue Anfragen zu stellen, wenn man z.B. die Struktur der unterliegenden Datenquellen nicht kennt, oder bekannt ist, dass z.B. semi- oder unstrukturierte Daten vorliegen.
Schemaabhängigkeit. Die Anfragesprache sollte die Anfrage einmal in Abhängigkeit des globalen Schemas oder, wenn z.B. kein vordefiniertes globales Schema existiert oder die Schemata der unterliegenden Datenquellen wohlbekannt sind, (teilweise) in Abhängigkeit des Schemas der unterliegenden Daten ermöglichen.
Zugriff auf Metadaten. Um die oben genannte Schemaabhängigkeit überhaupt gewährleisten zu können, ist es notwendig, Zugriff auf die Metadaten des Systems zu erlangen.

Des weiteren gibt es eine Reihe von allgemeinen Anforderungen wie Flexibilität, Erweiterbarkeit bzgl. Funktionalität, Unterstützung von Komposition, Korrelation und Aggregation von Daten verschiedener Quellen.

2.2.2. Ergebnispräsentation

Datenbanken unterstützen nur exakte Anfragen und liefern dementsprechend alle Datensätze zurück, die der Anfrage entsprechen. Information-Retrieval-Systeme dagegen liefern Ergebnisse, die relevant sind oder dem System als relevant erscheinen. Ein Mediator-System wird beide Varianten unterstützen müssen, da hier ähnlich einem IR-System vage Anfragen möglich sind. Damit übernehmen MQS aber auch die Probleme, die IR-Systeme mit sich bringen: Einmal können zu viele Ergebnisse geliefert werden, und zum anderen können zutreffende Datensätze, die in den Daten vorhanden sind, nicht angezeigt werden. Man bedient sich deshalb häufig zweier Techniken des IR:

Ranked List. Jedem Ergebnis wird die Relevanz in Form eines numerischen Wertes zugeordnet. Die Ergebnisse werden dann absteigend sortiert nach der Relevanz ausgegeben. Das IR kennt eine Reihe von Verfahren zur Berechnung dieser Relevanz. Die Schwierigkeit besteht darin, dieses Konzept mit dem der strukturierten Daten zu kombinieren (DBMS).
Relevance Feedback. Hier wird anhand des präsentierten Ergebnisses die Anfrage genauer spezifiziert. Ein üblicher Weg besteht darin, alle relevanten Ergebnisse zu markieren. Diese werden dann vom System zur Generierung einer neuen Liste benutzt.

2.3. Schnittstelle Mediator – Datenquelle

Die Schnittstelle zwischen Mediator und den zugrundeliegenden Datenquellen wird häufig durch sog. Wrapper realisiert, die dafür sorgen, dass jede einzelne Datenquelle vereinheitlicht angesprochen werden kann. Wrapper sind Module, die einen Intelligenzausgleich zwischen den verschiedenen Datenquellen durchführen und eine einheitliche Schnittstelle zur Verfügung stellen. Die Herausforderung besteht u.a. darin, auch semi- oder unstrukturierten Datenquellen, die von Haus aus keine Anfragefähigkeiten im engeren Sinn mitbringen, ebensolche Fähigkeiten zu geben.

Es stellt sich dann die Frage, in wie weit die Funktionalität des Wrappers gehen kann und gehen sollte. Man könnte sich z.B. vorstellen, dass ein Wrapper den Mediator bei der Anfrageaufteilung und –optimierung unterstützt. Zwei Extremfälle werden nun diskutiert.

2.3.1. Fat Wrapper

Fat Wrapper erhalten lediglich den Teil der Anfrage (Unteranfrage) des Benutzers, der für die jeweilige Datenquelle relevant ist, ausgedrückt in der globalen Anfragesprache. Demzufolge ist die gesamte strukturelle und semantische Anpassung sowie die Übersetzung der globalen Anfragesprache in die Schnittstellensprache der Datenquelle durch den Fat Wrapper zu implementieren. Das hat zur Folge, dass sich zwar eine hohe Performance bzw. ein höherer Verteilungsgrad des Mediators ergibt, da dieser nur die passenden Datenquelle herausfinden und die Anfrage in einzelne Unteranfragen aufteilen muss. Andererseits ist bei der Erweiterung des Systems um eine weitere Datenquelle viel Funktionalität in einem neuen Wrapper zu implementieren.

Die Optimierung der Gesamtanfrage kann allerdings nur im Mediator erfolgen, da einzelne Wrapper i.d.R. nicht miteinander kommunizieren. Dasselbe gilt für die Ergebnisintegration, da die Wrapper nicht die Ergebnisse der anderen Wrapper kennen.

2.3.2. Thin Wrapper

Im Gegensatz zu den Fat Wrappern werden bei den Thin Wrappern so viele Aufgaben wie möglich vom Query-Processor und von der Anfrageausführungseinheit erledigt. Dadurch wird es nötig, dass diese Module eine Reihe von Modellen, Schemata und Verfahren kennen, die in den zugrundeliegenden Datenquellen vorhanden sind. Die Performanz ist offensichtlich etwas schlechter als bei den Fat Wrappern, da hier die Anfrageverarbeitung in den genannten Komponenten ausgeführt wird. Dagegen ist es recht einfach, eine neue Datenquelle hinzuzufügen. Somit ist eine gute Erweiterbarkeit gewährleistet.

2.4. Metadaten – Repository

Jede Anfrageverarbeitung beruht auf genauen Kenntnissen der verfügbaren Datenquellen. Dazu zählen natürlich evtl. Schemata und Metainformationen dieser Quellen, die meist, aber nicht zwingend, in einem globalen Schema vereint sind. Diese Sammlung an Metainformationen nennt man Metadaten-Repository, die damit stark von der Realisierung des Systems abhängt. Bei der Verwendung von Fat Wrapper würde ein Teil der Metainformationen aus dem Repository dorthin ausgegliedert sein, was bedeutet, dass das Metadaten-Repository selber mit den Wrappern kommuniziert, um Metadaten zu erlangen (Metadaten-Akquisition) .

Darüber hinaus können hier Informationen über Anwendungen und deren spezifischen Anforderungen enthalten sein.

2.5. Anfrageverarbeitung

Wie aus Abbildung 4: Aufbau der Mediationsschicht hervorgeht, ist die Verarbeitung einer Anfrage, die eine Anwendung oder ein Benutzer an das System gestellt hat, im wesentlichen in drei Schritte eingeteilt. Welcher konkrete Algorithmus in einem System verwendet wird, hängt u.a. von der Art der Anfragesprache, den Typen der verwendeten Datenquellen sowie davon ab, welcher Anfragetyp verwendet wird.

2.5.1. Auswahl der Quellen (Source Selection)

Der erste Schritt bei der Verarbeitung einer Anfrage besteht darin festzustellen, welche der vorhandenen Datenquellen Informationen zu einem Gesamtergebnis beitragen könnten. Die Unsicherheit kann sich durch die Unvollkommenheit der Metadaten ergeben, die nicht unbedingt den Inhalt der Datenquelle beschreiben, insbesondere bei unstrukturierten Datenquellen. Bei der Auswahl können einige Faktoren eine Rolle spielen, z.B. Verfügbarkeit und Performanz der Quellen. Des weiteren ist auch möglich, dass einige Quellen andere Datenquellen referenzieren und somit deren Benutzung induzieren.

2.5.2. Anfrageaufteilung und –optimierung

Aufbauend auf den Informationen, die im vorherigen Schritt gewonnen wurden, wird nun die Anfrage aufgeteilt und optimiert. Bei der Aufteilung spielt nicht nur eine Rolle, ob eine Datenquelle zum Ergebnis beitragen kann, sondern auch die Semantik der Anfrage, d.h. man muss die Bedeutung der Attribute und Methoden der Anfrage und deren Verhältnis zu den Datenquellen analysieren. Bei der Optimierung steht natürlich im Vordergrund, bei mehreren Möglichkeiten bezüglich der Aufteilung der Anfrage diese bestmöglich nach Performanzgesichtspunkten aufzuteilen. Das setzt ebenfalls eine genaue Kenntnis der zugrundeliegenden Daten voraus.

2.5.3. Anfrageausführung und Ergebnisintegration

Nach der Verarbeitung der Anfrage muss diese ausgeführt werden. Offensichtlich sind jetzt die jeweils relevanten Daten der zugrundeliegenden Quellen auszulesen und zu verarbeiten. Ähnlich wie bei DBMS müssen diese miteinander korreliert (z.B. Joins) und selektiert werden, sowie Methodenaufrufe (bei objektorientierten Modellen), Abstraktionen und Aggregationen durchgeführt werden.

Im Gegensatz zu klassischen DBMS ist es hier, wie z.B. bei föderativen DBMS, entscheidend, eine Auflösung semantischer Unterschiede durchzuführen. Das ist wohl eine der schwierigsten Aufgaben, die ein System wahrzunehmen hat, und Lösungsansätze befindet sich deshalb noch in einem relativ frühen Stadium.

Ein Ansatz zur Auflösung semantischer Heterogenitäten stellt Schema Integration dar. Aufbauend auf dem globalen Schema (oder den einzelnen vereinheitlichten Schemata der Datenquellen) müssen in einem gesonderten Arbeitsschritt die entsprechenden Konflikte aufgedeckt werden. Dabei hängen die Möglichkeiten in diesem Arbeitsschritt natürlich von der Qualität des globalen Schemas ab, d.h. davon, ob bei der (automatischen) Erstellung dieses Schemas bereits hinreichende Vorintegrationsschritte durchgeführt wurden. Man kann bei diesem Schritt unterscheiden, ob hier nur Attribute oder auch die Instanzen der Daten selber angeschaut werden, um etwaige semantische Ähnlichkeiten und Redundanzen zu finden [BF94]. Finden sich in den Datenquellen neben semantischen auch strukturelle Unterschiede (z.B. Speicherung einer Information als Attribut oder als extra Relation), dann müssen evtl. Schematransformationen durchgeführt werden, die jedoch nicht trivial sind. Aus den Informationen, die in den obigen Schritten gewonnen wurden, müssen dann Integrationsregeln für die Transformation und Verarbeitung der Ergebnisse, die bei der Anfrageverarbeitung gewonnen wurden, erstellt werden. Diese Regeln werden dann bei der Durchführung der Anfrageausführung angewendet.

Man kann sich vorstellen, dass zusätzlich zu den obigen Schritten noch manuell hinzugefügte Integrationsregeln angewendet werden um gewisse Transformationen auf den Daten durchzuführen, die dazu dienen neue Informationen und Wissen zu gewinnen. Ein solcher Prozess geht offensichtlich Hand in Hand mit den erwähnten Abstraktionsmechanismen.

3. Beispiel einer Mediator-Architektur: Garlic (IBM)

Es gibt eine Vielzahl von Entwicklungen und Forschungsprojekten, die sich zum Ziel gesetzt haben, heterogener Daten Herr zu werden und dabei Mediatoren einzusetzen. Stellvertretend soll hier das Garlic-Projekt von IBM vorgestellt werden.

Garlic wird seit Mitte der 90er Jahre in den Almaden-Forschungslabors von IBM mit der Zielstellung entwickelt, insbesondere Multimediadaten mit herkömmlichen Daten zu integrieren. Garlic stellt ein klassisches Beispiel der Architektur dar, wie sie in Kapitel 2 vorgestellt wurde. Das heißt, wir finden in der Garlic-Architektur insbesondere Wrapper, Metadaten-Repository und einen Query Processor. Da alle Datenquellen als sog. Garlic-Objekte, also objektorientiert ähnlich dem Object Database Management Group (ODMG) Standard repräsentiert werden, stellen die Wrapper quasi eine objektorientierte Schnittstelle zu den Datenquellen dar. Die Benutzerschnittstelle ist sowohl als C++ API implementiert, als auch durch eine Anfragesprache, die SQL um objektorientierte Fähigkeiten erweitert, die im Zusammenhang mit der genannten objektorientierten Repräsentation benötigt werden, insbesondere um Aufrufe von Methoden realisieren zu können.

3.1. Wrapper-Architektur

Wrapper sind in Garlic annähernd als Thin Wrapper implementiert, die jedoch an gewissen Funktionen des Query Processors teilhaben. So spielen sie eine entscheidende Rolle bei der Planung von Anfragen und deren Ausführung. Zuvor werden die Wrapper jedoch im Garlic-System registriert, damit das wrapper-interne objekt-orientierte Schema in die Garlic-Metadaten aufgenommen werden kann. Der Wrapper ist des weiteren dafür verantwortlich, dass Methodenaufrufe sowohl bei objekt-orientierten als auch bei allen anderen Datenquellen durchgeführt werden können. Trotz der erhöhten Funktionalität der Wrapper sind diese laut [RS97] leicht und kostengünstig zu implementieren, und das objektorientierte Modell, in das die Datenquelle transformiert wird, garantiert Flexibilität und Erweiterbarkeit. Für Datenquellen, die keine Anfragemöglichkeiten bieten, muss der Wrapper diese nur bedingt implementieren, sondern es muss lediglich der Zugriff auf die einzelnen Datensätze gewährleistet werden. Die restliche Funktionalität übernimmt Garlic. Dazu ist es aber u.U. notwendig, nur mäßig strukturierte Daten durch die Implementierung des Wrappers in eine feste Struktur zu überführen.

Folgende Abbildung zeigt das Zusammenspiel zwischen Mediator und Wrapper bei Garlic:

Abbildung 5: Wrapper im Zusammenspiel mit anderen Modulen, aus [RS97]

Die folgenden Abschnitte beschäftigen sich mit Voraussetzungen und der Funktionsweise des in der Abbildung dargestellten Ablaufs.

3.1.1. Methoden in Garlic-Objekten

Jedes Garlic-Objekt enthält für jedes der in ihm enthaltenen Attribute automatisch entsprechende Methoden, die zum Lesen und Schreiben (get_<attributname>, set_<attributname>) dieses Attributes dienen. Für Methodenaufrufe gibt es in Garlic zwei verschiedene Verfahren.

Zum einen gibt es Stub Dispatch, das besonders für native objektorientierte Datenquellen geeignet ist. Bei diesem Verfahren stellt der Wrapper nur sog. Stummel-Methoden (schemaabhängige Methoden) zur Verfügung, die direkt an das objektorientierte DBMS weitergeleitet werden.

Das zweite Verfahren nennt sich Generic Dispatch und ist für Datenquellen geeignet, die keine objektorientierten Eigenschaften besitzen, oder für solche, die allgemeine Methodenaufrufe unterstützen, d.h. Methodenaufrufe, die unabhängig vom zugrundeliegenden Schema sein können. So sind z.B. die get und set Methoden in einem relationalem Wrapper so beschaffen, da sie in einheitlicher Weise auf die Attribute in Relationen zugreifen.

3.2. Modellierung von Daten als Objekte

Unabhängig davon, welcher Art die durch einen Wrapper abgedeckten Datenquellen sind, sie müssen in Garlic in ein objektorientiertes Modell mit Attributen und Methoden transformiert werden. Dazu besitzt jedes Garlic-Objekt ein Interface und eine Implementation. Das Interface stellt die Deklaration dar, also die Beschreibung, wie sich ein solches Objekt verhält; die Implementierung enthält dann die zugehörige Definition. Diese Trennung zwischen Syntax und Semantik ist günstig, da in dem Garlic-System ohnehin Metadaten der Datenquelle benötigt werden. Es ist auch möglich, mehrere Implementierungen zu einem gegebenen Interface anzugeben.

Bei der initialen Registrierung des Wrapper am Garlic-System liefert der Wrapper eine Beschreibung seines Inhalts, das sog. Repository schema mittels der GDL (Garlic Data Language), die der ODL der ODMG sehr ähnlich ist.

Jedes Garlic-Objekt besitzt einen sog. Object Identifier (OID) der das entsprechende Objekt für Garlic referenzierbar macht. Es besteht aus einem Implementation Identifier (IID), der angibt, welche Implementierung von dem Garlic-Object benutzt wird, sowie einem Schlüssel, der das Objekt innerhalb der Datenquelle auszeichnet.

Zur Illustration wird ein einfaches Beispiel angeführt, welches in einem Reisebüro eingesetzt werde könnte. Wir beschränken uns der Einfachheit halber im folgenden darauf, Städte, Länder, Hotels und Bilder zu integrieren.

Schema der relationalen Daten

interface Country {

attribute string name;

attribute string airlines_served;

attribute boolean visa_required;

attribute Image scene; }

interface City {

attribute string name;

attribute long population;

attribute boolean airport;

attribute Country country;

attribute Image scene; }

Schema der Webdaten

interface Hotel {

attribute readonly string name;

attribute readonly short class;

attribute readonly double daily_rate;

attribute readonly string location;

attribute readonly string city; }

Schema eines Image-Servers

interface Image {

attribute readonly string file_name;

double matches(in string file_name);

void display(in string device_name); }

Abbildung 6: Schema einer Reisebüroanwendung, aus [RS97]

In unserem Schema gibt es Länder, Städte, Hotels und zugehörige Bilder, die sich in unterschiedlichen Datenquellen befinden. Zu beachten ist, dass Referenzen über die Grenzen einer Datenquelle hinweg erzeugt werden können. Ebenso ist es nicht nur möglich, Lesezugriff, sondern auch Schreibzugriff zu deklarieren.

3.3. Anfrageverarbeitung

Als erster Vorgang bei der Verarbeitung einer Anfrage wird diese geparst und damit in ihre einzelnen Komponenten zerlegt. Dann wird ein optimierter Plan erstellt, der anschließend ausgeführt wird. Diese Verarbeitung erfolgt mittels sog. STARs und POPs, die sowohl in Garlic selbst, als auch in den Wrappern definiert werden.

3.3.1. STARs und POPs

Garlic benutzt einen klassischen Ansatz der dynamischen Programmierung zur Generierung und Optimierung der genannten Pläne. Ein Plan ist ein Baum, dessen Knoten aus POPs (Plan Operator) bestehen. Jeder dieser POPs enthält eine Reihe von Attributen, u.a. welche Tabelle, welche Spalten, Prädikate und Kosten der Operation verwendet werden. Eine solche Operation könnte z.B. ein Scan sein, der eine komplette Tabelle durchsucht.

Zur Generierung solcher Pläne werden grammatikähnliche Strukturen eingesetzt: STARs (STrategy Alternative Rules). Diese stellen ein Werkzeug zur Konstruktion von Plänen dar. Das heißt, die „Terminalsymbole“ der STARs sind POPs. Das Startsymbol wird als Root bezeichnet und vertritt eine bestimmte Funktionalität. So gibt es Roots für SELECT, INSERT, DELETE und UPDATE. Eine entscheidende Rolle spielen dabei auch die folgenden Roots: AccessRoot und JoinRoot. AccessRoot ist für den reinen Zugriff auf Datenquellen, JoinRoot für die Joins verantwortlich. Damit ist klar, dass Garlic selbst keine AccessRoots definiert, sondern diese in den Wrappern zu finden sind. JoinRoots dagegen kann man in beiden finden.

Durch die rekursive Anwendung solcher STARs werden alternative Pläne gewonnen. In einem solchen Plan sind dann keine Metazeichen der STARS mehr vorhanden, sondern nur noch POPs.

3.3.2. Schritte zur Gewinnung eines Plans

Garlic führt zur Ermittlung des optimalen Plans drei Schritte durch. Die Optimierung erfolgt anhand des Kostenmodells, das die Zeiten für Kommunikation und Ausführung der Unteranfragen berücksichtigt.

Im ersten Schritt wird ein Access-Plan für alle in der Anfrage vorkommenden Datenquellen mit Hilfe der Wrapper erstellt.

Der zweite Schritt wendet dann STARS zur Erstellung der verschiedenartigen Joins an.

Im letzten Schritt werden fehlende POPs ergänzt, wenn z.B. bestimmte geforderte Attribute in den vorhanden POPs nicht enthalten sind. Schließlich wird der beste Plan anhand des Kostenmodells ausgewählt.

3.3.3. Beispiel der Erzeugung eines Plans

Als Beispiel für den Vorgang der Erzeugung eines Planes wird die folgende einfache Anfrage betrachtet:

SELECT h.name, c.name, t.name

FROM Hotel h, Country c, City t

WHERE h.name LIKE ‘Z%’ AND r.name=h.city AND t.country=c.OID

Die folgende Abbildung stellt in vereinfachter Weise die Konstruktion des Plans dar:

Abbildung 7: Beispiel eines Plans zu einer Anfrage auf dem obigen Beispielschema

Man erkennt, das zunächst die Access-Pläne erstellt werden; diese werden dann mit Joins zusammengefasst, bis alle Datenquellen verarbeitet sind. Der Join zwischen City und Country wird in diesem Fall vom relationalen Wrapper und nicht von Garlic selbst ausgeführt.

Nachdem bereits ein Plan vorhanden ist, stellt die Ausführung einer solchen Anfrage nun kein großes Problem dar, da die Wrapper nur noch angewiesen werden, das zu tun, was sie vorher schon als möglich erklärt haben.

3.4. Bewertung

Garlic stellt ein flexibles und übersichtliches System zur Integration heterogener Datenquellen dar. Das zugrundeliegende objektorientierte Modell ist sehr leistungsfähig, bietet aber in Sachen Auflösung semantischer Unterschiede und erweiterte Abstraktionsmethoden kaum Unterstützung. Dennoch lassen sich mit einigem Wissen über die Semantik der einzelnen Schemata, was auf Grund des häufigen Einsatz von Multimediadaten kein Problem sein dürfte, gute Ergebnisse erzielen.

4. Sicherheit in Mediator-Architekturen – CHAOS

In den bisherigen Abschnitten wurden vor allem Architektur und Funktionsweise von Mediator-Systemen diskutiert. Allerdings spielt auch das Thema Sicherheit eine wesentliche Rolle bei Entwicklung und Einsatz solcher Systeme. Ohne entsprechende Maßnahmen ist es im Grunde unmöglich, das System einzusetzen, da in praktisch allen Anwendungsgebieten sensible Daten vorhanden sind, die vor unbefugtem Zugriff geschützt werden müssen. Mediatoren, die Zugriff auf viele Datenquellen gewähren müssen, sollten deshalb auch Mechanismen bieten, um eben diese Datenquellen vor Missbrauch zu schützen. Die klassischen Mechanismen wie verschlüsselte Übertragung und Firewalls reichen hier nicht aus. Vielmehr sind von DBMS her bekannte Verfahren notwendig, um Daten in ausreichendem Maße zu schützen. Da jedoch die verschiedenen heterogenen Datenquellen nicht nur in Struktur und Semantik ihrer Daten verschieden sind, sondern auch in ihren Sicherheitsvorkehrungen, muss hier ebenfalls ein vereinheitlichtes System eingeführt werden, das möglichst automatisch und flexibel die genannten Aufgaben durchführt. Man nennt solche Systeme Sicherheits-Mediatoren [LLW00].

Es werden zwei Ansätze vorgestellt, die die Architektur aus Kapitel 2 um Sicherheitskomponenten erweitern.

4.1. Statische Sicherheitsmechanismen

Der erste Ansatz zur Implementierung von Sicherheitsmechanismen besteht darin, ähnlich wie bei einem DBMS Policies und ein Regelsystem in einem eigenen Repository ähnlich dem Metadaten-Repository abzulegen. Diese globale Datenbank wird von einem Administrator verwaltet. Da diese statisch spezifiziert und überprüft werden, nennt man diese Systeme statische Sicherheits-Mediatoren.

Der erweiterte Aufbau im Vergleich zu Kapitel 2 ist in folgender Abbildung dargestellt:

Abbildung 8: Architektur eines statischen Sicherheits-Mediators

Damit lassen sich eine Reihe von Sicherheitsproblemen lösen, jedoch gibt es gewisse Mängel, die mit der Heterogenität und Unabhängigkeit der einzelnen Datenquellen zusammenhängen.

Zum einen werden in der Regel die einzelnen Datenquellen autonom verwaltet. Das heißt, es gibt keinen expliziten Sicherheitsadministrator für alle vorhanden Datenquellen. Wird in einer Datenquelle z.B. die Änderung des externen Schemas durchgeführt, müssen die Regeln im Mediator-System angepasst werden. Das bedeutet einen erhöhten Aufwand bei der Wartung.

Des weiteren ist es sehr schwierig, ein einheitliches Regelsystem zu entwerfen, das allen Datenquellen mit ihrer Heterogenität gerecht wird.

Ein weiteres Problem stellen unstrukturierte Daten dar, da Regelsysteme am besten für relationale Datenquellen geeignet sind, d.h. für das Filtern von Datensätzen aus einer Tabelle. Das klassische Sicht-Konzept bietet hier auch weitergehende Funktionalität durch die Möglichkeit des teilweisen Zugriffs auf Daten. Jedoch implizieren diese weiteren Aufwand bei der Wartung.

4.2. Aktive Sicherheitsmechanismen

Um die Mängel des ersten Ansatzes zu überwinden, wurde an der Stanford-Universität das CHAOS-Projekt (Configurable Heterogeneous Active Object System) gestartet. Im folgenden wird nur auf die sicherheitsrelevanten Komponenten des Systems eingegangen.

In CHAOS wird die Zugriffskontrolle auf die Ebene der Datenquellen verlagert, indem angenommen wird, dass jede Datenquelle eigene Zugriffskontrollmechanismen besitzt. Der Wrapper für die jeweilige Datenquelle beschreibt die dort enthaltenen Daten als sog. Active Objects, die als XML-Objekte implementiert sind. Diese enthalten auch Informationen bzw. Implementierungen zur Zugriffskontrolle. Ist nun eine Datenquelle ohne Sicherheitsvorkehrungen an das System angeschlossen, findet auch hier ein Intelligenzausgleich statt.

4.2.1. Active Objects

Active Objects sind ein zentraler Bestandteil von CHAOS, da sowohl die eigentlichen Daten, als auch die Sicherheitsmechanismen in diesen Objekten verankert sind. Active Objects sind XML-Elemente, die zwei Element-Typen enthalten, zum einen Daten-Elemente und zum anderen Aktive Elemente. Die Daten-Elemente beschreiben den Inhalt des Objekts, während die Aktiven Elemente den Namen eines sog. Aktiven Knotens enthalten, nämlich eine Java-Klasse, die von einer von CHAOS zur Verfügung gestellten Klasse abgeleitet werden muss. Java bietet in dem Zusammenhang viele Vorteile und wurde deshalb als Sprache ausgewählt. Dadurch besteht die Möglichkeit, die vorhandenen Sicherheitsmechanismen zu verwenden, statt sie zu ignorieren.

4.2.2. Anfrageverarbeitung

Neben den üblichen Schritten bei der Anfrageverarbeitung wird bei CHAOS zunächst bei jeder Anfrage ein sog. Client Environment erstellt, das Informationen über den Client enthält. Anschließend wird die Anfrage anhand des Client Environment und einer statischen Regeltabelle, die es zusätzlich gibt, überprüft. Nach der erfolgreichen Ausführung der Anfrage werden die Active Objects, die das Ergebnis darstellen, gefiltert. Dazu werden die Active Nodes des jeweiligen Active Objects ausgeführt, indem die execute – Methode aufgerufen wird. Dadurch können z.B. bestimmte Attribute gefiltert werden, damit diese dem Anwender verborgen bleiben. Active Nodes können über einen sog. Tag-Pfad feststellen, zu welchem Objekt sie gehören, und auf dieses zugreifen. Damit können die Active Nodes neben sicherheitsrelevanten Aufgaben auch andere individuelle Funktionen, z.B. Aufsummieren eines Attributwertes, durchführen.

Abbildung 9: Anfrageverarbeitung in CHAOS, aus [LLW00]

Die obige Abbildung zeigt den Ablauf der Filterung von Anfrage und Ergebnis. Bei jeder auftretenden Ausnahme wird die Ausführung der Anfrage abgebrochen.

Das vorgestellte Prinzip ermöglicht eine sehr gute Flexibilität und Erweiterbarkeit der Sicherheitseinrichtungen. Ein entscheidender Vorteil ist, dass die Sicherheitseinrichtungen in den Datenquellen verwendet werden können, so dass die Verwaltung der Sicherheitseinstellungen durch eine einzige Instanz erledigt werden kann.

5. Zusammenfassung und Ausblick

Die in diesem Dokument vorgestellten Systeme stellen einen Ansatz zur einheitlichen Informationsgewinnung aus heterogenen Datenquellen dar, der die nötige Flexibilität und Erweiterbarkeit, die in der Praxis gefordert ist, bietet. Jedoch steht die Entwicklung noch am Anfang. Es gibt einige verfügbare Systeme, die nicht vollkommen sind, aber schon weitreichende Dienste anbieten.

Generell sind für die Mediator-Architekturen zwei Entwicklungsrichtungen absehbar: Auf der einen Seite Systeme, die sich darauf konzentrieren, die semantischen Unterschiede zu bereinigen, und durch vielfältige Möglichkeiten der Abstraktion und Verarbeitung der Daten mit Mitteln der künstlichen Intelligenz die zugrundeliegenden Daten soweit zu Wissen verarbeiten, anhand dessen z.B. die Entscheidungsfindung in Unternehmen automatisiert werden kann.

Auf der anderen Seite sind Systeme vorstellbar, die ähnlich dem föderativen DBMS nicht nur Lesezugriff auf die jeweiligen Daten gestatten, sondern auch Updates und insbesondere die Transaktionsverarbeitung auf den zugrundeliegenden heterogenen Daten erlauben. Für beide Systeme gibt es ein breites Spektrum an Anwendungen mit dem Ziel, Kosten und Zeit bei den Arbeitsabläufen in Unternehmen zu sparen.

6. Literaturverzeichnis

[BF94]	Bonjour, M., Falquet, G.: Concept Bases: A Support to Information Systems Integration. CAiSE*94 Conference , Utrecht, 1994. http://cui.unige.ch/db-research/Members/mb/papers/caise94/CAISE94_1.html
[DD92]	Domenig, R., Dittrich, K.R.: An Overview and Classification of Mediated Query Systems. ACM SIGMOD Record 28(3), 1999. http://www.ifi.unizh.ch/dbtg/Projects/SINGAPORE/index.html .
[HK96]	Haas, L. M., Kossmann, D., Wimmers, E. L., Yang, J.: An Optimizer for Heterogeneous Systems with Nonstandard Data and Search Capabilities. Data Engineering Bulletin '96. http://www.almaden.ibm.com/cs/garlic/debull96.ps
[LLW00]	Liu, David, Kincho Law, and Gio Wiederhold: CHAOS: An Active Security Mediation System. Advanced Information Systems Engineering (CAISE 12), 5 - 9 June, 2000, Stockholm, Sweden, Springer LNCS. http://www-db.stanford.edu/pub/gio/gio-papers.html
[Pa99]	Papakonstantinou, Y. : Garlic (IBM Almaden): Mediator for Multimedia Sources, http://www.db.ucsd.edu/people/yannis/wics4b/
[RS97]	Tork Roth, M., Schwarz, P.: Don´t Scrap It, Wrap It! A Wrapper Architechture for Legacy Data Sources. Proc. VLDB Conf., Athen, 1997. http://www.almaden.ibm.com/cs/garlic/homepage.html
[St99]	Stonebraker, M.: Integrating Islands of Information, EAI-Journal, Sep./Oct. 1999. http://www.eaijournal.com/PDF/stonebraker.pdf
[Wi92]	Wiederhold, G.: Mediators in the Architecture of Future Information Systems. IEEE Computer (25), 1992. http://www-db.stanford.edu/pub/gio/gio-papers.html .