ROLAP versus MOLAP
Werbung
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
