Kapitel 3

Vorlesungs-Übersicht
1) Einführung und Definitionen
2) Architektur eines Data-Warehouse-Systems
3) Das multidimensionale Datenmodell
4) ETL: Extraktion, Transformation, Laden
5) Anfrageverarbeitung und -optimierung
6) Indexstrukturen für das multidimensionale Datenmodell
7) Materialisierte Views
8) Metadaten
9) OLAP, Data Mining, Process Mining
10) Zusammenfassung und Ausblick
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
1
Vorlesung Data-Warehouse-Systeme im Sommersemester 2006
Kapitel 3
- Das multidimensionale Datenmodell -
1
Kapitel 3: Überblick
3.1 Data-Warehouse-Designprozess
3.2 Konzeptuelle Datenmodellierung
3.3 Formalisierung und Analyseoperationen
3.4 Umsetzung des multidimensionalen Datenmodells
3.5 Zusammenfassung
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
3
3.1 Motivation
S
S
S
S
S
Zentrale Frage: Wie modellieren wir die Daten in geeigneter Weise,
d.h. für die Anwendung im Data-Warehouse-System?
Im Fokus: Modellierung sollte Analysen ermöglichen / unterstützen!
Anfragen beziehen sich meist auf mehrere Aspekte (z.B. Zeit, Ort,
Produkt)
Forderung nach mehrdimensionaler Darstellung der Daten (z.B. als
Würfel)
) 1. ASPEKT
Analog zu klassischen Datenbank-Systemen:
Nicht sofort Relationen / Tabellen anlegen (also z.B. in SQL), sondern
P Erst semantischer / konzeptueller Entwurf (z.B. Entity-Relationship)
Siehe auch Datenbank- bzw. Data-Warehouse-Designprozess
) 2. ASPEKT
P
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
4
2
3.1 Motivation (1. ASPEKT)
S
Datenmodell sollte Analyse unterstützen
P
P
P
S
Was soll analysiert werden? Kennzahlen (Erlöse, Gewinne, Verluste, etc.)
meist aus betriebswirtschaftlicher Sicht
Wie soll analysiert werden? Kennzahlen sollen aus unterschiedlichen
Perspektiven (zeitlich, regional, produktbezogen) betrachtet werden
können Dimensionen
Dimensionen sollen in verschiedener Granularität betrachtet werden
können (z.B. Zeit als Jahr, Quartal, Monat) Hierarchien oder
Konsolidierungsebenen
Verfügbare Informationen
P
Qualifizierend Repräsentiert durch „Kategorienattribute“
X
X
P
Daten zur Nutzung als Navigationsraster („Drill-Pfade“)
Modelliert als Begriffshierarchien im Rahmen von Dimensionen
Quantifizierend
X
X
Bilden Gegenstand der Auswertung („Summenattribute“)
Zellen eines Würfels, mit Dimensionen als Kanten
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
5
3.1 Motivation (2. ASPEKT)
Prozessmodell:
Sammeln von
Information
Analyse der
Bedeutung
Semantische
Datenmodelleriung
Rohmodellierung
Logische
Datenmodelleriung
DatenbankInstallation
Präzise
Modellierung
Zeit
Konzeptuelles Schema
• Interviews
• Analyse der
Substantive
• Entity-RelationshipModellierung (ERM)
• hierarchisch
• Netzwerk
• UML
• relational
• DB2
• objekt-orientiert
• Analyse von
Dokumenten
• ORACLE
•…
•…
•…
•XML
• Brainstorming
•…
DBMS unabhängig
vgl. [HLV00]
Konzeptuelles
Schemadesign
DBMS abhängig
Logisches
Schemadesign
Physisches
Schemadesign
3
3.1 Data-Warehouse-Designprozess (2. ASPEKT)
Analyse und Spezifikation
der Anforderungen
Operationales
Datenbankschema
Konzeptuelles
Design
Semiformales
Geschäftskonzept
Logisches
Design
Formales
konzeptuelles
Schema
Operationales
Datenbankschema
Physisches
Design
Physisches
Datenbankschema
Zeit
• Interviews
• ME/R
• multidimensional
• DB2
• Analyse der Substantive
• mUML
• relational
• ORACLE
• Brainstorming
• graphbasiert
• objekt-relational
• MS Server
• Analyse von Dokumenten
•…
•…
• Essbase
• MS Analysis
Services
•…
•…
vgl. [HLV00]
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
7
3.1 relationale vs. multidimensionale Schemaarchitektur (2. ASPEKT)
relational
multidimensional
Konzeptuelles Schema
Konzeptuelles Schema
Entity-Relationship
ME/R, mUML
Logisches Schema
Logisches Schema
Relationen
Dimensionen, Würfel
Physisches Schema
Physisches Schema
Speicherstrukturen
Relationen
(Faktentabelle, …),
MD-Strukturen
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
8
4
Kapitel 3: Überblick
3.1 Data-Warehouse-Designprozess
3.2 Konzeptuelle Datenmodellierung
3.3 Formalisierung und Analyseoperationen
3.4 Umsetzung des multidimensionalen Datenmodells
3.5 Zusammenfassung
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
9
3.2 … was wir kennen ….
Packungstyp
1
ist
verpackt
von
liegt in
n
n
Artikel
gehört
zu
1
Stadt
Datum.
wurde
verkauft
Bezirk
m
Filiale
Name
n
Artikel-Nr.
Auszug eines E/R-Modells für das Kaufhausbeispiel
Produktgruppe
S
Unterscheidung Klassifikationsstufen – (beschreibende) Attribute –
Kenngrößen Æ nicht direkt ersichtlich
P
S
z.B. Klassifikationsstufe Tag als Attribut modelliert, Klassifikationsstufe
Artikel als Entität
Welche Beziehungen sind Klassifikationsbeziehungen Æ nicht direkt
ersichtlich
P
z.B. als 1:n Beziehung, aber auch als Attribut (z.B. Bezirk bei Stadt)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
10
5
3.2 … was wir brauchen: Dimensionen und Hierarchien
S
Dimension:
P
P
P
P
P
S
Dimensionselemente:
P
P
P
S
Mögliche Perspektive, aus der Kennzahlen betrachtet werden können
endliche Menge von n (n ≥ 2) Dimensionselementen (Hierarchieobjekten)
Dimensionselemente stehen in Beziehung zueinander (z.B. Quartal ist
„Unterteilung“ von Jahr)
dienen der orthogonalen Strukturierung des Datenraums
Beispiele: Produkt, Geographie, Zeit
Knoten einer Klassifikationshierarchie
Klassifikationsstufe beschreibt Verdichtungsgrad
Darstellung von Dimensionen über Klassifikationsschema (Schema von
Klassifikationshierarchien)
Formen:
P
P
einfache Hierarchien
parallele Hierarchien
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
11
3.2 einfache Hierarchien
S
S
Oberster Knoten: Top beschreibt die stärkste Verdichtung (also auf
einen einzelnen Wert der Dimension)
Jede höhere Hierarchieebene enthält jeweils die aggregierten Werte
der niedrigeren Hierarchiestufe
Top
Top
Produktkategorie
Land
Produktfamilie
Stadt
Produktgruppe
Filiale
Artikel
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
12
6
3.2 parallele Hierarchien
S
S
S
Gruppierung innerhalb einer Dimension muss nicht immer eindeutig
sein mehrere Gruppierungen können parallel existieren
Keine hierarchische Beziehung in den parallelen Zweigen
Typisches Beispiel ist die Zeit-Dimension:
Top
Jahr
Quartal
Woche
Monat
Tag
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
13
3.2 Konzeptuelle Datenmodellierung
Transformation of the semi-formal business requirements
specification into a conceptual multidimensional schema.
S
konzeptuelle Datenmodellierung
P
P
P
P
P
P
P
Modellierung relevanter Zusammenhänge des Anwendungsgebietes
ER oder UML Diagrammen fehlt durch ihren universellen
Modellierungsanspruch eine DW-spezifische Semantik.
daher erfolgt die Modellierung durch ein MD-Designnotation. z.B. mE/R,
mUML
evolutionär: Erweiterung, Spezialisierung bestehender Formalismen vs.
revolutionär: neue, maßgeschneiderte Methodik
Diese unterstützen die Modellierung von Datenstrukturen wie
Dimensionen, Kenngrößen, Hierarchien
Entwurf einer für den Anwender bedarfsgerechten Auswertungsstruktur
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
14
7
3.2 mE/R-Modell
S
S
multidimensional Entity/Relationship
Erweiterung des klassischen ER-Modells (evolutionär)
P
Entity-Menge „Dimension Level“ (Klassifikationsstufe)
P
n-äre Beziehungsmenge „Fact“
P
Binäre Beziehungsmenge „Classification“ bzw. „Roll-Up“ (Verbindung von
Klassifikationsstufen)
X
X
X
S
keine explizite Modellierung von Dimensionen
Kennzahlen als Attribute der Beziehung
definiert gerichteten, nicht-zyklischen Graphen
mE/R-Modell: Notation
Klassifikationsstufe
FAKT
Klassifkationsbeziehung
Kenngröße
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
15
3.2 mE/R-Modell: Beispiel
Verkauf
Artikel
Gruppe
Familie
Branche
Filiale
Stadt
Bezirk
Region
Tag
Monat
Quartal
Jahr
Anzahl
Umsatz
Woche
S
S
S
S
S
Faktbeziehung: Verkaufsanalyse
Kenngrößen: Verkaufszahlen und Umsatz
Dimensionen: Produkt, Geographie, Zeit
Dimensionen ergeben sich aus den Basisklassifikationsstufen (z.B.
Tag)
Alternativpfad in der Zeitdimension
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
16
8
3.2 mUML - Grundlagen
S
S
S
Multidimensionale Erweiterung der UML…
… durch Einbeziehung multidimensionaler Sprachkonstrukte und deren
Semantik aus der Multidimensional Modeling Language (MML) Æ WIE?
UML: objektorientierte Notation
Unterstützung durch CASE-Werkzeuge, z.B. Rational Rose
bietet sprachinhärente Erweiterungsmöglichkeiten: Constraints, Eigenschaftswerte
(tagged values) und Stereotypen
P Achtung: in UML wird der Begriff Modell statt Schema verwendet!
P
P
S
S
S
tagged value entspricht Tupel (tag, Datenwert), wobei tag eine
Elementeigenschaft beschreibt (z.B. (EinzelVK, Preis))
tagged values beschreiben Eigenschaften von MML-Objekten
Stereotypen führen neue Modellierungskonstrukte auf Basis von UMLMetaklassen ein und spiegeln damit MML-Klassentypen wider:
P
P
S
Dimensionale Klassen
Fakt- und Datenklassen
Darstellung über UML-Klassendiagramme
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
17
3.2 mUML – Beispiel StarKauf*
<<Roll-up>>
Land
<<Dimensional-Class>>
<<Dimensional-Class>>
<<Dimensional-Class>>
Jahr
Region
<<Roll-up>>
Jahr
1 .. 2
<<Roll-up>>
Region
<<Dimensional-Class>>
<<Shared Roll-up>>
Jahr
Woche
<<Dimensional-Class>>
Quartal
Bezirk
<<Roll-up>>
Quartal
<<Dimensional-Class>>
<<Roll-up>>
Lieferantenland
<<Roll-up>>
Bezirk
<<Dimensional-Class>>
<<Dimensional-Class>>
Monat
Stadt
<<Roll-up>>
Monat
<<Roll-up>>
Woche
<<Roll-up>>
Stadt
<<Dimensional-Class>>
<<Dimensional-Class>>
<<Dimensional-Class>>
Tag
Filiale
<<Dimension>>
Zeit
Land
<<Fact-Class>>
Artikel
<<Roll-up>>
Produktgruppe
<<Dimension>>
Geographie
Verkauf
<<Dimensional-Class>>
Produktgruppe
<<Roll-up>>
Produktfamilie
1 .. *
<<Dimension>>
Produkt
<<Dimensional-Class>>
Produktfamilie
<<Dimensional-Class>>
Verkaufter Artikel
<<Roll-up>>
Produktkategorie
<<Dimensional-Class>>
Produktkategorie
9
3.2 mUML – Modellierung (1)
<<Roll-up>>
Land
<<Dimensional-Class>>
<<Dimensional-Class>>
<<Dimensional-Class>>
Jahr
Region
<<Roll-up>>
Jahr
1 .. 2
<<Roll-up>>
Region
<<Dimensional-Class>>
<<Shared Roll-up>>
Jahr
<<Dimensional-Class>>
Quartal
Woche
Bezirk
<<Roll-up>>
Quartal
<<Dimensional-Class>>
<<Roll-up>>
Lieferantenland
<<Roll-up>>
Bezirk
<<Dimensional-Class>>
<<Dimensional-Class>>
Monat
Stadt
<<Roll-up>>
Monat
<<Roll-up>>
Woche
Land
<<Roll-up>>
Stadt
<<Dimensional-Class>>
<<Dimensional-Class>>
Artikel
<<Dimensional-Class>>
<<Roll-up>>
Produktgruppe
<<Fact-Class>>
Filiale
Tag
Verkauf
<<Dimension>>
Zeit
<<Dimension>>
Anzahl:Verkäufe
Geographie
<<Fact-Class>>
EinzelVK:Preis
Verkauf
/Umsatz:Preis{formula=„Anzahl*EinzelVK“,
parameter=„Anzahl, EinzelVK“}
<<Dimension>>
Tagged value
Produkt
1 .. *
<<Dimensional-Class>>
Produktgruppe
<<Roll-up>>
Produktfamilie
<<Dimensional-Class>>
Produktfamilie
<<Dimensional-Class>>
<<Roll-up>>
Produktkategorie
Verkaufter Artikel
<<Dimensional-Class>>
Produktkategorie
3.2 mUML – Modellierung (2)
<<Roll-up>>
Land
<<Dimensional-Class>>
<<Dimensional-Class>>
<<Dimensional-Class>>
Jahr
Region
<<Roll-up>>
Jahr
1 .. 2
<<Roll-up>>
Region
<<Dimensional-Class>>
<<Shared Roll-up>>
Jahr
Woche
Quartal
Bezirk
<<Dimensional-Class>>
Monat
Stadt
<<Roll-up>>
Monat
<<Roll-up>>
Modellierung
der
Stadt
<<Dimensional-Class>>
Dimensionen
<<Dimensional-Class>>
<<Dimensional-Class>>
Tag
<<Dimension>>
Zeit
<<Roll-up>>
Lieferantenland
<<Roll-up>>
Bezirk
<<Dimensional-Class>>
<<Roll-up>>
Woche
Roll-up Pfade
<<Dimensional-Class>>
<<Roll-up>>
Quartal
<<Dimensional-Class>>
Land
<<Fact-Class>>
Artikel
<<Roll-up>>
Produktgruppe
Filiale
<<Dimension>>
Geographie
Verkauf
<<Dimensional-Class>>
Produktgruppe
<<Roll-up>>
Produktfamilie
1 .. *
<<Dimension>>
Produkt
<<Dimensional-Class>>
Produktfamilie
<<Dimensional-Class>>
Verkaufter Artikel
<<Roll-up>>
Produktkategorie
<<Dimensional-Class>>
Produktkategorie
10
3.2 mUML – Besonderheiten
<<Roll-up>>
Land
<<Dimensional-Class>>
• Anwendung von Aufsplittungsregeln
<<Dimensional-Class>>
• Letzte Kalenderwoche kann
zu 2
<<Dimensional-Class>>
<<Roll-up>>
Jahr
1 .. 2
<<Roll-up>>
Region
<<Dimensional-Class>>
<<Shared Roll-up>>
Jahr
<<Dimensional-Class>>
Quartal
Bezirk
<<Roll-up>>
Quartal
<<Dimensional-Class>>
Woche
<<Dimensional-Class>>
Monat
Stadt
<<Roll-up>>
Monat
<<Roll-up>>
Stadt
<<Dimensional-Class>>
<<Dimensional-Class>>
• Vererbung
<<Dimensional-Class>>
Artikel
• Spezialisierung
<<Roll-up>>
Produktgruppe
• Hier: eine Verkaufstransaktion
kann
auch
mehr
als
einen
Artikel
umfassen
<<Dimensional-Class>>
<<Dimension>>
Tag
<<Dimension>>
Zeit
<<Roll-up>>
Lieferantenland
<<Roll-up>>
Bezirk
<<Dimensional-Class>>
<<Roll-up>>
Woche
Land
unterschiedlichen Jahren gehörenRegion
Jahr
Filiale
<<Fact-Class>>
Geographie
Verkauf
Produktgruppe
<<Roll-up>>
Produktfamilie
1 .. *
<<Dimension>>
Produkt
<<Dimensional-Class>>
Produktfamilie
<<Dimensional-Class>>
Verkaufter Artikel
<<Roll-up>>
Produktkategorie
<<Dimensional-Class>>
Produktkategorie
3.2 Weitere Ansätze: Graphbasierte Ansätze
S
Idee: Beschreibung konzeptioneller Schemata in Form von Graphen
P
P
P
S
Ausgangspunkt: „statistische“ Tabelle mit Kopfzeile und seitlicher
Gliederung, teilweise Summenbildung über Zeilen und Spalten
Repräsentation der kategorisierenden Daten sowie der
Attributbeziehungen durch gerichteten, azyklischen Graphen
Navigationshilfe für Benutzer
Graphstruktur
P
P
P
Kanten: Beziehungen der Attribute
Knoten: unterschiedliche Semantik (in Abhängigkeit von konkreter
Notation)
Basistypen:
X
Kategorien- (Cluster) Knoten (C)
X
Kreuzprodukt-Knoten (X)
•
•
Repräsentiert Gruppierung einzelner Elemente gemäß Kategorienhierarchie
Aufspannen eines mehrdimensionalen Adressierungsraumes mit Hilfe der
Kategorienattribute über C-Knoten
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
22
11
3.2. Graphbasiertes Schema: Beispiel
Lehrer
Sekr.
Grundschule
Männl.
Realschule
Ing.
Chefs.
Sekr.
Bauing
.
1999
2000
2001
Weibl.
1999
2000
X
2001
Berufsgruppe
X
C
Jahr
Geschlecht
C
Männl.
Lehrer
C
Weibl.
1999
C
2001
Sekr.
Ing.
C
C
…
2000
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
23
3.2 Graphbasierte Ansätze: Zuordnungsregeln
S
Funktionale Abhängigkeit
P
Wird direkt durch Kante zwischen beiden C-Knoten repräsentiert
C
0 .. *
Berufsgruppe
Beruf
C
S
Berufsgruppe
0 .. 1
Beruf
N:M-Beziehung
P
Wird direkt durch Einführung eines X-Knotens repräsentiert
0 .. *
Geschlecht
X
0 .. *
Jahr
C
Geschlecht
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
C
Jahr
24
12
3.2 Graphbasierte Ansätze: weitere Knotentypen
S
Terminale Knoten (tn-Knoten)
P
P
S
Summenknoten (S-Knoten)
P
P
S
Repräsentation eines der möglichen Werte aus dem Wertebereich des
übergeordneten Kategorieattributes
Beispiel: „männlich“, „weiblich“ für „Geschlecht“
Explizite Spezifikation des quantitativen Teils eines Objektgraphen
(Mehrfachverwendung von Graphen)
Beispiel: „mittleres Einkommen“, „Anteil am Gesamteinkommen“ zu XKnoten
Topic-Knoten (T-Knoten)
P
P
P
Repräsentation einer Menge statistischer Objekte
Dekomposition statistischer Sachverhalte
Logische Verbindung von S-Knoten
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
25
3.2 Graphbasierte Ansätze: Modellierung der Abstraktion
S
Aggregation (A-Knoten)
P
P
S
Zusammenfassung logisch zusammengehöriger Einzelfakten
Beispiel: (Straße, Stadt, Land) zu Wohnort, (PersNr, Name, Wohnort,
Beruf) zu Erwerbstätige
Generalisierung (G-Knoten)
P
P
Definition einer übergeordneten Klasse abstrakter Objekte
Beispiel: Erwerbstätige, Erwerbslose zu Erwerbsperson
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
26
13
3.2 weitere Notationen
S
Erweiterungen von ER:
P
S
ADAPT
P
P
P
S
S
Application Design for Analytical Processing Technologies
Beschreibung sämtlicher Metadaten-Objekte
Aber: keine formale Grundlage
Graphbasiert:
P
S
Dimensional Fact Modeling
SUBJECT, GRASS, STORM, ADaS, …
Zur Zeit kein Standard verfügbar
Graphbasierte Ansätze zwar mächtig + flexibel, aber kaum verbreitet
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
27
3.2 TAFELÜBUNG: Konzeptuelle Modellierung
S
Gegeben: meteorologische Daten
P
P
P
P
S
In der meteorologischen Station MetWatch wird die Entwicklung von
Temperatur und Luftfeuchtigkeit innerhalb Deutschlands über die letzten
Jahre gemessen und ausgewertet.
Dazu interessieren die einzelnen Tageswerte, aber auch die wöchentliche,
monatliche und jährliche Entwicklung soll auswertbar sein.
Außerdem sollen die Werte einzelner Bundesländer, Regionen und Städte
analysiert werden.
Schließlich soll auch der Faktor „Großwetterlage“ mit den Kategorien
„Hoch“ und „Tief“ einbezogen werden.
Stellen Sie den obigen Sachverhalt in als mE/R-Modell dar.
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
28
14
3.2 TAFELÜBUNG: Ergebnis
Dimensionen: Großwetterlage, Geographie, Zeit
HochTief
Wetter
Stadt
Region
Tag
Monat
Bundesland
Temperatur
Luftfeuchtigkeit
Jahr
Woche
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
29
Kapitel 3: Überblick
3.1 Data-Warehouse-Designprozess
3.2 Konzeptuelle Datenmodellierung
3.3 Formalisierung und Analyseoperationen
P
P
P
Motivation
Definitionen
Operationen
3.4 Umsetzung des multidimensionalen Datenmodells
3.5 Zusammenfassung
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
30
15
3.3 Motivation: Beispiel multidimensionales Schema
Artikel
Gruppe
Familie
Kategorie
Stadt
Bezirk
Region
Quartal
Jahr
Verkauf
Anzahl
Kunde
Alter
Umsatz
Filiale
Einkauf
Menge
Woche
Preis
Tag
Monat
VK-Preis
Es befinden sich 4 Würfel in der
Datenbank
Lager
Nämlich: Verkauf, Einkauf, Preis, Lager
Lagerbestand
Mit den Dimensionen: Produkt, Zeit,
Geographie, Kunde
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
31
3.3 Schema einer Dimension
S
Schema einer Dimension DS
P
Partiell geordnete Menge von Kategorienattributen ({K1, …, Kn, TopD}; →)
X
X
P
P
Generisches maximales Element TopD
Funktionale Abhängigkeit →
TopD wird von allen Attributen funktional bestimmt:
∀i, 1 ≤ i ≤ n: Ki → TopD
Genau ein Ki, das alle anderen Kategorieattribute bestimmt
X
Gibt feinste Granularität einer Dimension vor:
∃i, 1 ≤ i ≤ n, ∀ j, 1 ≤ j ≤ n, i ≠ j, Ki → Kj
S
Beispiel für die Zeitdimension
DSZeit = ({Tag, Woche, Monat, Quartal, Jahr, TopZeit) mit den
funktionalen Abhängigkeiten
P
P
P
Tag → Woche
Tag → Monat → Quartal → Jahr
Tag → TopZeit, Woche → TopZeit, Quartal → TopZeit, Jahr → TopZeit
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
32
16
3.3 Kategorienattribute
S
Inhaltliche Verfeinerung durch unterschiedliche Rollen
P
Primärattribut
X
X
X
P
Klassifikationsattribut
X
X
P
Kategorienattribut, das alle anderen Attribute einer Dimension bestimmt
Definiert maximale Feinheit
Beispiel: „Tag“
Element der Menge, die mehrstufige Kategorisierung (Klassifikationshierarchie)
bilden
Beispiel: „Monat“, „Quartal“
Dimensionales Attribut
X
X
Element der Menge der Attribute, die vom Primärattribut oder einem
Klassifikationsattribut bestimmt werden und nur TopD bestimmen
Beispiel: „Artikelnummer“ zu Artikel
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
33
3.3 Kategorienattribute : Beispiel
Dimensionales Attribut
Kunde
Alter
Verkauf
Artikel
Gruppe
Familie
Branche
Filiale
Stadt
Bezirk
Region
Tag
Monat
Quartal
Jahr
Anzahl
Umsatz
Woche
Primärattribut
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
Klassifkationsattribute
34
17
3.3 Kennzahlen / Fakten
S
Kennzahlen/Fakten (engl. facts):
P
P
S
S
Fakt: Basiskennzahl
Kennzahl:
P
P
S
S
(verdichtete) numerische Messgrößen
Beschreiben betriebswirtschaftliche Sachverhalte
aus Fakten konstruiert (abgeleitete Kennzahl)
Durch Anwendung arithmetischer Operationen
Beispiele: Umsatz, Gewinn, Verlust, Deckungsbeitrag
Ein Fakt F eines multidimensionalen Schemas ist definiert als Tupel
F:= (G, SumTyp) mit
P
G := {DS1.K1, …, DSn.Kn} bezeichnet die Granularität des betrachteten Schemas
mit
X
X
X
P
DS1, …, DSn im Schema existierende Dimensionsschemata mit DSi = ({Ki1, …, Kim}, Æ)
∀ i, p mit 1 ≤ i, p ≤ n, i ≠ p: ¬ (DSi.Ki → DSp.Kp), d.h. keine funktionale Abhängigkeit
zwischen Kategorienattributen einer Granularität
Beispiel: GVerkauf1 = (Produkt.Gruppe, Zeit.Monat, Geographie.Stadt)
Summationstyp SumTyp (bestimmt, welche Aggregrationsfunktion auf Fakt /
Kenngröße angewendet werden darf)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
35
3.3 Kennzahl
S
Kennzahl M ist definiert als Tripel M = (G, f(F1, …, Fk), SumTyp) mit
Granularität G
Berechnungsvorschrift f()
P Summationstyp SumTyp
P Berechnung über nichtleerer Teilmenge der im Schema existierenden Fakten
P
P
S
Berechnungsvorschrift
P
Bildung von f()
X
Skalarfunktionen
•
•
X
Aggregatfunktionen
•
•
•
X
+, -, *, /, mod
Beispiel: Umsatzsteueranteil = Menge * Preis * Steuersatz
Funktion H() zur Verdichtung eines Datenbestandes, indem aus n Einzelwerten ein Aggregatwert
ermittelt wird
H: 2 dom(X1) ×… × dom(Xn) Æ dom(Y)
SUM(), AVG(), MIN(), MAX(), COUNT()
Ordnungsbasierte Funktionen
•
•
Definition von Kennzahlen auf Basis zuvor definierter Ordnungen
Bsp.: Kumulation, TOP(n)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
36
18
3.3 Summationstyp
S
S
erlaubte Aggregationsoperationen
FLOW
P
P
S
STOCK
P
P
S
Beliebig aggregierbar
Beispiel: Bestellmenge eines Artikels pro Tag
Beliebig aggregierbar mit Ausnahme temporaler Dimension
Beispiele: Lagerbestand, Einwohnerzahl pro Stadt
VALUE-PER-UNIT (VPU)
P
P
P
Aktuelle Zustände, die nicht summierbar sind
Zulässig nur: MIN(), MAX, AVG()
Beispiele: Wechselkurs, Steuersatz
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
37
3.3 Summierbarkeit
FLOW
STOCK: Aggregration über
temporale Dimension?
Nein
VPU
Ja
MIN/MAX
+
+
SUM
+
AVG
+
+
+
COUNT
+
+
+
-
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
+
+
-
38
19
3.3 Weitere Eigenschaften
S
Disjunktheit
P
P
Ein konkreter Wert einer Kennzahl geht exakt einmal in Ergebnis ein
Bsp.: Studierende im Grundstudium
Studierende
1999
2000
2001
Informatik
15
17
13
28
BWL
10
15
11
21
Gesamt
25
32
24
49
S
Gesamt
Vollständigkeit
P
Kennzahlen auf höherer Aggregationsebene lassen sich komplett aus
Werten tieferer Stufen berechnen
Restaurants
2001
2002
Ulm
45
46
Stuttgart
52
50
Augsburg
20
22
Gesamt
117
118
3.3 Multidimensionaler Datenwürfel für Verkauf
Zeit
Aus Darstellungsgründen im
Folgenden Abstraktion von
Dimension Kunde
Dimension
Jahr
Halbjahr
Quartal
Produkt
Kennzahl
Umsatz
Kategorie
Artikel
Kategorienattribut
Filiale
Geographie
Stadt
Bundesland
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
40
20
3.3 Würfel
S
S
S
S
S
S
Würfel (engl. cube, eigentlich Quader):
Grundlage der multidimensionalen Analyse
Kanten Dimensionen
Zellen ein oder mehrere Kennzahlen (als Funktion der Dimensionen)
Anzahl der Dimensionen Dimensionalität
Visualisierung
P
P
P
S
Aus Darstellungsgründen im
Folgenden Abstraktion von
Dimension Kunde
2 Dimensionen: Tabelle
3 Dimensionen: Würfel
>3 Dimensionen: Multidimensionale Domänenstruktur
Schema W eines Würfels ist definiert als Tupel W(G, M) mit
P
P
P
Granularität G
Menge der Kennzahlen M = (M1, …, Mm)
Beispiel: Verkauf((Produkt.Artikel, Zeit.Tag, Geographie.Filiale), (Verkauf, Umsatz))
S
Instanz eines Würfels wird durch das Kreuzprodukt der Wertebereiche aller am
Würfelschema beteiligten Attribute definiert (formal: WI ⊆ dom(G) × dom(M))
S
In multidimensionalen Schemata gilt Orthogonalität, d.h.
P
P
Beispiel für eine Würfelzelle des Verkaufswürfels: ((„Milch“, „22.02.05“, „Filiale Ulm“),(5, 4.95))
Keine funktionalen Abhängigkeiten zwischen Attributen unterschiedlicher Dimensionen
∀ i, 1 ≤ i ≤ n, ∀ j, 1 ≤ j ≤ n, i ≠ j, ¬ ∃ k, l : DSi.Kk Æ DSj.Kl
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
41
3.3 TAFELÜBUNG: Formalisierung konzeptuelles Modell
S
S
S
S
S
S
S
Gegeben: unsere Wetterstation MetWatch
Wie sieht die formale Definition des Würfels aus, der die Kenngrößen
Temperatur und Luftfeuchtigkeit auf den Klassifikationsstufen Monat
und Bundesland beschreibt?
Welche Berechnungsvorschrift bietet sich für die Kenngröße
Temperatur an?
Geben Sie eine beliebige Würfelzelle dieses Würfels an.
Wetter1((Zeit.Monat, Geographie.Bundesland,
Großwetterlage.HochTief), (Temperatur, Luftfeuchtigkeit))
Bspw. Durchschnittsbildung AVG() oder Maximum / Minimum
(Temperatur vom Typ VALUE-PER-UNIT)
Z.B. ((„April_2004“, „Hessen“, „Hoch“), (14, 20))
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
42
21
3.3 Grundoperatoren
S
Restriktion: Gegeben W((D1.K1, …, Dn.Kn), (M1, …, Mk)), Prädikat P
P
Restriktion ist definiert als σP(W) = {z ∈ W | P(z)}, falls alle Variablen in P
X
X
P
S
S
Entweder Klassifikationsstufen K sind, die funktional von einer
Klassifikationsstufe der Granularität von W abhängen
(formal: ∃Di.Ki mit Ki → K)
Oder Kenngrößen aus (M1, …, Mk) sind
Beispiel: W select = σP.Produktgruppe=„Video“(Verkauf)
Die Projektion einer Funktion der Kenngrößen F(K) eines Würfels W ist
definiert als πF(K)(W) = {(g, F(m)) ∈ dom(G) × dom(F(K)) | (g, m) ∈ W}
Verbundoperationen
P
P
P
P
Verbinden Kennziffern aus verschiedenen Würfeln zu einer neuen
Kennzahl
Gegeben: W1(G1, M1), W 2(G2, M2) lassen sich verbinden ⇔ G1 = G2 :=G
Verbund der Zellen wird über ihre Kennzahlen durchgeführt
Ergebnis W:= W1 W 2 mit W(G, M1 ∪ M2)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
43
3.3 Pivotierung / Rotation
Drehen des Würfels durch Vertauschen der Dimensionen Analyse
der Daten aus verschiedenen Perspektiven
Produkt
Ze
it
Produkt
Produkt
Ze
it
Pr
od
uk
t
Zeit
Zeit
Zeit
G
eo
gr
ap
hi
e
Zeit
Geographie
Produkt
Geographie
Pr
od
uk
t
G
eo
gr
ap
hi
e
S
Geographie
Geographie
22
3.3 Roll-Up / Drill-Down / Drill-Across
S
Roll-Up:
P
P
P
S
Drill-Down:
P
P
S
Erzeugen neuer Informationen durch Aggregierung der Daten entlang des
Konsolidierungspfades
Dimensionalität bleibt erhalten
Beispiel: Tag → Monat → Quartal → Jahr
komplementär zu Roll-Up
Navigation von aggregierten Daten zu Detail-Daten entlang der
Klassifikationshierarchie
Drill-Across:
P
P
Ausweisen von Kennzahlen bzgl. einer anderen Klassifikationshierarchie
bzw. Dimension
Also: „Wechsel von einem Würfel zu einem anderen“
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
45
3.3 Drill Down / Roll-up (2)
Q
G
eo
gr
ap
hi
e
Q
Zeit
2.
1.
Produkt
Drill-Down
Ja
n
Fe .
b.
M
ä
Ap rz
ril
M
a
Ju i
n
Ju i
li
Au
g
Se .
pt
O .
k
Not.
v
De .
z.
Roll-up
ua
rta
ua l
3.
r
Q ta l
u
4. art
Q al
ua
rta
l
Produkt Ge
og
ra
ph
ie
Zeit
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
46
23
3.3 Slice and Dice (1)
S
S
Erzeugen individueller Sichten
Slice:
P
P
P
S
Herausschneiden von „Scheiben“ aus dem Würfel durch Punkt- oder
Listeneinschränkungen auf Klassifikationsattributen
Verringerung der Dimensionalität
Beispiel: alle Werte des aktuellen Jahres in den Filialen Ulm und Bonn (Jahr = „2006“, Filiale IN („Ulm“, „Bonn“))
Dice:
P
P
P
Herausschneiden einen „Teilwürfels“
Erhaltung der Dimensionalität, Veränderung der Hierarchieobjekte
Beispiel: die Werte bestimmter Produkte oder Regionen
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
47
Dicing:
Geographie Pr
od
uk
t
Zeit
Geographie Pr
od
uk
t
Geographie
Slicing:
Pr
od
uk
t
3.3 Slice and Dice
Zeit
Zeit
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
48
24
Kapitel 3: Überblick
3.1 Data-Warehouse-Designprozess
3.2 Konzeptuelle Datenmodellierung
3.3 Formalisierung und Analyseoperationen
3.4 Umsetzung des multidimensionalen Datenmodells
P
P
Relationale Speicherung
Multidimensionale Speicherung
3.5 Zusammenfassung
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
49
3.4 Allgemeine Anmerkungen
S
Multidimensionale Sicht
P
P
S
Modellierung der Daten
Anfrageformulierung
Interne Verwaltung der Daten erfordert Umsetzung auf
P
ROLAP (relationales OLAP), Umsetzung der multidimensionalen Struktur
in Relationen
X
Vorteile:
•
•
X
relationale DBMS weit verbreitet
Ausgereifte Technologie
Nachteile:
•
•
Umsetzung der multidimensionalen Strukturen als Relationen:
Welche Nachteile ergeben sich hieraus?
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
50
25
3.4 Allgemeine Anmerkungen
P
MOLAP (multidimensionales OLAP), direkte Speicherung in
multidimensionalen Strukturen
X
Vorteile:
X
Nachteile:
•
•
•
P
Zellen können unter Umständen nur dünn besetzt sein (sparsity)
Skalierbarkeit
Hybrid, also Kombination von ROLAP und MOLAP
X
X
S
Keine Transformationen notwendig
Vorteile beider Varianten
Nachteil: Komplexität
Wesentliche Aspekte bei der Umsetzung multidimensionaler
Strukturen:
P
P
Speicherung
Anfrageformulierung bzw. -ausführung
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
51
3.4 Relationale Speicherung: Anforderungen
S
S
S
S
Informationen aus dem multidimensionalen Modell (z.B.
Klassifikationshierarchien) sollen nicht verloren gehen
effiziente Übersetzung und Verarbeitung multidimensionaler Anfragen
Update der gespeicherten Daten soll einfach sein
Analysen sollen adäquat unterstützt werden (z.B. Beachtung der
Anfragecharakteristik und des Datenvolumens)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
52
26
Aus Darstellungsgründen im
Folgenden Abstraktion von
Dimension Kunde
3.4 Relationale Speicherung: Faktentabelle
S
Ausgangspunkt: Umsetzung des Datenwürfels ohne
Klassifikationshierarchien
Dimensionen, Kennzahlen Spalten der Relation
Zelle Tupel
P Primärschlüssel: Artikel, Filiale, Tag
P Kenngrößen (measure, häufig numerisch): Verkauf
P Resultierende Tabelle heißt Faktentabelle (fact table)
P
P
Produkt
Melitta
Zeit
Jacobs
21.04.06
20.04.06
Ulm Stuttgart
Geographie
Artikel
Filiale
Tag
Verkauf
Melitta
Ulm
20.04.06
200
Jacobs
Ulm
21.04.06
500
Melitta
Stuttgart
20.04.06
214
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
53
3.4 Relationale Speicherung: Snowflake-Schema (1)
S
S
Klassifikationsstufen werden jeweils als eine Tabelle abgebildet (z.B.
Artikel, Produktgruppe, etc.)
Tabelle enthält
P
P
P
S
ID für Klassifikationsknoten
beschreibendes Attribut (z.B. Marke, Hersteller, Bezeichnung)
Fremdschlüssel der direkt übergeordneten Klassifikationsstufe
Faktentabelle enthält (neben Kenngrößen):
P
P
Fremdschlüssel der jeweils niedrigsten Klassifikationsstufe
Fremdschlüssel bilden zusammengesetzte Primärschlüssel für
Faktentabelle
S
Vorteile:
S
Nachteile:
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
54
27
3.4 Relationale Speicherung: Snowflake-Schema (2)
Quartal
n
1
Aus Darstellungsgründen im
Folgenden Abstraktion von
Dimension Kunde
Monat
QuartalID
Bezeichnung
JahrID
MonatID
Bezeichnung
QuartalID
1
Produktgruppe
n
1
Tag
Jahr
1
JahrID
Bezeichnung
n
1
n
Artikel
TagID
Bezeichnung
MonatID
WochenID
1
n
n
Woche
WochenID
Bezeichnung
JahrID
n
Stadt
n
n
ArtikelID
Bezeichnung
ProduktgruppeID
Marke …
Produktfamilie
1
n
ProduktfamilieID
Bezeichnung
ProduktkategorieID
1
ProduktkategorieID
Bezeichnung
Produktkategorie
Filiale
1
FilialeID
Bezeichnung
StadtID
Bezirk
1
StadtID
Bezeichnung
BezirkID
ArtikelID
TagID
FilialeID
Verkäufe
Umsatz
1
n
1
1
Verkauf
n
ProduktgruppeID
Bezeichnung
ProduktfamilieID
n
Region
1
BezirkID
Bezeichnung n
RegionID
Land
1
RegionID
Bezeichnung n
LandID
LandID
Bezeichnung
3.4 Relationale Speicherung: Snowflake-Schema (3)
Quartal
n
1
Monat
QuartalID
Bezeichnung
JahrID
MonatID
Bezeichnung
QuartalID
Zugehörige
1:n-Beziehung
1
Fremdschlüssel
Produktgruppe
n
1
Tag
Jahr
1
JahrID
Bezeichnung
n
1
n
Artikel
TagID
Bezeichnung
MonatID
WochenID
1
Verkauf
n
n
Woche
n
WochenID
Bezeichnung
JahrID
1
StadtID
Bezeichnung
BezirkID
n
ArtikelID
Bezeichnung
ProduktgruppeID
Marke …
n
n
Produktfamilie
1
n
ProduktfamilieID
Bezeichnung
ProduktkategorieID
1
ProduktkategorieID
Bezeichnung
Faktentabelle
Produktkategorie
Filiale
1
1
n
ArtikelID
TagID
FilialeID
Verkäufe
Umsatz
1
n
Stadt
1
FilialeID
Bezeichnung
StadtID
Bezirk
BezirkID
Bezeichnung n
RegionID
1
Region
RegionID
Bezeichnung n
LandID
1
ProduktgruppeID
Bezeichnung
ProduktfamilieID
Land
LandID
Bezeichnung
Aus Darstellungsgründen hier
Abstraktion von
Dimension Kunde
28
3.4 TAFELÜBUNG: Snowflake-Schema
S
S
Gegeben: unsere Wetterstation MetWatch
Geben Sie die relationale Speicherung des Wetter-Würfels als
Snowflake-Schema an.
Monat
n
MonatID
Bezeichnung
QuartalID
1
Tag
Jahr
1
JahrID
Bezeichnung
n
1
n
TagID
Bezeichnung
MonatID
WochenID
Stadt
1
n
Woche
n
1
Wetter
n
WochenID
Bezeichnung
JahrID
Region
1
StadtID
TagID
HTID
Temp.
Luftf.
StadtID
Bezeichnung
RegionID
n
RegionID
Bezeichnung
BundeslandID
n
Bundesland
n
1
BundeslandID
Bezeichnung
HochTief
1
1
HTID
Bezeichnung
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
57
3.4 Relationale Speicherung: Star-Schema (1)
S
Snowflake-Schema ist normalisiert:
P
P
S
Vermeidung von Update-Anomalien
Anfragen verursachen jedoch häufig „Monsterjoins“ (Joins über mehrere Tabellen)
deshalb Übergang zum so genannten Star-Schema:
P
P
P
P
P
Die zu einer Dimension gehörenden Tabellen werden denormalisiert, also zu einer
Dimensionstabelle (pro Dimension) „zusammengefasst“
Eine Konsequenz hieraus sind Redundanzen in der Dimensionstabelle
Diese Redundanzen erlauben jedoch eine schnellere Anfragebearbeitung
Beispiel: Artikel, Produkt, Produktgruppe etc. als Spalten in einer Tabelle Produkt
Vorteile des Star-Schemas:
X
X
P
Intuitive Umsetzung der multidimensionalen Struktur
Schnellere Anfrageauswertung, keine „Monsterjoins“
Nachteile:
X
X
Redundanzen aufgrund der Denormalisierung
Mehrfache Hierarchien können nicht direkt modelliert werden
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
58
29
3.4 Relationale Speicherung: Star-Schema (2)
3. Dimensionstabelle
1. Dimensionstabelle
Dim3_Schlüssel
Dim1_Schlüssel
Dim3_Attribute
Dim1_Attribute
4. Dimensionstabelle
2. Dimensionstabelle
Faktentabelle
Dim4_Schlüssel
Dim1_Schlüssel
Dim2_Schlüssel
Dim4_Attribute
Dim2_Schlüssel
Dim2_Attribute
Dim3_Schlüssel
…
Measure1
Measure2
Measure3
…
Allgemeines Star-Schema
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
59
3.4 Relationale Speicherung: Star-Schema (3)
Aus Darstellungsgründen im
Folgenden Abstraktion von
Dimension Kunde
Zeit
Produkt
1
ZeitID
1
Tag
ProduktID
Artikel
Woche
Produktgruppe
Monat
Produktfamilie
Verkauf
n
Quartal
Jahr
Geographie
n
GeographieID
ProduktID
n
Produktkategorie
ZeitID
Bezeichnung
GeographieID
Marke
Verkäufe
Packungstyp
Umsatz
…
Filiale
Stadt
StarKauf*-Szenario als StarSchema modelliert
Bezirk
Region
Land
1
…
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
60
30
3.4 Relationale Speicherung: Star-Schema (4)
S
Muster eines Star-Schemas:
P
P
P
P
S
Multidimensionales Schema mit n Dimensionen
Dimensionstabellen D1, ..., Dn der Form Di(PAi, Ai1, ..., Aik)
Faktentabelle F(PA1, ..., PAn, f1, ..., fk)
Jeder Teil des kompositen Primärschlüssels der Faktentabelle ist
Fremdschlüssel zum Primärschlüsselattribut der korrespondierenden
Dimension
Redundanzen in Dimensionstabelle durch Denormalisierung
P
Beispiel: Zugehörigkeit eines Artikels zu Produktgruppe führt zu
Zugehörigkeit zu Produktfamilie
ProduktID
Artikel
…
Produktgruppe
Produktfamilie
Kategorie
…
123
124
125
126
Melitta
Jacobs
Lavazza
Nesquik
…
…
…
…
Filterkaffee
Filterkaffee
Espresso
Instant-Kakao
Kaffee
Kaffee
Kaffee
Kakao
Heißgetränke
Heißgetränke
Heißgetränke
Heißgetränke
…
…
…
…
3.4 Vergleich von Star- und Snowflake-Schema (1)
S
Vorüberlegung: Wie sehen DWH-Anwendungen typischerweise aus?
P
P
P
S
Häufig werden Anfragen auf höhere Klassifikationsstufen gestellt
Dimensionstabellen weisen im Vergleich zu Faktentabellen ein geringes
Datenvolumen auf
Klassifikationen werden sehr selten geändert
Vorteile des Star-Schemas
P
P
P
P
P
leicht verständliche Struktur
Benutzer kann Anfragen intuitiver formulieren
effiziente Anfrageverarbeitung innerhalb einer Dimension (keine JoinOperation notwendig)
Redundanzen aufgrund Denormalisierung und damit verbunden das
Datenvolumen halten sich meistens in Grenzen
Gefahr von Update-Anomalien gering
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
62
31
3.4 Vergleich von Star- und Snowflake-Schema (2)
S
S
S
Vergleiche basieren häufig auf für Kostenbetrachtungen
Wir werden im Folgenden Kostenabschätzungen für Speicherbedarf
und Anfragekomplexität für Snowflake- und Starschema erarbeiten
Annahmen hierzu:
P
P
P
P
P
P
D Dimensionen, je K Klassifikationsstufen plus Top
Jeder Klassifikationsknoten hat 3 Kinder ⇒
M Fakten, gleich verteilt in Dimensionen
Attribut: b Bytes;
Knoten haben nur ID;
f Faktattribute
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
63
3.4 Vergleich von Star- und Snowflake-Schema (3)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
64
32
3.4 Vergleich von Star- und Snowflake-Schema (4)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
65
3.4 Vergleich von Star- und Snowflake-Schema (5)
S
Anfrage: Verkäufe der Produktgruppe „Soft-Drink“ pro Filiale und Jahr
Snowflake-Schema:
S
Anzahl der Joins: 6 (steigt linear mit Anzahl der Aggregationspfade)
S
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
66
33
3.4 Vergleich von Star- und Snowflake-Schema (6)
S
Anfrage für Star-Schema:
S
Anzahl der Joins: 3 (unabhängig von der Länge der
Aggregationspfade)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
67
3.4 Weitere Möglichkeiten
S
„Mix“ aus Snowflake-Schema oder Star-Schema
P
Entscheidung für jeweilige Dimension anhand der folgenden Fragen:
X
X
X
X
S
Zusammenfassungen innerhalb des Star-Schemas
P
P
P
S
Wie häufig ändert sich die jeweilige Dimensionen?
Wie viele Klassifikationsstufen besitzt die Dimension?
Wie viele Dimensionselemente besitzt die Dimension?
Sollen bestimmte Aggregate materialisiert gehalten werden?
eine Faktentabelle
mehrere Kennzahlen nur möglich bei gleichen Dimensionen
Im Beispiel (Folie 31) haben nur die Kennzahlen Verkauf und Umsatz die
gleichen Dimensionen und können deshalb durch eine gemeinsame
Faktentabelle repräsentiert werden
Galaxie (Multi-Faktentabellen-Schema, Multi-Cube, Hyper-Cube)
P
P
mehrere Faktentabellen
teilweise mit gleichen Dimensionstabellen verknüpft
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
68
34
3.4 Fact Constellation
S
S
Aus Optimierungsgründen kann es sinnvoll sein, bestimmte Aggregate
(die z.B. häufig angefragt werden) vorzuhalten (z.B. Umsatz pro
Monat).
Erste Möglichkeit: Speicherung der Aggregate in der Faktentabelle
P
S
S
Hierzu nötig: Unterscheidung in Dimensionstabelle über spezielle Attribute
(z.B. „Stufe“, siehe Abbildung auf Folie 72)
Alternative: die Aggregrate werden in eigenen Faktentabellen gehalten
Diese Art von Schema wird Fact-Constellation-Schema genannt (da
mehrere Faktentabellen) und ist ein Spezialfall des Galaxie-Schemas.
P
P
Einführung des zusätzlichen Attributes „Stufe“ ist nicht nötig
Würfel, die durch Aggregation auseinander hervorgehen, teilen sich
entsprechende Dimensionen
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
69
3.4 Klassifikationshierarchien (1)
S
Horizontal: Modellierung der Stufen der Klassifikationshierarchie als
Spalten der denormalisierten Dimensionstabelle
Vorteil:
S
Nachteile:
S
SELECT DISTINCT Produktgruppe
FROM Produkt
WHERE Produktkategorie = „Heissgetraenk“
ProduktID
Artikel
Produktgruppe
Produktkategorie
123
124
125
126
Melitta
Jacobs
Lavazza
Nesquik
Filterkaffee
Filterkaffee
Espresso
Instant-Kakao
Heissgetraenk
Heissgetraenk
Heissgetraenk
Heissgetraenk
35
3.4 Klassifikationshierarchien (2)
S
Vertikal (rekursiv): normalisierte Dimensionstabelle mit Attributen
P
P
S
Vorteile:
P
P
S
Dimensions_ID: Schlüssel, der Beziehung zu Faktentabelle herstellt
Eltern_ID: Attributwert der Dimensions-ID der nächsthöheren Stufe
Einfache Änderung am Klassifikationsschema
Einfache Behandlung vorberechneter Aggregate
Nachteil:
P
P
Self-Join für Anfragen einzelner Stufen
(Bsp.: Produktgruppe innerhalb einer Kategorie)
Rekursion
SELECT L3.ElternID
DimensionsID
ElternID
Melitta
Jacobs
…
Filterkaffee
…
Filterkaffee
Filterkaffee
…
FROM Produkt AS L1, Produkt AS L2, Produkt AS L3 Heissgetraenk
WHERE L1.DimensionID = „Heissgetraenk“ AND
…
L2.ElternID = L1.DimensionID AND
L3.ElternID = L2.DimensionID
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
Heissgetraenk
…
Lebensmittel
…
71
3.4 Klassifikationshierarchien (3)
S
Kombination von horizontaler und vertikaler Darstellung
P
P
P
P
S
Repräsentation der Klassifikationsstufen als Spalten
Spaltenbezeichner werden generisch gehalten
Speicherung der Knoten aller höheren Stufen als Tupel
Zusätzliches Attribut „Stufe“ Angabe der bezeichneten
Klassifikationsstufe
DimesionsID
Stufe1_ID
Stufe2_ID
Stufe
Melitta
Jacobs
Filterkaffee
Heissgetraenk
Filterkaffee
Filterkaffee
Heissgetraenk
NULL
Heißgetränke
Heissgetraenk
NULL
NULL
0
0
1
2
Wie können bei der relationalen Abbildung Semantikverluste verhindert
werden?
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
72
36
3.4 Relationale Umsetzung multidimensionaler Anfragen
S
S
S
S
Hängt von der Abbildungsvariante für das Schema ab
Meistens Aggregatanfragen bestehend aus (n+1)-Wege-Verbund zwischen n
Dimensionstabellen und der Faktentabelle
Star-Join-Anfragemuster
Beispiel: „Wie viele Artikel der Produktkategorie Heißgetränke wurden 2004
pro Monat in den unterschiedlichen Regionen verkauft?“
SELECT G.Region, Z.Monat, SUM (Verkäufe)
FROM Verkauf V, Zeit Z, Produkt P, Geographie G
WHERE V.Produkt_ID = P.Produkt_ID AND
V.ZEIT_ID = Z.ZEIT_ID AND
V.Geo_ID = G.Geo_ID AND
P.Produktfamilie = „Heissgetraenk“ AND
Z.Jahr = 2004 AND
G.Land = „Deutschland“
GROUP BY G.Region, Z.Monat
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
73
3.4 CUBE-Operator (1)
Erweiterung in SQL: Gruppierung einer Eingaberelation nach
mehreren Gruppierungskombinationen
CUBE-Operator
S
SELECT Region, Prodfamilie, Jahr, SUM(Verkäufe) AS
Verkäufe FROM …
GROUP BY Region, Prodfamilie, Jahr;
Verkauf
Einfache Gruppierungsbedingung
Region
Prodfamilie
Jahr
Verkäufe
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Hessen
Hessen
Hessen
Hessen
…
Video
Video
Video
Audio
Audio
Audio
TV
TV
TV
Video
Video
Video
Audio
…
1998
1999
2000
1996
1999
2000
1996
1999
2000
1998
1999
2000
1996
…
12
48
58
31
67
66
15
55
51
22
50
67
51
…
37
3.4 CUBE-Operator (2)
Verkauf
(SELECT Region, Prodfamilie, Jahr,
SUM(Verkäufe) AS Verkäufe
FROM…
GROUP BY Region, Prodfamilie, Jahr)
UNION
(SELECT Null AS Prodfamilie, Region, Jahr,
SUM(Verkäufe) AS Verkäufe
FROM
GROUP BY Region, Jahr)
UNION
… // (Prodfamilie,Region), (Prodfamilie,Jahr)
// (Region), (Jahr)
UNION
(SELECT Prodfamilie, NULL AS Region, NULL AS
Jahr, SUM(Verkäufe) AS Verkäufe
FROM…
GROUP BY Prodfamilie)
UNION
(SELECT NULL AS Prodfamilie, NULL AS Region,
NULL AS Jahr, SUM(Verkäufe) AS Verkäufe
FROM…)
Komplexe Gruppierungsbedingung
Region
Prodfamilie
Jahr
Verkäufe
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Bayern
Hessen
…
Hessen
NULL
NULL
NULL
NULL
NULL
…
NULL
NULL
NULL
NULL
Video
Video
Video
Video
Audio
Audio
Audio
Audio
TV
TV
TV
TV
NULL
Video
…
NULL
Video
Video
Video
Video
Audio
…
NULL
NULL
NULL
NULL
1998
1999
2000
NULL
1998
1999
2000
NULL
1996
1999
2000
NULL
NULL
1998
…
NULL
1998
1999
2000
NULL
1996
…
1998
1999
2000
NULL
12
48
58
118
31
67
66
164
15
55
51
121
403
22
…
501
34
96
156
257
82
…
172
382
350
806
3.4 CUBE-Operator (3)
S
Nachteile dieser Lösung:
Aufwendige Formulierung (aber automatische Generierung durch OLAP-Tools)
Potenziell teure Verbundoperationen müssen für jede Teilanfrage neu ausgewertet
werden
P CUBE-Operator erzeugt alle möglichen Gruppierungskombinationen; andernfalls
nur über lange UNION-Listen möglich
P
P
SELECT
Region, Prodfamilie, Jahr,
GROUPING(Region), GROUPING(Prodfamilie), GROUPING(Jahr),
SUM(Verkäufe) AS Verkäufe
FROM…
GROUP BY
CUBE(Region, Prodfamilie, Jahr)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
76
38
3.4 CUBE-Operator (3)
S
Nachteile dieser Lösung:
GROUPING
liefert (aber
1, falls
auf Gruppierungsattribut
angewandt
Aufwendige
Formulierung
automatische
Generierung durch
OLAP-Tools)
und über dieses Attribut hinweg aggregiert wird
P Potenziell teure Verbundoperationen müssen für jede Teilanfrage neu ausgewertet
Andernfalls liefert GROUPING 0
werden
P CUBE-Operator
erzeugt alle möglichen
Gruppierungskombinationen;
Æ Falls Gesamtsumme
nicht zurück
geliefert werden soll: andernfalls
nur über lange UNION-Listen möglich
HAVING NOT(GROUPING(Prodfamilie) = 1
AND GROUPING(Region) = 1
AND GROUPING(Jahr) = 1)
P
SELECT
Region, Prodfamilie, Jahr,
GROUPING(Region), GROUPING(Prodfamilie), GROUPING(Jahr),
SUM(Verkäufe) AS Verkäufe
FROM…
GROUP BY
CUBE(Region, Prodfamilie, Jahr)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
77
Produkt
Ze
it
Produkt
Produkt
Ze
it
Pr
od
uk
t
Zeit
Zeit
Zeit
G
eo
gr
ap
hi
e
Zeit
Geographie
Produkt
Geographie
Pr
od
uk
t
G
eo
gr
ap
hi
e
3.4 CUBE-Operator(4): Pivotierung / Rotation (zur Erinnerung)
Geographie
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
Geographie
78
39
3.4 CUBE-Operator (5)
Verkäufe
Bayern
Hessen
Video
Audio
TV
SUMME
Verkäufe
2002
12
31
15
58
2002
2003
48
67
55
170
Hessen
22
51
49
122
2004
58
66
51
175
SUMME
34
82
64
180
SUMME
118
164
121
403
Bayern
48
67
55
170
2002
22
51
49
122
Hessen
50
34
37
121
2003
50
34
37
121
SUMME
98
101
92
291
2004
67
42
51
160
Bayern
58
66
51
175
SUMME
139
127
137
403
Hessen
67
42
51
160
257
291
258
806
SUMME
125
108
102
335
257
291
258
806
SUMME
Bayern
2003
2004
SUMME
Video
Audio
TV
SUMME
12
31
15
58
mit 2 unterschiedlichen Pivotierungen
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
79
3.4 CUBE-Operator(6): Roll-Up (SQL99)
SELECT
Prodkategorie, Prodfamilie,
Region, Land,
SUM(Verkäufe) AS Verkäufe
Rollup in dieser Dimension in
folgenden Schritten:
d.h.
FROM…
WHERE…
GROUP BY
ROLLUP(Produktkategorie, Prodfamilie),
ROLLUP(Land, Region)
Erzeugt: (Prodkategorie, Prodfamilie)
(Prodkategorie)
()
zuerst
kreuz
A1, …, An-1, An
A1, …, An-1
…
A1
()
(Land, Region)
(Land)
()
dann
Bei 4 Gruppierungsattribute
– Cube-Operator: 24 = 16 unterschiedl. Gruppierungen
– Rollup-Operator: 3*3 = 9 unterschiedl. Gruppierungen
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
80
40
3.4 GROUPING Sets
S
S
S
Komplexeste Art der Gruppierung (in SQL:99)
Argumente können selbst wieder Gruppierungen sein, außer Grouping
Sets.
Beispiel:
SELECT ... SUM(Verkäufe) AS Verkäufe
FROM ...
GROUP BY
ROLLUP(Produktkategorie, Produktfamilie) (1)
GROUPING SETS((STADT),(REGION)),
(2)
GROUPING SETS(ROLLUP(Jahr, Quartal, Monat),(Woche)) (3)
Bedeutung:
(1) entlang der Klassifikationshierarchie
(2) nur für Städte und Regionen
(3) Nutzung der Parallelhierarchie (Jahr Æ Quartal Æ Monat) und Woche
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
81
3.4 Probleme der relationalen Speicherung
S
S
S
S
S
Multidimensionale Struktur muss in eine oder mehrere „flache“
relationale Tabellen gepresst werden.
Transformation multidimensionaler Anfragen in relationale
Repräsentation notwendig komplexe Anfragen
Einsatz komplexer Anfragewerkzeuge notwendig (OLAP-Werkzeuge)
Semantikverlust
daher: direkte multidimensionale Speicherung ?
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
82
41
3.4 Multidimensionale Speicherung (1)
S
Verwendung unterschiedlicher Datenstrukturen für Datenwürfel und
Dimensionen
P
Dimension:
X
X
P
endliche, geordnete Liste von Dimensionswerten
Ordnung der Dimensionswerte
Würfel:
X
X
X
X
X
X
Für n Dimensionen: n-dimensionaler Raum
m Dimensionswerte einer Dimension: Aufteilung des Würfels in m parallele
Ebenen
Zelle eines n-dimensionalen Würfels wird eindeutig über n-Tupel von
Dimensionswerten identifiziert
Zelle kann ein oder mehrere Kennzahlen eines zuvor definierten Datentyps
aufnehmen
Wir als Array gespeichert
häufig proprietäre Strukturen (und Systeme)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
83
3.4 Multidimensionale Speicherung (2)
S
Klassifikationsstufen:
P
Wichtig: Knoten der höheren Stufen bilden weitere Ebenen
Ulm
Umsatz in BadenWürttemberg im
Januar
Stuttgart
Baden-Württemberg
München
Bayern
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
Umsatz in
Stuttgart im
1. Quartal
Januar
Februar
März
1. Quartal
84
42
3.4 Multidimensionale Speicherung (3)
S
S
Vergleich Aggegration zur Laufzeit versus Vorberechnung
Laufzeit:
P
P
P
S
Berechnung aus Detaildaten
hohe Aktualität, jedoch hoher Aufwand
eventuell Caching
Vorberechnung:
P
P
P
Berechnung und Eintragen der Aggregationswerte in entsprechende
Zellen
Neuberechnung nach jeder Datenübernahme notwendig
hohe Anfragegeschwindigkeit, jedoch Zunahme der Würfelgröße und
Laufzeitaufwand
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
85
3.4 Multidimensionale Speicherung (4)
S
S
Weitere Datenstrukturen
Virtueller Würfel
P
S
S
Ergibt sich aus bestehenden Würfeln durch die Anwendung von
Berechnungsfunktionen (z.B. Gewinn)
Teilwürfel (Kombination mehrerer Ebenen eines Würfels Æ virtuell)
Attribute
P
P
Merkmale einer Dimension
Untermengen von Dimensionswerten können über Attribute identifiziert
werden (z.B. „Produktfarbe“)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
86
43
3.4 Multidimensionale Speicherung (5)
D1
D2
( 5)
(4)
Mä
nte
l
3)
e id
er
n(
He
D3
Ho
se
Linearisierungsreihenfolge:
md
e
1)
S
Kl
S
Rö
ck
e(
S
Speicherung des Würfels als n-dimensionales Array
hierzu Linearisierung in eine eindimensionale Liste ( Kapitel 6,
multidimensionale Indexstrukturen)
Indizes des Arrays ≡ Koordinaten der Würfelzellen (Dimensionen Di)
Indexberechnung für Zelle mit Koordinaten x1, …, xn
Index(z) = x1 + (x2 – 1) * |D1|
+ (x2 – 1) * |D1| * |D2| + …
+ (xn – 1 ) * |D1| * … * |Dn-1|
n(
2)
S
1
2
3
4
5
Januar (1)
6
7
8
9
10
Februar (2)
11 12 13 14 15
16 17 18 19 20
März (3)
April (4)
3.4 Multidimensionale Speicherung (6)
S
Probleme bei der multidimensionalen Speicherung:
P
ungünstige Linearisierungsreihenfolgen können zu schlechtem
Anfrageverhalten führen!
P
Skalierbarkeitsprobleme aufgrund dünn besetzter Datenräume
teilweise einseitige Optimierung bezüglich Leseoperationen
Reorganisation nach Änderungen an den Dimensionen kann aufwendig
werden (da Dimensionswerte geordnet)
keine Standard für multidimensionale DBMS ( Spezialwissen notwendig)
X
P
P
P
Eventuell Abhilfe durch Caching
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
88
44
3.4 Multidimensionale Speicherung (7)
S
S
Vergleich von multidimensionaler und relationaler Speicherung
Welche Faktoren spielen eine Rolle?
Speicherung Array
Relational (Star-Schema)
Faktoren
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
89
Kapitel 3: Überblick
3.1 Data-Warehouse-Designprozess
3.2 Konzeptuelle Datenmodellierung
3.3 Formalisierung und Analyseoperationen
3.4 Umsetzung des multidimensionalen Datenmodells
3.5 Zusammenfassung
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
90
45
3.5 Zusammenfassung
S
Konzeptuelle Modellierung der Daten:
P
P
P
P
S
Multidimensionale Erweiterungen von
Entity/Relationship-Modell (mE/R)
UML (mUML)
Weitere Ansätze (z.B. graphbasiert)
Umsetzung der konzeptuellen Modellierung:
P
P
P
Relational (ROLAP): Snowflake-Schema, Star-Schema
Multidimensional (MOLAP)
Hybrid (HOLAP): Kombination aus ROLAP und MOLAP
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
91
Referenzen
[HLV00]
Bodo Hüsemann, Jens Lechtenbörger, Gottfried Vossen:
Conceptual Data Warehouse Design, In Proc. Int‘l Workshop
on Design and Management of Data Warehouses, pp. 3–9
(2000)
©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3
92
46