Data Warehousing und Data Mining

Transkript

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

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 Ulf Leser: DWH und DM, Sommersemester

3 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 Ulf Leser: DWH und DM, Sommersemester

4 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 Ulf Leser: DWH und DM, Sommersemester

5 Beispiel Member: Unique Names oder Navigation SELECT {Wein, Bier, Limo, Saft} ON COLUMNS {[2000], [1999], [1998].[1], [1998].[2]} on ROWS FROM Sales WHERE (Measures.Menge, Region.Germany) Auswahl des Fakt Menge Beschränkung auf Werte in BRD Verschiedene Klassifikationsstufen in einer Dim möglich Wein Bier Limo Saft Implizite Summierung Ulf Leser: DWH und DM, Sommersemester

6 Navigation in den Hierarchien SELECT {Prodgroup.MEMBERS, [Becks Bier].PARENT} ON COLUMNS {Year.MEMBERS} on ROWS FROM Sales WHERE (Measures.Menge) Navigationsfunktionen MEMBERS: Knoten einer Klassifikationsstufe CHILDREN: Kinderknoten eines Klassifikationsknoten PARENT: Vaterknoten eines Klassifikationsknoten LASTCHILD, FIRSTCHILD, NEXTMEMBER, LAG, LEAD... DESCENDENTS: Rekursives Absteigen Ulf Leser: DWH und DM, Sommersemester

7 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 Ulf Leser: DWH und DM, Sommersemester

8 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 P WHERE P.pg_name= Wein AND SELECT P.product_id T.month_id, = S.product_id sum(amount*price) GROUP BY FROM T.day_id sales S, product P, time T WHERE P.pg_name= Wein AND P.product_id SELECT T.year_id, = S.product_id sum(amount*price) AND T.day_id FROM = S.day_id sales S, product P, time T GROUP BY T.month_id WHERE P.pg_name= Wein AND P.product_id = S.product_id AND T.day_id = S.day_id GROUP BY T.year_id Ulf Leser: DWH und DM, Sommersemester

9 ROLLUP Beispiel SELECT FROM WHERE GROUP BY T.year_id, T.month_id, T.day_id, sum(...) sales S, time T T.day_id = S.day_id ROLLUP(T.year_id, T.month_id, T.day_id) 1997 Jan Jan Jan Jan ALL Feb March ALL ALL ALL Jan ALL ALL ALL... ALL... ALL Ulf Leser: DWH und DM, Sommersemester

10 Multidimensionale Aggregation Verkäufe nach Produktgruppen und Jahren Gesamt Weine Biere Gesamt sum()... GROUP BY pg_id, year_id sum()... GROUP BY pg_id sum()... GROUP BY year_id sum() Wie viele Queries sind notwendig? Ulf Leser: DWH und DM, Sommersemester

11 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... Bier Charlottenburg ALL... Bier ALL Wein ALL ALL Kreuzberg ALL Charlottenburg Bier ALL ALL... Wein ALL ALL... ALL ALL ALL ALL ALL Kreuzberg ALL... ALL Charlottenburg ALL... ALL ALL ALL... Ulf Leser: DWH und DM, Sommersemester

12 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 Ulf Leser: DWH und DM, Sommersemester

13 OVER() mit lokaler Partitionierung OVER() gestattet die Angabe attributlokaler Partitionen Ausgabe der Summe Verkäufe eines Tages im Verhältnis zu Verkäufen des Jahres SELECT FROM sales S, GROUP BY S.day_id; day_id 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 day_sum day_id day_sum year_sum Ratio SQL Funktion YEAR() Ulf Leser: DWH und DM, Sommersemester

14 Veranschaulichung S.day_id, sum(amount), sum(amount) OVER(PARTITION BY YEAR(S.day_id)) GROUP BY S.day_id (S.day_id, sum(amount)) FROM sales S GROUP BY YEAR(day_id) Ulf Leser: DWH und DM, Sommersemester

15 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_sum FROM sales S, GROUP BY S.day_id; Ulf Leser: DWH und DM, Sommersemester

16 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 Ulf Leser: DWH und DM, Sommersemester

17 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 Ulf Leser: DWH und DM, Sommersemester

18 Der ETL Prozess Qrt l. Qrt l. Qrt l. Qrt l. Extraction Transformation Load Ulf Leser: DWH und DM, Sommersemester

19 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 Ulf Leser: DWH und DM, Sommersemester

20 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 Ulf Leser: DWH und DM, Sommersemester

21 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 Ulf Leser: DWH und DM, Sommersemester

22 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 Ulf Leser: DWH und DM, Sommersemester

23 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 Ulf Leser: DWH und DM, Sommersemester

24 Datenversorgung Quelle... Technik Aktualität DWH Belastung DWH Belastung Quellen... erstellt periodisch Exportfiles Reports, Snapshots Je nach Frequenz Eher niedrig Eher niedrig... pushed jede Änderung Trigger, Maximal Hoch Hoch Changelogs, Replikation... erstellt Extrakte auf Anfrage (Poll) Vor Benutzung Sehr schwierig Maximal Medium Medium Anwendungsgesteuert Je nachdem Je nach Frequenz Je nach Frequenz Je nach Frequenz Ulf Leser: DWH und DM, Sommersemester

25 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 Ulf Leser: DWH und DM, Sommersemester

26 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-Files für sehr große Dateien Ulf Leser: DWH und DM, Sommersemester

27 Das Differential Snapshot Problem (DSP) Quelle liefert Snapshots als Files F i Einfache und identische Struktur mit Attributen A 1, A n Jedes Tupel hat einen Schlüssel k File = ungeordnete Menge von Records (K, A 1,... A n ) Definition Gegeben zwei Dateien F 1, F 2 gleicher Struktur mit f 1 = F 1, f 2 = F 2. Das Differential Snapshot Problem (DSP) besteht darin, die kleinste Menge O={INS, DEL, UPD}* zu finden für die gilt: O(F 1 ) = F 2 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 O 1 ={ (ins(x)),(del(x)) } {} Ulf Leser: DWH und DM, Sommersemester

28 Szenario Alter Snapshot K104, k,k,... K4, t,r,... K202, a,a,... K102, p,q,... INS K103 INS K3 DEL K4 UPD K202:... Neuer Snapshot K103, t,h,... K104, k,k,... K102, p,q,... K3, t,r,... K202, b,b,... DSP - Algorithmus DWH Ulf Leser: DWH und DM, Sommersemester

29 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 Ulf Leser: DWH und DM, Sommersemester

30 1. Versuch: DS small - kleine Files Annahme: Hauptspeicher m >f 1 oder >f 2 Algorithmus (sei m>f 1 ) F 1 komplett in den Hauptspeicher lesen F 2 sequentiell lesen. Für Record r r F 1 : O=O (UPD r) (oder ignorieren, wenn keine Änderung) r F 1 : O=O (INS r) A[r]=true Abschließend: Alle Records r F 1 mit A[r]=false: O=O (DEL r) Anzahl IO: f 1 +f 2 Verbesserungen F 1 im Speicher sortieren schnellerer Lookup Ulf Leser: DWH und DM, Sommersemester

31 2. Versuch: DS naive NestedLoop Ab jetzt: m<<f 1 und m<< f 2 Algorithmus Record r aus F 1 lesen r in F 2 suchen, dazu F 2 sequentiell lesen r nicht in F 2 : O=O (DEL r) r verändert in F 2 : O=O (UPD r) r unverändert in F 2 : ignorieren Problem? INS wird nicht gefunden Lösung Array A mit IDs aus F 2 on-the-fly generieren Für jedes r, das in F 2 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 Ulf Leser: DWH und DM, Sommersemester

32 DS naive Verbesserungen Kosten? Anzahl IO : f 1 *f 2 +INS-Erzeugung Verbesserungen? Suche in F 2 abbrechen, wenn r gefunden Verbessert die Laufzeit erheblich, Worst-Case Komplexität bleibt gleich Jeweils Partition mit Größe m von F 1 laden Verbesserung der Kosten auf f 1 /m*f 2 Ähnlich zu Blocked-Nested-Loop Ulf Leser: DWH und DM, Sommersemester

33 3. Versuch: DS sort Sort-Merge Sortieren auf Sekundärspeicher F 1 in Partitionen P i mit P i =m lesen P i im Hauptspeicher sortieren und als F i schreiben Alle F i mergen Dazu müssen wir vielleicht sehr viele Dateien öffnen Kann man umgehen (hierarchisches, externes Sortieren) Sortiertes F 2 aufheben für nächstes DS Pro DS muss dann nur ein F (F 2 ) sortiert werden Algorithmus Sortierte F 1 und F 2 öffnen Mergen (paralleles Lesen mit Skipping) Anzahl IO 1x f 1x f 2xf f 1 + f 2 f 1 +5*f 2 Ulf Leser: DWH und DM, Sommersemester

34 DS sort2 Verbesserung Sortiertes F 1 vorhanden Vom letzten Berechnen Berechnung von O F 2 in Partitionen P i mit P i =m lesen P i im Hauptspeicher sortieren und als F i 2 schreiben Alle F i 2 mergen und gleichzeitig mit F 1 vergleichen Dabei sortierte F i 2 für das nächste Mal schreiben 1x f 2 1x f 2 f 1 + 2*f 2 Anzahl IO: f 1 +4*f 2 Geht s noch besser? Ulf Leser: DWH und DM, Sommersemester

35 4. Versuch: DS hash Partitioned Hash Trick: Persistente Sortierung der P i ist nicht wirklich notwendig Algorithmus F 2 in Partitionen P i mit P i =m/2 hashen Sicherstellen der Obergrenze für Platzbedarf der Hash-Buckets ist hier die Schwierigkeit F 1 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 P 1,i und P 2,i parallel lesen und DS berechnen Anzahl IO: f 1 + 3*f 2 2x f 2 f 1 + f 2 Ulf Leser: DWH und DM, Sommersemester

36 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 delta SELECT UPD,... FROM F1, F2 WHERE F1.K=F2.K AND K1.W F2.W UNION SELECT INS,... FROM F2 WHERE NOT EXISTS (...) UNION SELECT DEL,... FROM F1 WHERE NOT EXISTS (...) Ulf Leser: DWH und DM, Sommersemester

37 Vergleich - Eigenschaften IO Bemerkungen DS naiv f 1 * f 2 Außerdem INS-Datenstruktur notwendig Ds small f 1 + f 2 Nur für kleine Dateien Ds sort2 f 1 + 4*f 2 Ds hash f 1 + 3*f 2 Gleichverteilende Hashfunktion notwendig Partitionsgröße schwierig zu schätzen Auf keinen Fall größer als 2*m/2 werden Gefahr, beträchtlich Speicher zu verschwenden Ulf Leser: DWH und DM, Sommersemester

38 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: f 1 +f 2 Ulf Leser: DWH und DM, Sommersemester

39 DS mit Zeitstempel Annahme: Records sind (K, A 1,...,A n,t) T: Zeitstempel der letzten Änderung Kann man das für einen O(f 2 )-Algorithmus ausnutzen? Algorithmus Festhalten von des letzten Update jedes Files (T 0 ) F 2 sequentiell lesen Nur Records mit T > T 0 interessant Aber: INS oder UPD? Weiteres Problem: DEL wird nicht gefunden Zeitstempel erspart nur Attributvergleich, aber nicht das Lesen der Records Ulf Leser: DWH und DM, Sommersemester

40 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 Ulf Leser: DWH und DM, Sommersemester

41 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 Aspekte Z.B. SAP Trigger, Integritätsconstraints, Indexaktualisierung Update oder Insert? Ulf Leser: DWH und DM, Sommersemester

42 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 Ulf Leser: DWH und DM, Sommersemester

43 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 Ulf Leser: DWH und DM, Sommersemester

44 Beispiel: ORACLE sqlldr Controlfile LOAD DATA INFILE '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" ) Quelle: Oracle 9.2, Dokumentation Ulf Leser: DWH und DM, Sommersemester

45 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... Ulf Leser: DWH und DM, Sommersemester

46 Direct Path Quelle: Oracle 9.2, Dokumentation Ulf Leser: DWH und DM, Sommersemester

47 Technik: Quelle Arbeitsbereich - BasisDB Quelle 1 RDBMS Quelle 2 IMS Rel. Schema Q1 Rel. Schema Q2 Cube; Integriertes Schema BULK Load nur für ersten Schritt Zweiter Schritt INSERT INTO... SELECT... Logging ausschaltbar Parallelisierbar Ulf Leser: DWH und DM, Sommersemester

48 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_line if (f[10]=2 & f[12]>0) write(file, f[1], string(f[4]), f[6]+f[7], bulk_upload( file) Ulf Leser: DWH und DM, Sommersemester

49 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 &... Ulf Leser: DWH und DM, Sommersemester

50 Quelle Arbeitsbereich Cube Was macht man wo und wann? Quelle -> Arbeitsbereich Arbeitsbereich -> Cube Art des Zugriffs Satzorientiert (read) Mengenorientiert (SQL) Verfügbare Datenbasen Verfügbare Datensätze Programmiersprache Eine Quelle Quellabhängig: Alle, alle Änderungen, Deltas Skripte: Perl, AWK,... oder 3GL Viele Quellen Zusätzlich Cube verfügbar (für Duplikate etc.) SQL, PL/SQL Ulf Leser: DWH und DM, Sommersemester

51 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 Ulf Leser: DWH und DM, Sommersemester

52 Heterogenität 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 Ulf Leser: DWH und DM, Sommersemester

53 Heterogenität DWH CRM- System Produktionsplanung Lagerverwaltung CRM-System der Tocherfirma Ulf Leser: DWH und DM, Sommersemester

54 Ü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) Ulf Leser: DWH und DM, Sommersemester

55 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, , 9/12/2006, ) Überwindung in der Regel nicht problematisch Umrechnung, Übersetzungstabellen, Ulf Leser: DWH und DM, Sommersemester

56 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? Ulf Leser: DWH und DM, Sommersemester

57 Beispiel Fast dasselbe in verschiedenen Datenmodellen Ulf Leser: DWH und DM, Sommersemester

58 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 Ulf Leser: DWH und DM, Sommersemester

59 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 Ulf Leser: DWH und DM, Sommersemester

60 Spezialfall: Schematische Heterogenität maenner( Id, vorname, nachname) frauen( Id, vorname, nachname) Relation vs. Attribut Relation vs. Wert person( Id, vorname, nachname, maennlich?, weiblich?) person( Id, vorname, nachname, geschlecht) Attribut vs. Wert Ulf Leser: DWH und DM, Sommersemester

61 Integrierte Sichten Verlangt viele Verrenkungen Sicht muss angepasst werden, wenn neue Filmtypen vorliegen Datenänderungen bedingen Schemaänderungen Das will man unbedingt vermeiden Ulf Leser: DWH und DM, Sommersemester

62 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? Ulf Leser: DWH und DM, Sommersemester

63 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 boolsche Attribute Ulf Leser: DWH und DM, Sommersemester

64 FILM-PERSONEN ist m:n Schema des Filmdienst FILM-GENRE ist m:n Personen können mehrere Namen haben (Aliase, Künstlernamen) Eigene Tabelle für Filmtitel und Filmtiteltypen (?) Ulf Leser: DWH und DM, Sommersemester

65 Schema der IMDB ACTOR und ACTRESS in verschiedenen Tabellen Beteiligte in eigenen Tabellen (FD hat Tabelle FUNKTIONEN) Ulf Leser: DWH und DM, Sommersemester

66 Semantik 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 Ulf Leser: DWH und DM, Sommersemester

67 Semantik von was? Name Extension Intension Realweltliche Objekte repräsentiert Konzept Ulf Leser: DWH und DM, Sommersemester

68 Synonyme Verschiedene Namen für dasselbe Konzept Und die selbe Menge von Objekten DB1: Angestellter( Id, Vorname, Name,männlich,weiblich) DB2: Person( Id, Vorname, Nachname, Geschlecht) Ulf Leser: DWH und DM, Sommersemester

69 Homonyme Gleiche Namen für verschiedene Konzepte Treten oft bei Überschreitung von Domänengrenzen auf DB1: Sekr., Sachbearbeiter, Bereichsleiter, etc. Angestellter( Id, Vorname, Name, m, w, Funktion) DB2: Protein( Id, Sequenz, organismus, Funktion, ) Transport, Katalyse, Signal, Ulf Leser: DWH und DM, Sommersemester

70 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 Ulf Leser: DWH und DM, Sommersemester

71 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 Ulf Leser: DWH und DM, Sommersemester

72 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 Ulf Leser: DWH und DM, Sommersemester