Hausarbeit zum Seminar: Digital Information Curation WS 2005/2006. Dozenten: Prof. Dr. Marc Scholl, Dr. André Seifert. Language, Model, and Algorithms

Transkript

1 Universität Konstanz Hausarbeit zum Seminar: Digital Information Curation WS 2005/2006 Dozenten: Prof. Dr. Marc Scholl, Dr. André Seifert Declarative Data Cleaning: Language, Model, and Algorithms Sebastian Rexhausen

2 1 Einführung Grundlage dieser Seminararbeit bildet die Veröffentlichung von Helena Galhardas et al. Declarative Data Cleaning: Language, Model, and Algorithms in VLDB '01: Proceedings of the 27th International Conference on Very Large Data Bases aus dem Jahre In ihr wird der Ansatz des Declarative Data Cleanings genauer erläutert und das darauf aufsetzende Projekt AJAX näher vorgestellt. Die damals verfügbaren Data Cleaning Tools führten in den Augen der Autoren zu ungenügenden Ergebnissen, weshalb sie den Entwurf eines eigenen Konzeptes/Tools vorantrieben, welches beim Design und der Implementierung des Data Cleaning Prozesses unterstützen sollte. Dabei wurde vor allem Wert gelegt auf klare Trennung von logischer Spezifikation und physischer Implementierung der Datentransformationen, Nachvollziehbarkeit und Erklärung der Data Cleaning Ergebnisse und zuletzt auf Benutzerinteraktion während des ganzen Analyse-Prozesses. Die in dieser Arbeit verwendeten Beispiele werden anhand von Citeseer-Quellenangaben, welche auch im Paper [1] genutzt werden, erläutert. 2 Data Cleaning Data Cleaning wird auch synonym unter den Begriffen data cleansing, data scrubbing oder Datenbereinigung verwendet. Seine Aufgabe besteht darin, Inkonsistenzen und Fehler in Datenbeständen zu erkennen und die unsauberen Daten anschließend zu entfernen bzw. zu korrigieren. Die Hauptnachfrage nach Data Cleaning liegt beim Entfernen von Anomalien in einer Datensammlung, bei der Überführung von unstrukturierten/teilstrukturierten Daten in strukturierte Daten oder bei der Kombination von Daten aus mehreren Quellen (siehe [2] Seite 11ff). Data Cleaning Verfahren finden eine weite Verbreitung bei Decision-Support-Systemen und bei Data Warehouses denn nur auf Grund von verlässlichen Daten kann die Genauigkeit, Richtigkeit und hohe Performance bei darauf basierenden Analysen gewährleistet werden. Unsaubere Daten können auf verschiedenartige Weise entstehen. Im Folgenden wird versucht anhand einer Problemstellung, wie sie Citeseer beim Einfügen von neuen Dokumenten in ihren Datenbestand hat, näher auf die verschiedenen Arten von unsauberen Daten einzugehen. Im Beispiel werden Quellenangaben aus zwei verschiedenen Arbeiten behandelt, die dasselbe Dokument beschreiben:

3 Referenz aus Paper1: [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, Available via WWW at www-db.stanford.edu as pub/papers/self-maint.ps. Referenz aus Paper2: [12] D. Quass, A. Gupta, I. Mumick, and J. Widom: Making views selfmaintanable for data, PDIS'95 Data Cleaning Probleme: Keine universelle ID Auf Grund von nicht existierenden Standards im Bezug auf Zitierstil der Quellenangabe existiert kein Zwang eine weltweit geltende, universelle ID für dasselbe Objekt zu nutzen. Somit können Data Cleaning Systeme bei Extraktion von Quellenangaben ([QGMW96] [12]) aus verschiedenen Papers nicht von einem Matching über eine universelle ID ausgehen, sondern müssen die Zuordnung derselben Objekte über verschiedene Verfahren sicherstellen. Syntax & Formatierung Ebenfalls kann nicht davon ausgegangen werden, dass ein Standard für die Syntax bzw. die Formatierung von Quellenangaben genutzt wird. Folglich müssen aufwendige Verfahren generiert werden, um z.b. denselben Autor (Dallan Quass D. Quass) oder dieselbe Konferenz (Conference on Parallel and Distributed Information Systems PDIS) zu identifizieren. Konsistenz der Daten Ferner kann nicht von einer völligen Korrektheit der in den Quellenangaben enthaltenen Daten (1996 '95) ausgegangen werden. Bei solchen Inkonsistenzen muss in den meisten Fällen ein Mensch zur Korrektur herangezogen werden. Fehlerhaftigkeit der Daten Fehlerhafte Daten, die durch Tippfehler (maintanable), Rechtschreibfehler oder Import-Fehler entstehen, sind ein weiteres großes Problem für die Data Cleaning Verfahren. Rechtschreibkorrekturen oder Ähnlichkeitsmaße wie die Levenshtein- Distanz können in vielen Fällen diese Probleme minimieren. Aber gerade bei Eigen-

4 oder Ortsnamen muss auf die Exaktheit der Daten größter Wert gelegt und somit muss die Wahl der Verfahren durch mehrere Testreihen gestützt werden. Unterschiedliche Informationen Die letzte große Problemstellung sind unterschiedliche Informationen in den Quellenangaben (Ortsangabe keine Ortsangabe). Ihnen kann meist auch nur durch Miteinbeziehen eines Menschen entgegnet werden. 2.1 Declarative Data Cleaning Die Ergebnisse aller bis zum Erscheinen des Papers genutzten Data Cleaning Ansätze und Tools zeigten laut den Autoren bei der Analyse mehrere Unzulänglichkeiten. So war es mit keinem der damaligen Tools möglich, z.b. ein Auftreten von Inkonsistenzen (1996 '95) während des Analyseprozesses zu beheben. Die Änderungen konnten nur aus Logfiles ausgelesen werden und im Nachhinein (halb-)automatisch bzw. manuell vorgenommen werden Nutzerinteraktion während dieses bis dato unidirektionalen Prozesses war nicht vorgesehen. Ferner waren die Spezifikation der Funktionen und deren Implementierung so sehr miteinander verwoben, dass bei kleinen Änderungen große Teile des Codes neu geschrieben werden mussten oder ein Austausch eines Algorithmusses die Anpassung der Spezifikation nach sich zog. Diese Unzulänglichkeiten ließen die Autoren bei der Entwicklung ihres Frameworks ihr Hauptaugenmerk auf die Punkte und lenken: Trennung von logischer Spezifikation und physischer Implementierung Die Trennung von logischer Spezifikation und physischer Implementierung ermöglicht, dass ein Problem beschrieben werden kann, ohne erklären zu müssen, wie die passenden Berechnungen aussehen. Der Fokus liegt also nicht wie bei anderen Data Cleaning Tools darauf, wie etwas zu geschehen hat oder was zu tun ist, sondern nur noch darauf, welches Ergebnis gewünscht ist (ähnlich zu Prolog oder SQL).

5 Abbildung 1 Datenflussdiagramm mit logischer und physischer Ebene für bibliographische Daten anhand des Citeseer Beispiels Logische Spezifikation In der logischen Spezifikation wird ein Datenflussdiagramm mit Hilfe von logischen Operatoren (Mapping, Matching, Clustering, Merging, View siehe Kapitel 3) erstellt, um aus den zuvor unsauberen Publikationsdaten (Dirty Data) eine Liste von sauberen Publikationen (Publications) zu erstellen. Ein Datenflussdiagramm für das Säubern der Citeseer-Daten würde wie Abbildung 1 aussehen (Ziffern beziehen sich auf Abbildung): 1. Füge jedem Datensatz einen eindeutigen Schlüssel hinzu 2. Extrahiere aus jedem Datensatz die Namen der Autoren, Titel der Veröffentlichung, Name der Veranstaltung und die Beziehung von Autor und Titel 3. Extrahiere aus jedem Datensatz die Ausgabe, Nummer, Land, Stadt, Seitenanzahl, Jahr und URL. Nutze anschließend eigene Wörterbücher (Cities, Countries), um die Einträge auf einen gemeinsamen, in den Wörterbüchern festgelegten, Nenner zu bringen. 4. Eliminiere Duplikate 5. Füge die Einträge zusammen In Abbildung 2 ist der Data Cleaning Prozess genau aufgezeigt und die zum Bereinigen der Publikationsdaten benötigten Tabellen und die Ergebnis-Tabelle Publications zu sehen.

6 Abbildung 2 - Data Cleaning Prozess am Beispiel von Citeseer Physische Implementierung Die physische Ebene bezieht sich auf die Implementierung der hinter den logischen Operatoren stehenden Funktionen. Wie genau diese Funktionen aussehen oder wie ihr Quellcode aussieht kann dem Nutzer egal sein er muss sich wie beim Anfragen einer SQL- Datenbank nur um die logische Ebene kümmern (Query formulieren) und könnte später die Optimierung der dahinter stehenden Algorithmen angehen ohne die Anfrage umformulieren zu müssen. Ferner kann er zwischen verschiedenen Funktionen (für Matching z.b. Nested Loop oder Neighborhood Join) wählen solche mit denen er denkt, optimale (sowohl nach Qualitätsals auch nach Performanz-Kriterien) Ergebnisse zu erzielen User Interaction Bei bis dato vorhandenen Data Cleaning Systemen wurden Datensätze, die nicht korrekt bereinigt werden konnten, in eine Logdatei geschrieben. Manche zur Bereinigung von Daten nötige Schritte des Data Cleaning Prozesses konnten/können nicht automatisch vom System vorgenommen werden. Je größer also die zu bereinigende Datenmenge, desto größer wurde auch die Logdatei. Mit Hilfe von Dialogen (z.b oder 1995 korrekt? ), Exceptions und Backtracking (Zurückverfolgen der Anfragen) versucht das AJAX-System hingegen schon während der Analyse den User mit in den Data Cleaning Prozess einzubeziehen. Falls Fehler im Prozess auftreten, wird nicht wie bei anderen Systemen die Arbeit unterbrochen (oder die Logdatei erweitert), sondern dem Nutzer nur das Auftreten mitgeteilt. Er kann somit die Effektivität und Effizienz seines vorher festgelegten Datenflussdiagramms weiter steigern.

7 3 Specification Language 3.1 Mapping Der Mapping-Operator arbeitet die Daten für die weitere Verarbeitung auf. Falls kein Unique- Key vorhanden ist, erzeugt er einen und fügt ihn dem Eintrag hinzu falls nicht übernimmt er den vorhandenen. Formale Spezifikation: CREATE MAPPING <operation-name> FROM <predicate-name> [<alias-variable>] [LET <let-clause>] [WHERE <where-clause>] <select-into-clause> Citeseer-Funktion (siehe Abbildung 1 Ziffer 1): CREATE MAPPING AddKeytoDirtyData FROM DirtyData LET Key = generatekey(dirtydata.paper) {SELECT Key.gernerateKey AS paperkey, DirtyData.paper AS paper INTO KeyDirtyData} 3.2 Matching Der Matching-Operator sucht nach Einträgen, die wahrscheinlich das gleiche Objekt beschreiben. Die Übereinstimmungskriterien können ein oder mehrere Einträge sein. Formale Spezifikation: CREATE MATCHING <operation-name> FROM (<predicate-name> [<alias-variable>])+ [LET <let-clause>] [WHERE <where-clause>] INTO <predicate-name> Citeseer-Funktion (Siehe Abbildung 1 Ziffer 4): CREATE MATCHING MatchDirtyAuthors FROM DirtyAuthors a1, DirtyAuthors a2 LET distance = editdistanceauthors(a1.name, a2.name)

8 WHERE distance < maxdist(a1.name, a2.name, 15) INTO MatchAuthors 3.3 Clustering Der Clustering-Operator gruppiert Einträge, deren Ähnlichkeitswert einen vorgegebenen Schwellenwert übersteigt. Formale Spezifikation: CREATE CLUSTERING <operation-name> FROM <predicate-name> [<alias-variable>] BY METHOD <method-name> WITH PARAMETERS <parameter-name> [{<parameter-name}] INTO <predicate-name> Citeseer-Funktion (Siehe Abbildung 1 Ziffer 4): CREATE CLUSTERING clusterauthorsbytransitiveclosure FROM MatchAuthors BY METHOD transitive closure WITH PARAMETERS authorkey1, authorkey2 INTO clusterauthors 3.4 Merging Der Merging-Operator fügt die durch den Clusteralgorithmus berechneten Gruppen zu jeweils einem Eintrag zusammen. Formale Spezifikation: CREATE MERGING <operation-name> USING <predicate-name> [<alias-variable>] LET <let-clause> [WHERE <where-clause>] <select-into-clause> Citeseer-Funktion (Siehe Abbildung 1 Ziffer 4): CREATE MERGING MergeAuthors USING clusterauthors(cluster_id) ca LET name = getlongestauthorname(dirtyauthors(ca).name) key = generatekey()

9 {SELECT key AS authorkey, name AS name INTO Authors} 3.5 View Der View-Operator arbeitet die Inhalte aus verschiedenen Relationen zu einer neuen Relation so auf, dass sie einem gewünschten Ausgabeformat entsprechen. Formale Spezifikation: CREATE VIEW <operation-name> FROM (<predicate-name> [<alias-variable>])+ [WHERE <where-clause>] {<select-into-clause>} Citeseer-Funktion (Siehe Abbildung 1 Ziffer 5): CREATE VIEW viewpublications FROM DirtyPubs p, Titles t WHERE p.pubkey AS 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,... INTO Publications CONSTRAINT NOT NULL title}

10 4 Fazit Das in dem Paper beschriebene Verfahren ist eine zur damaligen Zeit konsequente Weiterentwicklung der bestehenden Verfahren. Es wurde ein Data Cleaning Framework entwickelt, welches die größten Schwachpunkte (Trennung von logischer Spezifikation und physischer Implementierung) der bisherigen Produkte angeht und um neue Ideen (User Interaction) erweitert. Leider hat der Prototyp nie das Licht der freien Welt erblick und wurde trotz viel versprechender Ansätze und scheinbar sehr gut funktionierendem Prototyp nicht wie versprochen (siehe [2]) der breiten Masse zugänglich gemacht. Allerdings wurde das Anwendungsgebiet von Declarative Data Cleaning enorm eingeschränkt obwohl es eigentlich eine Erweiterung darstellen sollte. Es arbeitet nur auf bereits strukturierten Daten und muss ferner das Schema dieser Daten im Vorhinein kennen, um darauf seine Operationen anwenden zu können. Wie aber unstrukturierte Daten behandelt und abgeglichen werden können, wird in diesem Paper nicht behandelt. Ferner ist die PhD Thesis [2] der Hauptautorin Helena Galhardas auch die letzte Veröffentlichung im Hinblick auf Declarative Data Cleaning. Wenn es also die Lösung der Data Cleaning Bewegung gewesen wäre, hätten weitere Entwicklungen und darauf basierende Veröffentlichungen folgen müssen auch von Fremdautoren. Summa summarum ist die Arbeit von Galhardas, Florescu, Shasha, Simon und Saita also zwar ein logischer Schritt der Weiterentwicklung von bestehenden Verfahren, der aber irgendwann sowieso kommen musste.

11 5 Quellen: [1] Helena Galhardas, Daniela Florescu, Dennis Shasha, Eric Simon, Cristian-Augustin Saita: Declarative Data Cleaning: Language, Model, and Algorithms, 10S., in VLDB '01: Proceedings of the 27th International Conference on Very Large Data Bases, [2] Helena Galhardas: Data Cleaning: Model, Declarative Language, and Algorithms, PhD Thesis, 146S., University Versailles Saint-Quentin-en-Yvelines, 17 September 2001,