dwh ws0809 kapitel3 - universität ulm · auch mehr als einen artikel umfassen ©stefanie...

46
1 1 ©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 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 Kapitel 3 - Das multidimensionale Datenmodell - Vorlesung Data-Warehouse-Systeme im Sommersemester 2006

Upload: lykhanh

Post on 05-Aug-2019

221 views

Category:

Documents


0 download

TRANSCRIPT

1

1©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

Vorlesungs-Übersicht

1) Einführung und Definitionen2) Architektur eines Data-Warehouse-Systems

3) Das multidimensionale Datenmodell

4) ETL: Extraktion, Transformation, Laden

5) Anfrageverarbeitung und -optimierung

6) Indexstrukturen für das multidimensionale Datenmodell7) Materialisierte Views

8) Metadaten

9) OLAP, Data Mining, Process Mining

10) Zusammenfassung und Ausblick

Kapitel 3

- Das multidimensionale Datenmodell -

Vorlesung Data-Warehouse-Systeme im Sommersemester 2006

2

3©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

Kapitel 3: Überblick

3.1 Data-Warehouse-Designprozess3.2 Konzeptuelle Datenmodellierung

3.3 Formalisierung und Analyseoperationen

3.4 Umsetzung des multidimensionalen Datenmodells

3.5 Zusammenfassung

4©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.1 Motivation

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), sondernErst semantischer / konzeptueller Entwurf (z.B. Entity-Relationship)

Siehe auch Datenbank- bzw. Data-Warehouse-Designprozess2. ASPEKT

3

5©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.1 Motivation (1. ASPEKT)

Datenmodell sollte Analyse unterstützenWas soll analysiert werden? Kennzahlen (Erlöse, Gewinne, Verluste, etc.) meist aus betriebswirtschaftlicher SichtWie soll analysiert werden? Kennzahlen sollen aus unterschiedlichen Perspektiven (zeitlich, regional, produktbezogen) betrachtet werden können DimensionenDimensionen sollen in verschiedener Granularität betrachtet werden können (z.B. Zeit als Jahr, Quartal, Monat) Hierarchien oder Konsolidierungsebenen

Verfügbare InformationenQualifizierend Repräsentiert durch „Kategorienattribute“

Daten zur Nutzung als Navigationsraster („Drill-Pfade“)Modelliert als Begriffshierarchien im Rahmen von Dimensionen

QuantifizierendBilden Gegenstand der Auswertung („Summenattribute“)Zellen eines Würfels, mit Dimensionen als Kanten

3.1 Motivation (2. ASPEKT)

Sammeln von Information

Semantische Datenmodelleriung

Logische Datenmodelleriung

Datenbank-Installation

Konzeptuelles Schema

Analyse der Bedeutung

Rohmodellierung Präzise Modellierung

Zeit

• Interviews

• Analyse der Substantive

• Brainstorming

• Analyse von Dokumenten

• …

• Entity-Relationship-Modellierung (ERM)

• UML

• …

• hierarchisch

• Netzwerk

• relational

• objekt-orientiert

•…

•XML

• DB2

• ORACLE

• …

DBMS unabhängig DBMS abhängig

Konzeptuelles Schemadesign

Logisches Schemadesign

Physisches Schemadesign

Prozessmodell:

vgl. [HLV00]

4

7©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.1 Data-Warehouse-Designprozess (2. ASPEKT)

Analyse und Spezifikation der Anforderungen

Konzeptuelles Design

Logisches Design

Physisches Design

Operationales Datenbank-

schema

Zeit

• Interviews

• Analyse der Substantive

• Brainstorming

• Analyse von Dokumenten

• …

• ME/R

• mUML

• graphbasiert

• …

• multidimensional

• relational

• objekt-relational

•…

• DB2

• ORACLE

• MS Server

• Essbase

• MS Analysis Services

• …

Semiformales Geschäfts-

konzept

Formales konzeptuelles

Schema

Operationales Datenbank-

schema

Physisches Datenbank-

schema

vgl. [HLV00]

8©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.1 relationale vs. multidimensionale Schemaarchitektur (2. ASPEKT)

Konzeptuelles Schema

Entity-Relationship

Logisches Schema

Relationen

Physisches Schema

Speicherstrukturen

Konzeptuelles Schema

ME/R, mUML

Logisches Schema

Dimensionen, Würfel

Physisches Schema

Relationen (Faktentabelle, …),

MD-Strukturen

relational multidimensional

5

9©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

Kapitel 3: Überblick

3.1 Data-Warehouse-Designprozess3.2 Konzeptuelle Datenmodellierung

3.3 Formalisierung und Analyseoperationen

3.4 Umsetzung des multidimensionalen Datenmodells

3.5 Zusammenfassung

10©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 … was wir kennen ….

Unterscheidung Klassifikationsstufen – (beschreibende) Attribute –Kenngrößen nicht direkt ersichtlich

z.B. Klassifikationsstufe Tag als Attribut modelliert, Klassifikationsstufe Artikel als Entität

Welche Beziehungen sind Klassifikationsbeziehungen nicht direkt ersichtlich

z.B. als 1:n Beziehung, aber auch als Attribut (z.B. Bezirk bei Stadt)

Packungstyp

Produktgruppe

Artikel Filiale

Stadtist verpackt

von

gehört zu

wurde verkauft

liegt in

Artikel-Nr.

Datum.

Bezirk

Name

Auszug eines E/R-Modells für das Kaufhausbeispiel

1

n

1

n

n m

6

11©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 … was wir brauchen: Dimensionen und Hierarchien

Dimension:Mögliche Perspektive, aus der Kennzahlen betrachtet werden könnenendliche Menge von n (n ≥ 2) Dimensionselementen (Hierarchieobjekten)Dimensionselemente stehen in Beziehung zueinander (z.B. Quartal ist „Unterteilung“ von Jahr)dienen der orthogonalen Strukturierung des DatenraumsBeispiele: Produkt, Geographie, Zeit

Dimensionselemente:Knoten einer KlassifikationshierarchieKlassifikationsstufe beschreibt VerdichtungsgradDarstellung von Dimensionen über Klassifikationsschema (Schema von Klassifikationshierarchien)

Formen:einfache Hierarchienparallele Hierarchien

12©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 einfache Hierarchien

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

Produktkategorie

Produktfamilie

Produktgruppe

Artikel

Top

Land

Stadt

Filiale

7

13©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 parallele Hierarchien

Gruppierung innerhalb einer Dimension muss nicht immer eindeutigsein mehrere Gruppierungen können parallel existierenKeine hierarchische Beziehung in den parallelen Zweigen

Typisches Beispiel ist die Zeit-Dimension:

Top

Jahr

Quartal

Monat

Tag

Woche

14©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 Konzeptuelle Datenmodellierung

Transformation of the semi-formal business requirements specification into a conceptual multidimensional schema.

konzeptuelle DatenmodellierungModellierung relevanter Zusammenhänge des AnwendungsgebietesER oder UML Diagrammen fehlt durch ihren universellen Modellierungsanspruch eine DW-spezifische Semantik.

daher erfolgt die Modellierung durch ein MD-Designnotation. z.B. mE/R, mUMLevolutionär: Erweiterung, Spezialisierung bestehender Formalismen vs.

revolutionär: neue, maßgeschneiderte MethodikDiese unterstützen die Modellierung von Datenstrukturen wie Dimensionen, Kenngrößen, HierarchienEntwurf einer für den Anwender bedarfsgerechten Auswertungsstruktur

8

15©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 mE/R-Modell

multidimensional Entity/RelationshipErweiterung des klassischen ER-Modells (evolutionär)

Entity-Menge „Dimension Level“ (Klassifikationsstufe)keine explizite Modellierung von Dimensionen

n-äre Beziehungsmenge „Fact“Kennzahlen als Attribute der Beziehung

Binäre Beziehungsmenge „Classification“ bzw. „Roll-Up“ (Verbindung von Klassifikationsstufen)

definiert gerichteten, nicht-zyklischen Graphen

mE/R-Modell: Notation

FAKT

Kenngröße

Klassifikationsstufe Klassifkationsbeziehung

16©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 mE/R-Modell: Beispiel

Faktbeziehung: Verkaufsanalyse

Kenngrößen: Verkaufszahlen und Umsatz

Dimensionen: Produkt, Geographie, Zeit

Dimensionen ergeben sich aus den Basisklassifikationsstufen (z.B. Tag)

Alternativpfad in der Zeitdimension

Verkauf

Anzahl

Umsatz

Artikel

Filiale

Tag

Gruppe

Stadt

Monat

Woche

Familie

Bezirk

Quartal

Branche

Region

Jahr

9

17©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 mUML - Grundlagen

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 Rosebietet sprachinhärente Erweiterungsmöglichkeiten: Constraints, Eigenschaftswerte (tagged values) und StereotypenAchtung: in UML wird der Begriff Modell statt Schema verwendet!

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 UML-Metaklassen ein und spiegeln damit MML-Klassentypen wider:

Dimensionale KlassenFakt- und Datenklassen

Darstellung über UML-Klassendiagramme

3.2 mUML – Beispiel StarKauf*

<<Dimensional-Class>>

Produktgruppe

<<Dimensional-Class>>

Produktfamilie

<<Dimensional-Class>>

Produktkategorie

<<Dimensional-Class>>

Artikel

<<Roll-up>> Produktgruppe

<<Roll-up>> Produktfamilie

<<Roll-up>> Produktkategorie

<<Dimensional-Class>>

Bezirk

<<Dimensional-Class>>

Stadt

<<Dimensional-Class>>

Filiale

<<Dimensional-Class>>

Region

<<Roll-up>> Region

<<Roll-up>> Bezirk

<<Roll-up>> Stadt

<<Dimensional-Class>>

Land

<<Fact-Class>>

Verkauf

<<Dimensional-Class>>

Verkaufter Artikel

<<Dimensional-Class>>

Monat

<<Dimensional-Class>>

Tag

<<Dimensional-Class>>

Quartal

<<Roll-up>> Quartal

<<Roll-up>> Monat

<<Dimensional-Class>>

Jahr

<<Dimensional-Class>>

Woche

<<Roll-up>> Lieferantenland

<<Roll-up>> Land

<<Dimension>> Produkt

<<Dimension>> Geographie

1 .. *

<<Dimension>> Zeit

<<Roll-up>> Woche

<<Shared Roll-up>> Jahr

<<Roll-up>> Jahr

1 .. 2

10

3.2 mUML – Modellierung (1)

<<Dimensional-Class>>

Produktgruppe

<<Dimensional-Class>>

Produktfamilie

<<Dimensional-Class>>

Produktkategorie

<<Dimensional-Class>>

Artikel

<<Roll-up>> Produktgruppe

<<Roll-up>> Produktfamilie

<<Roll-up>> Produktkategorie

<<Dimensional-Class>>

Bezirk

<<Dimensional-Class>>

Stadt

<<Dimensional-Class>>

Filiale

<<Dimensional-Class>>

Region

<<Roll-up>> Region

<<Roll-up>> Bezirk

<<Roll-up>> Stadt

<<Dimensional-Class>>

Land

<<Fact-Class>>

Verkauf

<<Dimensional-Class>>

Verkaufter Artikel

<<Dimensional-Class>>

Monat

<<Dimensional-Class>>

Tag

<<Dimensional-Class>>

Quartal

<<Roll-up>> Quartal

<<Roll-up>> Monat

<<Dimensional-Class>>

Jahr

<<Dimensional-Class>>

Woche

<<Roll-up>> Lieferantenland

<<Roll-up>> Land

<<Dimension>> Produkt

<<Dimension>> Geographie

1 .. *

<<Dimension>> Zeit

<<Roll-up>> Woche

<<Shared Roll-up>> Jahr

<<Roll-up>> Jahr

1 .. 2

<<Fact-Class>>

Verkauf

Anzahl:Verkäufe

EinzelVK:Preis

/Umsatz:Preis{formula=„Anzahl*EinzelVK“, parameter=„Anzahl, EinzelVK“}

Tagged value

3.2 mUML – Modellierung (2)

<<Dimensional-Class>>

Produktgruppe

<<Dimensional-Class>>

Produktfamilie

<<Dimensional-Class>>

Produktkategorie

<<Dimensional-Class>>

Artikel

<<Roll-up>> Produktgruppe

<<Roll-up>> Produktfamilie

<<Roll-up>> Produktkategorie

<<Dimensional-Class>>

Bezirk

<<Dimensional-Class>>

Stadt

<<Dimensional-Class>>

Filiale

<<Dimensional-Class>>

Region

<<Roll-up>> Region

<<Roll-up>> Bezirk

<<Roll-up>> Stadt

<<Dimensional-Class>>

Land

<<Fact-Class>>

Verkauf

<<Dimensional-Class>>

Verkaufter Artikel

<<Dimensional-Class>>

Monat

<<Dimensional-Class>>

Tag

<<Dimensional-Class>>

Quartal

<<Roll-up>> Quartal

<<Roll-up>> Monat

<<Dimensional-Class>>

Jahr

<<Dimensional-Class>>

Woche

<<Roll-up>> Lieferantenland

<<Roll-up>> Land

<<Dimension>> Produkt

<<Dimension>> Geographie

1 .. *

<<Dimension>> Zeit

<<Roll-up>> Woche

<<Shared Roll-up>> Jahr

<<Roll-up>> Jahr

1 .. 2

Modellierung der Dimensionen

Roll-up Pfade

11

3.2 mUML – Besonderheiten

<<Dimensional-Class>>

Produktgruppe

<<Dimensional-Class>>

Produktfamilie

<<Dimensional-Class>>

Produktkategorie

<<Dimensional-Class>>

Artikel

<<Roll-up>> Produktgruppe

<<Roll-up>> Produktfamilie

<<Roll-up>> Produktkategorie

<<Dimensional-Class>>

Bezirk

<<Dimensional-Class>>

Stadt

<<Dimensional-Class>>

Filiale

<<Dimensional-Class>>

Region

<<Roll-up>> Region

<<Roll-up>> Bezirk

<<Roll-up>> Stadt

<<Dimensional-Class>>

Land

<<Fact-Class>>

Verkauf

<<Dimensional-Class>>

Verkaufter Artikel

<<Dimensional-Class>>

Monat

<<Dimensional-Class>>

Tag

<<Dimensional-Class>>

Quartal

<<Roll-up>> Quartal

<<Roll-up>> Monat

<<Dimensional-Class>>

Jahr

<<Dimensional-Class>>

Woche

<<Roll-up>> Lieferantenland

<<Roll-up>> Land

<<Dimension>> Produkt

<<Dimension>> Geographie

1 .. *

<<Dimension>> Zeit

<<Roll-up>> Woche

<<Shared Roll-up>> Jahr

<<Roll-up>> Jahr

1 .. 2

• Anwendung von Aufsplittungsregeln• Letzte Kalenderwoche kann zu 2 unterschiedlichen Jahren gehören

• Vererbung• Spezialisierung• Hier: eine Verkaufstransaktion kann auch mehr als einen Artikel umfassen

22©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 Weitere Ansätze: Graphbasierte Ansätze

Idee: Beschreibung konzeptioneller Schemata in Form von GraphenAusgangspunkt: „statistische“ Tabelle mit Kopfzeile und seitlicher Gliederung, teilweise Summenbildung über Zeilen und SpaltenRepräsentation der kategorisierenden Daten sowie der Attributbeziehungen durch gerichteten, azyklischen GraphenNavigationshilfe für Benutzer

GraphstrukturKanten: Beziehungen der AttributeKnoten: unterschiedliche Semantik (in Abhängigkeit von konkreter Notation)Basistypen:

Kategorien- (Cluster) Knoten (C)• Repräsentiert Gruppierung einzelner Elemente gemäß Kategorienhierarchie

Kreuzprodukt-Knoten (X)• Aufspannen eines mehrdimensionalen Adressierungsraumes mit Hilfe der

Kategorienattribute über C-Knoten

12

23©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2. Graphbasiertes Schema: Beispiel

2001

2000

1999Weibl.

2001

2000

1999Männl.

Bauing.

Sekr.Chefs.Real-schule

Grund-schule

Ing.Sekr.Lehrer

X

X C

C C C C C

Männl. Weibl. 19992000

2001

GeschlechtJahr Lehrer Sekr. Ing.

Berufsgruppe

24©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 Graphbasierte Ansätze: Zuordnungsregeln

Funktionale AbhängigkeitWird direkt durch Kante zwischen beiden C-Knoten repräsentiert

N:M-BeziehungWird direkt durch Einführung eines X-Knotens repräsentiert

Berufsgruppe Beruf0 .. * 0 .. 1

C

C

Berufsgruppe

Beruf

Geschlecht Jahr0 .. * 0 .. *

C C

Geschlecht Jahr

X

13

25©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 Graphbasierte Ansätze: weitere Knotentypen

Terminale Knoten (tn-Knoten)Repräsentation eines der möglichen Werte aus dem Wertebereich des übergeordneten KategorieattributesBeispiel: „männlich“, „weiblich“ für „Geschlecht“

Summenknoten (S-Knoten)Explizite Spezifikation des quantitativen Teils eines Objektgraphen (Mehrfachverwendung von Graphen)Beispiel: „mittleres Einkommen“, „Anteil am Gesamteinkommen“ zu X-Knoten

Topic-Knoten (T-Knoten)Repräsentation einer Menge statistischer ObjekteDekomposition statistischer Sachverhalte

Logische Verbindung von S-Knoten

26©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 Graphbasierte Ansätze: Modellierung der Abstraktion

Aggregation (A-Knoten)Zusammenfassung logisch zusammengehöriger EinzelfaktenBeispiel: (Straße, Stadt, Land) zu Wohnort, (PersNr, Name, Wohnort, Beruf) zu Erwerbstätige

Generalisierung (G-Knoten)Definition einer übergeordneten Klasse abstrakter Objekte

Beispiel: Erwerbstätige, Erwerbslose zu Erwerbsperson

14

27©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 weitere Notationen

Erweiterungen von ER:Dimensional Fact Modeling

ADAPTApplication Design for Analytical Processing Technologies Beschreibung sämtlicher Metadaten-Objekte

Aber: keine formale Grundlage

Graphbasiert:SUBJECT, GRASS, STORM, ADaS, …

Zur Zeit kein Standard verfügbarGraphbasierte Ansätze zwar mächtig + flexibel, aber kaum verbreitet

28©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.2 TAFELÜBUNG: Konzeptuelle Modellierung

Gegeben: meteorologische Daten 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.

15

29©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

Dimensionen: Großwetterlage, Geographie, Zeit

3.2 TAFELÜBUNG: Ergebnis

Wetter

Temperatur

Luftfeuchtigkeit

HochTief

Stadt

Tag

Region

Monat

Woche

Jahr

Bundesland

30©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

Kapitel 3: Überblick

3.1 Data-Warehouse-Designprozess3.2 Konzeptuelle Datenmodellierung

3.3 Formalisierung und AnalyseoperationenMotivationDefinitionenOperationen

3.4 Umsetzung des multidimensionalen Datenmodells

3.5 Zusammenfassung

16

31©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Motivation: Beispiel multidimensionales Schema

Verkauf

Anzahl

Umsatz

Artikel

Filiale

Tag

Gruppe

Stadt

Monat

Woche

Familie

Bezirk

Quartal

Kategorie

Region

Jahr

Einkauf

Menge

Preis

VK-Preis

Lager

Lagerbestand

Es befinden sich 4 Würfel in der Datenbank

Nämlich: Verkauf, Einkauf, Preis, Lager

Mit den Dimensionen: Produkt, Zeit, Geographie, Kunde

Kunde Alter

32©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Schema einer Dimension

Schema einer Dimension DSPartiell geordnete Menge von Kategorienattributen ({K1, …, Kn, TopD}; →)

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 bestimmtGibt feinste Granularität einer Dimension vor:

∃i, 1 ≤ i ≤ n, ∀ j, 1 ≤ j ≤ n, i ≠ j, Ki → Kj

Beispiel für die Zeitdimension DSZeit = ({Tag, Woche, Monat, Quartal, Jahr, TopZeit) mit den funktionalen Abhängigkeiten

Tag → WocheTag → Monat → Quartal → JahrTag → TopZeit, Woche → TopZeit, Quartal → TopZeit, Jahr → TopZeit

17

33©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Kategorienattribute

Inhaltliche Verfeinerung durch unterschiedliche RollenPrimärattribut

Kategorienattribut, das alle anderen Attribute einer Dimension bestimmt

Definiert maximale FeinheitBeispiel: „Tag“

KlassifikationsattributElement der Menge, die mehrstufige Kategorisierung (Klassifikationshierarchie) bildenBeispiel: „Monat“, „Quartal“

Dimensionales AttributElement der Menge der Attribute, die vom Primärattribut oder einem Klassifikationsattribut bestimmt werden und nur TopD bestimmenBeispiel: „Artikelnummer“ zu Artikel

34©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Kategorienattribute : Beispiel

Verkauf

Anzahl

Umsatz

Artikel

Filiale

Tag

Gruppe

Stadt

Monat

Woche

Familie

Bezirk

Quartal

Branche

Region

Jahr

KlassifkationsattributePrimärattribut

Kunde Alter

Dimensionales Attribut

18

35©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Kennzahlen / Fakten

Kennzahlen/Fakten (engl. facts):(verdichtete) numerische MessgrößenBeschreiben betriebswirtschaftliche Sachverhalte

Fakt: BasiskennzahlKennzahl:

aus Fakten konstruiert (abgeleitete Kennzahl)Durch Anwendung arithmetischer Operationen

Beispiele: Umsatz, Gewinn, Verlust, DeckungsbeitragEin Fakt F eines multidimensionalen Schemas ist definiert als Tupel

F:= (G, SumTyp) mit G := {DS1.K1, …, DSn.Kn} bezeichnet die Granularität des betrachteten Schemas mit

DS1, …, DSn im Schema existierende Dimensionsschemata mit DSi = ({Ki1, …, Ki

m}, )∀ i, p mit 1 ≤ i, p ≤ n, i ≠ p: ¬ (DSi.Ki → DSp.Kp), d.h. keine funktionale Abhängigkeit zwischen Kategorienattributen einer GranularitätBeispiel: GVerkauf1 = (Produkt.Gruppe, Zeit.Monat, Geographie.Stadt)

Summationstyp SumTyp (bestimmt, welche Aggregrationsfunktion auf Fakt / Kenngröße angewendet werden darf)

36©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Kennzahl

Kennzahl M ist definiert als Tripel M = (G, f(F1, …, Fk), SumTyp) mitGranularität GBerechnungsvorschrift f()

Summationstyp SumTypBerechnung über nichtleerer Teilmenge der im Schema existierenden Fakten

Berechnungsvorschrift Bildung von f()

Skalarfunktionen• +, -, *, /, mod• Beispiel: Umsatzsteueranteil = Menge * Preis * Steuersatz

Aggregatfunktionen• 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)

19

37©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Summationstyp

erlaubte AggregationsoperationenFLOW

Beliebig aggregierbarBeispiel: Bestellmenge eines Artikels pro Tag

STOCKBeliebig aggregierbar mit Ausnahme temporaler Dimension

Beispiele: Lagerbestand, Einwohnerzahl pro Stadt

VALUE-PER-UNIT (VPU)Aktuelle Zustände, die nicht summierbar sindZulässig nur: MIN(), MAX, AVG()Beispiele: Wechselkurs, Steuersatz

38©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Summierbarkeit

+++COUNT

+++AVG

-+-+SUM

+++MIN/MAX

JaNein

VPUSTOCK: Aggregration über temporale Dimension?

FLOW

20

3.3 Weitere Eigenschaften

DisjunktheitEin konkreter Wert einer Kennzahl geht exakt einmal in Ergebnis einBsp.: Studierende im Grundstudium

VollständigkeitKennzahlen auf höherer Aggregationsebene lassen sich komplett aus Werten tieferer Stufen berechnen

49243225Gesamt

21111510BWL

28131715Informatik

Gesamt 200120001999Studierende

118117Gesamt

2220Augsburg

5052Stuttgart

4645Ulm

20022001Restaurants

40©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Multidimensionaler Datenwürfel für Verkauf

Produkt

Artikel

Zeit

Filiale

Stadt

Bundesland

Kategorie

Quartal

Halbjahr

Jahr

Geographie

KennzahlUmsatz

Dimension

Kategorienattribut

Aus Darstellungsgründen im Folgenden Abstraktion von

Dimension Kunde

21

41©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Würfel

Würfel (engl. cube, eigentlich Quader):Grundlage der multidimensionalen AnalyseKanten DimensionenZellen ein oder mehrere Kennzahlen (als Funktion der Dimensionen)Anzahl der Dimensionen DimensionalitätVisualisierung

2 Dimensionen: Tabelle3 Dimensionen: Würfel>3 Dimensionen: Multidimensionale Domänenstruktur

Schema W eines Würfels ist definiert als Tupel W(G, M) mitGranularität GMenge der Kennzahlen M = (M1, …, Mm)

Beispiel: Verkauf((Produkt.Artikel, Zeit.Tag, Geographie.Filiale), (Verkauf, Umsatz))

Instanz eines Würfels wird durch das Kreuzprodukt der Wertebereiche aller am Würfelschema beteiligten Attribute definiert (formal: WI ⊆ dom(G) × dom(M))

Beispiel für eine Würfelzelle des Verkaufswürfels: ((„Milch“, „22.02.05“, „Filiale Ulm“),(5, 4.95))

In multidimensionalen Schemata gilt Orthogonalität, d.h.Keine funktionalen Abhängigkeiten zwischen Attributen unterschiedlicher Dimensionen∀ i, 1 ≤ i ≤ n, ∀ j, 1 ≤ j ≤ n, i ≠ j, ¬ ∃ k, l : DSi.Kk DSj.Kl

Aus Darstellungsgründen im Folgenden Abstraktion von

Dimension Kunde

42©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 TAFELÜBUNG: Formalisierung konzeptuelles Modell

Gegeben: unsere Wetterstation MetWatchWie 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))

22

43©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Grundoperatoren

Restriktion: Gegeben W((D1.K1, …, Dn.Kn), (M1, …, Mk)), Prädikat PRestriktion ist definiert als σP(W) = {z ∈ W | P(z)}, falls alle Variablen in P

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: Wselect = σ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

Verbinden Kennziffern aus verschiedenen Würfeln zu einer neuen Kennzahl

Gegeben: W1(G1, M1), W2(G2, M2) lassen sich verbinden ⇔ G1 = G2 :=GVerbund der Zellen wird über ihre Kennzahlen durchgeführt

Ergebnis W:= W1 W2 mit W(G, M1 ∪ M2)

3.3 Pivotierung / Rotation

Drehen des Würfels durch Vertauschen der Dimensionen Analyse der Daten aus verschiedenen Perspektiven

Produkt

Zei

tGeo

graphi

e

Zeit

Geo

gra

ph

iePro

dukt

Geographie

Pro

du

ktZei

t

Zeit

Pro

du

ktGeo

graphi

e

Produkt

Geo

gra

ph

ieZei

t

Geographie

Zei

tPro

dukt

23

45©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Roll-Up / Drill-Down / Drill-Across

Roll-Up:Erzeugen neuer Informationen durch Aggregierung der Daten entlang des KonsolidierungspfadesDimensionalität bleibt erhalten

Beispiel: Tag → Monat → Quartal → Jahr

Drill-Down:komplementär zu Roll-UpNavigation von aggregierten Daten zu Detail-Daten entlang der Klassifikationshierarchie

Drill-Across:Ausweisen von Kennzahlen bzgl. einer anderen Klassifikationshierarchie bzw. Dimension

Also: „Wechsel von einem Würfel zu einem anderen“

46©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Drill Down / Roll-up (2)

Pro

du

ktGeo

graphi

e

1. Q

uarta

l2.

Qua

rtal

3. Q

uarta

l4.

Qua

rtal

Zeit

Drill-Down

Pro

du

ktGeo

graphi

e

Zeit

Jan.

Feb.

Mär

zApr

ilM

aiJu

ni Juli

Aug.

Sept.

Okt

.Nov

.Dez

.

Roll-up

24

47©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Slice and Dice (1)

Erzeugen individueller SichtenSlice:

Herausschneiden von „Scheiben“ aus dem Würfel durch Punkt- oder Listeneinschränkungen auf KlassifikationsattributenVerringerung der DimensionalitätBeispiel: alle Werte des aktuellen Jahres in den Filialen Ulm und Bonn (Jahr = „2006“, Filiale IN („Ulm“, „Bonn“))

Dice:Herausschneiden einen „Teilwürfels“Erhaltung der Dimensionalität, Veränderung der Hierarchieobjekte

Beispiel: die Werte bestimmter Produkte oder Regionen

48©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.3 Slice and Dice

Zeit

Geo

gra

ph

iePro

dukt

Slicing:

Zeit

Geo

gra

ph

iePro

dukt

Zeit

Geo

gra

ph

iePro

dukt

Dicing:

25

49©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

Kapitel 3: Überblick

3.1 Data-Warehouse-Designprozess3.2 Konzeptuelle Datenmodellierung

3.3 Formalisierung und Analyseoperationen

3.4 Umsetzung des multidimensionalen DatenmodellsRelationale Speicherung

Multidimensionale Speicherung

3.5 Zusammenfassung

50©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Allgemeine Anmerkungen

Multidimensionale SichtModellierung der DatenAnfrageformulierung

Interne Verwaltung der Daten erfordert Umsetzung aufROLAP (relationales OLAP), Umsetzung der multidimensionalen Struktur in Relationen

Vorteile: • relationale DBMS weit verbreitet

• Ausgereifte Technologie

Nachteile:• Umsetzung der multidimensionalen Strukturen als Relationen:

• Welche Nachteile ergeben sich hieraus?

26

51©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Allgemeine Anmerkungen

MOLAP (multidimensionales OLAP), direkte Speicherung in multidimensionalen Strukturen

Vorteile:• Keine Transformationen notwendig

Nachteile:• Zellen können unter Umständen nur dünn besetzt sein (sparsity)

• Skalierbarkeit

Hybrid, also Kombination von ROLAP und MOLAPVorteile beider VariantenNachteil: Komplexität

Wesentliche Aspekte bei der Umsetzung multidimensionaler Strukturen:

Speicherung

Anfrageformulierung bzw. -ausführung

52©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Relationale Speicherung: Anforderungen

Informationen aus dem multidimensionalen Modell (z.B. Klassifikationshierarchien) sollen nicht verloren geheneffiziente Ü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)

27

53©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Relationale Speicherung: Faktentabelle

Ausgangspunkt: Umsetzung des Datenwürfels ohne Klassifikationshierarchien

Dimensionen, Kennzahlen Spalten der RelationZelle Tupel

Primärschlüssel: Artikel, Filiale, TagKenngrößen (measure, häufig numerisch): VerkaufResultierende Tabelle heißt Faktentabelle (fact table)

Produkt

Zeit

Geographie 21420.04.06StuttgartMelitta

50021.04.06UlmJacobs

20020.04.06UlmMelitta

VerkaufTagFilialeArtikel

Melitta

Jacobs

Ulm Stuttgart

20.04.0621.04.06

Aus Darstellungsgründen im Folgenden Abstraktion von

Dimension Kunde

54©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Relationale Speicherung: Snowflake-Schema (1)

Klassifikationsstufen werden jeweils als eine Tabelle abgebildet (z.B. Artikel, Produktgruppe, etc.)Tabelle enthält

ID für Klassifikationsknotenbeschreibendes Attribut (z.B. Marke, Hersteller, Bezeichnung)Fremdschlüssel der direkt übergeordneten Klassifikationsstufe

Faktentabelle enthält (neben Kenngrößen):Fremdschlüssel der jeweils niedrigsten KlassifikationsstufeFremdschlüssel bilden zusammengesetzte Primärschlüssel für Faktentabelle

Vorteile:

Nachteile:

28

3.4 Relationale Speicherung: Snowflake-Schema (2)

ArtikelIDTagID

FilialeIDVerkäufe Umsatz

Verkauf ArtikelID

Bezeichnung ProduktgruppeID

Marke …

Artikel

ProduktgruppeIDBezeichnung

ProduktfamilieID

Produktgruppe

ProduktfamilieIDBezeichnung

ProduktkategorieID

Produktfamilie

ProduktkategorieIDBezeichnung

Produktkategorie

FilialeIDBezeichnung

StadtID

Filiale

StadtIDBezeichnung

BezirkID

Stadt

BezirkIDBezeichnung

RegionID

Bezirk

RegionIDBezeichnung

LandID

Region

LandIDBezeichnung

Land

TagIDBezeichnung

MonatIDWochenID

Tag

WochenIDBezeichnung

JahrID

Woche

MonatIDBezeichnung

QuartalID

Monat

QuartalIDBezeichnung

JahrID

Quartal

JahrIDBezeichnung

Jahr

1

n

1

n

1

n

1

n

1

n

1

n

1

n

1

n

1

n

n

1

1

n

n

1

n

1

n

1

1

n

Aus Darstellungsgründen im Folgenden Abstraktion von

Dimension Kunde

3.4 Relationale Speicherung: Snowflake-Schema (3)

ArtikelIDTagID

FilialeIDVerkäufe Umsatz

Verkauf ArtikelID

Bezeichnung ProduktgruppeID

Marke …

Artikel

ProduktgruppeIDBezeichnung

ProduktfamilieID

Produktgruppe

ProduktfamilieIDBezeichnung

ProduktkategorieID

Produktfamilie

ProduktkategorieIDBezeichnung

Produktkategorie

FilialeIDBezeichnung

StadtID

Filiale

StadtIDBezeichnung

BezirkID

Stadt

BezirkIDBezeichnung

RegionID

Bezirk

RegionIDBezeichnung

LandID

Region

LandIDBezeichnung

Land

TagIDBezeichnung

MonatIDWochenID

Tag

WochenIDBezeichnung

JahrID

Woche

MonatIDBezeichnung

QuartalID

Monat

QuartalIDBezeichnung

JahrID

Quartal

JahrIDBezeichnung

Jahr

1

n

1

n

1

n

1

n

1

n

1

n

1

n

1

n

1

n

n

1

1

n

n

1

n

1

n

1

1

n

Faktentabelle

FremdschlüsselZugehörige

1:n-Beziehung

Aus Darstellungs-gründen hier Abstraktion von Dimension Kunde

29

57©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 TAFELÜBUNG: Snowflake-Schema

Gegeben: unsere Wetterstation MetWatchGeben Sie die relationale Speicherung des Wetter-Würfels als Snowflake-Schema an.

StadtIDTagIDHTID

Temp. Luftf.

Wetter StadtID

Bezeichnung RegionID

Stadt

RegionIDBezeichnung BundeslandID

Region

BundeslandIDBezeichnung

Bundesland

HTIDBezeichnung

HochTief

TagIDBezeichnung

MonatIDWochenID

Tag

WochenIDBezeichnung

JahrID

Woche

MonatIDBezeichnung

QuartalID

Monat

JahrIDBezeichnung

Jahr

1

n

1

n

1

n

1

n

n

1

1

n

n

1

n

1

1

n

58©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Relationale Speicherung: Star-Schema (1)

Snowflake-Schema ist normalisiert:Vermeidung von Update-Anomalien Anfragen verursachen jedoch häufig „Monsterjoins“ (Joins über mehrere Tabellen)

deshalb Übergang zum so genannten Star-Schema:Die zu einer Dimension gehörenden Tabellen werden denormalisiert, also zu einer Dimensionstabelle (pro Dimension) „zusammengefasst“

Eine Konsequenz hieraus sind Redundanzen in der DimensionstabelleDiese Redundanzen erlauben jedoch eine schnellere AnfragebearbeitungBeispiel: Artikel, Produkt, Produktgruppe etc. als Spalten in einer Tabelle Produkt

Vorteile des Star-Schemas:Intuitive Umsetzung der multidimensionalen StrukturSchnellere Anfrageauswertung, keine „Monsterjoins“

Nachteile:Redundanzen aufgrund der DenormalisierungMehrfache Hierarchien können nicht direkt modelliert werden

30

59©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Relationale Speicherung: Star-Schema (2)

Dim1_Schlüssel

Dim2_Schlüssel

Dim3_Schlüssel

Measure1

Measure2

Measure3

Faktentabelle

Allgemeines Star-Schema

Dim1_Schlüssel

Dim1_Attribute

1. Dimensionstabelle

Dim2_Schlüssel

Dim2_Attribute

2. Dimensionstabelle

Dim3_Schlüssel

Dim3_Attribute

3. Dimensionstabelle

Dim4_Schlüssel

Dim4_Attribute

4. Dimensionstabelle

60©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Relationale Speicherung: Star-Schema (3)

ProduktID

ZeitID

GeographieID

Verkäufe

Umsatz

Verkauf

ProduktID

Artikel

Produktgruppe

Produktfamilie

Produktkategorie

Bezeichnung

Marke

Packungstyp

Produkt

ZeitID

Tag

Woche

Monat

Quartal

Jahr

Zeit

GeographieID

Filiale

Stadt

Bezirk

Region

Land

Geographie

n

1

n

n

1

1

StarKauf*-Szenario als Star-Schema modelliert

Aus Darstellungsgründen im Folgenden Abstraktion von

Dimension Kunde

31

3.4 Relationale Speicherung: Star-Schema (4)

Muster eines Star-Schemas: Multidimensionales Schema mit n DimensionenDimensionstabellen 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 DenormalisierungBeispiel: Zugehörigkeit eines Artikels zu Produktgruppe führt zu Zugehörigkeit zu Produktfamilie

Heißgetränke

Heißgetränke

Heißgetränke

Heißgetränke

Kaffee

Kaffee

Kaffee

Kakao

Filterkaffee

Filterkaffee

Espresso

Instant-Kakao

Melitta

Jacobs

Lavazza

Nesquik

123

124

125

126

…KategorieProduktfamilieProduktgruppe…ArtikelProduktID

62©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Vergleich von Star- und Snowflake-Schema (1)

Vorüberlegung: Wie sehen DWH-Anwendungen typischerweise aus?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-Schemasleicht verständliche Struktur Benutzer kann Anfragen intuitiver formuliereneffiziente Anfrageverarbeitung innerhalb einer Dimension (keine Join-Operation notwendig)Redundanzen aufgrund Denormalisierung und damit verbunden das Datenvolumen halten sich meistens in GrenzenGefahr von Update-Anomalien gering

32

63©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Vergleich von Star- und Snowflake-Schema (2)

Vergleiche basieren häufig auf für KostenbetrachtungenWir werden im Folgenden Kostenabschätzungen für Speicherbedarf und Anfragekomplexität für Snowflake- und Starschema erarbeiten

Annahmen hierzu: D Dimensionen, je K Klassifikationsstufen plus Top

Jeder Klassifikationsknoten hat 3 Kinder ⇒

M Fakten, gleich verteilt in DimensionenAttribut: b Bytes; Knoten haben nur ID;

f Faktattribute

64©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Vergleich von Star- und Snowflake-Schema (3)

33

65©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Vergleich von Star- und Snowflake-Schema (4)

66©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Vergleich von Star- und Snowflake-Schema (5)

Anfrage: Verkäufe der Produktgruppe „Soft-Drink“ pro Filiale und JahrSnowflake-Schema:

Anzahl der Joins: 6 (steigt linear mit Anzahl der Aggregationspfade)

34

67©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Vergleich von Star- und Snowflake-Schema (6)

Anfrage für Star-Schema:

Anzahl der Joins: 3 (unabhängig von der Länge der Aggregationspfade)

68©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Weitere Möglichkeiten

„Mix“ aus Snowflake-Schema oder Star-SchemaEntscheidung für jeweilige Dimension anhand der folgenden Fragen:

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?

Zusammenfassungen innerhalb des Star-Schemaseine Faktentabelle

mehrere Kennzahlen nur möglich bei gleichen DimensionenIm 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)mehrere Faktentabellen

teilweise mit gleichen Dimensionstabellen verknüpft

35

69©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Fact Constellation

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

Hierzu nötig: Unterscheidung in Dimensionstabelle über spezielle Attribute (z.B. „Stufe“, siehe Abbildung auf Folie 72)

Alternative: die Aggregrate werden in eigenen Faktentabellen gehaltenDiese Art von Schema wird Fact-Constellation-Schema genannt (da mehrere Faktentabellen) und ist ein Spezialfall des Galaxie-Schemas.

Einführung des zusätzlichen Attributes „Stufe“ ist nicht nötigWürfel, die durch Aggregation auseinander hervorgehen, teilen sich entsprechende Dimensionen

3.4 Klassifikationshierarchien (1)

Horizontal: Modellierung der Stufen der Klassifikationshierarchie als Spalten der denormalisierten DimensionstabelleVorteil:

Nachteile:

SELECT DISTINCT Produktgruppe

FROM Produkt

WHERE Produktkategorie = „Heissgetraenk“

Heissgetraenk

Heissgetraenk

HeissgetraenkHeissgetraenk

Filterkaffee

Filterkaffee

EspressoInstant-Kakao

Melitta

Jacobs

LavazzaNesquik

123

124

125126

ProduktkategorieProduktgruppeArtikelProduktID

36

71©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Klassifikationshierarchien (2)

Vertikal (rekursiv): normalisierte Dimensionstabelle mit AttributenDimensions_ID: Schlüssel, der Beziehung zu Faktentabelle herstelltEltern_ID: Attributwert der Dimensions-ID der nächsthöheren Stufe

Vorteile:Einfache Änderung am Klassifikationsschema

Einfache Behandlung vorberechneter Aggregate

Nachteil:Self-Join für Anfragen einzelner Stufen (Bsp.: Produktgruppe innerhalb einer Kategorie)

RekursionSELECT L3.ElternID

FROM Produkt AS L1, Produkt AS L2, Produkt AS L3

WHERE L1.DimensionID = „Heissgetraenk“ AND

L2.ElternID = L1.DimensionID AND

L3.ElternID = L2.DimensionID

FilterkaffeeFilterkaffee

Heissgetraenk…Lebensmittel…

MelittaJacobs

…Filterkaffee…

Heissgetraenk…

ElternIDDimensionsID

72©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Klassifikationshierarchien (3)

Kombination von horizontaler und vertikaler DarstellungRepräsentation der Klassifikationsstufen als Spalten Spaltenbezeichner werden generisch gehaltenSpeicherung der Knoten aller höheren Stufen als TupelZusätzliches Attribut „Stufe“ Angabe der bezeichneten Klassifikationsstufe

Wie können bei der relationalen Abbildung Semantikverluste verhindert werden?

0

0

1

2

Heißgetränke

Heissgetraenk

NULL

NULL

Filterkaffee

Filterkaffee

Heissgetraenk

NULL

Melitta

Jacobs

Filterkaffee

Heissgetraenk

StufeStufe2_IDStufe1_IDDimesionsID

37

73©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Relationale Umsetzung multidimensionaler Anfragen

Hängt von der Abbildungsvariante für das Schema abMeistens Aggregatanfragen bestehend aus (n+1)-Wege-Verbund zwischen n Dimensionstabellen und der Faktentabelle Star-Join-AnfragemusterBeispiel: „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

3.4 CUBE-Operator (1)

Erweiterung in SQL: Gruppierung einer Eingaberelation nach mehreren Gruppierungskombinationen CUBE-Operator

SELECT Region, Prodfamilie, Jahr, SUM(Verkäufe) AS Verkäufe FROM …GROUP BY Region, Prodfamilie, Jahr;

12485831676615

555122506751…

1998199920001996199920001996

199920001998199920001996…

VideoVideoVideoAudioAudioAudioTV

TVTVVideoVideoVideoAudio

BayernBayernBayernBayernBayernBayernBayern

BayernBayernHessen HessenHessenHessen…

VerkäufeJahrProdfamilieRegionVerkauf

Einfache Gruppierungsbedingung

38

3.4 CUBE-Operator (2)

12485811831676616415555112140322…501349615625782…172382350806

199819992000NULL199819992000NULL199619992000NULLNULL1998…NULL199819992000NULL1996…199819992000NULL

VideoVideoVideoVideoAudioAudioAudioAudioTVTVTVTVNULLVideo…NULLVideoVideoVideoVideoAudio…NULLNULLNULLNULL

BayernBayernBayernBayernBayernBayernBayernBayernBayernBayernBayernBayernBayernHessen…HessenNULLNULLNULLNULLNULL…NULLNULLNULLNULL

VerkäufeJahrProdfamilieRegionVerkauf

(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

76©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 CUBE-Operator (3)

Nachteile dieser Lösung:Aufwendige Formulierung (aber automatische Generierung durch OLAP-Tools)Potenziell teure Verbundoperationen müssen für jede Teilanfrage neu ausgewertet werdenCUBE-Operator erzeugt alle möglichen Gruppierungskombinationen; andernfalls nur über lange UNION-Listen möglich

SELECT

Region, Prodfamilie, Jahr,

GROUPING(Region), GROUPING(Prodfamilie), GROUPING(Jahr),

SUM(Verkäufe) AS Verkäufe

FROM…

GROUP BY

CUBE(Region, Prodfamilie, Jahr)

39

77©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 CUBE-Operator (3)

Nachteile dieser Lösung:Aufwendige Formulierung (aber automatische Generierung durch OLAP-Tools)Potenziell teure Verbundoperationen müssen für jede Teilanfrage neu ausgewertet werdenCUBE-Operator erzeugt alle möglichen Gruppierungskombinationen; andernfalls nur über lange UNION-Listen möglich

SELECT

Region, Prodfamilie, Jahr,

GROUPING(Region), GROUPING(Prodfamilie), GROUPING(Jahr),

SUM(Verkäufe) AS Verkäufe

FROM…

GROUP BY

CUBE(Region, Prodfamilie, Jahr)

GROUPING liefert 1, falls auf Gruppierungsattribut angewandt und über dieses Attribut hinweg aggregiert wirdAndernfalls liefert GROUPING 0

Falls Gesamtsumme nicht zurück geliefert werden soll:

HAVING NOT(GROUPING(Prodfamilie) = 1AND GROUPING(Region) = 1AND GROUPING(Jahr) = 1)

78©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 CUBE-Operator(4): Pivotierung / Rotation (zur Erinnerung)

Produkt

Zei

tGeo

graphi

e

Zeit

Geo

gra

ph

iePro

dukt

Geographie

Pro

du

ktZei

t

Zeit

Pro

du

ktGeo

graphi

e

Produkt

Geo

gra

ph

ieZei

t

Geographie

Zei

tPro

dukt

40

79©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 CUBE-Operator (5)

806258291257SUMME

403137127139SUMME

1605142672004

1213734502003

1224951222002Hessen

403121164118SUMME

1755166582004

1705567482003

581531122002Bayern

SUMMETVAudioVideoVerkäufe

335102108125SUMME

SUMME

2004

2003

2002

Verkäufe

Hessen

Bayern

SUMME

Hessen

Bayern

SUMME

Hessen

Bayern

806258291257

160514267

175516658

2919210198

121373450

170556748

180648234

122495122

58153112

SUMMETVAudioVideo

mit 2 unterschiedlichen Pivotierungen

80©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 CUBE-Operator(6): Roll-Up (SQL99)

SELECT

Prodkategorie, Prodfamilie, Region, Land,

SUM(Verkäufe) AS VerkäufeFROM…

WHERE…GROUP BY

ROLLUP(Produktkategorie, Prodfamilie), ROLLUP(Land, Region)

Erzeugt: (Prodkategorie, Prodfamilie) kreuz (Land, Region)(Prodkategorie) (Land)() ()

zuerst dann

Bei 4 Gruppierungsattribute– Cube-Operator: 24 = 16 unterschiedl. Gruppierungen– Rollup-Operator: 3*3 = 9 unterschiedl. Gruppierungen

Rollup in dieser Dimension in folgenden Schritten:

d.h. A1, …, An-1, An

A1, …, An-1

A1

()

41

81©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 GROUPING Sets

Komplexeste Art der Gruppierung (in SQL:99)Argumente können selbst wieder Gruppierungen sein, außer GroupingSets.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

82©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Probleme der relationalen Speicherung

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 ?

42

83©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Multidimensionale Speicherung (1)

Verwendung unterschiedlicher Datenstrukturen für Datenwürfel und Dimensionen

Dimension:endliche, geordnete Liste von Dimensionswerten

Ordnung der Dimensionswerte

Würfel:Für n Dimensionen: n-dimensionaler Raum

m Dimensionswerte einer Dimension: Aufteilung des Würfels in m parallele EbenenZelle eines n-dimensionalen Würfels wird eindeutig über n-Tupel von Dimensionswerten identifiziert

Zelle kann ein oder mehrere Kennzahlen eines zuvor definierten Datentyps aufnehmenWir als Array gespeichert

häufig proprietäre Strukturen (und Systeme)

84©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Multidimensionale Speicherung (2)

Klassifikationsstufen:Wichtig: Knoten der höheren Stufen bilden weitere Ebenen

Ulm

Stuttgart

Baden-Württemberg

München

Bayern

Januar Februar

März 1. Quartal

Umsatz in Stuttgart im 1. Quartal

Umsatz in Baden-Württemberg im

Januar

43

85©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Multidimensionale Speicherung (3)

Vergleich Aggegration zur Laufzeit versus VorberechnungLaufzeit:

Berechnung aus Detaildatenhohe Aktualität, jedoch hoher Aufwandeventuell Caching

Vorberechnung:Berechnung und Eintragen der Aggregationswerte in entsprechende ZellenNeuberechnung nach jeder Datenübernahme notwendighohe Anfragegeschwindigkeit, jedoch Zunahme der Würfelgröße und Laufzeitaufwand

86©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Multidimensionale Speicherung (4)

Weitere DatenstrukturenVirtueller Würfel

Ergibt sich aus bestehenden Würfeln durch die Anwendung von Berechnungsfunktionen (z.B. Gewinn)

Teilwürfel (Kombination mehrerer Ebenen eines Würfels virtuell)Attribute

Merkmale einer Dimension Untermengen von Dimensionswerten können über Attribute identifiziert werden (z.B. „Produktfarbe“)

44

3.4 Multidimensionale Speicherung (5)

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|

Linearisierungsreihenfolge:D3

D1

D2

2019181716

1514131211

109876

54321

Hos

en (1

)H

emde

n (2

)R

öcke

(3)

Kle

ider

(4)

Män

tel (

5)

Januar (1)

Februar (2)

März (3)

April (4)

88©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Multidimensionale Speicherung (6)

Probleme bei der multidimensionalen Speicherung:ungünstige Linearisierungsreihenfolgen können zu schlechtem Anfrageverhalten führen!

Eventuell Abhilfe durch Caching

Skalierbarkeitsprobleme aufgrund dünn besetzter Datenräumeteilweise einseitige Optimierung bezüglich LeseoperationenReorganisation nach Änderungen an den Dimensionen kann aufwendig werden (da Dimensionswerte geordnet)

keine Standard für multidimensionale DBMS ( Spezialwissen notwendig)

45

89©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.4 Multidimensionale Speicherung (7)

Vergleich von multidimensionaler und relationaler SpeicherungWelche Faktoren spielen eine Rolle?

Relational (Star-Schema)ArraySpeicherungFaktoren

90©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

Kapitel 3: Überblick

3.1 Data-Warehouse-Designprozess3.2 Konzeptuelle Datenmodellierung

3.3 Formalisierung und Analyseoperationen

3.4 Umsetzung des multidimensionalen Datenmodells

3.5 Zusammenfassung

46

91©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

3.5 Zusammenfassung

Konzeptuelle Modellierung der Daten:Multidimensionale Erweiterungen vonEntity/Relationship-Modell (mE/R)

UML (mUML)Weitere Ansätze (z.B. graphbasiert)

Umsetzung der konzeptuellen Modellierung:Relational (ROLAP): Snowflake-Schema, Star-SchemaMultidimensional (MOLAP)

Hybrid (HOLAP): Kombination aus ROLAP und MOLAP

92©Stefanie Rinderle-Ma, Institut DBIS, Universität Ulm, WS 2008/09 – Kap. 3

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)