Data-Warehouse

Vorlesung
Grundlagen betrieblicher
y
Informationssysteme
Prof. Dr. Hans Czap
Lehrstuhl für Wirtschaftsinformatik I
Email: Hans
Hans.Czap@uni
Czap@uni-trier
trier.de
de
Lehrstuhl für
Wirtschaftsinformatik I
- II - 1 -
Inhalt
Kap. 1 Ziele der Datenbanktheorie
Kap. 2 Datenmodellierung und Datenbankentwurf
K
Kap.
3D
Datenbankarchitektur
t b k hit kt
Kap. 4 Die Datenbanksprache SQL
Kap 5 Konzepte für Objektorientierte Datenbanken
Kap.
Kap. 6 Objektrelationale Datenbanken
Kap.
p 7 Datenbankentwurf: Funktionale Abhängigkeiten
gg
und
Normalisierung
Kap. 8 Datenintegrität
• Sperrprotokolle
• Recovery
Kap 9 Data-Warehouse-Konzept
Kap.
Data Warehouse Konzept
Kap. 10 Data Mining und Knowledge Discovery
Lehrstuhl für
Wirtschaftsinformatik I
- II - 2 -
Data-Warehouses
Die Bereitstellung von Daten für Entscheidungsunterstützungen
(DSS = Decision Support Systeme, EIS Executive Information Systems)
erfordert
f d t in
i vielen
i l Fäll
Fällen den
d Rückgriff
Rü k iff auff hi
historische
t i h D
Daten
t und/oder
d/ d
spezifische, zeitaufwendige Datenkombinationen.
– Der g
gemeinsame Betrieb operativer IS und die Unterstützung
g strategischer
g
bzw.
grundsätzlicher Entscheidungen würde den operativen Betreib massiv
beeinträchtigen.
– Verwendung
g eigener
g
Hard- und Softwaresysteme
y
Literatur: Bauer,
Bauer Günzel (Hrsg.):
(Hrsg ): Data Warehouse Systemedpunkt Verlag,
Verlag
Heidelberg, 2., überarbeitete und aktualisierte Auflage, 2004
Lehrstuhl für
Wirtschaftsinformatik I
- II - 3 -
OLTP versus OLAP
OLTP = Online Transaction Processing
•
Verarbeitung und Abfragen von Daten des operativen Geschäfts:
– einfache Abfragen (Abfragen, bei denen nur wenige Relationen verknüpft
werden müssen),
– Datenänderungen bei hoher Parallelität,
Parallelität
– hohes Transaktionsvolumen
• große Anzahl paralleler Abfragen
• große
ß Anzahl
A
hl paralleler
ll l Updates
U d
– hohe Wiederholung der ähnlicher Anfragen (Standardisierbarkeit)
•
Technologische
g
Basis: relationales Datenbanksystem
y
Beispiele:
– Suche den am nächsten gelegenen Lagerort des Artikels X
– Erhöhe/Erniedrige die Lagermenge des Artikels X um Y Stück
– Verbuche die Zahlung der Rechnung Z
Lehrstuhl für
Wirtschaftsinformatik I
- II - 4 -
OLTP versus OLAP
OLAP: Online Analytical Processing
•
•
•
•
Ermittlung von Trends
Extrapolation von Entwicklungen
Basis: historische Daten , die nach unterschiedlichen Kriterien gruppiert und
ausgewertet werden
Beispiele
V di ht
Verdichtung
nach
h
– Kundengruppen,
– geographischen Regionen
– unterschiedlichen Zeiträumen
– Produktsparten
– Vertretern etc
etc.
Analytische Auswertungen werden betont:
– Abfragen hoher Komplexität (keine Updates, nur Abfragen!)
– geringes Transaktionsvolumen
– geringer Wiederholungsgrad
– riesiges zu speicherndes Datenvolumen (Größenordnung im Tera-Byte-Bereich!)
Tera Byte Bereich!)
Î Data Ware House
Lehrstuhl für
Wirtschaftsinformatik I
- II - 5 -
Data-Warehouse: Konzept und Anwendungsidee
•
•
•
•
Trennung von statistischen Auswertungen und operationalen Anwendungen
Integration verschiedener Datenquellen zum Bau von
Entscheidungsunterstützungssystemen
Ein Data-Warehouse ist themenbezogen, integriert, zeitveränderlich und
nichtflüchtig
Schritte zum Einrichten eines Data-Warehouse
– Extrahieren von Daten aus operationalen Datenbanken,
– Laden eines initialen Data
Data-Set,
Set
– periodisches Aktualisieren dessen,
•
Transformation von Quelldaten in das Warehouse-Datenmodell.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 6 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 7 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 8 -
Phasen des Data-Warehousing
•
•
•
•
Trennung von statistischen Auswertungen und operationalen Anwendungen
Integration verschiedener Datenquellen zum Bau von
Entscheidungsunterstützungssystemen
Ein Data-Warehouse ist themenbezogen, integriert, zeitveränderlich und
nichtflüchtig
Schritte zum Einrichten eines Data-Warehouse
– Extrahieren von Daten aus operationalen Datenbanken,
– Laden eines initialen Data
Data-Set,
Set
– periodisches Aktualisieren dessen,
•
Transformation von Quelldaten in das Warehouse-Datenmodell.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 9 -
Anforderungen an ein Data-Warehouse im Unterschied von OLTP
und OLAP
•
•
•
•
•
Entfallen aufwendiger Konzepte wie Transaktionsmanager und RecoveryRecovery
Mechanismus
Konfiguration der Daten entsprechend den geplanten Auswertungen (z.B.
hi
hierarchisch
hi h verdichtet)
di ht t)
Aufwendige Indexierung (z.T. Vollindexierung mittels Bit-Maps)
expliziter Zeitbezug der Daten eines Data Warehouse
keine Normalisierung zu Gunsten von größerer Performance
Lehrstuhl für
Wirtschaftsinformatik I
- II - 10 -
Referenzmodell Architektur Data-Warehousing
•
•
•
•
•
Eine Referenzarchitektur enthält die grundsätzlichen Strukturen. Es ist ein
statisches Konzept, das nur gelegentlich angepasst wird.
Ermöglicht strukturierte Vergleiche zwischen unterschiedlichen Data
DataWarehouse-Systemen bzw. unterschiedlichen Komponenten derartiger
Systeme
Hat standardisierenden Charakter und dient als Basis konkreter
Implementierungen
Vermittelt ein gemeinsames Verständnis von DW-Systemen
DW Systemen
Idealtypisches Konzept, funktionsorientiert
Lehrstuhl für
Wirtschaftsinformatik I
- II - 11 -
Analyse
Abb. 2-1 Referenzmodell für die Architektur von DataWarehouse-Systemen (Referenzarchitektur)
Data
D
t
Warehouse
Data
DataWarehouseManager
Laden
MetadatenM
t d t
Manager
Repositorium
BasisDatenbank
Laden
Arbeitsbereich
Transformation
Extraktion
Monitor
Datenbeschaffungsbereich
Datenfluss
Kontrollfluss
Datenquelle
Lehrstuhl für
Wirtschaftsinformatik I
- II - 12 -
Die Komponenten der DW-Architektur
•
DW-Manager
– steuert, initiiert und überwacht die einzelnen DW-Prozesse von der Extraktion
der Daten bis hin zur Analyse
Varianten der Initialisierung:
• regelmäßige Zeitintervalle,
• in Abhängigkeit des geänderten Datenvolumens
Datenvolumens,
• durch expliziten Anstoß
– Monitore entdecken und melden dem DW-Manager Änderungen in den Quellen,
die für das DW relevant sind
– Extraktoren selektieren und transportieren die Daten aus den Datenquellen in
den Arbeitsbereich
– Transformatoren
T
f
t
vereinheitlichen,
i h itli h
bereinigen,
b i i
integrieren,
i t i
konsolidieren,
k
lidi
aggregieren und ergänzen extrahierte Daten im Arbeitsbereich
– Ladekomponenten übertragen die bereinigten Daten aus dem Arbeitsbereich in
die Basisdatenbank und anschließend in das DW
– Analysekomponenten analysieren die Daten und präsentieren die Ergebnisse
Lehrstuhl für
Wirtschaftsinformatik I
- II - 13 -
Die Komponenten der DW-Architektur
•
Datenquellen
– Datenquellen sind sämtliche dem DW vorgelagerten Systeme, die Daten an das
DW liefern
liefern. Auswahlkriterien:
•
•
•
•
Zweck des DW
Qualität der Quelldaten
Verfügbarkeit (rechtlich,
(rechtlich sozial,
sozial organisatorisch,
organisatorisch technisch)
Preis
– Anforderungen an die Qualität der Quelldaten
•
•
•
•
•
•
•
Konsistenz
Konsisten
Korrektheit
Vollständigkeit
G
Genauigkeit
i k it und
dG
Granularität
l ität
Zuverlässigkeit und Glaubwürdigkeit
Verständlichkeit
Verwendbarkeit und Relevanz
Lehrstuhl für
Wirtschaftsinformatik I
- II - 14 -
Die Komponenten der DW-Architektur
•
Monitore
– Komponente, die Datenänderungen in den Datenquellen meldet. Typischerweise
wird pro Datenquelle ein eigener Monitor benötigt
– Monitor-Strategien, basierend auf den Konzepten:
•
•
•
•
•
•
Trigger
Replikation
Zeitstempel
Logdatei
Snapshot
Arbeitsbereich
– Dient der temporären Zwischenspeicherung. Ziel: Integration der Daten
– Verwaltung durch den DW-Administrator
Lehrstuhl für
Wirtschaftsinformatik I
- II - 15 -
Die Komponenten der DW-Architektur
•
Extraktionskomponente: Übertragung aus Datenquelle in Arbeitsbereich
Wie bereits notiert gibt es folgende Alternativen:
periodisch auf Anfrage
periodisch,
Anfrage, ereignisgesteuert
ereignisgesteuert, bei jeder Änderung
•
Transformationskomponente
– Hat den Zweck, die Daten in einheitliches Format zu übertragen und die
semantische
ti h Korrektheit
K
kth it sicherzustellen
i h
t ll
•
•
Datenmigration
– Anpassung von Datentypen (Vereinheitlichung von Zeichenketten,
D t
Datumsangaben,
b
K
Kombination
bi ti b
bzw. S
Separierung
i
von Att
Attributwerten)
ib t
t )
– Konvertierung unterschiedlicher Kodierungen
– Umrechnung von Maßeinheiten
Data-Cleansing (Datenbereinigung)
– Data Scrubbbing
Ausnutzung anwendungsspezifischer Information, um semantische Unzulänglichkeiten zu
b
beseitigen
iti
» Anpassung der semantischen Zuordnung von Daten
» Beseitigung von Doubletten
– Data Auditing
Identifizieren von (möglicherweise fehlerhaften) Ausreißern mit Hilfe von Data Mining.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 16 -
Die Komponenten der DW-Architektur
•
Ladekomponente
Übertragung der Daten aus dem Arbeitsbereich in die Basisdatenbank.
Typischerweise als inkrementelles Laden realisiert
realisiert. Dabei wird ein geänderter
Satz im DW nicht überschrieben, sondern zusätzlich angelegt. Weiteres
Problem bereiten die z.T. sehr hohen Ladevolumina.
– Online Ladevorgang
– Offline Ladevorgang
•
Basisdatenbank
– Versorgt die sich anschließenden DW‘s mit den erforderlichen Daten
(
(Distributionsfunktion)
)
– Stellt dazu eine anwendungsunabhängige integrierte Sicht der Daten bereit
– Sie enthält die Basisdaten im erforderlichen Detailierungsgrad. Sie enthält keine
Aggregate („single
( single point of truth“):
truth ): Nachvollziehbarkeit und Verfügbarkeit
– Die Aktualisierungshäufigkeit hängt von den Erfordernissen der DWAnwendungen ab
– Allerdings wird in vielen Implementierungen auf die Basisdatenbank verzichtet
verzichtet.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 17 -
Die Komponenten der DW-Architektur
•
Data Warehouse
Das DW ist die den gewünschten Analysen zugrunde liegende Datenbank. Ziel:
Bereitstellung und Verwaltung der Daten für die gewünschte Analyse
Analyse.
– Daten sind im DW analysebezogen gespeichert (Î Star-Schema und
Snowflake-Schema)
– Data
D t M
Marts
t (historischer
(hi t i h B
Begriff,
iff h
heute
t b
bzw. b
beii V
Verwendung
d
einer
i
Basisdatenbank weitgehend überholt)
Teilsicht eines DW, das organisatorischen Gegebenheiten Rechnung trägt (z.B.
D t
Datenschutzaspekte,
h t
kt L
Lastverteilung,
t t il
Ei
Eigenständigkeit
tä di k it ((z.B.
B M
Mobilität)
bilität) bestimmter
b ti
t
Anwendungen
Im Gegensatz zum View-Konzept von RDBMS, das die physische Anordnung der Daten
nicht verändert (nur logische Sicht auf die Daten) bestehen Data Marts aus
anwendungsbezogenen Anordnungen bzw. Umgruppierungen der Daten des DataWarehouse (materialisierte Views). Zur Pflege dieser Daten (Aktualisierungen!), aber auch
zur Erstellung
g anwendungsspezifischer
g p
Reports
p
und Auswertungen
g sowie der Betreuung
g
der spezifischen Fachabteilungen wird in der Literatur von dem Data-Mart-Administrator
gesprochen. Die automatische Aktualisierung der Daten eines Data-Mart erfolgt durch den
bereits erwähnten Integrator.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 18 -
Die Komponenten der DW-Architektur
•
Analyse
Die eigentliche Auswertung der Daten. Analysemethoden (Businesss Intelligence
Tools „BI-Tools
BI-Tools“))
–
–
Reporting : Werkzeuge zur Erstellung von Berichten und zur Datenrepräsentation. Z.B.
Ampelfunktion um Abweichungen von vorgegebenen Bereichen kenntlich zu machen,
Tortendiagramme,
g
, Säulendiagramme,
g
, Tabellen,, Grafiken etc.
Online Analytical Processing (OLAP): Interaktives Arbeiten mit multidimensionalen Würfeln
• drill down / roll up: Detaillieren und Verdichten in einer Dimension
• drill through
• slice: Herausschneiden einer Scheibe aus dem OLAP-Würfel durch Fixierung einer
Dimensionsausprägung.
• dice (= „würfeln
würfeln“ = Drehen des Würfels,
Würfels Sichtbarmachen anderer Dimensionen)
– Data Mining
Lehrstuhl für
Wirtschaftsinformatik I
- II - 19 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 20 -
OLAP als Mittel zur Unterstützung von Entscheidungen
– Die Dimensionen als entscheidungsrelevante Größen müssen vorab festgelegt
werden. Anfragen, die sich nicht diesem vorgefertigten Schema unterordnen,
können entweder nicht oder nur nach erheblichem Aufwand beantwortet werden.
Innovative Fragestellungen werden deswegen nicht ausreichend unterstützt.
– Betonung zeitlicher Verläufe und damit zusammenhängender Operationen, wie
Trendanalysen
y
und Prognose-Rechnungen
g
g
– Verknüpfung der Daten unterschiedlicher Dimensionen nach relativ einfachen
Kriterien, z.B. zur Abweichungsanalyse (Vergleich von Soll und Ist-Daten) oder
g von Kennziffernsystemen.
y
zur Bildung
Lehrstuhl für
Wirtschaftsinformatik I
- II - 21 -
Data Mining als Mittel zur Unterstützung von Entscheidungen
•
•
•
•
Auswertung der im Data Warehouse gehaltenen Daten mit dem Ziel neue
Zusammenhänge bzw. Zusammenhangsmuster (Pattern-Analyse) zu
entdecken. Konkret ist dabei an Assoziationen bzw. der Analyse von
Sequenzen zu denken.
Klassifikation von Daten mit dem Ziel Risiko-Faktoren zu entdecken bzw.
Ef l
Erfolgsgruppen
(z.B.
( B für
fü M
Marketing-Aktivitäten)
k ti Akti ität ) zu identifizieren
id tifi i
b
bzw. zu
selektieren. Typisches Anwendungsbeispiel: Klassifikation von
Konsumenten, die um einen Kredit nachsuchen, in Risikogruppen.
Verwendung von Techniken der Statistik
Anwendung maschineller Lernverfahren
Lehrstuhl für
Wirtschaftsinformatik I
- II - 22 -
Die Komponenten der DW-Architektur
•
Repositorium
Enthält die Metadaten des DW. Sie werden von den Nutzern zum Verständnis
benötigt und von Monitor und ETL-Prozessoren zur Steuerung der Prozesse:
–
Fachliche Metadaten
• Anwendungsspezifische Dokumentationen zu standardisierten Anfragen und
Auswertungen
• Fachbegriffe, Terminologien, Thesauri, domainenspezifisches Wissen
• Kontextinformationen zu Maßeinheiten oder Datumsformaten
– Technische Metadaten
•
•
•
•
Logische und physische Datenschemata
Integritätsbedingungen
I l
Implementierungsinformationen
ti
i f
ti
zu den
d ETL
ETL-Prozessen
P
d
der unterschiedlichen
t
hi dli h
Datenquellen
M t d t
Metadatenmanager
Verwaltet und aktualisert die Metadaten im Repositorium. Stellt Schnittstellen zum
Lesen und Schreiben des Repositoriums bereit.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 23 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 24 -
Das multidimensionale Modell OLAP-Würfel (Data Cube)
•
•
Typische Anfragen an ein Data Warehouse sind multidimensional: Erstelle eine
Übersicht über die Umsätze, Kosten, Deckungsbeiträge sämtlicher Produkte,
geordnet nach Quartalen und Filialen. Dimensionen wären im vorliegenden Fall:
Produkte, Quartale (Zeit), Filialen.
Unterschieden wird folglich in Fakten ( = Zahlenwerte, Messwerte) und
Dimensionen. Dimensionen beschreiben den Kontext des Messwerts und werden
häufig hierarchisch verdichtet:
–
–
•
•
•
Produkt Î Produktgruppe Î Produktlinie Î Sparte
Tag
g Î Monat Î Quartal Î Jahr
Veranschaulichung: 3-dimensionaler Würfel (bzw. in Form einer 3-dimensionalen
Tabelle)
Zellen des Würfels: spezifische Werte Umsatz, Kosten, Deckungsbeitrag pro
Produkt, Quartal und Filiale
Typische Auswertungen eines OLAP
OLAP-Würfels
Würfels ergeben sich durch Projektionen und
Summationen (drill down, drill through, roll up, slice, dice)
Lehrstuhl für
Wirtschaftsinformatik I
- II - 25 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 26 -
OLAP-Architekturen
•
ROLAP und MOLAP
Die Aufbereitung der Daten eines Data-Warehous für die Zellen des OLAPWürfels kann als VIEW einer relationalen Datenbank erfolgen. In diesem
Fall spricht man von ROLAP (relationales OLAP).
Die Werte der Zellen können aber auch vor der Nutzung aus dem DataWareho se a
Warehouse
ausgelesen
sgelesen und
nd im OLAP
OLAP-Würfel
Würfel physisch
ph sisch abgespeichert
werden, was man dann MOLAP (multidimensionales OLAP) nennt.
– ROLAP
Nutzung der bekannten relationalen Technologie. Kein zusätzliches DBS
erforderlich. Erfahrungen der Mitarbeiter mit relationalen DBS können genutzt
werden.
Nachteil: hochkomplexe SQL-Anfragen, nur beschränkte Nutzung für EIS
– MOLAP
Mittels eigenständigem System (Multidimensionales DatenbankmanagementDatenbankmanagement
system MDBMS) kann eine Optimierung des multidimensionalen Modells
erfolgen. Verzicht auf Sperrkonzepte, Transaktionsmanager und RecoveryMechanismen reduziert den Overhead
Overhead.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 27 -
OLAP-Architekturen
Star-Schema und Snowflake-Schema bei ROLAP
•
Beispiel
Relation Prod_Umsatz_Filiale hält die Umsätze verschiedener Produkte pro
Filiale und Tag über mehrer Jahre fest:
Prod_Umsatz_Filiale ( Prod#, Filialen#, Umsatz, Datum)
Dimensionen des OLAP-Würfels
Produkt Î Produktgruppe Î Produktlinie Î all
Filiale Î Stadt Î Region Î Land Î all
g Î Woche;; Tag
g Î Monat Î Q
Quartal Î Jahr
Tag
Lehrstuhl für
Wirtschaftsinformatik I
- II - 28 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 29 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 30 -
Star-Schema
•
Relationen: Dimensionstabellen
PRODUKT (Prod#, Name,..., Prodgruppe, Gruppenbez., Prodlinie, Linienbez.)
FILIALE (Filialen#, Name,..., Stadt, Region, Land)
DATUM (Datum#, Woche, Monat, Quartal, Jahr)
•
IIm Zentrum
Z t
des
d „Sterns“
St
“ beim
b i Starschema
St
h
steht
t ht die
di sogenannte
t FactF t
Table, die die konkreten Zahlenwerte, hier Umsatz, mit den Schlüsseln der
einzelnen Dimensionen verknüpft:
Fact-Table: PROD_UMSATZ (Prod#, Filialen#, Umsatz, Datum#)
•
Keine Normalisierung!
•
Fact Constellation Schema
Überlagerung von Sternen dadurch, dass die Dimensionstabellen für mehrere
unterschiedliche Faktentabellen verwendet werden.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 31 -
Lehrstuhl für
Wirtschaftsinformatik I
- II - 32 -
Snowflake-Schema
•
Relationen: Dimensionstabellen
PRODUKT (Prod#, Name,..., Prodgruppe#)
PRODUKTGRUPPE (Prodgruppe#, Gruppen_Bezeichnung,...
Gruppen Bezeichnung,... , Prodlinie#)
PRODUKTLINIE (Prodlinie#, Linien_Bezeichnung)
FILIALE (Filialen#,
(Fili l # Name,...,
N
St
Stadt_Name)
dt N
)
STADT (Stadt_Name,.., Region#)
REGION (Region#, Bezeichnung,..., Land)
LAND (Land)
DATUM (Datum#,
(Datum# Wochen#,
Wochen# Monats#)
WOCHE (Wochen#, Jahr#)
MONAT (Monats#, Name, Quartals#)
Quartal(Quartals#, Jahr#)
JAHR (Jahr#)
•
Das Snowflake
Snowflake-Schema
Schema ist normalisiert
Lehrstuhl für
Wirtschaftsinformatik I
- II - 33 -