Seminar Data Warehousing Seminar Data Warehousing Thema: Speichermodelle für Data-Warehouse-Strukturen Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Ernst-Abbe-Platz 1-4 07743 Jena Lehrstuhlinhaber Prof. Dr. Klaus Küspert von Antje Höll Betreuer: Dipl.-Inf. David Wiese 27.06.2005 0 Seminar Data Warehousing Gliederung 1 Einleitung .......................................................................................................................... 1 2 Begriffsdefinition.............................................................................................................. 2 3 Relationale Speicherung .................................................................................................. 2 3.1 Star Schema................................................................................................................ 3 3.2 Snowflake Schema ..................................................................................................... 4 3.3 Mischformen .............................................................................................................. 5 3.3.1 Factless Fact Table ............................................................................................. 6 3.3.2 Galaxy Schema................................................................................................... 6 3.3.3 Fact Constellation Schema ................................................................................. 6 3.4 4 Darstellungsarten für Klassifikationshierarchien ....................................................... 7 3.4.1 Horizontale Darstellung ..................................................................................... 7 3.4.2 Vertikale Darstellung ......................................................................................... 7 3.4.3 Kombinierte Darstellung .................................................................................... 8 Multidimensionale Speicherung ..................................................................................... 8 4.1 Datenstrukturen .......................................................................................................... 9 4.2 Speicherung................................................................................................................ 9 4.2.1 Probleme bei der Array-Speicherung............................................................... 11 4.3 Grenzen der multidimensionalen Datenhaltung ....................................................... 12 4.4 HOLAP..................................................................................................................... 12 5 Vergleich (ROLAP, MOLAP, HOLAP)....................................................................... 13 6 Fazit ................................................................................................................................. 14 Abbildungsverzeichnis Literaturverzeichnis I Seminar Data Warehousing 1 Einleitung „Bei einem Data Warehouse System handelt es sich um eine Sammlung von unterschiedlichen Technologien, welche dem geschulten Mitarbeiter (Beispielsweise einem Datenerfasser, Manager, Analytiker, Sachbearbeiter) ermöglicht, dass er seine Entscheidungen schneller und qualitativ besser treffen kann. Von einem solchen System wird erwartet, dass die richtigen Informationen zum richtigen Zeitpunkt am richtigen Ort sind, damit die richtigen Entscheidungen getroffen werden können. Ein Data Warehouse ist ein wichtiges System zur Integration von unterschiedlichen Informationsquellen innerhalb einer Unternehmung.“ [3] In der Abb.1 ist ein Überblick über eine mögliche Architektur eines Data-WarehouseSystems gegeben. Abb.1: Das Data-Warehouse-Prinzip [4] Diese Arbeit befasst sich im Rahmen des Seminars Data Warehousing mit den Speichermodellen für die Data-Warehouse-Strukturen. Dabei werden im nachfolgenden Abschnitt die Begriffe Kennzahl, Dimension, Hierarchie und Datenwürfel kurz erklärt. Der dritte Abschnitt befasst sich mit der relationalen Speicherung und es werden mögliche Schemata erläutert, wie man multidimensionale Datenmodelle auf relationale Datenmodelle abbilden kann. Im vierten Abschnitt 1 Seminar Data Warehousing wird die multidimensionale Speicherung vorgestellt. Es werden u.a. Speicherungsmöglichkeiten genannt und einige Grenzen der Datenhaltung aufgezeigt. Abschließend werden die zwei Möglichkeiten zur Speicherung des multidimensionalen Datenmodells und eine Kombination beider Modelle tabellarisch verglichen. 2 Begriffsdefinition Zunächst werden einige Begriffe des multidimensionalen Datenmodells erläutert, die zum besseren Verständnis beitragen sollen. • Kennzahlen sind numerische Messgrößen, die betriebswirtschaftliche Sachverhalte beschreiben. Als Beispiele sind hierfür Umsatz, Gewinn, Verlust oder Deckungsbeitrag zu nennen. • Eine mögliche Sicht auf die assoziierten Kennzahlen geben Dimensionen. Sie sind eine endliche Menge von n (n ≥ 2) Dimensionselementen (Hierarchieobjekten), die eine semantische Beziehung aufweisen und der orthogonalen Strukturierung des Datenraums dienen. Produkt, Geographie und Zeit sind Beispiele für Dimensionen. • Um die Hierarchien in den Dimensionen darzustellen, verwendet man ein Klassifikationsschema. • Der Datenwürfel, auch Hypercube genannt, besteht aus mehreren Dimensionen zur Identifikation von Kennzahlen. Eine OLAP-Anwendung kann aus einem oder mehreren Datenwürfeln bestehen. 3 Relationale Speicherung Die relationale Speicherung eines multidimensionalen Datenmodells, die auch ROLAP (relational OLAP) genannt wird, setzt auf herkömmlichen relationalen Datenbanken auf. Somit wird eine multidimensionale Analyse auf einer relationalen Datenbank ermöglicht. Die Daten werden hierbei in Relationen gespeichert, die sich gut als Tabellen visualisieren lassen. Für eine effiziente Abbildung von multidimensionalen Konstrukten auf relationale Datenbankschemata sind einige Anforderungen zu beachten. Zum einen sollten die multidimensionale Anfragen effizient in die entsprechenden relationalen Anfragen zu übersetzten und abzuarbeiten sein. Zum anderen sollte der Verlust an anwendungs2 Seminar Data Warehousing bezogener Semantik möglichst gering ausfallen und die Wartbarkeit der relationalen Tabellen einfach und schnell zu realisieren sein. Um die Strukturen eines Datenwürfels abbilden zu können, wird bei der relationalen Speicherung eine Trennung von Struktur und Inhalt vorgenommen. Das heißt, man unterscheidet zwischen Faktentabellen und Dimensionstabellen. Die Faktentabelle ist relativ einfach zu realisieren, da sie den Datenwürfel ohne Klassifikationshierarchien speichert. Dabei werden die Dimensionen des Würfels als Spalten und jede Not NullZelle als ein Tupel der Relation aufgefasst. Ein Beispiel für eine Faktentabelle ist in der Abb. 2 dargestellt. Hierbei wird ein Teil der Spalten als Dimensionen und der andere Teil der Spalten als Kennzahlen betrachtet und somit ist der Datenwürfel äquivalent zur resultierenden Tabelle, der Faktentabelle. Abb.2: Dualismus von Würfel und Tabelle [5] Für die Abbildung der Klassifikationshierarchien eignen sich verschiedene Schemata, die nachfolgend beschreiben werden. 3.1 Star Schema Die zentrale Faktentabelle im Star Schema beinhaltet einen Primärschlüssel, der aus den Primärschlüsseln der Dimesionstabellen zusammengesetzt sein kann, und Spalten für die zu analysierenden Geschäftsdaten (Kennzahlen). Im Allgemeinen ist sie die längste Tabelle im Star Schema, da sie sehr viele Tupel enthält. Pro Dimension enthält das Star Schema eine Dimensionstabelle, welche komplett denormalisiert ist. Jede Dimensionstabelle enthält einen Primärschlüssel, die hierarchische Struktur der jeweiligen Dimension und die qualifizierenden Attribute. Die Dimensionstabellen sind im Vergleich zu der Faktentabelle durch die vielen Attribute wesentlich breiter und die Korrelation zur Faktentabelle geschieht mittels Fremdschlüsselbeziehungen. Die 3 Seminar Data Warehousing Abb.3 zeigt die sternförmige Darstellung der Dimensionstabellen um die Faktentabelle, welches dem Schema den Namen gibt. Durch die Denormalisierung liegen in den Dimensionstabellen Redundanzen vor, die zu Änderungsanomalien führen können. Trotzdem führen diese Redundanzen zu einer schnelleren Anfragebearbeitung, da nicht, wie in normalisierten Schemata, erst Joins über mehrere Tabellen gemacht werden müssen. Weitere Vorteile bieten der einfache Aufbau der Dimensionstabellen und die einfache und flexible Darstellung von Klassifikationshierarchien. Abb.3: Beispiel für ein Star Schema [1], S.206 Diese Eigenschaften führen dazu, dass das Star Schema ein verbreitetes Modell für das Data Warehouse Design ist. 3.2 Snowflake Schema Im Gegensatz zum Star Schema sind die Dimensionstabellen hier normalisiert. Das heißt, für jede Klassifikationsstufe wird eine eigene Relation angelegt. Diese Dimensionstabellen enthalten jeweils einen Primärschlüssel und beschreibende Attribute. Die 1:n-Beziehung zwischen zwei übereinander liegenden Klassifikationsstufen wird mittels eines Fremdschlüssels von der tiefer liegenden auf die nächst höhere Stufe dargestellt. In der Abbildung 4 ist eine graphische Darstellungsmöglichkeit des Snowflake Schemas zu sehen. Da diese entfernt an eine Schneeflocke erinnert, bekam diese Art von Schema ihren Namen. 4 Seminar Data Warehousing Die Kennzahlen werden, wie bei dem Star Schema beschrieben, mit Hilfe einer Faktentabelle verwaltet, wobei die Dimensionsspalten aus Fremdschlüsseln auf die Dimensionselemente der niedrigsten Stufe bestehen. Den Primärschlüssel der Faktentabelle bilden alle diese Fremdschlüssel. Abb.4: Beispiel für ein Snowflake Schema [1], S.204 Ein Vorteil dieses Modells ist die Vermeidung von Änderungsanomalien, da die Dimensionstabellen normalisiert sind. Aber durch die höhere Anzahl an Dimensionstabellen wird das Snowflake Schema wesentlich komplexer, was eine aufwendigere Administration, erhöhte Zugriffskosten durch die vielen benötigten Joins und eine schlechtere Performance zur Folge hat. 3.3 Mischformen Welches der beiden Schemata besser geeignet ist, hängt vom Anwendungsprofil ab. In der Realität verwendet man aber häufig Mischformen, um die spezifischen Nachteile von Star und Snowflake Schema zu vermeiden bzw. deren spezifische Vorteile zu nutzen. 5 Seminar Data Warehousing 3.3.1 Factless Fact Table Factless Fact Tables enthalten, wie der Name schon sagt, in den Faktentabellen keine Kenngrößen. Dies kann dann eintreten, wenn nur das Auftreten eines bestimmten Ereignisses aufgezeichnet werden soll, z.B. wenn nur das Faktum, dass ein bestimmter Kunde ein bestimmtes Produkt zu einer bestimmten Zeit gekauft hat, von Interesse ist. 3.3.2 Galaxy Schema Da die Geschäftssituation in der Regel sehr komplex ist, gibt es in einem Unternehmen sehr viele Kenngrößen mit jeweils unterschiedlichen Dimensionen. Für diese Modellierung eignet sich das Galaxy Schema. Es enthält mehrere unabhängige Faktentabellen, die teilweise mit den gleichen Dimensionstabellen verknüpft sind. Diese Faktentabellen entstehen, wenn die Kennzahlen durch unterschiedliche Dimensionen beschrieben werden. In der Abbildung 5 ist dies gut dargestellt, denn die zwei Faktentabellen Einkauf und Verkauf entstehen, weil die Kennzahlen Einkaufsmenge und Verkaufsmenge nicht auf die identischen Dimensionstabellen zugreifen. Abb.5: Beispiel für ein Galaxy Schema [6] 3.3.3 Fact Constellation Schema Mit dem Fact Constellation Schema können gegenüber den bisher erläuterten Schemata auch aggregierte Kennzahlen in zusätzlichen Faktentabellen abgespeichert werden. Das Attribut „Ebene“, welches zur Unterscheidung der Klassifikationsstufen 6 Seminar Data Warehousing in den Dimensionstabellen dient und in einigen Modellen verwendet werden kann, wird hier nicht benötigt. Des Weiteren erreicht man, im Vergleich zur Aggregation in einer Tabelle, eine höhere Performance. Dennoch kann das Schema durch eine Vielzahl von Faktentabellen schnell unübersichtlich werden und schwerer zu handhaben sein. 3.4 Darstellungsarten für Klassifikationshierarchien Im Folgenden werden weitere Möglichkeiten zur denormalisierten Darstellung von Klassifikationen erläutert. 3.4.1 Horizontale Darstellung Bei der Horizontalen Darstellung werden die Stufen der Klassifikationshierarchie als Spalten in eine denormalisierte Dimensionstabelle modelliert. Damit sind Einschränkungen auf höherer Granularität auch ohne teuere Verbundoperationen (Joins) abarbeitbar. Aber bei Anfragen bestimmter Stufen muss eine Duplikateliminierung erfolgen, die durch die erforderliche Sortierung relativ teuer ist. Die Anordnung der Spalten nebeneinander gibt dem Namen, wie man in der Abb. 6 sehen kann. Produkt_ID Artikel Produktgruppe Produktfamilie Kategorie 1234 Lavamat S Waschmaschinen Waschgeräte weiße Ware 1235 Duett Waschmaschinen Waschgeräte weiße Ware 1236 Novotronic Trockner Waschgeräte weiße Ware 1237 Vento 500 Trockner Waschgeräte weiße Ware Abb.6: Horizontale Darstellung einer Klassifikationshierarchie [1], S.206 3.4.2 Vertikale Darstellung Diese Darstellung verwendet eine denormalisierte Dimensionstabelle mit zwei Attributen, eine Dimensions_ID und eine Eltern_ID, wobei die Dimensions_ID ein Schlüssel ist, der die Beziehung zur Faktentabelle schafft und die Eltern_ID einem Attributwert der Dimensions_ID der nächsthöheren Stufe entspricht (Abb. 7). Da das Tabellenschema keine strukturellen Informationen über das Klassifikationsschema enthält, ist eine Änderung am Klassifikationsschema relativ leicht möglich. Ein Nachteil wäre, dass für Anfragen auf einzelnen Stufen mehrere teure Verbundoperationen (engl. self-join) notwendig sind. 7 Seminar Data Warehousing Dimensions_ID Eltern_ID Lavamat S Waschmaschinen Duett Waschmaschinen Novotronic Trockner Vento 500 Trockner Waschmaschinen Waschgeräte Trockner Waschgeräte Waschgeräte weiße Ware Abb.7: Vertikale Darstellung einer Klassifikationshierarchie [1], S.210 3.4.3 Kombinierte Darstellung Die kombinierte Darstellung verbindet die beiden vorher beschrieben Strategien. Hierbei werden Klassifikationsstufen als Spalten repräsentiert, wobei die Spalten generisch bezeichnet werden (Dimensions_ID, Stufe1_ID, Stufe2_ID,…, Stufe (explizite Angabe der Stufenebene)) und die Knoten aller höheren Stufen als Tupel gespeichert. Die Abb. 8 zeigt das Resultat. Dimensions_ID Stufe1_ID Stufe2_ID Stufe3_ID Stufe Lavamat S Waschmaschinen Waschgeräte weiße Ware 0 Duett Waschmaschinen Waschgeräte weiße Ware 0 Novotronic Trockner Waschgeräte weiße Ware 0 Vento 500 Trockner Waschgeräte weiße Ware 0 Waschmaschinen Waschgeräte weiße Ware NULL 1 Trockner Waschgeräte weiße Ware NULL 1 Waschgeräte weiße Ware NULL NULL 2 Abb.8: Kombinierte Darstellung einer Klassifikationshierarchie [1], S.211 4 Multidimensionale Speicherung Multidimensionale Datenbanken setzen die auf konzeptioneller Ebene dargestellten multidimensionalen Datenstrukturen physisch um. Es wird eine Zellenstruktur gebaut, in der jede Zelle entlang der entsprechenden Dimensionen indiziert werden kann. Solche Systeme, die ihre Daten in einem multidimensionalen Feld speichern, werden auch multidimensional OLAP (MOLAP) genannt. Für die Speicherung werden multidimensionale Datenbankmanagementsysteme (MDBMS) verwendet. 8 Seminar Data Warehousing 4.1 Datenstrukturen Da die Dimensionen und Würfel grundlegende Datenbankobjekte eines MDBMS sind, werden sie genauer betrachtet. In Bezug auf die Speicherung sind Dimensionen endlich geordnete Listen von Dimensionswerten, welche die Dimensionselemente auf allen Klassifikationsstufen enthalten. Indem man die Dimensionswerte auf eine Indexmenge abbildet, erreicht man ihre „Ordnung“. Dadurch sind sie mittels der Ordnungszahl eindeutig identifizierbar und für die spätere Array-Umsetzung wird der Indexzugriff einfacher. Eine Dimension D mit m Dimensionswerten kann man formal als m-Tupel darstellen: D = ( x1D , x2D ,..., xmD ) . Einen mehrdimensionalen Würfel kann man durch die Kombination mehrere Dimensionen definieren. Hierbei hilft die Vorstellung, dass die n Dimensionen einen ndimensionalen Raum aufspannen. Die m verschiedenen Werte einer Dimension teilen diesen Würfel in m verschiedene parallele Ebenen. Der Schnittpunkt von n Ebenen eines n-dimensionalen Würfels bezeichnet eine Zelle, welche die jeweiligen Kennzahlen enthält. Diese Zelle kann eindeutig über ein n-Tupel von Dimensionswerten angesprochen werden, wobei der i-te Wert des Tupels ein Wert der Dimension Di ist. Einen Würfel kann folgendermaßen beschreiben werden: W = (( D1 , D2 ,..., Dn ), ( M 1 : Typ1 ,..., M m : Typm )) Di: Dimensionen, Mi:Typi: Kenngrößen des Würfels mit dem jeweiligen Datentyp Besonders betrachtet werden müssen leere Zellen und dabei vor allem die Ursache warum sie leer sind (z.B. kein Wert verfügbar oder Wert aufgrund der Semantik der Anwendung nicht sinnvoll). Für die verschiedenen Fälle muss dann jeweils ein Symbol zur Darstellung definiert werden. 4.2 Speicherung Die multidimensionale Speicherung basiert im Wesentlichen auf multidimensionalen Arrays. Dabei werden die Zellen eines mehrdimensionalen Würfels sequentiell in ein n-dimensionales Array, dessen Indizes die Koordinaten der Würfelzellen bilden, gespeichert. Dieses Array muss wiederum zum Speichern in eine eindimensionale Liste oder in ein eindimensionales Array überführt werden, was als Linearisierung be9 Seminar Data Warehousing zeichnet wird. Es gibt verschiedene Linearisierungsreihenfolgen. In Abb. 9 ist eine Array-Linearisierung für ein dreidimensionales Array dargestellt. Abb.9: Linearisierungsreihenfolge [1], S.236 Allgemein lässt sich daraus folgende Berechnungsvorschrift für den Array-Index der Zelle z(x1, x2,…, xn), xi ∈ Di , eines Würfels ableiten: Index( z ) = x1 + ( x2 − 1) ⋅ D1 + ( x3 − 1) ⋅ D1 ⋅ D2 + ... + ( xn − 1) ⋅ D1 ⋅ ... ⋅ Dn−1 n i −1 = 1 + ∑ ( xi − 1) ⋅ ∏ D j j =1 j =1 Anhand zweier Beispiele soll die Array-Speicherung genauer verdeutlicht werden. In Abb. 10 ist eine Adressberechnung in einem zweidimensionalen Array dargestellt, wobei die Dimension Produkt die Werteliste (Hosen, Hemden, …) enthält und die Dimension Zeit aus der Werteliste (Januar, Februar, …) besteht. Die jeweiligen Ordnungszahlen stehen in Klammern. Um beispielsweise den Indexwert für die Zelle (Kleider, März) zu errechnen, muss folgende Berechnung erfolgen, die sich aus der allgemeinen Berechnungsvorschrift für den Array-Index ergibt: 1 + ( x1 − 1) + ( x2 − 1) ⋅ D1 = 1 + 3 + 2 ⋅ 5 = 14 Abb.10: Beispiel für eine Adressberechnung [1], S.236 Abb. 11 illustriert die Adressberechnung in einem dreidimensionalen Datenwürfel. Wie hier die Reihenfolge der Würfelzellen in einem Array ist, wird in der nebenste- 10 Seminar Data Warehousing henden Abbildung gezeigt. Die Berechnung der einzelnen Indexwerte erfolgt mittels dieser Berechnungsvorschrift: Index( z ) = (( x0 ( D1 + 1) + x1 ) ⋅ ( D2 + 1)) + x2 mit z = ( x0 ,..., xn −1 ) . ALL entspricht hierbei den summierten Werten pro Dimension. Somit ergibt sich beispielsweise für die Zelle (ALL,ALL,ALL) bzw. (5,4,3) ein Indexwert von (5(4 + 1) + 4) ⋅ (3 + 1)) + 3 = 119 . Reihenfolge der Würfelzellen im Array Abb.11: dreidimensionaler Würfel [2], S.37/38 4.2.1 Probleme bei der Array-Speicherung Eines der Hauptprobleme bei der Array-Speicherung stellt die Tatsache dar, dass in der Realität die Würfel zumindest auf der Detailebene dünn besetzt sind. Für die Berechnung der Position einer Zelle in einem eindimensionalen Array ist es notwendig, dass für leere Zellen Platz reserviert wird. Somit werden beim Auslesen von vielen Leerzellen, bei gleicher Menge an Seiten, weniger effektive Daten übertragen. Ein weiteres Problem ergibt sich bei ungünstig gewählten Linearisierungsreihenfolgen, da dadurch die Anzahl der Plattenzugriffe beeinflusst wird und somit auch die Anfrageperformance. Dies ist natürlich auch abhängig von der Art der Anfrage. Ziel ist es also, so wenig wie möglich Lesevorgänge zu haben, damit die gewünschten Daten schneller angezeigt werden können. Deshalb ist bei der Definition eines Würfels die Reihenfolge der Dimensionen zu beachten. 11 Seminar Data Warehousing 4.3 Grenzen der multidimensionalen Datenhaltung Durch die multidimensionale Speicherung kann man zwar eine hohe Anfragegeschwindigkeit erreichen, aber aufgrund von dünn besetzten Datenräumen kann bei Würfeln mit steigender Größe irgendwann eine Skalierungsgrenze erreicht werden. Ein weiterer Grund ist die vorausgesetzte Ordnung der Dimensionswerte bei der Array-Speicherung, denn dies erschwert zeitliche Änderungen an den Dimensionen. So kann das Einfügen neuer Werte oder neuer Klassifikationsstufen eine vollständige Reorganisation des Würfels bedeuten. Weiterhin gibt es für die MDBMS im Moment noch keinen Standard, wie bei den relationalen DBMS das SQL. Man spricht von so genannten proprietären MDBMS. Eine weitere Grenze stellt das Spezialwissen dar, welches zur Erstellung und Wartung der MDBMS erforderlich ist. Dieses Wissen unterscheidet sich immer noch stark von den Kenntnissen für relationale Datenbanken. 4.4 HOLAP Der Ansatz der hybriden Speicherung (Hybrides OLAP) soll die Vor- und Nachteile der vorher beschriebenen Ansätze verbinden. Die Idee ist hier, Detaildaten, die meist in großer Anzahl vorliegen, in einer relationalen Datenbank zu speichern und aggregierte Daten in multidimensionalen Strukturen abzulegen, um einen schnellen Zugriff auf die oberste Klassifikationsstufen zu gewährleisten, da in den aggregierten Daten keine Nulls enthalten sind. Der Zugriff erfolgt über die multidimensionale Datenbank durch ein multidimensionales Anfragewerkzeug. Bei jeder Anfrage wird individuell entschieden, ob die Daten in der multidimensionalen Welt vorliegen, ob sie in der relationalen Welt vorliegen und von dort gelesen werden müssen oder die dritte Möglichkeit, dass sie nur aus Berechnungen von Daten aus beiden Welten zu gewinnen sind. Die Entscheidungsfindung über den nötigen Beschaffungsweg der Daten ist für den Anwender transparent. Die Art der Verteilung auf relationale bzw. multidimensionale Datenbanken ist anwendungsspezifisch. Dennoch wird dieser Ansatz in der Realität wenig verwendet, da für dessen Entwicklung ein umfassendes Wissen aus beiden Welten notwendig ist und sich der Implementierungsaufwand als sehr aufwendig erweist. 12 Seminar Data Warehousing 5 Vergleich (ROLAP, MOLAP, HOLAP) In dieses Kapitel werden die Vor- und Nachteile drei Ansätze tabellarisch gegenübergestellt. ROLAP Vorteile MOLAP HOLAP - verwendet bewährte - Antwortzeiten bei - vereinigt das Beste Datenbanktechnologie kleineren Datenmen- aus ROLAP und MO- - Standard- gen sehr gut LAP Abfragesprache (SQL) - effiziente multidi- - MDDB-System greift - beliebige Skalierbar- mensionale Speicher- nicht mehr auf die o- keit strukturen perativen Systeme zu, - effiziente Speiche- - meist eigene, multi- sondern auf ein relati- rung großer Daten- dimensionale Abfra- onales DW mengen gesprache, i.A. ver- - zahlreiche erfolgrei- ständlicher als SQL che DW-Lösungen basieren auf einer ROLAP-Architektur Nachteile - Standard-SQL für - proprietäre MDDB- - umfangreiche multidimensionale Ana- Systeme werden ein- Kenntnisse über RO- lysen nur bedingt aus- gesetzt, keine Abfra- LAP und MOLAP reichend gesprache als Stan- - enormer Implemen- - schlechtere Perfor- dard definiert tierungs-Aufwand mance (durch Daten- - eingeschränktes Da- - keine einheitliche redundanz kompen- tenvolumen OLAP- sierbar) Abfragesprache - Schnittstelle zu einem RDBMS notwendig - zusätzliche Laderoutinen von RDBMS zum MDBMS 13 Seminar Data Warehousing 6 Fazit Für die Speicherung von multidimensionalen Datenstrukturen kann man die relationale oder die multidimensionale Speicherung wählen. Diese beiden Ansätze wurden in dieser Arbeit vorgestellt. Eine generelle Empfehlung, welche Vorgehensweise am Besten geeignet ist, kann man nicht geben. Jedoch kann man sagen, dass sich die relationale Speicherung sehr gut für dünn besetzte Würfel eignet, da sie auf herkömmlich relationale Datenbanken aufbaut, für die große Datenmengen verwalten kann und eine leichte Skalierbarkeit ermöglicht. Das heißt, je größer die zu speichernde Datenmenge, desto eher überwiegen die Vorteile einer ROLAP-Lösung. Im Gegensatz dazu, ist die multidimensionale Speicherung u.a. wegen der ArraySpeicherung bei dicht besetzten Würfeln vorzuziehen. 14 Seminar Data Warehousing Abbildungsverzeichnis Seite Abb.1 Das Data-Warehouse-Prinzip 1 Abb.2 Dualismus von Würfel und Tabelle 3 Abb.3 Beispiel für ein Star Schema 4 Abb.4 Beispiel für ein Snowflake Schemas 5 Abb.5 Beispiel für ein Galaxy Schema 6 Abb.6 Horizontale Darstellung einer Klassifikationshierarchie 7 Abb.7 Vertikale Darstellung einer Klassifikationshierarchie 8 Abb.8 Kombinierte Darstellung einer Klassifikationshierarchie 8 Abb.9 Linearisierungsreihenfolge 10 Abb.10 Beispiel für eine Adressberechnung 10 Abb.11 dreidimensionaler Würfel 11 II Seminar Data Warehousing Literaturverzeichnis [1] Bauer, A; Günzel, H.: Data Warehouse Systeme. Architektur, Entwicklung, Anwendung. Heidelberg: dpunkt.verlag. 2004. [2] Tam, Y.J.: Datacube: Its implementation and application in OLAP mining. MSc.Thesis, Simon Fraser University, Canada. 1998. Internetquellen [3] http://www.2cool4u.ch/business_it/datawarehouse/datawarehousing_systeme _implementierung.pdf, S.10, 17.06.2005 [4] http://www.seda.wiai.uni-bamberg.de/exwiai/veranstaltungen/praesentationen/ ceus-Stammtisch-20041201.pdf, S.8, 17.06.2005 [5] http://www-is.informatik.uni-oldenburg.de/~koester/Vorlesung/DWH-und-KDD-VL-03---Multidim-Datenmodell.pdf, S.31, 27.06.2005 [6] http://www.wiinf.uni-wuerzburg.de/Dateianlagen/Lehrveranstaltungen/semwi WS0203/Thema%2010.pdf, S.14, 27.06.2005 III