Konzeptuelle und logische Modellierung eines Data-Warehouse-Systems

Transkript

1 Seminar Data Warehousing im Verkehrsbereich Sommersemester 2003 Konzeptuelle und logische Modellierung eines Data-Warehouse-Systems Ling Kong

2 Inhaltsverzeichnis 1. Einleitung Multidimensionales Datenmodell Konzeptuelle Modellierung ME/R-Modell MML und muml Ansatz von Totok Logische Modellierung Formale Beschreibung Snowflake Schema Star-Schema Zusammenfassung Literatur i

3 1. Einleitung Data Warehouse Technologien haben aufgrund des enormen Volumens von operativen Daten und dem Echtzeit-Reporting bzw. Auswertung durch OLAP (OnLine Analytical Processing) auf Basis von operativen Daten in betrieblichen Informationssystemen an Bedeutung gewonnen. Data Warehouse Technologien stellen eine Infrastruktur dar, die für Analyse- bzw. Auswertungszwecke von umfangreichen Daten aus betrieblichen Informationssystemen aufgebaut wird. In einem Data-Warehouse-System sollen umfangreiche Datenbestände aus vieler verschiedenen Quellsystemen, die für die Analyse der Anwendung notwendig sind, in geeigneter Form zu Verfügung gestellt werden. Eine der zentralen Themen im Data Warehousing stellt die Modellierung der Datenstrukturen für die Datenhaltung, Datenverwaltung und Datenauswertung mit OLAP in einem Data-Warehouse dar. In dieser Arbeit werden die Grundlagen auf Modellierungsebene für Data-Warehouse-Systeme, insbesondere die konzeptuelle und logische Modellierung, erläutert. Um die Eignung der multidimensionalen Datenmodellierung für Data-Warehouse-Systeme zu zeigen, wird zuerst auf den typischen Entwurfsprozess von Datenbanksystemen eingegangen. Diesen zeigt Abbildung 1.1. Anforderungsanalyse konzeptuelle DB- Modellierung Logische DB- Modellierung Physischer DB- Entwurf Anforderungen an Datenbanksystem Konzeptuelles Schema (unabhängig vom Zieldatenmodell) Logisches Schema (in einem konkreten Datenmodell) Internes Schema (in einem konkreten Datenbanksystem) Abbildung 1.1 Typischer Entwurfsprozess von Datenbanksystemen Im typischen Entwurfsprozess von Datenbanksystemen werden nach der Anforderungsanalyse die konzeptuelle und logische Datenbankmodellierung durchgeführt. Dabei werden die Anforderungen an das Datenbanksystem zuerst im konzeptuellen Schema und dann im logischen Schema abgebildet. Aus Sicht der Datenbanktheorie wird die konzeptuelle Modellierung eher auf einer von Zieldatenmodellen unabhängigen Ebene durchgeführt. Deshalb ist das konzeptuelle Schema unabhängig vom konkret verwendeten Zieldatenmodell. Demgegenüber wird das logische Schema in einem konkreten Datenmodell dargestellt. Nach der Entscheidung für ein konkretes Datenbanksystem wird das interne Schema hergestellt (vgl. [Lehn03]). Im klassischen relationalen Datenbankenentwurf findet für die Erstellung des konzeptionellen Schemas meist eine Variante des Entity/Relationship- Modells (E/R-Modell) Anwendung. Das logische Datenschema wird dann formal im konkreten relationalen Datenmodell spezifiziert. Das relationale Datenmodell stellt dazu lediglich Relationen über Attribute als Ausdrucksmittel bereit. Die Schönheit eines logischen Schemas als Ergebnis des logischen Datenbankenentwurfs wird dabei formal quantifizierbar durch den Grad der vorgenommenen Normalisierung bestimmt. Das interne Schema wird durch die Fähigkeiten des jeweiligen Datenbanksystems bestimmt (vgl. [BaGü01]). 1

4 Der Entwurf von Data-Warehouse-Systemen wird in der Praxis analog wie der vorstehende Entwurfsprozess von klassischen Datenbanksystemen vorgehen. Beim Entwurf von Data- Warehouse-Systemen wird ebenso zuerst ein quellsystemunabhängiges konzeptuelles Schema erstellt und dann in einem geeigneten logischen Schema spezifiziert. Zur Strukturierung der Daten in Data-Warehouse-Systemen werden verlangt, dass das Datenmodell eines Data- Warehouse-Systems sich weniger an den Funktionen betrieblicher Informationssysteme, sondern vielmehr an Analyseanforderungen orientiert. Die Frage hier ist aber, wie das Datenmodell in Data-Warehouse-Systemen aussieht und welche konzeptuelle und logische Modellierungsmethode bzw. -schemata in Data-Warehouse-Systemen eingesetzt werden. Diese Arbeit konzentriert sich auf die Grundlagen der konzeptuellen und logischen Modellierung von Data-Warehouse-Systemen. Demnach lässt sich die Aufgabenstellung dieser Arbeit an den folgenden Fragen verdeutlichen: Welche Datenmodelle liegen einem Data-Warehouse konzeptuell zu Grunde? Welche konzeptuellen Modellierungen von Data-Warehouse-Systemen existieren? Welche logischen Modellierungsschemata finden bei der Modellierung von Data- Warehouse-Systemen Anwendung? Daraus ergibt sich als Zielsetzung dieser Arbeit, einen Überblick über die Grundlagen der konzeptuellen und logischen Modellierung von Data-Warehouse-Systemen zu geben. 2. Multidimensionales Datenmodell Im Vergleich zum Datenmodell für klassische Datenbanksystemen soll das Datenmodell eines Data-Warehouse-Systems sich weniger an den Funktionen operativer Anwendungssystemen, sondern vielmehr an der Analyse operativer Daten orientieren. Außerdem soll ein Datenmodell eines Data-Warehouse-Systems in der Lage sein, unterschiedlichen Sichten auf die Datenobjekte des Modells abzuleiten. Dazu wird ein neues Datenmodell, das mutidimensionale Datenmodell, das sich als besonders zweckmäßig für die Datenmodellierung von Data-Warehouse-Systemen erwiesen hat, eingeführt. Im multidimensionalen Datenmodell unterscheiden sich qualifizierende und quantifizierende Daten. Die quantifizierenden Daten sind die eigentlichen zu analysierenden Daten. Demgegenüber dienen die qualifizierenden Daten hauptsächlich zur Beschreibung der quantifizierenden Daten. Ein multidimensionales Datenmodell besitzt die Struktur, welche aus den folgenden Komponenten besteht (vgl. [BaGü01]): Kenngröße Kenngröße (Bsp. Verkaufsmenge, Umsatz usw.) stellt quantifizierende Daten dar, die in der Praxis auch als Kennzahlen bezeichnet werden. Kenngrößen sind meist numerische Daten. Dimensionen Eine Dimension ist eine ausgewählte Entität (Bsp. Zeit, Produkt, Ort usw.), welche die beschreibenden Daten für Fakten darstellt. Ein Fakt wie z. B. der Umsatz kann z. B. nach Produkt oder Produktgruppen, nach Städten oder Regionen oder über die Zeitachse gruppiert werden. 2

5 Eine Dimension stellt innerhalb des multidimensionalen Datenmodells eine ausgewählte Entität, mit der eine Auswertungssicht eines Anwendungsbereichs definiert wird. Das Konzept Dimension dient der eindeutigen, orthogonalen Strukturierung des Datenraums in einem Data-Warehouse-System. Eine Dimension kann auch Attribute haben, die die Eigenschaften einer Dimension genau beschreiben. In der Praxis enthält ein multidimensionales Datenmodell mindestens drei Dimensionen, und zwar Zeit, Ort und eine Dimension der betrieblichen Merkmale wie z. B. Produkt, Kunde usw. Durch die Einführung von mehreren Dimensionen wie z. B. Kunde, Produkt und Zeit können dann die Daten für unterschiedliche Kombinationen aus diesen Dimensionen gespeichert, analysiert und ausgewertet werden. Klassifikationshierarchie Eine wichtige Aufgabe eines Data-Warehouse-Systems ist die Speicherung, Analyse und Auswertung aggregierter Daten, z. B. die Verkaufsdaten bestimmter Produktgruppen und innerhalb bestimmter Zeitperioden. Deshalb kann eine Dimension hierarchisch zusammenhängende Merkmale enthalten. Im Fall einer Produkt-Dimension kann z. B. auf die unterste Ebene das Produkt sein, darüber die Produktgruppe liegen, nach den können dann oben noch Produktfamilie, Produktkategorie usw. hinzukommen. Meist ist die höchste Stufe innerhalb einer Dimension die totale Aggregation. Deshalb kann eine Dimension hierarchisch zusammenhängende Merkmale enthalten, d.h. damit die Analyse bzw. Auswertung von Faktdaten auf verschiedenen Granularitäten durchgeführt werden kann, werden Dimensionen hierarchisch organisiert. Die Daten auf der niedrigsten Stufe bestimmen die Datengranularität eines multidimensionalen Datenmodells und daher die zu speichernde Datenmenge. Die Hierarchie einer Dimension bildet mittels einer Baumstruktur eine Abstraktionshierarchie über die Elemente einer Dimension. Die Elemente einer Dimension bilden die Blätter eines Baums, die auch als basisgranulare Klassifikationsknoten bezeichnet werden. Die mittels einer Baumstruktur dargestellte Hierarchie wird wiederum als Klassifikationshierarchie bezeichnet. Sie beschreibt damit die verschiedenen Verdichtungsstufen einer Dimension. P r o d u k t - D i m e n s i o n T O P Z e i t - D i m e n s i o n T o p Produktkategorie Jahr P ro d u k tfa m ilie Q u a r t a l W o c h e Produktgruppe M o n a t P r o d u k t einfache H ierarchie T a g parallele H ierarchie Abbildung 2.1 Einfache und parallele Hierarchie In einem managementunterstützenden System, ist es notwendig, das Zustandekommen von hochverdichteten Zahlen nachvollziehen zu können. Will ein Enterscheidungsträger das Zustandkommen einer Jahresumsatzzahl näher analysieren, so wird er möglicherweise die Zahlen für den einzelnen Monat anfordern und eventuell noch eine weitere darunter liegende Verdichtungsebene sehen wollen. Das Herunterbewegen in einer Dimensionshierarchie zu Elementen mit niedrigerem Verdichtungsniveau nennt man Drill Down, die umgekehrte Richtung wird Roll Up genannt. 3

6 Dimensionen können einfache oder parallele Klassifikationshierarchien beinhalten (siehe Abb.2-1). Die Dimensionen Produkt und Ort enthalten z. B. jeweils eine einfache Hierarchie. Die einzelnen Produkte werden zu Produktgruppen zusammengefasst, diese bilden Produktfamilien, die dann zu Produktkategorien aggregiert werden und die Dimension Produkt bilden. Multiple Hierarchien entstehen, wenn innerhalb einer Dimension zwei verschiedene Arten der Gruppierung möglich sind, die in den parallelen Ästen in keiner hierarchischen Beziehung zueinander stehen ([Sche98]). Diese verschiedenen parallelen Hierarchien im Klassifikationsschema berücksichtigen jeweils einen Aspekt und ignorieren dafür andere. In der Zeit Dimension gibt es die Möglichkeit, von Tag über Monat und Quartal zum Jahr oder von Tag zur Woche zu gelangen. Eine Woche kann in zwei Monaten enthalten sein und auch einen Jahreswechsel umfassen. Parallele Hierarchien erhöhen die Flexibilität der Analysen, indem sie ermöglichen, auf verschiedenen Pfaden durch eine Dimension zu navigieren und damit die Daten unter verschiedenen Aspekten zu betrachten. Klassifikationsschema Klassifikationshierarchien können durch eine große Zahl von Knoten und Verknüpfungen umfangreich werden. Deshalb werden Dimensionen über das Schema ihrer Klassifikationshierarchie, das so genannte Klassifikationsschema, dargestellt und die Klassifikationsknoten durch ihre Klassifikationsstufen repräsentiert. Das Klassifikationsschema einer Dimension ist eine halbgeordnete Menge von Klassifikationsstufen mit einem kleinsten Element. Es ist also das Schema zur Abstraktion von einer oder mehreren Klassifikationshierarchien, die einer Dimension zugeordnet wird. Datenwürfel Das multidimensionale Datenmodell lässt sich am besten mit der Würfel-Metapher beschreiben. Die Kanten eines Datenwürfels werden also von den Dimensionen aufgespannt. Die jeweilige Kantenlänge ergibt sich aus der Anzahl der Elemente einer Dimension. In den Würfelzellen werden eine oder mehrere Kenngrößen bzw. Kennzahl abgelegt. Damit wird jede Kenngröße durch eine bestimmte Anzahl von Dimensionen charakterisiert. Die Anzahl der Dimensionen, die einen Würfel aufspannen, wird als Dimensionalität des Würfels bezeichnet. Die Kombination zweier Dimensionen liefert ein Rechteck, das als Tabelle dargestellt werden kann. Wenn drei Dimensionen kombiniert werden, erhält man einen Würfel als einfaches dreidimensionales Modell. Es ist zu beachten, dass die Würfel-Metapher eigentlich nur für dreidimensionale Modelle gültig ist. Der Begriff Datenwürfel wird aber auch für n-dimensionale Strukturen verwendet. Auch bei höheren Dimensionen spricht es von Würfeln, man nennt sie dann Hyper-Würfel. Als ein Beispiel stellt Abbildung 2.2 einen multidimensionalen Datenwürfel dar. Alle Dimensionen spannen einen Raum auf, der als Datenwürfel bezeichnet wird. Die Kanten/Achsen der Würfel stellen die Dimensionen (hier: Ort, Produkt, Zeit) dar. Jede Kantenlänge ist Anzahl der Blätter von niedrigsten Klassifikationsstufen einer Dimension. In den Datenzellen sind Kenngrößen abgelegt (hier: Umsatz). Die Ortsdimension ist hier durch eine Klassifikationshierarchie verdeutlicht. 4

7 Ort Dimensionen Kenngröße / Kennzahl Datenwürfel Ort Land Region Bezirk Stadt Filiale Zeit Hierarchie Produkt Abbildung 2.2 Ein multidimensionaler Datenwürfel 3. Konzeptuelle Modellierung Die konzeptuelle Modellierung von Data-Warehouse-Systemen soll die neueste Entwicklung im Bereich der Integrationsstrategien für Managementinformation darstellen, die Qualität, die Integrität und die Konsistenz des zugrundeliegenden Datenmaterials sicherstellen. Die konventionellen Entwurfsmethoden wie das Entity-Relation-Diagram oder UML, reichen für diesen Zweck nicht mehr aus. Das E/R-Modell unterstützt keine semantische Unterscheidung zwischen qualifizierenden und quantifizierenden Entities. Schwierigkeiten gibt es z. B. bei der Abbildung von Dimensionshierarchien. Inzwischen mehren sich daher die Stimmen, welche die Notwendigkeit einer speziellen multidimensionalen Notation zur Darstellung von OLAP- Systemen sehen. Ein konzeptuelles Modell soll über folgende Eigenschaften verfügen: Ausdrucksstärke: Das Datenmodell muss mächtig genug sein, um die Unterschiede zwischen Daten- und Abhängigkeitstypen aufzuzeigen. Außerdem sollte es möglich sein, Anwendungssemantik und -constraints zu beschreiben. Einfachheit: Das Modell sollte einfach genug sein, um von einem typischen (End-) Benutzer verwendet und verstanden zu werden. Eine grafische Repräsentation ist wünschenswert. Minimalität: Das Modell sollte nur eine kleine Anzahl an Basiskonzepten beinhalten. Die Konzepte sollten eindeutig sein, sich in Ihrer Bedeutung also nicht überschneiden. Die Anzahl der verfügbaren Symbole sollte möglichst gering gehalten werden, anstatt zu versuchen alle Sonderfälle abzudecken Formalität: Die Konzepte des Modells sollten formal definiert und korrekt sein. Daher kann ein konzeptuelles Schema als formale eindeutige Abstraktion der Realität gesehen werden. 5

8 3.1 ME/R-Modell Die ME/R-Notation (Multidimensional Entity/Relationship, [SBHD99]) wurde als spezielle Modellierungstechnik für multidimensionale Schemata entwickelt. Sie stellt eine Erweiterung des bekannten E/R-Ansatzes (Entity/Relationship, [Chen76]) für relationale Schemata dar. Die Grundidee des ME/R-Ansatzes ist wie folgt: Um eine naturgemäße Darstellung der multidimensionalen Semantik zu erlauben, wird das E/R-Modell entsprechend spezialisiert und geringfügig erweitert. Zuerst sollen alle eingeführten Elemente der ME/R Notation Spezialfälle der ursprünglichen ER/-Konstrukte sein, damit für Leute, die mit dem E/R Modell schon erfahren sind, auch das ME/R-Modell verstehen und benutzen können. Ihre Semantik muss die Unterscheidung zwischen Klassifikationsschema, Würfelstruktur und die hierarchische Struktur der Klassifikationen darstellen. Aus dieser Überlegung führt die ME/R-Notation folgende spezialisierte Konstrukte der ursprünglichen E/R-Notation ein (siehe Abbildung 3.1): o Eine spezielle Entitätenmenge Klassifikationsstufe o Eine spezielle Entität Fakt o Eine spezielle binäre Klassifikationbeziehungsmenge zur Verbindung von Klassifikationsstufen. o Eine spezielle Faktbeziehungsmenge, um Fakte und Dimensionen zu verbinden. Die Klassifikationsbeziehung verbindet eine Dimensionsstufe A mit einer Dimensionsstufe B, welche eine höherwertige Abstraktionsebene darstellt. Beispielsweise werden Städte nach Ländern klassifiziert. Aufgrund der speziellen Semantik der Klassifikationsbeziehung dürfen keine Zyklen im so genannten Klassifikationsgraphen existieren (vgl. [BaGü01]). Fakt Faktbeziehung K enngröße K lassifikationsbeziehung K lassifikationsstufe Abbildung 3.1 Grafische Notation der ME/R-Elemente Die Faktbeziehungsmenge ist eine Spezialisierung einer allgemeinen n-ären Beziehungsmenge. Sie verbindet n verschiedene Entitäten von Klassifikationsstufen. Solche Beziehungen stellen ein Fakt der Dimensionalität n dar und entsprechen einem Würfel. Eine Beschreibung des Fakts wird als Name der Menge verwendet. Die unmittelbar verbundenen Klassifikationsstufen werden atomare Klassifikationsstufen genannt. Die Faktbeziehungsmenge modelliert die inhärente Trennung zwischen Dimension und Würfelzellen und somit die Struktur des Würfels. Die Attribute der Faktbeziehungsmenge 6

9 modellieren die Kenngrößen der Fakten, wogegen die Klassifikationsstufen die qualifizierenden Daten darstellen (vgl. [BaGü01]). Um die spezialisierten Elemente von den ursprünglichen E/R-Modellierungselementen zu unterscheiden und die Verständlichkeit des graphischen Modells zu verbessern, werden spezielle grafische Symbole für Fakt, Klassifikationsstufen, Faktbeziehungen und Klassifikationsbeziehung verwendet. Als Beispiel nehmen wir eine Verkaufsanalyse. Kenngrößen können z. B. Verkaufszahlen oder der Umsatz sein. Als Dimension dienen Produkt, Geographie und Zeit. Innerhalb einer Dimension sind auch Alternativpfade der Klassifikationsbeziehungen möglich. Abbildung 3.2 zeigt solche Alternativpfade bei der Zeitdimension. Wochen sind somit nicht mehr eindeutig zu Quartalen oder Jahren zusammengefasst. P r o d u k t - k a t e g o r i e P r o d u k t - fam ilie P r o d u k t - g r o u p e A rtik e l la n d R e g i o n B e z i r k S t a d t F ilia le V e r k a u f V e rk ä u fe U m s a t z Jah r Q u a r t a l M o n a t T a g W o c h e Abbildung 3.2 Kaufhaus-Szenario in ME/R-Notation 3.2 MML und muml Die muml (Multidimensional UML) ist eine in [HeHa99] vorgestellte multidimensionale Erweiterung der Unified Modeling Language, welche die Erstellung konzeptueller multidimensionaler Schemata unter Verwendung der UML-Notation ermöglicht. Um die Spezifikation von muml zu verstehen, geben wir zuerst eine Überblick über MML (Multidimensional Modeling Language) ([HeHa99]). Als rein konzeptuelle Modellierungssprache abstrahiert die MML dabei von jeglichen Implementierungsdetails, so dass sie sich nur auf die Spezifikation der zur Verfügung stehenden multidimensionalen Konstrukte, deren Beziehungen und Abhängigkeit untereinander und Semantik multidimensionaler Schemata beschränkt. Die MML berücksichtigt dabei die strikte Trennung zwischen Metamodell, Schema und Ausprägung. Eigenschaften des Schemas lassen sich daher nicht in Abhängigkeit der Ausprägung spezifizieren. Ein zentraler Aspekt der MML ist die Unterscheidung zwischen Datenobjekten, deren multidimensionalem Zusammenhang und den Elementen zur Beschreibung nichtdimensionaler, struktureller Eigenschaften. Für die weitere konzeptuelle Modellierungsphase liefert die MML ein objektorientiertes Metamodell. Ausgangspunkt für die Spezifikation der muml bilden die UML-eigenen Erweiterungsmechanismen, durch die eine Anpassung für spezielle Einsatzgebiete erfolgen kann. Beispielsweise wurden MML-Metamodelle verwendet. 7

10 In Ergänzung der durch das UML-Metamodell definierten Eigenschaften von Modellelementen können unter Verwendung des so genannten Tagged-Value-Mechanismus neue Elementeigenschaften definiert werden. Ein Tagged Value entspricht dabei einem Zweitupel, bestehend aus einen Schlüsselwort, dem Tag, das die Elementeigenschaft benennt, und einem zugehörigen Datenwert. Mittels des Tagged-Value-Mechanismus werden in der muml Eigenschaften von MML-Objekten beschrieben, für die in der UML kein äquivalentes Modellierungskonstrukt existiert. Das zweite Erweiterungskonstrukt, der Stereotyp, führt ein neues Modellierungskonstrukt ein, das auf einer existierten Klasse bzw. einem existierten Typ des UML-Metamodells basiert und damit eine neue Untermetaklasse bzw. einen neuen Untermetatyp beschreibt. Unter Verwendung dieser Erweiterungsmechanismen spiegeln sich beispielsweise unterschiedliche MML-Klassentypen für die Kennzeichnung von dimensionalen Klassen sowie Fakt- und Datenklassen in entersprechenden Stereotypen für das UML-Klassenkonstrukt wider. Zusätzliche Eigenschaften bestimmter MML-Modellierungskonstrukte, wie z. B. Berechnungsformeln abgeleiteter Attribute, werden durch Elementeigenschaften repräsentiert. Abbildung 3.3 zeigt eine Fakt-Klasse, welche die drei Kenngrößen Anzahl, EinzelVK und Umsatz beinhaltet, wobei Umsatz eine abgeleitete Kenngröße ist, die sich aus den Werten der beiden anderen berechnet. <<Fact-Class>> V e r k a u f A nzahl: V erkauf EinzelV K : Preis U m sa tz : P re is{ fo rm u la = A n z a h l EinzelVK, P a ra m e te r = A n z a h l, E in z e lv K } Abbildung 3.3 muml: Fakt-Class-Klasse Jahr Land Region <<Shared-Roll-up>> Woche Quartal Monat Bezirk Artikel Tag Stadt Produktgruppe <<Dimension>> Zeit <<Fakt-Class>> Verkauf 1..* <<Fakt-Class>> Verkauft Artikel Filiale <<Dimension>> Geographie <<Dimension>> Produkt Produktfamilie Produktkategorie Abbildung 3.4 muml-schema Produktverkauf 8

11 Anhand des durchgängigen Szenarios wird im Folgenden die muml-notation näher betrachtet. In Abbildung 3.4 sind die Klassifikationsschemata der Zeit-, Produkt und Geographiedimension dargestellt 3.3 Ansatz von Totok Der objektorientierte Ansatz hat in diesem Jahrzehnt breiten Einzug in die Systemanalyse, -gestaltung und -implementierung gefunden. Die grundlegende Idee des Ansatzes besteht in der wirklichkeitsnahen Abbildung von realen Gegenständen oder Sachverhalten in Objekte der Systemwelt. Objektorientierte Modellierung betracht nicht nur Daten, sondern zusätzlich auch die Methoden, mit denen auf die Daten zugriffen wird. Der große Vorteil ist die Wiederverwendbarkeit von Bausteinen für alle Phasen der Systementwicklung. Ein objektorientierter Modellierungsrahmen wurde erstmalig von Totok in seinem Buch Modellierung von OLAP- und Data-Warehouse-System präsentiert ([Toto00]). Als Notation wird UML benutzt. Eine Besonderheit dieses Ansatzes liegt daran, dass er die Verbindung von Kennzahlen und Dimensionselementen mit den entsprechenden Methoden realisiert. Dabei besteht die Möglichkeit, dynamische Aspekte zu berücksichtigen und Flexibilität für Spezialfälle zu bewahren. Darüber hinaus sind die Ableitungsdetails im Klassenmodell sichtbar gemacht. <<Dimension>> Artikel <<Dimension>> Zeit << originäres Dimensionalselement >> Einzelartikel <<Dimension>> Vertribsweg << originäres Dimensionalselement >> Filiale <<originäre Kenngrösse>> Artikel berechne JahrsStandardpreiseElement:list(Quartal),Preis) Element:list(monat) <<geordnete Hierachieebene>> Jahr Element:list(Quartal) <<geordnete Hierachieebene>> Quartal berechne Quartals-StandardpreiseElement:list(Quartal),Preis) <<Dimension>> Szenario <<geordnete Hierachieebene>> Monat berechne Abweichung(Ausprägung1,Ausprägung2) Element:list(Tag) berechnen Monat-StandardpreiseElement:list(Quartal),Preis) << originäres Dimensionalselement >> Ausprägung <<originäres Dimensionalselement>> Tag Abbildung 3.5 Gültigkeitszuordnung für eine Kenngröße Abbildung 3.5 zeigt die Gültigkeitszuordnung für eine Kenngröße bei gleichem Beispiel. Die Kenngröße Preis eines Artikels ist nach den Entscheidungsobjekten Zeit, Szenario und Vertriebsweg analysierbar. Und nur für beliebige Kombinationen dieser Verknüpfungen gültig. Einer Aggregation der Preisinformation über die Hierarchieebenen der Entscheidungsobjekte macht allerdings kein Sinn, da die Preisinformation auf Artikel bezogen ist und sich ähnlich wie eine Bestandsgröße verhält. Im Beispiel wird täglich eine aktuelle Preisinformation im System eingestellt. Daher sollte der Monatspreis der 9

12 Standardpreis sein, der sich z. B. durch Durchschnittsbildung ergibt. Diese Berechnung ist im Beispiel als Methode angegeben: berechneter Monatstandardpreis. Für Quartal und Jahr würden die Methoden analog definiert. Ableitungsregeln können sowohl in Kennzahlenobjekten als auch in hierarchischen Dimensionselementen definiert werden. Im Gegensatz zur Zeitdimension macht eine Verdichtung über die Hierarchie der Artikeldimension keinen Sinn. Eine Summierung über Artikelgruppen wird daher nicht benötigt (vgl. [BaGü01]). 4. Logische Modellierung Nach der konzeptuellen Modellierung ist eine formale Beschreibung des multidimensionalen Datenmodells für Data-Warehouse-System dringend nötig. Zunächst müssen die verwendeten Basiskonstrukte und deren Beziehungen formal beschrieben werden. Das Pendant im relationalen Datenmodell ist die formale Definition einer Relation, eines Relationenschemas, einer Domäne etc. Im Falle des multidimensionalen Paradigmas sind die zu formalisierenden Entitäten Datenwürfel, Dimensionen etc. ([BaGü01]). Im Zuge des logischen Designs wird das systemunabhängige konzeptuelle Modell in ein logisches (systemabhängiges) Implementierungsmodell überführt. Einschränkungen und Besonderheiten des eingesetzten Systems werden berücksichtigt. Im relationalen Fall operativer Datenbanken kann man prinzipiell von einem logischen Relationenmodell sprechen. Der logische Entwurf besteht in diesem Fall aus der Transformation von Entities und Beziehungen in die entsprechenden Relationen bzw. Tabellen. Im multidimensionalen Falle ist das etwas anderes. Der Hauptunterschied zwischen dem multidimensionalen und relationale Modell ist die zusätzliche Semantik, durch die die Beziehungen zwischen den Klassifikationsstufen einer Dimension untereinander, zwischen den Würfeln und den Klassifikationsstufen seiner Dimensionen sowie zwischen verschiedenen Würfeln zum Bestandteil des Modells gemacht werden. 4.1 Formale Beschreibung Da Operationen wie z. B. Aggregation oder Ranking-Abfragen innerhalb des multidimensionalen Datenmodells sehr kompliziert und aufwändig sein können, gibt es deshalb bis jetzt noch keine standardisierte Formalisierung für multidimensionales Datenmodell, aber einige wissenschaftliche Versuche sind ausgeführt. Im Folgenden wird der Ansatz aus [Lehn03] vorgestellt. Schema einer Dimension Das Schema einer Dimension D besteht aus einer partiell geordneten Menge von Kategorienattributen {D 1,...D n, Top D } wobei die folgenden Voraussetzungen gelten: D 1,, D n sind funktional abhängig, 10

13 Fakt Top D stellt ein generisches maximales Element in Bezug auf (D 1...D n ) dar, so dass Top D von allen Attributen funktional bestimmet wird, d.h. i(1 i n): D i Top D. Des Weiteren existiert genau ein D i, welches alle anderen Kategorienattribute bestimmt und somit die feinste Granularität einer Dimension vorgibt, d.h. i(1 i n j(1 j n, i j) : D i D ). ) j Ein Fakt F eines multidimensionalen Schemas besteht aus einer Granularität G und einem Summationstyp SumTyp: F=(G, SumTyp) Die Granularität G={G 1...,Gn} ist dabei eine Teilmenge aller im multidimensionalen Schema existierenden Dimensionen mit Dimensionsschemata DS 1...DS n, so dass gilt: (1) i( 1 i k) j( i j n) : G i DS j (2) i( 1 i k) j(1 j k) i j : G i G j Die zweite Forderung besagt dabei, dass zwischen den Kategorienattributen innerhalb einer Granularität keine funktionale Abhängigkeit bestehen darf. Kenngröße Eine Kenngröße M ist definiert durch eine Granularität G, durch eine Berechnungsvorschrift f() über eine nichtleere Teilmenge aller im Schema existierenden Fakten und wiederum durch einen Summationstyp. M=(G, f(f 1,..., F k ), SumTyp) Der Summationstyp bestimmt, welche Aggregationsoperationen (Summe, Durchschnitt,...) auf Kenngrößen angewendet werden dürfen. Die Berechnungsvorschrift f() wird dabei durch folgende Funktionen gebildet: (1) Skalafunktionen: Die Menge der Skalafunktionen umfasst zur Kombination mehrerer Fakten zu einer Kenngröße eine Vielzahl von Skalafunktionen wie +, -, *, /, mod etc. (2) Aggregationsfunktionen: Eine Aggregationsfunktion nimmt die Verdichtung des Datenbestands vor, indem aus n Einzelwerten ein durch die Aggregationsfunktion bestimmter Wert ermittelt wird. (3) Ordnungsbasierte Funktionen: Die Ordnungsbasierte Funktion definiert eine Kenngröße basiert auf einer zuvor definierten Ordnung. Datenwürfel(Hypercube) Das Schema eines Datenwürfels C besteht aus der Menge der dimensionalen Schemata DS und der Menge der Kenngrößen M, d.h.: C=(DS, M)=({D 1,..., D n },{M 1,..., M m }), wobei {D 1,..., D n } als Dimensionshierarchien und {M 1,...,M m } als Menge von Kenngrößen bezeichnet werden ([Lehn03]). 11

14 4.2 Snowflake Schema Eine direkte Möglichkeit, Klassifikationen wie sie im ME/R Modell modelliert sind, in einer relationalen Datenbank umzusetzen, besteht darin, eine eigene Tabelle für jede Klassifikationsstufe anzulegen. Diese Tabelle enthält neben der ID für die Klassifikationsknoten dieser Klassifikationsstufe auch die beschreibenden Attribute. Zusätzlich enthalten die Tabellen Fremdschlüssel der direkt benachbarten höheren Klassifikationsstufen. Die Kenngrößen eines Datenwürfels werden innerhalb einer Faktentabelle verwaltet. Diese wird nach obigem Schema konstruiert, d.h., neben einer Spalte für jede Kenngröße enthält sie Fremdschlüsselbeziehungen zu den jeweils niedrigsten Klassifikationsstufen der verschiedenen Dimensionen, gemäß der Granularität des Datenwürfels. Die Fremdschlüssel entsprechen den Zellkoordinaten in der multidimensionalen Datensicht. Sie bilden daher den zusammengesetzten Primärschlüssel für die Faktentabelle. Abbildung 4.1 zeigt eine Umsetzung des Beispielszenarios nach diesem Muster. Die Faktentabelle enthält die Kenngrößen Verkäufe und Umsatz. Außerdem besitz sie Fremdschlüsselbeziehungen zu den Tabellen, welche die jeweils niedrigste Klassifikationsstufe repräsentieren (Tag, Artikel und Filiale). Der Primärschlüssel der Faktentabelle wird durch die Konkatenation aller Fremdschlüssel gebildet (im Beispiel Tag_ID, Artikel_ID und Filiale_ID). Die Namensgeber vergleichen diese Variante mit dem Kristall einer Schneeflocke. Daher kommt der Name "Snowflake" für dieses logische Modell. Jede dieser Tabellen enthält keine Mehrfacheinträge. Der Vorteil besteht in der optimalen Unterstützung von Aggregaten, der besseren Unterstützung von n:m-beziehungen zwischen Hierarchieobjekten und der Redundanzfreiheit. Probleme bestehen durch ein komplexeres Modell, welches für den Benutzer das Verständnis erschwert und bei der Anfrage kompliziert erscheint. Jahr Jahr_ ID Jahr M o n a t M o n a t _ I D B e z e i c h n u n g Jahr_ID W o c h e W o c h e _ I D B e z e i c h n u n g Jahr_ID T a g T a g _ I D B ezeichnung M o n a t - I D W o c h e _ I D V e r k a u f A r t i k e l_ I D T a g _ I D F i li a l e _ I D V e r k ä u f e U m s a t z A r t i k e l A r t i k e l_ I D A rtikelnam en B ezeichnung M a r k e P a c k u n g s t y p ProdG ruppe_id... F i l i a l e F ilia le _ ID B e z e ic h n u n g S t a d t _ I D S t a d t Produktgruppr ProdG ruppe_id B ezeichnung ProdK at_id Produktkategorie Prodkat_ID B ezeichnung S t a d t _ I D B e z e i c h n u n g R e g i o n _ I D R e g i o n R e g i o n _ I D B ezeichnung L a n d _ I D L a n d L a n d _ I D B ezeichnung Abbildung 4.1 Umsetzung des Beispielszenarios in ein Snowflake-Schema 4.3 Star-Schema Wie in Abbildung 4.1 gezeigt, sind bei Snowflake-Schema alle Tabellen in Normalform. Bei einer Anfrage wird JOIN Operation immer ausgeführt, um viele Tabellen miteinander zu verbinden. So wird in dem Beispiel für eine Gruppierung nach Produktkategorie, Land und Jahr ein Verbund mit elf Tabellen benötigt. Weil solche Verbindungen besonders 12

15 zeitaufwändig sind, wird stattdessen in Data-Warehouse-Systemen häufig das Star-Schema benutzt. Im Star-Schema werden alle Dimensionsstufen, die zu einer Dimension gehören zu einer Dimensionstabelle zusammengefügt. Dies führt zur Denormalisierung der Dimensionstabelle. Um eine schnellere Anfragebearbeitung zu erreichen, weicht man also an dieser Stelle bewusst vom Prinzip der Normalisierung ab. Eine Faktentabelle wird mit N Dimensionen assoziiert. Im Modell ergibt sich dann ein Stern: die Faktentabelle bildet den Kern des Sternes, die dazugehörigen Dimensionen stellen die Strahlen des Sternes dar, daher kommt der Name Star-Schema. Innerhalb eines Star-Schemas gibt es für jede Dimension genau eine Dimensionstabelle. Abbildung 4.2 zeigt den prinzipiellen Aufbau eines Star-Schemas, und Abbildung 4.3 repräsentiert das bereits ernannte Beispiel Verkauf im Star-Schema. In Abbildung 4.3 sind die Klassifikationsschemata der Zeit-, Produkt und Geographiedimension dargestellt. Produktgruppe, Produktfamilie und Produktkategorie werden im Star-Schema zu einer einzigen Dimensionstabelle Produkt zusammengefasst. Die Fremdschlüssel der Faktentabelle sind mit der niedrigsten Granularität bezeichnet (z. B. Product_ID) 3.D im ensionstabelle 1.Dimensionstabelle Dim3-Schlüssel Dim3_Attribute 4.D im ensionstabelle Dim4-Schlüssel Dim4_Attribute Faktentabelle Dim1-Schlüssel Dim2_Schlüssel Dim3_Schlüssel Dim4_Schlüssel... Kenngröße1 Kenngröße2 Kenngröße3... Dim1-Schlüssel D im 1_A ttribute 2.Dimensionstabelle Dim2-Schlüssel D im 2_A ttribute Abbildung 4.2 Allgemeines Star-Schema In einem Star-Schema ist die Faktentabelle wie im Snowflake-Schema normalisiert, demgegenüber sind die Dimensionstabellen nicht. Demzufolge gibt es viele Redundanzen innerhalb der Dimensionstabellen. Die funktionalen Abhängigkeiten zwischen den Klassifikationsstufen werden bei dieser Abbildung nicht sichtbar. Zeit Zeit ID Tag W o c h e M o n a t Quartal Jahr Geographie Geo ID F ilia le Stadt Bezirk R egion Land 1 1 n n Verkauf Produkt ID Z e it ID Geo ID V erkäufe Umsatze n 1 Produkt Produkt ID A rtik e l Produktgruppe P ro d u k tfam ilie Produktkategorie Bezeichnung M a rk e Packungstyp... Abbildung 4.3 Das Bespiel für Star-Schema 13

16 Die Argumentation, wann und warum ein Star-Schema trotzdem dem Snowflake-Schema vorzuziehen ist, stützt sich auf folgende Heuristiken über die Charakteristika von Data- Warehouse-Systemen: Schnellere Anfragebeantwortung. Einschränkungen für Anfragen werden typischerweise auf höherer Granularitätsstufe (z. B Produktkategorie) definiert. Die Denormalisierung spart gegenüber dem Snowflake-Schema aufwändige Verbindungsoperationen zwischen verschiedenen Tabellen einer Dimension ein. Erträglicher Speicheraufwand für Dimensionstabellen. Das Datenvolumen der Dimensionstabellen mit den Klassifikationshierarchien ist relativ gering im Vergleich zum gesamten Volumen der Zellinhalte (Größe der Faktentabelle). Daher führt die Denormalisierung insgesamt nicht zu einer dramatischen Erhöhung des Datenvolumens. Wenige Änderungen im Dimensionstabellen. Änderungen von Dimensionstabellen treten weitaus seltener als das Hinzufügen von neuen Faktendaten auf. Zusammenfassend besitzt das Star-Schema also folgende Eigenschaften, die es für Anwendungen geeignet erscheinen lassen: Einfache Struktur: Star-Schema hat eine einfache Struktur. Im Star-Schema werden Anfragen dadurch einfacher und lassen sich leichter formulieren. Einfache und flexible Darstellung von Klassifikationshierarchien: Klassifikationshierarchien werden nicht mehr wie im Snowflake-Schema durch viele zusammenhängende Tabellen dargestellt, sondern einfach innerhalb von Dimensionstabellen als Spalten angegeben. Effiziente Anfrageverarbeitung innerhalb der Dimensionen: Durch die Denormalisierung der Dimensionstabellen sind bei Selektionsprädikaten, die höhere Dimensionsstufen zur Einschränkung verwenden, keine Verbundoperationen zwischen verschiedenen Tabellen nötig, um die Menge von Tupel zu bestimmen, die mit der Faktentabellen verbunden werden müssen. Ob die Vorteile des Snowflake-Schemas wie z. B. geringerer Speicherplatzbedarf und bessere Änderungsfreundlichkeit überwiegend oder das Star-Schema besser geeignet ist, hängt stark von den konkreten Daten- und Anfragecharakteristiken. 5. Zusammenfassung In dieser Arbeit wurden die konzeptuelle und die logische Modellierung von Data- Warehouse-Systemen betrachtet. Zuerst erfolgte ein Rückblick auf den Modellierungsprozess beim Entwurf von relationalen Datenbankensystem. Dann wurden die Grundlagen des multidimensionalen Modells vorgestellt. Dabei wurde auch erklärt, warum und wie das multidimensionale Modell für die Modellierung von Data-Warehouse-Systemen eingesetzt werden soll. Für die konzeptuelle Modellierung von Data-Warehouse-Systemen wurde zuerst das ME/R- Modell, das eine naturgemäße Darstellung der multidimensionalen Semantik illustriert, vorgestellt. Danach wurden die Grundlagen für die muml, die eine multidimensionale 14

17 Erweiterung der Unified Modeling Language darstellt, erklärt. Darüber hinaus wurde ein neuer Ansatz für die Modellierung von Data-Warehouse-Systemen, und zwar der objektorientierte Ansatz von Totok, vorgestellt. Die Formalisierung der konzeptuellen Modellierung für Data-Warehouse-System wurde in Kapitel 4 diskutiert. Dabei wurde insbesondere die formale Darstellung der Elemente, wie z. B. Dimension, Fakt, Kenngröße und Datenwürfel, eingeführt. Danach wurden zwei logische Schemata, das Snowflake-Schema und das Star-Schema, vorgestellt. Dabei wurden die Vor- und Nachteile von Star-Schema und Snowflake-Schema erläutert. Eine wichtige Betrachtung ist, dass das Star-Schema für OLAP-Anwendungen besonders geeignet ist. Am Ende wurde die Modellierung von Data-Warehouse-Systemen schrittweise beschrieben. Literatur [BaGü01] Bauer, A.; Günzel, H.: Data Warehouse Systeme: Architektur, Entwicklung, Anwendung, 1.Auflage 2001 [Chen76] Chen, P.P.-S.: The Entity Relationshop Model-Towards a Unified View of Data. ACM Tods Vol. 1, No.1, 1976 [HeHa99] Herden, O.; Harren, A.: MML und muml-sprache und Werkzeug zur Unterstützung des konzeptuellen Data Warehouse Designs, in proceeding 2 GI- Workshop Data Mining und Data Warehousing als Grundlage moderner Entscheidungsunterstützender Systeme DMDW 99, Magdeburg, Deutschland, 1999 [KRRT98] Kimball, R.; Reeves, L.; Ross, M.; Thornwaite, W.: The Data Warehouse Lifecycle Toolkit. Wiley, 1998 [Lehn03] Wolfgang Lehner: Datenbanktechnologie für Data-Warehouse-Systeme, Konzepte und Methoden, 1.Auflage 2003 [MuBe98] Mucksch, H.; Behme, W.: Das Data Warehouse Konzept: Architektur Datenmodelle Anwendungen mit Erfahrungsberichten, 3.Auflag 1998 [SBHD98] Sapia, C., Blaschka, M., Höfling, G.,Dinter, B.: extending the E/R Model for the Multidimensional Paradigm. In Kambayashi, Y. et. Al.(Hrsg.), Advances in Database Technologies, LNCS Vol. 1552, Springer, [Toto00] Totok,A.: Modellierung von OLAP- und Data-Warehouse-System, Dt.Univ.-verl. (Gabler); Wiesbaden, 2000, zugel.: Diss.; techn. Braun-schweig,1999. [Wede91] Wedekind, H.: Datenbanksysteme, Band 1, eine konstruktive Einführung in die Datenverarbeitung in Wirtschaft und Verwaltung, 3. durchgesehene Auflage. BI Wissenschaftsverlag, Mannheim,