ETL: Extraction, Transformation, Load · Ulf Leser Wissensmanagement in der Bioinformatik ETL: Extraction, Transformation, Load Data Warehousing und Data Mining

Ulf Leser

Wissensmanagement in der Bioinformatik

ETL: Extraction, Transformation, Load

Data Warehousingund

Data Mining

Ulf Leser: DWH und DM, Sommersemester 2007 2

Sprachen für OLAP Operationen

• Sprachen für OLAP Operationen – Bereitstellung der notwendigen Operationen– Ökonomisches Design

• Keine vielfach geschachtelten SQL Operationen• Keine „Programmierung“

• Hauptsächlich zwei Ansätze– Multidimensional Expressions (MDX)

• Basiert direkt auf MDDM Elementen: Cube, Dimension, Fakt, ...• Auf dem Vormarsch als Standard

– Erweiterungen von SQL • Erweiterungen um spezielle Operationen (ROLLUP, CUBE, …)• Daten müssen relational vorliegen• „MDDM-unaware“ – Anfragen müssen auf Star-/ Snowflake-

Schema formuliert werden


MDX

• MDX: Multidimensional Expressions– Microsoft‘s Vorschlag, „OLE DB for OLAP“

• Eigene Anfragesprache– Standard ohne feste Semantik (by example)– MDDM Konzepte als First-Class Elemente– Dadurch kompaktere Anfragen als mit SQL– SQL-artige Syntax– Sehr mächtig und komplex

• Erzeugung der Objekte (DDL) erfolgt anderweitig– DSO Interface (Decision Support Objects) von SQL Server

• Wird von vielen kommerziellen Tools zur Kommunikation mit OLAP Datenbank benutzt


Struktur einer MDX Query

SELECT <axis-spec1>, <axis-spec2>, ..FROM <cube-spec1>, <cube-spec2>, ...WHERE <slice-specification>

• Dimensions (SELECT)– Angabe der darzustellenden Achsen– Abbildung in „mehrdimensionale“ Tabellen

• ON COLUMNS, ROWS, PAGES, CHAPTER, ...– Jede Achsenspezifikation muss eine Menge von Members beschreiben

• Als explizit angegebene Menge (in {})• Oder durch Funktionen

– Namen von Members werden in [] verpackt• Wenn nötig zur syntaktischen Abgrenzung

• Cube (FROM)– Auswahl des Basis-Cubes für die Anfrage

• Slicer (WHERE)– Auswahl des betreffenden Fakten– Intuitiv zu lesen als „etwas zu tun haben mit“


Beispiel

SELECT {Wein, Bier, Limo, Saft} ON COLUMNS{[2000], [1999], [1998].[1], [1998].[2]} on ROWS

FROM SalesWHERE (Measures.Menge, Region.Germany)

Wein Bier Limo Saft

2000

1999

1998.1

1998.2

Member: Unique Names oder Navigation

Implizite Summierung

Verschiedene Klassifikationsstufen in einer Dim möglich

Auswahl des Fakt „Menge“Beschränkung auf Werte in BRD


Navigation in den Hierarchien

Navigationsfunktionen• MEMBERS: Knoten einer Klassifikationsstufe• CHILDREN: Kinderknoten eines Klassifikationsknoten• PARENT: Vaterknoten eines Klassifikationsknoten• LASTCHILD, FIRSTCHILD, NEXTMEMBER, LAG, LEAD...• DESCENDENTS: Rekursives Absteigen

SELECT {Prodgroup.MEMBERS, [Becks Bier].PARENT} ON COLUMNS{Year.MEMBERS} on ROWS

FROM SalesWHERE (Measures.Menge)


SQL und OLAP

• Übersetzung MDDM in Star- oder Snowflake Schema• Triviale Operationen

– Auswahl (slice, dice): Joins und Selects– Verfeinerung (drill-down): Joins und Selects

• Einfache Operation– Aggregation um eine Stufe: Group-by

• Interessant– Hierarchische Aggregationen– Multidimensionale Aggregationen– Analytische Funktionen (gleitende Durchschnitte etc.)

• Ist alles in SQL-92 möglich, aber nur kompliziert auszudrücken und ineffizient in der Bearbeitung


Hierarchische Aggregation –2-

Alle Verkäufe der Produktgruppe „Wein“ nach Tagen, Monaten und Jahren

Benötigt UNION und eine Query pro Klassifikationsstufe

SELECT T.day_id, sum(amount*price)FROM sales S, product PWHERE P.pg_name=„Wein“ AND

P.product_id = S.product_idGROUP BY T.day_id

SELECT T.month_id, sum(amount*price)FROM sales S, product P, time TWHERE P.pg_name=„Wein“ AND

P.product_id = S.product_id ANDT.day_id = S.day_id

GROUP BY T.month_id

SELECT T.year_id, sum(amount*price)FROM sales S, product P, time TWHERE P.pg_name=„Wein“ AND

P.product_id = S.product_id ANDT.day_id = S.day_id

GROUP BY T.year_id


ROLLUP BeispielSELECT T.year_id, T.month_id, T.day_id, sum(...)FROM sales S, time TWHERE T.day_id = S.day_idGROUP BY ROLLUP(T.year_id, T.month_id, T.day_id)

1997 Jan 1 200

1997 Jan ...

31

ALL

...

ALL

...

ALL

1998 Jan 1 100

1998 ... ...

1998 ALL ALL 45.000

... ... ...

ALL

1997 Jan 300

1997 Jan 31.000

1997 Feb

1997 March 450

1997 ...

1997 ALL 1.456.400

ALL ALL 12.445.750


Multidimensionale Aggregation

Verkäufe nach Produktgruppen und Jahren

1998 1999 2000 Gesamt

Weine 15 17 13 45

Biere 10 15 11 36

Gesamt 25 32 24 81

Wie viele Queries sind notwendig ?

• sum() ... GROUP BY pg_id, year_id• sum() ... GROUP BY pg_id• sum() ... GROUP BY year_id• sum()


CUBE - Beispiel

SELECT pg_id, shop_id, sum(amount*price)FROM sales S ...GROUP BY CUBE (S.pg_id, S.shop_id, T.year_id)

Bier Kreuzberg ALL ...

ALL

1997

1998

1997

1998

Bier ALL ALL ...

Wein ALL ALL ...

ALL ALL 1997 ...

ALL ALL 1998 ...

ALL Kreuzberg ALL ...

ALL Charlottenburg ALL ...

ALL

Bier Charlottenburg ...

Bier ALL ...

Wein ALL ...

ALL Kreuzberg ...

ALL Charlottenburg ...

ALL ALL ...


SQL Analytical Functions

• Erweiterung in SQL3 zur flexibleren Berechnung von Aggregaten und Rankings– Ausgabe der Summe Verkäufe eines Tages zusammen mit der Summe

Verkäufe des Monats in einer Zeile– Rang der Summe Verkäufe eines Monats im Jahr über alle Jahre– Vergleich der Summe Verkäufe eines Monats zum gleitenden

Dreimonatsmittel

• OLAP Funktionen– Erscheinen in der SELECT Klausel– Berechnen für jedes Tupel des Stroms der Groupby-Query einen Wert– Diese Werte können von neuen, in der SELECT Klausel angegeben

Partitionierungen und Sortierungen abhängen– Damit kann man unabhängige Gruppierungen in einer Zeile des

Ergebnisses verwenden• CUBE etc. erzeugen immer neue Tupel


OVER() mit lokaler Partitionierung

SELECT S.day_id, sum(amount) AS day_sum, sum(amount) OVER(PARTITION BY YEAR(S.day_id)) AS year_sum,day_sum/year_sum AS ratio

FROM sales S, GROUP BY S.day_id;

day_id day_sum year_sum Ratio

1.1.1999 500 5.000

5.000

5.000

5.000

5.000

1.000

1.000

1.10.2001 4.000 4.000 1.00

0.10

2.1.1999 500 0.10

3.1.1999 1.000 0.20

1.2.1999 1.500 0.30

2.2.1999 1.500 0.30

1.1.2000 600 0.60

5.5.2000 400 0.40

day_id day_sum

1.1.1999 500

2.1.1999 500

3.1.1999 1.000

1.2.1999 1.500

2.2.1999 1.500

1.1.2000 600

1.10.2001 4.000

5.5.2000 400

• OVER() gestattet die Angabe attributlokaler Partitionen• Ausgabe der Summe Verkäufe eines Tages im Verhältnis zu

Verkäufen des Jahres

SQL Funktion YEAR()


Veranschaulichung

(S.day_id, sum(amount))FROM sales S

S.day_id, sum(amount), sum(amount) OVER(PARTITION BY YEAR(S.day_id))

GROUP BY S.day_id

GROUP BY YEAR(day_id)


Lokale Sortierung

• Durch lokale Sortierung mit ORDER BY kann die Reihenfolge der Tupel im inneren Strom pro OVER() Klausel bestimmt werden

• Die Aggregatfunktion iteriert bei einem ORDER BY nur über die Tupel zwischen dem ersten bis zum aktuellen Tupel (bzgl. der angegebenen Ordnung)

• Dadurch kann man kumulierte Summen erreichen• Beispiel: Summe der Verkäufe pro Tag sowie die kumulierten

Gesamtverkäufe nach Tagen, und die kumulierten Verkäufe im jeweiligen Monat nach Tagen

SELECT S.day_id, sum(amount) AS day_sum,sum(amount) OVER(ORDER BY S.day_id) AS cum_sum,sum(amount) OVER(PARTITION BY S.month_id

ORDER BY S.day_id) AS cumm_sumFROM sales S, GROUP BY S.day_id;


Dynamische Fenster

• Der Vergleich der Werte des aktuellen Tuples mit den lokalen Aggregaten zieht immer folgende Tupel in die Aggregation mit ein– OVER() ohne Argument: Alle Tupel– OVER(PARTITION BY): Alle Tupel der gleichen Partition– OVER(ORDER BY): Alle Tupel zwischen Ordungsbeginn und

aktuellem Tupel• Das Fenster des Vergleichs kann man auch explizit

angeben– ROWS BETWEEN … AND …– Möglich jeweils

• UNBOUND PRECEDING / FOLLOWING: Vom Anfang / bis zum Ende• K PRECEDING / FOLLOWING: Die k Tupel vorher / nachher• CURRENT ROW: aktuelles Tupel

• Damit kann man gleitende Durchschnitte bilden


Inhalt dieser Vorlesung

• ETL: Extraction, Transformation, Load- Extraktion von Daten aus Quellen- Das Differential Snapshot Problem- Laden von Daten in das DWH

- Schema- und Datenheterogenität- Datenkonflikte- Datentransformation

• Datenqualität– Data Cleansing– Der Merge/Purge Algorithmus


Der ETL Prozess

0

2 0

4 0

6 0

8 0

10 0

1.Qr t l .

2 .Qr t l .

3 .Qr t l .

4 .Qr t l .

• Extraction• Transformation• Load


ETL - Übersicht

• Daten werden mehrmals physikalisch bewegt– Von den Quellen zur Staging Area

• Extraktion von Daten aus den Quellen• Erstellen / Erkennen von differentiellen Updates• Erstellen von LOAD Files

– Von der Staging Area zur Basisdatenbank• Data Cleaning und Tagging• Erstellung integrierter Datenbestände

• Ziele– Kontinuierliche Datenversorgung des DWH– Sicherung der DWH Konsistenz bzgl. Datenquellen

• Effiziente Methoden essentiell -> Sperrzeiten minimieren• Rigorose Prüfungen essentiell -> Datenqualität sichern


1. Extraktion

• Aufgabe: Extraktion von Änderungsdaten aus Quellen– Ist auf Kooperation der Quellen angewiesen– Quellen müssen ihre Daten preisgeben

• Überwindet Systemgrenzen– Zugriff auf HOST Systeme ohne Online Zugriff

• BATCH Jobs, Reportwriter– Daten in Non-standard Datenbanken

• Keine Anfragesprachen im eigentlichen Sinne• Programmierung in PL-1, COBOL, Natural, IMS, ...

– Verteiltes (Herrschafts-)Wissen• Unklare Semantik, Doppelbelegung von Feldern, sprechende

Schlüssel• Fehlende Dokumentation

– Oftmals kommerzielle Tools vorhanden• Insb. zum Zugriff auf Standardsoftware


Extraktion

• Zwei wichtige Eigenschaften des Extraktionsschritts– Zeitpunkt– Art der extrahierten Daten

• Zu beachten– Wir betrachten meistens „Flow“-artige DWH

• Alle Veränderungen (Verkäufe, Telefonate, …) sollen im Cube repräsentiert werden

• Nachträgliche Änderungen sind möglich, aber eher selten– Stornierungen, Rücksendungen

– Die Situation ist anders bei „Stock“-artigen Daten• Zustand zu einem bestimmten Zeitpunkt (Lagerbestand)• Hier müssen die Zeitpunkte festgelegt werden


Zeitpunkt der Extraktion

• Synchrone Extraktion– Quelle propagiert jede Änderung

• Asynchrone Extraktion– Periodisch

• Push: Quellen erzeugen regelmäßig Extrakte – Das ist Standard: Reportgenerierung

• Pull: DWH fragt regelmäßig Datenbestand ab– Ereignisgesteuert

• Push: Quelle informiert z.B. alle X Änderungen• Pull: DWH erfragt Änderungen bei bestimmten Ereignissen

– Jahresabschluss, Quartalsabschluss, …

– Anfragegesteuert• Push: -• Pull: DWH erfragt Änderungen bei jedem Zugriff auf die (noch

nicht vorhandenen oder potentiell veralteten) Daten


Art der Daten

• Snapshot: Quelle liefert kompletten Datenbestand– Lieferantenkatalog, Preisliste, etc. („Stock“-artige Daten)– Korrekter Import erfordert Erkennen von Änderungen

• Differential Snapshot-Problem• Alternative: Komplettes Überschreiben (aber IC!)

– Historie kann nicht exakt abgebildet werden• Warum nicht?

• Log: Quelle liefert jede Änderung seit letztem Export– Transaktionslogs oder anwendungsgesteuertes Logging– Kann direkt importiert werden

• Das DWH speichert dann ggf. Ereignis und seine Stornierung

• Nettolog: Quelle liefert das Delta zum letzten Export– Kann direkt importiert werden – Bei „Stock“-artigen Daten keine komplette Historie möglich


Datenversorgung

Quelle ... Technik Aktualität DWH

Belastung DWH

Belastung Quellen

... erstellt periodisch Exportfiles

Reports, Snapshots

Trigger, Changelogs, Replikation

Sehr schwierig

Je nachdem

Je nach Frequenz

Eher niedrig Eher niedrig

... pushed jede Änderung Maximal Hoch Hoch

Vor Benutzung Maximal Medium Medium

Anwendungs-gesteuert

Je nach Frequenz

Je nach Frequenz

Je nach Frequenz

... erstellt Extrakte auf Anfrage (Poll)







Differential Snapshot Problem [LGM96]

• Viele Quellen liefern immer den vollen Datenbestand– Molekularbiologische Datenbanken– Kundenlisten, Angestelltenlisten– Produktkataloge– „Dumme“ Reports

• Problem– Ständiges Einspielen aller Daten ineffizient

• Häufige Wiederholung derselben Operationen

– Duplikate müssen erkannt und gelöscht werden• Erfordert vorheriges Löschen oder Überschreiben• Viele Probleme mit Schlüsseln, IC‘s, …

• Gesucht: Algorithmen zur Berechnung von DELTA-Filesfür sehr große Dateien


Das Differential Snapshot Problem (DSP)

• Quelle liefert Snapshots als Files Fi

– Einfache und identische Struktur mit Attributen A1, … An

– Jedes Tupel hat einen Schlüssel k– File = ungeordnete Menge von Records (K, A1, ... An)

• DefinitionGegeben zwei Dateien F1, F2 gleicher Struktur mit f1=|F1|, f2=|F2|. Das Differential Snapshot Problem (DSP) besteht darin, die kleinste Menge O={INS, DEL, UPD}* zu finden für die gilt: O(F1) = F2

• Bemerkung– INS, DEL, UPD operieren jeweils auf genau einem Tupel identifiziert

über seinen Schlüssel k• Änderungen in mehreren Attributen eines Tuples zählen wir nur einmal

– O ist im Allgemeinen nicht eindeutig• O1={ (ins(X)),(del(X)) } ≡ {}


Szenario

DWH

INS K103INS K3DEL K4UPD K202: ...

K104,k,k,...K4, t,r,...K202,a,a,...K102,p,q,...

K103,t,h,...K104,k,k,...K102,p,q,...K3, t,r,...K202,b,b,...

DSP - Algorithmus

Alter Snapshot

Neuer Snapshot


Annahmen

• Kostenmodell– IO Komplexität– Alle Operationen im Hauptspeicher sind umsonst– Das Lesen jedes Records kostet 1

• Sequentielles Lesen– Das Schreiben des DS ignorieren wir

• Das ist immer gleich teuer (wenn wir das kleinste finden …)– Keine Beachtung von Blockgrößen etc.

• Hauptspeichergröße: m Records• Files wesentlich größer als Hauptspeicher• Achtung: Ähnlich zu Joins, aber …

– Wir haben keine Duplikate (0-1 : 0-1 Beziehung)– Joins erzeugen keine INS, DEL

• Sondern (in gewisser Weise) nur UPD


1. Versuch: DSsmall - kleine Files

• Annahme: Hauptspeicher m >f1 oder >f2• Algorithmus (sei m>f1)

– F1 komplett in den Hauptspeicher lesen– F2 sequentiell lesen. Für Record r

• r∈F1: O=O∪(UPD r) (oder ignorieren, wenn keine Änderung)• r∉F1: O=O∪(INS r)• A[r]=true

– Abschließend: Alle Records r∈F1 mit A[r]=false: O=O∪(DEL r)

• Anzahl IO: • f1+f2

• Verbesserungen• F1 im Speicher sortieren – schnellerer Lookup


2. Versuch: DSnaive – Nested Loop

• Ab jetzt: m<<f1 und m<< f2• Algorithmus

– Record r aus F1 lesen– r in F2 suchen, dazu F2 sequentiell lesen– r nicht in F2: O=O∪(DEL r)– r verändert in F2 : O=O∪(UPD r)– r unverändert in F2 : ignorieren

• Problem?– INS wird nicht gefunden

• Lösung– Array A mit IDs aus F2 on-the-fly generieren– Für jedes r, das in F2 enthalten ist: A[r]=true– Abschließender Lauf über A; A[r]=false : (INS r)– Nachteil?

• Geht nur, wenn A in den Hauptspeicher passt• Sonst: Nested Loop in die Gegenrichtung laufen lassen


DSnaive – Verbesserungen

• Kosten?– Anzahl IO : f1*f2+INS-Erzeugung

• Verbesserungen?– Suche in F2 abbrechen, wenn r gefunden

• Verbessert die Laufzeit erheblich, Worst-Case Komplexität bleibt gleich

– Jeweils Partition mit Größe m von F1 laden• Verbesserung der Kosten auf f1/m*f2• Ähnlich zu Blocked-Nested-Loop


3. Versuch: DSsort – Sort-Merge

• Sortieren auf Sekundärspeicher– F1 in Partitionen Pi mit |Pi|=m lesen– Pi im Hauptspeicher sortieren und als Fi schreiben– Alle Fi mergen

• Dazu müssen wir vielleicht sehr viele Dateien öffnen• Kann man umgehen (hierarchisches, externes Sortieren)

• Sortiertes F2 aufheben für nächstes DS– Pro DS muss dann nur ein F (F2) sortiert werden

• Algorithmus– Sortierte F1‘ und F2 ‘ öffnen– Mergen (paralleles Lesen mit Skipping)

• Anzahl IO• f1+5*f2

1x f

1x f

2xf

f1 + f2


DSsort2 – Verbesserung

• Sortiertes F1 vorhanden– Vom letzten Berechnen

• Berechnung von O– F2 in Partitionen Pi mit |Pi|=m lesen– Pi im Hauptspeicher sortieren und als F2

i schreiben– Alle F2

i mergen und gleichzeitig mit F1 vergleichen • Dabei sortierte F2

i für das nächste Mal schreiben

Anzahl IO: f1+4*f2

1x f21x f2

f1 + 2*f2

Geht‘s noch besser ?


4. Versuch: DShash – Partitioned Hash

• Trick: Persistente Sortierung der Pi ist nicht wirklich notwendig

• Algorithmus– F2 in Partitionen Pi mit |Pi|=m/2 hashen

• Sicherstellen der Obergrenze für Platzbedarf der Hash-Buckets ist hier die Schwierigkeit

– F1 liegt noch partitioniert vom letzten Mal vor• Mit derselben Hashfunktion• Damit hat man genau zwei m/2 große Partitionen von

Records, die alle denselben Hashkey haben• Partitionen sind nicht sortiert

– Jeweils P1,i und P2,i parallel lesen und DS berechnen

• Anzahl IO: f1 + 3*f2

2x f2

f1+ f2


Warum nicht einfach ...

• … UNIX diff verwenden?– diff erwartet / beachtet Umgebung der Records– Hier: Records sind völlig ungeordnet

• … DSP in der Datenbank lösen?– Dreimaliges Lesen jeder Relation notwendig

• … je nachdem, wie gut die Datenbank optimiert …

INSERT INTO deltaSELECT ‚UPD‘, ...FROM F1, F2WHERE F1.K=F2.K AND K1.W≠F2.W

UNIONSELECT ‚INS‘, ...FROM F2WHERE NOT EXISTS ( ...)

UNIONSELECT ‚DEL‘, ...FROM F1WHERE NOT EXISTS ( ...)


Vergleich - Eigenschaften

IO Bemerkungen

DSnaiv f1 * f2 Außerdem INS-Datenstruktur notwendig

Dssmall f1 + f2 Nur für kleine Dateien

Dssort2 f1 + 4*f2

Dshash f1 + 3*f2 Gleichverteilende Hashfunktion notwendigPartitionsgröße schwierig zu schätzenAuf keinen Fall größer als 2*m/2 werdenGefahr, beträchtlich Speicher zu verschwenden


Weitere DS Verfahren

• Anzahl Partitionen / Runs größer als Filehandles des OS– Hierarchische externe Sortierverfahren

• Kompression– Files komprimieren• Größere Partitionen / Runs• Größere Chance, Vergleich in-memory durchzuführen• In Realität schneller (bei unserem Kostenmodell nicht)

• „Windows“ Algorithmus– Annahme: Files haben eine „unscharfe“ Ordnung– Merging mit sliding window über beide Files– Liefert u.U. redundante INS-DEL Paare– Anzahl IO: f1+f2


DS mit Zeitstempel

• Annahme: Records sind (K, A1,...,An,T)• T: Zeitstempel der letzten Änderung• Kann man das für einen O(f2)-Algorithmus ausnutzen?• Algorithmus

– Festhalten von des letzten Update jedes Files (T0)– F2 sequentiell lesen

• Nur Records mit T > T0 interessant

– Aber: INS oder UPD?– Weiteres Problem: DEL wird nicht gefunden

• Zeitstempel erspart nur Attributvergleich, aber nicht das Lesen der Records







Load

• Aufgabe– Effizientes Einbringen von externen Daten in DWH

• Kritischer Punkt– Load-Vorgänge blockieren unter Umständen die komplette DB

(Schreibsperre auf Faktentabelle)

• Möglichkeiten– Satzbasiert– BULK-Load– Anwendungsspezifische Schnittstellen

• Z.B. SAP

• Aspekte– Trigger, Integritätsconstraints, Indexaktualisierung– Update oder Insert?


Satzbasiert

• Standard-Schnittstellen: PRO*SQL, JDBC, ODBC, ...• Arbeitet im normalen Transaktionskontext• Trigger, Indexe und Constraints bleiben aktiv

– Manuelle Deaktivierung möglich

• Keine großräumigen Sperren– Satzsperren– Sperren können durch Zwischen-COMMIT verringert werden

• In Oracle ist das weniger performant – shadow blocks• Aber andere Prozesse erhalten wieder eine Chance

• Benutzung von Prepared Statements essentiell• Teilweise proprietäre Erweiterungen (Arrays) verfügbar


BULK Load

• DB-spezifische Erweiterungen zum Laden großer Datenmengen

• Läuft (meist) in speziellem Kontext– Oracle: sqlldr mit DIRECTPATH Option– Komplette Tabellensperre– Keine Beachtung von Triggern oder Constraints– Indexe werden erst nach Abschluss aktualisiert– Kein transaktionaler Kontext– Kein Logging (d.h. kein Recovery etc.)– Checkpoints zum Wiederaufsetzen– Rasend schnell

• Praxis: BULK Uploads


Beispiel: ORACLE sqlldr

LOAD DATAINFILE 'book.dat'REPLACE INTO TABLE book(book_title POSITION(1) CHAR(35),book_price POSITION(37) ZONED(4,2),book_pages POSITION(42) INTEGER,book_id "book_seq.nextval")

Controlfile

Quelle: Oracle 9.2, Dokumentation


BULK Load Beispiel

• Vielfältige Optionen– Behandlung von Ausnahmen (Badfile)– Einfache Datentransformationen– Checkpoints– Optionale Felder– Konditionales Laden in mehrere Tabellen– Konditionales Laden von Records– REPLACE oder APPEND – Paralleles Laden– ...


Direct Path

Quelle: Oracle 9.2, Dokumentation


Technik: Quelle – Arbeitsbereich - BasisDB

• BULK Load nur für ersten Schritt• Zweiter Schritt

– INSERT INTO ... SELECT ....– Logging ausschaltbar– Parallelisierbar

Quelle 2IMS

Quelle 1RDBMS Rel. Schema Q1

Rel. Schema Q2

Cube; Integriertes

Schema


Transformationen beim Laden der Daten

• Extraktion der Daten aus Quelle mit einfachen Filtern– Spaltenauswahl, Keine Reklamationen, ...

• Erstellen eines LOAD Files mit einfachen Konvertierungen– Zahl – String, Integer – Real, ...

• Transformation meist zeilenorientiert• Vorbereitung für den DB-spezifischen BULK-LOADER

while (read_line)parse_lineif (f[10]=2 & f[12]>0)write(file, f[1], string(f[4]), f[6]+f[7],...

...bulk_upload( file)


Transformationen in Staging Area

• Benutzt SQL• Effiziente mengenorientierte Berechnungen möglich• Vergleiche über Zeilen hinaus möglich

– Schlüsseleigenschaft, Namensduplikaterkennung, ...• Vergleiche mit Daten in Basisdatenbank möglich

– Duplikate, Plausibilität (Ausreißer), Konsistenz (Artikel-Ids)• Typisch: Tagging von Datensätzen durch Prüf-Regeln

UPDATE sales SET price=price/MWST;UPDATE sales SET cust_name=(SELECT cust_name FROM customer WHERE id=cust_id);

...UPDATE sales SET flag1=FALSE WHERE cust_name IS NULL;...INSERT INTO DWH SELECT * FROM sales WHERE f1=TRUE & f2=TRUE & ...


Quelle – Arbeitsbereich – Cube

Was macht man wo und wann ?

Quelle -> Arbeitsbereich Arbeitsbereich -> Cube

Art des Zugriffs Satzorientiert (read) Mengenorientiert (SQL)

Verfügbare Datenbasen

Eine Quelle Viele Quellen

Verfügbare Datensätze

Quellabhängig: Alle, alle Änderungen, Deltas

Zusätzlich Cube verfügbar (für Duplikate etc.)

Programmier-sprache

Skripte: Perl, AWK, ... oder 3GL

SQL, PL/SQL




• Schema- und Datenheterogenität- Datenkonflikte- Datentransformation



• Zwei Informationssysteme sind heterogen, wenn sie sich „irgendwie“ unterscheiden

• Verschiedene Ausprägungen von „irgendwie“ => verschiedene Arten von Heterogenität

• Informationsintegration = Überbrückung von Heterogenität• Erstellung eines homogenen Systems

• Materialisierte Integration

• Oder: Erweckung des Anscheins eines homogenen Systems• Virtuelle Integration

Heterogenität


Heterogenität

CRM-System

Produktions-planung

CRM-Systemder Tocherfirma

Lager-verwaltung

DWH


Übersicht

• Technische Heterogenität• Technische Realisierung des Datenzugriffs• Technische Unterschiede in der Darstellung

• Syntaktische Unterschiede• Unterschiede in der Darstellung• Gleiche Dinge syntaktisch verschieden repräsentieren

• Datenmodellheterogenität• Strukturelle Heterogenität

• Strukturelle Unterschiede in der Darstellung• Gleiche Dinge verschieden modellieren

• Semantische Heterogenität• Unterschiede in der Bedeutung von Namen (Schema und Daten)• Gleiches sagen, verschiedenes meinen (oder andersrum)


Syntaktische Heterogenität

• Unterschiedliche Darstellung desselben Sachverhalts• Dezimalpunkt oder –komma• Euro oder €• Comma-separated oder tab-separated• HTML oder ASCII oder Unicode• Notenskala 1-6 oder „sehr gut“, „gut“, …• Binärcodierung oder Zeichen• Datumsformate (12. September 2006, 12.9.2006, 9/12/2006, …)

• Überwindung in der Regel nicht problematisch• Umrechnung, Übersetzungstabellen, …


Datenmodellheterogenität

• Typische Datenmodelle• CSV• Relational (Tupel)• XML (XML)• Non-Standard (ASN.1)• Domänenspezifisch (ACeDB, EXPRESS, OPEN-GIS, …)• Proprietär (UniProt, PDB, …)

• Unterschied: Zum Austausch oder zur Speicherung• XML als Speicherformat?• Black-Box-Sicht – was zählt, ist was die Quelle liefert

• Erfordert Konvertierung• Spezielle Semantik geht unter Umständen verloren• XML-Schachtelung im relationalen Modell?


Beispiel

„Fast“ dasselbe in verschiedenen Datenmodellen


Strukturelle Heterogenität

• Allgemein• Gleiche Dinge in unterschiedlichen Schemata ausdrücken

• Andere Aufteilung von Attributen auf Tabellen• Fehlende / neue Attribute (wenn Intension nicht betroffen ist)• Setzt intensionale Überlappung voraus („gleiche Dinge“)

• Fast immer mit semantischer Heterogenität verbunden• Ausnahme: 1:1 Beziehungen

• Spezialfall: Schematische Heterogenität• Verwendung anderer Elemente eines Datenmodells• Kann nicht durch SQL überwunden werden


Beispiel

• Verursacht durch verschiedene Abbildungen eines objektorientierten Modells

• Gleichwertig?• Nur durch zusätzliche IC• S1: typ darf nur bestimmte

Werte annehmen• S1: umsatz darf nicht immer

gefüllt sein (abh. von typ)• S2: Gleiche film_id darf

nicht in verschiedenen Tabellen vorkommen

• …


person( Id, vorname, nachname, maennlich?, weiblich?)

maenner( Id, vorname, nachname)frauen( Id, vorname, nachname)

person( Id, vorname, nachname,geschlecht) Attribut vs. Wert

Relation vs. Wert

Relation vs. Attribut

Spezialfall: Schematische Heterogenität


Integrierte Sichten

• Verlangt viele Verrenkungen• Sicht muss angepasst werden, wenn neue Filmtypen

vorliegen• Datenänderungen bedingen Schemaänderungen• Das will man unbedingt vermeiden


Exotische Probleme?

• Oh nein• Schema zur Speicherung

von Filmen des Verleihers „XYZ“• ACTORS als VARCHAR• ORIGINAL – bedeutet

was?• TITLE, YEAR, … an drei

Stellen• ID-Räume DEUTSCH und

ORIGINAL getrennt?• …


Exotische Probleme?

• Schema von eachmovie(HP) • Eine einzige Tabelle für Filme• Zusätzliche Informationen

über Benutzer des Web-Systems

• Wenig Infos über Filme, aber Links zu weiteren Quellen

• GENRE sind boolscheAttribute

• …


Schema des Filmdienst

Eigene Tabelle für Filmtitel und Filmtiteltypen (?)

FILM-GENRE ist m:n

Personen können mehrere Namen haben (Aliase,

Künstlernamen)

FILM-PERSONEN ist m:n


Schema der IMDB

Beteiligte in eigenen Tabellen(FD hat Tabelle FUNKTIONEN)

ACTOR und ACTRESS in verschiedenen Tabellen


• Fremdwörterduden zu “Semantik”• „Teilgebiet der Linguistik, das sich mit den Bedeutungen

sprachlicher Zeichen und Zeichenfolgen befasst“• „Bedeutung, Inhalt eines Wortes, Satzes oder Textes“

• Programmiersprachen• Syntax: EBNF, Grammatiken• Semantik: Wirkungen der Ausführung; operationale Semantik,

Fixpunktsemantik, …

• Sprache• Syntaktisch falsch: „Ich esse Butterbrot ein“• Semantisch falsch: „Ich esse einen Schrank“

Semantik


Semantik von was?

Name

KonzeptRealweltliche Objekte

Intension Extension

repräsentiert


DB2:

Person( Id, Vorname, Nachname, Geschlecht)

DB1:

Angestellter( Id, Vorname, Name,männlich,weiblich)

Synonyme

• Verschiedene Namen für dasselbe Konzept– Und die selbe „Menge“ von Objekten


DB2:

Protein( Id, Sequenz, organismus, Funktion, …)

DB1:

Angestellter( Id, Vorname, Name, m, w, Funktion)

Sekr., Sachbearbeiter, Bereichsleiter, etc.

Transport, Katalyse, Signal, …

Homonyme

• Gleiche Namen für verschiedene Konzepte– Treten oft bei Überschreitung von Domänengrenzen auf


Probleme

• Mögliche Beziehungen zwischen Mengen A, B realweltlicher Objekte, die Konzepte c(A), c(B) repräsentieren• A=B (Äquivalenz): „semantische“ (echte) Synonyme

• Kreditinstitut, Bank (?)• Gibt es echte Synonyme?

• A⊆B (Inklusion): c(B) ist Hyperonym (Oberbegriff) zu c(A); c(A) ist Hyponym zu c(B)• Tochter ⊆ Kind

• A ∩ B ≠ ∅ ∧ A≠B (Überlappung): Schwierigster Fall• Küche-Kochnische; Haus-Gebäude; Regisseur-Schauspieler

• A ∩ B = ∅ (Disjunktion): nicht verwandte Begriffe (häufigster Fall) • Dose-Lohnsteuerjahresausgleich


Semantik: Woher nehmen?

• Was bestimmt die Semantik eines Namens?• Für Attributnamen

• Datentyp• Constraints (Schlüssel, FK, unique, CHECK, …)• Zugehörigkeit zu einer Relation• Andere Attribute dieser Relation• Beziehung der Relation zu anderen Relationen• Dokumentation• Vorhandene Werte• Wissen über den Anwendungsbereich • … • Der Kontext


Kontext

• Semantik eines Namens ändert sich mit dem Kontext• Beispiel

• Unternehmen A: angestellte( …)• Unternehmen B: mitarbeiter( …)• Mitarbeiter und Angestellte kann man als Synonyme betrachten• Aber: A.angestellte ∩ B.mitarbeiter = ∅

• Wenn Personen nicht in zwei Unternehmen beschäftigt sind

• Erst bei einem Merger von A und B werden A.angestellte und B.mitarbeiter zu Synonymen

• Sollten dann zu einer Tabelle integriert werden







Datenkonflikte

• Datenkonflikt • Zwei Duplikate haben unterschiedliche Attributwerte für ein

semantisch gleiches Attribut• Datenkonflikte entstehen

• Innerhalb eines Informationssystems (intra-source)• Bei der Integration mehrerer Informationssysteme (inter-

source)• Besser: Konflikte werden durch Integration aufgedeckt

• Voraussetzung• Existenz von Duplikaten auf Datenebene• Betrifft nur identifizierbare Objekte

• Keine Duplikate in Brückentabellen etc.• Duplikate müssen als solche erkannt werden

• Duplikaterkennung


amazon.deamazon.de

bol.debol.de

IDID

$5.99Moby DickHerman Melville0766607194

$3.98H. Melville0766607194

Konflikt kann auch mitNULL-Wert herrschen

Datenkonflikte - Beispiel


• Innerhalb eines Informationssystems• Fehlende Integritätsbedingungen oder Konsistenz-Checks• Freitextfelder, Kommentarfelder• Intensional redundante Schemata

• Fehlerhafte Normalisierung

• Falsche Einträge• Tippfehler, Übertragungsfehler, OCR-Fehler , …

• Sich ändernde Werte – Zeitbezug • Adressen, Einkommen, Preise, …

• …

Entstehung von Intra-Source-Konflikten


• Bei der Integration von Informationssystemen• Lokal konsistent aber global inkonsistent• Andere Datentypen („1“ versus „eins“)• Andere lokale Schreibweisen oder Konventionen

• Skalen (inch – cm) , Währungen, rechtliche Bedingungen (MWST), …

• Übertragungsfehler• Fehlerhafte Parser beim ETL

• Verwendung unterschiedlicher Standards• Produktnummern, Produktklassen, Berufsbezeichnungen, …

• Divergierende Aktualisierungszeitpunkte• …

Entstehung von Inter-Source-Konflikten


• Konfliktlösungsfunktionen• Zum Beispiel durch

• Präferenzordnung über Datenquellen • Aktualität, Trust (Vertrauen),

Verfügbarkeit, usw.

Auflösen

amazon.deamazon.de

bol.debol.de

IDID

$5.99Moby DickHerman Melville0766607194

$3.98H. Melville0766607194







Transformation

• Aufgabe– Umwandlung der Daten in eine „DWH-gerechte“ Form

• Form follows Function– Quellen: hoher Transaktionsdurchsatz– DWH: statistische Analysen

• Arten von Transformationen– Schematransformation– Datentransformation

• Transformationen möglich an zwei Stellen– Transformation der Quell-Extrakte zu Load-Files– Transformation von der Staging-Area in die Basis-DB


Schematransformationen

• Transformation von Daten eines Schemas in ein anderes Schema

• Unterschiedliche Modellierung– Unterschiedliche Normalisierung– Was ist Relation, was Attribut, was Wert ?– Aufteilung von Daten in Tabellen– Redundanzen aus Quellsystemen– Schlüssel

In SQL nur teilweise gut unterstützt– INSERT hat(te) nur eine Zieltabelle– SQL greift auf Daten zu, nicht auf Schemaelemente

• Keine Überbrückung schematischer Heterogenität

– Erfordert oftmals Programmierung


Beispiele

quelle(id, name, strasse, plz, umsatz)

kunde(id, name, umsatz)adresse(id, strasse, plz)

premium_k(id, name, umsatz)normal_k(id, name, umsatz)

Erfordert zwei Durchläufe der Quelltabelle- INSERT INTO kunde ... SELECT- INSERT INTO adresse ... SELECT

Erfordert zwei Durchläufe der Quelltabelle- INSERT INTO premium_k ...

SELECT ... WHERE umsatz>=X

- INSERT INTO normal_k ... SELECT ...WHERE umsatz<XYZ


Vermeidung redundanter INSERTs

• Multi-Table INSERT

• Alternative: PL/SQL (JDBC) Programmierung– Durchlauf der Quelltabelle mit Cursor– Conditionales Insert in Zieltabelle– Cursor meistens langsamer

INSERT ALL WHEN umsatz < XTHEN INTO normal_k

WHEN umsatz >= XTHEN INTO premium_k

ELSE INTO normal_k

SELECT id, name, umsatzFROM quelle;


Transformation bei schematischer Heterogenität

tab1( id, name, geschlecht)

tab2( id, name, M, W)

tab31( id, name)tab32( id, name)

• tab1 → tab2– INSERT INTO tab2 (id, name, ‚T‘, ‚F‘)

SELECT … geschlecht=‚maennlich‘– INSERT INTO tab2 (id, name, ‚F‘, ‚T‘)

SELECT … geschlecht=‚weiblich‘

• tab3 → tab1 – INSERT INTO tab1(id, name, ‚weiblich‘) ... SELECT ... FROM tab31– INSERT INTO tab1(id, name, ‚maennlich‘) ... SELECT ... FROM tab32

• Alle Werte müssen zum Zeitpunkt der Anfrageformulierung feststehen• Neues Geschlecht – Alle Queries ändern


Datentransformationen

• Syntax von Werten– Datum: 20. Januar 2003, 20.01.2003, 1/20/03– Codierungen: „1: Adr. unbekannt, 2: alte Adresse, 3: gültige

Adresse, 4: Adr. bei Ehepartner, ...“– Sprache– Abkürzungen/Schreibweisen: Str., strasse, Straße, ...– Datentypen: Real, Integer, String– Genauigkeit, Feldlänge, Nachkommastellen, ...– Skalen: Noten, Temperatur, Längen, Währungen,...

• Transformation in SQL recht gut unterstützt– Vielfältige Funktionen im Sprachstandard– Stringfunktionen, Decodierung, Datumsumwandlung, Formeln,

Systemvariable, ...– Funktionen in PL/SQL erstellen – in SQL verwenden


Beispiele

„Leser, Ulf“ „Leser“, „Ulf“„Naumann, Felix“ „Naumann“, „Felix“

INSERT INTO kunden( nachname, vorname)SELECT SubStr(name, 0, inStr(name,',')-1),

SubStr(name, inStr(name,',')+1) FROM rawdata;

„Leser“, 12/20/1954 „Leser“, 20.12.1954„Naumann“, 18/5/1954 „Naumann“, 18.05.1954

INSERT INTO kunden( name, geburtsdatum)SELECT name,

to_date( birthday, ‚MM/DD/YYYY‘) FROM rawdata;

„Müller“, ‚m‘, „sehr gut“ „Müller“ 0 1„Meier“, ‚w‘, „gut“ „Meier“ 1 2

INSERT INTO schueler(name, geschlecht, klasse)SELECT name,

decode( upper(sex), ‚M‘, 0, 1),decode( grade, ‚sehr gut‘, 1, ‚gut‘, 2, ...)

FROM rawdata;







Datenqualität

• Was ist Datenqualität?– „Fitness for use“– Anwendungsabhängig

• Folgen geringer Datenqualität – Falsche Prognosen– Verpasstes Geschäft

• DWH besonders anfällig für Qualitätsprobleme– Probleme akkumulieren

• Qualität der Ursprungsdaten (Eingabe, Fremdfirmen, ...)• Qualität der Quellsysteme (Konsistenz, Constraints, Fehler, ...)• Qualität des ETL-Prozess (Parsen, Transformieren, ...)

– Probleme treten erst bei Konsolidierung zu Tage– DWH unterstützt strategische Entscheidungen: Hohe

Folgekosten bei Fehlentscheidungen


Similarity Functions

Data Transformation

DataExtraction

Data Cleansing im DWH

Datenquellen

Lookuptables

Datascrubbing

Object Fusion

...

Data Warehouse

Data Loading

Datacleansing


Beispiel: Kampagnenmanagement

• Probleme im CRM eines Multi-Channel Vertriebs– Kunden doppelt geführt– Kunden falsch bewertet– Falsche Adressen– Haushalte / Konzernstrukturen nicht erkannt

• Folgen– „False positives“: Verärgerte Kunden durch mehrere /

unpassende Mailings– „False negatives“: Verpasste Gelegenheiten durch fehlende /

falsche Zuordnung (Cross-Selling)– Sinnlose Portokosten bei falschen Adressen– …


Aspekte von Datenqualität

1. Datenintegrität: Schlüssel, Fremdschlüssel, Integritätsbedingungen, ...

2. Fehlende Daten: Fehlende Attributwerte, fehlende Tupel3. Falsche Daten

– Objektiv falsch: Negative Preise, 32.13.2002, Buchstaben statt Ziffern– Widersprüchliche Werte aus unterschiedlichen Quellen

4. Formatfehler5. Unplausible Daten: Ausreißer, unerwartete Werte, ...6. Semantik von NULL Werten

– Wert möglich, aber unbekannt: Ist er Professor?– Wert möglich, existiert aber nicht: Er ist kein Professor!– Wert unmöglich: Kinder unter 18 haben keinen Titel

7. Duplikate8. Schlechte / fehlende Dokumentation9. …


Data Cleansing Operationen

• Ziel: Verbesserung der Datenqualität– Ergänzung fehlender Werte– Korrektur durch Lookup, Neuberechnen, Runden, ...– Erkennen und Löschen „unrettbarer“ Daten– Optimum kaum erreichbar: 80/20 Regel

• DQ muss (und kann) gemessen werden– DQ Metriken notwendig– Verbesserungen quantifizieren

• Data Cleansing– Domänenabhängiger Prozess– Produkte gibt es vor allem für Adressdaten


Data Cleansing Schritte [KRRT98]

1. Elementizing• Zerlegung der Werte• Erste Normalform

2. Standardizing• Schreibweisen, Vokabulare, Bezeichnungen, Titel

3. Verifying• Fehlende Werte, Cross-Matching, Plausibilität

4. Matching• Erkennen gleicher Objekte: Kunden, Lieferanten, ...

5. Household – Matching• Erkennen von Organisationen: Haushalte, Abteilungen, Firmen

6. Documenting


Nachvollziehbarkeit

• Daten müssen erklärbar sein – Anwender eines DWH: „Da fehlt ein Produkt im Report“– Analysewerkzeug fehlerhaft?– Report falsch?– Data Mart Definition falsch?– Basisdatenbank unvollständig?– ETL Prozeduren fehlerhaft?

• DC Aktionen müssen nachvollziehbar sein– Protokollieren der Aktionen durch alle Prozessschritte– Wiederholbarkeit aller Aktionen bei neuen Daten / Anfragen

• Schwierig: Unsystematische ad-hoc Aktionen• DC programmieren, keine manuellen Änderungen

– Mühsam, aber notwendig zur Unterstützung kontinuierlicher Prozesse





• Datenqualität– Data Cleansing– Duplikaterkennung und der Merge/Purge Algorithmus


Duplikate und Fusion

• Viele Fehler findet man erst durch Vergleich– Quelle 1: Hans Meyer, Frankfurter Allee 200– Quelle 2: Hans Meier, Frankfurter Alee 202

• Vergleich erfordert Identifikation verschiedener Repräsentationen desselben Objekts

• Fusion verschmilzt Duplikate zu einem Objekt– Nicht-redundante Darstellung: Jedes Objekt ist nur einmal im

Ergebnis repräsentiert– Homogene Darstellung: Jedes (einwertige) Attribut dieses

Objekts hat nur einen Wert– Datenfusion: Bestimmte diese Werte aus den Attributwerten der

Duplikate


Duplikate

• Relationale Welt– Duplikat = Zwei Tupel einer Relation die identische Werte in

allen Attributen besitzen

• Allgemein– Duplikat = Paar von Tupeln, die demselben Realweltobjekt

entsprechen („synonyme“ Objekte)

• Beispiele– Personen, Rechnungen, Lieferungen, Bestellungen, …

• Viele kommerzielle Tools– Vor allem im Bereich Customer Relationship Management (CRM)

• Duplikate von „Duplikaterkennung“– Record Linkage, Object Identification, Deduplication, Entity

Resolution, …


Einspielen neuer Objekte?

• Duplikatvermeidung: Vor dem Einfügen eines neuen Tupels prüfen, ob das Objekt schon vorhanden ist– Nehmen wir Namen als Schlüssel an

• Typischer Ablauf– FOR $new IN new_cust

SELECT count(*) INTO c FROM cust WHERE name=$new;if (c == 0)INSERT INTO cust VALUES( $new, …);

else// Daten ändernUPDATE cust SET … WHERE name=$new;

END FOR;

• Effizient?


MERGE

• Für jedes UPDATE zwei Suchen nach $new in cust• Besser: MERGE („Upsert“)

– MERGE INTO cust CUSING (

SELECT *FROM new_cust) N

ON (C.name = N.name)WHEN MATCHED THEN

UPDATE SET …WHEN NOT MATCHED THEN

INSERT VALUES (…);

• Benötigt für jedes existierende N-Tupel nur einen Zugriff auf cust– Cursor ist implizit definiert– Effizient, wenn Duplikaterkennung einfach ist (Schlüssel)


Duplikate: Das formale Problem

• Gegeben: Tupel T={t1,..,tm} mit Attributen A1,…,Ak– Kein „semantischer“ Schlüssel– Komplexere Modelle (Bäume, Graphen) möglich

• Tupel entsprechen Objekten O={o1,…,on}– Über die wissen wir meistens nichts, man kennt nur die Tupel– Manche der Tupel sind Duplikate

• Gesucht: eine Funktion dup: TxT→bool– dup gibt true zurück, wenn Tupel t1 und t2 demselben Objekt o

entsprechen• Eine Möglichkeit: dedup: T → N

– Jedem Tupel wird eine natürliche Zahl zugeordnet– Zwei Tupel bekommen dann und nur dann dieselbe Zahl

zugeordnet, wenn sie Duplikate sind– Berechnung eines identifizierenden Schlüssels


Transitivität

• Im strengen Sinne ist die Duplikateigenschaft transitiv– (dup(t1,t2)=true ∧ dup(t2,t3)=true) → dup(t1,t3)=true

• Im realen Leben muss man damit vorsichtig sein– Man nimmt an, dass Duplikate irgendwie ähnlich sind– Ähnlichkeit misst man durch eine Funktion sim: TxT → [0,1]– Verwend. eines Schwellwerts: dupsim(t1,t2)=true gdw. sim(t1,t2)>t– Aber: Ähnlichkeit ist mitnichten transitiv

• Meier, Meyer, Mayer, Bayer, Bayes, Bades, …• Meier, Meir, Mer, Er, R, …

• Gut überlegen, bevor man in Algorithmen Transitivität ausnutzt– Hängt ab vom Vertrauen in sim und in t– Kann Fehlerraten drastisch erhöhen


Genauigkeit der Duplikaterkennung

• Annahme: Verwendung von sim und Threshold t• Weitere Annahme: sim(t1,t2) korreliert mit der

Wahrscheinlichkeit, dass t1 und t2 Duplikate sind – sim irrt sich also meistens nicht oder nur ein wenig

• Dann hängt die Genauigkeit von dupsim von t ab• Hohes t

– Nahezu alle Duplikate, die man findet, sind auch welche– Aber man findet viele Duplikate nicht, weil sim nicht groß genug

ist

• Niedriges t– Man findet praktisch alle Duplikate– Aber man findet auch viele falsche Duplikate


Prinzipielles Vorgehen

• Annahme: Verwendung einer „guten“ sim• Um alle Duplikate zu finden, muss man alle Paare

miteinander vergleichen• Beim Vergleich geht man attributweise vor

– Schema Matching muss also schon vorher erfolgt sein

• Ähnlichkeit zweier Tupel setzt sich aus der Ähnlichkeit ihrer Attribute zusammen– Ggf mit Gewichtung der Attribute


Vom Attribut zum Tupel

• Theoretisch könnte man die Ähnlichkeit zweier Tupel als (gewichtetes) Mittel der Ähnlichkeiten ihrer Attributwerte definieren– Oder Verwendung von Fuzzy-Logik oder probablistischen

Modellen

• In der Praxis verwendet man eher Domänen- wissen, das man in Regeln kodiert


Die Sorted Neighborhood Methode

• Input– Tabelle mit N Tupeln– Ähnlichkeitsmaß

• Output – Cluster äquivalenter Tupel (= Duplikate)

• Problem: Viele Tupel– Es gibt O(n2) viele Tupelpaare– Das dauert zu lange– Außerdem: Nur sehr wenige sind tatsächlich Duplikate

• Idee– Partitioniere Tabelle geschickt – Tupelpaare werden nur noch innerhalb einer Partition gebildet


Sorted Neighborhood [HS98]

• Sorted Neighborhood Algorithmus– Sortiere Tupel so, dass Duplikate (hoffentlich) nahe beieinander liegen

• Dazu: Erzeuge einen Sortierschlüssel aus relevanten Attributen

– Merge-Phase: Fenster der Größe w über sortierte Liste schieben– Nur Tupel innerhalb eines Fensters vergleichen

• Man hat also überlappende Partitionen

– Purge-Phase: Duplikate werden verschmolzen, gelöscht, getagged, …

• Komplexität– n Tupel– Schlüsselerzeugung sei linear– Sortieren ist O(n*log(n))– Anzahl Vergleiche ist O(n*w)

• N „neue“ Tupel werden mit (w-1) Tupeln im Fenster verglichen

– Zum Vergleich: Naiver Ansatz war O(n2)


1. Schlüsselerzeugung

Vorname Nachname Adresse ID

Sal Stolpho 123 First St. 456780

Felix Naumann Hauptstr. 11 987654

Sal Stolfo 123 First Street 456789

Mauricio Hernandez 321 Second Ave 123456

Schlüssel

STOSAL123FRST456

HERMAU321SCND123

NAUFEL11HPTSTR987

STOSAL123FRST456

• Schlüsselerzeugung ist zentral für die Effektivität des Verfahrens– Ordnung der Schlüssel bestimmt die Partitionen– Schlechte Reihenfolge – schlechter Recall

• Leider ist überhaupt nicht klar, was ein guter Schlüssel zur Duplikaterkennung ist– Implizit erfolgt eine Priorisierung der Attribute durch den Aufbau des

Schlüssels– Wieder: Domänenwissen


Merge

Vorname Nachname Adresse ID

Mauricio Hernandez 321 Second Ave 123456

Felix Naumann Hauptstr. 11 987654

Sal Stolpho 123 First St. 456780

Sal Stolfo 123 First Street 456789

Schlüssel

HERMAU321SCND123

NAUFEL11HPTSTR987

STOSAL123FRST456

STOSAL123FRST456

• Regelbasierte Entscheidung auf Duplikat, z.B.– IF last_name(r1) = last_name(r2)

AND edit_distance(first_name(r1), firstname(r2)) < 5,AND address(r1) = address(r2)THEN dup(r1,r2)=true

– IF (ID(r1) = ID(r2) OR last_name(r1) = last_name(r2))AND address(r1) = address(r2)AND city(r1) = city(r2)AND (state(r1) = state(r2) OR zip(r1) = zip(r2))THEN dup(r1,r2)=true


Praktischer Aufwand

• Komplexität: O(n*log(n)+n*w)• Praktisch – IO. Mindestens drei Läufe notwendig

– Schlüssel erzeugen und speichern– Sortieren– Fenster schieben

• Man hält immer w Tupel im Speicher• Beim Verschieben fällt ein Tupel raus und eines kommt hinzu• Das neue Tupel wird mit w-1 Tupeln im Fenster vergleichen

– Praktisch sollte sich w also an der Blockgröße und der Größe des Hauptspeichers orientieren

• Nicht nur IO: Teure Operationen– Schlüssel erzeugen – große Schlüssel müssen viele Werte anfassen– Vergleichen – komplexe Regeln erfordern viele Einzelvergleiche – Die Merge-Phase dominiert typischerweise die Gesamtkosten


Problem

• Genauigkeit schlecht– Sortierkriterium bevorzugt immer Attribute– Sind erste Buchstaben wichtiger für Identität als letzte?– Ist Nachname wichtiger als Hausnummer?

• Lösung 1: Fenster vergrößern?– Dominanz eines Attributes bleibt gleich, aber Laufzeit

verschlechtert sich erheblich– Folge: keine nennenswerte Verbesserung bei kleiner

Vergrößerung und sehr hohe Kosten bei großer Vergrößerung

• Anderer Vorschlag?


Multipass Verfahren

• Lösung 2: Multipass– Merge-Purge mehrmals mit verschiedenen Schlüsseln laufen

lassen– Pro Lauf können kleine w und einfache Schlüssel verwendet

werden– Duplikatbeziehungen aller Läufe sind gleichwertig– Für k Läufe benötigt man ~(1+2*k) Scans der Tabelle

• Alle Schlüssel in einem Lauf berechnen

– Weniger effizientes, aber deutliches effektiveres Verfahren als Single-Pass


Bewertung

• Hier nur Merge betrachtet– Auch Purge nicht trivial!

• Parallelisierung– Sortierung parallelisierbar– Window-Vergleiche partitionierbar

• Merge/Purge in der Datenbank– Sortierungen müssen materialisiert werden– Gleichheitsregeln in PL/SQL implementieren


Literatur

• [Bae01] Baer: „ETL Processing with Oracle 9i“, Oracle Corp. White Paper, 2001

• [RD00] Rahm, Do: „Data Cleaning: Problems and Current Approaches“, IEEE Data Engineering Builletin, 2000

• [LGM96] Labio, W. and Garcia-Molina, H. (1996). "EfficientSnapshot Differential Algorithms for Data Warehousing". 22nd VLDB, Bombay, India. pp. 63-74.

• [LN06] Leser, U. and Naumann, F. (2006) „Informationsintegration“, dpunkt.verlag Heidelberg.

• [HS98] M. Hernandez and S. Stolfo „Real-world data is dirty: Datacleansing and the merge/purge problem“. Data Mining and Knowledge Discovery, 2(1): 9-37.

Documents

ETL: Extraction, Transformation, Load · Ulf Leser Wissensmanagement in der Bioinformatik ETL: Extraction, Transformation, Load Data Warehousing und Data Mining