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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OEM Object-Exchange Model objektorientiertes Datenmodell 06.11.2018 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

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

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

LOREL Lightweight Object REpository Language 06.11.2018 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

MSL Mediator Specification Language DATALOG-Variante 06.11.2018 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“>}> }>@source1 © 2001 David Kaiser, Thomas Hoffmann, Christina Reuter MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

06.11.2018 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

Anfragebebearbeitung im MSI 06.11.2018 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

06.11.2018 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

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