1 Automatische Erstellung von Integrationslösungen Markus Eppert Seminar Mastering the Information Explosion – Information Integration and Information Quality

2 Übersicht Motivation AutoMed SEMEX Fazit

3 Motivation Heterogene Datenquellen schon innerhalb einzelner Unternehmen Weltweit wachsende Datenmengen Ziel Datenintegration: Einheitliches Schema auf Daten aus verschiedenen Datenquellen Manuelle Datenintegration sehr kostspielig Erstellung automatischer Integrationslösungen erwünscht

4 AutoMed Domänenunabhängiger Ansatz zur automatischen Datenintegration Zugrundeliegendes Konzept: Hypergraph Data Model Both-as-View-Ansatz als Integrationskonzept Optimierung und Validierung der entstandenen Transformationspfade durch die Transformation Manipulation Language

5 Hypergraph Data Model Beschrifteter, gerichteter Graph HDM-Schema: Tripel = Kanten können Knoten und andere Kanten verbinden Knoten haben einen eindeutigen Namen Namen für Kanten sind optional Anschaulich: Knoten = einzelne Klassen bzw. Konstrukte Kanten = Referenzen Durch Constraints können Bedingungen definiert werden

6 Primitive Transformationen renameNode(oldName, newName) renameEdge((oldName, c1,..., cm), newName) addNode(name, q) delNode(name, q) addEdge((name, c1,..., cm), q) delEdge((name, c1,..., cm), q) addConstraint(c) delConstraint(c) Umkehrtransformationen für jede Transformation vorhanden

7 Anwendungsbeispiel (I) Schema 1 N = {Person,Mathematiker, Informatiker} E = C = {Mathematiker Person, Informatiker Person} Schema 2 N = {Person,Fachgebiet} E = {(null,Person,Fachgebiet)} C = Person MathematikerInformatiker Fachgebiet Person

8 Anwendungsbeispiel (II) Person MathematikerInformatiker 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker

8 Anwendungsbeispiel (II) Person MathematikerInformatiker 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker

8 Anwendungsbeispiel (II) Person MathematikerInformatiker 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) 4. delConstraint(Mathematiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker

8 Anwendungsbeispiel (II) Person MathematikerInformatiker 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) 4. delConstraint(Mathematiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker

8 Anwendungsbeispiel (II) Person Mathematiker 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) 4. delConstraint(Mathematiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker 5. delNode(Informatiker, {x | (x, Info) (null, Person, Fachgebiet)}) Informatiker

8 Anwendungsbeispiel (II) Person Mathematiker 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) 4. delConstraint(Mathematiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker 5. delNode(Informatiker, {x | (x, Info) (null, Person, Fachgebiet)})

8 Anwendungsbeispiel (II) Person Mathematiker 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) 4. delConstraint(Mathematiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker 5. delNode(Informatiker, {x | (x, Info) (null, Person, Fachgebiet)}) 6. delNode(Mathematiker, {x | (x, Mathe) (null, Person, Fachgebiet)})

8 Anwendungsbeispiel (II) Person 1. addNode(Fachgebiet, {Mathe, Info}) 2. addEdge(null, Person, Fachgebiet, {(x, Mathe) | x Mathematiker} {(x, Info) | x Informatiker}) 3. delConstraint(Informatiker Person) 4. delConstraint(Mathematiker Person) Fachgebiet MatheInfo = Mathematiker = Informatiker 5. delNode(Informatiker, {x | (x, Info) (null, Person, Fachgebiet)}) 6. delNode(Mathematiker, {x | (x, Mathe) (null, Person, Fachgebiet)})

9 Both-as-View in AutoMed Übertragung der LS in ÄS durch primitive Transformationen ÄS sind syntaktisch äquivalent, Vereinigung möglich id-Transformation zur Sicherstellung der Äquivalenz Auswahl eines beliebigen ÄS, über welches das GS erstellt wird Instanzen aus anderen ÄS können durch die Vereinigung ergänzt werden

10 BaV vs. LaV und GaV Transformationspfade im AutoMed Metadata Repository gespeichert Queries ermöglichen Bilden von GaV- und LaV-Sichten BaV mächtiger

11 Transformation Manipulation Language (TML) Ziel: Optimierung und Validierung der entstandenen Transformationspfade –Entfernen komplementärer Transformationen –Zusammenfassen mehrerer Transformationen Jede Transformation wird mit Vor- und Nachbedingungen ergänzt

12 Komplementäre Transformationen Beispiel: t(i): addNode(Komplementär, q) t(i+1): delNode(Komplementär, q) Transformationen können entfernt werden, ohne dass sich das resultierende Schema ändert Regeln zur Entdeckung komplementärer Transformationen werden aus den Vor- und Nachbedingungen abgeleitet Problem: Vergleich nur zwischen benachbarten Transformationen möglich

13 Vertauschen vom Transformationsschritt t(i) mit t(i+1) Wichtig: Bei einem Tausch darf t(i+1) nicht von Konstrukten abhängen, die erst durch t(i) eingeführt wurden Beispiel:t(i): renameNode(Alt, KeinTausch) t(i+1): delNode(KeinTausch, q) kein Tausch möglich, da t(i+1) ein Konstrukt löschen würde, das (noch) nicht existiert Genaue Regeln zum Tauschen werden ebenfalls durch die Vor- und Nachbedingungen festgelegt

14 Partiell komplementäre Transformationen Partiell komplementär: Zwei Transformationen können zu einer einzigen Transformation zusammengefasst werden Beispiel:t(i): addNode(A, q) t(i+1): renameNode(A, B) Vereinfacht zu addNode(B, q) Vereinfachungen wiederum aus den Vor- und Nachbedinungen ableitbar

15 SEMEX Abkürzung für SEMantic EXplorer spezielle Anwendungsdomäne: Personal Information Management (PIM) Extrahierung von Zusammenhängen verschiedener Daten aus unterschiedlichen Anwendungen Verwenden von Attributen, Schlüsseln und Fremdschlüsseln ähnlich zu SQL

16 Der Aufbau von SEMEX

17 Assoziationen und Instanzen Verschiedene Möglichkeiten zur Extrahierung von Daten: Simple/Extracted: –Direkte Extrahierung von Daten durch Importer aus bekannten Formaten (z.B. -Adressbuch) External: –Extrahierung von Daten durch externe Dienste –Ermittlung von Assoziationen über ein Web-Interface Defined: –Definition von Objekten und Assoziationen aus einfacheren Objekten (z.B. Co-Autor als Assoziation zwischen Autoren und Veröffentlichungen)

18 Vorgehen bei Datenintegration 1. Schritt: Schema Matching –Übereinstimmungen von Attributen aus der externen Quelle mit denen des Domänenmodells finden 2. Schritt: Finden verwandter Attribute –Suche nach Klassen aus dem Domänenmodell zur möglichen Anreicherung mit zu integrierenden Attributen –Output: mögliche Integrationsklassen für die Attribute 3. Schritt: Zuordnung der Attribute –Vorschläge zur Zuordnung der Attribute zu bestimmten Klassen –Output: Vorgeschlagene Mappings, können durch den Benutzer modifiziert werden

19 Reference Reconciliation (I) Ziel: Datensätze, die dasselbe Objekt repräsentieren –identifizieren –zusammenführen Frühere Ansätze: –Abgleichung von Objekten einer einzelnen Tabelle –Alle Objekte enthalten dieselbe Menge an Attributen –Attribute haben jeweils nur einen einzigen Wert Im PIM nicht anwendbar, da Heterogene Datenquellen Attribute mit mehreren Werten möglich (z.B. -Adressen)

20 Reference Reconciliation (II) Reference Reconciliation in SEMEX: 1. Schritt: –Angleichung basierend auf gleichen Werten in Schlüsselattributen –Merging bei einem gemeinsamen Wert in einem Schlüssel 2. Schritt: –Angleichung basierend auf der Ähnlichkeit von Strings (Edit Distance) –Einsatz domänenabhängiger Heuristiken (z.B. Aufbau von - Adressen)

21 Reference Reconciliation (III) 3. Schritt: Anwendung von globalem Wissen –Suchmaschinen-Analyse: Suchmaschinen-Analysierer gibt Texte von zwei Referenzen in Google ein und vergleicht die Top-Treffer Referenzen zu derselben Person haben oft ähnliche Top-Treffer –Time-series comparison: Auswahl von Referenzpaaren, die als ähnlich eingestuft, aber nicht zusammengefasst wurden Sammeln von Zeitmarken aus den s, die mit den Referenzen in Verbindung gebracht wurden Merging bei geringer oder gar keiner Überschneidung der Zeitmarken

22 Reference Reconciliation (IV) Reference Reconciliation über mehrere Klassen: paperpa1= (Conflict Detection Tradeoffs for Replicated Data, , {pe1, pe2}, c1) pa2=(Conflict detection tradeoffs for replicated data, , {pe3, pe4}, c2) personpe1=(M.J. Carey, null, i1) pe2=(M. Livny, null, i1) pe3=(Mike Carey, i2) pe4=(Miron Livny, i2) insti1 =(Univ. of Wisconsin Madison, null) i2 =(WISC, 1210 W. Dayton St., Madison) confc1 =(ACM Transactions on Database Systems, 1991) c2 =(TODS, 1991)

23 Reference Reconciliation (V) 1. Phase: Abgleichung der Objekte einer einzelnen Klasse –Im Beispiel: Merging von pa1 und pa2 wegen starker Ähnlichkeit 2. Phase: Erstellen eines Abhängigkeitsgraphen –Knoten sind gemischte Paare und Kandidatenpaare –Jeder Knoten erhält ein Ähnlichkeitsmaß zwischen 0 und 1 –Kante impliziert Berücksichtigung der verbundenen Knoten bei Neuberechnung der Ähnlichkeit –Im Beispiel:

24 Data Repository Datenbank, in welche die neu gewonnenen Instanzen und Assoziationen gespeichert werden Verwendet das Resource Description Framework RDF, implementiert mit dem Semantic Web Framework Jena Aktualisierung der Daten –regelmäßiges Absuchen des Desktops –Extrahierung von Instanzen und Assoziationen –inkrementelle Erweiterung der Datenbank

25 Domänenmodell Objektorientiertes Metamodell mit Klassen und Assoziationen Unterstützt z.Z. keine Vererbung Individuelle Anpassung des Standard-Domänenmodells durch Verfeinerung oder Modifizierung bereits vorhandener Klassen möglich

26 On-the-fly-Integration mit SEMEX Unterstützung des Benutzers beim Datenimport durch folgende Werkzeuge: Datenvorbereitung und Wrapping: Transformiert die Daten in eine strukturierte Form, mit der SEMEX weiterarbeiten kann Schema Matching und Mapping: Ermöglicht die Beschreibung der semantischen Zusammenhänge zwischen Datenquelle und Domänenmodell Datenimport: Importiert Daten von der externen Datenquelle nach dem Schema Matching Reference Reconciliation Datenanalyse und Zusammenfassung (optional): Sucht Muster aus den importierten Daten, die für den Benutzer von Interesse sein könnten

27 Queries in SEMEX Suche mit Schlüsselwörtern: –Anzeige aller Objekte, die mit diesem Wort in Beziehung stehen –Kann Mengen von Objekten aus verschiedenen Klassen liefern –Objekte bereits in verschiedene Klassen eingeteilt Auswahl einer Klasse aus dem Domänenmodell: –Eingabe bestimmter Werte für einige Attribute der ausgewählten Klasse Selektion Assoziations-Queries: –Durchsuchen der Daten durch den Benutzer über Assoziationen zwischen Objekten –Auswahl eines Objekts alle Objekte erreichbar, die mit diesem in Verbindung stehen

28 Fazit AutoMed als domänenunabhängiger Ansatz SEMEX als Ansatz in der PIM-Domäne Hoher Grad an Unterstützung durch den Benutzer nötig –Mapping weitestgehend manuell –Matching teilweise automatisiert Vielversprechende Ansätze, aber noch viele zu lösende Probleme –Hauptschwierigkeit: Semantische Heterogenität –Geringer Automatisierungsgrad Es ist noch ein weiter Weg zu anwendbaren automatischen Integrationslösungen

29 Fragen?