Preview of “02 architektur” - db.inf.uni-tuebingen.de · •Ziel: Aktualisierung der...

Data Warehouses

Sommersemester 2011

Melanie [email protected]

Lehrstuhl für Datenbanksysteme, Universität Tübingen

Kapitel 2Architektur

2

• Bestandteile eines DW

• Konfigurationen

• ETL

Data Warehouses | SS 2011 | Melanie Herschel | Universität Tübingen

Die Vogelperspektive

3

DB2 Oracle XML

DataMart 1

DataMart 2

DataMart 3

Datenquellen

Data Warehouse (DW)

Basisrelationen

Teilsichten über DW

• Heterogene und autonome Datenquellen.

• Data Warehouse sammelt Daten der Quellen und speichert diese “gebündelt” in Basisrelationen.

• Verschiedene Sichten (Data Marts) über die Relationen im Data Warehouse werden Anwendungen zur Verfügung gestellt.

Data-Warehouse-System


Detailansicht

4

Meta-daten

DB2 Oracle XML

DataMart 1

DataMart 2

DataMart 3

Datenquellen

Data Warehouse (DW)

Basisrelationen



Datenbeschaffung & Transformation

(staging area)

Daten-konsolidierung

Daten-bereitstellung

Datenanalyse

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Nach Wolfgang Lehner, Datenbanktechnologie fürData Warehouse Systeme, dpunkt.verlag, 2003


Bestandteile eines Data-Warehouse-SystemsQuellsysteme

• Systeme und Dateinen, die als Datenlieferenaten dienen.

• Meist sehr heterogen (siehe Klassifikation auf folgender Folie)

• Zugriff durch das Data-Warehouse-System

• Push: Quelle erzeugt regelmäßig Extrakte

• Pull: Data-Warehouse stößt Zugriff an

• Jede Quelle muss individuell behandelt werden.

5

DB2 Oracle XML

DataMart 1

DataMart 2

DataMart 3

Datenquellen

Data Warehouse (DW)

Basisrelationen





6

DB2 Oracle XML

DataMart 1

DataMart 2

DataMart 3

Datenquellen

Data Warehouse (DW)

Basisrelationen



Heterogenität

Syntaktische Heterogenität

Strukturelle Heterogenität

Semantische Heterogenität

Datenmodell SchematischHardware Software Schnittstellen Namenskonflikte Identität Datenkonflikte

•Bandbreite•CPU•Hauptspeicher•...

•OS•Protokolle•Sicherheit•...

•HTLM•SQL•XQuery•...

•Relational•OO•...

•Attribut vs. Wert•Relation vs. Wert•Attributbenennung•Normalisierung•Schachtelung•...

•Konzept•Synonym•Homonym•Einheiten•...

•Unterschiedliche Darstellung des gleichen Objekts

•Fehlende Daten•Wiedersprüchliche Daten



7

DB2 Oracle XML

DataMart 1

DataMart 2

DataMart 3

Datenquellen

Data Warehouse (DW)

Basisrelationen



Quellsystem 1

p_id Name Preis Typ

1 Matrix 9.99 Blue Ray

2 Der Pate $12.45 DVD

3 Dirty Dancing 7.50 Video

... ... ...

p_id wagen_id anzahl datum

1 234 2 1/1/2010

2 234 1 1/1/2010

2 456 0 2/2/2010

3 456 1 3/3/2011

... ... ... ...

Produkt

Verkauf

Quellsystem 2

kennung Beschreibung dvd video blueray

P1 The Matrix nein nein ja

P2 The Godfather ja nein nein

P3 Moulin Rouge nein nein ja

... ... ...

lid p_kennung lagerbestand letzte_beschaffung

1 PDVD1 50 1.4.10

1 PDVD2 20 1.3.10

2 PDVD2 -10 1.1.10

2 PDVD3 30 1.2.10

... ... ... ...

Produkt

Lagerbestand

Gegeben die oben beschriebenen Quellsysteme 1 und 2, welche Arten der Heterogenität erkennen Sie?


Bestandteile eines Data-Warehouse-SystemsDatenbeschaffung und Transformation

• Ziel: Integration der extrahierten Daten

• Relevante lokale Daten (Daten aus den Datenquellen) werden physisch in die Kontrollsphäre des Data Warehouse gebracht (load time).

• Säuberung und Anpassung der Daten (Transformation)

• Prüfung ausreichender Datenqualität

• Zusammenführung lokaler Daten zu einem globalen Gesamtbild

• Zwischenergebnisse werden nur temporär gespeichert.

• Der Bereich zur Datenbeschaffung und Transformation wird oft staging area genannt.

8

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .


Bestandteile eines Data-Warehouse-SystemsDatenbeschaffung und Transformation

9

Transformation der Datenbestände aus den Quellsystemen 1 und 2

id Name Preis Währung typ

1 The Matrix 9.99 EUR Blue Ray

2 The Godfather 12.45 USD DVD

3 Dirty Dancing 7.50 EUR Video

4 Moulin Rouge NULL NULL Blue Ray

id wagen_id anzahl datum

1 234 2 1/1/2010

2 234 1 1/1/2010

3 456 1 3/3/2011

... ... ... ...

Produkt_Integriert

Verkauf

lid id lagerbestand letzte_beschaffung

1 1 50 1/4/2010

1 2 20 1/3/2010

2 2 0 1/1/2010

2 4 30 1/2/2010

... ... ... ...

Lagerbestand

•Schemaebene•Neues id Feld• Name = Beschreibung•Preis aufgeteilt in Preis + Währung•Typdarstellung aus Quelle 1 übernommen

•Datenebene•Werte für id Feld generiert•Identität von Filmen überprüft•Englische Namen übernommen•Preis von Währungszeichen befreit•Währung aus Preisangaben abgeleitet•typ aus Quelle 1 und 2 integriert

•Schemaebene•Quelle 1 einziger Datenlieferant für Verkauf --> Schema übernommen (bis auf id)

•Datenebene•Werte für id Feld anhand von Produkt.id generiert•Irrelevante Tupel (anzahl = 0) gefiltert

•Schemaebene•Quelle 2 einziger Datenlieferant für Lagerbestand --> Schema übernommen (bis auf id)

•Datenebene•Werte für id Feld anhand von Produkt.id generiert•Datumsformat angepasst•Unzulässige Werte (lagerbestand < 0) korrigiert

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .


Bestandteile eines Data-Warehouse-SystemsDatenkonsolidierung

• Ziel: Aktualisierung der konsolidierten Datenbasis im Data Warehouse

• Hinzufügen der neu integrierten Daten zum Datenbestand das Data Warehouse (refresh time)

• Schema

• Schemaentwurf nach Regeln des relationalen Schemaentwurfs (Normalisierung, Vermeidung von Redundanz)

• Oft Ergebnis der Schemaintegration der einzelnen Quellsysteme

10

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Konsolidierte Datenbasis

•Realisiert eine organisationsweite, anwendungsunabhängige Speicherung aller relevanten Detaildaten.

•Gibt somit einen Überblick über Vorgänge und Zustände einer Organisation, die im Rahmen des Data-Warehouse-Konzepts abgespeichert werden.



• Schemaintegration aufgrund von Heterogenität problematisch, insb. aufgrund der Semantik von Schemaelementen.

• Was speichert die Relation KVMU?

• Was speichert das Feld Produkt.ANS?

• Was speichert das Feld Name? (Filmtitel, Schauspielername, Untertitel, ...)

• Was ist Preis? (Steuer, Währung, Rabatte, ...?)

• Schemaintegration bisher nicht automatisierbar, sondern semi-automatisch und interaktiv.

• Aktives Forschungsfeld: identifizieren von Korrespondenzen zwischen Schemaattributen (schema matching) (z.B. Name = Beschreibung).

11

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Schemaintegration

Gegeben eine Menge von Quellen Qi mit jeweiligen Schemata Si, so finde ein Schema

S = ∪Si, wobei es sich bei ∪ um eine semantische Vereinigung handelt.



12

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Beispiel eines normalisierten Schemas einer konsolidierten Datenbasis

Ulf Leser: DWH und DM, Sommersemester 2007 28

Beispiel: Normalisiertes Schema

line_itemorder_idproduct_idamountsingle_price

orderidsession_idsupply_idtotal_amountday

iddaymonth_id

monthidMonthyear_id

yearidyear

supply_stationidregion_id

productidproductgroup_id

productgroupidname

regionidname

customeridnamecust_class

discountcustomer_idproductg_iddiscount

sessionidcust_idday_idtime

order_statusorder_idsupply_idstatus


Bestandteile eines Data-Warehouse-SystemsDatenbereitstellung

13

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

• Probleme der konsolidierten Datenbasis

• Viele Relationen, unübersichtliches Schema

• Viele Joins in (fast) allen Queries notwendig, Optimierung schwierig

• Joins lenken vom Analyseziel ab – man möchte lieber mit Begriffen des Geschäftsprozesses umgehen

• Lösung: multidimensionale Modellierung in dispositiver Datenbasis



• Ziel der Datenbereitstellung: Aktualisierung der dispositiven Datenbasis, abgeleitet von der konsolidierten Datenbasis.

• Schemaentwurf für Anwendung optimiert (Star/Snowflake-schema)

• Detailgrad der Daten ebenfalls der Anwendung angepasst.

• Möglich sind auch verschiedene Detailstufen (Aggregation), die explizite Redundanz erzeugen.

14

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Dispositive Datenbasis

Die dispositive Datenbasis hält Daten in einer anwendungsorientierten und optimierten Form für geplante Auswertungsszenarien vor.



15

Beispiel eines normalisierten Schemas einer konsolidierten Datenbasis

Ulf Leser: DWH und DM, Sommersemester 2007 29

Multidimensionales Schema

line_itemorder_idproduct_idamountsingle_pricediscount_rate

supplyidregion

productidnameproduct_group

customeridnamecust_class

timeiddaymonthyear

• Technische Informationen raus (Session)• Nur abgeschlossene Bestellungen aufnehmen (Orderstatus)• Zusammenfassen (discount_rate)• Denormalisieren (überall)• Konzentration auf Businessobjekte und -prozesse

Star schema

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .


Bestandteile eines Data-Warehouse-SystemsDatenanalyse

• Bereich zur Datenanalyse umfasst alle Datenbasen und Systeme, die zur konkreten Interaktion mit dem Nutzer / Auswertungsanwendungen dienen.

• Spezialisierte Sichten über dispositive Datenbasis, sogenannte data marts, werden hier für bestimmte Anwendungen bereitgestellt.

• Sichten in klassischen relationalen Datenbanken: gespeicherte Anfragen, Anfrageausführung bei jeder Verwendung der Sicht.

• Da wiederholter Zugriff auf große dispositive Datenbasis zu teuer, verwenden Data Warehouses materialisierte Sichten, die Anfrageergebnis speichern.

• Interessante Probleme

• Aktualisierung der Sichten (view maintenance)

• Auswahl der Sichten, da eine Sicht für mehr als nur eine Analyseanfrage nutzbar (view selection)

16

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .


Bestandteile eines Data-Warehouse-SystemsDatenanalyse

17

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Beispiel möglicher Sichten

Fallen Ihnen Analyseanfragen ein, die Sie ebenfalls anhand dieser beiden Sichten beantworten können?

customer_class product_name product_class count

Class 1 The Matrix Blue Ray 5000

Class 2 The Matrix Blue Ray 2000

Class 1 Dirty Dancing Video 1000

Class 2 Dirty Dancing Video 6000

... ... ... ...

customer_class_per_product product_sales_per_region

region product_name product_class income

Europe The Matrix Blue Ray 50,000

North America The Matrix Blue Ray 100,000

Asia The Matrix Blue Ray 90,000

Europe The Godfather DVD 150,000

... ... ... ...


Bestandteile eines Data-Warehouse-SystemsMetadata Repository

• Ziele

• Nachvollziehbarkeit der Prozesse

• Vermeidung von Fehlinterpretationen

• Technische Beschreibung des Data Warehouse

• Anforderungen an Metadaten-Verwaltung / Repository

• Vollständige Bereitstellung aller relevanten Metadaten auf aktuellem Stand

• Flexible Zugriffsmöglichkeiten (DB-basiert) über mächtige Schnittstellen

• Versions- und Konfigurationsverwaltung

• Unterstützung für technische und fachliche Aufgaben und Nutzer

• aktive Nutzung für DW-Prozesse (Datentransformation, Analyse)

18

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

[Prof. Rahm, Universität Leipzig, VL Data Warehouses]


Bestandteile eines Data-Warehouse-SystemsMetadata Repository - Implementierung

• Realisierungsformen

• Werkzeugspezifisch: fester Teil von Werkzeugen

• Allgemein einsetzbar: generisches und erweiterbares Repository-Schema (Metadaten-Modell)

• Zahlreiche proprietäre Metadaten-Modelle

• Standardisierungsbemühungen, z.B. das Common Warehouse Metamodel (CWM) der Object Management Group (OMG)

• Häufig Integration von bzw. Austausch zwischen dezentralen Metadaten-Verwaltungssystemen notwendig.

19

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .



Data-Warehouse-System(besprochene Komponenten)

Bestandteile eines Data-Warehouse-SystemsMetadata Repository - Arten von Metadaten

20

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .




• Technische Metadaten

• Informationen, die beim Aufbau und beim Betrieb des Data-Warehouse-Systems anfallen.

• Zur Laufzeit gesammelte Protokollinformationen, die Auskunft darüber geben, wann welche Transformation stattgefunden hat und mit welchem Zustand sie terminiert ist.

21

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Beispiele für technische Metadaten

•Technische Daten für Zugriff (Protokoll, Nutzer, Passwort, ...)

• Abbildungsvorschriften zur Durchführung von Schemaanpassungen (schema matching)

•Transformationsskript zur Straßenstandardisierung

•Prozessbeschreibung der gesamten Transformation



• Geschäftsprozessorientierte Metadaten

• Beschreibung, wie die Daten der operativen Quellsysteme und des Data-Warehouse-Systems aus der Perspektive des Geschäftsprozesses zu interpretieren sind.

• Spezifikation der Semantik erfolgt auf einer höheren Sprachebene, auf der Aussagen über die Daten gemacht werden können.

22

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Beispiel aus dem Bankenumfeld


23


• Konfigurationen

• ETL


Konfigurationen

• Besprochene Architektur ist maximales Rahmenwerk.

• Das heisst, nicht jede Data Warehouse Lösung muss alle besprochenen Komponenten implementieren.

• Spezifische Konfiguration hängt stark vom Anwendungsszenario ab.

• Die physische Verteilung der Daten (gleicher Server vs. unterschiedliche Systeme) kann variieren.

• Konfigurationen variieren bezüglich persistenter (materialisierter) und flüchtiger (temporärer, virtueller) Datenhaltung.

24


KonfigurationenBeispiel Konfiguration 1 - Fehlen der Konsolidierten Datenbasis

25

Meta-daten

staging area


Datenanalyse

Basisdaten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

DB2 Oracle XMLDatenquellen

Analysewerkzeuge Data Mining ToolsSpreadsheets

Query Tools


KonfigurationenBeispiel Konfiguration 2 - Überspringen der Transformation

26

Meta-daten

staging area


Datenanalyse

Basisdaten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .


Analysewerkzeuge Data Mining ToolsSpreadsheets

Query Tools

OperationalData Store

Operational Data Store (ODS) nach Inmon

Themenorientierte, integrierte, nicht dauerhafte bzw. nicht persistente detaillierte Sammlung von Daten, um eine Organisationseinheit bei ihrem Bedarf nach aktuellen, betrieblichen, integrierten und gesamtheitlichen Informationen zu unterstützen.


KonfigurationenBeispiel Konfiguration 3 - Monolithischer DW-Server

27

Meta-daten

Basisdaten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .


DW-Server


KonfigurationenBeispiel Konfiguration 4 - Verteiltes System

28

Meta-daten

Basisdaten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .


RepositoryServer

Data Marts auf eigenen Rechnern (Laptop)

Data Warehouse Server

Staging Area Server


KonfigurationenBeispiel Konfig. 5 - Materialisierte Integration & Virtuelle Views

29

Meta-daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

. . .

DB2 Oracle XML

Data Mining ToolsSpreadsheets

Query Tools

Summen-daten

temporär / virtuell

persistent / materialisiert

Basisdaten


KonfigurationenBeispiel Konfiguration 6 - Virtuelle Integration

30

Transformation

DB2 Oracle XML

Data Mining Tools

Spreadsheets

Query Tools

temporär / virtuell

persistent / materialisiert Basisdaten

Konsolidierte Daten

! Daten sind in Quellen gespeichert.

! Informationsquellen sind (zu einem gewissen Grad) autonom.

! Nur die zur Anfragebeantwortung notwendigen Daten werden übertragen.

! Transformation und Integration nur zur Anfragezeit möglich.

! Anfragen werden deklarativ an das globale Schema gestellt (hier entspricht es dem konsolidierten Schema) und verteilt ausgeführt.

! Keine historische Komponente

! Zwei wesentliche Architekturen

! 5-Schicht Architektur für föderierte Datenbanksysteme

! Mediator-Wrapper Architektur


5-Schichten Architektur [SL90]!Anwendung: heterogene, verteilte,

föderierte DBMS

! Z.B. Katalog DBMS und Image DBMS, die gemeinsamen Zugriff erlauben.

! Z.B. “lokale” Data Warehouses aus Teilbereichen eines Unternehmens

!Semi-autonome Quellen:

! Starke Autonomie,

! aber Wille zur Kooperation mit anderen

! „Föderation“ (federation)

! Verwendung von Metadaten erleichtert Anfragebearbeitung

Föderiertes Schema

Externes Schema 1

Externes Schema N...

Komponenten-schema

Komponenten-schema

Lokales Schema

Lokales Schema

...

...

Exportschema Exportschema

31


5-Schichten Architektur [SL90]

! Lokale Schemas

! Logisches Schema der Datenquellen

!Komponentenschemas

! Kanonisches Datenmodell ( = Datenmodell des föderierten Schemas)

! Übergang durch Mappings

! Überwindet Datenmodellheterogenität

!Exportschemas

! Teilmenge des Komponentenschemas

Föderiertes Schema

Externes Schema 1


Komponenten-schema

Komponenten-schema

Lokales Schema

Lokales Schema

...

...


32


5-Schichten Architektur [SL90]! Föderiertes Schema

! Integriert aus den Exportschemas

! Kennt Datenverteilung

! Andere Namen:

! Import Schema! Globales Schema! Enterprise Schema! Unified Schema! Mediator Schema

! Externes Schema

! Föderiertes Schema kann sehr groß sein " Vereinfachung im Exportschema

! „Schema Evolution“ leichter

! Zusätzliche Integritätsbedingungen

! Zugangskontrollen

Föderiertes Schema

Externes Schema 1


Komponenten-schema

Komponenten-schema

Lokales Schema

Lokales Schema

...

...


33


Quelle 1 Quelle 2 Quelle 3

Anwendung 1 Anwendung 2

Mediator

Wrapper1

Wrapper2

Wrapper3

34

Mediator-Wrapper Architektur! Anwendung

● Heterogene Quellen

● Stark autonome Quellen, die oft nichts von ihrer Integration wissen.

● Kein Umfangreiches Metadata-Repository vorhanden.

!Mediator

! Schema anwendungsorientiert entwickelt, nicht anhand von Schemaintegration.

! Komponente zur Integration

!Wrapper

! Vermitteln zwischen Quelle und Mediator

! Lösen Schnittstellen-, Datenmodell-, und schematische Heterogenität

! Unterstützen Anfrageoptimierung


35


• Konfigurationen

• ETL


Überblick Data Warehouse Architektur

36

Meta-daten

DB2 Oracle XML

DataMart 1

DataMart 2

DataMart 3

Datenquellen

Data Warehouse (DW)

Basisrelationen



Datenbeschaffung & Transformation

(staging area)

Daten-konsolidierung


Datenanalyse

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Nach Wolfgang Lehner, Datenbanktechnologie fürData Warehouse Systeme, dpunkt.verlag, 2003


Datenbeschaffung und Transformation

• Erinnerung

• Ziel ist, lokale Daten (d.h., Daten aus den Quellsystemen) zu integrieren.

• Diese integrierten Daten werden physisch in die Kontrollsphäre des Data Warehouse gebracht.

• Drei wesentliche Schritte finden im Bereich der Datenbeschaffung und Transformation, der staging area, statt, und werden als Extract-Transform-Load (ETL) Prozess bezeichnet.

37

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Extract-Transform-Load (ETL) Prozess.

• Extract: Beschaffung der relevanten Daten aus den Quellsystemen

• Transform: Transformation der Quelldaten in das Schema und Format der Zieldatenbank (im allgemeinen Framework der konsolidierten Datenbank).

• Load: Laden der Daten in die Zieldatenbank.


Der ETL ProzessExtract

• Strenge Performance-Anforderungen

• Analysewerkzeuge brauchen Daten rechtzeitig.

• Analysewerkzeuge brauchen möglichst aktuelle Daten.

• Operativer Betrieb der Quellsysteme soll nicht bzw. nur minimal eingeschränkt werden.

! Variabler Datenumfang der Extraktion

! Variable Kooperationsbereitschaft der Quellsysteme zur Datenübergabe

• Heterogene Datenquellen, insb. syntaktische Heterogenität bei der Extraktion relevant.

! Variable Zugriffsmöglichkeiten auf Datenquellen

38


Der ETL ProzessExtract - Datenmäßiger Umfang der Extraktion

Zwei wesentliche Varianten:

• Extraktion der Nettoänderungen

• Es werden nur die Teile der Datenbasis in das Data-Warehouse-System überführt, die sich seit dem vorangegangenen Extraktionsvorgang geändert haben.

• Veränderungen sind neu hinzugefügte Einträge (insert) und gelösche Einträge (delete). Änderungen existierender Datensätze (update) werden typischerweise als als insert+delete modelliert.

• Abzug des kompletten Quelldatenbestands (snapshot)

• Verwendung, wenn zu viele Änderungen der Quellen oder wenn Extraktion der Nettoänderungen aus systemtechnischen Gründen nicht möglich ist.

• Zielkonflikt: konsistenter Abzug der Quelldaten vs. Einschränkung des operativen Betriebs durch exklusiven Zugriff auf diese. " Spezielle snapshot Verfahren [AdLi80] zur Erstellung einer logischen Datenbankkopie.

39


Der ETL ProzessExtract - Kooperationsbereitschaft der Quellsysteme

Kooperationsbereitschaft der Quellsysteme, absteigend sortiert:

• Replikationsquellen

• Extrem enge Kopplung von Quellsystem und Eingangsbereich des DW.

• Einsatz von Replikationstechniken, um synchron Änderungen an den Quellsystemen direkt an das DW zu propagieren.

• Aktive Quellen

• Änderungen werden von der Quelle selbständig an das DW propagiert.

• Verwendung von Datenbanktriggern

• Snapshot-Quellen

• Quelle liefert einen Snapshot, der einem konsistenten, aber nicht notwendigerweise aktuellen Datenbankzustand entspricht.

• Änderungen der Quelle (die im Snapshot reflektiert sind) können ohne Beeinträchtigung des operativen Systems extrahiert werden.

40


Der ETL ProzessExtract - Kooperationsbereitschaft der Quellsysteme (ctd)

• Exportbasierte Quellen

• Alternativ zu einem Snapshot kann eine physische Kopie der Datenbasis (database dump) exportiert werden.

• Erstellen der Exportdatei muss vom Quellsystem unterstützt werden.

• Protokollierende Quellen

• Auswertung des Änderungsprotokolls einer Quelldatenbank zur Feststellung der im DW zu reflektierenden Änderungen.

• Nicht explizit unterstützende Quellen

• Geschlossene Systeme, keine elegante Möglichkeit, Daten für eine weitere Anwendung bereitzustellen.

• Spezialsoftware (adapter) oder Programmierung individualisierter Anwendungssoftware nötig.

41


Der ETL ProzessExtract - Zugriffsmöglichkeiten auf Datenquellen

• Zugriff auf Ebene des Anwendungsdialogs

• Bei abgeschlossenen Systemen, Anwendungsdialog einziges Zugriffsprotokoll.

• Extraktion der Daten durch Simulation eines entsprechenden Anwendungsdialogs.

• Zugriff auf Anwendungsebene

• Operative Systeme mit externen Schnittstellen.

• Extraktion der Daten über eine entsprechende Programmierschnittstelle.

• Zugriff auf Ebene des Datenbanksystems

• Direkter Zugriff auf das System zur persistenten Speicherung (z.B. RDBMS) vorhanden.

• Verwendung standardisierter bzw. systemspezifischer Protokolle als Programmierschnittstelle (z.B. ODBC bei C/C++, JDBC bei Java)

42


Der ETL ProzessExtract - Zugriffsmöglichkeiten auf Datenquellen (ctd)

• Zugriff auf Ebene der Protokollierungsinformation

• Kein Zugriff auf Anwendungs- oder Datenbankebene

• Zugriff auf Änderungsprotokolle

• Verwendung spezieller Extraktoren (log file sniffer), die aus Änderungsprotokollen die Änderungen am Quelldatenbestand liefern.

• Export und Import

• Kein Zugriff aus dem Zielsystem, also dem Data Warehouse, auf jegliche Informationen im Quellsystem.

• Quellsystem exportiert Daten in einem fest vorgeschriebenen Format.

• Zielsystem kann diese Daten importieren.

43


Der ETL ProzessTransform

• Erzeugung einer konsistenten und integrierten Datenbasis

• Einmaliger Schritt: Entwurf des Schemas der konsolidierten Datenbasis

"Techniken der Schemaintegration

• Schritt bei jedem erneuten Laden von Daten: Transformation der Quelldaten in das Zielschema (Schema der konsolidierten Datenbasis).

" Techniken der Datenintegration

44


Der ETL ProzessTransform - Schemaintegration

• Definition siehe Folie 11, Techniken nicht im Detail in dieser VL

• Anforderungen an das integrierte Schema

• VollständigkeitAlle in den Quellschemata beschriebenen Gegenstände werden im Zielschema reflektiert.

• KorrektheitSemantik der Quelldaten geht durch Zielschema nicht verloren. Da die integrierten Daten (z.B. Preis) jedoch alle die gleiche Darstellung haben sollen (z.B. ohne MWSt), muss die ursprüngliche Semantik der Quellen nachvollziehbar sein.

• MinimalitätKeine Redundanz der im globalen Schema dargestellten Gegenstände.

• VerständlichkeitSchema muss von jedermann verstanden und modifiziert werden können. 45


Der ETL ProzessTransform - Datenintegration

• Wichtigste Aufgabe: Datenqualität der integrierten Daten gewährleisten.

• Detaillierte Techniken werden in Kapitel 5 - Datenreinigung besprochen.

• 5 Phasen der Datenreinigung (diese und nächste Folie):

• Zerlegen der Daten in die Bestandteile (elementizing)Z.B. wird Attribut Adresse in Straße, Hausnummer, PLZ, Stadt aufgeteilt.

• Standardisierung der elementaren Angaben (standardizing)Z.B. Vereinheitlichung verschiedener Datumsformate, Straßennamen wie “Stuttgarter Str.” einheitlich in “Stuttgarter Straße” transformieren.

• Plausibilitätsprüfungen (verification)Z.B. Konflikt zwischen PLZ = “70567” und Stadt = “Tübingen” für eine beschriebene Adresse erkennen.

46


Der ETL ProzessTransform - Datenintegration (ctd)

• Abgleich mit bestehenden Daten (matching)Z.B. Prüfung der Existenz eines gleichen Produkts in der bisherigen integrierten Datenbasis. Falls vorhanden, muss die Darstellung erweitert bzw. aktualisiert werden.

• Gruppenbildung (householding)Prüfung ob neue Objekte mit bereits existierenden Objekten aus Sicht der Anwendung definierte Gruppen, z.B., Käuferklassen bilden oder vergrößern. Dies ist für Analysezwecke vorteilhaft.

47


Der ETL ProzessLoad

• Ziel: Effizientes Hinzufügen der transformierten Daten in das Data Warehouse.

• Techniken

• SQL – Satzbasiert

• Standardschnittstellen: Embedded SQL, JDBC, ...

• Einzelne Operationen oder proprietäre Erweiterungen – Array Insert

• Beachtung und Aktivierung aller Datenbankverfahren – Trigger, Indexaktualisierung, Concurrency, ...

• BULK Loader Funktionen: DB-spezifische Erweiterungen zum Laden großer Datenmengen

• Benutzung von Anwendungsschnittstellen: Bei manchen Produkten notwendig (SAP)

48

[Prof. Ulf Leser, HU Berlin, Data Warehouse VL, SS 2007]


Der ETL ProzessLoad - Bulk Uploads

• Für große Datenmengen einzige ausreichend performante Schnittstelle

• Kritischer Prozess

• LOAD füllt i.d.R. immer nur eine Tabelle

• LOAD setzt eine Sperre auf die gesamte Tabelle

• Während LOAD werden Integritätsconstraints, Trigger, Indexaktualisierung deaktiviert

! Nach LOAD werden IC überprüft und Indexe aktualisiert

! Trigger werden nicht ausgeführt

• Update oder Insert? (Upsert!)

• Performance von LOAD oft limitierender Faktor

49

[Prof. Ulf Leser, HU Berlin, Data Warehouse VL, SS 2007]


Zusammenfassung

• Architektur / Bestandteile eines Data Warehouse

• Konfiguration hängt von Anwendung ab

• Implementierte Komponenten variieren

• Verteilte Systeme

• Materialisierte Integration

• Virtuelle Integration

• Extract-Transform-Load (ETL) Prozess

• Extract: Beschaffung der relevanten Daten aus Quellsystemen

• Transform: Transformation der Quelldaten in das Schema und Format der Zieldatenbank.

• Load: Laden der Daten in die Zieldatenbank.50

Meta-daten

Basisdaten

Konsolidierte Daten

Dispositive Daten

Data Marts

Transformation

Detaildaten

Summen-daten

. . .

Preview of “02 architektur” - db.inf.uni-tuebingen.de · •Ziel: Aktualisierung der...

Documents

Transcript of Preview of “02 architektur” - db.inf.uni-tuebingen.de · •Ziel: Aktualisierung der...