070430-db-integr
Werbung
Integration von föderierten Datenbanken Peter Brezany Institut für Scientific Computing Universität Wien P.Brezany Institute of Scientific Computing – University of Vienna 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 P.Brezany Institute of Scientific Computing – University of Vienna 2 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) P.Brezany Institute of Scientific Computing – University of Vienna 3 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: • Evolution • E.g. Attribute in verschiedenen Tabellen – Änderungen im Laufe der „Lebenszeit“ der Integration erforderlich P.Brezany Institute of Scientific Computing – University of Vienna 4 Föderierte Datenbanken 5 Schichten Referenz-Architecture: • • • • • P.Brezany 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 Vienna 5 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!!! P.Brezany Institute of Scientific Computing – University of Vienna 6 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 P.Brezany Institute of Scientific Computing – University of Vienna 7 Architecture of a Mediation-Based Information System P.Brezany Institute of Scientific Computing – University of Vienna 8 Mediators – centralisiert vs. verteilt Centralized Model P.Brezany Distributed Model Institute of Scientific Computing – University of Vienna 9 A Prototypical Architecture of a Data Integration System P.Brezany Institute of Scientific Computing – University of Vienna 10 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) P.Brezany Institute of Scientific Computing – University of Vienna 11 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 P.Brezany Institute of Scientific Computing – University of Vienna 12 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) P.Brezany Institute of Scientific Computing – University of Vienna 13 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,.... P.Brezany Institute of Scientific Computing – University of Vienna 14 Mediation Schema P.Brezany Institute of Scientific Computing – University of Vienna 15 Grid Data Mediation Service Architecture P.Brezany Institute of Scientific Computing – University of Vienna 16 Case Studie - Anfrage • Query: – SELECT p_name FROM patient WHERE id=10 Standard to optimized P.Brezany Institute of Scientific Computing – University of Vienna 17 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,... P.Brezany Institute of Scientific Computing – University of Vienna 18 Adaptive Semantic Data Integr. on the Grid P.Brezany Institute of Scientific Computing – University of Vienna 19 Zusammenfassung • Datenintegration zur Entscheidungsfindung immer wichtiger • Hohe Anforderungen (Autonomie!) • Vielzahl von Problemen (Evolution, Semantik) • FDBS vs VDBS vs Mediator/Wrapper P.Brezany Institute of Scientific Computing – University of Vienna 20 Weiterführende Informationen • IBM Systems Journal Vol. 41 zum Thema „Information Integration“ http://www.research.ibm.com/journal/sj41-4.html • Vorlesung der Uni Freiburg zum Thema „Heterogene Datenbanksysteme” http://www.informatik.uni-freiburg.de/~dbis/lehre/isss99/integra.ps P.Brezany Institute of Scientific Computing – University of Vienna 21
