Antje HöllSeminar Data Warehousing - SS 2005 1 Speichermodelle.

Antje Höll Seminar Data Warehousing - SS 2005 1

Speichermodelle

Seminar Data Warehousing - SS 2005 2Antje Höll

Speichermodelle: Überblick

1. Relationale Speicherung (ROLAP) 1.1 Star Schema1.2 Snowflake Schema1.3 Mischformen1.4 Darstellungsarten für Klassifikationshierarchien

2. Multidimensionale Speicherung (MOLAP, HOLAP)2.1 Datenstrukturen2.2 Speicherung2.3 Grenzen der Datenhaltung2.4 HOLAP

3. Vergleich (ROLAP, MOLAP, HOLAP) 4. Fazit


1. Relationale Speicherung

ROLAP = Relational OLAP relationale Speicherung des multidimensionalen Datenmodells

ermöglicht eine multidimensionale Analyse auf einer relationalen Datenbank

Speicherung der aggregierten Daten in Relationen SQL als deskriptive Anfragesprache für das Datenmodell

Anforderungen möglichst geringer Verlust an anwendungsbezogener Semantik

(multidimensionalen Modell, z.B. Klassifikationshierarchien) effiziente Übersetzung multidimensionaler Anfragen effiziente Verarbeitung der übersetzten Anfragen einfache und schnelle Wartbarkeit der relationalen Tabellen

(z.B. Laden neuer Daten)


Faktentabelle relationale Speicherung eines Datenwürfels ohne Klassifikationshierarchien

Dimensionen, Kennzahlen Spalten der Relation Zelle Tupel

1. Relationale Speicherung

Abbildung der Klassifikationshierarchien: Star-, Snowflake-Schema oder Mischformen


1. Relationale Speicherung 1.1 Star-Schema

Faktentabelle: eine (zentrale) Faktentabelle enthält (Geschäfts-) Daten, die analysiert werden sollen

quantifizierende Daten Primärschlüssel: zusammengesetzt aus Fremdschlüsseln kann sehr viele Zeilen enthalten

Dimensionstabellen: denormalisiert pro Dimension nur eine Tabelle enthalten Attribute qualifizierende Daten jede Dimensionstabelle hat einen Primärschlüssel kleiner als Faktentabelle Zusammenhang zur Faktentabelle über

Fremdschlüsselbeziehungen



Beispiel:

KundenIDKundenNameGeschlechtAlter

ZeitIDTagWocheMonatQuartalJahr

ProduktIDArtikelProduktgruppeProduktfamilieProduktkategorieBezeichnungMarke…

GeoIDFilialeOrt Land Region…

KundenIDProduktIDZeitIDGeoID

AnzahlUmsatz

Kunde

Produkt

Verkauf

Geografie

1

n

1

1

1

n

n

n

Zeit


Vorteile: einfache Struktur

einfache und flexible Darstellung von Klassifikationshierarchien einfacher Aufbau der Dimensionstabellen

effiziente Anfrageverarbeitung innerhalb der Dimensionen (=schnellerer Datenzugriff)

weniger teure Verbundoperationen

Nachteile: Faktentabelle normalisiert und Dimensionstabellen

denormalisiert Redundanzen in Dimensionstabellen Änderungsanomalien



1. Relationale Speicherung 1.2 Snowflake-Schema

Faktentabelle: eine zentrale Faktentabelle verwaltet die Kennzahlen Dimensionsspalten bestehen aus Fremdschlüsseln auf die

Dimensionselemente der niedrigsten Stufe Primärschlüssel: zusammengesetzt aus Fremdschlüsseln

Dimensionstabellen: normalisiert für jede Klassifikationsstufe eigene Relation jede Dimensionstabelle besitzt einen Primärschlüssel enthalten Attribute Zusammenhang zur Faktentabelle über Fremdschlüsselbeziehungen Fremdschlüsselbeziehungen zwischen Dimensionen



Beispiel:KundenIDKundenNameGeschlechtAlter

TagIDBezeichnungMonatIDWocheID

ArtikeltIDBezeichnung ProduktgruppeIDMarke…

FilialeIDBezeichnungStadtID

KundenIDArtikelIDTagIDFilialeID

AnzahlUmsatz

Kunde

Artikel

Verkauf

Filiale

1

n

Tag

ProduktgruppeIDBezeichnungProduktfamilieID

Produktgruppe

1

n

1

n

ProduktfamilieIDBezeichnungProduktkategorieID

Produktfamilie

1

n

ProduktkategorieIDBezeichnung

Produktkategorie1

n

StadtIDBezeichnungRegionID

RegionIDBezeichnungLandID

Region

LandIDBezeichnung

Landn

1

Stadt

n

1 n 1 n

1

MonatIDBezeichnungQuartalID

MonatQuartalIDBezeichnungJahrID

Quartal

JahrIDBezeichnung

Jahr

WocheIDBezeichnungJahrID

Wochen

1 nn

1

1

n 1n

11

n


Vorteile: normalisierte Struktur

Vermeidung von Änderungsanomalien Tabellen der operativen Systeme bleiben von der

Struktur und dem Inhalt unverändert/unberührt

Nachteile: Normalisierung

hohe Anzahl an Tabellen erhöhte Zugriffskosten (höherer Join-Aufwand) schlechtere Performance



Star-vs. Snowflake-Schema Star-Schema: - Redundanzen kein so großes Problem

- selten Änderungen an Klassifikationen Änderungsanomalien kontrollierbar

Einschränkungen für Anfragen finden häufig auf höherer Granularitätsstufe statt beim Snowflake-Schema jedes Mal teure Verbundoperationen nötig entfällt beim Star-Schema deutliche Steigerung der

Anfragegeschwindigkeit

Struktur der Klassifikationen (Hierarchien) wird im Snowflake-Schema auch im Tabellennamen widergespiegelt

im Starschema wird die gesamte Klassifikation als eine Tabelle abgebildet

Fazit: Welches Schema geeignet ist, hängt vom Anwendungsprofil ab!

Mischform

1. Relationale Speicherung 1.3 Mischformen (1)


1. Factless Fact Tables Faktentabelle ohne Kenngrößen Verweis auf Dimensionen ausschließlich Fremdschlüsselspalten Datensätze repräsentieren Ereignisse, bei denen keine weiteren

Informationen, als das Ereignis selbst, anfallen

Beispiel:


KursNrKursName…

RaumNr…

LehrerNrLehrerNameGehalt…

MatrNrNameGeschlechtAlter

DatumTagMonatQuartalJahr

DatumRaumNrMatrNrKursNrLehrerNr

Studenten

Zeit

Einrichtungen

Kurse

Lehrer

1

n

n

n

n

n1

1

1

1

Anwesenheit


2. Galaxie-Schema mehrere unabhängige Faktentabellen teilweise gemeinsame Nutzung von Dimensionstabellen


LieferantIDLieferantNameLieferantenGrIDLieferantenGr

DatumTagMonatQuartalJahr

ProduktIDProduktNameProduktGruppe

FilialeIDFilialeOrt Land Region

KundenIDProduktIDDatumFilialeID

Verkaufsmenge

Lieferant

Produkt

Verkauf Filiale

Zeit

LieferantIDProduktIDDatumFilialeID

Einkaufsmenge

Einkauf

KundenIDKundenNameKundenGrIDKundenGr

Kunde


3. Fact Constellation - Schema

Speicherung vorberechneter Aggregate eigene Tabelle für aggregierte Kenngrößen (fact constellation)

für jede Aggregationskombination eine eigene Fakttabelle nötig Trennung der aggregierten Werte von den atomaren Werte

schnellerer Zugriff auf die Aggregationen mit der Anzahl der Dimensionen steigt die Anzahl der Fakttabellen

explosionsartig an Modell sehr unübersichtlich und schwerer zu handhaben

Beispiel: Umsatz für eine Region



1. Relationale Speicherung 1.4 Darstellungsarten für Klassifikationshierarchien (1)

Horizontal Modellierung der Stufen der Klassifikationshierarchie als Spalten

der denormalisierten Dimensionstabelle Vorteil:

Einschränkungen auf höherer Granularität ohne Join Nachteil:

Duplikateliminierung beim Anfragen bestimmter Stufen, wie bspw. Produktgruppe in einer Kategorie relativ teuer, da Sortierung erforderlich

Produkt_ID Artikel Produktgruppe Produktfamilie Kategorie

1234 Lavamat S Waschmaschinen Waschgeräte weiße Ware

1235 Duett Waschmaschinen Waschgeräte weiße Ware

1236 Novotronic Trockner Waschgeräte weiße Ware

1237 Vento 500 Trockner Waschgeräte weiße Ware



Vertikal (rekursiv) Normalisierte Dimensionstabelle mit 2

Attributen Dimensions_ID Schlüssel, der die

Beziehung zur Faktentabelle schafft Eltern_ID Attributwert der Dimensions-

ID der nächsthöheren Stufe Vorteil:

einfache Änderung am Klassifikationsschema, da Tabellenschema keine Informationen über Klassifikationsschema hat

Nachteil: mehrere teure

Verbundoperationen für Anfragen einzelner Stufen nötig

Dimensions_ID Eltern_ID

Lavamat S Waschmaschinen

Duett Waschmaschinen

Novotronic Trockner

Vento 500 Trockner

Waschmaschinen Waschgeräte

Trockner Waschgeräte

Waschgeräte weiße Ware


Verbindung der Horizontal-und Vertikal-Strategie

Repräsentation der Klassifikationsstufen als Spalten –jedoch Stufen nicht mit den Namen der Klassifikationsstufen benannt

zusätzliches Attribut „Stufe“ zur Angabe, zu welcher Stufe das Tupel gehört


Dimensions_ID Stufe1_ID Stufe2_ID Stufe3_ID Stufe

Lavamat S Waschmaschinen Waschgeräte weiße Ware 0

Duett Waschmaschinen Waschgeräte weiße Ware 0

Novotronic Trockner Waschgeräte weiße Ware 0

Vento 500 Trockner Waschgeräte weiße Ware 0

Waschmaschinen Waschgeräte weiße Ware NULL 1

Trockner Waschgeräte weiße Ware NULL 1

Waschgeräte weiße Ware NULL NULL 2


Problem: bei allen genannten Abbildungsvarianten geht Semantik verloren

Gründe für Semantikverluste:

Unterscheidung zwischen Kennzahl und Dimension schwierig (Attribute der Faktentabelle)

Unterscheidung zwischen Attribute von Dimensionstabellen (beschreibend, Aufbau der Hierarchie) nicht möglich

Aufbau der Dimensionen geht verloren Wie verlaufen Drill-Pfade?

zusätzliches Attribut „Stufe“ zur Angabe der bezeichneten Klassifikationsstufe

Lösung:

Erweiterung des Systemkatalogs des relationalen DBMS um Metadatentabellen für multidimensionale Anwendungen



2. Multidimensionale Speicherung

MOLAP = Multidimensional OLAP multidimensionale Speicherung des multidimensionalen Datenmodells Speicherung der aggregierten Daten in speziellen multidimensionalen

Datenstrukturen Verwendung unterschiedlicher Datenstrukturen für Datenwürfel und

Dimensionen Speicherung basiert auf Arrays Ordnung der Dimension zur Adressierung der Würfelzellen notwendig basiert nicht auf SQL, sondern bedient sich eigener

Programmierschnittstellen wird von speziell dafür entwickelte Datenbanken ausgeführt

MDBMS


2. Multidimensionale Speicherung 2.1 Datenstrukturen (1)

Dimension:

endliche, geordnete Liste von Dimensionswerten enthält Dimensionselemente und die höheren

Klassifikationsstufen Dimensionswerte sind einfache unstrukturierte Datentypen

(String, Integer, Date) Ordnung der Dimensionswerte notwendig

(Ordnungszahlen: ganze Zahlen)


Würfel:

n Dimensionen spannen n-dimensionaler Raum auf m Dimensionswerte einer Dimension teilen den Würfel für diese

Dimension in m parallele Ebenen Zelle: Schnittpunkt von n Ebenen eines n-dimensionalen Würfels Zelle eines n-dimensionalen Würfels wird eindeutig über n-Tupel

von Dimensionswerten bestimmt Zellen können eine oder mehrere Kennzahlen eines zuvor

definierten Datentyps aufnehmen

W = ((D1, D2, …,Dn), (M1:Typ1, …, Mm: Typm))

Bsp.: Verkauf = ((Produkt, Filiale, Zeit), (Anzahl: integer, Umsatz: long))

2. Multidimensionale Speicherung 2.1 Datenstrukturen (2)


2. Multidimensionale Speicherung 2.2 Speicherung (1)

Array-Speicherung sequentielle Speicherung der Zellen des Würfels in n-dimensionales Array

mehrdimensionaler Würfel in eine eindimensionale Liste = Linearisierung

Indizes des Arrays bilden Koordinaten der Würfelzellen Berechnungsvorschrift für den Array-Index der Zelle z(x1, x2, ... xn) eines Würfels:

1 2 1 3 1 2 n 1 n-1

1

1 1

Index (z) = x + (x -1) · |D | + (x -1) · |D | · |D | + ... + (x -1) ·|D | · ... · |D |

= 1+ ( 1)in

i ji j

x D

D1

D2

D3


Adressberechnung in einem zweidimensionalen Datenwürfel

D1 = Produkt mit Werteliste (Hosen, Hemden, Röcke, Kleider, Mäntel)

D2 = Zeit mit Werteliste (Januar, Februar, März, April)

Ordnungszahlen stehen in Klammern

ges.: Indexwerte

1 2 11 ( 1) ( 1) 1 3 2 5 14x x D


1. Beispiel:

1 2 3 4 5

6 7 8 9 10

11 12 13 14 15

16 17 18 19 20

Hose

n (1

)He

mde

n (2

)Rö

cke (

3)Kl

eider

(4)

Mänte

l (5)

Februar (2)

Januar (1)

März (3)

April (4)


3-D Würfel Dimensionen D0, D1, D2 Dimensionsgrößen |D0|= 5, |D1|= 4, |D2|= 3

Reihenfolge der Würfelzellen in einem Array

ALL = summierte Werte pro Dimension 3-D Vektor V (v0, v1, v2)

0 1 1 2 2(( ( 1) )( 1))index v D v D v


2. Beispiel:

0

4

8

12

16

20

24

28

40


Zahl der Plattenzugriffe bei ungünstigen Linearisierungsreihenfolgen Reihenfolge der Dimensionen ist bei Definition des Würfels zu beachten Caching zur Reduzierung der Zugriffe notwendig

Speicherung dünn besetzter Würfel (leere, undefinierte Zellen)

beim Auslesen von Zellwerten müssen mehr Blöcke/Seiten übertragen werden leere Speicherblöcke/-seiten nicht physisch ablegen


Probleme:


Skalierbarkeitsprobleme aufgrund dünn besetzter Datenräume teilweise einseitige Optimierung auf schnelles Lesen Ordnung der Dimensionswerte wird bei Array-Speicherung

vorausgesetzt erschwert Änderungen an den Dimensionen

kein Standard für MDBMS Proprietär Spezialwissen für Erstellung und Wartung erforderlich

2. Multidimensionale Speicherung 2.3 Grenzen der Datenhaltung


Verbindung der Vorteile von ROLAP und MOLAP relational (Skalierbarkeit, Standard) multidimensional (analytische Mächtigkeit, direkte OLAP-

Unterstützung)

Speicherung: historische Detaildaten Relationale Datenbank aggregierte Daten Multidimensionale Datenbank

Zugriff erfolgt über die multidimensionale Datenbank durch ein multidimensionales Anfragewerkzeug

Aber: umfassende Kenntnisse aus beiden Welten notwendig enormer Implementierungsaufwand

2. Multidimensionale Speicherung 2.4 HOLAP


3. Vergleich: ROLAP, MOLAP, HOLAP (1)

ROLAP MOLAP HOLAPverwendet bewährte Datenbanktechnologie Standard-Abfragesprache (SQL) beliebige Skalierbarkeit effiziente Speicherung großer Datenmengen zahlreiche erfolgreiche DW-Lösungen basieren auf einer ROLAP-Architektur

Antwortzeiten bei kleineren Datenmengen sehr gut effiziente multidimensionale Speicherstrukturen meist eigene, multidimensionale Abfragesprache, intuitiv verständlicher als SQL

vereinigt das Beste aus ROLAP und MOLAPMDDB-System greift nicht mehr auf die operativen Systeme zu, sondern auf ein relationales DW

Vorteile:


3. Vergleich: ROLAP, MOLAP, HOLAP (2)

ROLAP MOLAP HOLAPStandard-SQL für multidimensionale Analysen nur bedingt ausreichendschlechtere Performance (durch Datenredundanz kompensierbar) langen Antwortzeiten durch direkten Zugriff auf große Datenmengen

proprietäre MDDB-Systeme werden eingesetzt, keine Abfragesprache als Standard definiert eingeschränktes Datenvolumen Schnittstelle zu einem RDBMS notwendig

umfangreiche Kenntnisse über ROLAP und MOLAP enormer Implementierungs-Aufwandkeine einheitliche OLAP-Abfragesprache

Nachteile:


ROLAP gut für dünn besetzte Würfel

setzt auf herkömmliche relationale Datenbanken auf Datenwürfel werden in mehrere flachen Tabellen gemäß dem

Star- Schema gespeichert Unterstützung großer Datenmengen - Skalierbarkeit

MOLAP gut für dicht besetzte Würfel

effizientere Speicherung durch Array-Speicherung primär für aggregierte Daten relevant, weniger zur Verwaltung

von Detail-Fakten

4. Fazit


Vielen Dank für die Aufmerksamkeit…

Antje HöllSeminar Data Warehousing - SS 2005 1 Speichermodelle.

Documents

Transcript of Antje HöllSeminar Data Warehousing - SS 2005 1 Speichermodelle.