institute for software science – university of viennap.brezany datenintegration peter brezany...
TRANSCRIPT
Institute for Software Science – University of Vienna
P.Brezany
DatenintegrationDatenintegration
Peter Brezany Institut für Softwarewissenschaften
Universität Wien
Institute for Software Science – University of Vienna
P.Brezany 2
Inhalt
• Motivation• Anforderung an verteilte Datenhaltung• Probleme bei Datenintegration
– Heterogenität– Verteilung– Autonomie– Evolution
• Modelle– Verteilte Datenbanken– Föderierte Datenbanken
• Integrationsansätze• Case Studie: Mediator/Wrapper Ansatz
Institute for Software Science – University of Vienna
P.Brezany 3
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 for Software Science – University of Vienna
P.Brezany 4
Anforderungen I
• Verteilungstransparenz:– Stellt sich Benutzer wie ein zentrales DBMS dar
• Lokale Autonomie– Einzelne Knoten sollen ein Max. an Kontrolle über die auf ihnen
gespeicherten Daten behalten• Hohe Verfügbarkeit• Unabhängigkeit von zentralen Systemfunktionen• Ortstransparenz• Fragmentierungstransparenz• Replikationstransparenz• Verteilte Anfragenbearbeitung
– Durch Optimierer festgelegt• Verteilte Transaktionsverwaltung
Institute for Software Science – University of Vienna
P.Brezany 5
Anforderungen II
• Hardwareunabhängigkeit• Betriebssystemunabhängigkeit• Netzwerkunabhängigkeit
– Auch unterschiedliche Netztechnologien möglich• Datenbanksystemunabhängigkeit
Institute for Software Science – University of Vienna
P.Brezany 6
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
Institute for Software Science – University of Vienna
P.Brezany 7
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 for Software Science – University of Vienna
P.Brezany 8
Mögliche DBS
Institute for Software Science – University of Vienna
P.Brezany 9
Virtuell vs. Materiell
Institute for Software Science – University of Vienna
P.Brezany 10
Begriffsdefinitionen
• Föderiertes Datenbanksystem:– viele Datenbanken tragen Daten und Ressourcen zu einer
Multidatenbank-Föderation bei, doch hat jeder Teilnehmer volle lokale Autonomie
• Verteiltes Datenbanksystem:– ist eine Datenbank, die absichtlich über gewisse Zahl von
Orten verteilt wurde. Eine VDB wird als Ganzes entworfen, und ist mit ziemlich zentralisierter Steuerung assoziiert
Institute for Software Science – University of Vienna
P.Brezany 11
Föderierte Datenbanken5 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 for Software Science – University of Vienna
P.Brezany 12
Verteiltes Datenbanksytem
4 Ebenen Schema Architektur
Institute for Software Science – University of Vienna
P.Brezany 13
Kopplung
• Enge:– Globales Schema: einfach zu verwenden– Von Administrator erstellt– Wichtig bei vielen Datenquellen!
• lose:– Kein globales Schema– gemeinsame Abfragesprache für die Komponenten– Benutzer selbst für auflösung von Heterogenitäten
verantwortlich» müssen sehr erfahren sein
Institute for Software Science – University of Vienna
P.Brezany 14
Integrationsstrategien I
• Top-Down (LAV):– Vorgabe des globalen Schemas– Abbildung der lokalen Schemata auf das globale– Vorteil wenn sie Quellen schnell ändern, hinzukommen/verschwinden
• Buttom-Up (GAV):– Globales Schema wird als Sicht über lokalen Schemata definiert– Vorteil einer engeren Integration
In GAV Query-Reformulation ist sehr einfach (Rule Unfolding) dafürskaliert es nicht so gut im Bezug auf die Anzahl der Datenquellen.In LAV muss das System herausfinden wie Daten zusammengefügt werden müssen um Anfrage zu beantworten (sehr complex) und es können besser Einschränkungen der Datenquellen spezifiziert
werden.
Institute for Software Science – University of Vienna
P.Brezany 15
Integrationsstrategien II
GAV LAV
Angeln deuten View Definitionen an!
(Source: Busse et al. TU Berlin)
Institute for Software Science – University of Vienna
P.Brezany 16
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 for Software Science – University of Vienna
P.Brezany 17
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 for Software Science – University of Vienna
P.Brezany 18
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 for Software Science – University of Vienna
P.Brezany 19
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 for Software Science – University of Vienna
P.Brezany 20
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 for Software Science – University of Vienna
P.Brezany 21
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 for Software Science – University of Vienna
P.Brezany 22
Case Studie - Anfrage
• Query:– SELECT p_name FROM patient WHERE id=10
to
Standard
optimized
Institute for Software Science – University of Vienna
P.Brezany 23
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 for Software Science – University of Vienna
P.Brezany 24
Zusammenfassung
• Datenintegration zur Entscheidungsfindung immer wichtiger
• Hohe Anforderungen (Autonomie!)
• Vielzahl von Problemen (Evolution, Semantik)
• FDBS vs VDBS vs Mediator/Wrapper
Institute for Software Science – University of Vienna
P.Brezany 25
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