Wrapper / Mediator Ansätze zum Information Brokering

Transkript

1 WS 1999/2000 Wrapper / Mediator Ansätze zum Information Brokering Ausarbeitung von Darmstadt, im Januar 2000 Betreuer Gerald Huck und Ingo Macherius Prof. Erich J. Neuhold Fachbereich Informatik FG Integrierte Publikations- und Informationssysteme Institut für Integrierte Publikations- und Informationssysteme

2 Inhaltsverzeichnis 1 Einleitung Mediatoren Allgemein ARANEUS Web-Base Management System ARANEUS Architektur ARANEUS Datenmodell ARANEUS Ablauf The GARLIC System GARLIC Architektur GARLIC Datenmodell GARLIC Ablauf The TSIMMIS Project TSIMMIS Architektur TSIMMIS Datenmodell TSIMMIS Ablauf Zusammenfassung Literaturverzeichnis Seite 1 von 17

3 1 Einleitung In der heutigen Informationsgesellschaft wird die Beschaffung, Integration und Präsentation von Informationen verschiedener Art und Herkunft immer wichtiger. Durch die Explosion des WWW sind immer mehr Informationen in losen Strukturen als Hypertext-Dokumente gespeichert. Durch Verbesserungen der Kommunikationstechnologien wurde es möglich, historisch getrennte Informationssysteme zu verbinden. Leider gibt es viele Probleme bei der Zusammenstellung von Informationen aus verschiedenen Systemen. Ein einfaches Verbinden der Informationsquellen löst dies nicht. Obwohl die Systeme verbunden sind, sind die Informationen in verschiedenen Datenmodellen dargestellt und der Zugriff auf diese Informationen damit erschwert oder sogar verweigert. Zum Beispiel gibt es viele Firmen, die ihre Informationen in vielen verschiedenen Informationsquellen gespeichert haben. Eine Datenbank hat z.b. persönliche Informationen aller Angestellten gespeichert, in einer komplett anderen Datenbank sind die Gehälter dieser Angestellten abgespeichert. Wenn nun die Adresse und das Gehalt benötigt werden, muß man in beiden Datenbanken mit unterschiedlichen Anwendungen suchen. Man hat dann 2 einzelne Suchergebnisse, die man von Hand z.b. in einem Dokument zusammenfügen muß. Es ist schwierig, Informationen aus mehreren verschiedenen Informationsquellen in kurzer Zeit zusammenzustellen. Erschwerend kommt noch hinzu, daß die Datentypen der Informationen sehr unterschiedlich sein können. Seite 2 von 17

4 2 Mediatoren Allgemein Bei den o.a. Problemen kommen Wrapper/Mediator Systeme zum Einsatz. Ihre Aufgabe ist die Integration der heterogenen Informationsquellen. Sie bieten vermittelnde Dienste an und verbinden Informationsquellen mit Anwendungen. Sie sind eine Middleware und stehen zwischen den Anwendungen und den Informationsquellen (siehe Abb. 1) Abb. 1: Schichtmodel Die Hauptaufgaben der Mediator-Systeme sind folgende: I. Das System muß sich Zugriff zu den heterogenen Informationsquellen verschaffen. II. Die erhaltenen Daten bzw. Informationen müssen in eine standardisierte Semantik und Darstellung transferiert werden III. Die Datenmodelle der Informationsquelle und der Anwendung müssen angepaßt werden IV. Die Daten müssen nach den gewünschten Suchkriterien integriert werden Wichtig für Mediator-Systeme ist, daß man sich auf standardisierte Schnittstellen einigt. Mediatoren sind eine Art Dienstleister, die Informationsdienste zur Verfügung stellen. Eine Automatisierung in diesem Bereich bezieht sich auf die Anpassung von vorhandenen Daten an die Anfragen des Kunden. Seite 3 von 17

5 Trotzdem ist immer menschliches Wissen bei den Mediator-Systemen von Nöten, z.b. um den Kunden Mehrwert anzubieten. Beispiele solcher Mehrwertdienste sind die Auswahl von wahrscheinlich relevanten Daten neben den explizit angeforderten Daten, eine Optimierung des Datenzugriffs, ein Einbauen von Sicherheitsmechanismen zum Schutz der Daten, eine Reduktion von historischen Daten auf einige Auszüge, eine Einschätzung der Datenqualität von verschiedenen Quellen, usw. Der Nutzen der Mehrwertdienste muß die Kosten der Zwischenschaltung eines Mediators übersteigen. Mediatoren können Informationen aufwerten, indem ein Experte sein Wissen einfügt. Mediatoren sollten auch von diesen Experten instand gehalten werden, damit sie sich an die sich ständig verändernden Gegebenheiten anpassen können. Ein einziger genereller Mediator für alle Bedürfnisse ist unmöglich zu realisieren. Eine einzige Anwendung benötigt unter Umständen sogar mehr als einen Mediator. Deshalb gibt es viele Mediatoren. Jeder von ihnen konzentriert sich auf sein Fachgebiet oder seinen Bereich, wie in Abbildung 2 dargestellt. Abb. 2: Gliederung in Bereiche Drei solcher Mediator-Systeme, die es schon gibt, werden hier vorgestellt. Anhand dieser Systeme kann man erkennen, daß es verschiedenartige Systeme mit großen Unterschieden gibt. Diese Unterschiede liegen im wesentlichen in der Art der Datenspeicherung, dem Datenmodell und der Art der Daten. Seite 4 von 17

6 3 ARANEUS Web-Base Management System Dieses System wurde an der Universität Rom entwickelt und verwaltet Webdaten im Datenbankstil. Web-Base bedeutet dabei eine Sammlung aus heterogenen Daten zum Einen aus Datenbanken, zum Anderen aus dem Web. Ein Web-Base Management System muß mit beiden Datenarten arbeiten können. Das ARANEUS Projekt will Tools für Datenmanagement im WWW entwickeln, die verschiedene Anwendungen unterstützen sollen wie einen hochwertigen Zugriff auf Daten im Web, Design, Entwurf und Pflege von Web Seiten und kooperative Anwendungen im Web. Ferner sollten Queries unterstützt werden. Ganz wichtig ist die Integration von Web Seiten durch Anwendungen, die Daten von anderen Web Seiten extrahieren, diese zusammenfügen und sie in integrierter Form auf einer neuen Seite präsentieren. Weitere wichtige Eigenschaften von ARANEUS sind das Datenmodell ADM (ARANEUS DATA MODEL), mehrere Sprachen zum wrappen, durchsuchen, entwerfen und updaten von Web Seiten und Methoden und Techniken zum implementieren und designen von Web Seiten. Durch das ARANEUS System sollen verschiedenartige Daten (aus Datenbanken und dem Web) zusammenarbeiten können. Seite 5 von 17

7 3.1 ARANEUS Architektur Abb. 3: ARANEUS Architektur In Abbildung 3 ist die Architektur von ARANEUS als Grafik dargestellt. ARANEUS ist in Java implementiert und läuft daher auf jeder Java-fähigen Plattform. Die Benutzerschnittstelle ist in HTML geschrieben. Das System hat Zugriff auf eine (möglicherweise auf einem Server liegende) relationale Datenbank (DBMS), die es benutzt, um Tabellen zu speichern und zu manipulieren. Das SQL-basierte Protokoll JDBC wird von dem System zur Kommunikation mit der Datenbank benutzt. Das DBMS ist kein richtiger Bestandteil des WBMS, das WBMS greift aber auf das DBMS zu, um Tabellen zu bearbeiten. Das System benutzt die Sprache ULIXES, um Web Seiten zu durchsuchen. Wenn eine externe Seite durchsucht werden soll, erfolgt zunächst eine ADM-Beschreibung, indem der Inhalt der Seite analysiert wird. Um die Daten zu erhalten, muß die Seite gewrappt werden. Dadurch kann man die Seiten durchsuchen und rekonstruieren. Das System benutzt ein erweiterbares Wrapper Library um Wrapper zu speichern. EDITOR ist eine Sprache zum durchsuchen und umstrukturieren von Textdokumenten. Alle Wrapper des Systems sind in EDITOR geschrieben. Wenn also eine Seite besucht wird, wird die Quelle aus dem Netz geladen und von dem entsprechenden Wrapper bearbeitet, welcher das resultierende ADM mit Hilfe des Object Managers speichert. Seite 6 von 17

8 ULIXES wird wie o.a. benutzt, um Web Seiten zu durchsuchen. Es implementiert eine Navigational Algebra. Mit Hilfe sog. Navigational Expressions kann man die ADM Seiten nach den Wünschen des Benutzers durchsuchen. Die Seiten werden anhand der Abfragen mit Startpunkt und Endpunkt (bis... gefunden) durchsucht. Auf diese Art und Weise kann man Daten aus den Seiten gewinnen und diese in der Datenbank speichern. Dies wird dann mit beliebig vielen Seiten gemacht. Eine neue Seite mit den zusammengefügten Daten kann man mit dem Modul PENELOPE erstellen. Grundidee ist, daß die auf der Seite zu veröffentlichen Daten in der Datenbank gespeichert werden. PENELOPE benutzt die beiden Sprachen PDL (PENELPOPE Definition Language) und PML (PENELOPE Manipulation Language). Wenn eine neue Seite generiert wird, wird als erstes das ADM Modell entworfen. Dies wird dann durch PDL an die Datenbank angepaßt. Die Seite wird dann mit Hilfe von PML entworfen. Das heißt, die logische Struktur wird in ADM erstellt und mit PENELOPE wird die Hypertext Struktur erzeugt. 3.2 ARANEUS Datenmodell Das ADM (ARANEUS Data Model) ist Seiten-orientiert, da Seiten eine zentrale Rolle spielen. Jede Seite wird als Objekt mit Identifier URL und Attributen wie Links, Bilder usw. angesehen. Ähnliche (homogene) Seiten werden als sog. page-schemes zusammengefaßt. Eine Web-Site ist also eine Sammlung von page-schemes, die durch Links verbunden werden. Page-schemes sind so etwas wie Klassen bei der OO und werden zum modellieren eines Bündels von homogenen Seiten verwendet. Im System werden ADM-Objekte mit dem ADM Object Manager Modul bearbeitet. Objekte werden zerlegt und in dem DBMS gespeichert. ADM ist ein festes, relationales Datenmodell, da die strukturierten Daten Datenbanktabellen sind. Dieses relationale Modell hat den Vorteil, daß nicht alle Klassen geändert werden müssen, wenn der Hypertext geändert wird. Daher kann sich die Präsentation der Daten ändern, ohne das die Daten geändert werden. Deshalb wird jedem page-scheme ein HTML Template zugeordnet. Dieses Template legt das Layout der Seiten anhand der page-scheme fest und kann unabhängig von der page-scheme verändert werden. Wenn PENELOPE eine Instanz einer page- Seite 7 von 17

9 scheme erzeugt, werden die Werte aus der Datenbank gelesen und mit dem dazugehörigen Template verschmolzen. Die Datenbanken der Seiten müssen periodisch einem Update unterzogen werden. Diese Updates müssen natürlich auch auf der Seite reflektiert werden. Um die Konsistenz zwischen DBMS und der HTML Seite zu erhöhen, wird die Page- Update-Sprache PML und ein Algorithmus zur Pflege der Seiten benutzt. Wenn also eine Änderung der Datenbank an das System gemeldet wird, wird eine sogenannte mixed transaction ausgeführt, in welcher SQL die Datenbanktabellen updatet und PML die Seiten updatet um eine Konsistenz zwischen den beiden zu erreichen. 3.3 ARANEUS Ablauf Nun folgt eine grobe Ablaufbeschreibung des ARANEUS Systems. Als erstes werden die original Seiten (external Web Sites) gewrappt und dadurch in ADM beschrieben. Danach werden die relevanten Teile der Seiten mit Hilfe von ULIXES und der Navigational Expressions anhand der Wünsche des Benutzers extrahiert. Diese Daten werden dann temporär auf der Datenbank gespeichert. Das kann nun mit beliebig vielen Seiten passieren. Dann werden SQL-Statements auf die Datenbank angewendet, um einen integrierten Datensatz zu erhalten. Dieser integrierte Datensatz liegt nun als ADM vor und wird mittels PENELOPE als neue Hypertext Seite generiert, die dann dem Benutzer zugänglich ist. Seite 8 von 17

10 Abb. 4: The view definition process in ARANEUS Wie man aus der Ablaufbeschreibung erkennen kann, gehen die Daten von einer schwach strukturierten Organisation, den Web Seiten, zu einer stark strukturierten, den Datenbanken, und wieder zurück zu den Web Strukturen. Dies kann man auch in Abbildung 4 nachvollziehen. Seite 9 von 17

11 4 The GARLIC System GARLIC (diese Abkürzung hat keine Bedeutung) wurde von dem IBM Almaden Research Center entwickelt. Es ist ein System mit dazugehörenden Tools zum Management von einer Vielzahl von heterogenen Multimedia Informationen. Heterogene Daten, die in verschiedenen Datenservern liegen, werden integriert, ohne zu ändern, wo oder wie diese Daten gespeichert sind, d.h. ohne diese Daten zu kopieren. Die Daten werden durch ein einheitliches OO Schema betrachtet und können durch einen OO SQL-Dialekt durchsucht und manipuliert werden. Da die meisten dieser Daten als Objekte modelliert sind, beinhaltet GARLIC ein OO Datenmodell. Dieses Modell wird komplettiert durch eine OO-Query-Sprache und unterstützt durch Tools zur Datengewinnung. Sie präsentieren das OO Schema den Anwendungen, interpretieren Objekt Abfragen und Updates, unterstützen das Absenden von Abfragen an Datenserver und geben Abfrageergebnisse an die Anwendungen zurück. 4.1 GARLIC Architektur Abb. 5: Garlic System Architektur Abbildung 5 zeigt die Architektur von Garlic als Grafik. Am unteren Rand des Systems sind verschiedene Datenserver (Data Repository) wie Datenbanken, Filesysteme, Dokument-Manager usw., die die zu integrierenden Daten enthalten. Daneben existiert ein spezielles Complex Object Repository, Seite 10 von 17

12 welches komplexe Objekte enthält, die die meisten GARLIC Anwendungen benötigen, um die Daten in sinnvoller Weise zusammenzufügen (bzw. zu integrieren). Bei einer Autoversicherung würden hier zum Beispiel die Bilder eines kaputten Autos liegen, die mit dem Unfallbericht verknüpft werden können. Über den Datenservern befindet sich jeweils ein Wrapper, welcher das jeweilige Datenmodell in ein einheitliches übersetzt. Die Wrapper modellieren die Daten aus den jeweiligen Datenservern als GARLIC Objekte und bieten deren Attribute an, d.h. durch den Wrapper müssen die Zieldaten in GDL (GARLIC Data Language) betrachtbar sein. Das zentrale Modul ist das GARLIC Query Services & Runtime System Modul. Dieses bietet Abfragemechanismen und Datenmanipulation an. Die Abfragen, die ein Benutzer eingibt, werden in diesem Modul weitergeleitet und in kleine Abfragen, die auf den unterliegenden Datenservern ausgeführt werden können, unterteilt. Die Wrapper übersetzen dann diese kleinen Abfragen in die Query Sprache des jeweiligen Datenservers. Das Metadata Repository übernimmt das sog. Constraint Management. Hier werden Integrierungsbedingungen und beschränkungen festgelegt und überwacht. Die Endbenutzer können mittels einer Browser Schnittstelle auf die Daten zugreifen und diese navigieren. Anwendungen können eine C++-Schnittstelle benutzen, um mit dem System zu kommunizieren. 4.2 GARLIC Datenmodell Das GARLIC Datenmodell bietet eine integrierte, OO Sichtweise der Daten von verschiedenen Quellen und ist kein neues OO Datenmodell, sondern eine Erweiterung von ODMG-93, einem Datenbankableger von CORBA. Die fundamentalen Elemente sind die Objekte und Values. Die Beschreibung der Objekt Schnittstelle beinhaltet Attribute, Verbindungen und Methoden, die für die Objekte der Schnittstelle charakteristisch sind. Es existiert eine starke Trennung zwischen der Schnittstelle und ihrer Implementierung. Der Typ des Objekts ist immer durch seine Schnittstelle festgelegt. Das Problem, daß Daten in den unterliegenden Servern spezifische Referenzen enthalten können, die nur dem entsprechenden Server bekannt sind und von Seite 11 von 17

13 GARLIC nicht umwandelbar sind, löst GARLIC mit den sog. Implementationcontrained references, welches Referenzen sind, die nur von den unterliegenden Servern gelesen werden können. Die Wrapper sind dann für die Umwandlung in das GARLIC Referenz Format zuständig. Im GARLIC Datenmodell ist Vererbung möglich. Die erbende Schnittstelle erbt alle Attribute usw. Alle relationalen Daten können in GARLIC auch als OO Daten angesehen werden, z.b. kann man die Tabelle einer relationalen Datenbank als Sammlung von Objekten betrachten. 4.3 GARLIC Ablauf Nun folgt wieder eine grobe Ablaufbeschreibung bei GARLIC. Der Benutzer schreibt eine Abfrage am Browser. Das zentrale Modul unterteilt diese Abfrage in mehrere kleine Abfragen und leitet diese an die Wrapper weiter. Die Wrapper übersetzen die keinen Abfragen in die jeweilige, dem Datenserver eigene Query Sprache und leiten die Abfrageergebnisse an das zentrale Modul zurück. Dort werden die Daten integriert und das endgültige Ergebnis an den Browser weitergeleitet (oder bei Anwendungen an die C++ Schnittstelle) Seite 12 von 17

14 5 The TSIMMIS Project TSIMMIS steht für The Stanford IBM Manager of Multiple Information Services. Das Ziel dieses Projekts ist die Entwicklung von Tools zur Vereinfachung der Integration von heterogenen Informationsquellen aus strukturierten und semi-strukturierten Daten. Dies soll aber nicht durch eine vollständig automatisierte Integration geschehen, vielmehr soll ein Rahmen von Tools geschaffen werden, welcher Menschen bei der Integration unterstützt. Es soll ein integrierter Zugriff auf diverse Informationsquellen unter Sicherstellung der Konsistenz der Daten angeboten werden. TSIMMIS bietet neben dem eigenen Datenmodell und der Query Sprache auch Tools zur automatisierten Erstellung der benötigten Komponenten an. 5.1 TSIMMIS Architektur Abb. 6: TSIMMIS Architektur Abbildung 6 gibt einen graphischen Überblick über die Architektur von TSIMMIS. Am unteren Rand des Systems befinden sich wieder die Datenquellen. Darüber befindet sich jeweils ein Wrapper (Translator) zur Transformation des jeweiligen Datenmodells in ein vorgegebenes, hier das OEM (Object Exchange Model). Dazu werden Queries aus dem OEM in Queries, die die Quelle ausführen kann übersetzt und Daten, die von den Quellen zurückkommen in das OEM übersetzt. Seite 13 von 17

15 Über den Wrappern befinden sich Mediatoren, die die Informationen verfeinern, die von den Quellen kommen. Ein Mediator besitzt das Wissen, das notwendig ist, um bestimmte Informationen weiterzugeben bzw. zu verarbeiten, indem sie z.b. die Daten in ein bestimmtes Format konvertieren, oder um doppelte Informationen zu eliminieren. Mediatoren zu Implementieren kann sehr aufwendig sein. In TSIMMIS soll viel des Codes automatisiert werden. Ein wichtiges Ziel ist deshalb die automatische oder semi-automatische Generierung von Mediatoren ausgehend von der Beschreibung der zu behandelnden Daten. Diese werden von dem Mediator Generator hergestellt. Ähnlich ist der Translator Generator,der OEM Wrapper generiert. Mediatoren und Wrapper exportieren beide identische Schnittstellen an ihre Clients. Beide haben OEM SQL-Queries als Eingabe und liefern OEM Objekte zurück. Endbenutzer und Mediatoren können ihre Informationen sowohl von Wrappern als auch von anderen Mediatoren bekommen. Benutzer haben entweder durch das Schreiben von Anwendungen, die OEM Objekte einlesen können, oder durch das Nutzen eines Browsers von TSIMMIS Zugriff auf die Informationen. Der Benutzer schreibt eine Abfrage auf einer interaktiven WWW-Seite und erhält als Antwort ein Hypertext Dokument. Eine wichtige Komponente ist das Constraint Management. Hier liegen die Integrierungsbeschränkungen, die die semantischen Konsistenzbedingungen der Informationen beschreiben. In diesem Modul findet die Durchführung und Überwachung dieser Beschränkungen statt. Mittels des graphische Browsers (mit dem Namen MOBIE) kann man Abfragen an TSIMMIS senden und die gelieferten Ergebnisse, in Form von OEM Objekten, navigieren. MOBIE verbindet Benutzer mit den Mediatoren oder Wrappern. Classifier/Extractor sind für die Informationsgewinnung aus komplett unstrukturierten Daten wie Bitfolgen oder Files zuständig. 5.2 TSIMMIS Datenmodell Das TSIMMIS Datenmodell nennt sich OEM (Object Exchange Model). Die Grundidee dieses erweiterbaren Models ist, daß alle Objekte und deren Subobjekte eine Beschriftung haben, die ihre Bedeutung beschreibt. Seite 14 von 17

16 Zum Beispiel repräsentiert das folgende Objekt eine Temperatur von 80 Grad Fahrenheit: <temp-in-fahrenheit, int, 80> Hieraus wird ersichtlich, daß jedes Objekt die Struktur Label, Type, Value und Object-ID hat. Label ist die o.a. Beschriftung, Type ist der Datentyp des Objektwertes und Value ist der Wert des Objekts. Optional kann noch ein Identifier des Objekts, die Object-ID, angegeben sein. Die Daten müssen nicht als OEM gespeichert sein, OEM wird nur benutzt um Abfragen zu verarbeiten und den Benutzer mit Resultaten zu versorgen. OEM ist ein beliebig erweiterbares Graphen Modell, das sehr einfach gehalten ist. 5.3 TSIMMIS Ablauf Nun wieder eine grobe Ablaufbeschreibung des Systems. Als erstes muß sich der Benutzer an einen Mediator (oder einen Wrapper) anmelden. Dann gibt er seine Abfrage in die Benutzer Schnittstelle ein. Die Abfrage wird mehrere kleine Abfragen unterteilt und so an die Wrapper weitergeleitet. Die Wrapper übersetzen die kleinen Abfragen in die Datenserver eigene Abfrage-Sprache. Die Abfrage wird dann in dem Datenserver ausgeführt und das Ergebnis an den Wrapper zurückgeliefert. Dort wird es in ein OEM Objekt umgewandelt. Diese OEM Objekte werden in Zusammenarbeit mit den Constraint Managern und den Mediatoren integriert und an die Benutzer Schnittstelle zurückgeliefert. Seite 15 von 17

17 6 Zusammenfassung Zusammenfassend kann man sagen, daß die 3 Systeme mit doch sehr unterschiedlichen Ansätzen an die Problematik gehen. Während ARANEUS ein Data-Warehousing betreibt und sehr Webseiten orientiert ist, weist GARLIC ein föderiertes, statisches DBMS auf. TSIMMIS dagegen hat eine sehr flexible Architektur und kommt den modernen Ansprüchen an ein Mediator-System wohl am weitesten entgegen. Sehr unterschiedlich sind auch die benutzten Datenmodelle. Während ARANEUS ein festes, relationales und GARLIC ein festes, objektorientiertes Datenmodell gewählt haben, wird bei TSIMMIS ein beliebig erweiterbares Datenmodell benutzt. Keines der oben aufgezeigten Systeme kann die Ziele und Ansprüche, die an solche Systeme geknüpft werden, vollständig erfüllen. Sie stellen jedoch alle gute Ansätze dar. ARANEUS ist in Betrieb. Es ist leider nur für die ursprünglich gedachten Datenserver verwendbar. Wenn TSIMMIS, besonders die automatisierte Generierung der Wrapper und Mediatoren, gut funktionieren sollte, könnte dies ein Schritt in die richtige Richtung sein. Seite 16 von 17

18 7 Literaturverzeichnis [GW96] Gio Wiederhold und Michael Genesereth. The Conceptual Basis for Mediation Services, [AMMMS98] P.Atzeni, G.Mecca, P.Merialdo, A.Masci, G.Sindoni. From Databases to Web-Bases: The ARANEUS Experience, [AMM97] P.Atzeni, G.Mecca, P.Merialdo. To Weave the Web, [CHS95] M.J.Carey, L.M.Haas, P.M.Schwarz. Towards Heterogeneous Multimedia Information Systems: The Garlic Approach, [RS97] M.T.Roth, P.Schwarz. Don t Scrap It, Wrap It! A Wrapper Architecture for Legacy Data Sources, [CGH94] S.Chawathe, H.Garcia-Molina, J.Hammer. The TSIMMIS Project: Integration of Heterogeneous Information Services, [GPQ97] H.Garcia-Molina, Y.Papakonstantinou, Dallan Quass. The TSIMMIS Approach to Mediation: Data Models and Languages, Seite 17 von 17