View
213
Download
0
Category
Preview:
Citation preview
2
Inhalt§ 4.1 Motivation
§ 4.2 Datenintegration
§ 4.3 Konzeptuelle Modellierung
§ 4.4 Anfragen an Data Warehouses
§ 4.5 Implementierungsaspekte
Data Engineering / Kapitel 4: Data Warehouses
3
Literatur
§ V. Köppen, G. Saake und K.-U. Sattler:Data Warehouse Technologien,mitp Professional, 2014http://www.dbis.prakinf.tu-ilmenau.de/biber/biber3.html
§ Andreas Bauer und Holger Günzel:Data Warehouse Systeme,dpunkt.verlag, 2013
Data Engineering / Kapitel 4: Data Warehouses
4
4.1 Motivation§ Vielzahl von operativen Systemen in Unternehmen
§ Einkauf/Verkauf von Lieferanten/Kunden
§ Kundenverwaltung (Adressen, Beschwerden)
§ Organisation (Mitarbeiter, Abteilungen)
§ Marketing (Management von Kampagnen)
§ Unternehmenssteuerung (management) benötigt ganzheitliche Sicht auf Unternehmensdaten,um analytische Fragen zu beantwortenund Entscheidungen zu treffen
Data Engineering / Kapitel 4: Data Warehouses
5
Online Transaction Processing (OLTP)§ Online Transaction Processing (OLTP) zur raschen
Bearbeitung von Transaktionen aus operativen Systemen
§ Transaktionen betreffen nur einen kleinen Teil der Daten§ Mitarbeiter stoßen Transaktionen im Tagesgeschäft
bei Verwendung der operativen Systeme an
§ Beispiele:
§ Zeige Daten zu Kunde mit KundenNr 1776289 an
§ Füge neue Bestellung mit Bestellpositionen ein
§ RDBMS sind für diese Art von Transaktionen optimiert
Data Engineering / Kapitel 4: Data Warehouses
6
Online Analytical Processing (OLAP)§ Online Analytical Processing (OLAP) zur raschen
Bearbeitung von analytischen Transaktionen
§ Transaktionen betreffen u.U. einen großen Teil der Daten
§ Ursprung der Transaktionen sind analytische Fragen,die in der Unternehmenssteuerung entstehen
§ Beispiele:
§ Umsatzentwicklung von Produkt B in den letzten 10 Jahren
§ Gewinn nach Bundesland und Produktkategoriein den letzten 6 Quartalen
Data Engineering / Kapitel 4: Data Warehouses
7
Data Warehouses§ Data Warehouses (DWs) haben sich als eigenständige
Systeme zur Unterstützung von OLAP etabliert
§ DWs als eigenständige Systeme, um Beeinträchtigungder operativen Systeme durch Anfragen zu vermeiden
§ DWs müssen Daten aus den verschiedenen operativen Systemen und evtl. externen Datenquellen integrieren
Data Engineering / Kapitel 4: Data Warehouses
8
Datenquellen§ DWs integrieren Daten aus verschiedenen Quellen
§ operative Systeme (z.B. Einkauf/Verkauf, Organisation)
§ externe Datenquellen (z.B. statistische Daten, Wetterdaten)
§ Datenintegration stößt auf viele Herausforderungen
§ Verknüpfung von Datensätzen (z.B. nach Akquisition)
§ Datenqualität (z.B. Eingabefehler, fehlende Attribute)
§ Duplikate (z.B. doppelte Kundeneinträge)
§ Effizienz (z.B. inkrementelle Integration, Bulk-Loading)
Data Engineering / Kapitel 4: Data Warehouses
9
Basisdatenbank und Datenwürfel§ Terminologie im Bereich Data Warehouses uneinheitlich;
wir orientieren uns an der in [2] vorgeschlagenen
§ Datenintegration führt zu einer Basisdatenbank (BDB),in der alle relevanten Rohdaten zusammengeführt sind
§ Datenwürfel (data cubes) werden aus BDB abgeleitet; sie stellen betriebswirtschaftliche Fakten (z.B. Umsatz) mehrdimensional (z.B. Produkt, Zeitraum, Region) dar
Data Engineering / Kapitel 4: Data Warehouses
10
Datenwürfel
Quelle: Köppen, Saake und Sattler [2, S.46]
Multidimensionales Datenmodell Grundbegriffe
GrundbegriffeDimensionenFakten / Kennzahlen
Produkt
Verkaufsort
Zeit
KennzahlUmsatz
Filiale
Stadt
Bundesland
Gruppe Artikel
JahrQuartal
Monat
Kategorie
c� Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung: 08.11.2013 3–2
Data Engineering / Kapitel 4: Data Warehouses
11
Data Marts und Data Warehouse§ Data Marts sind definierte Sichten (z.B. für eine Sparte
oder ein Vertriebsgebiet) auf Datenwürfeln und/oder BDB
§ Data Warehouse bezeichnet Gesamtheit aus Basisdatenbank, Datenwürfeln sowie Data Marts
Data Engineering / Kapitel 4: Data Warehouses
12
12 OLAP-Regeln nach Codd§ E. F. Codd hat 1993 einen Katalog von Anforderungen
formuliert, die OLAP-Systeme erfüllen müssen
1. Multidimensionale Sichtauf Kennzahlen (z.B. Umsatz), die in verschiedenenDimension (z.B. Zeit) aggregiert und gruppiert werden
2. TransparenzImplementierung bleibt dem Benutzer verborgen
3. OLAP-ZugriffeZugriffsschnittstelle ist auf OLAP-Analysen zugeschnitten
4. PerformanzLeistung des Data-Warehouse-Systems ist unempfindlich gegenüber Anzahl von Dimensionen
Data Engineering / Kapitel 4: Data Warehouses
13
12 OLAP-Regeln nach Codd5. Skalierbarkeit
Nutzung von verteilten Architekturen zum Umgang mit sehr großen Datenmengen
6. Generische DimensionalitätDimensionen gleich behandelt und organisiert
7. Dünnbesetzte StrukturenEffizienter Umgang mit dünnbesetzten Datenwürfelndurch geeignete Daten- und Indexstrukturen
8. MehrbenutzerbetriebKonfliktfreier Betrieb mit mehreren Benutzern
Data Engineering / Kapitel 4: Data Warehouses
14
12 OLAP-Regeln nach Codd9. Uneingeschränkte Operationen
Auf Datenwürfel definierte Operatoren werden umgesetzt
10. Intuitive BenutzeroberflächenBenutzeroberfläche soll intuitiv sein und z.B. eine Navigation entlang der Dimensionshierarchien erlauben
11. Flexibles ReportingTabellarische, aber auch zwei- oder mehrdimensionaleReports (Berichte) müssen frei konfigurierbar sein
12. Beliebig viele Dimensionen und AggregationsebenenKeinerlei Einschränkungen bzgl. Anzahl von Dimensionenund Tiefe der Dimensionshierarchien
Data Engineering / Kapitel 4: Data Warehouses
15
FASMI-Anforderungen§ Pendse und Creeth haben folgende Anforderungen an
Data-Warehouse-Systeme formuliert
§ Fast, d.h. kurze Antwortzeiten, die dem Benutzer ein interaktives Arbeiten ermöglichen (weniger als 5 Sekunden)
§ Analysis, d.h. es muss eine adäquate auf analytische Fragestellungen ausgerichtete Schnittstelle bereitstehen
§ Shared, d.h. das System muss mehrere Benutzer erlauben und ihre heterogenen Anforderungen unterstützen
Data Engineering / Kapitel 4: Data Warehouses
16
FASMI-Anforderungen
§ Multidimensional, d.h. das konzeptionelle Datenmodell muss die inhärente Multidimensionalität der analytischen Fragestellungen berücksichtigen
§ Information, d.h. das System muss alle für die Analysenbenötigten Daten zusammenführen und verwalten
Data Engineering / Kapitel 4: Data Warehouses
17
4.2 Datenintegration§ Daten werden im Rahmen eines ETL-Prozesses aus
operativen Systemen ins Data Warehouse überführt
§ Extraktionsphase identifiziert regelmäßig zu übernehmende Änderungen in den Datenquellen
§ Transformationsphase behebt Daten- und Schemakonflikte zwischen Datenquelle und Basisdatenbank
§ Ladephase bringt die transformierten Daten effizient(z.B. mittels Bulk-Loading) in die Basisdatenbank ein
Data Engineering / Kapitel 4: Data Warehouses
18
Datenqualität und Datenbereinigung§ Mangelnde Qualität der Daten aus den verschiedenen
Datenquellen machen eine Bereinigung notwendig
§ Vereinheitlichung von Datentypen und Format (z.B. Name)
§ Erkennen und Zusammenführen von Duplikaten
Extraktion, Transformation, Laden Datenfehler
Datenfehler
KNr Name Geb.datum Alter Geschl. Telefon PLZ34 Meier, Tom 21.01.1980 35 M 999-999 3910734 Tina Möller 18.04.78 29 W 763-222 3699935 Tom Meier 32.05.1969 27 F 222-231 39107
Person Emailnullnull
t@r.de
PLZ391073699695555
OrtMagdeburg
SpanienIllmenau
Ort
Eindeutigkeitverletzt
Unterschiedliche Repräsentation
WidersprüchlicheWerte
Fehlende Werte(z.B. Default-Werte)
Referentielle Integrität verletzt
Duplikate
Schreib- oder Tippfehler
Falsche oder unzulässige Werte
unvollständig
c� Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung: 08.11.2013 4–54
Quelle: Köppen, Saake und Sattler [2, S.82]
Data Engineering / Kapitel 4: Data Warehouses
19
Duplikatenerkennung§ Duplikatenerkennung mittels einer Vergleichsfunktion,
welche die Ähnlichkeit von zwei Datensätzen misst
§ Editierdistanzen für textuelle Attribute§ Numerischen Distanzen für numerische Attribute
§ Paare von Datensätzen deren Ähnlichkeit über einem Schwellwert liegt, werden zusammengefasst
§ Verfahren versuchen durch geschicktes Abschätzen vonÄhnlichkeiten oder Sortieren möglichst weniger als O(n2)Vergleiche durchzuführen
Data Engineering / Kapitel 4: Data Warehouses
20
Editierdistanz nach Levenshtein§ Editierdistanz nach Levenshtein d(s,t) zwischen zwei
Zeichenketten s und t misst die minimale Anzahl vonOperationen (Zeichen löschen, ändern, hinzufügen),die notwendig sind, um s in t umzuwandeln
§ Beispiel: Editierdistanz zwischen cabel und cube
§ lösche l am Ende von cabel
§ ersetzte a durch u
Data Engineering / Kapitel 4: Data Warehouses
21
Editierdistanz nach Levenshtein§ Editierdistanz lässt sich somit wie folgt rekursiv definieren
§ Berechnung in O(n2) mit dynamischer Programmierung
d(s[0..i], t[0..j]) = min
Y___]
___[
d(s[0..i ≠ 1], t[0..j ≠ 1]) + 1(s[i] ”= t[j]) // Andern?
d(s[0..i], t[0..j ≠ 1]) + 1 // Hinzufugen
d(s[0..i ≠ 1], t[0..j]) + 1 // Loschen
Data Engineering / Kapitel 4: Data Warehouses
22
Editierdistanz nach Levenshtein§ Beispiel: Editierdistanz von ware und wurst
§ DP-Tabelle beinhaltet d(s[0..i],t[0..j]) in DP[i,j]
01234
0 1 2 3w a r e
wurst
Data Engineering / Kapitel 4: Data Warehouses
23
Editierdistanz nach Levenshtein§ Beispiel: Editierdistanz von ware und wurst
§ DP-Tabelle beinhaltet d(s[0..i],t[0..j]) in DP[i,j]
01234
0 1 2 3w a r e
0 1 2 3 4w 1 0 1 2 3u 2 1 1 2 3r 3 2 2 1 2s 4 3 3 2 2t 5 4 4 3 3
Data Engineering / Kapitel 4: Data Warehouses
24
q-Gramme§ Menge der q-Gramme zu einer Zeichenkette beinhaltet
alle Zeichenketten der Länge 3, die darin enthalten sind
§ Beispiel: warehouse beinhaltet die 3-Gramme{__w, _wa, war, are, reh, eho, hou, ous, use, se_, e__}
§ Ähnlichkeit von zwei Zeichenketten als Dice-Koeffizientder Mengen ihrer q-Gramme
dice(s, t) = 2 · |grams(s, q) fl grams(t, q)||grams(s, q) + grams(t, q)|
Data Engineering / Kapitel 4: Data Warehouses
25
q-Gramme§ Zwei Zeichenketten s und t müssen mindestens
gemeinsame q-Gramme haben, um eine Editierdistanzvon höchstens k zu haben
§ Man kann diese Schranke ausnutzen, um die Zahl der Paare von Zeichenketten, für die die Editierdistanzexakt berechnet werden muss, deutlich zu reduzieren
max(|s|, |t|) ≠ 1 ≠ (k ≠ 1)
Data Engineering / Kapitel 4: Data Warehouses
26
4.3 Konzeptuelle Modellierung§ Werkzeuge zur konzeptuellen Modellierung von Data
Warehouses betrachten Fakten und Dimensionen
Multidimensionales Datenmodell Grundbegriffe
GrundbegriffeDimensionenFakten / Kennzahlen
Produkt
Verkaufsort
Zeit
KennzahlUmsatz
Filiale
Stadt
Bundesland
Gruppe Artikel
JahrQuartal
Monat
Kategorie
c� Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung: 08.11.2013 3–2Quelle: Köppen, Saake und Sattler [3, S.46]
Data Engineering / Kapitel 4: Data Warehouses
27
Fakten und Kennzahlen§ Zellen eines Datenwürfels stellen betriebswirtschaftliche
Fakten in Form einer Kennzahl (measure) dar
§ Fakten sind in den Dimensionen des Datenwürfels eingebettet und beziehen sich auf eine Positionim aufgespannten Datenraum
§ Kennzahlen (z.B. Umsatz, Gewinn, verkaufte Stückzahl)sollen Verdichtung entlang der Dimensionen erlauben
§ Beispiel: Umsatz für Produkt B in Filiale X im Mai 2015
Data Engineering / Kapitel 4: Data Warehouses
28
Dimensionen§ Dimensionen beschreiben mögliche Sichten und
strukturieren den aufgespannten Datenraum
§ Dimensionen beinhalten einfache oder parallele Klassifikationshierarchien, entlang derer sichFakten auf einer höheren Klassifikationsstufeweiter verdichten lassen
Data Engineering / Kapitel 4: Data Warehouses
29
Einfache und parallele Hierarchien§ Einfache Hierarchie für Dimension Verkaufsort
§ Parallele Hierarchien für Dimension Zeitraum
Multidimensionales Datenmodell Grundbegriffe
Einfache HierarchieHöhere Hierarchieebene enthält die aggregierten Werte genaueiner niedrigeren HierarchiestufeOberster Knoten: Top
I Enthält Verdichtung auf einen einzelnen Wert für die Dimension
Top
Bundesland
Stadt
Filiale
c� Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung: 08.11.2013 3–7
Multidimensionales Datenmodell Grundbegriffe
Parallele HierarchieInnerhalb einer Dimension sind mehrere unabhängige Arten derGruppierung möglichKeine hierarchische Beziehung zwischen parallelen ZweigenParallelhierarchie
I Pfad im KlassifikationsschemaI Konsolidierungspfad
Top
Jahr
Quartal
Monat
Tag
Woche
c� Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung: 08.11.2013 3–8Quelle: Köppen, Saake und Sattler [2, S.48]
Data Engineering / Kapitel 4: Data Warehouses
30
Multidimensional Entity-Relationship-Modell
§ Multidimensional Entity-Relationship-Modell (ME/R)als Erweiterung des ERMs zur konzeptuellenModellierung von Data Warehouses
§ Fakten als ausgezeichnete Beziehungstypen
§ Dimensionen als Gruppen von Entitytypen verbunden durch ausgezeichneten Klassifikationsbeziehungstyp
Quelle: Köppen, Saake und Sattler [2, S.53]
Multidimensionales Datenmodell Konzeptuelle Modellierung
ME/R: Notationen
Fakten-name Ebene
Faktenbeziehung KlassifikationsstufeKlassifikations-
beziehung
Attribut-bezeichnung
Attribut
c� Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung: 08.11.2013 3–28
Data Engineering / Kapitel 4: Data Warehouses
31
Multidimensional Entity-Relationship-ModellMultidimensionales Datenmodell Konzeptuelle Modellierung
ME/R: Beispiel
Verkauf Filiale
Tag
ArtikelProdukt-gruppe
Produkt-kategorie
Monat Quartal JahrWoche
Stadt Bundes-land
Anzahl Umsatz
KundeKunden-gruppe
c� Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung: 08.11.2013 3–29
Quelle: Köppen, Saake und Sattler [2, S.54]
Data Engineering / Kapitel 4: Data Warehouses
32
Zusammenfassung§ Unterstützung der Unternehmenssteuerung durch
Data Warehouses mit ganzheitlicher Sichtauf Daten aus operativen Systemen
§ Online Transaction Processing (OLTP) und Online Analytical Processing unterscheiden sich deutlich
§ Datenintegration als eine wichtige Herausforderung
§ Multidimensional Entity-Relationship-Model zur konzeptuellen Modellierung von Data Warehouses
Data Engineering / Kapitel 4: Data Warehouses
Recommended