Cube Maintenance Under Dimension Updates Fachseminar „Data Warehousing und Mining“ Stefan Walthert 2. Dezember 1999

Gliederung Multidimensionales, hierarchisches Datenmodell Dimension Updates Structural Updates Instance Updates Incremental Maintenance Maintenance mit Hilfe des View Gitters Schlussfolgerungen

Motivation 1 Die meisten Data Warehouse-Systeme unterstützen Datenanalyse durch ein multidimensionales Datenmodell, in welchem die Attribute in Dimensionen und Measures unterteilt sind. Artikel Früchtetee Frigor Dunkel Measure 40 Frigor Hell Branche Crémant 4.6. 5.6. 7.6. 8.6. Coop Bülach Volg Hettlingen Zeit Denner Thun Laden Dimensionen

Motivation 2 Dimensionen werden in bestehenden Systemen als eher statisch betrachtet, während Measures den dynamischen Teil des Data Warehouses bilden. In der Praxis kommt es aber auch vor, dass auf Grund von geänderten Anforderungen Änderungen an den Dimensionen vorgenommen werden müssen. In diesem Vortrag sollen verschiedene Operationen auf den Dimensionen, deren Auswirkungen auf die Struktur der Daten und Algorithmen, um diese zu implementieren, vorgestellt werden. Zeit Laden Artikel Früchtetee Frigor Dunkel Frigor Hell Branche Crémant 15.00 16.00 17.00 08.00 Coop Bülach Volg Hettlingen Denner Thun ? 09.00 4.6. 5.6. Beispiel Was geschieht, wenn die Dimension Zeit nicht mehr in Tage, sondern Stunden eingeteilt wird?

Dimension 1 Das verwendete Datenmodell unterteilt die Dimensionen in hierarchisch gegliederte Levels. Für die Dimension Produkt sieht diese Gliederung folgendermassen aus: All all Rollup-Funktion Konzern Nestlé Unilever Levels Firma Caillers Lipton Sais Schokolade Fette Getränke Kategorie Marke Branche Frigor Secret Garden Rama Ordnungsrelation  Artikel unterstes Level linf Crémant Hell Dunkel Margarine Früchtetee

Dimension 2 Eine Dimension besteht aus folgenden Elementen: Name der Dimension (Produkt) Menge von Levels ({Artikel, Marke, Firma, Kategorie, Konzern, All}); oberstes Level: immer All, nur ein unterstes Level (Artikel)  - Relation, welche die Levels hierarchisch ordnet (z.B. Marke  Firma). Rollup-Funktion, welche die Instanzen der einzelnen Levels gemäss der  - Relation miteinander verbindet (z.B. {Caillers  Nestlé, Sais  Unilever, Lipton  Unilever}). Dimensionen werden auch in sogenannten Dimension Tables gespeichert:

Dimension 3 Im Verlauf dieses Vortrages werden zusätzlich zur Dimension Produkt folgende weitere Dimensionen verwendet: All Region LadenId all Zürich Bern Coop Bülach Volg Hettlingen Denner Thun All Woche Tag all 4. Juni 5. Juni Woche 22 Woche 23 6. Juni Dimension Laden Dimension Zeit

Fact Table Eine Fact Table erstellt nun Verbindungen unter den verschiedenen Dimensionen, indem einem Punkt aus dem Dimensionenraum ein oder mehrere Werte aus dem Raum der Measures zugewiesen wird. Eine Fact Table enthält folgende Elemente: Name der Fact Table (Tägliche_Verkäufe) Menge von Levels aus verschiedenen Dimensionen ({Artikel, LadenId, Tag}) Measure Level (Verkäufe) Eine Fact Table, welche von jeder Dimension jeweils das unterste Level enthält, wird Base Fact Table genannt. Levels Measure

Multidimensionale Datenbank In einer multidimensionalen Datenbank werden nun Dimensionen und Fact Tables zusammengenommen. Diese erhält dadurch ein sogenanntes Star Schema: Dimension Zeit Dimension Produkt Dimension Laden Base Fact Table Tägliche_Verkäufe

Level Groups Wenn man aus jeder Dimension ein Level nimmt und diese gruppiert, erhält man eine Level Group GB. Beispiel Es gibt spezielle Arten von Level Groups: GBottomD: Level Group, welche das unterste Level aller Dimensionen enthält. GBD: Menge aller möglichen Level Groups All All Region LadenId All Woche Tag Konzern Firma GB{Kategorie, Region, Tag} Kategorie Marke Produkt Artikel Laden Zeit GBottom{Produkt, Laden, Zeit}

Cube View 1 Um bei Abfragen eine möglichst schnelle Antwort zu liefern, können mit dem Cube View-Operator Fact Tables vorberechnet werden. Beispiel Beim folgenden Beispiel wird entlang der Dimension Zeit ein Level (von Tag nach Woche) aufgerollt und über das Measure Verkäufe summiert: Cube View Artikel Frigor D. Frigor H. Branche C. 4.6. 5.6. 7.6. Coop B. Zeit Volg H. Denner T. Laden

Cube View 2, Data Cube Cube View, Fortsetzung Mit Hilfe des Data Cube-Operators kann man eine neue multidimensionale Datenbank erstellen, welche häufig verwendete Views schon enthält:

Dimension Updates Bisher: Ändern der Measures Ziel: Ändern der Struktur der Dimensionen Manipulation von ganzen Instanzen (Einfügen, Löschen)  Set von Update Operatoren: Structural Update Operators ändern die Struktur der Dimensionen. Instance Update Operators ändern den Inhalt der Dimensionen.

Structural Updates - Operators 1 Generalize erstellt direkt oberhalb eines Levels ein neues Level. Dazu muss die Rollup-Funktion erweitert werden. Beispiel All Region LadenId all ZH BE Coop B. Volg H. Denner T. All LadenId Region Typ all Generalize Genoss. Superdisc. ZH BE Coop B. Volg H. Denner T.

Structural Updates - Operators 2 Specialize erstellt unterhalb des untersten Levels einer Dimension ein neues Level, welches nun zum untersten Level dieser Dimension wird. Wiederum muss die Rollup-Funktion ergänzt werden. Beispiel All all W 22 4.6. 5.6. W 23 7.7. All all Woche Specialize Woche W 22 W 23 Tag Tag 4.6. 5.6. 7.6. Stunde 15 16 17 08 09

Structural Updates - Operators 3 Relate Levels verbindet zwei vorher unabhängige Levels miteinander, indem eine Rollup-Funktion zwischen diesen Levels definiert wird. Dabei löscht diese Operation alle redundanten Verbindungen. Beispiel All Konzern Artikel all Nestlé Unilever Firma Marke Kategorie Caillers Lipton Schoko. Geträ. Branche Frigor SG C. H. D. FT

Structural Updates - Operators 4 Unrelate Levels löscht die Relation zwischen zwei Levels. Dabei muss sichergestellt werden, dass ober- und unterhalb liegende Levels immer noch dieselben Levels erreichen können wie vorher. Beispiel Kategorie Firma Marke All Konzern Artikel all Nestlé Unilever C. H. D. FT Caillers Lipton Branche Frigor SG Schoko. Geträ. All Konzern Artikel all Nestlé Unilever Firma Caillers Lipton Kategorie Schoko. Geträ. Marke Branche Frigor SG C. H. D. FT

Structural Updates - Operators 5 Delete Level löscht ein Level. Dabei muss eine Rollup-Funktion zwischen den Levels unter und über dem gelöschten Level definiert werden. Beispiel All Konzern Artikel all Nestlé Unilever Firma Caillers Lipton Marke Bra. Frig. SG Bra. Frig. SG Marke Marke Bra. Frig. SG Kategorie Schoko. Geträ. C. H. D. FT

Structural Updates - Maintenance Wie ändern sich der Data Cube bzw. die Dimension Tables und die Fact Tables bei Structural Updates? Generalize, Relate Level, Unrelate Level: keine Modifikation der Base Fact Table, nur der Dimension Table Delete Level: Wenn das gelöschte Level ein unterstes Level war, dann berechne neue Base Fact Table, sonst lösche jede Fact Table, in welcher das gelöschte Level zum Schema gehört. Specialize: Berechne neue Base Fact Table, welche das neue unterste Level enthält.

Instance Updates - Operators 1 Add Instance fügt in ein Level eine neue Instanz ein. Dabei muss angegeben werden, zu welchen Instanzen der oberhalb liegenden Levels die neue Instanz aufgerollt wird. Beispiel All all Konzern Nestlé Unilever Firma Caillers Lipton Schoko. Geträ. Kategorie Marke Bran. Frig. SG Artikel C. H. D. FT Hagebuttentee

Instance Updates - Operators 2 Delete Instance löscht eine Instanz eines Levels. Beispiel All all Konzern Nestlé Unilever Firma Caillers Lipton Schoko. Geträ. Kategorie H. H. H. Marke Bran. Frig. SG Artikel C. D. FT

Instance Updates - Maintenance 1 Bei den nun folgenden Verfahren werden Instance Updates in zwei Phasen durchgeführt: Propagation Phase Berechne für jede gespeicherte View eine Tabelle, in welcher die Updates stehen (= Delta Table) Refresh Phase Wende die in der Delta Table enthaltenen Updates auf die Views an. Die Berechnung dieser Delta Tables kann auf unterschiedliche Art und Weise vorgenommen werden. Zwei dieser Verfahren werden vorgestellt: 1. Incremental View Maintenance 2. Maintenance mit Hilfe des View Gitters

Instance Updates - Maintenance 2 Um die beiden Verfahren zu veranschaulichen, wird eine verkleinerte Version des vorherigen Data Cubes verwendet: All Marke Artikel all Frigor H. FT HT Caillers Lipton All LadenId all Coop B. Volg H. All Woche Tag all W 22 4.6. 5.6. W 23 7.6. Dimension Produkt Dimension Laden Dimension Zeit Base Fact Table Tägliche_Verkäufe Es wird angenommen, dass alle möglichen Views vorberechnet wurden.

Instance Updates - Incremental Maintenance Beim inkrementellen Verfahren wird ausgehend von der Base Fact Table für jede View und die Base Fact Table selber eine Delta Table berechnet. Beispiel Delta Table für die View Verkäufe_MLW, welche beim Löschen von Früchtetee entsteht. Base Fact Table Tägliche_Verkäufe Dazu muss man Tägliche_Verkäufe  Artikel = a2 Produkt  Zeit berechnen. Danach werden die gewünschten Levels projiziert bei gleichzeitiger Aggregation Lösche Frü.Tee Delta View  Verkäufe_MLW

Delta View  Verkäufe_MLW Instance Updates - Incremental Maintenance Im 2. Schritt wird auf jede View mit der dazugehörenden Delta Table ein Refresh-Algorithmus angewandt. Beispiel Fortsetzung Delta View  Verkäufe_MLW View Verkäufe_MLW Refresh View Verkäufe_MLW

Instance Updates - Incremental Maintenance Um eine Delta Table für eine View zu berechnen, sind also je nach View mehrere Joins und Aggregationen nötig. Bei n Dimensionen mit je k Levels: kn Aggregationen n Projektionen, d.h. bei z.B. 10 Dimensionen mit je 8 Levels: > 1 Mia. Aggregationen für eine Löschoperation! Fazit Verfahren ist naheliegend und einfach # Aggregationen wächst exponentiell mit der # Dimensionen  Verfahren ist nicht geeignet für grosse Datenbanken mit vielen Dimensionen und Levels Wie können nun die Anzahl Aggregationen und Joins reduziert werden?

Instance Updates - Maintenance mit View-Gitter Das folgende Verfahren verwendet ein sogenanntes View-Gitter, einen gerichteten Graphen, welcher die Beziehungen zwischen den Views darstellt: Die Views sind die Knoten. Eine Kante besteht zwischen zwei Views, wenn man durch ein Rollup von einer View zur anderen gelangen kann. Beispiel View RAW View MLW View RLA Rollup entlang Laden Rollup entlang Produkt Rollup entlang Zeit View RLW

Instance Updates - Maintenance mit View-Gitter Das vollständige View-Gitter für unser Beispiel sieht folgendermassen aus: AAA Produkt: R: Artikel M: Marke A: Alle Laden: L: Laden Zeit: T: Tag W: Woche AAW ALA MAA ALT AAT ALW MAW MLA RAA MAT MLW RAW RLA Zeit MLT RAT RLW Laden Produkt RLT Dimension Produkt Dimension Laden Dimension Zeit

Instance Updates - Maintenance mit View-Gitter Hinter dem Verfahren, welches ich nun vorstellen werde, steckt diese Überlegung: Wenn man aus einer View eine Nachfolgeview aufrollen kann, dann kann man aus einer Delta Table auch eine „Nachfolge“-Delta Table berechnen. Dadurch muss man nicht jede Delta Table aus der Base Fact Table ermitteln. MLW RAW RLA MLW RAW RLA ! RLW RLW

Instance Updates - Maintenance mit View-Gitter Dabei taucht aber eine Frage auf: Jede View und deshalb jede Delta Table hat mehrere potentielle Vorgänger:  MLW ? ? Welchen Vorgänger soll man auswählen?  MLT  RLW  MLW  MLT  RLW ? ? Dieses neue Verfahren erstellt nun für ein View-Gitter einen Plan, der für jede View einen Vorgänger zur Berechnung der Delta Table auswählt. Danach aktualisiert der Refresh-Algorithmus jede View mit Hilfe der dazugehörenden Delta Table.

Instance Updates - Maintenance mit View-Gitter Beispiel Für das Löschen von Früchtetee sieht dieser Plan folgendermassen aus: ALT AAT RLA RAA MAT ALW MLT AAW RAW MLA RLW MAA RLT RAT MLW MAW ALA AAA : für diese Views werden die Delta Tables aus der jeweiligen View berechnet PLZ : die Berechnung der Delta Tables erfolgt entlang der Dimension Produkt Wenn man nun die Delta Tables gemäss diesem Plan berechnet, sind keine Joins und Aggregationen nötig!

Instance Updates - Maintenance mit View-Gitter Fazit Löschen von Instanzen: Keine Joins und Aggregationen Einfügen von Instanzen (ohne Beispiel): Joins und Aggregationen unumgänglich  minimieren durch geschickte Wahl der Vorgänger-Delta Table, z.B. diejenige mit kleinster geschätzten Grösse diejenige, welche sich noch im Cache befindet In jedem Fall konnte die Anzahl Joins und Aggregate stark reduziert werden.

Schlussfolgerungen Dimension Updates Maintenance bei Instance Updates bei Vorstellung des Datenmodells: logische Sicht bei Besprechung der Implementation: relationales Modell  Untersuchung der Updates bei anderen Speicherungsarten (Hash Tables, ...) Bezeichnung “Dimension Updates” eher verwirrend, da Updates v.a. Fact Tables, nicht Dimension Tables, verändern Maintenance bei Instance Updates Dies wurde erreicht u.a. mit der formalen Beschreibung des Datenmodells und der Update-Operationen Erst theoretische Überlegungen, noch keine Implementation oder Tests

Literatur C.A. Hurtado, A.O. Mendelzon, A.A. Vaisman. Maintaining Data Cubes under Dimension Updates. Proceedings of the International Conference on Data Engineering (ICDE), Sydney, Australia, 1999. S. Agarwal, R. Agrawal, P.M. Deshpande, A. Gupta, J.F. Naughton, R. Ramakrishnan, S. Sarawagi. On the Computation of Multidimensional Aggregates. Proceedings of the 22nd VLDB Conference, Bombay, India, 1996 A. Gupta, V. Harinarayan, D. Quass. Aggregate Query Processing in Data Warehousing Environments. Proceedings of the 21st VLDB Conference, Zurich, Switzerland, 1995 A. Gupta, I.S. Mumick, D. Subrahmanian. Maintaining Views Incrementally. Proceedings of the ACM-SIGMOD Conference on Management of Data, Washington D.C., USA, 1993