Institute of Scientific Computing – University of ViennaP.Brezany Integration von föderierten Datenbanken Peter Brezany Institut für Scientific Computing Universität Wien

Institute of Scientific Computing – University of ViennaP.Brezany 2 Motivation 2 widersprüchliche Ziele: –Verteilung/Dezentralisation »Insbesondere bei Neuentwicklungen (Lastverteilung, Erhöhung der Ausfallssicherheit,...) –Integration »Bei bestehenden Systemen will man verteilt gespeicherte und unabhängig verwaltete Daten (die aber inhaltlich zusammengehören) wieder logisch zusammenführen Anwendungsbeispiele: –Geizhals: Produktdatenbanken von verschiedenen Händler ansprechen –Biomedizin: Zu Begriff Bilder, Übersetzungen,... verfügbar machen Für beide Ziele gilt: –Techn. Vorraussetzung (Vernetzung heterogener Rechner) gegeben –Entfernter Zugriff auf Daten in der Regel effizient möglich

Institute of Scientific Computing – University of ViennaP.Brezany 3 Probleme I Autonomie –Design: Datenquellen Manager entscheidet was und wie gespeichert –Kommunikation: wie und wann auf Anfrage geantwortet wird –Ausführung: lokale Operationen ohne Einwirkung von externen ausführbar –Verbindung: ob und wieviel von Funktionalität/Resourcen zur Verfügung gestellt wird Verteilung (hybrid)

Institute of Scientific Computing – University of ViennaP.Brezany 4 Probleme II Heterogenität –Syntaktisch »Technisch: OS, Platform,... »Schnittstelle: Abfragesprache,... –Datenmodel »Relational, OO,..... »Oft über Wrapper aufgelöst –Logisch »Semantisch: Gleiche Namen für unterschiedliche Konzepte (Hynonyme) Unterschiedliche Namen für gleiche Konzepte (Synonyme) Attribut kann gleiche Bedeutung haben, aber unterschiedliche Einheit »Schematisch: Kodierung von Concepten mit unterschiedlichen Elementen des Datenmodels »Strukturell: E.g. Attribute in verschiedenen Tabellen Evolution –Änderungen im Laufe der Lebenszeit der Integration erforderlich

Institute of Scientific Computing – University of ViennaP.Brezany 5 Föderierte Datenbanken 5 Schichten Referenz-Architecture: Lokales Schema: ausgedrückt in lokaler DDL & Datenmodel Component Schema: in gemeinsames Datenmodel überführtes lokales Schema Export Schema: Teil des Component Schemas welches extern sichtbar ist Global Schema: Integration aller export. Schemas External Schema: Global Schema angepasst an spezielle User/Anwendungen

Institute of Scientific Computing – University of ViennaP.Brezany 6 Kriterien für Integrationsmethoden Vollständigkeit –Es darf keine in einem lokalen Schema enthaltene Information verloren gehen Korrektheit –Alle in dem integrierten Schema enthaltenen Informationen müssen in mindestens einem lokalen Schema semantisch äquivalent vorhanden sein »Nur konsistente Ergänzungen der bestehenden Schemata erlaubt Minimalität –Konzepte, die in mehreren lokalen Schemata modelliert sind, dürfen nur einmal im integrierten Schema repräsentiert sein Verständlichkeit –Integriertes Schema sollte leicht verständlich sein!!!

Institute of Scientific Computing – University of ViennaP.Brezany 7 Mediatoren Wiederhold 92 Wrapper: –Komponente die Datenquellen einheitlich zugreifbar macht (Interface) –Versteht Anfragen des Mediators –VT: neue Arten/Strukturen/Quellen einfach hinzufügbar Mediator: –Verwendet Wrapper und andere Mediatoren als Quellen –Hat föderiertes Schema, Aufgaben können aber weit über reine Datenintegration hinausgehen »Abstrahierung von Daten »Enthalten techn. und administratives Wissen um Informationen für Entscheidungsfindung zu liefern –Sollten leichtgewichtig, wiederverwendbar und flexible sein –Verteilung vorgesehen

Institute of Scientific Computing – University of ViennaP.Brezany 8 Architecture of a Mediation-Based Information System

Institute of Scientific Computing – University of ViennaP.Brezany 9 Mediators – centralisiert vs. verteilt Centralized Model Distributed Model

Institute of Scientific Computing – University of ViennaP.Brezany 10 A Prototypical Architecture of a Data Integration System

Institute of Scientific Computing – University of ViennaP.Brezany 11 Case Studie - Gegebenheiten Heterogenitäten: –Name in A ist Vorname Nachname (wie im Ziel Format) –Name in C über 2 Spalten verteilt => zusammenführen Verteilung: –3 Datenquellen (XML, relational, Datei mit bestimmten Format)

Institute of Scientific Computing – University of ViennaP.Brezany 12 Case Studie - Infobedarf Vorgangsweise via Top Down Approach: –Welche Daten sollen in welcher Form verfügbar sein »Tabelle: patient (p_id, p_name, p_adr, p_dob, p_fc) –Quellen beschreiben damit sie gewünschte Daten liefern können »SQL View Definitions, XML Dokumente,... mit eingebauter Funktionalität oder auch der Möglichkeit externe Funktionen zu verwenden –Zusätzliche Operatoren nötig um Daten zusammenzuführen

Institute of Scientific Computing – University of ViennaP.Brezany 13 Case Studie - Infobedarf Mediator: –Userschnittstelle –Schema für User –Kennt teilnehmende Wrapper und Operationen um Ergebnisse zusammenzuführen »R = (A JOIN B) UNION C –Mägl. Abfragesprache: SQL Wrapper: –Nicht direkt vom User angesprochen –Kennt sein eigenes Schema und Daten die er zur Verfügung stellt –Versteht Anfragen des Mediators »E.g. Anfrage besteht aus array mit gewünschten Spalten und Bedingungen an die Daten »Wie er sie auf tatsächliche Datenquelle anwendet »Für jeden Type von Datenquellen eigenen Wrapper –Gibt Ergebnisse in vordefinierter Form zurück (XML Dokument mit speziellem Schema, e.g. XMLWebRowSet)

Institute of Scientific Computing – University of ViennaP.Brezany 14 Case Studie - Komponenten Mediator: –User Schema: : patient (p_id, p_name, p_adr, p_dob, p_fc) –Zerlegt Anfrage in benötigte Spalten für jeden Wrapper + dazugehörige Bedingungen Wrapper: –Einen für XMLDB: »Schema: patient (p_id, p_name, p_adr, p_dob) »Setzt Anfragen in XPath um »Transformiert XML Ergebnisse in Standardformat –Einen für MySQL: »Schema: patient (p_id, p_fc) »Baut SQL Anfrage aus Mediator Anfrage zusammen »Hat schon richtiges Ergebnissformat, nämlich WebRowSet –Einen für CSV: »Schema: patient (p_id, p_name, p_adr, p_dob, p_fc) »Liest Zeile für Zeile und retuniert nur solche, die Bedingungen erfüllen –Gleicht Schwächen der Quellen aus, e.g. keine Abfragesprache, keine Sortierung,....

Institute of Scientific Computing – University of ViennaP.Brezany 15 Mediation Schema

Institute of Scientific Computing – University of ViennaP.Brezany 16 Grid Data Mediation Service - Architecture

Institute of Scientific Computing – University of ViennaP.Brezany 17 Case Studie - Anfrage Query: –SELECT p_name FROM patient WHERE id=10 to Standard optimized

Institute of Scientific Computing – University of ViennaP.Brezany 18 Mögl. Probleme bei Mediatoren Wer programmiert neu benötigte Wrapper? Offene gut dokumentierte Schnittstellen? –semiautomatisiert Wer generiert Beschreibungen für Wrapper bei Schemaänderungen? Welches einheitliche Austauschformat zw. Wrapper – Mediator verwendet? –OO (Amos II), relational, XML,...

Institute of Scientific Computing – University of ViennaP.Brezany 19 Adaptive Semantic Data Integr. on the Grid

Institute of Scientific Computing – University of ViennaP.Brezany 20 Zusammenfassung Datenintegration zur Entscheidungsfindung immer wichtiger Hohe Anforderungen (Autonomie!) Vielzahl von Problemen (Evolution, Semantik) FDBS vs VDBS vs Mediator/Wrapper

Institute of Scientific Computing – University of ViennaP.Brezany 21 Weiterführende Informationen IBM Systems Journal Vol. 41 zum Thema Information Integration Vorlesung der Uni Freiburg zum Thema Heterogene Datenbanksysteme ss99/integra.ps