Indexstrukturen für das Data Warehousing

Transkript

1 Indexstrukturen für das Data Warehousing Volker Wildi Konstanz, den 7. August 2005 Inhaltsverzeichnis 1. Einführung 1 2. Bisherige Indexstrukturen Der Bitmap-Index Der R-Baum Der X-Baum Der DC-Baum Konzepthierarchie Minimal-beschreibende Sequenzen Algorithmen Einfügen Splitten Hierarchie-Splitt Bereichsabfragen Leistungsmessung Testumgebung Ablauf der Messungen Ergebnisse Zusammenfassung 7 A. Algorithmen 8 A.1. Einfügen eines Verzeichnisknotens A.2. Splitten eines Verzeichnisknotens A.3. Hierarchie-Splitt A.4. Bereichsabfrage Einführung Ein Data Warehouse [2, 9] ist eine Sammlung von Daten von mehreren Quellen, die zusammengefügt und um eine Auswertungsinformation erweitert werden, um dann in einer zentralen Datenbank abgespeichert zu werden. Mit Hilfe eines Data Warehouses können organisatorische Entscheidungen besser getroffen werden. Dieser Entscheidungsprozess wird als OLAP (On-Line Analytical Processing) [2, 3] bezeichnet. Damit solche OLAP-Anwendungen funktionieren können, müssen sie verschiedene Sichten (Dimensionen) der Daten besitzen. Ein Datenwürfel ist eine mehrdimensionale Sicht der Datenbank mit einem zusätzlichen Wert, z. B. von Autoverkäufen. Dieser Würfel ist in verschiedene Dimensionen unterteilt, wie z. B. Modell, Farbe, Verkaufsdatum usw. Die zu untersuchende Metrik wird als Messattribut bezeichnet, im Beispiel Autoverkäufe. Jede Zelle des Datenwürfels entspricht einer eindeutigen Menge an Werten der verschiedenen Dimensionen und enthält den Messwert für diese Menge. Ein Data Warehouse besteht aus mehreren Datenwürfeln. Ein Datenwürfel kann als d-dimensionales Array betrachtet werden, wobei jede Zelle die Messattribute für den jeweiligen Unterwürfel enthält. Typischerweise tangieren Abfragen eine riesige Menge an Datensätzen und sind deshalb sehr aufwendig zu verarbeiten. Daher empfiehlt es sich, die Ergebnisse relevanter Abfragen zu merken, um die Ausführung zu beschleunigen. Allerdings kann dieser Ansatz nicht in dynamischen Umgebungen eingesetzt werden, da die Abfragen nicht genau bekannt sind und deren Anzahl potentiell sehr groß ist. In diesem Umfeld sollten Bereichsabfragen unterstützt werden. Bereichsabfragen [8] geben einen fortlaufenden Bereich für 1

2 jede ihrer Dimensionen des Datenwürfels und wenden einen Aggregationsoperator auf eine Menge an selektierten Zellen an. Damit diese Bereichsabfragen effizient unterstützt werden können, wurden mehrere Ansätze für mehrdimensionale Indexstrukturen über die Zeit entwickelt. In einem Data Warehouse werden normalerweise die Einfüge- und Löschoperationen in der Datenbank sofort durchgeführt. Aktualisierungen werden gesammelt und periodisch (z. B. jede Nacht) in das Data Warehouse mit Hilfe eines Batch-Modus eingespielt. Danach müssen auch alle Indexstrukturen auf den aktuellen Stand gebracht werden. Allerdings hat dieses Vorgehen zwei entscheidende Nachteile: Die Durchschnittszeit für das Einspielen eines einzelnen Updates ist klein, im Gegensatz zur gesamten Batch-Einspielung. Dadurch ist das Data Warehouse für einen gewissen Zeitrahmen nicht erreichbar. Der Datenstand ist nicht immer aktuell. Dies ist bei vielen Anwendungen nicht problematisch, aber es gibt Anwendungen (z. B. Aktienmarkt) für die dies essentiell ist. Eine Bereichsabfrage ist ein fortlaufender Bereich, die jede Dimension des Datenwürfels einschränken soll, um eine Treffermenge zurückzuliefern. Auf diese wird dann anschließend ein Aggregationsoperator angewendet. Ein Beispiel für eine solche Bereichsabfrage könnte die folgende sein: Gib alle täglichen Durchschnittsverkäufe im Monat Juli aus. Die Menge an Daten, die in einem Data Warehouse gespeichert werden, sind riesig. Für einen effizienten Zugriff auf diese Daten müssen deshalb Indexstrukturen eingesetzt werden. Weiter sollen diese Indexstrukturen auch Bereichsabfragen effizient unterstützen [6]. Dazu gibt es eine Reihe an Ansätzen für solche Indexstrukturen, wie den Bitmap- Index, den R-Baum [7] oder den X-Baum [1], die im nachfolgenden kurz beschrieben werden sollen. 2. Bisherige Indexstrukturen 2.1. Der Bitmap-Index Beim Bitmap-Index [4, 10] handelt es sich um eine eindimensionale Indexstruktur, die sehr oft in bisherigen Implementationen wie z. B. Oracle [11] oder Sybase [12] eingesetzt wird. Die Blattseiten dieser Indexstruktur enthalten keine Liste an Identifikationsnummern, sondern Bitvektoren. Diese Bitvektoren besitzen für jeden Datensatz ein eigenes Bit. Die Implementation dieses Indexes ist sehr einfach und durch die Verwendung von Bit-Operationen sehr effizient. Allerdings kann diese Indexstruktur unter Umständen sehr viel Speicher einnehmen. Dazu ist die Ausführungsgeschwindigkeit der Insert- und Delete-Operationen drastisch langsamer im Vergleich zu einer Baumstruktur, da bei jedem neuen Datensatz der gesamte Index neu aufgebaut werden muss Der R-Baum Eine andere Indexstruktur, die auf einer Baumstruktur aufsetzt, ist der R-Baum [7]. Dabei handelt es sich um eine Erweiterung des eindimensionalen Datenraums des B-Baums zu einem d-dimensionalen Datenraum. Der R-Baum verwendet d- dimensionale Hyperrechtecke zur Indizierung der Datensätze. Jedes dieser Hyperrechtecke kann zwischen einem und N Datensätze erfassen, wobei N die Kapazität dieses Hyperrechteckes ist. Alternativ werden diese Hyperrechtecke auch als Minimum Bounding Rectangles (MBRs) bezeichnet. Die MBRs der R-Bäume überlappen sich sehr oft, was sehr von Nachteil ist, da sich mit disjunkten MBRs mehr Raum abdecken lässt Der X-Baum Der X-Baum [1] ist eine Erweiterung des R-Baumes, der den Nachteil der überlappenden MBRs vermeidet. Weiter führt diese Indexstruktur das Prinzip der Superknoten ein. Diese sollen verhindern, dass ein Baum beim Splitten entartet und 2

3 umgehen. Zusätzlich soll diese eine effiziente Unterstützung für Bereichsabfragen bieten. Die Struktur des DC-Baumes ähnelt dem des X-Baumes, dabei werden die MBRs durch eine andere Datenstruktur ersetzt Konzepthierarchie Abbildung 1: Beispiel für einen R-Baum so unbalanciert wird. Ein Superknoten besitzt als Kapazität ein Vielfaches der Standard-Blockgröße. Abbildung 2 gibt ein Beispiel für einen X-Baum. Allerdings birgt auch diese Indexstruktur einen Nachteil, weil wie auch beim R-Baum bei den MBRs zu viel leerer Raum abgedeckt wird, wie Abbildung 3 zeigt. Abbildung 2: Beispiel für einen X-Baum Ein Datenwürfel besteht bekanntlich aus mehreren Dimensionen und einem Messwert. Existiert nun mehr als ein funktionales Attribut pro Dimension, dann werden diese Attribute in ein Hierarchieschema gegliedert. Eine Konzepthierarchie ist eine Instanz eines Hierarchieschemas. Abbildung 4 zeigt ein Beispiel für die Dimension Kunde und dessen funktionalen Attributen Region, Nation und KundenID. Die Wurzel jeder Konzepthierarchie trägt die Bezeichnung ALL. Dies stellt auch die Vereinigung aller Werte in dieser Konzepthierarchie dar. Es wird je eine Konzepthierarchie pro Dimension angelegt. Weiter wird eine partielle Ordnung einer Dimension eingeführt, die für die Splittalgorithmen des DC-Baumes wichtig ist. Zwei Attributwerte a und b innerhalb einer Dimension sind partiell geordnet (a b), falls a gleich b ist, oder a ein direkter oder indirekter Abkömmling von b ist. Abbildung 3: Das Bild links stellt die Überlappung eines R- Baumes dar. Die rechte Grafik zeigt die farbliche Kennzeichnung der Anzahl der Überlappungen. 3. Der DC-Baum Die nachfolgend vorgestellte Indexstruktur trägt den Namen DC-Baum [5] und soll die Nachteile der im vorherigen Abschnitt beschriebenen Indexstrukturen Abbildung 4: Hierarchieschema und Konzepthierarchie für die Dimension Kunde Die Vorteile der partiellen Ordnung im Vergleich zur totalen Ordnung sind in Abbildung 5 dargestellt. In einer totalen Ordnung wird jedem Produkt eine eindeutige Identifikationsnummer zugeordnet. Ein Problem existiert erst beim Einfügen neuer Produkte. Wird in dem Beispiel aus 3

4 Abbildung 5 ein neuer Fernseher der Marke Samsung hinzugefügt, so würde dieser zwischen i und i+1 eingefügt werden. Die totale Ordnung im Beispiel erlaubt nur Bereichsabfragen nach der Marke. Es werden also nicht alle Attribute gleich behandelt, da z. B. nicht nach den Produkttypen gesucht werden kann. Das Einfügen in der partiellen Ordnung hingegen, ist genauso natürlich, da die Blätter in der Konzepthierarchie als Mengen aufgebaut sind. Diese Struktur ermöglicht nun auch Bereichsabfragen nach Produkttypen als auch Marken, wobei diese noch effizienter durch die Blattmengen beantwortet werden können. Dies wird durch einen Algorithmus ermöglicht, der weiß, welche Blätter die relevanten Daten beinhalten und somit nicht die komplette Liste der Produkte durchlaufen muss. Der DC-Baum speichert eine Konzepthierarchie pro Dimension und ordnet jedem Attributwert eine ID pro eingefügtem Datensatz zu. Dies vermeidet das Abspeichern von langen Zeichenketten, definiert aber keine totale Ordnung. Wichtig ist, dass der DC-Baum seine Konzepthierarchie dynamisch verwaltet. Eine Identifikationsnummer wird als Ganzzahl abgespeichert und hat eine feste Länge von 4 Bytes. Dabei geben die vier höchstwertigen Bits die Höhe der ID in der Konzepthierarchie an, um Identifikationsnummern in verschiedener Level zu unterscheiden. Der DC-Baum repräsentiert die Konzepthierarchie als eine Art Wörterbuch, indem er die ID des Vaters für jede ID in einer Konzepthierarchie abspeichert. Am Beispiel aus Abbildung 4 enthält jeder Datensatz einen Wert für jede Region, Nation und KundenID. Der DC-Baum weist jedem Wert eine ID zu und aktualisiert seine Konzepthierarchie für die Dimension Kunde Minimal-beschreibende Sequenzen Die vom X-Baum verwendeten MBRs eignen sich nicht als Approximationsmethode für den Einsatz beim DC-Baum. Ab- Abbildung 5: Vergleich zwischen der totalen (oben) und der partiellen (unten) Ordnung Abbildung 6: Vergleich zwischen einer MBR und einer MDS bildung 6 zeigt ein Beispiel für zwei partiell geordnete Dimensionen A und B, wobei die totale Ordnung durch die Indizes gegeben ist. Die linke Abbildung zeigt ein MBR, welche eine totale Ordnung für diese Dimension annimmt. Die Angabe ([A2, A8], [B2, B5]) ist ausreichend zur Definition einer MBR, da der Bereich [A2, A8] alle Attribute enthält, die zwischen A2 und A8 liegen. Allerdings gilt dies nicht für eine partielle Ordnung dieser Dimension. Deshalb verwendet der DC-Baum so genannte Minumum Describing Sequences (MDSs). Die Approximation mit Hilfe der MDS wird auf der rechten Seite von Abbildung 6 dargestellt. Dort werden nur Attributwerte abgebildet, die in mindestens einem Datensatz vorhanden sind. So sind zum Beispiel die beiden Attribute A1 und A4 nicht in der ersten Menge des MDS enthalten. Eine MDS deckt also weniger leere Bereiche als ein MBR ab. Dafür muss sie andererseits mehr Informationen abspeichern, da die MDSs untereinander in ihrer Größe variieren. Folgenden Punkt gilt es zu beachten: Erstens müssen alle Attributwerte einer 4

5 gegebenen Dimension dem gleichen Level der Konzepthierarchie angehören. Zweitens ist der Messwert kein Bestandteil der MDS, wird aber mit dem Knoten abgespeichert, da die MDS mit dem Messwert verbunden ist. Die erste MDS eines neuen DC-Baumes sieht wie folgt aus MDS(ALL,..., ALL). Dadurch sind die relevanten Level alle mit dem obersten Level initialisiert. Beim Durchführen eines Hierarchiesplittes für einen gegebenen Knoten wird eine Dimension bestimmt und der relevante Level dieser Dimension wird um eins verringert für die MDS der zwei entstandenen Untergruppen Algorithmen Die nachfolgend vorgestellten Algorithmen des DC-Baumes werden hier in ihrer Funktionsweise beschrieben. Der Pseudocode zu diesen Algorithmen findet sich in Anhang A Einfügen Der vorgestellte Einfügealgorithmus ist annähernd unverändert im Vergleich zum Einfügealgorithmus des X-Baumes. Der einzufügende Datensatz enthält bereits die zugewiesenen IDs für seine Attribute und Messwerte. Nachdem die Messwerte des Verzeichnisknotens aktualisiert wurden, wählt die ChooseSubtree- Methode ein Kind follow aus, in welchem dann der Datensatz weiter eingefügt werden soll. Muss darauf auch der follow geteilt werden, so enthält der Verzeichnisknoten ein neues Kind. Hat dieser Verzeichnisknoten seine Kapazität überschritten, so wird dem Splitt-Algorithmus dieser Knoten als Parameter übergeben. Das Ergebnis dieses Algorithmuses ist entweder ein gesplitteter Verzeichnisknoten oder ein Superknoten. War dieser schon ein Superknoten, so wird dieser vergrößert, ansonsten wird ein neuer Superknoten erzeugt Splitten Der Splitt-Algorithmus für die Verzeichnisknoten durchläuft alle Dimensionen, bis er einen angemessenen Splitt findet oder alle Dimensionen geprüft hat. Zu Beginn des Algorithmus wird eine Splittdimension aus den Hierarchieleveln der Elemente der MDS selektiert. Damit eine balancierte Struktur entsteht, selektiert der Algorithmus die Dimension mit dem höchsten Hierarchielevel. Enthält z. B. eine MDS einen ALL-Wert in einer Dimension und in allen anderen Dimensionen nur Werte von niedrigeren Leveln in der Konzepthierarchie, so wird die Dimension mit dem ALL-Wert als Splittdimension ausgewählt. Anschließend werden die MDSs der Verzeichniseinträge an die MDS des Verzeichnisknotens angepasst, da sie in jeder Dimension Elemente enthalten, die im gleichen Level der entsprechenden Konzepthierarchie sein müssen (Definition der MDS). Da die MDS eines Verzeichnisknotens selbst alle MDSs der Einträge des Verzeichnisknotens enthält, ist diese Verzeichnis-MDS die beste Wahl. Die modifizierten MDSs und die gewählte Splittdimension werden dem Hierarchiesplitt-Algorithmus als Parameter übergeben. Dabei entstehen zwei Gruppen von MDSs. Sind die resultierenden Gruppen zu unausgeglichen oder sie überlappen sich zu sehr, so wird eine andere Dimension ausgewählt. Wird daraufhin kein entsprechender Splitt für irgendeine Dimension gefunden, so wird auch hier ein Superknoten erzeugt. Dabei gilt zu beachten, dass ein solcher Knoten wie jeder andere Verzeichnisknoten gesplittet werden kann, falls die Kapazität des Verzeichnisknotens die Blockanzahl des Superknotens überschreitet Hierarchie-Splitt Die Idee dieses Algorithmus ist, dass die Gruppen des MBRs in zwei Untergruppen geteilt werden, indem zuerst zwei MBRs gewählt werden (die so genannten Seeds), die nicht in der gleichen Unter- 5

6 gruppe enthalten sein sollen. Dieser Algorithmus setzt auf dem des R-Baumes auf, allerdings verwendet dieser die partielle Ordnung. Zuerst werden die zwei Seeds-MDSs aus der ganzen Menge ausgewählt, die dann die Eingangsgruppen des Algorithmuses bilden. Danach werden die restlichen Klassen je nach Kriterium in eine der beiden Teilgruppen eingefügt. Im Idealfall sind die beiden Teilgruppen disjunkt und teilen sich innerhalb dieser beiden Gruppen entlang der Splittdimension so viele Attribute wie möglich. Die Laufzeit dieses Algorithmuses ist in O(n 2 ), da für jede verbleibende MDS geprüft werden muss, zu welcher Gruppe diese zugeordnet wird. Dabei müssen bei jedem Schleifendurchlauf zwei Fragen beantwortet werden. Welche MDS wird als nächstes eingefügt und in welche der beiden Teilgruppen? Die erste Frage wird durch die Splittdimension entschieden. Das Splitten entlang der Splittdimension hat die Absicht zwei Gruppen mit disjunkten Attributen zu erhalten. Dieser Algorithmus wählt eine Gruppe so aus, dass die neue MDS mit der Gruppen-MDS so viele Attributwerte wie möglich in dieser Splittdimension gemeinsam haben. Die zweite Frage wird durch die drei Kriterien Überlappung, Ausdehnung und Volumen beantwortet, wobei die drei Kriterien in dieser Reihenfolge geprüft werden. Daher wird die gewählte MDS in die Gruppe eingefügt, mit der sie sich am geringsten überlappt. Falls dies keine Entscheidung (bei Gleichheit) brachte, so wird die Ausdehnung betrachtet. Sollte sich das Volumen vergrößern oder eine Entscheidung nicht erlauben, so wird eine der Gruppen ausgewählt Bereichsabfragen Der DC-Baum bietet zusätzlich eine Unterstützung für Bereichsabfragen. Dafür wird dem Algorithmus eine Bereichs-MDS als Parameter übergeben. Der Algorithmus durchläuft alle Dimensionen der Verzeichniseinträge. Dabei werden in jedem Schritt die beiden MDSs der Abfrage und des Verzeichnisknotens vergleichbar gemacht werden, um sie anschließend miteinander zu vergleichen. Dabei gilt es drei Fälle zu unterscheiden. Erstens, die beiden Bereiche überlappen sich überhaupt nicht, dann ist dieser Eintrag nicht relevant für diese Abfrage und die Ergebnismenge bleibt unverändert. Zweitens, der Bereich der Eintrages ist komplett in der Bereichsabfrage enthalten, so wird dieser Eintrag komplett zu der Ergebnismenge hinzugefügt. Oder drittens, die beiden Bereiche überlappen sich, so wird diese Bereichsabfrage rekursiv für den Sohnknoten aufgerufen. 4. Leistungsmessung Dieser Abschnitt vergleicht die Leistungen des DC-Baumes mit den denen des X- Baumes und der sequentiellen Suche unter realistischen Bedingungen Testumgebung Die zugrundeliegende Datenbank für die Leistungsmessungen des DC-Baumes war der TPC Benchmark D (TPC-D) [13]. Dabei handelt es sich um ein Geschäfts- Data Warehouse mit Dimensionen wie z. B. Teile, Lieferanten, Kunden, usw. Weiter eignet sich dieser Benchmark für Langzeitabfragen auf komplexen Datenstrukturen Ablauf der Messungen Damit die Leistung des DC-Baumes mit den anderen beiden Algorithmen verglichen werden konnte, mussten zuerst einmal Bereichsabfragen erzeugt werden. Es wurden zufällig Level aus der Konzepthierarchie für jede Dimension ausgewählt, die dann einer Bereichs-MDS zugeordnet wurden. Am Beispiel der Dimension Lieferant mit funktionalen Attributen Region, Nation und Lieferant würden die Bereichsabfragen zufällige Attributwerte aus diesen enthalten. Die Größe der einzelnen Mengen der Bereichs-MDS ist durch ihre Se- 6

7 lektivität begrenzt. Bei einer Selektivität von 15% enthält diese Menge bis zu 15% von allen Attributen in jeder Dimension. Allerdings gab es bei dieser Art der Abfragenerzeugung ein Problem, da der X-Baum im Gegensatz zum DC-Baum MBRs benutzt und somit mit den MDSs und Konzepthierarchien nicht umgehen konnte. Dies konnte vermieden werden, indem zu jedem Level in der Konzepthierarchie eine zusätzliche Dimension hinzugefügt wurde. Hingegen mussten keine Änderungen bei den Bereichs-MDSs gemacht werden, um diese in Bereichs- MBRs des X-Baumes zu konvertieren. Jetzt war es möglich, alle drei Indexstrukturen miteinander zu vergleichen. Damit die Messungen fair abliefen, stand allen drei Indexstrukturen der gleiche Arbeitsspeicher, nämlich genauso viel wie der DC-Baum beantspruchte, zur Verfügung Ergebnisse Die nachfolgenden Tests über die Einfügezeiten und die Abfragezeiten wurden mit verschiedenen Selektivitäten durchgeführt. Dabei hat auch die Größe der Datenwürfelbereiche variiert, nämlich von bis zu Datensätzen. Der X-Baum speichert im Gegensatz zum DC-Baum keine Konzepthierarchien ab und vermeidet dadurch häufige Berechnungen, was die Einfügezeit signifikant verringert. Allerdings haben Messungen ergeben, dass das Einfügen eines einzelnen Datensatzes in den DC-Baum nur ungefähr 0,025 Sekunden benötigt und das auf einer HP C160 mit 768MB RAM und HP UX Das dynamische Einfügen hat daher keinen erheblichen Einfluss auf die Laufzeit des Data Warehouses und ermöglicht somit den DC-Baum immer aktuell zu halten. Die Testmessungen für Bereichsabfragen zeigten eine Reduzierung der Ausführungszeiten beim DC-Baum im Vergleich zu den anderen Indexstrukturen. Tatsächlich betrug die Beschleunigung für die Bereichsabfragen des DC-Baumes bezogen auf den X-Baum 4,5 bei einer Selektivität von 5%. Gegenüber der sequientiellen Suche sogar um 12,5. Die Messungen zeigten weiter, dass Bereichsabfragen mit einer Selektivität von 5% am schnellsten verarbeitet werden konnten. Dies liegt am Kompromiss zwischen dem Level, bei dem der DC-Baum die Bereichsabfragen komplett beantwortet, und den Ausführungskosten bei Bereichsabfragen mit größeren Bereichs-MDS. Je größer die Abfrage- MDS, desto höher ist auch die Wahrscheinlichkeit, dass die MDS eines Eintrages vollständig in der Abfrage-MDS enthalten ist. Daher ist auch klar, dass eine größere Abfrage-MDS eine bessere Ausführung erlaubt. Demgegenüber steht die teuere Berechnung der Abfrage-MDS, da die Wahrscheinlichkeit für die Überlappung von der Größe der Mengen abhängig ist. Beträgt die Selektivität der Bereichsabfragen nur 1%, so sind diese zu klein um die Abfrage zu bearbeiten. Hingegen bei einer Selektivität von 25% ist die Berechnung zu aufwendig, womit der beste Kompromiss bei 5% liegt. Weiter fällt auf, dass die Knotengröße, die durchschnittliche Anzahl an Einträgen, für die zwei höchsten Level im DC-Baum unterhalb der Wurzel linear mit der Anzahl der Datensätze zunimmt. Allerdings stabilisiert sich die Knotengröße bei 15 Einträgen im höchsten Level. Das liegt daran, dass bei jedem Splitten eines Verzeichnisknotens zwei neue Verzeichnisknoten mit MDSs erzeugt werden, die entweder weniger Attributwerte oder Attributwerte eines niedrigeren Level der Konzepthierarchie in jeder Dimension enthalten. 5. Zusammenfassung Mit dem DC-Baum wurde eine dynamische Indexstruktur vorgestellt, das ihr Einsatzgebiet im Bereich des Data Warehouse findet und dabei zwei Nachteile bisheriger Indexstrukturen umgeht. Dabei handelt sich um das Aktuellhalten beim Einspielen neuer Datensätze in die Indexstruktur auf der einen Seite und die 7

8 ständige Verfügbarkeit des Data Warehouses auf der anderen Seite. Weiter wurde eine effiziente Unterstützung für Bereichsabfragen geschaffen, da diese sehr häufig in diesem Gebiet vorkommen. Die Messungen am TPC-D-Benchmark gaben Argumente, dass diese Indexstruktur auch in professionellen RDBMS Verwendung finden sollte. Allerdings gibt es bis heute noch keine Implementierung in einem solchen System. Ein möglicher Grund dafür könnte noch die quadratische Laufzeit des Splittalgorithmuses sein. Daher sind auch die Erfinder des DC-Baumes motiviert, diesen effizienter zu implementieren, damit ihre entworfene Indexstruktur den Einsatz auch in professionellen Systemen findet. Aber erst die Zukunft wird zeigen, wie diese Indexstruktur sich im alltäglichen Einsatz eines Data Warehouses bewährt. A. Algorithmen Nachfolgend sind die Algorithmen des DC-Baumes im Pseudocode aufgeführt. A.1. Einfügen eines Verzeichnisknotens i n t DirNode : : I n s e r t ( data d ) Update measure value ; f o l l o w = ChooseSubtree ( d ) ; f o l l o w >i n s e r t ( d ) ; I f f o l l o w has been s p l i t : I n s e r t new son ; I f the c a p a c i t y i s reached : S p l i t ( DirNode NewBrother ) ; I f s p l i t was s u c c e s s f u l : return SPLIT ; Else : return SUPERNODE; return NONE; A.2. Splitten eines Verzeichnisknotens DirNode : : S p l i t ( DirNode NewBro) While found = FALSE and a t l e a s t one dimension has not been p r o c e s s e d : Choose dimension by l e v e l o f concept h i e r a r c h y ; Adapt MDSs o f e n t r i e s to MDS o f d i r e c t o r y node ; H i e r a r c h y S p l i t ( ModifiedMDSs [ ], SplitDimension ) ; I f nodes are balanced and o v e r l a p i s not too high : found = TRUE; I f non o f the s p l i t s was s u c c e s s f u l : Create supernode ; A.3. Hierarchie-Splitt H i e r a r c h y S p l i t (MBSs [ ], SplitDim ) Compute the c o v e r i n g MDS f o r each p a i r o f MDSs; I n i t i a t e the two s e e d s by choosing the p a i r with the l a r g e s t MDS; While remaining MDSs e x i s t : Compute the enlargement o f the two groups in the s p l i t dimension f o r each remaining MDS; Choose the MDS by the g r e a t e s t d i f f e r e n c e between the enlargements o f the two groups in the s p l i t dimension ; I n s e r t t h i s MDS i n t o the group with t h e minimum r e s u l t i n g o v e r l a p between the groups ; Resolve t i e s by choosing the minimum sum o f e x t e n s i o n s ; Resolve f u r t h e r t i e s by choosing the minimum sum o f volumes ; 8

9 A.4. Bereichsabfrage Der nachfolgend aufgeführte Pseudocode für Bereichsabfragen verwendet intern den Aggregationsoperator SUM. Selbstverständlich sind auch andere Aggregationsoperatoren möglich. double DirNode : : RangeQuery ( rngmds) r e s u l t = 0. 0 ; For each d i r e c t o r y entry : For each dimension : I f the rngmds and the MDS o f the entry are not on the same l e v e l in the c u r r e n t dimension, adapt the MDS with the lower l e v e l to the one with the higher l e v e l ; I f t h e r e i s o verlap between rngmds and the MDS o f the entry : I f the MDS o f the entry i s contained in the rngmds : r e s u l t += measure value o f entry ; Else : r e s u l t += entry >RangeQuery ( rngmds) ; Literatur [1] Stefan Berchtold, Daniel A. Keim, and Hans-Peter Kriegel. The X- Tree: An Index Structure for High- Dimensional Data. In Proc. 22th Int. Conf. on Very Large Databases, pages 28 39, Bombay, India, [2] Surajit Chaudhuri and Umeshwar Dayal. An Overview of Data Warehousing and OLAP Technology. SIG- MOD Record, 26(1):65 74, Analytical Processing) to User Analyst: An IT Mandate. Technical Report, [4] Ramez Elmasri and Shamkant B. Navathe. Fundamentals of Database Systems. Addision Wesley, Reading, MA, 4th edition, [5] Martin Ester, Jorn Kohlhammer, and Hans-Peter Kriegel. The DC-Tree: A Fully Dynamic Index Structure for Data Warehouses. In ICDE, pages , [6] Himanshu Gupta, Venky Harinarayan, Anand Rajaraman, and Jeffrey D. Ullman. Index Selection for OLAP. In ICDE, pages , [7] Antonin Guttman. R-Trees: A Dynamic Index Structure for Spatial Searching. In Proc. ACM SIGMOD Int. Conf. on Management of Data, pages 47 57, Boston, MA, [8] Ching-Tien Ho, Rakesh Agrawal, Nimrod Megiddo, and Ramakrishnan Srikant. Range Queries in OLAP Data Cubes. In Proc. ACM SIGMOD Int. Conf. on Management of Data, pages 73 88, New York, NY, [9] William H. Inmon. Building the Data Warehouse. John Wiley & Sons, Inc., New York, NY, 3rd edition, [10] Marcus Jürgens. Index Structures for Data Warehouses. Ph.D. Thesis, [11] Oracle Datenbank. oracle.com/database/index.html. [12] Sybase Datenbank. http: // informationmanagement. [13] Transaction Processing Council. TPC Benchmark D. [3] Edgar F. Codd, S. B. Codd, and C. T. Salley. Providing OLAP (On-Line 9