Data Mining Engineering

Werbung
Datenintegration
Peter Brezany
Institut für Softwarewissenschaften
Universität Wien
P.Brezany
Institute for Software Science – University of Vienna
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
P.Brezany
Institute for Software Science – University of Vienna
2
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 for Software Science – University of Vienna
3
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
P.Brezany
Institute for Software Science – University of Vienna
4
Anforderungen II
• Hardwareunabhängigkeit
• Betriebssystemunabhängigkeit
• Netzwerkunabhängigkeit
– Auch unterschiedliche Netztechnologien möglich
• Datenbanksystemunabhängigkeit
P.Brezany
Institute for Software Science – University of Vienna
5
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
P.Brezany
Institute for Software Science – University of Vienna
6
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 for Software Science – University of Vienna
7
Mögliche DBS
P.Brezany
Institute for Software Science – University of Vienna
8
Virtuell vs. Materiell
P.Brezany
Institute for Software Science – University of Vienna
9
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
P.Brezany
Institute for Software Science – University of Vienna
10
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 for Software Science – University of Vienna
11
Verteiltes Datenbanksytem
4 Ebenen Schema Architektur
P.Brezany
Institute for Software Science – University of Vienna
12
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
P.Brezany
Institute for Software Science – University of Vienna
13
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.
P.Brezany
Institute for Software Science – University of Vienna
14
Integrationsstrategien II
GAV
(Source: Busse et al. TU Berlin)
LAV
Angeln deuten View Definitionen an!
P.Brezany
Institute for Software Science – University of Vienna
15
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 for Software Science – University of Vienna
16
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 for Software Science – University of Vienna
17
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 for Software Science – University of Vienna
18
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 for Software Science – University of Vienna
19
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 for Software Science – University of Vienna
20
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 for Software Science – University of Vienna
21
Case Studie - Anfrage
• Query:
– SELECT p_name FROM patient WHERE id=10
Standard
to
optimized
P.Brezany
Institute for Software Science – University of Vienna
22
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 for Software Science – University of Vienna
23
Zusammenfassung
• Datenintegration zur Entscheidungsfindung immer
wichtiger
• Hohe Anforderungen (Autonomie!)
• Vielzahl von Problemen (Evolution, Semantik)
• FDBS vs VDBS vs Mediator/Wrapper
P.Brezany
Institute for Software Science – University of Vienna
24
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 for Software Science – University of Vienna
25
Herunterladen