Data Warehousing und Data Mining

Transkript

1 Data Warehousing und Data Mining Speicherung multidimensionaler Daten Ulf Leser Wissensmanagement in der Bioinformatik

2 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

3 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

4 Beispielschema year month day shop_name pg_name amount price sales shop region productgroup product product_name region_name Ulf Leser: Data Warehousing und Data Mining 4

5 Annahmen für Kostenbetrachtungen d Dimensionen, je k Klassifikationsstufen plus Top Jeder Klassifikationsknoten hat 3 Kinder Level k: 1=3 0 Knoten (Top) Level k-1: 3=3 1 Knoten... Level 0: Höchste Granularität, 3 k Knoten Zusammen: n= i= 0... k i 3 Knoten pro Dimension 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

6 Gleichmäßige Klassifikationshierarchie Zu jedem Knoten gibt es gleich viele Kinder/Fakten Level 2 Top Level 1 K1 K2 K3 Level 0 K1.1 K1.2 K1.3 K2.1 K2.2 K2.3 K3.1 K3.2 K3.3 Fakten Ulf Leser: Data Warehousing und Data Mining 6

7 Beispielquery year month day shop_name pg_name amount price sales shop region productgroup product product_name region_name Summe aller Verkäufe der Produktgruppe Wasser nach Shop und Jahr Ulf Leser: Data Warehousing und Data Mining 7

8 Variante 1 - Snowflake year id year productgroup id pg_name month id month year_id day id day month_id sales product_id day_id shop_id amount price product id product_name pg_id shop id shop_name region_id region id region_name Ulf Leser: Data Warehousing und Data Mining 8

9 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 Ein Tupel pro Klassifikationsknoten jeder Dimension Speicherplatz: (( d + f )* m + d * n) * b Fremdschlüssel je Dimension Measures Ulf Leser: Data Warehousing und Data Mining 9

10 Snowflake - Query 6 Joins SELECT X.shop_name, y.year, sum(amount*price) FROM sales S,... PG, P, D, M, Y, shop X WHERE 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 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

11 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

12 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 ( ) k d + f * m + d *3 * k) * b Ein Attribut pro Klassifikationsstufe Ulf Leser: Data Warehousing und Data Mining 12

13 Star - Query SELECT L.shop_name, T.year, sum(amount*price) FROM sales S, product P, time T, localization L WHERE 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 group by 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

14 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 shop shop_id shop_name address region manager region_id facilities name country... size country_id... name continent size continent_id... name... Ulf Leser: Data Warehousing und Data Mining 14

15 Variante 3: Fullfact year id year productgroup id pg_name 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 product id product_name pg_id shop id shop_name region_id region id region_name Ulf Leser: Data Warehousing und Data Mining 15

16 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

17 Fullfact Query SELECT X.shop_name, T.year, sum(amount*price) FROM sales S, productgroup PG, year Y, shop X WHERE 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

18 Speicherverbrauch 1 Speicherplatz nach Anz. Dim., M=10 6, K=4 Speicher snowflake star fullfact Dimensionen Ulf Leser: Data Warehousing und Data Mining 18

19 Speicherverbrauch 2 Speicherplatz nach Anz. Fakten, D=4, K= Speicher snowflake star fullfact Fakten Ulf Leser: Data Warehousing und Data Mining 19

20 Speicherverbrauch 3 Speicherplatz nach Anz. K-Stufen, M=10 6, D=4 Speicher snowflake star fullfact Klassifikationsstufen Ulf Leser: Data Warehousing und Data Mining 20

21 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

22 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

23 Entartete DWH Anzahl Klassifikationsknoten nähert sich Anzahl Fakten Bsp.: Experimentelle Daten (Knoten = Gene, Werte = Ergebnisse von Tests) Speicherplatz nach Anz. Knoten, M=10 6, D= Speicher snowflake star fullfact Klassifikationsknoten pro Dimension Ulf Leser: Data Warehousing und Data Mining 23

24 Galaxy Schema Mehrere Faktentabellen Jahr Monat Tag Lager Produktgruppe Produkt Verkauf Shop Region Ulf Leser: Data Warehousing und Data Mining 24

25 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 NULL NULL NULL NULL 130 Ulf Leser: Data Warehousing und Data Mining 25

26 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 K2 K3 K2 K1.1 K1.2 K1.3 K2.1 K2.2 K2.3 K3.1 K3.2 K3.3 Top Top K1 K3 K1 K2 K1.1 K1.2 K1.3 K2.1 K2.2 K1.1 K1.2 K1.3 K2.1 K2.2 K2.3 Ulf Leser: Data Warehousing und Data Mining 26

27 Unbalancierte Hierarchien Zuordnung von Produkten zu Hauptgruppen, Teilung großer Shops in Abteilungen, Im Snowflake Schema 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 Shop1 Müssen vom Client bei Ausgabe unterdrückt werden Im Starschema: Ebenso (Auffüllen mit NULLs) Abt1 Top Shop2 Abt2 Abt3 Ulf Leser: Data Warehousing und Data Mining 27

28 Unbeschränkt tiefe Hierarchien Top Unbeschränkt lange Klassenhierarchien 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 K2 Ulf Leser: Data Warehousing und Data Mining 28

29 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

30 Nicht-hierarchische Hierarchien Knoten können mehrere Vorgänger derselben Stufe haben Selbst-Referenzialität reicht nicht mehr Rekursive Modellierung K1.1 Gleiche Nachteile wie Selbst-Referenzialität K1.2 Zuordnung von Werten bei Gruppierung nicht klar K1 K1.3 K2 Top K2.1 K2.2 K2.3 sales product_id id product edges child_id predecessor_id Ulf Leser: Data Warehousing und Data Mining 30

31 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

32 Ä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

33 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

34 Versionierungsmodelle Linear Hierarchisch V1 V1 V2 V2 V4 V3 V3 V5 V6 V7 Zu jeden Zeitpunkt existiert von jedem Tupel nur eine Version Standardmodell Zeitliche Reihenfolge halbgeordnet z.b. in CVS Deutlich komplexer Ulf Leser: Data Warehousing und Data Mining 34

35 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 d 0 Zwei prominente Varianten Single-Table Schattentabellen Ulf Leser: Data Warehousing und Data Mining 35

36 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 product product_id version alive validfrom name packungsgröße farbe gewicht Ulf Leser: Data Warehousing und Data Mining 36

37 INSERT INSERT Objekt k in T Gibt es k schon in T? Nein Ja INSERT INTO T VALUES (id=k, version=0, alive=true, validfrom=sysdate, ) Letzte Version von k in T finden (v ) k.v.alive=true? Ja Nein» Fehlermeldung» INSERT INTO T VALUES (id=k, version=v +1, alive=true, validfrom=sysdate, ) Ulf Leser: Data Warehousing und Data Mining 37

38 DELETE DELETE Objekt k aus T Gibt es k schon in T? Nein Ja Nichts tun Letzte Version von k in T finden (v ) k.v.alive=true? Ja Nein» INSERT INTO T VALUES (id=k, version=v +1, alive=false, validfrom=sysdate, )» UPDATE T SET alive=false WHERE (id, version) = (k, v )» Nichts tun Ulf Leser: Data Warehousing und Data Mining 38

39 UPDATE UPDATE Objekt k in T k in T vorhanden? Nein Ja Nichts tun Letzte Version von k in T finden (v ) k.v.alive=true? Ja Nein» INSERT INTO T VALUES (id=k, version=v +1, alive=true, validfrom=sysdate, )» UPDATE T SET alive=false WHERE (id, version) = (k, v )» Nichts tun Ulf Leser: Data Warehousing und Data Mining 39

40 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

41 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

42 Variante 2: Schattentabellen Anlegen einer Tabelle T s 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 T S speichert alte Versionen T speichert nur aktuellste Version Ulf Leser: Data Warehousing und Data Mining 42

43 INSERT INSERT Objekt k in T k in T vorhanden? Nein Ja INSERT INTO T VALUES (id=k, validfrom=sysdate, ) Fehlermeldung Ulf Leser: Data Warehousing und Data Mining 43

44 Variante 2: DELETE DELETE Objekt k aus T k in T vorhanden? Nein Ja Nichts tun Letzte Version von k in T S suchen (v ) v existiert nicht INSERT INTO T S VALUES (id=k, version=0, validuntil=sysdate, ) v existiert INSERT INTO T S VALUES (id=k, version=v +1, validuntil=sysdate, ) DELETE FROM T WHERE id=k Ulf Leser: Data Warehousing und Data Mining 44

45 UPDATE UPDATE Objekt k in T k in T vorhanden? Nein Ja Nichts tun Letzte Version von k in T S finden (v ) v existiert nicht INSERT INTO T S VALUES( id=k, version=0, validuntil=sysdate, ) v existiert INSERT INTO T S VALUES( id=k, version=v +1, validuntil=sysdate, ) UPDATE T SET validfrom=sysdate, WHERE id=k Ulf Leser: Data Warehousing und Data Mining 45

46 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 T S nehmen mit max(validuntil), aber kleiner d Erfordert Zugriff auf T und T S Ulf Leser: Data Warehousing und Data Mining 46

47 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

48 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

49 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

50 Ä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

51 Änderung: InsN Einfügen eines neuen Klassifikationsknoten ohne Nachkommen in einen Pfad auf Level i 0 Level 2 Top Level 1 K1 K2 K3 K4 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 51

52 Ä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

53 Änderung: DelN Löschen eines Klassifikationsknoten in einem Pfad an Level i 0; Umhängen der Nachkommen auf beliebigen anderen Knoten desselben Levels Level 2 Top Level 1 K1 K2 K3 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 53

54 Änderung: DelN 0 Löschen eines Klassifikationsknoten in einem Pfad an Level i=0; Umhängen der Fakten auf andere Knoten mit Level 0 Level 2 Top Level 1 K1 K2 K3 Level 0 K1.1 K1.2 K1.3 K2.1 K2.2 K2.3 K3.1 K3.2 K3.3 Fakten Ulf Leser: Data Warehousing und Data Mining 54

55 Ä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, 3 k 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/3 k-i Updates (Level i: 3 k-i Knoten) DelN 0 1 Delete, m/3 k Update 1 Delete, m/3 k Update 1 Delete, m/3 k Updates Ulf Leser: Data Warehousing und Data Mining 55

56 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

57 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

58 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

59 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

60 Beispiel: Star Schema 1. Name eines Levels 2. Name eines Attributes time day_id day month_id month year_id year sales product_id day_id shop_id amount price 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) Ref. IC innerhalb einer Tabelle Ulf Leser: Data Warehousing und Data Mining 60

61 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 month CHILD OF quarter CHILD OF year ) HIERARCHY fis_rollup ( day CHILD OF fis_week CHILD OF fis_month CHILD OF fis_quarter CHILD OF fis_year ) <attribute determination clauses>... Klassifikationspfad 1 Klassifikationspfad 2 Ulf Leser: Data Warehousing und Data Mining 61

62 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

63 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

64 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

65 Klassifikationshierarchien Modellierung als eingebettete Knoten der untersten Stufe Jahr Jahr Q3 Q2 Q1 Q4 Q3 Q2 Q1 Q2 Q Q4 Q3 Q2 Q1 Ulf Leser: Data Warehousing und Data Mining 65

66 Array Adressierung Sei d i = D i, d Dimensionen, b: Speicherplatz pro Attribut (Key oder Wert) Linearisierte Darstellung <1,1,1>, <1,1,2>,..., <1,1,d 1 >, <1,2,1>,... Offset der Zelle <a 1,...a d > b* d i= 1 i 1 ( a i 1)* d j j= 1 Ulf Leser: Data Warehousing und Data Mining 66

67 Arrayspeicherung - Probleme Naive MOLAP: Unterschiedliche Performanz je nach Reihenfolge der Dimensionen in Array / Anfrage Daten liegen nach D n 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

68 Speicherverbrauch Speicherung Koordinaten Array Implizit (Linearisierung) Relational (Star Schema) Explizit (redundant) Leere Zellen Belegen Platz Belegen keinen Platz Neue Klassifik.- knoten Speicherverbrauch Typisches Zugriffsmuster Komplette Reorganisation Stark wachsender Speicher b i= 1 (plus Listen bei mehreren Fakten pro Koordinate) d d i Sequentiell Neue Zeile in Dim-tabelle Kaum Speicherwachstum * b* m*( d + 1) Random Access Ulf Leser: Data Warehousing und Data Mining 68

69 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 Füllgrad in % Speicherplatz nach Füllgrad, b=8, k=20, d= Füllgrad in % Array Relational Array Relational Ulf Leser: Data Warehousing und Data Mining 69

70 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

71 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