Datenintegration

1. Datenintegration Peter Brezany Institut für Softwarewissenschaften Universität Wien

2. 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 Inhalt

3. 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 Motivation

4. 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 Anforderungen I

5. Hardwareunabhängigkeit Betriebssystemunabhängigkeit Netzwerkunabhängigkeit Auch unterschiedliche Netztechnologien möglich Datenbanksystemunabhängigkeit Anforderungen II

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

7. 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 Probleme II

8. Mögliche DBS

9. Virtuell vs. Materiell

10. 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 Begriffsdefinitionen

11. 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

12. 4 Ebenen Schema Architektur Verteiltes Datenbanksytem

13. 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 Kopplung

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ür skaliert 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.

15. Integrationsstrategien II (Source: Busse et al. TU Berlin) GAV LAV Angeln deuten View Definitionen an!

16. 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!!! Kriterien für Integrationsmethoden

17. 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 Mediatoren

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)

19. 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 Case Studie - Infobedarf

20. 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) Case Studie - Infobedarf

21. 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,.... Case Studie - Komponenten

22. Query: SELECT p_name FROM patient WHERE id=10 Case Studie - Anfrage Standard to optimized

23. 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,... Mögl. Probleme bei Mediatoren

24. Datenintegration zur Entscheidungsfindung immer wichtiger Hohe Anforderungen (Autonomie!) Vielzahl von Problemen (Evolution, Semantik) FDBS vs VDBS vs Mediator/Wrapper Zusammenfassung

25. 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 Weiterführende Informationen