ROLAP versus MOLAP

Data Warehousing
und
Data Mining
Speicherung multidimensionaler Daten
Ulf Leser
Wissensmanagement in der
Bioinformatik
Inhalt dieser Vorlesung
• Relationales OLAP (ROLAP)
–
–
–
–
–
Snowflake-, Star- und Fullfactschema
Speicherplatz und Queries
Änderungen in den Dimensionen
Schemavarianten
Beispiel: ROLAP in Oracle
• Evolution in Daten und Dimensionen
• Beispiel: ROLAP in Oracle
• Multidimensionales OLAP (MOLAP)
Ulf Leser: Data Warehousing und Data Mining
2
Relationales OLAP
• MDDM und relationales Modell nicht vergleichbar
– Konzeptionelle versus logische Ebene
– Falsch: „Relationales Modell ist zweidimensional, MDDM ist
beliebig-dimensional, das ist inkompatibel“
• Relationales Modell kann beliebig-dimensionale Daten
repräsentieren
• Verschiedene Abbildungen MDDM-Relational existieren
– Unterschiede in Speicherverbrauch, Redundanz, Performance
von INSERT/SELECT/UPDATE, ...
Ulf Leser: Data Warehousing und Data Mining
3
Beispielschema
year
month
day
shop_name
amount
sales
pg_name
shop
region
price
product_name
productgroup
Ulf Leser: Data Warehousing und Data Mining
product
region_name
4
Annahmen für Kostenbetrachtungen
• d Dimensionen, je k Klassifikationsstufen plus Top
• Jeder Klassifikationsknoten hat 3 Kinder
–
–
–
–
Level k:
Level k-1:
...
Level 0:
1=30 Knoten (Top)
3=31 Knoten
Höchste Granularität, 3k Knoten
i
3
• Zusammen: n= ∑
Knoten pro Dimension
i = 0...k
•
•
•
•
m Fakten, gleichverteilt in allen Dimensionen
Attribut: b Bytes
Knoten haben nur ID
Es gibt f Measures
Ulf Leser: Data Warehousing und Data Mining
5
Gleichmäßige Klassifikationshierarchie
Zu jedem Knoten gibt es gleich viele Kinder/Fakten
Top
Level 2
K1
Level 1
Level 0
K1.1
K1.2
K2
K1.3
Fakten
Ulf Leser: Data Warehousing und Data Mining
...
K2.1
K2.2
...
K3
K2.3
K3.1
K3.2
K3.3
...
6
Beispielquery
year
month
day
shop_name
amount
sales
pg_name
shop
region
price
product_name
productgroup
product
region_name
Summe aller Verkäufe
der Produktgruppe „Wasser“
nach Shop und Jahr
Ulf Leser: Data Warehousing und Data Mining
7
Variante 1 - Snowflake
year
productgroup
id
year
id
pg_name
product
month
id
month
year_id
day
id
day
month_id
sales
product_id
day_id
shop_id
amount
price
id
product_name
pg_id
shop
id
shop_name
region_id
region
id
region_name
Ulf Leser: Data Warehousing und Data Mining
8
Snowflake Schema
• Faktentabelle
– Measures plus Fremdschlüssel der kleinsten Klassifikationsstufe
jeder Dimension
• Dimensionstabellen
– Eine Tabelle pro Klassifikationsstufe
– Attribute: Knotenattribute und ID
– Ein Tupel pro Klassifikationsknoten
• Eigenschaften
– Voll normalisiert
– Speicherplatz:
Fremdschlüssel je
Dimension
Ulf Leser: Data Warehousing und Data Mining
Ein Tupel pro
Klassifikationsknoten
jeder Dimension
((d + f )* m + d * n )* b
Measures
9
Snowflake - Query
SELECT
FROM
WHERE
X.shop_name, y.year, sum(amount*price)
sales S, ... PG, P, D, M, Y, shop X
PG.name=„Wasser“ AND
PG.id = P.pg_id AND
P.id = S.product_id AND
D.id = S.day_id AND
M.id = D.month_id AND
Y.id = M.year_id AND
X.id = S.shop_id
group by X.shop_name, Y.year
• 6 Joins
– 4 Joins, wenn shop_name / year nicht notwendig
• Anzahl Joins steigt in jeder Dimension linear mit Länge
der Aggregationspfade in der Anfrage
Ulf Leser: Data Warehousing und Data Mining
10
Variante 2: Star Schema
product
product_id
product_name
pg_id
pg_name
time
day_id
day
month_id
month
year_id
year
sales
product_id
day_id
shop_id
amount
price
localization
shop_id
shop_name
region_id
region_name
Ulf Leser: Data Warehousing und Data Mining
11
Star Schema
• Faktentabelle
– Measures plus Fremdschlüssel der kleinsten Klassifikationsstufe
jeder Dimension
• Dimensionstabellen
– Eine Tabelle pro Dimension
– Attribute: ID und Knotenattribute aller Klassifikationsstufen
– Ein Tupel pro Klassifikationsknoten mit Level 0
• Eigenschaften
– Denormalisierte Dimensionen
– Speicherplatz
Ein Tupel pro
Klassifikationsknoten Level 0
((d + f )* m + d * 3
k
)
* k *b
Ein Attribut pro Klassifikationsstufe
Ulf Leser: Data Warehousing und Data Mining
12
Star - Query
SELECT
FROM
WHERE
group by
L.shop_name, T.year, sum(amount*price)
sales S, product P, time T, localization L
P.pg_name=„Wasser“ AND
P.product_id = S.product_id AND
T.day_id = S.day_id AND
L.shop_id = S.shop_id
L.shop_name, T.year
• 3 Joins
– Keine Reduktion wenn Jahrname nicht notwendig
– 2 Joins, wenn Shopname nicht notwendig
• Anzahl Joins
– Unabhängig von Länge der Aggregationspfade in der Anfrage
– Steigt linear mit der Anzahl Dimensionen in der Anfrage
Ulf Leser: Data Warehousing und Data Mining
13
Variante: Knotenattribute im Star Schema
• Eigenen Tabellen pro Klassifikationsstufe
– Dimensionstabelle repräsentiert Hierarchie und enthält nur Keys
– Normalisiert, speicherplatzeffizient, ggf. zusätzliche Joins
• Dimensionstabelle
– Keys mehrfach vorhanden, zusätzlichen Joins für „sprechende“
Attribute notwendig
sales
Product_id
Day_id
Shop_id
amount
price
localization
shop_id
region_id
country_id
continent_id
Ulf Leser: Data Warehousing und Data Mining
shop
shop_id
shop_name
region
address
region_id
manager
facilitiesname country
size
...
country_id
...
name continent
size
continent_id
...name
...
14
Variante 3: Fullfact
productgroup
year
id
pg_name
id
year
product
month
id
month
year_id
day
id
day
month_id
sales
product_id
pg_id
day_id
month_id
year_id
shop_id
region_id
amount
price
id
product_name
pg_id
shop
id
shop_name
region_id
region
id
region_name
Ulf Leser: Data Warehousing und Data Mining
15
Fullfact
• Faktentabelle
– Measures plus Fremdschlüssel jeder Klassifikationsstufe
• Dimensionstabellen
– Eine Tabelle pro Klassifikationsstufe
– Attribute: Knotenattribute und ID
– Ein Tuple pro Klassifikationsknoten
• Eigenschaften
– Normalisierte Dimensionen, denormalisierte Fakten
– Speicherverbrauch
((d * k + f )* m + d * n )* b
Ein FK pro Klassifikationsstufe
Ulf Leser: Data Warehousing und Data Mining
16
Fullfact Query
SELECT
FROM
WHERE
X.shop_name, T.year, sum(amount*price)
sales S, productgroup PG, year Y, shop X
PG.pg_name=„Wasser“ AND
PG.id = S.pg_id AND
Y.id = S.year_id AND
X.id = S.shop_id
group by X.shop_name, Y.year
• 3 Joins (1 Join, wenn Shopname/Jahrname unnötig)
• Wichtiger Effekt (Vergleich zu Star Schema): DimTabs
sind kleiner in allen Klassifikationsstufen mit Level!=0
• Anzahl Joins
– Unabhängig von Länge der Aggregationspfade in der Anfrage
– Steigt linear mit der Anzahl Klassifikationsstufen in der Anfrage
Ulf Leser: Data Warehousing und Data Mining
17
Speicherverbrauch 1
Speicherplatz nach Anz. Dim., M=106, K=4
25000000
Speicher
20000000
snowflake
15000000
star
10000000
fullfact
5000000
0
3
4
5
Dimensionen
Ulf Leser: Data Warehousing und Data Mining
18
Speicherverbrauch 2
Speicherplatz nach Anz. Fakten, D=4, K=4
2000000000
Speicher
1500000000
snowflake
star
1000000000
fullfact
500000000
0
1000000
10000000
100000000
Fakten
Ulf Leser: Data Warehousing und Data Mining
19
Speicherverbrauch 3
Speicherplatz nach Anz. K-Stufen, M=106, D=4
25000000
Speicher
20000000
snowflake
15000000
star
10000000
fullfact
5000000
0
3
4
5
Klassifikationsstufen
Ulf Leser: Data Warehousing und Data Mining
20
Fazit – Speicher und Query
• Speicherverbrauch Snowflake / Star praktisch identisch
– Bedarf für Dimensionen vernachlässigbar
• Fullfact mit deutlich höherem Speicherverbrauch
– Dafür minimale Anzahl Joins (im Idealfall 0)
• Star braucht meist weniger Joins als Snowflake
• Laufzeitverhalten hängt von vielen Faktoren ab
–
–
–
–
–
Bereichs- oder Punktanfrage, Selektivität
Indexierung
Gruppierung und Aggregation
...
Aber: Joins sind tendenziell immer teuer
Ulf Leser: Data Warehousing und Data Mining
21
Inhalt dieser Vorlesung
• Relationales OLAP (ROLAP)
– Snowflake-, Star- und Fullfactschema
– Speicherplatz und Queries
– Schemavarianten
• Evolution in Daten und Dimensionen
– Änderung in den Werten
– Änderungen in der Struktur
• Beispiel: ROLAP in Oracle
• Multidimensionales OLAP (MOLAP)
Ulf Leser: Data Warehousing und Data Mining
22
Entartete DWH
• Anzahl Klassifikationsknoten nähert sich Anzahl Fakten
– Bsp.: Experimentelle Daten (Knoten = Gene, Werte =
Ergebnisse von Tests)
Speicherplatz nach Anz. Knoten, M=106, D=4
25000000
Speicher
20000000
snowflake
15000000
star
10000000
fullfact
5000000
0
100000
200000
300000
Klassifikationsknoten pro Dimension
Ulf Leser: Data Warehousing und Data Mining
23
Galaxy Schema
Mehrere Faktentabellen
Jahr
Monat
Tag
Lager
Produktgruppe
Produkt
Verkauf
Shop
Ulf Leser: Data Warehousing und Data Mining
Region
24
Constellation Schema
• Fact Constellation Schema = Star Schema mit eigenen
Summentabellen für prä-aggregierter Daten
• Alternative: Einbeziehung als “spezielle Fakten“ in
Faktentabelle
Summe über alle
Tage für P=2, S=130
Summe über alle
Tage und Produkte
für S=130
Verkauf
Day
Product
shop
3.99
1
2
130
14.80
1
2
130
12.98
1
4
130
16.02
1
4
130
18.79
NULL
2
130
29.00
NULL
4
130
47.79
NULL
NULL
130
Ulf Leser: Data Warehousing und Data Mining
25
Nicht-Standard Hierarchien
• Bisherige Annahmen: Jede Hierarchie
– ist balanciert: Blätter haben alle den gleichen Abstand zu Root
– hat eine feste maximale Tiefe
– ist eine Hierarchie: Jeder Knoten hat nur einen Vorgänger
Top
Top
K1
K1.1
K1.2
K2
K1.3
K2.1
K2.2
K3
K2.3
K3.1
K2
K3.2
K3.3
Top
Top
K3
K1
K1.1
K1.2
K1.3
K2.1
K2.2
K1
K1.1
Ulf Leser: Data Warehousing und Data Mining
K1.2
K2
K1.3
K2.1
K2.2
…
K2.3
26
Unbalancierte Hierarchien
• Zuordnung von Produkten zu
Hauptgruppen, Teilung großer
Shops in Abteilungen,…
• Im Snowflake Schema
Top
Shop1
Shop2
Abt1
Abt2
Abt3
– Fakten mit „Fremdschlüsseln“ in mehrere Tabellen
– Klassifikationsknoten referenzieren verschiedene Elterntabellen
– DB kann beides nicht prüfen
• Eine Lösung: Auffüllen mit Dummy-Werte
– Jeder Shop bekommt eine NULL-Abteilung
– Einführung einer NULL Produktgruppe
– Müssen vom Client bei Ausgabe unterdrückt werden
• Im Starschema: Ebenso (Auffüllen mit NULLs)
Ulf Leser: Data Warehousing und Data Mining
27
Unbeschränkt tiefe Hierarchien
Top
• Unbeschränkt lange Klassenhierarchien
K2
– Stücklisten (Teil von ...)
– Stark variierende, länderspezifische
Organisationsstrukturen
– Auch „parent-child hierarchies“ genannt
• Weder in Star noch Snowflake möglich
…
– Snowflake: Verlängerung erfordert neue Tabellen
– Star: Verlängerung erfordert neue Attribute (und viele NULLs)
• Immer: Es ist unklar, wie viele Joins man braucht, um
ein komplettes Roll-Up zu berechnen
Ulf Leser: Data Warehousing und Data Mining
28
Modellierung über Selbst-Referenzialität
sales
product_id
time_id
shop_id
amount
price
product
id
level
name
predecessor_id
• Ermöglicht beliebige Hierarchien
– Umfasst auch unbalancierte Hierarchien
• Probleme
–
–
–
–
Rekursives SQL oder Traversierung über Host-Language nötig
Keine individuellen Attribute pro Stufe
Keine Unterstützung durch SQL-OLAP
Eingeschränkte referenzielle Integrität
– product_id könnte auf höheren Knoten in product zeigen
Ulf Leser: Data Warehousing und Data Mining
29
Nicht-hierarchische Hierarchien
• Knoten können mehrere
Vorgänger derselben Stufe haben
• Selbst-Referenzialität reicht nicht
mehr
• Rekursive Modellierung
Top
K1
K1.1
K1.2
K2
K1.3
K2.1
K2.2
– Gleiche Nachteile wie Selbst-Referenzialität
– Zuordnung von Werten bei Gruppierung nicht klar
sales
product_id
…
product
id
…
Ulf Leser: Data Warehousing und Data Mining
edges
child_id
predecessor_id
30
K2.3
Inhalt dieser Vorlesung
• Relationales OLAP (ROLAP)
– Snowflake-, Star- und Fullfactschema
– Speicherplatz und Queries
– Schemavarianten
• Evolution in Daten und Dimensionen
– Änderung in den Werten
– Änderungen in der Struktur
• Beispiel: ROLAP in Oracle
• Multidimensionales OLAP (MOLAP)
Ulf Leser: Data Warehousing und Data Mining
31
Änderungen in den Dimensionen
• DWH speichern Daten über lange Zeiträume
• In langen Zeiträumen passieren oftmals Änderungen
– In den Werten (Namen / Eigenschaften von Produkten, Status
von Kunden etc.)
– In den Dimensionsstrukturen (Neue Organisationsebenen,
Zusammenfassung von Produktgruppen, Auslistung, …)
• „Alte“ Fakten sollen im „alten“ Bezugsrahmen bleiben
• Echtes, ständig vorhandenes, schwieriges Problem
• Keine Silver Bullets, nur Workarounds
Ulf Leser: Data Warehousing und Data Mining
32
„Slowly Changing“ Dimensions
• Updates bei den Klassifikationsknoten einer Hierarchie
– Gemeint sind nicht Korrekturen (Buch hätte schon immer
„gebunden“ sein sollen), sondern Änderungen (Buch wurde
bisher nur gebunden verkauft, jetzt nur noch broschiert)
– Auch Deletes und Inserts – Knoten existieren nur in Zeiträumen
(mit unterschiedlichen Werten)
• Alte Werte sollten von alten Fakten adressiert werden,
neue Werte von neuen Fakten
• Ausführen des Updates führt zu Verfälschungen
– Verkäufe eines gebundenen Buchs vor Stichtag werden plötzlich
zu Verkäufen eines broschierten Buchs
• Lösung: Daten versionieren
Ulf Leser: Data Warehousing und Data Mining
33
Versionierungsmodelle
Linear
Hierarchisch
V1
V1
V2
V3
• Zu jeden Zeitpunkt
existiert von jedem
Tupel nur eine Version
• Standardmodell
Ulf Leser: Data Warehousing und Data Mining
V2
V3
V4
V5
V6
V7
• Zeitliche Reihenfolge
halbgeordnet
• z.B. in CVS
• Deutlich komplexer
34
Versionen im relationalen Modell
• RDBMS soll Versionen auf Tupelebene verwalten
– Änderung in einem Attribut – eine neue Version
– Änderungen in mehreren Attributen – eine neue Version
– Keine Schemaänderungen
• Anforderungen
– (Schneller) Zugriff auf aktuelle Version
– Zugriff auf Version zu beliebigem Zeitpunkt d0
• Zwei prominente Varianten
– Single-Table
– Schattentabellen
Ulf Leser: Data Warehousing und Data Mining
35
Variante 1: Single-Table
• Erweiterung jeder Tabelle T um die folgenden Attribute
–
–
–
–
Versionsnummer
ALIVE
VALIDFROM
Schlüsselveränderung id → (id, version)
product
product_id
name
packungsgröße
farbe
gewicht
Ulf Leser: Data Warehousing und Data Mining
product
product_id
version
alive
validfrom
name
packungsgröße
farbe
gewicht
36
INSERT
• INSERT Objekt k in T
– Gibt es k schon in T?
– Nein
• INSERT INTO T VALUES (id=k, version=0, alive=true,
validfrom=SYSDATE, …)
– Ja
• Letzte Version von k in T finden (v‘)
• k.v‘.alive=true ?
– Ja
» Fehlermeldung
– Nein
» INSERT INTO T VALUES (id=k, version=v‘+1, alive=true,
validfrom=SYSDATE, …)
Ulf Leser: Data Warehousing und Data Mining
37
DELETE
• DELETE Objekt k aus T
– Gibt es k schon in T?
– Nein
• Nichts tun
– Ja
• Letzte Version von k in T finden (v‘)
• k.v‘.alive=true?
– Ja
» INSERT INTO T VALUES (id=k, version=v‘+1, alive=false,
validfrom=SYSDATE, …)
» UPDATE T SET alive=false WHERE (id, version) = (k, v‘)
– Nein
» Nichts tun
Ulf Leser: Data Warehousing und Data Mining
38
UPDATE
• UPDATE Objekt k in T
– k in T vorhanden?
– Nein
• Nichts tun
– Ja
• Letzte Version von k in T finden (v‘)
• k.v‘.alive=true?
– Ja
» INSERT INTO T VALUES (id=k, version=v‘+1, alive=true,
validfrom=SYSDATE, …)
» UPDATE T SET alive=false WHERE (id, version) = (k, v‘)
– Nein
» Nichts tun
Ulf Leser: Data Warehousing und Data Mining
39
SELECT
• SELECT aktuellste Version von k
SELECT * FROM T
WHERE alive=true AND id=k;
• SELECT aktueller Zustand von T
SELECT * FROM T
WHERE alive=true;
• SELECT alle Tupel gültig zum Zeitpunkt d
SELECT * FROM T
WHERE validfrom = (SELECT MAX(validfrom)
FROM T1
WHERE T.id=T1.id AND
T2.validfrom <= d);
Vorsicht: Gelöschte Tupel werden
nicht korrekt behandelt
Ulf Leser: Data Warehousing und Data Mining
40
Bewertung
• Bewertung
– INSERT / DELETE / UPDATE erfordern Trigger
– Version/alive sollte in praktisch alle Indexe aufgenommen
werden
– Relativ schneller Zugriff auf aktuellste Version
• alive hat nur zwei Werte; schlechte Selektivität, also meist Scan
– Nur bei sehr vielen Änderungen steigt Selektivität und Index lohnt sich
• Tendenziell Verlangsamung durch wachsende Tabelle
– Schwierige Rekonstruktion alter Datenbestände
• Varianten
– Versionsnummer weglassen (Datum reicht eigentlich)
– VALIDFROM und VALIDUNTIL verwenden
• Einfachere Rekonstruktion, mehr Speicherplatz
Ulf Leser: Data Warehousing und Data Mining
41
Variante 2: Schattentabellen
• Anlegen einer Tabelle Ts pro Tabelle T
– Alle Attribute auf T plus
• Versionsnummer version
• validfrom und validuntil
– Schlüsselveränderung id → (id, version)
• Außerdem: T um Attribut validfrom erweitern
• TS speichert alte Versionen
• T speichert nur aktuellste Version
Ulf Leser: Data Warehousing und Data Mining
42
INSERT
• INSERT Objekt k in T
– k in T vorhanden ?
• Nein
– INSERT INTO T VALUES (id=k, validfrom=SYSDATE, …)
• Ja
– Fehlermeldung
Ulf Leser: Data Warehousing und Data Mining
43
Variante 2: DELETE
• DELETE Objekt k aus T
– k in T vorhanden ?
– Nein
• Nichts tun
– Ja
• Letzte Version von k in TS suchen (v‘)
• v‘ existiert nicht
– INSERT INTO TS VALUES (id=k, version=0, validuntil=SYSDATE, …)
• v‘ existiert
– INSERT INTO TS VALUES (id=k, version=v‘+1, validuntil=SYSDATE,
…)
• DELETE FROM T WHERE id=k
Ulf Leser: Data Warehousing und Data Mining
44
UPDATE
• UPDATE Objekt k in T
– k in T vorhanden?
– Nein
• Nichts tun
– Ja
• Letzte Version von k in TS finden (v‘)
• v‘ existiert nicht
– INSERT INTO TS VALUES( id=k, version=0, validuntil=SYSDATE, …)
• v‘ existiert
– INSERT INTO TS VALUES( id=k, version=v‘+1, validuntil=SYSDATE,
…)
• UPDATE T SET validfrom=SYSDATE, … WHERE id=k
Ulf Leser: Data Warehousing und Data Mining
45
SELECT
• SELECT aktuellste Version von k
SELECT * FROM T
WHERE id=k;
• SELECT aktueller Zustand von T
SELECT * FROM T;
• SELECT alle Tupel gültig zum Zeitpunkt d
– Kompliziert ....
• Alle k in T mit validfrom≤d nehmen
• Von allen anderen k: Wert von TS nehmen mit max(validuntil), aber
kleiner d
– Erfordert Zugriff auf T und TS
Ulf Leser: Data Warehousing und Data Mining
46
Bewertung
• Bewertung
– INSERT / DELETE / UPDATE erfordern Trigger
– Sehr schneller Zugriff auf aktuellste Version
• Kein Unterschied zu nicht-versioniert
– Komplexer Zugriff auf Zustand zu Zeitpunkt d
– Komplizierteres INSERT /DELETE / UPDATE
• Meistens zwei Tabellen betroffen
– Gut geeignet zur Archivierung (T bleibt unangetastet)
Ulf Leser: Data Warehousing und Data Mining
47
Vergleich
• Häufige Änderungen, eher wenig Lesezugriffe Variante 1
• Seltenere Änderungen, vor allem Zugriff auf aktuellste
Version – Variante 2
• Variante 2 eher für DWH geeignet
– Alle Zugriffe ohne Zeitbezug laufen ohne Änderungen
• Vorsicht vor unvorhergesehenen Effekten
(Indexdegradierung, Tabellenfragmentierung, etc.)
• Vorsicht vor Referenzen / Fremdschlüssel auf
versionierte Objekte
– Hier gibt es weitere implizite Integritätsconstraints
Ulf Leser: Data Warehousing und Data Mining
48
Inhalt dieser Vorlesung
• Relationales OLAP (ROLAP)
• Sich ändernde Dimensionen
– Änderung in den Werten
– Änderungen in der Struktur
• Beispiel: ROLAP in Oracle
• Multidimensionales OLAP (MOLAP)
Ulf Leser: Data Warehousing und Data Mining
49
Änderungen in Klassifikationshierarchie
• Auch Dimensionen verändern sich
• Mögliche Operationen
– Gelöschte / neue Klassifikationsknoten
– Gelöschte / neue Klassifikationsstufen
– Neue Dimensionen
• Aufwand für Operationen abhängig von Modellierung
• Im folgenden: Vier Operationen
Ulf Leser: Data Warehousing und Data Mining
50
Änderung: InsN
Einfügen eines neuen Klassifikationsknoten ohne
Nachkommen in einen Pfad auf Level i≠0
Top
Level 2
K1
Level 1
Level 0
K1.1
K1.2
K2
K1.3
Ulf Leser: Data Warehousing und Data Mining
K2.1
K2.2
K3
K2.3
K3.1
K4
K3.2
K3.3
51
Änderung: InsS
Einfügen einer neuen Klassifikationsstufe in einen Pfad
zwischen Level i und i-1 (i>1) mit 3(k+1)-i
Klassifikationsknoten mit Umhängen Knoten auf Level i-1
Level 3
Top
Level 2
K1
K2
K3
Level 1
K1.1
K1.2
K1.3
K2.1
K2.2
K2.3
K3.1
K3.2
K3.3
Level 0
K1.1
K1.2
K1.3
K2.1
K2.2
K2.3
K3.1
K3.2
K3.3
Ulf Leser: Data Warehousing und Data Mining
52
Änderung: DelN
Löschen eines Klassifikationsknoten in einem Pfad an
Level i≠0; Umhängen der Nachkommen auf beliebigen
anderen Knoten desselben Levels
Top
Level 2
K1
Level 1
Level 0
K1.1
K1.2
K2
K1.3
Ulf Leser: Data Warehousing und Data Mining
K2.1
K2.2
K3
K2.3
K3.1
K3.2
K3.3
53
Änderung: DelN0
Löschen eines Klassifikationsknoten in einem Pfad an
Level i=0; Umhängen der Fakten auf andere Knoten mit
Level 0
Top
Level 2
K1
Level 1
Level 0
K1.1
K1.2
K2
K1.3
Fakten
Ulf Leser: Data Warehousing und Data Mining
...
K2.1
K2.2
...
K3
K2.3
K3.1
...
K3.2
K3.3
...
54
Änderungskosten
Padding: NULL in Knoten mit Level j<i
Snowflake
Star
Fullfact
InsN
1 Insert
(1 Insert)
1 Insert
InsS
1 neue Tabelle,
3(k+1)-i Updates
(Umhängung)
1 neues Attribut,
3k Updates
(Wert des Attrib.)
1 neue Tabelle,
1 neues Attribut,
m Updates
(in Faktentabelle)
DelN
1 Delete,
3 Update
0 Delete,
3 Update
1 Delete,
m/3k-i Updates
(Level i: 3k-i Knoten)
DelN0
1 Delete,
m/3k Update
1 Delete,
m/3k Update
1 Delete,
m/3k Updates
Ulf Leser: Data Warehousing und Data Mining
55
Versionierung in Oracle
• Oracle Flashback (lineare Versionierung)
– Rücksetzen der Datenbank auf Status zu Zeitpunkt X
– Flashback-Queries (AS OF): Zugriff auf Daten zu Zeitpunkt X
– Änderungen werden gepuffert; UNDO-Buffergröße bestimmt
maximalen zeitlichen Abstand
– DDL Operationen zerstören UNDO Informationen
– Umsetzung tief im System, schnell, transparente Nutzung
• Workspace Manager (hierarchische Versionierung)
– Auf Tabellenebene (funktioniert mit einer Art Schattentabelle)
– Benutzung für WHAT-IF, oder versuchsweise große Änderungen
(ohne TX) mit anschliessendem MERGE
– Div. Einschränkungen bei Constraints, Trigger, etc.
– Umsetzung in PL/SQL Packages, eher langsam
Ulf Leser: Data Warehousing und Data Mining
56
Inhalt dieser Vorlesung
•
•
•
•
Relationales OLAP (ROLAP)
Evolution in Daten und Dimensionen
Beispiel: ROLAP in Oracle
Multidimensionales OLAP (MOLAP)
Ulf Leser: Data Warehousing und Data Mining
57
MDDM Konstrukte in Oracle
• Oracle Sprachelemente
– Dimensionen
– Klassifikationsstufen
– Klassifikationspfade
• Definition mit eigenen DDL Befehlen
• Setzen auf existierendes relationales Schema auf
– Star oder Snowflake
Ulf Leser: Data Warehousing und Data Mining
58
Beispiel: Snowflake Schema
sales
product_id
day_id
shop_id
amount
price
product
id
product_name
pg_id
productgroup
id
pg_name
CREATE DIMENSION s_pg
LEVEL product IS (product.id)
LEVEL productgroup IS (productgroup.id)
HIERARCHY pg_rollup (
product CHILD OF productgroup
JOIN KEY (pg_id)
REFERENCES productgroup
);
Ulf Leser: Data Warehousing und Data Mining
59
Beispiel: Star Schema
time
day_id
day
month_id
month
year_id
year
sales
product_id
day_id
shop_id
amount
price
1. Name eines Levels
2. Name eines Attributes
CREATE DIMENSION s_time
LEVEL day IS (time.day_id)
LEVEL month IS (time.month_id)
LEVEL year IS (time.year_id)
HIERARCHY pg_rollup (
day CHILD OF
month CHILD OF
year)
ATTRIBUTE day_id DETERMINES (day)
ATTRIBUTE month_id DETERMINES (month)
ATTRIBUTE year_id DETERMINES (year)
Ulf Leser: Data Warehousing und Data Mining
Ref. IC innerhalb
einer Tabelle
60
Multiple Pfade
Dimension
CREATE DIMENSION times_dim
LEVEL day IS TIMES.TIME_ID
LEVEL month IS TIMES.CALENDAR_MONTH_DESC
LEVEL quarter IS TIMES.CALENDAR_QUARTER_DESC
Klassifikationsstufen LEVEL year IS TIMES.CALENDAR_YEAR
LEVEL fis_week IS TIMES.WEEK_ENDING_DAY
LEVEL fis_month IS TIMES.FISCAL_MONTH_DESC
LEVEL fis_quarter IS TIMES.FISCAL_QUARTER_DESC
LEVEL fis_year IS TIMES.FISCAL_YEAR
HIERARCHY cal_rollup (
day CHILD OF
CHILD OF
Klassifikationspfad 1 month
quarter CHILD OF
year )
HIERARCHY fis_rollup (
day CHILD OF
CHILD OF
Klassifikationspfad 2 fis_week
fis_month CHILD OF
fis_quarter CHILD OF
fis_year )
<attribute determination clauses>...
Ulf Leser: Data Warehousing und Data Mining
61
Eigenschaften
• Vollständige und überlappungsfreie Hierarchien
– „The child_key_columns must be non-null and the parent key must be unique
and non-null. You need not define constraints to enforce these conditions,
but queries may return incorrect results if these conditions are not true.“
– „.. the joins between the dimension tables can guarantee that each child-side
row joins with one and only one parent-side row. In the case of denormalized
dimensions, determine whether the child-side columns uniquely determine
the parent-side (or attribute) columns. If you use constraints to represent
these relationships, they can be enabled with the NOVALIDATE and RELY
clauses if the relationships represented by the constraints are guaranteed by
other means.„
• Verwendung und Anzeige über PL/SQL Packages
– DEMO_DIM, DBMS_OLAP,…
• Sinn
– Für Query Rewrite (siehe „Materialisierte Sichten“)
– Für Client-Software / Visualisierung / Navigation
Ulf Leser: Data Warehousing und Data Mining
62
Inhalt dieser Vorlesung
•
•
•
•
Relationales OLAP (ROLAP)
Evolution in Daten und Dimensionen
Beispiel: ROLAP in Oracle
Multidimensionales OLAP (MOLAP)
Ulf Leser: Data Warehousing und Data Mining
63
Multidimensionales OLAP
• Grundidee: Speicherung multidimensionaler Daten in
multidimensionalen Arrays
• Tendenziell gibt das Probleme
– Range-Queries, Einbeziehung prä-aggregierter Daten
– Wenn Daten nicht in Hauptspeicher passen
– Siehe auch multidimensionale Indexstrukturen (später)
• Dafür rasend schnell für „passende“ Zugriffsmuster
• Im folgenden: Ein Würfel, ein Fakt
Ulf Leser: Data Warehousing und Data Mining
64
Klassifikationshierarchien
1999
2000
Modellierung als eingebettete Knoten der untersten Stufe
Jahr
Jahr
Q3
Q2
Q2
Q1
Q1
1999
Q4
Q4
Q3
Q3
Q2
Q2
Q1
Q1
Ulf Leser: Data Warehousing und Data Mining
65
Array Adressierung
• Sei di=|Di|, d Dimensionen,
• b: Speicherplatz pro Attribut (Key oder Wert)
• Linearisierte Darstellung
– <1,1,1>, <1,1,2>, ... , <1,1,d1>, <1,2,1>, ...
• Offset der Zelle <a1,...ad>
i −1


b * ∑  (ai − 1) * ∏ d j 
i =1 
j =1

d
Ulf Leser: Data Warehousing und Data Mining
66
Arrayspeicherung - Probleme
• Naive MOLAP: Unterschiedliche Performanz je nach
Reihenfolge der Dimensionen in Array / Anfrage
– Daten liegen nach Dn geordnet auf Platte
– Zugriff auf <2,2,X> - sequentieller Read
– Zugriff auf <X,1,3> oder <3,X,3> - Zugriff auf viele Blöcke
• Aber: RDBMS hat ähnliche Probleme
– Zugriff abhängig von Anordnung der Tupel auf der Platte
– Forschung: „Column stores“
• Problem: Speicherung verschiedener Werte pro Zelle
– Mehrere Verkäufe von „CocaCola“ an einem Tag in einem Shop?
– Auflösung durch Listen etc.
Ulf Leser: Data Warehousing und Data Mining
67
Speicherverbrauch
Array
Relational
(Star Schema)
Speicherung
Koordinaten
Implizit
(Linearisierung)
Explizit
(redundant)
Leere Zellen
Belegen Platz
Belegen keinen Platz
Komplette Reorganisation
Stark wachsender Speicher
Neue Zeile in Dim-tabelle
Kaum Speicherwachstum
Neue Klassifik.knoten
Speicherverbrauch
d
b * ∏ di
b * m * (d + 1)
i =1
(plus Listen bei mehreren
Fakten pro Koordinate)
Typisches
Zugriffsmuster
Sequentiell
Ulf Leser: Data Warehousing und Data Mining
Random Access
68
Vergleich Speicherplatz
Speicherplatz nach Füllgrad, b=8, k=100, d=5
• Parameter:
Füllgrad, k, d
• Schon bei kleinen
Füllgraden ist Array
platzeffizienter
• Tatsächlicher Füllgrad
oft klein, wenn viele
Dims / Knoten
– Bei weitem nicht alle
Kombinationen finden
sich in den Daten
500000000
400000000
300000000
Array
200000000
Relational
100000000
0
10 20 30 40 50 60 70 80 90 100
Füllgrad in %
Speicherplatz nach Füllgrad, b=8, k=20, d=3
300000
250000
200000
150000
Array
100000
Relational
50000
0
10 20 30 40 50 60 70 80 90 100
Füllgrad in %
Ulf Leser: Data Warehousing und Data Mining
69
Sparse Matrices
• Viele Dimensionen und Klassifikationsknoten
– Dünn besetzte Matrizen, geringer Füllungsgrad
– Ineffiziente Speicherplatznutzung
– Überflüssiges I/O (Auch NULLs müssen gelesen werden)
• Abhilfe: Komprimierung
– Run-Length Encoding (RLE): Schlecht indizierbar
– 2-Ebenen Speicherung
• Ebene 1: Array mit dünn besetzten Dimensionen
• Ebene 2: Arrays mit dicht besetzten Dimensionen
• Gewinn: Viele Ebene 2 Blöcke leer – weglassen
– Siehe multidimensionale Indexstrukturen (später)
Ulf Leser: Data Warehousing und Data Mining
70
Fazit MOLAP
• Kein Standard vorhanden, proprietäre Produkte
• Volksmeinung
– Prinzipiell schneller
– Gut für aggregierte Daten (keine Listen etc.)
– Schlechte Skalierbarkeit, wenn der Hauptspeicher ausgeht
• Typischer Einsatz
– (Regelmäßige) Snapshots des (ROLAP) Cubes auf Client in
MOLAP Datenbank laden
– Vorberechnung aller Aggregate
– Read-Only
– Verwendung für schnelle, intuitive User-Interfaces
• Real-Time OLAP
Ulf Leser: Data Warehousing und Data Mining
71