Data Warehouse Systeme - Das multidimensionale Datenmodell

Inhaltsverzeichnis

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1. Einleitung

2. Einführung in das multidimensionale Datenmodell

3. Konzeptuelle Modellierung
3.1. ME/R Modell
3.2. Multidimensional UML (mUML)
3.3. Objektorientierter multidimensionaler Modellrahmen

4. Logische Modellierung
4.1. Struktur des multidimensionalen Datenmodells
4.1.1. Dimensionen
4.1.2. Klassifikationsschema
4.1.3. Klassifikationshierarchie
4.1.4. Würfel, Würfelschema
4.2. Multidimensionale Datenmanipulationskonzepte
4.2.1. Projektions- und Selektionsoperation
4.2.2. Klassifikationsbasierte Bereichsrestriktionen
4.2.3. Multidimensionale Verbundoperationen
4.2.4. Multidimensionale Aggregationsoperationen
4.2.5. Multidimensionale Navigationsoperatoren
4.3. Anfragen in einem Data Warehouse

5. Unterstützungen von Veränderungen
5.1. Temporale Datenbanken
5.2. Veränderungen von Klassifikationshierarchien
5.3. Gültigkeitszeitmatrix
5.4. Veränderungen von Datenbankschemata

6. Zusammenfassung

Literaturverzeichnis

Eidesstattliche Erklärung

Abbildungsverzeichnis

Abb. 1-1 Vorgehensweise beim Entwurf von Datenbanken

Abb. 2-1 Multidimensionaler Datenwürfel

Abb. 3-1 Auszug eines E/R Modells

Abb. 3-2 Die graphische Notation der ME/R - Elemente

Abb. 3-3 Beispielszenario in ME/R-Notation

Abb. 3-4 Ausschnitt des MML-Metamodells

Abb. 3-5 mUML - Schema Produktverkauf

Abb. 3-6 Basiselemente des objektorientierten multidimensionalen Modellrahmens

Abb. 3-7 Gültigkeitszuordnungen für eine Kenngröße

Abb. 4-1 Beispiel eines multidimensionalen Schemas

Abb. 4-2 Ausschnitt aus der Klassifikationshierarchie der Produktdimension

Abb. 4-3 Slice-Operationen

Abb. 4-4 Dice-Operation

Abb.4-5 Beispiel einer multidimensionalen Aggregation

Abb. 4-6 Multidimensionale Navigation

Abb. 5-1 Ausschnitt der Klassifikationshierarchie der Dimension Produkt am 2000-03-01

Abb. 5-2 Ausschnitt der Klassifikationshierarchie der Dimension Produkt am 2001-05-07

Abb. 5-3 Ausschnitt der Klassifikationshierarchie der Dimension Produkt am 2004-08-09

Abb. 5-4 Zeitstempelung der Klassifikationshierarchie der Produktdimension

Abb. 5-5 Gültigkeitszeitmatrix der Klassifikationshierarchie der Produktdimension

Abb. 5-6 Alternativen beim Einfügen einer Dimension

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

In den letzten Jahren haben Data Warehouse Systeme ein reges Interesse im Bereich des Controllings geweckt. Die stark wachsende Integration der Märkte und die stetig fortschreitende Globalisierung führen zu einem enorm steigenden Wettbewerbsdruck. Aus dieser Situation heraus haben Data Warehouse Systeme immer mehr an Bedeutung erlangt um eine entscheidende Aufgabe des Controllings, die Schaffung von Informationskongruenz^[1], zu realisieren.

Die Basis des Data Warehouses, die zentrale Komponente des Data Warehouse Systems, bildet dabei die Sammlung von operativen Daten aus unterschiedlichen Quellsystemen, aus denen durch analytische Operationen entscheidungsunterstützende Informationen für ein Unternehmen gewonnen werden.

Eine zentrale Aufgabe des Data Warehouses ist es, einen adäquaten Modellierungsansatz der Datenstrukturen zur Verwirklichung der physischen Integration und dem Analyseaspekt bereitzustellen. Der Ansatz des multidimensionalen Datenmodells hat sich als besonders adäquat durchgesetzt.

Dieser Beitrag beschäftigt sich mit dem Entwurf einer Datenbank für ein Data Warehouse System unter den Aspekten der konzeptionellen und logischen Modellierung unter Berücksichtigung der Unterstützung von Veränderungen.

Der Fokus liegt dabei auf dem Konzept des multidimensionalen Datenmodells.

In Analogie zu dem Entwurf von konventionellen Datenbanken soll die Vorgehensweise anhand der Abbildung 1-1 näher spezifiziert werden. Abbildung 1-1 zeigt den typischen Verlauf für den Entwurf einer klassischen Datenbank^[2]. Nach der Anforderungsanalyse erfolgt unabhängig vom konkret verwendeten Datenmodell die Erstellung des konzeptionellen Schemas.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1-1 Vorgehensweise beim Entwurf von Datenbanken ^[3]

Das logische Schema wird dann aus dem konzeptionellen Schema abgeleitet und beschreibt im Allgemeinen die Daten in einem konkreten Datenmodell. Am Ende dieser Ableitung setzt ein Datenbankentwicklungssystem das logische Schema direkt in das interne Schema eines konkreten Datenbanksystems um^[4].

Zur Darstellung der konzeptionellen Modellierung soll ein Überblick über verschiedene graphische Designnotationen vorgestellt werden, mit den Schwerpunkten das ME/R-Modell, mUML und der objektorientierte multidimensionale Modellrahmen von Totok. Alle drei Ansätze setzen sich mit der Modellierung multidimensionaler Datenmodelle auseinander. Im logischen Datenmodell wird das multidimensionale Modell anhand von Gegenüberstellungen mit dem relationalen Modell formal näher erläutert. Eine weitere Umsetzung des logischen Modells soll nicht Gegenstand dieser Arbeit sein. Abschließend wird der Aspekt von Veränderungen im Rahmen des Data Warehouses näher diskutiert.

2. Einführung in das multidimensionale Datenmodell

Data Warehouse Systeme orientieren sich anhand der Analyse operativer Daten an der Gewinnung entscheidungsunterstützender Informationen. Diese Informationen sind von Natur aus multidimensional^[5]. Eine typische Beispielanfrage an ein analytisches Datenmodell wäre „Wie hoch war der Umsatz des Produktes A in der Region B in der Zeit C“. Abbildung 2-1 veranschaulicht in Form eines Würfels den Umsatz als Kenngröße der betrieblichen Leistung, die sich nach den Dimensionen Zeit, Produkt und Geographie ermitteln lässt. Die Kenngrößen entsprechen den einzelnen Zellen des Würfels und enthalten, sofern vorhanden, diskrete Werte, wie im Beispiel die Umsätze.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1 Multidimensionaler Datenwürfel^[6]

Die Achsen bzw. die Kanten des Würfels repräsentieren die einzelnen Dimensionen. Eine Dimension lässt sich in mehrere Hierarchieebenen aufteilen, wobei eine höhere Hierarchieebene die aggregierten Werte der jeweils niedrigeren Hierarchiestufe enthält. Somit kann jede Dimension mittels einer Baumstruktur visualisiert werden (vgl. Abbildung 2-1). Auf eine formale Beschreibung des Datenmodells soll an dieser Stelle verzichtet werden, da sie Gegenstand von Kapitel 4 ist.

Das Beispiel zeigt, dass eine grundlegende Anforderung an ein betriebliches Informationssystem die Möglichkeit nach multidimensionaler Auswertung ist. Um diesen Anspruch zu erfüllen, ist eine entscheidungsorientierte, multidimensionale Strukturierung der zugrunde liegenden Datenbasis zwingend erforderlich. Dazu wird ein neues Datenmodell, das multidimensionale Datenmodell, eingeführt, welches sich für die Modellierungen von Data Warehouse Systemen als besonders geeignet erwiesen hat. Dabei sollen die Daten eines multidimensionalen Datenmodells möglichst so abgebildet werden, wie sie auch von den Anwendern in der Realität gesehen werden. Der Zugriff auf Daten erfolgt dabei in einer intuitiven Form, die keine Formulierung von komplexen Abfragen mit speziellen Fragen mehr erforderlich macht^[7].

3. Konzeptuelle Modellierung

Für den Entwurf eines Data Warehouse Systems hat sich wie auch schon bei konventionellen Datenbanksystemen das konzeptuelle Datenmodell erwiesen. Mit Hilfe von speziellen Designnotationen ermöglicht die konzeptionelle Modellierung eine einfache Darstellung der konkreten Anwendungsproblematik. Im Vordergrund steht die Abbildung der betrieblichen Situation in Form von Beziehungen und Daten möglichst ohne Informationsverlust^[8]. Hierbei dürfen allerdings nur die relevanten Aspekte berücksichtigt werden, da die Abbildung sonst zu komplex werden würde. Darauf aufbauend hat sich bei dem Entwurf von konventionellen Datenbanksystemen das Entity Relationship Diagramm und die UML durchgesetzt. Diese Entwurfstechniken sind jedoch für den Aufbau eines Data Warehouse insofern inadäquat, da sie keine für das multidimensionale Datenmodell ausdrucksfähige Semantik besitzen^[9].

Abbildung in dieser Leseprobe nicht enthaltenAbb. 3-1 Auszug eines E/R Modells ^[10]

Das Entity Relationship Modell sowie die UML wurden für die Entwicklung von verschiedenartigen Systemen entworfen, jedoch nicht speziell für den Entwurf eines Softwaresystems. Diese Problematik soll anhand eines Beispielentwurfs mittels des Entity Relationship Modells näher erläutert werden. Abbildung 3-1 zeigt einen Ausschnitt aus einem möglichen E/R Modell für ein Einkaufszentrum^[11]. Das Beispiel zeigt, dass die im Data Warehouse eingeführten Klassifikationshierarchien nicht sinngemäß modelliert werden können; eine Klassifikationshierarchie ist für den Anwender nicht nachvollziehbar. Auch eine Unterscheidung zwischen den signifikanten Merkmalen des multidimensionalen Modells, nämlich den Klassifikationsstufen, den beschreibenden Attributen sowie den Kenngrößen ist nicht ersichtlich. So wurden in diesem Beispiel Klassifikationsstufen als Attribute oder Entitäten modelliert, die aber aufgrund von Analysezwecken im Modell des Data Warehouse System eindeutig als Klassifikationsstufen repräsentiert werden müssten.

Da vorhandene konventionelle Modellierungsformen die Paradigmen des multidimensionalen Modells nicht erfüllen, ist es notwendig, eine spezielle Designnotation für das multidimensionale Datenmodell einzuführen. Dabei wird zwischen evolutionären und revolutionären Ansätzen unterschieden. Während evolutionäre Ansätze sich auf bereits vorhandene Modelle stützen und erweitern bzw. das bestehende Konzept anpassen, bauen revolutionäre Ansätze auf einer komplett neuen Methodik auf.

Im Folgenden werden das ME/R-Modell, die mUML und der objektorientierter multidimensionale Modellrahmen von Totok diskutiert.

3.1. ME/R Modell

Die Technik des multidimensionalen Entity Relationship Modells (ME/R Modell) basiert im Wesentlichen auf den Ideen des im Jahre 1976 von Peter Chen^[12] eingeführten Entity Relationship Modells für relationale Schemata.

Um die Paradigmen des multidimensionalen Schemas zu erfüllen wurde die vorhandene Notation um eine spezielle erweitert und spezialisiert (evolutionärer Ansatz). Dabei geht das ME/R Modell von folgenden Grundgedanken aus^[13]:

- Spezialisierung des E/R Modells: Die Semantik des vorhandenen E/R Modells sollte nicht verletzt werden. Die neuen Konstrukte sollen Spezialfälle des ursprünglichen E/R Modells mit einer neuen Notation sein, damit die Flexibilität und Ausdrucksstärke gewahrt werden kann.
- Minimale Erweiterung des E/R Modells: Durch die notwendige Erweiterung des E/R Modells sollte trotzdem gewährleistet sein, dass erfahrene E/R - Modellierer keine Anpassungsschwierigkeiten an die neuen Elemente haben. Daraus resultiert, dass das konventionelle E/R Modell um nur sowenig neue Notationselemente wie nötig erweitert werden soll^[14]. Daher gibt es auch keine Elemente für bestimmte Dimensionstypen oder -elemente^[15].
- Darstellung der multidimensionalen Semantik: Obwohl das E/R Modell nur minimal erweitert werden soll, muss die Semantik des ME/R Modells ausdrucksstark genug sein um die neuen Eigenschaften des multidimensionalen Schemas sinngemäß wiederzugeben. Dies bezieht sich im Wesentlichen auf die Unterscheidung der qualifizierenden und quantifizierenden Daten sowie der Klassifikationshierarchie.
Basierend auf diesen Grundgedanken wird das E/R Modell um folgende spezialisierte Konstrukte erweitert (Abb.3-2):
- eine spezielle Entitätenmenge „Klassifikationsstufe“; keine explizite Modellierung von Dimensionen
- eine spezielle Entität Fakt für die Kennzahlen
- eine spezielle binäre Klassifikationsbeziehungsmenge zur Verbindung von verschiedenen Klassifikationsstufen
- eine spezielle n-äre Faktbeziehungsmenge, um Fakten und Klassifikationsstufen zu verbinden

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3-2 Die graphische Notation der ME/R – Elemente^[16]

Die binäre Klassifikationsbeziehung verbindet jeweils eine Klassifikationsstufe (Dimensionsstufe) mit einer weiteren Klassifikationsstufe, die eine höherwertigere Abstraktionsebene darstellt. Dabei können auch alternative Pfade, Mehrfachhierarchien oder die gemeinsame Nutzung derselben Dimensionsebenen modelliert werden. Bedingt aus der speziellen Semantik der Klassifikationsbeziehungen ist jedoch zu beachten, dass der Graph einer Klassifikationsbeziehung immer ein gerichteter, zyklenfreier Graph ist.

Die Faktbeziehungsmenge verbindet n verschiedene Entitäten von Klassifikationsstufen; sie stellt einen Fakt der Dimensionalität n dar. Durch Verknüpfungen mit verschiedenen Dimensionen wird ein multidimensionaler Zusammenhang hergestellt und die Struktur des Würfels gebildet. Hierbei ist zu beachten, dass auch Beziehungen zwischen Fakten modelliert werden können. Die unmittelbar mit dem Fakt verbundenen Klassifikationsstufen werden atomare Klassifikationsstufen genannt. Die Attribute der Faktbeziehungsmenge modellieren die Kenngrößen der Fakten (quantifizierende Daten), wohingegen die Klassifikationsstufen die qualifizierenden Daten darstellen^[17].

Anhand eines Beispiels sollen die spezialisierten Elemente des ME/R Modells näher erläutert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3-3 Beispielszenario in ME/R-Notation ^[18]

Abbildung 3-3 zeigt eine Faktbeziehung für die Analyse des Verkaufs eines Kaufhauses. Die Kenngrößen in diesem Beispiel sind die Verkäufe und die Umsätze. Alternativ kann die Notation für die Kenngrößen auch insofern abweichen, dass die Kenngrößen als externe Attribute des Fakts dargestellt werden. Diese Notation würde das Prinzip der Minimalität weiter stützen, hätte aber den Nachteil, dass die Semantik nicht immer eindeutig wäre. So würde zwischen den Attributen des Faktes und den Attributen von Dimensionselementen nicht genau unterschieden werden können.

Die Struktur des Würfels wird durch die Dimensionen Produkte, Geographie und Zeit gebildet, die durch die einzelnen Klassifikationspfade dargestellt werden. Die Klassifikationen werden bottom-up verknüpft, was bedeutet, dass die unterste Hierarchieebene mit dem Fakt bzw. der Fakttabelle verbunden ist. Das Beispiel zeigt, dass innerhalb einer Domäne auch alternative Pfade möglich sind. So sind in der Dimension Zeit Klassifikationen von Tage zu Monaten sowie von Tage zu Wochen modellierbar. Eine Klassifikationsbeziehung von Wochen zu Quartalen bzw. zu Jahren wäre aber aufgrund der Uneindeutigkeit nicht möglich.

Die Pfeile bzw. die Klassifikationsbeziehungen verbinden die Hierarchieebenen in ihrer Verdichtungsfolge.

3.2. Multidimensional UML (mUML)

Der objektorientierte Ansatz der mUML ermöglicht die Erstellung konzeptueller, multidimensionaler Schemata unter Verwendung einer Erweiterung der United Modeling Language (UML) und der Multidimensional Modeling Language (MML). Für das Verständnis der Spezifikation der mUML soll im Folgenden die MML genauer thematisiert werden.

Die MML bildet als Kern der konzeptionellen Entwurfsebene eine einheitliche Grundlage für graphische, konzeptionelle Modellierungsnotationen. Als objektorientierte Sprache besitzt die MML neben den multidimensionalen auch objektorientierte Sprachelemente wie Klassen, Vererbung, Komposition etc. Ihre Eigenschaften werden durch 24 Metaklassen in einem Metamodell beschrieben^[19].

Anhand der Abbildung 3-4, die einen Ausschnitt des MML – Metamodells repräsentiert, sollen die wichtigsten Konstrukte detaillierter dargestellt werden.

Das Metamodell lässt sich grob in fünf Bereiche gliedern: die allgemeinen Verbindungen, der multidimensionale Kontext, die Datenmodelle, die Hilfsmetaklassen und die Properties.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3-4 Ausschnitt des MML-Metamodells

Der Bereich der Datenelemente stellt ein Kernelement der MML dar und repräsentiert die allgemeinen datenaufnehmenden Komponenten eines MML-Schemas und entspricht im Wesentlichen einem Datentyp, wobei es sich um einfache (Metaklasse Data-Type) oder strukturierte (Metaklasse Data-Class) Datentypen handeln kann. Die Zuordnung der Datentypen zu dem existierenden System erfolgt aufgrund, dass es sich um konzeptionelle Datentypen handelt, erst in den folgenden Entwurfsschritten. So ist es zum Zeitpunkt der konzeptionellen Modellierung nicht notwendig, das zu implementierende System zu kennen.

Mit Hilfe der Fact–Class und der Dimensional–Class des multidimensionalen Kontexts wird eine Differenzierung zwischen qualifizierender (Dimensionen) und quantifizierender (Kennzahlen) Daten vorgenommen. Die Dimensional–Class beschreibt Klassen, die innerhalb einer Dimension angeordnet sind, und nimmt die Funktion der Hierarchieebene im multidimensionalen Datenmodell ein. Die Metaklasse Fact–Class ermöglicht die Darstellung der Fakten.

Die einzelnen Verknüpfungen der verschiedenen Schemaelemente lassen sich durch die Metaklasse Connection–Element realisieren. Die Unterklassen dieser Metaklasse sind in die Bereiche der allgemeinen Verbindungen und den Properties aufgeteilt. Die allgemeinen Verbindungen stellen objektorientierte Konstrukte wie Assoziationen, Generalisierungen und Kompositionen zur Verfügung, während die Properties der Darstellung multidimensionaler Kontexte dienen, wie z. B. dem Aufbau einer hierarchischen Struktur.

Das Konzept der MML ermöglicht bereits etablierte Designnotationen weiter zu verwenden bzw. adäquat zu erweitern. Für die Spezifikation der mUML wurden die Erweiterungsmechanismen, die Constraints, die Tagged Values und die Stereotypen der UML genutzt um die multidimensionalen Eigenschaften darzustellen ohne dessen Metamodell direkt verändern zu müssen^[20].

Constraints (Zusicherungen) schränken die möglichen Inhalte, Zustände oder die Semantik eines Modellelements als Ausdrücke ein. Bei dem Ausdruck kann es sich um ein Stereotyp oder Tagged Value handeln.

Ein Tagged Value ermöglicht durch die nähere Spezifikation von Modellelementen mit Hilfe von Charakteristika die Beschreibung von Eigenschaften von MML–Objekten in der mUML. Der so genannte Eigenschaftswert besteht aus einem bezeichnenden Schlüsselwort, dem Tag, und einem dem Tag zugeordneten Datenwert, dem Value.

Im Unterschied zu den Eigenschaftswerten kann durch einen Stereotyp das Metamodell um ein neues Element erweitert werden. Entsprechend der mit der Erweiterung definierten Semantik wird das Modellierungselement, auf das es angewendet wird, direkt semantisch beeinflusst, jedoch darf dessen Struktur nicht verändert werden^[21].

Mittels der Erweiterungsmechanismen können durch die Definition entsprechender Stereotypen die unterschiedlichen MML-Klassentypen für die Kennzeichnung von dimensionalen Klassen sowie Fakt- und Datenklassen in UML - Notation modelliert werden. Zusätzliche Eigenschaften von MML-Modellierungskonstrukten, wie abgeleitete Attribute, werden durch Elementeigenschaften dargestellt.

Ein mUML - Diagramm wird mittels des Klassendiagramms (Static-Structure–Diagramm) dargestellt und beinhaltet deshalb statische Eigenschaften von Klassen und Objekten wie beispielsweise Attribut- und Methodenangaben oder Beziehungen.

Anhand eines Beispiels soll im Folgenden die mUML–Notation näher betrachtet werden^[22]. Abbildung 3-5 zeigt ein vereinfachtes mUML – Schema für den Produktverkauf mit den Klassifikationsschemata der Zeit-, Produkt- und Geografiedimension.

Die verschiedenen Klassifikationsstufen der jeweiligen Dimensionen lassen sich als Klassen des Typs Dimensional Class modellieren. Die Hierarchien der Dimensionen werden durch so genannte Roll-up^[23] Verbindungen dargestellt. Eine gesonderte Rolle nimmt in diesem Beispiel die Zeitdimension ein.

[...]

---

^[1] Totok, Andreas,2000: Modelierung von OLAP- und Data-Warehouse-Systemen, S.14f.

^[2] Vgl. Lehner, Wolfgang, 2003: Datenbanktechnologie für Data Warehouse Systeme – Konzepte und Methoden, S.53f.

^[3] Quelle: Lehner, Wolfgang, 2003: (FN2), S.54

^[4] Vgl. o.V., Datenbanksysteme: Konzepte und Architekturen: Internet http://cheese.geo.unizh.ch:9000/student/all/de/basic/DBSysConcept/view-pdf

^[5] Vgl. Totok, Andreas, 2000: (FN1), S.75

^[6] Vgl. Bauer, Andreas, 2004: Data Warehouse Systeme – Architektur, Entwicklung, Anwendung S. 103

^[7] Vgl. Hoffman/Kusterer: Handelscontrolling auf Basis eines Data Warehouse und OLAP , in Controlling 1/97 S.57

^[8] Vgl. Gerhardt, Hans-Detlef, 2003:Einführung in die Datenbanktechnologie, Folie 5-3

^[9] Vgl. Bauer, Andreas,2004: (FN6), S.162f.

^[10] Quelle Bauer, Andreas, 2004: (FN6), S.163

^[11] Vgl. Bauer, Andreas, 2004: (FN6), S. 162

^[12] Vgl. Chen, Peter , 1976 : The Entity-Relationship Model

^[13] Vgl. Bauer, Andreas, 2004: (FN6), S.166

^[14] Vgl. Sapia, Carsten, 1998: Extending the E/R Model for the multidimensional Paradigm, S.52

^[15] Vgl. Totok, Andreas, 2000: (FN1), S.126

^[16] Vgl. Quelle Bauer, Andreas, 2004: (FN6), S.167

^[17] Vgl. Bauer, Andreas, 2004: (FN6) S.167

^[18] Quelle Bauer, Andreas, 2004: (FN6), S.167

^[19] Vgl. Bauer, Andreas, 2004: (FN4), S. 172

^[20] Vgl. Bauer, Andreas, 2004: (FN6), S.168

^[21] Vgl. Wahl, Günter, 1998: UML kompakt, Internet http://www.sigs-datacom.de/sd/publications/os/1998/02/OBJEKTspektrum_UM_kompakt.htm

^[22] Vgl. Bauer, Andreas, 2004: (FN6), S.169f.

^[23] Roll-up Operationen ermöglichen das Wechseln auf eine gröbere Hierarchieebene (siehe Kapitel 4.2.5.)