Institute of Scientific Computing – University of Vienna

P.Brezany

Integration von föderierten Integration von föderierten DatenbankenDatenbanken

Peter Brezany

Institut für Scientific Computing

Universität Wien

Institute of Scientific Computing – University of Vienna

P.Brezany2

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 Vienna

P.Brezany3

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 Vienna

P.Brezany4

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 Vienna

P.Brezany5

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 Vienna

P.Brezany6

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 Vienna

P.Brezany7

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 Vienna

P.Brezany8

Architecture of a Mediation-Based Information System

Institute of Scientific Computing – University of Vienna

P.Brezany9

Mediators – centralisiert vs. verteilt

Centralized Model Distributed Model

Institute of Scientific Computing – University of Vienna

P.Brezany10

A Prototypical Architecture

of a Data Integration

System

Institute of Scientific Computing – University of Vienna

P.Brezany11

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 Vienna

P.Brezany12

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 Datenliefern können

» SQL View Definitions, XML Dokumente,...mit eingebauter Funktionalität oder auchder Möglichkeit externe Funktionen zu verwenden

– Zusätzliche Operatoren nötig um Datenzusammenzuführen

Institute of Scientific Computing – University of Vienna

P.Brezany13

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 Vienna

P.Brezany14

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 Vienna

P.Brezany15

Mediation Schema

Institute of Scientific Computing – University of Vienna

P.Brezany16

Grid Data Mediation Service - Architecture

Institute of Scientific Computing – University of Vienna

P.Brezany17

Case Studie - Anfrage

• Query:– SELECT p_name FROM patient WHERE id=10

to

Standard

optimized

Institute of Scientific Computing – University of Vienna

P.Brezany18

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 Vienna

P.Brezany19

Adaptive Semantic Data Integr. on the Grid

Institute of Scientific Computing – University of Vienna

P.Brezany20

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 Vienna

P.Brezany21

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/is-ss99/integra.ps