070430-db-integr

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