Integration von fderierten Datenbanken Peter Brezany Institut fr

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: • 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 P. Brezany 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. XMLWeb. Row. Set) 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 My. SQL: » Schema: patient (p_id, p_fc) » Baut SQL Anfrage aus Mediator Anfrage zusammen » Hat schon richtiges Ergebnissformat, nämlich Web. Row. Set – 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/sj 41 -4. html • Vorlesung der Uni Freiburg zum Thema „Heterogene Datenbanksysteme” http: //www. informatik. uni-freiburg. de/~dbis/lehre/isss 99/integra. ps P. Brezany Institute of Scientific Computing – University of Vienna 21