Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Verteilte Systeme und Informationssysteme Hausarbeit im Seminar: Informationsintegration Deklarative Datenreinigung mit AJAX Oliver Vietor [email protected] Studiengang Informatik Matr.-Nr. 6334524 Fachsemester 2 Betreuer: Dipl.-Inf. Fabian Panse Deklarative Datenreinigung mit AJAX III Inhaltsverzeichnis 1 Einleitung.................................................................................................................... 1 2 Datenreinigung ........................................................................................................... 2 3 4 5 2.1 Probleme ............................................................................................................. 2 2.2 Existierende Tools ............................................................................................... 3 2.3 Deklarative Datenreinigung ................................................................................ 4 AJAX ........................................................................................................................... 5 3.1 Benutzerinteraktion ............................................................................................. 5 3.2 Trennung von Logik und Implementation ........................................................... 5 Deklarative Sprache..................................................................................................... 7 4.1 Mapping.............................................................................................................. 7 4.2 View.................................................................................................................... 8 4.3 Matching ............................................................................................................. 9 4.4 Clustering...........................................................................................................10 4.5 Merging..............................................................................................................10 Fazit ...........................................................................................................................11 Literaturverzeichnis ..........................................................................................................12 Deklarative Datenreinigung mit AJAX 1 1 Einleitung Wenn versucht wird, unstrukturierte Daten aus mehreren verschiedenen Datenquellen zu einem einheitlichen Format zusammenzuführen, liegen diese einerseits meistens in vollkommen verschiedenen Formaten vor und andererseits stehen Teile dieser Daten miteinander im Widerspruch zueinander. Das Ziel von Datenreinigung ist es, Inkonsistenzen und Fehler in Datenbeständen zu finden und anschließend zu korrigieren bzw. zu beheben. Ein Tool, was die Reinigung von Daten ermöglicht, ist das von Galhardas et al. entwickelte AJAX. Es umfasst eine eigene Sprache, ein Ausführungsmodel sowie mehrere Algorithmen. Im Rahmen dieser Ausarbeitung wird AJAX allgemein vor gestellt und auf die dazugehörige Sprache eingegangen. Hauptquellen für diese Ausarbeitung sind das Paper „Declarative Data Cleaning: Language, Model, and Algorithms“ von Galhardas et al. [GFS+01] sowie die überarbeitete bzw. ergänzende Fassung aus dem Jahr 2006 von Galhardas [Gal06]. Leider ist die dazugehörige Projekthomepage [Gal+12] nur noch teilweise verfügbar. So zeigen die Verweise in der Kategorie ‚Tutorials‘ leider nicht mehr auf herunterladbare Beispiel-Daten sowie das Tool selber inklusive Konfigurations- und Gebrauchsanleitungen, sondern führen nur noch ins leere. 2 Oliver Vietor 2 Datenreinigung Der Kontext der Datenreinigung und im weiteren Verlauf das Konzept von AJAX wird anhand eines Beispiels vorgestellt. Das Ziel des Beispielszenarios ist es, aus verschiedenen Quellen einheitliche Literaturangaben zu generieren, die dann zum Beispiel für eine digitale Bücherei bzw. Suchmaschine wie CiteSeer [Cit15] verwendet werden können. Das Ziel ist es folgende zwei Quellenangaben, die aus zwei verschiedenen Werken stammen, zusammenzufügen. [QGMW96] Dallan Quass, Ashish Gupta, Inderphal Singh Mumick, and Jennifer Widom. Making Views Self-Maintainable for Data Warehousing. In Proceedings of the Conference on Parallel and Distributed Information Systems. Miami Beach, Florida, USA, 1996. Available via WWW at wwwdb.stanford.edu as pub/papers/selfmaint.ps. Quellenangabe aus Werk A [12] D. Quass, A. Gupta, I. Mumick, and J. Widom: Making views self -maintanable for data, PDIS'95 Quellenangabe aus Werk B Die beiden Quellenangaben verweisen beide auf dasselbe Paper, wobei sie sich jedoch in ihrem Umfang und ihrer Form grundlegend unterscheiden. 2.1 Probleme Während im Werk A als Verweis auf die Quelle innerhalb des Dokumentes die Bezeichnung QGMW96, also die Anfangsbuchstaben der j eweiligen Autoren zusammen mit der Jahreszahl verwendet wird, werden die Quellen im Werk B lediglich durchnummeriert. Eine eindeutige Bezeichnung – also eine allgemeingültige ID – gibt es also in beiden Fällen nicht. Wenn jedoch festgestellt wird, dass zwei Quellenangaben auf dasselbe Werk verweisen, ließe sich eine neue, global eindeutige ID automatisch generieren. Eine weitere Kategorie von Unterschieden sind Unterschiede formaler Art. Im Werk A werden die Autoren vollständig mit Vor- und Nachnamen genannt, wohingegen in Werk B jeweils nur der erste Buchstabe des Vornamen angegeben ist. Ebenso wird die Konferenz, auf der das Paper entstanden ist, verschieden referenziert. Während im Werk A der Name der Konferenz vollständig ausgeschrieben wird (Conference on Parallel and Distributed Information Systems), wird im Werk B lediglich das Akronym PDIS angegeben. Mögliche Datenreinigungsverfahren müssten also alle Darstellungsmöglichkeiten solcher Angaben nacheinander vergleichen, was sehr aufwendig ist. Deklarative Datenreinigung mit AJAX 3 Ein weiteres Problem ist die Inkonsistenz der Daten. So wird einerseits als Erscheinungsjahr 1996 und andererseits 1995 angegeben. Wenn nur ein Werk eine von allen anderen Werken verschiedene Angabe zu einer Quelle macht, könnte diese relativ leicht herausgefiltert werden. Wenn es aber nur die zwei Angaben gibt, muss das korrekte Ergebnis manuell ausgewählt werden. Ebenso können Daten fehlerhaft sein. Dies kommt zum Beispiel durch verdrehte oder fehlende Buchstaben, welche durch die automatische Texterkennung der PDF-Dateien zustande kommen können. So fehlt im Titel der Quellenangabe im Werk B […maintanable…] ein Buchstabe. Hierbei helfen Verfahren, die die Wörter aufgrund von Ähnlichkeiten vergleichen. Die letzte Problemquelle bei der Zusammenführung mehrere Quellenangaben sind der unterschiedliche Umfang der Informationen. So ist im Werk A eine Angabe zur Entstehungsort vorhanden, im Werk B allerdings nicht. Aufgrund der auf vielen verschieden Weisen darstellbaren Angaben, ist hier eine Zusammenführung aufwendig und schwierig. 2.2 Existierende Tools Bereits 2001, als das Paper von Galhardas et al. veröffentlicht wurde, gab es eine Vielzahl an Tools, die zur Datenreinigung eingesetzt wurden. Das Hauptziel solcher Tools ist es, Datenflussgraphen zu erstellen, die effektiv dirty data – also nicht-einheitliche Daten – bereinigen können und dabei ebenfalls effizient mit einer großen Anzahl von Eingabedaten umgehen können. Jedoch haben die existierenden Tools eine Reihe von problematischen Eigenschaften, die durch die Entwicklung von AJAX verbessert werden sollten. Zum einen soll in AJAX die sonst mangelhafte Trennung zwischen der logischen Spezifikationen der Daten Transformation und der dazugehörigen physikalischen Implementation verbessert werden. So würden zum Beispiel einige Tools für die Unifikation der Autorenangaben bereits feste Algorithmen und dadurch Implementationen einsetzten. Wenn diese Algorithmen jedoch aufwändig ausgetauscht werden, müssen meistens ebenfalls die logischen Spezifikationen mit geändert werden, welches durch die strikte Trennung der beiden Schichten verhindert werden soll. Zum anderen sollen die Interaktionsmöglichkeiten des Benutzers mit dem Tool verbessert werden. Die Interaktion mit bereits existierende Tools fand in der Regel nur über erstellte Logfiles statt. Bei den zwei verschiedenen Jahresangaben ist also nach der Ausführung des Tools eine manuelle Durchsicht der Logfiles nötig und daraufhin eine manuelle Anpassung der Daten. Ob nach dieser Änderung die Daten übereinstimmen und ob bei der manuellen Änderung keine weiteren Fehler hinzugekommen sind, ließe sich nur über eine erneute Ausführung des Tools herausfinden. Das zweite Hauptziel von AJAX ist diesen Interaktionsprozess zu verbessern. Im Kapitel 3 wird näher auf diese beiden Hauptaugenmerke eingegangen. 4 Oliver Vietor 2.3 Deklarative Datenreinigung Der Begriff der deklarativen Datenreinigung ist auf die in AJAX verwendete Sprache zurückzuführen. Einerseits gibt es imperative Programmiersprachen wie Java oder C++, bei denen die Programme aus Befehlen (lat. imperare = befehlen) bestehen. Im Gegen satz dazu gibt es deklarative Programmiersprachen wie z. B. SQL oder Prolog. Bei imperativen Sprachen liegt dabei das wie soll etwas durchgeführt werden im Vordergrund, während bei deklarativen Sprachen das was im Fokus ist bzw. welche Ergebnisse abgefragt werden sollen. [Mic15] Deklarative Datenreinigung mit AJAX 5 3 AJAX AJAX ist ein Tool zur Datenreinigung, welches im Jahr 2000 am Nationalen Forschungsinstitut für Informatik und Automatisierung in Frankreich entwickelt worden ist. Es ist in Java geschrieben und arbeitet auf Oracle Datenbanken. Verwenden lässt sich das Tool über die Entwicklungsumgebung Eclipse, wobei mittlerweile die entsprechenden Dateien nicht mehr auf der Projekthomepage verfügbar sind [Gal+12]. Die wesentlichen Neuerungen im Vergleich zu bereits bestehenden Tools werden in den folgenden Unterkapiteln erläutert. 3.1 Benutzerinteraktion Bei den bisherigen Datenreinigungstools wurde bei nicht automatisch behandelbaren Diskrepanzen zwischen den verschiedenen Eingabedaten lediglich ein Eintrag in einer Logdatei angelegt, die anschließend manuell durchgegangen werden musste und woraufhin die Daten schlussendlich noch manuell bearbeitet werden mussten. AJAX ergänzte die Logdateien durch interaktive Abfragen, bei denen der Benutzer auswählen kann, welche Daten korrekt welche fehlerhaft sind und somit korrigiert werden sollen. Außerdem ermöglichen Exceptions eine bessere Behandlung von Fehlerfällen. So würde ein leerer Autorenname oder ein Veröffentlichungsdatum, welches mehr als 200 Jahre zurückliegt, als fehlerhaft angegeben werden. Datenbereinigung mit AJAX lässt sich dadurch wesentlich bequemer betreiben und es werden eher manuelle Fehler behoben bzw. vermieden. 3.2 Trennung von Logik und Implementation Um die logischen Spezifikationen und die dazugehörigen physischen Implementierungen zu trennen, beinhaltet AJAX eine deklarative Sprache, auf die im Kapitel 4 genauer eingegangen wird. Der Beispielkontext ist weiterhin die Zusammenführung der verschiedenen Quellenangaben aus unterschiedlichen Werken. Ziel ist es, aus den ‚schmutzigen‘ Eingabedaten die Informationen zu den Autoren, der Events sowie die Publikationen herauszufiltern. Anhand der Nummerierungen (1-5) auf der logischen Schicht (Abbildung 1) werden im Folgenden die einzelnen Teilschritte des Datenreinigungsprozesses erläutert. Auf die physische Ebene, also auf die Implementierung der jeweiligen Funktionen, wird im Rahmen dieser Ausarbeitung nicht genauer eingegangen. 6 Oliver Vietor Abbildung 1 Übersicht AJAX Framework – [Gal06] Seite 334 Deklarative Datenreinigung mit AJAX 7 4 Deklarative Sprache Die in AJAX beschriebene Sprache baut auf der ebenfalls deklarativen Sprache SQL auf. Dabei werden SQL-Statements durch neue Schlüsselworte um weitere Funktionen ergänzt. Syntaktisch hat jeder Operator eine FROM Klausel, welche die Eingabedaten angibt, eine CREATE Klausel, welche neben der Bezeichnung des Operators den Namen für die Ausgabe angibt, eine SELECT Klausel, welche das Format der Ausgabedaten angibt sowie eine WHERE Klausel, mit der nicht relevante Tupel aus den Eingabedaten herau sgefiltert werden können. Durch die optionale LET Klausel kann die nötige Transformationslogik, die auf jedes Eingabetupel angewendet werden muss, um Ausgabetupel daraus zu erstellen, angegeben werden. Durch die LET Klausel können einerseits lokale Variablen deklariert werden und andererseits externe Funktionen aufgerufen werden. Zum Gruppieren der Ausgabetupel wird die BY METHOD Klausel verwendet. Abbildung 2 Eingabe- und Ausgabedaten des Datenreinigungsbeispiels – [Gal06] Seite 331 Der Ablauf von Eingabe- und Ausgabedaten des Datenreinigungsprozess ist in Abbildung 2 analog dargestellt. Die Code-Auszüge sind jeweils entweder aus [GFS+01] oder [Gal06], die Beschreibungen angelehnt an ebendiesen oder an [GFS+00]. 4.1 Mapping Der Mapping-Operator versucht, die Daten in ein standardisiertes Daten-Format zu bringen. So wird, wenn möglich, zum Beispiel das Datumsformat angeglichen [Gal+12] . Außerdem wird jedes Tupel der Relation DirtyData{paper} in ein Tupel der Relation KeyDirtyData{paperKey, paper} umgewandelt. Jedem Paper wird also ein generierter Schlüssel zugeordnet (Abbildung 1 Ziffer 1). Dies geschieht mit Hilfe der LET Klausel und dem Aufruf von generateKey. Durch das SELECT INTO Statement, wird der neu 8 Oliver Vietor generierte Schlüssel zusammen mit den Informationen des Papers in einer neuen Relation KeyDirtyData gespeichert. Durch die geschweiften Klammern um das SELECT INTO werden jeweils die einzelnen SELECT INTO Unterabfragen zur besseren Übersicht von einander getrennt. zu Abbildung 1 Ziffer 1: AJAX: CREATE MAP AddKeytoDirtyData FROM DirtyData LET Key = generateKey(DirtyData.paper) {SELECT Key.gernerateKey AS paperKey, DirtyData.paper AS paper INTO KeyDirtyData} Der aus dem AJAX Code erstellte, äquivalente SQL-Aufruf sieht wie folgt aus: SQL: CREATE TABLE KeyDirtyData(paperKey varchar2(100), paper varchar2(1024) NOT NULL); INSERT INTO KeyDirtyData SELECT dd.paper paper, generateKey(paper) paperKey FROM DirtyData dd Die AJAX und SQL Aufrufe sind sich hier relativ ähnlich. Neben der anderen Reihenfolge der Teilstatements unterscheidet sich der AJAX Code im Wesentlichen dadurch, dass Angaben zum Typ und zur Länge der Spalte weggelassen werden. Im nächsten Schritt (Abb. 1 Ziffer 2) wird die Relation KeyDirtyData durch weitere Mapping-Operationen weiter unterteilt: Aus jedem Eingabetupel werden die Namen der Autoren, die Titel der Publikationen, die Namen der Events sowie die Verbindung zwischen Titeln und Autoren hergestellt und in einzelne Tabellen gespeichert. Jedes der drei SELECT INTO Statements (DirtyTitles, DirtyEvents und DirtyAuthors), die hier im entsprechenden AJAX Code verwendet werden, wird hierbei durch die geschweiften Klammern voneinander getrennt. Im dritten Schritt (Abb. 1 Ziffer 3) werden alle Informationen wie Auflage, Nummer, Land, Stadt und Erscheinungsjahr extrahiert. Mithilfe von Wörterbüchern werden die Städtebzw. Ländernamen mit allen möglichen alternativen Sch reibweisen bzw. deren Synonyme aufgelistet, was eine Vereinheitlichung der Daten ermöglicht. 4.2 View Der View-Operator entspricht im Wesentlichen dem gleichnamigen SQL-Statement. In diesem Schritt (Abb. 1 Ziffer 4) werden die Ergebnisse aus den beiden Vorverarbeitungsschritten (Abb. 1 Ziffer 2 und 3) wieder zusammengeführt. Dabei werden mehrere Eingabetupel, die die Autornamen, die Titel und die Events beinhalten, zu einem Ausgabetupel zusammengefügt. Anders als bei dem aus SQL bekannten VIEW Statement Deklarative Datenreinigung mit AJAX 9 wird die Angabe, welche Spalten in die View übernommen werden sollen, nicht an zweiter Position des Statements gestellt (CREATE VIEW name SELECT culumn1, column2, …), sondern wird ähnlich bei dem Mapping Operator (Kapitel 4.1) an das Ende des Statements gestellt. Es ist dabei ebenso möglich, über die geschweiften Klamern mehrere SELECT INTO Statements zu verwernden. Ein weiterer Unterschied zum regulären SQL ViewOperators ist es, dass AJAX zusätzlich die Verwendung von Exceptions ermöglicht. zu Abb. 1 Ziffer 4: AJAX: CREATE VIEW viewPublications FROM DirtyPubs p, Titles t WHERE p.pubkey = t.pubKey {SELECT p.pubkey AS pubKey, t.title AS title, t.eventKey AS eventKey, p.volume AS volume, p.number AS number, p.country AS country, p.city AS city, p.pages AS pages, p.year AS year, p.url AS url INTO Publications } 4.3 Matching Der Matching-Operator erhält als Eingabe zweimal die Relation DirtyAuthors{authorKey, name}. Daraufhin wird versucht, paarweise doppelte Einträge, also Duplikate, in der Relation zu finden (Abb. 1 Ziffer 5). In der LET Klausel wird dafür die Edit-Distanz (auch Levenshtein-Distanz), also die minimalen Kosten, die zur Umformung von Autor1 in Autor2 entstehen, berechnet. Durch die WHERE Klausel werden diejenigen Tupel aussortiert, deren Edit-Distanz größer ist, als die Distanz der längsten 15% aller Autorennamen (vgl. [GFS+01] Abschnitt 3.3.). Durch das INTO Statement wird, ähnlich wie zuvor bei den SELECT INTO Statements, der Name der Ziel-Relation angegeben. zu Abb. 1 Ziffer 5: AJAX: CREATE MATCH MatchDirtyAuthors FROM DirtyAuthors a1, DirtyAuthors a2 LET distance = editDistanceAuthors(a1.name, a2.name) WHERE distance < maxDist(a1.name, a2.name, 15) INTO MatchAuthors 10 Oliver Vietor Der äquivaltente SQL-Aufruf sieht wie folgt aus: SQL: CREATE TABLE MatchAuthors(authorKey1 varchar2(100), authorKey2 varchar2(100), distance number); INSERT INTO MatchAuthors SELECT authorKey1, authorKey2, distance FROM (SELECT a1.authorKey authorKey1, a2.authorKey authorKey2, editDistanceAuthors(a1.name, a2.name) distance FROM DirtyAuthors a1, DirtyAuthors a2) WHERE distance < maxDist; 4.4 Clustering Der Cluster-Operator ist vergleichbar mit dem SQL GROUP BY, wobei der Unterschied dazu ist, dass der AJAX Cluster-Operator im Gegensatz zum GROUP BY auch beliebige Cluster-Algorithmen zulässt. Ziel dieses Schrittes ist es, durch das Bilden der transitiven Hülle, in den vorher nur paarweise verglichenen Autoren nun auch transitive Duplikate zu entfernen: Autor1 und Autor2 sowie Autor2 und Autor3 wurden im Matching-Schritt als Duplikate erkannt; im Clustering-Schritt werden nun auch Autor1 und Autor3 als zusammengehörige Duplikatenpaare erkannt. zu Abb. 1 Ziffer 5: AJAX: CREATE CLUSTER clusterAuthorsByTransitiveClosure FROM MatchAuthors BY METHOD transitive closure WITH PARAMETERS authorKey1, authorKey2 INTO clusterAuthors 4.5 Merging Der Merging-Operator hat kein direktes Pendant in SQL, ist allerdings mit AggregationsFunktionen vergleichen. Die gruppierten Datensätze, die durch den Cluster-Operator erstellt wurden, werden vom Merging-Operator jeweils zu einem Eintrag zusammengefasst. Als Autorenname wird dabei der längste der ggf. verschieden geschriebenen Autorennamen übernommen, da bei einigen Quellenangaben Teile der Autorennamen abgekürzt oder komplett weggelassen werden. Ebenso wird aus dem Autorennamen eine eindeutige ID generiert. zu Abb. 1 Ziffer 5: AJAX: CREATE MERGE MergeAuthors USING clusterAuthors(cluster_id) ca LET name = getLongestAuthorName(DirtyAuthors(ca).name) key = generateKey(name) {SELECT key AS authorKey, name AS name INTO Authors} Deklarative Datenreinigung mit AJAX 11 5 Fazit Es gibt zwar diverse Standards in diesem Beispiel zur Angabe von Quellen, allerdings werden diese nicht einheitlich angewendet. Fehlende oder fehlerhafte Felder führen dazu, dass Daten bereinigt werden müssen, wie in dem Beispiel der Zusammenführung von Quellenangaben. Effiziente und für den Benutzer bequem und zuverlässig zu benutzende Tools sind dabei unerlässlich. Die Neuerungen, die durch die Entwicklung von AJAX zu diesen Tools hinzugefügt wurden, zeigen aber auch, dass Datenreinigungs-Tools längst noch nicht vollständig und fehlerfrei sind. Auch, wenn AJAX selber mittlerweile nicht mehr weiter entwickelt wird – ist laut Projekthomepage [Gal+12] auch lediglich nur ein Prototyp —, beziehen sich heutzutage dennoch weiterhin viele Publikationen in diesem Bereich auf die Paper [GFS+01] und [Gal06]. Heutzutage gibt es neben der Zusammenführung von Quellenangaben sehr viele weitere Anwendungsgebiete für Datenreinigung. So müssen zum Beispiel Preisvergleichsportale – egal was dort nun verglichen werden soll – die Daten der einzelnen Bezugsquellen vor der Weiterverarbeitung bereinigen. 12 Oliver Vietor Literaturverzeichnis [Cit15] Pe nnsylvania State Unive rsity (2015): Cite SeerX. http://csxstatic.ist.psu.edu. [GFS+00] Galhardas, He le na; Florescu, Danie la; Shasha, De nnis; Simon, Eric: An e xte nsible Frame work for Data Cle aning. In: 16th Inte rnational Conference on Data Engine ering. San Die go, CA, USA, 29 Fe b.-3 March 2000, S. 312. [GFS+01] Galhardas, He le na; Florescu, Danie la; Shasha, De nnis; Simon, Eric; Saita, CristianAugustin (2001): De clarative Data Cle aning: Language, Mode l, and Algorithms. In: Proce edings of the 27th Inte rnational Confe rence on Ve ry Large Data Bases. [Gal06] Galhardas, He le na (2006): Data Cle aning and Transformation Using the AJAX Frame work. In: David Hutchison, Take o Kanade , Josef Kittle r, Jon M. Kle inbe rg, Frie de mann Mattern, John C. Mitche ll e t al. (Hg.): Ge ne rative and Transformational Te chnique s in Software Engine ering, Bd. 4143. Be rlin, He ide lbe rg: Springe r Be rlin He ide lbe rg (Le cture Note s in Compute r Science), S. 327–343. [Gal+12] Galhardas e t al. (2012*): AJAX. A Data Cle aning Prototype. Proje kthomepage. http://we b.ist.utl.pt/~he le na.galhardas/Ajax/index.html *le tzte Ände rung 2012 [Mic15] Microsoft (2015): Functional Programming vs. Imperative Programming. MSDN Library. https://msdn.microsoft.com/en-US/library/bb669144.aspx.