Declarative Data Cleaning

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
[email protected]
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 2001. 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:
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,
1996. 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 LevenshteinDistanz können in vielen Fällen diese Probleme minimieren. Aber gerade bei Eigen-
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 2.1.1 und 2.1.2 lenken:
2.1.1 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).
Abbildung 1 – Datenflussdiagramm mit logischer und physischer Ebene für bibliographische Daten
anhand des Citeseer Beispiels
2.1.1.1 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.
Abbildung 2 - Data Cleaning Prozess am Beispiel von Citeseer
2.1.1.2 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 SQLDatenbank 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äts-
als auch nach Performanz-Kriterien) Ergebnisse zu erzielen.
2.1.2 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. „1996 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.
3 Specification Language
3.1 Mapping
Der Mapping-Operator arbeitet die Daten für die weitere Verarbeitung auf. Falls kein UniqueKey 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)
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()
{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}
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.
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, 2001. http://www.vldb.org/conf/2001/P371.pdf
[2]
Helena Galhardas: “Data Cleaning: Model, Declarative Language, and Algorithms”,
PhD Thesis, 146S. , University Versailles Saint-Quentin-en-Yvelines, 17 September
2001, http://www.inria.fr/rrrt/tu-0691.html