Ausführung von OLAP Operationen - informatik.hu-berlin.de · Ulf Leser Wissensmanagement in der Bioinformatik Data Warehousing Ausführung von OLAP Operationen

Ulf Leser

Wissensmanagement in der Bioinformatik

Data Warehousing

Ausführung von OLAP Operationen

Ulf Leser: Data Warehousing, Vorlesung, SoSe 2003 2

Variante 1 - Snowflake

SalesProduct_idDay_idShop_idamountprice

DayIddaymonth_id

MonthIdMonthyear_id

Yearidyear

Shopidshop_nameregion_id

Productidproduct_namepg_id

Productgroupidpg_name

Regionidregion_name


Variante 2: Star Schema

Salesproduct_idday_idshop_idamountprice

Timeday_iddaymonth_idmonthyear_idyear

Localizationshop_idshop_nameregion_idregion_name

Productproduct_idproduct_namepg_idpg_name


Variante 3: Fullfact

SalesProduct_idpg_idDay_idmonth_idyear_idShop_idregion_idamountprice

DayIddaymonth_id

MonthIdMonthyear_id

Yearidyear

Shopidshop_nameregion_id

Productidproduct_namepg_id

Productgroupidpg_name

Regionidregion_name


Speicherverbrauch 3

Speicherplatz nach Anz. K-Stufen, M=106, D=4

0

5000000

10000000

15000000

20000000

25000000

3 4 5

Klassifikationsstufen

Spei

cher snowflake

starfullfact


Änderungskosten

Snowflake Star Fullfact

InsN 1 Insert (1 Insert) 1 Insert

1 neues Attribut, 3K Updates(Wert des Attrib.)

1 neues Attribut,M Updates(In Faktentabelle)

1 Delete,M/3K-i Updates(Level i: 3k-i Knoten)

1 Delete, M/3K Updates

0 Delete,3 Update

1 Delete,M/3K Update

1 neue Tabelle, 3(k+1)-(i-1) Updates(Umhängung)

1 Delete, 3 Update

1 Delete,M/3K Update

InsS

DelN

DelN0


Arrayspeicherung - Probleme

• Naive MOLAP: Unterschiedliche Performanz je nach Dimensionsreihenfolge 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– RDBMS mit ähnlichen Problemen

• Speicherung verschiedener Werte pro Zelle ?– Mehrere Verkäufe von „CocaCola“ an einem Tag in

einem Shop– Auflösung durch Listen o.ä.


Vergleich Speicherplatz

• Faktoren– Füllgrad– k: Anz. Knoten– n: Anz. Dimensionen

• Schon bei geringen Füllgraden ist Array platzeffizienter

• Aber: Füllgrad ist bei vielen Dimensionen bzw. Klassifikations-knoten oft erstaunlich gering– Bei weitem nicht alle

Kombinationen vorhanden

0

100000000

200000000

300000000

400000000

500000000

10 20 30 40 50 60 70 80 90 100

Füllgrad in %

Speicherplatz nach Füllgrad, b=8, k=100, n=5

ArrayRelational

0

50000

100000

150000

200000

250000

300000

10 20 30 40 50 60 70 80 90 100

Füllgrad in %

Speicherplatz nach Füllgrad, b=8, k=20, n=3

ArrayRelational


Inhalt dieser Vorlesung

• Sprachen für OLAP Operationen– MDX– SQL Erweiterungen


OLAP Operationen

• Die schon besprochenen– Roll-Up, Drill-Down, Slice, Dice

• Keine Rotierung: Aufgabe der Darstellungsschicht• Vor allem: Hierarchische Aggregation

– Roll-Ups mit Aggregation auf allen Ebenen (Summe pro Tag, pro Monat, pro Jahr)

– Roll-Ups über mehrere Dimensionen (Cross-Tabs): Verkäufe pro Marke und Jahr und Shop, Summen in allen Kombinationen

– ...


Absetzen von OLAP Operationen

• MDX– Eigene Sprache – Benutzt MDDM Elementen: Cube, Dimension, Fakt, ...– Auf dem Vormarsch als Standard

• Erweiterungen von SQL – Umsetzung in relationale Operationen– Operiert auf Star oder Snowflake-Schema


MDX

• Microsoft‘s Vorschlag• Teil von „OLE DB for OLAP“• MDX: Multidimensional Expressions• Neue Sprache

– Standard ohne feste Semantik (by example)– MDDM Konzepte als First-Class Elemente– SQL-artige Syntax, aber gänzlich andere Bedeutung– DDL und DML (hier nur letzteres)– Sehr mächtig und komplex


MDX Elemente

• Measures = Fakten– Modelliert als eigene Dimension mit einer Stufe– Faktname ist der einzige Klassifikationsknoten

• Dimensions = Dimensionen– Level = Klassifikationsstufe– Multiple hierarchies = Verschiedene Pfade – Member = Klassifikationsknoten

• Syntax– {} Sets– [] Einschluss von Strings


Grundprinzip

Automarke

Jahr

Asien

Südamerika

2002

2001

2000

1999

Kontinent

VWPeugot

BMW

Ford

1997

1999

1998

MDX Query


Struktur

• Dimensions (Select)– Angabe der darzustellenden Achsen– Abbildung in zweidimensionale Tabellen

• ON COLUMNS, ROWS, PAGES, CHAPTER, ...– Mischungen verschiedener Klassifikationsstufen einer Dim. erlaubt

• Werte auf verschiedenen Aggregatsebenen werden gemischt dargestellt

• Cube (From)– Verbundoperationen auf Cubes (?)

• Slicer (Where)– Auswahl des betreffenden Fakten/Gruppen Mengen

SELECT <axis-spec1>, <axis-spec2>, ..FROM <cube-spec1>, <cube-spec2>, ...WHERE <slice-specification>


Remember ...

ShopVerkauf Region

Produktgruppe Produkt

Monat TagJahr

Menge

Preis

Country


Beispiel

SELECT {Wein, Bier, Limo, Saft} ON COLUMNS{[2000], [1999], [1998].[1], [1998].[2]} on ROWS

FROM SalesWHERE (Measures.Menge, Country.Germany)

Wein Bier Limo Saft

2000

1999

1998.1

1998.2

Knotenbezeichnung: Unique Names oder Navigation (s.u.)

Slicer: Auswahl des Fakt „Menge“, Beschränkung auf Werte in BRD

Implizite Summierung von Menge, nur BRD, nach Produktgruppe /

Zeitangabe

Verschiedene Klassifikationsstufen möglich


Navigation

Navigationsfunktionen• Members: Knoten einer Klassifikationsstufe• Children: Kinderknoten eines Klassifikationsknoten• Parent: Vaterknoten eines Klassifikationsknoten• LastChild, FirstChild, NextMember, CurrentMember, ...• Descendent: Recursives Absteigen

SELECT {Prodgroup.MEMBERS, [Becks Bier].PARENT} ON COLUMNS{Year.MEMBERS} on ROWS

FROM SalesWHERE (Measures.Menge)


Crossjoin

• Projektion zweier Dimensionen in Eine• Semantik: Alle möglichen Kombinationen

SELECT CROSSJOIN( {Germany, France}{Wein, Bier}) ON COLUMNS

{Year.MEMBERS} on ROWS FROM SalesWHERE (Measures.Menge)

Germany France

Wein Bier Wein Bier

1997

1998

...


Weitere Feature

• TOPN Queries

• Filtering dimension values

• Named Sets und Calculated Members• Zeitreihenoperationen und conditionale Werte• ...

SELECT {Year.MEMBERS} ON COLUMNS{TOPCOUNT(Country.MEMBERS, 5, Measures.Menge} ON ROWS

SELECT FILTER(Germany.CHILDREN, ([2002], M.Menge) > ([2001], M.Menge)} ON COLUMNS

Month.MEMBER ON ROWS


MDX - Fazit

• Hohe Komplexität• Mächtige Sprache• Direkte Anlehnung an MDDM• Könnte sich als Standard durchsetzen

– Schnittstelle zwischen OLAP GUI und DB-Server– Unterstützt von MS, Microstrategy, Cognos,

BusinessObjects, ...


Inhalt dieser Vorlesung

• Sprachen für OLAP Operationen– MDX– SQL Erweiterungen


SQL und OLAP

• Übersetzung eines MDDM in ein Star-Schema– Oder Snowflake Schema

• Triviale Operationen– Auswahl (slice, dice): Joins und Selects– Verfeinerung (drill-down): Joins und Selects

• Einfache Operation– Aggregation um eine Stufe: Group-by

• Schwieriger– Mehrere hierarchische, multidimensionale

Aggregationen


Beispielschema

Salesproduct_idday_idshop_idamountprice

Timeday_iddaymonth_idmonthyear_idyear

Localizationshop_idshop_nameregion_idregion_name

Productproduct_idproduct_namepg_idpg_name


Einschub: GROUP-BY

• Syntax– SELECT Klausel darf nur GROUP_BY Ausdrücke, Konstante und

Aggregatfunktionen enthalten

• Semantik– Partitionierung der Ergebnistupel nach unterschiedlichen Werten

der GROUP-BY Attribute– Summierung der Aggregationswerte (Measures) pro Partition

SELECT T.day_id, sum(amount*price)FROM Sales SGROUP BY T.day_id

Innere Query(Tuplestrom)

Partitionierung (Group by)

Aggregation (pro Partition)

Selektion der Part. (having)

Sortierung (der Partitionen)


Beispiel Aggregation

Alle Verkäufe der Produktgruppe „Wein“ nach Monaten

SELECT T.month, sum(amount*price)FROM Sales S, Product P, Time TWHERE P.pg_name=„Wein“ and

P.product_id = S.product_id andT.day_id = S.day_id

GROUP BY T.month_id

Scheitert: „... T.month is not a GROUP-BY expression ...“

• Funktionale Abhängigkeit T.month_id->T.Month nicht bekannt

• (Erinnerung: „ATTRIBUTE ... DETERMINES“ in Oracle)


Hierarchische Aggregation

Alle Verkäufe der Produktgruppe „Wein“ nach Tagen, Monaten und Jahren

SELECT T.year_id, T.month_id, T.day_id, sum(...)FROM Sales S, Product P, Time TWHERE P.pg_name=„Wein“ and


GROUP BY T.year_id, T.month_id, T.day_id

• Summe nur für Tage (unterteilt nachMonaten/Jahren)

• Keine Summen pro Monat / pro Jahr • Nicht in einer Query formulierbar

1997 1 1 150

1997 1 2 130

1997 1 3 145

1997 1 4 122

... ... ... ...

1997 1 31 145

1997 2 1 133

1997 2 2 122

... ... ... ...

1997 3 10 180

1997 12 31 480

1998 1 1 240

... ... ... ...

2003 6 18 345


Hierarchische Aggregation –2-

Alle Verkäufe der Produktgruppe „Wein“ nach Tagen, Monaten und Jahren

Benötigt UNION und eine Query pro Klassifikationsstufe

SELECT T.day_id, sum(amount*price)FROM Sales S, Product PWHERE P.pg_name=„Wein“ and

P.product_id = S.product_idGROUP BY T.day_id

SELECT T.month_id, sum(amount*price)FROM Sales S, Product P, Time TWHERE P.pg_name=„Wein“ and


GROUP BY T.month_id

SELECT T.year_id, sum(amount*price)FROM Sales S, Product P, Time TWHERE P.pg_name=„Wein“ and


GROUP BY T.year_id


Ergebnis

Tage

Monate

Jahre

1997 1 1 150

1997 1 2 130

... ... ... ...

1997 1 31 145

1997 2 1 133

... ... ... ...

1997 12 31 480

1998 1 1 240

... ... ... ...

2003 6 18 345

1997 1 - 12000

1997 2 - 13000

... ... ... ...

2003 6 - 15600

1997 - - 123453

1998 - - 143254

... ... ... ...

Schöner wäre

............

143254--1998

............

345111998

123453--1997

14000-121997

............

480121997

12000-11997

1453111997

............

150111997


ROLLUP Operator

• Herkömmliches SQL– Dimension mit k Stufen – Union von k Queries

k Scans der Faktentabelle• Keine Optimierung wg. fehlender Multiple-Query

Optimierung in kommerziellen RDBMS

Schlechte Ergebnisreihenfolge

• ROLLUP Operator– Hierarchische Aggregation mit Zwischensummen– Summen werden durch „ALL“ als Wert repräsentiert


ROLLUP BeispielSELECT T.year_id, T.month_id, T.day_id, sum(...)FROM Sales S, Time TWHERE T.day_id = S.day_idGROUP BY ROLLUP(T.year_id, T.month_id, T.day_id)

1997 Jan 1 200

1997 Jan ...

31

ALL

...

ALL

...

ALL

1998 Jan 1 100

1998 ... ...

1998 ALL ALL 45.000

... ... ...

ALL

1997 Jan 300

1997 Jan 31.000

1997 Feb

1997 Feb 450

1997 ...

1997 ALL 1.456.400

ALL ALL 12.445.750


Multidimensionale Aggregation

Verkäufe nach Produktgruppen und Jahren

1998 1999 2000 Gesamt

Weine 15 17 13 45

Biere 10 15 11 36

Gesamt 25 32 24 81

Wie viele Queries sind notwendig ?

• sum() ... GROUP BY pg_id, year_id• sum() ... GROUP BY pg_id• sum() ... GROUP BY year_id• sum()


Cube Operator

• d Dimensionen, jeweils eine Klassifikationsstufe– Jede Dimension kann in Gruppierung enthalten sein oder nicht– 2d Gruppierungsmöglichkeiten

• Herkömmliches SQL– Viel Schreibarbeit– 2d Scans der Faktentabelle (wieder keine Optimierung möglich)

• CUBE Operator– Berechnung der Summen von sämtlichen Kombinationen der

Argumente (Klassifikationsstufen)– Summen werden durch „ALL“ repräsentiert– Keine Beachtung von Hierarchien

• Durch Schachtelung mit ROLLUP erreichbar


CUBE - Beispiel

SELECT pg_id, shop_id, sum(amount*price)FROM Sales S ...GROUP BY CUBE (S.pg_id, S.shop_id, T.year_id)

Bier Kreuzberg ALL ...

ALL

1997

1998

1997

1998

Bier ALL ALL ...

Wein ALL ALL ...

ALL ALL 1997 ...

ALL ALL 1998 ...

ALL Kreuzberg ALL ...

ALL Charlottenburg ALL ...

ALL

Bier Charlottenburg ...

Bier ALL ...

Wein ALL ...

ALL Kreuzberg ...

ALL Charlottenburg ...

ALL ALL ...


Cube-Operator: Veranschaulichung

CHEVY

FORD 19901991

19921993

REDWHITEBLUE

By Color

By Make & Color

By Make & Year

By Color & Year

By MakeBy Year

Sum

The Data Cube and The Sub-Space Aggregates

REDWHITEBLUE

Chevy Ford

By Make

By Color

Sum

Cross TabRED

WHITEBLUE

By Color

Sum

Group By (with total)Sum

Aggregate

Source: Gray et al., „Datacube“, Microsoft & IBM


GROUPING SETS Operator

• CUBE– Alle Gruppierungskombinationen– Das sind sehr viele ...

• GROUPING SETS– Explizite Angabe der gewünschten Gruppierungen– Gruppierung wird für jeden SET einzeln ausgeführt,

benötigt aber nur einen SCAN – Äquivalent zu UNION einzelner GROUP BY


GROUPING SETS - Beispiel

SELECT pg_id, shop_id, sum(amount*price)FROM Sales SGROUP BY GROUPING SETS((S.pg_id), (S.shop_id))

Bier ALL 300

Wein ALL 450

ALL Kreuzberg 350

ALL Charlottenburg 400


Fazit

• Operationen schachtelbar– GROUP BY ROLLUP( year, month, day, CUBE(pg_id, shop_id))

• SQL-Standard– Implementiert (mindestens) von Oracle, DB2, SQLServer

• Wesentliche Verbesserung– Kompaktere Queries– Deutliche Beschleunigung durch weniger Scans– Aggregierbarkeit beachten: „ROLLUP AVG“?– Implementierung von CUBE nicht trivial – sehr viele Zwischensummen

• Weitere Operationen– GROUPING – Erkennen von Summenwerten– Sliding Windows, sequenzbasierte Operationen – Percentile, Rank, TopN – Queries– ...

• Aktives Gebiet aller DB-Hersteller


Literatur

• [BG01]: Bauer, Günzel: „Data Warehouse Systeme: Architektur, Entwicklung, Anwendung“, dpunkt.Verlag, 2001

• [Leh03] Lehner: „Datenbanktechnologie für DataWarehouse Systeme“, dpunkt.Verlag, 2003

• [GCB+97] Gray et al. „Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals“, Journal on Data Mining and Knowledge Discovery, 1997

• [Nol99] Nolan: „Introduction to Multidimensional Expressions (MDX)“, Microsoft Corp.

Documents

Ausführung von OLAP Operationen - informatik.hu-berlin.de · Ulf Leser Wissensmanagement in der Bioinformatik Data Warehousing Ausführung von OLAP Operationen