David Kaiser, Thomas Hoffmann, Christina Reuter

Präsentation zum Thema: "David Kaiser, Thomas Hoffmann, Christina Reuter"—  Präsentation transkript:

1 Aufbau Integrierter Informationssysteme Integration durch Mediatoren und Wrapper
David Kaiser, Thomas Hoffmann, Christina Reuter Martin-Luther-Universität Halle-Wittenberg Hauptseminar - Halle

2 Gliederung Einleitung Architektur und Merkmale von MBIS Beispiel:
TSIMMIS-Ansatz Zusammenfassung © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

3 Einleitung- Gliederung
1.1 Hauptziele der Integration 1.2 Probleme der Integration 1.2.1 Autonomie 1.2.2 Heterogenität 1.3 Integrationsansätze und Architekturformen 1.4 Grundlagen Mediatoren + Wrapper © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

4 Hauptziele der Integration
Mehrere Informationssysteme müssen so integriert werden das der Endbenutzer Die Illusion hat mit einem Informationssystem zu arbeiten Einfache und kostengünstige Erweiterbarkeit Bei Integration unstrukturierter Daten muss der Benutzer in der Lage sein genaue als auch ungenaue Anfragen stellen zu können © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

5 Probleme bei der Integration
Autonomie: welchen Abhängigkeiten wird eine Datenquelle unterworfen, wenn sie in einen Verbund eintritt Heterogenität: unterschiedliche Hardware, Datenmodelle und Semantik Evolutionsfähigkeit: jedes Softwaresystem unterliegt kontinuierlicher Evolution Schreibzugriff: Datenquellen müssen Autonomie abgeben Verteilte Transaktionsverwaltung Schwierig © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

6 Formen von Autonomie Entwurfsautonomie: Kommunikationsautonomie:
Die Fähigkeit einer Datenquelle seine eigene Struktur in jeder Beziehung selbst zu bestimmen. (Datenmodell, Bedeutung der Daten, Änderungsfreiheit) Kommunikationsautonomie: Die Fähigkeit eines DBS zu entscheiden wann, wie und ob es auf Anfragen von Benutzern oder anderen DBSen reagiert. Ausführungsautonomie: Die Eigenschaft eines DBS lokale Befehle oder Transaktionen auszuführen ohne von externen Operationen gestört zu werden. Das DBS muss externe Operationen abbrechen, verbieten oder deren Reihenfolge selbst bestimmen können. © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

7 Formen von Heterogenität (1)
Strukturelle Heterogenität: Entsteht durch die unterschiedlichen Repräsentationen in den DBS und tritt vor allem bei unterschiedlichen Datenmodellen oder Schemata auf (Attribut-,Tabellen- und Schemakonflikte,Format,Datentyp) Semantische Heterogenität: Entsteht durch die unterschiedlichen Repräsentationen in den DBS welche durch ihre Bedeutung in Konflikt geraten. Dies tritt insbesondere bei verschiedenen Maßstäben von Attributen oder Relationen auf (Namens-,Wertebereich- und DB-Sprachkonflikte) © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

8 Formen von Heterogenität (2)
Syntaktische Heterogenität: 1. Technische: Unterschiedliche Plattformen, Betriebssysteme oder Zugriffsprotokolle 2. Schnittstellen: Verschiedene Anfragesprachen und deren Dialekte. Einschränkungen der Sprache, Anfragen und Wertmengen Datenmodell Heterogenität: Bedeutung der verschiedenen Datenmodell und Schemata (Rel,OO) Logische Heterogenität: 1. semantische: Bedeutung der Daten und Schemata 2. schematische: Daten einerseits als Attribute oder als Werte 3. strukturelle: Daten mit gleicher Bedeutung im gleichen Datenmodell aber mit unterschiedlichen Strukturen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

9 Materialisierte Systeme
Integrationsansätze Universal DBMS Data Warehouse Materialisierte Systeme Such- maschinen Föderierte DBMS Mediatoren Systeme Virtuelle Systeme Strukturierte Unstrukturierte Strukturierte, Semistrukturierte, © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

10 2 Schichten Client Server Architektur
Architekturen 2 Schichten Client Server Architektur Variante 1: - Client: Benutzerschnittstelle + Anwendungslogik - Server: DB Benutzerschnittstelle Anwendungslogik DB Server Client Benutzerschnittstelle Anwendungslogik DB Server Client Variante 2: - Client: Benutzerschnittstelle - Server: DB + Anwendungslogik © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

11 Client-Server Architektur
Trennung der Funktionen des Server von denen die vom Client realisiert werden Probleme: - welche Komponente integriert Daten von verschiedenen Quellen - welche Komponente führt Transformation von Daten in von Clients benötigte Strukturen durch Lösung: - entkopple Clients und Server durch eine mittlere Schicht, welche die vermittelnden Funktionalitäten realisiert  3 Schichtenarchitektur © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

12 Vergleich der Architekturen
2-Schichten 3-Schichten Vorteile Einfache Entwicklung von nicht- integrierten Standartlösungen Wiederverwendbarkeit Pflege, Wartung Skalierbarkeit Nachteile Wartung, Pflege -Entwicklungsaufwand am Anfang der Realisierung hoch Zur Lösung der Integrationsprobleme Übergang zur 3-Schichten Architektur © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

13 Drei-Schichten-Architektur
Mediationsschicht Wrapper Applikationsschicht Datenquellen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

14 Definitionen Mediatoren - Mediation = Vermittlung
„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“ (Wiederhold 1992) - Mediation = Vermittlung - Mediatoren bilden eine Vermittelnde Schicht (mediation layer), die zwischen den Anwendungen und Datenquellen vermittelt - Mediatoren stellen eine Vielzahl von Funktionen bereit, so dass die Anwendungen die benötigten Information in geeigneter Form (syntaktsch und semantisch) erhalten (Value-added services). © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

15 Definitionen Wrapper „wrapper“ = Hülle
Primäre Aufgabe ist die Einkapselung der in der Datenquelle gespeicherten Daten und ihre Schnittstelle nach außen Logisches Grundmodell: Applikation Wrapper Datenquelle Sprache X Sprache Z Modell Y Modell W © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

16 Definitionen Wrapper können für folgende Aufgaben eingesetzt werden:
- Schaffung einer vereinfachten Schnittstelle für eine Datenquelle - Vereinheitlichung der Schnittstellen heterogener Datenquellen - Erhöhung der Funktionalität einer Datenquelle - Offenlegung von internen Schnittstellen einer Datenquelle © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

17 Vorteile des Wrappings
- Vereinfachte Systemevolution - Starke Skalierbarkeit - Heterogenität - Kostenersparnis - Unabhängigkeit der Datenquellen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

18 Nachteile des Wrappings
Schlechtere Performance Der Zugriff auf die Datenquellen erfolgt beim Wrapping indirekt Dadurch wird der Zugriff langsamer Aktualität der Wrapper notwendig Aktualität ist Grundvoraussetzung für das funktionieren des Systems © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

19 Architektur mediatorbasierter Informationssysteme
Gliederung des 2. Teils Architektur mediatorbasierter Informationssysteme 2.1 Drei-Schichtenmodell 2.2 Aufbau der Mediationsschicht 2.3 I³-Referenzarchitektur 3. Merkmale von MBIS © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

20 Architektur Aufbau vorhandener Systeme nur zu einem gewissen Grad übereinstimmend deshalb hier eine auf eine allgemeine Auswahl dieser Informationssysteme beschränkt es liegt eine dreischichtige Architektur vor bestehend aus: Applikationsschicht Mediationsschicht Schicht der Datenquellen Idee: Funktionalitätsverlagerung in eine vermittelnde (Mediation) Schicht, um den globalen Anforderungen gerecht zu werden © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

21 Drei-Schichten-Architektur
Mediationsschicht Wrapper Applikationsschicht Datenquellen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

22 Drei-Schichten-Architektur  Wrapper
Mediationsschicht Lösung der Schnittstellen- und Datenmodellheterogenität Ermöglichung des Zugriffs auf eine Datenquelle, mit Hilfe einer nach aussen sichtbaren Schnittstelle unabhängig vom Datenmodell und des Anfragemechanismus zum Mediator hin eine einheitliche Schnittstelle © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

23 Drei-Schichten-Architektur Mediationsschicht
Integration und Anreicherung der Daten mehrere Mediatoren lösen Probleme der logischen Heterogenität Redundanzfreie Präsentation der Information in der Anwendungsschicht Mediation: Aktivität, die Daten durch das Anwenden von Wissen über die Ressourcen, Suchstrategien, Benutzeranforderungen in Information verwandelt Grad der Integration variiert mit der Datenquelle und den Anforderungen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

24 Drei-Schichten-Architektur Applikationsschicht
Mediationsschicht Schnittstelle zwischen MBIS und Benutzer 2 Aufgaben: Spezifikation der Anfrage Präsentation der Ergebnisse © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

25 MBIS-Architektur  Aufbau der Mediationsschicht
Anwendung Anfragesprache (-schnittstelle) Ergebnis- präsentation Source Selection Anfrageaufteilung Anfrage- optimierung integration ausführung Wrapper 1 Wrapper 2 Wrapper n Query Processor Metadaten Repository Globales Schema Schnittstelle User-Mediator Schnittstelle Mediator- Datenquellen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

26 Aufbau der Mediationsschicht
Zwei Möglichkeiten der Realisierung eines MBIS: ein einziges zentrales System beinhaltet die gesamte Funktionalität Netzwerk mit einer Vielzahl miteinander kommunizierender Komponenten, auf denen die Funktionalität verteilt ist „Netzwerk von Mediatoren“ spezialisierte Mediatoren nach Fachgebiet, Domäne, ... Vorteil: Höhere Flexibilität und Erweiterbarkeit, wenn entsprechende Sprache zwischen den Mediatoren verfügbar ist Nachteil: entstehender Overhead © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

27 Aufbau Mediationsschicht  Schnittstelle User-Mediator
Interface User-Mediator Schnittstelle User-Mediator Garantiert, dass eine Anwendung die zur Verfügung gestellte Funktionalität in einfacher Weise nutzen kann Ermöglichung einer einheitlichen Auswertung der Ergebnisse GUI steht nicht im Vordergrund, da der Benutzer eher indirekt durch ein bestimmtes Anwendungsprogramm auf den Mediator zugreift © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

28 Aufbau Mediationsschicht  Interface User-Mediator
Anfragesprache: einfache API`s nicht ausreichend sollte SQL ähnlich sein Anfragesprache Spezielle Anforderungen: Unterstützung verschiedener Anfragetypen: durch sehr variables Informationsbedürfnis Ermöglichen vager,ungenauer Fragestellung Schemaabhängigkeit: Anfrage in Abhängigkeit eines globalen oder (teilweise) in Abhängigkeit eines lokalen Schemas Zugriff auf Metadaten Vorraussetzung für Schemaabhängigkeit Zugriff auf „Daten über Daten“ weitere allgemeine Anforderungen: Flexibilität; Erweiterbarkeit; Funktionalität; Unterstützung von Komposition, Korrelation, Aggregation © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

29 Aufbau Mediationsschicht  Interface User-Mediator
Ergebnis- Präsentation Ergebnispräsentation: MBIS unterstützen 2 Möglichkeiten: genaue Antwort auf exakte Query wie bei normalen DB-Anfragen mit einer Ausgabe die exakt der Anfrage entspricht  Information Retrieval Systeme liefern relevanter oder für das System relevanter Ergebnisse vage Anfragen möglich © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

30 Aufbau Mediationsschicht  Interface User-Mediator
Probleme von Information Retrieval Systemen: Zuviele Ergebnisse Zutreffende Datensätze nicht in der Ergebnismenge angezeigt Lösung durch: Ranked List: jedem DS wird nach einem bestimmten Verfahren berechnete Relevanz zugeordnet Relevanz ist Sortierkriterium bei Auflistung der Ergebnisse Relevance Feedback: anhand des Ergebnisses wird die Anfrage genauer spezifiziert alle relevanten Ergebnisse werden markiert, um daraus eine neue Liste zu generieren © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

31 Aufbau Mediationsschicht  Interface Mediator-Datenquelle
Schnittstelle Mediator-Datenquelle Realisierung erfolgt durch spezielle Module (sog. Wrapper) Wrapper: sorgen für Intelligenzausgleich zwischen den Datenquellen stellen einheitliche Schnittstelle zu den Ressourcen her Kategorisierung nach dem Grad ihrer Funktionalität 2 Extrema:  Fat Wrapper  Thin Wrapper Wrapper Interface Mediator- Datenquelle © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

32 Aufbau Mediationsschicht  Interface Mediator-Datenquelle
Fat Wrapper: Erhalten nur Teil der Anfrage des Benutzers, der für die jeweilige Datenquelle relevant ist Strukturelle, semantische Anpassung, Übersetzung der globalen Anfragesprache in die Schnittstellensprache der Datenquelle erfolgt durch den Wrapper „viel Funktionalität im Wrapper“ Vorteil: Hohe Performance, höherer Verteilungsgrad des Mediators Nachteil: Höherer Aufwand bei Erweiterung des Systems um eine Datenquelle Thin Wrapper: Verlagerung der meisten Arbeiten auf den Query-Processor und der Ausführungseinheit diese Module müssen eine Menge von Modellen, Schemata und Verfahren der Datenquellen kennen Nachteil: Performance schlechter, da Anfrageverarbeitung in den komponenten Vorteil: einfaches Hinzufügen einer neuen Datenquelle © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

33 Aufbau Mediationsschicht  Metadaten Repository
enthält Sammlung von Metainformation Metamodelle (Metadaten über Datenmodelle) Beschreibung des Inhalts von Datenquellen Metainformation über Komponentensysteme Information über Anwendungen und deren spezielle Anforderungen Design abhängig von der Realisierung des MBIS (bei Fat Wrapper  ein Teil der Metainformation dorthin ausgegliedert) Metadatenakquisition durch Kommunikation mit Wrappern möglich © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

34 Aufbau Mediationsschicht  Anfrageverarbeitung
Query Processor Aufteilung Optimierung Selektion Ausführung Ergebnis- integration Anfrageverarbeitung: in 3 Schritte untergliedert: Auswahl der Quelle Anfrageaufteilung und – optimierung Anfrageausführung und Ergebnisintegration © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

35 Aufbau Mediationsschicht  Anfrageverarbeitung
Auswahl der Datenquellen: Feststellen welche Datenquellen zur Lösung der Aufgabe beitragen Unter Benutzung der Metadaten ihre Unvollkommenheit führt zu Unsicherheit bei der Selektion Auswahlkriterien können auch Verfügbarkeit und Performance der DQ sein Datenquellen können andere referenzieren, diese müssen auch in der Auswahl enthalten sein © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

36 Aufbau Mediationsschicht  Anfrageverarbeitung
Anfrageaufteilung und – optimierung: Aufteilung nach Datenquelle und Semantik der Anfrage Analyse der Bedeutung der Attribute, Methoden der Anfrage, und deren Verhältnis zu den DQ Bei mehreren Möglichkeiten der Teilung Mögliche Optimierung durch Zuordnung der Teilqueries auf performante Quellen Vorraussetzung: Kenntnis der zugrundeliegenden Daten © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

37 Aufbau Mediationsschicht  Anfrageverarbeitung
Anfrageausführung und Ergebnisintegration: Auslesen der relevanten Daten aus den entsprechenden Quellen Durchführung von Korrelation (Joins); Selektion; Methodenaufrufen (in oo-Modellen); Abstraktion; Aggregation der Daten schwierigste Aufgabe: Auflösung semantischer Differenzen (wie bei FDBMS: Schemaintegration) Aufdeckung von Konflikten Untersuchung von Attributen oder Instanzen nach semantische Ähnlichkeiten und Redundanzen bei strukturellen Unterschieden Schematransformation aus den gewonnen Informationen: Erstellung von Integrationsregeln für die Transformation und Verarbeitung der Ergebnisse diese Regeln zur Durchführung der Anfrageausführung verwendet denkbar: manuell hinzugefügte Integrationsregeln, um durch Transformation auf Daten neue Informationen und Wissen zu gewinnen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

38 I³-Referenzarchitur I³ = Intelligente Integration von Information
enthält grundlegende, umfassende Klassifikation der notwendigen Funktionen für ein mediatorbasiertes Informationssystem nur abstrakte Darstellungen, keine implementierungsspezifischen Details Definition der Referenzarchitektur: beschreibt Aspekte der Verbindung der funktionalen Grundelemente und ihrer Schnittstellen in einem System. macht deutlich wo Protokolle definiert und Gruppierungen von Funktionen durchgeführt werden müssen schafft die theoretische Grundlage für wiederverwendbare Komponenten © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

39 I³-Referenzarchitektur
Probleme, die gelöst werden müssen: Autonomie der Informationsquellen Heterogenität der Informationsquellen Größe und Verteiltheit der Systeme Evolution der Informationsquellen Als Modell der Dienste bezeichnet Komponenten der I³-RA entsprechen sog. I³-Services Dienste werden in 4 Kategorien gruppiert © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

40 Semantic Integration& Transformation Services Functional Extensions
Coordination & Management Services Dynamic Tool Selection Dynamic Configuraiton Construction Static Configuration Construction Ad Hoc Configuration Construction Resource Discovery Configuration Process Primitives Template Interpretation and Execution Semantic Integration& Transformation Services Schema Integration Information Integration Process Integration Support Physical Integration Support Component Programming Functional Extensions Active Inference Multistate Temporal Object-Orientation Persistence Wrapping Communication Data Restructuring Behavioral Transformation I³-Referenzarchitektur © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

41 Coordination & Management Services
Dynamic Tool Selection Dynamic Configuraiton Construction Static Configuration Construction Ad Hoc Configuration Construction Resource Discovery Configuration Process Primitives Template Interpretation and Execution Unterstützt die Erstellung von I³-Konfigurationen für eine spezifische Aufgabe Lokalisierung geeigneter Komponenten Finden von Informationsquellen, die für die Anfrage nützlich sind Starten, Steuern, Scheduling dieser Komponenten dynamische Aspekte des MBIS angesiedelt (Brokering, Facilitation) © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

42 Semantic Integration & Transformation Service
Transformation Services Schema Integration Information Integration Process Integration Support Physical Integration Support Component Programming Unterstützung der notwendigen semantischen Manipulation der Information zur Lösung einer Aufgabe Erlauben Integration mehrerer heterogener Datenquellen in einer „Integrationsbasis“ primäre Dienste: Unterstützung der Schema- und Datenintegration hier: vollständige Durchführung der Integration durch Mediatoren und Übergabe der integrierten Ergebnisse an Coordination & Management Services © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

43 Functional Extensions
Active Inference Multistate Temporal Object-Orientation Persistence Verstärkung der semantischen Ausdrucksfähigkeit von Informationsquellen Erweiterung der Funktionalität der anderen Dienste © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

44 Basis der Dienste der I³-Referenzarchitektur
Wrapping Wrapping Communication Data Restructuring Behavioral Transformation Basis der Dienste der I³-Referenzarchitektur Transformation von Kommunikationsschnittstellen, Datenstrukturen und Programmlogiken Auflösung technischer Inkompatibilitäten Schaffung einer Menge von wiederverwendbaren gekapselten standardisierten Infoquellen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

45 Merkmale von MBIS MBIS lassen sich nach folgenden Kriterien charakterisieren: Enge vs lose Kopplung Lesen oder Schreiben Datenmodell des Mediators Anfragesprachen in Wrappern Sammeln, Integrieren, Verweisen, Abstrahieren Virtuelle Anfrageverarbeitung vs Materialisierung Bottom-Up vs Top-Down Klassische Kriterien zur Klassifizierung föderierter IS © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

46 Merkmale von MBIS Enge vs lose Kopplung:
abhängig von der Existenz eines integrierten Schemas Enge Kopplung: alle Komponentenschema in einem homogenen Schema zusammengefasst kann durch Schemaintegration ad-hoc erfolgen Benutzer stellen Anfragen an dieses Schema und das System muss diese in Teilanfragen an die Komponenten zerlegen Lose Kopplung: kein integriertes Schema vorhanden Benutzer müssen die Integration durchführen Benutzeranfragen richten sich direkt an Relationen oder Klassen der Komponenten Grauzonen bei: losen Systemen, die Views gestattet, die allen Benutzern zur Verfügung stehen  eine Menge solcher Views entspricht letztendlich einem integrierten Schema © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

47 Merkmale von MBIS Lesen oder Schreiben:
oft auf lesenden Zugriff auf die Daten beschränkt schreibender Zugriff birgt viele Probleme: Autonomie-Einschränkung der einzelnen Komponenten Verteilte TA-Verwaltung ist konzeptionell schwierig und verlangt adäquate Fähigkeiten in den Komponenten eng integrierte Systeme stehen oft vor dem „update through views“-Problem © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

48 Merkmale von MBIS Datenmodell des Mediators:
jeder eng-integrierender Vermittler muss auf einem bestimmten Datenmodell aufbauen, in dem das integrierte Schema definiert ist Fragen: Wie wird die Integration von Komponenten unterstützt, die ein anderes Datenmodell verwenden? Inwieweit lassen sich Schemata in verschiedenen Modellen verlustfrei und sinnvoll ineinander abbilden? © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

49 Merkmale von MBIS Anfragesprachen in den Wrappern:
Anfragebeschränkungen der einzelnen Datenquellen (z. Bsp. Erzeugung von HTML-Tabellen, auf die jedoch keine Bedingungen ausgeführt werden können) Welche Anfragebeschränkungen kann das System tolerieren?? Wie werden diese Einschränkungen kompensiert?? Quellen komplett spiegeln und Anfragen dann lokal vom Mediator ausführen  sehr aufwendig Wo werden die Kompensationen durchgeführt?? (Mediator, Wrapper, speziellen Komponenten) © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

50 Merkmale von MBIS Sammeln, Integrieren, Verweisen, Abstrahieren...
Unterscheidung der Mediatoren nach den Fähigkeiten im Umgang mit Daten trivialste Methode: pures Sammeln von allen Daten ohne jegliche Transformation Datenintegration durch : Erkennen gleicher Objekte, redundanter Daten, Unterstützung bei der Auflösung von Datenkonflikten andere Möglichkeit: Daten nur durch Verweise auf die Originaldaten zu „sammeln“ wichtige Eigenschaften von „idealen“ Mediatoren: Datenabstraktion, -aggregation Zusammenfassung nach strukturellen und semantischen Aspekten © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

51 Merkmale von MBIS Virtuelle Anfragebearbeitung vs Materialisierung:
in MBIS grundsätzlich virtuelle Strategie: nur kleine Mengen von Daten wirklich replizieren Ausnahmen: Replikation von Metadaten (Komponentenschema, Objektnamen) Mischarchitekturen bei denen die Anfragebearbeitung auf materialisierten Wege erfolgt: Sämtliche Information in eine Data Warehouse DB importiert Anfragen an die Quellen werden durch das Data Warehouse beantwortet Data Warehouse (DW) entspricht dem Mediator © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

52 Merkmale von MBIS Vorteil der Materialisierung:
geringere Komplexität der Anfragebearbeitung, da alle Daten in einer DB vorhanden und mit der hohen Funktionalität dieser auch beantwortbar keine neuen Technologien nötig, alles verfügbar Vorteil virtueller Anfragebearbeitung: gesicherte Aktualität der Daten Weniger Speicheraufwand und Performancebelastung (als bei DW), da nur angefragte Daten extrahiert werden View zur Gewinnung der Daten besser geeignet Nachteil virtueller Anfrageverarbeitung: hohe Komplexität der Anfragebearbeitung, die u. U. neue Technologien benötigt © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

53 Merkmale von MBIS Bottom-Up versus Top-Down:
Unterscheidung nach der Entwicklungsstrategie Top-Down: Beginn mit den Anforderungen an das MBIS erst Definition des globalen Schemas mit den allen relevanten Konzepten daraus: Bestimmung der bedeutsamen Komponenten und der Durchführung der logischen und semantischen Integration mit dem globalen Schema Bottom-Up: Beginn mit dem Ziel eine bestimmte Menge von Komponenten in einem Integrierten System zu verbinden Komponentenschemata sind der Ausgangspunkt evtl Ableitung eines globalen Schemas © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

54 Merkmale von MBIS Wahl der Entwicklungsstrategie besonders wichtig für die Evolutionsfähigkeit des Systems: Nachteile der Bottom-Up-Strategie: Schaffung relativ abgeschlossener, schlecht erweiterbarer Systeme schlechte Reaktionsfähigkeiten auf bestimmte Veränderungen wie: neue Komponenten, Anforderungen Nachteile der Top-Down-Entwicklung: Schwache Bindung von Komponenten an das System (z. Bsp: Integration von WWW-Quellen) „semantische Unterscheidungsfähigkeit“ schwacher, da Komponenten nicht von vorneherein an der Entwicklung beteiligt sind © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

55 3. Beispiel TSIMMS The Stanford-IBM Manager of Multiple Information Sources Komponenten OEM Anfragesprachen MSI Mediatoren Wrapper © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

56 Architektur MSI Nutzeranfrage MSL/LOREL OEM MSL Mediator Wrapper
© 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

57 OEM Object-Exchange Model objektorientiertes Datenmodell
OEM Object-Exchange Model objektorientiertes Datenmodell Daten selbstbeschreibend parsen ohne Referenz auf ein externes Schema möglich flexible Datenorganisation Strukturen Unterschiede in Ausdrücken, Art der Informationen © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

58 OEM-Objekte Komponenten
Ausdruck, der die Herkunft des Objektes beschreibt transient, lokal zu einer Anfrage z.B. Pointer auf ein Objekt, dass eine Anfrage beantwortet Bezeichner der Objektklasse Typ des Wertes einzelner Wert oder Ansammlung von Werten Objekt-ID: Bezeichnung Typ Wert © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

59 OEM-Objekte ermöglicht Aufbau von Strukturen library set book set
author string Date title string An introduction... © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg

60 LOREL Lightweight Object REpository Language
LOREL Lightweight Object REpository Language OQL-basierte Benutzeranfragesprache in TSIMMS basiert auf OEM-Objektstrukturen Pfadausdrücke ist Folge von hierarchisch sortierten labels, verbunden durch Punkte OQL-ähnliche Anfragen select library.book.title from library where library.book.author = „Date“ © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

61 MSL Mediator Specification Language DATALOG-Variante
MSL Mediator Specification Language DATALOG-Variante objekt-orientierte, logische Anfragesprache und Sprache zur Spezifikation von Mediatoren Anfrage in MSL besteht aus Regeln: Kopf (beschreibt das Objekt, das von dem Mediator zur Verfügung gestellt werden soll) gefolgt von :- und Körper (Bedingungen, die vom Quellobjekt erfüllt sein müssen) <booktitle X> :- <library { <book {<title X> <author „Date“>}> © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

62 MSI Benutzeranfrage in MSL oder LOREL an den MSI (Mediator Specification Interpreter) der MSI verarbeitet die Anfrage Einzelanfragen werden an die Wrapper der einzelnen Datenquellen oder an weitere Mediatoren gestellt © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

63 Anfragebebearbeitung im MSI
Anfragebebearbeitung im MSI View Expander And Algebraic Optimizer erstellt einen logischen Plan für die Anfragebearbeitung welche Quellen sollen befragt werden dieser logischen Plan wird dem Cost Based Optimizer zur Erstellung eines physischen Plans übergeben legt fest, in welcher die Quellen befragt werden ausführen des physischen Plans von der Datamerge Engine Zusammenführen der Informationen zu global gültigen OEM-Objekten © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

64 Wrapper/WSL Wrapper entscheidet zuerst, ob eine darunterliegende Quelle die Anfrage beantworten kann wenn ja, konvertieren der Anfrage in ein von der Quelle verständliches Format und konvertieren der Antwort in OEM-Objekte wenn nicht, feststellen, ob durch lokales Filtern (z.B. Selektion) in Teilanfragen die Anfrage beantwortet werden kann Anfragen mittels WSL (Wrapper Specificaion Language) © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

65 Zusammenfassung Ein mediatorbasiertes Informationssystem ermöglicht einen einheitlichen Zugriff auf eine Menge weitgehend autonomer Informationssysteme. Aufgrund der Autonomie der Quellen ist es verteilt und heterogen. Wichtige Bestandteile sind Mediatoren und Wrapper. Mediatoren erreichen eine enge Kopplung und damit die logische Integration der Datenbestände. Wrapper kapseln die Datenquellen und überbrücken Datenmodellheterogenitäten. © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg