Transkript

1

2

3

4

5

6 Modellgestütztes Management

7 Analysemuster in der dimensionalen Datenmodellierung Stephan Schneider Institut für Wirtschaftsinformatik / Fachbereich Wirtschaft Fachhochschule Kiel Sokratesplatz Kiel stephan.schneider@fh-kiel.de Abstract: Im Entwicklungszyklus von Data Warehouse-Systemen ist die Konstruktion fachlicher dimensionaler Datenmodelle während der Analysephase eine der wichtigsten, richtungsweisenden und herausforderndsten Tätigkeiten zugleich. Fachliche dimensionale Datenmodelle repräsentieren den operativen sowie strategischen Informationsbedarf eines Unternehmens. Sie werden über automatisch realisierbare Transformationsprozesse in logische und anschließend physische Datenmodelle umgewandelt. Physische Datenmodelle werden zur Instanziierung dimensionaler Datenbanken verwendet, die der Generierung von für Entscheidungsprozesse relevanten Informationen dienen. Trotz der unbestritten enormen Bedeutung der Analysephase wird bei der Konstruktion fachlicher dimensionaler Datenmodelle nicht auf bewährte Konstruktionsmuster in Form von Analysemustern, die Lösungsansätze für bekannte und wiederkehrende Probleme in bestimmten Kontexten adressieren, zurückgegriffen. Die Nichtberücksichtigung von bewährten Analysemustern kann in Anbetracht der Informationsbedarfsdiffizilität zu mangelhaften und qualitativ ungesicherten fachlichen dimensionalen Datenmodellen und somit Datenbanken führen, aus denen wiederum qualitativ unzureichend gesicherte Informationen generiert werden. Der Einsatz von Analysemustern in der dimensionalen Datenmodellierung ist bis heute weder in der Literatur noch in der Praxis thematisiert. Diese Arbeit versteht sich als ein erster Schritt, diese Forschungslücke in der dimensionalen Datenmodellierung zu schließen. Daher widmet sich dieser Artikel dem Einsatz von Analysemustern in der dimensionalen Datenmodellierung. 7

8 1 Einführung Die methodische Entwicklung von Informationssystemen ist in die aufeinander folgenden Kernphasen Analyse, Entwurf und Implementierung untergliedert. Diese aus dem Systems Engineering bekannte methodische Vorgehensweise zur Entwicklung von (IT-)Systemen ist nahtlos auf das Data Warehousing zur Entwicklung von Data Warehouse-Systemen übertragbar [BMR07, S. 449 ff.], [Ho01, S. 211 ff.]. Das Ergebnis einer Vorgängerphase (z. B. Analyse) in Form eines Informationsmodells (z. B. konzeptionelles bzw. fachliches Datenmodell) dient als Input für eine nachfolgende Phase (z. B. Entwurf). Die Analysephase ist der erste Schritt im gesamten Systementwicklungszyklus und demzufolge die fundamentale und bedeutsamste Phase überhaupt. Während der Analysephase werden die Systemanforderungen definiert und in konzeptionellen Informationsmodellen dokumentiert. Im weiteren Verlauf dieser Arbeit stehen konzeptionelle Datenmodelle als spezielle Informationsmodelle der Analysephase im Fokus der Betrachtung. Ein sehr probates und auch bedeutsames Mittel zur Konstruktion von normalisiert strukturierten konzeptionellen Datenmodellen, die letztlich zur Instanziierung operativer Datenbanken verwendet werden, sind sogenannte Analysemuster. Der Einsatz von Analysemustern, wie er bei David C. Hay [Ha98], Len Silverston [Si01a, Si01b] und auch Martin Fowler [Fo99] thematisiert ist, kann einen wertvollen Beitrag hinsichtlich der Zeit- und Kostenersparnis und Qualitätssicherung in der Konstruktion konzeptioneller Datenmodelle leisten. Obgleich der Einsatz von Analysemustern zur Konstruktion normalisierter konzeptioneller Datenmodelle in den zuvor genannten Arbeiten behandelt wird, so ist bis heute die Verwendung von Analysemustern in der konzeptionellen dimensionalen Datenmodellierung weder in der Literatur noch in der Praxis ein Thema. Einzig in den Büchern von [Ki98], [Ki08] und [KR02] sind ein paar spezielle, exemplarische Problemsituationen sowie deren Lösungsansätze skizziert und entsprechend modelliert, jedoch nicht in Form von Mustern. Trotz der enormen Bedeutung der Analysephase per se wird während der Konstruktion von konzeptionellen dimensionalen Datenmodellen, die für die Entwicklung von IT-Systemen für Business Intelligence-Lösungen fundamental sind, nicht auf bewährte Problemlösungsansätze in Form von Mustern zurückgegriffen. Angesichts der enormen Bedeutung der Analysephase erscheint diese Tatsache mehr als verwunderlich, zumal die Nichtberücksichtigung von bewährten Analysemustern zu qualitativ ungesicherten und somit mangelhaften fachlichen dimensionalen Datenmodellen bzw. Datenbanken führen kann, aus denen wiederum qualitativ ungesicherte Informationen generiert werden. In wissenschaftlicher Hinsicht erweist sich die Nichtberücksichtigung von Analysemustern zur Konstruktion fachlicher dimensionaler Datenmodelle und demnach im Entwicklungszyklus von Data Warehouse-Systemen als eine Forschungslücke. Diese Arbeit versteht sich als ein erster Ansatz, diese Lücke zu schließen. 8

9 2 Forschungsdesign: Wissenschaftstheoretische Positionierung Diese Arbeit befindet sich am Beginn eines Forschungszyklus. Am Anfang einer Forschungsarbeit steht ein Forschungsproblem, das zumeist auf einer in der Umwelt des Forschers beobachtbaren Frage- oder Problemstellung basiert oder sich an traditionellen Problemstellungen der Wissenschaft orientiert [Sc07, S. 469]. Da es sich, wie eine umfangreiche Untersuchung der Data Warehouse-Literatur gezeigt hat, bei Analysemustern in der dimensionalen Datenmodellierung um eine Forschungslücke handelt, existieren demzufolge noch keine fundierten Erkenntnisse zu dieser Thematik. Das Forschungsproblem ist demnach im Mangel an Erkenntnissen sowie an nutzbringenden Artefakten (Analysemustern) zu sehen. Zur Lösung dieses Problems wird sich an der Dualität wissenschaftlicher Forschung orientiert, wie sie in [Sc07, S. 71] veranschaulicht ist (Abbildung 1). Wissenschaftliche Forschung Wissensmotiv (Erkenntniserzielung und -fundierung) Maxime des Handelns: Wahrheit Grundlegende Verfahren: Erk.-Erzielung: Induktion, Deduktion, Abduktion, Hermeneutik Erkenntnis Erk.-Fundierung: Evaluierung Gestaltungsmotiv (Erkenntnisnutzung) Maxime des Handelns: Nützlichkeit Grundlegende Verfahren: Konstruktion Expliziertes Ergebnis der Erkenntnis Hypothese Übergang Theorie (Re-) Konstruktion Artefakt Evaluierung Abbildung 1: Dualität wissenschaftlicher Forschung Jede Wissenschaft verfolgt grundsätzlich zwei Forschungsziele: Erkenntnisziel und Gestaltungsziel [Fr90, S. 14]. Dem Erkenntnisziel nach versucht eine Wissenschaft fundierte Erkenntnisse über einen Erkenntnisgegenstand zu erlangen, um auf dieser Grundlage dem Gestaltungsziel folgend nutzbringende Artefakte zu konstruieren. Die Maxime des erkenntnisgetriebenen Handelns ist die Wahrheit, die des gestaltungsorientierten Handels die Nützlichkeit [Fr90, S. 14]. 9

10 Speziell in der Wirtschaftsinformatik zeigt sich die Dualität wissenschaftlicher Forschung in dem von Hevner et al. viel beachteten Artikel "Design Science in Information Systems Research" [He04]. Für sie zeichnet sich wissenschaftliche Forschung der Wirtschaftsinformatik durch die zwei verschiedenen, komplementären Paradigmen "Behavorial Science" und "Design Science" aus. Das verhaltenswissenschaftliche Paradigma (Behavioral Science), dessen Wurzeln in den Naturwissenschaften liegen, strebt im Zuge des Erkenntnisgewinns nach der Bildung und Überprüfung von empirisch abgesicherten Theorien über IT-Artefakte. Das konstruktionswissenschaftliche Paradigma (Design Science), dessen Wurzeln in den Ingenieurwissenschaften liegen und mit einem problemlösenden Ansatz zu vergleichen sind, haben die erkenntnisgetriebene Konstruktion und Bewertung von für die Wissenschaft und Praxis nützlichen IT-Artefakten zum Gegenstand. Um Forschungsziele zu erreichen, werden gegebenenfalls mehrere, unterschiedliche Forschungsmethoden eingesetzt werden. Eine Forschungsmethode ist als zielgerichtetes Verfahren ein intersubjektiv nachvollziehbares System aus zielgerichteten Regeln [WiHe07, S. 281]. Ein Forschungsdesign bietet als ein Untersuchungsplan einen geeigneten Rahmen, um Forschungsziele und eingesetzte Forschungsmethoden aufzuzeigen und demnach die wissenschaftstheoretische Position sowie damit implizit den aktuellen Stand einer wissenschaftlichen Arbeit zu explizieren [BrEs06, S. 146]. Den Ausgangspunkt und das erkenntnistheoretische bzw. hypothetische Fundament der der hier vorgestellten Artefakte (Analysemuster) bilden eigene theoretische Erkenntnisse, in zahlreichen Data Warehousing-Projektierungen gesammelte praktische Erfahrungen und aus Literaturrecherchen gewonnene Informationen. Die Gesamtheit dieser Erkenntnisse wird in induktiver und sachlogischer Weise weiterentwickelt und einer kognitiven Synthese gleichsam in abstrakte Wissenskonstrukte überführt. Diese Wissenskonstrukte sind die Quellen der Explikation bzw. Konstruktion der Artefakte. Da diese Arbeit noch auf keine empirisch gestützten und somit fundierten Erkenntnisse zurückgreifen kann, müssen die den Artefakten zugrunde liegenden Erkenntnisse gemäß dem forschungsstrategischen Zusammenhang zwischen Hypothese, gehaltvolle Hypothese und Theorie nach [Sc07, S. 470] als reine Hypothese angesehen werden. Das Forschungsdesign dieser Arbeit ist in der nachfolgenden Tabelle zusammengefasst. Forschungsziele Status der E rkenntnis Forschungsmethoden (1) Erkenntnismotiv (2) Gestaltungsmotiv Hypothese (1) Induktion, sachlogische Überlegungen (Denkmethoden) (2) Konstruktion von Artefakten (Analysemuster) Tabelle 1: Forschungsdesign dieser Arbeit 10

11 3 Dimensionale Datenmodelle Seit ihrer Entstehung in den 1990er Jahren haben sich Data Warehouse-Systeme als Ergebnis von Aktivitäten des Data Warehousing als fester Bestandteil in der Applikationslandschaft von Unternehmen etabliert [In05], [Ki98], [Ki08], [KR02], [IGG03], [BG09], [Wi00], [CG99]. Mithilfe eines Data Warehouse-Systems wird die Verbesserung bzw. Optimierung der betrieblichen Datenlogistik angestrebt. Ein Data Warehouse-System ist ein unternehmensweites Informationssystem, das aus Applikationen und Datenbanken besteht, die das Data Warehouse nutzbar machen [Wi00, S. 128]. Eine klassische Definition von Data Warehouse wurde von William Inmon geprägt, der auch als der "Vater des Data Warehousing" gilt. Inmon definiert ein collection of data in support 29]. Auf der Grundlage dieser Definition lässt sich ein Data Warehouse als eine integrierte Datenbasis, die sowohl Ziel datenintegrativer Maßnahmen auf operativen Datenbeständen als auch Quelle für informationserzeugende Maßnahmen innerhalb analytischer Anwendungssysteme, die zur Entscheidungsunterstützung eingesetzt werden, verstehen [Sc06, S. 173], [Sc07, S. 382]. Im Zentrum eines Data Warehouse-Systems steht das Data Warehouse, das die Basis für die unternehmensweite Datenlogistik stellt. Je nach Architekturform des Data Warehouse-Systems besteht ein Data Warehouse aus unterschiedlichen Datenbanktypen [Sc07, S. 385]. Zu diesen Datenbanktypen gehören immer dimensional strukturierte Datenbanken, die als Ausgangspunkt für informationserzeugende Maßnahmen innerhalb analytischer Anwendungssysteme zur Entscheidungsunterstützung verwendet werden. Dimensional strukturierte Datenbanken sind Instanzen von dimensionalen Datenmodellen. Ein dimensionales Datenmodell ist ein spezielles Datenmodell, das die typmäßige Strukturorganisation von multidimensionalen Daten beschreibt und dabei überwiegend auf die Konzepte Dimension und Kennzahl zurückgreift [KR02], [IGG03]. Multidimensionale Daten sind speziell für Analysezwecke zusammengestellte Daten, die nach vielfältigen Kriterien (Dimensionen), die jeweils in der Regel eine interne hierarchische Gliederung aufweisen, die Auswertung von Fakten (Kennzahlen) erlauben [Sc07, S. 385]. Kimball et al. bringen die grundlegende Idee, die sich hinter der dimensionalen Datenmodellierung verbirgt, treffend zum Ausdruck: dimensional modeling is that nearly every type of business data can be represented as a kind of cube of data, where the cells of the cube contain measured values and the edges Ki98, S. usually numeric values; we refer to them as facts. Facts are surrounded by largely textual context that is true at the moment the fact is recorded. This context is intuitively divided into independent logical clumps called dimensions 08, S. 235]. 11

12 Die grundlegende Idee hinter der dimensionalen Datenmodellierung ist also, dass die Datenstruktur entscheidungsunterstützender Anwendungssysteme multidimensional organisiert ist und demnach nahezu jeder Typ von entscheidungsunterstützenden Geschäftsdaten als eine Art mehrdimensionales Gebilde interpretiert und repräsentiert werden kann. Zur Veranschaulichung des mehrdimensionalen Gebildes wird gerne die Würfelmetapher bemüht, die einen intuitiven und leicht verständlichen Zugang zur dimensionalen Datenmodellierung bietet. Das mehrdimensionale Gebilde wird demzufolge als Datenwürfel betrachtet. Während ein "echter" Würfel jedoch lediglich auf drei Dimensionen beschränkt ist, kann ein Datenwürfel allgemein N Dimensionen besitzen [BG09, S. 112 ff.], [Sc07, S. 385]. Die Zellen des Datenwürfels beinhalten die Kennzahlen. Eine Kennzahl ist eine quantitativ erfassbare Größe, die eine in konzentrierter Form auswertbare und betriebswirtschaftlich relevante Information über einen betrieblichen Sachverhalt darstellt (z. B. Umsatz, Kosten) [Sc07, S, 385]. Die Kanten des Datenwürfels repräsentieren die Dimensionen. Eine Dimension ist eine Einflussgröße auf eine Kennzahl und beschreibt somit eine mögliche Sicht auf die Kennzahl [Ho01, S. 211], [Sc07, S. 385]. In Anlehnung an den Kontextgedanken bei Kimball et al. lässt sich eine Dimension auch als ein eindeutiges, orthogonales Strukturierungselement multidimensionaler Daten betrachten [BG09, S. 109 u. 189]. Datenmodelltechnisch handelt es sich bei Dimensionen um Klassen (Entitätstypen), die im Zuge einer N-ären Assoziation einen mehrdimensionalen Datenwürfel aufspannen und eine Assoziationsklasse namens Faktentabelle bilden, die die Kennzahlen beinhaltet. Klassische Beispiele für Dimensionen sind die Zeit, der Ort und das Produkt, die allesamt einen Einfluss auf die Kennzahlen Umsatz oder Kosten haben. Die nachfolgende Abbildung 2 illustriert das Grundschema eines dimensionalen Datenmodells. Es wird aufgrund seiner Darstellungsform auch als Sternschema bezeichnet. Sämtliche folgenden fachlichen dimensionalen Datenmodelle sind mithilfe der Barker-Notation [Ba90] formuliert. # * Dimension 1 Dimension 1 KEY Further Attributes # * Dimension 3 Dimension 3 KEY Further Attributes 1,1 1,1 0,n 0,n # # # # * o Fact Table Dimension 1 KEY Dimension 2 KEY Dimension 3 KEY Dimension N KEY Facts Fact Attributes 0,n 0,n 1,1 1,1 # * Dimension 2 Dimension 2 KEY Further Attributes # * Dimension N Dimension N KEY Further Attributes Abbildung 2: Schema eines dimensionalen Datenmodells 12

13 4 Analysemuster 4.1 Problemlösungsverhalten von Experten Experten sind Personen, die über ein umfangreiches Domänenwissen, d. h. Wissen auf einem oder mehreren Sach- bzw. Fachgebieten, verfügen. Nach [CGF88] sind unter anderem das Erkennen von Zusammenhängen und das Achten auf wiederholbare Strukturen als auf Oberflächlichkeiten Schlüsseleigenschaften eines Experten. Darüber hinaus zeichnen sich Experten im Gegensatz zu Laien in der Regel dadurch aus, dass sie eine Vielzahl von Problemen erfolgreich gelöst haben und anstehende Probleme nicht immer von Grund auf erneut lösen, sondern sich bereits bewährter Lösungsmuster vergangener Probleme bedienen [Ga94], [Ba05, S. 84]. Ein Experte zieht vielmehr zur Lösung eines neuen Problems bekannte Lösungsansätze oder im Idealfall Lösungsmuster alter Probleme heran. Er erfindet somit das sprichwörtliche Rad nicht immer wieder erneut, sondern greift auf bewährtes Problemlösungswissen zurück und adaptiert dieses auf die neue Problemsituation. Voraussetzung für die Anwendung einer bereits praktizierten Lösung für ein neues Problem ist, dass der Lösungsansatz für das alte Problem erstens grundsätzlich anwendbar ist und zweitens in einem geeigneten Abstraktionsniveau vorliegt. Das explizierte Domänenwissen, das die Lösung für ein sich wiederholendes Problem in einem Kontext beschreibt, und auf einem entsprechenden Abstraktionsniveau vorliegt bezeichnet man als Muster (Pattern) [Bu98], [Sc07, S. 350]. Diese einfach gehaltene Definition erklärt zudem, weshalb im Zusammenhang mit einem Muster von einem Problem-Kontext-Lösungs-Tripel gesprochen wird. Die Idee, Wissen in kanonischer Form aufzuzeichnen und wiederzuverwenden, geht auf den Architekten Christopher Alexander zurück. In seinem Buch "The Timeless Way of Building" beschreibt er verschiedene Muster und ihre Eigenschaften speziell für den Einsatz beim Hausbau und der Städteplanung [Al79]. Für die Softwareentwicklung hat das 1994 erschienene Werk "Design Patterns: Elements of Reusable Object-Oriented Software" von [Ga94] den größten Einfluss sowie eine initiierende Wirkung auf die Musterbewegung ausgeübt. Obwohl die Musterbewegung mehrere Wurzeln verzeichnet [Fo99, S. 5], gehören Muster spätestens seit dem Erscheinen dieses Werks zum gängigen Usus der Softwareentwicklung. Wie bereits der Titel andeutet, handelt es sich bei den in diesem Buch vorgestellten Mustern um Muster speziell für die Entwurfsphase der Softwareentwicklung. 13

14 Das Konzept der Muster als erfolgreiches Artefakt der Wiederverwendung in der Entwurfsphase hat dazu beigetragen, das Musterkonzept auch während der Analysephase zu nutzen. In Analogie zu Entwurfsmustern während des Entwurfs werden Muster während der Analyse als Analysemuster bezeichnet. Der Begriff Analysemuster wurde von Martin Fowler geprägt. In seinem Buch "Analysis Patterns: Reusable Object Vorwort u. S. 9]. Er lässt die Definition bewusst offen, um anzudeuten, dass ein Muster im Endeffekt alles sein kann. Die Wendung "praktischer Kontext" zeigt, dass ein Muster das Ergebnis tatsächlicher, praktischer Anwendungen ist und aus Erfahrungswissen über eine Domäne resultiert. Jede im Rahmen der Softwareentwicklung durchzuführende Modellkonstruktion lässt sich als Problem ansehen, das es aus Expertensicht unter Einsatz von Mustern zu lösen gilt. Da die Phase der Analyse im gesamten Systems- bzw. Software Engineering Prozess die wichtigste Phase darstellt, muss Analysemustern dementsprechend ein hoher Stellenwert eingeräumt werden. 4.2 Schema der Beschreibungsform Zur Spezifikation von Analysemustern wird in dieser Arbeit eine einfache Beschreibungsform gewählt, die aus einer Beschreibung des Problems, des Kontexts, der Lösung sowie einer Methode besteht. Für eine umfassende Musterbeschreibungsstruktur, die sich üblicherweise an der in Musterkatalogen anzutreffenden Form orientiert und diese um diverse Aspekte (z. B. organisatorische und ökonomische Aspekte) erweitert, ist auf [Ha01, S. 46 f.] und [JS06, S. 193 ff.] verwiesen. Eindeutiger Name. Jedes Muster erhält einen eindeutigen Namen, der es möglichst präzise und prägnant bezeichnet. Problem. Für jedes Muster wird eine Beschreibung des Problems angefertigt. Unter einem Problem ist eine aus subjektiver Sicht unbefriedigende Situation mit negativen Auswirkungen zu verstehen. Die Problembeschreibung skizziert das in einem Kontext wiederholt auftretende und zu lösende Problem sowie gegebenenfalls Aspekte, die bei der Lösung des Problems zu berücksichtigen sind. Im Zusammenhang mit der Informationsmodellierung ist ein Problem in deskriptiver Hinsicht eine bestimmte, unbefriedigende Gegebenheit der in der Problemdomäne (Kontext) befindlichen Phänomene, zu deren Unterstützung ein IT-System konzipiert und realisiert wird, bzw. in präskriptiver Hinsicht eine bestimmte, unbefriedigende Gegebenheit von Teilen eines Informationsmodells (z. B. eines dimensionalen Datenmodells). Kontext. Für jedes Muster wird eine Beschreibung des Kontexts angefertigt. Der Kontext benennt die reale oder ideelle Situation bzw. den Sinnzusammenhang, in dem die wahrgenommenen Phänomene verortet sind und in dem das Problem wiederholt auftritt. Darüber hinaus beschreibt der Kontext die Voraussetzungen für den Einsatz des Musters. 14

15 Lösung. Für jedes Muster wird eine Lösung des Problems beschrieben. Unter einer Lösung ist eine aus subjektiver Sicht befriedigende Situation ohne negative Auswirkungen zu verstehen. Die Lösung, die das Muster für ein Problem anbietet, wird in Form einer grafischen Darstellung repräsentiert. Die grafische Darstellung umfasst den Aufbau des Musters und dessen Beitrag zur Lösung des Problems. Methode. Die Methode eines Musters beschreibt als zielgerichtetes Vorgehen die Ableitung konkreter, auf den Mustern basierender dimensionaler Datenmodelle. 5 Ausgewählte Analysemuster für dimensionale Datenmodelle Wie bereits in Kapitel 1 Einführung erwähnt sind Analysemuster in der dimensionalen Datenmodellierung bis heute weder in der Literatur noch in der Praxis auch nur ansatzweise thematisiert. Einzig Kimball et al. behandeln in ihren Büchern [Ki98], [Ki08] und [KR02] im Rahmen eines "Graduate Course on Dimensional Modeling" einige wenige beispielhafte Problemsituationen und deren Lösungen in Form von dimensionalen Datenmodellen. Der Mustergedanke spielt dabei keine Rolle. Dieses Kapitel bereitet Problemlösungssituationen in allgemeiner Form auf und stellt die speziellen Problem-Kontext-Lösung-Tripel inklusive Methode in Form von Analysemustern vor. 5.1 Unterschiedliche Veränderungszyklen von Dimensionsattributwerten Eindeutiger Name. Dimensionsattributwerteänderung. Problem. Eine Dimension verfügt in der Regel über eine Vielzahl von Attributen, die über Denormalisierungsprozesse den Weg aus normalisiert strukturierten Klassengeflechten in die Dimension finden. Die Konzeption einer Dimension folgt dabei bewusst dem Prinzip der Denormalisierung. Ursprünglich auf dem Grundsatz der Normalisierung aufgebaute und demnach auf verschiedene Klassen aufgeteilte Attribute werden in einer Dimension zusammengeführt. Im Zuge dieser Zusammenführung erfolgt keine Unterscheidung dahingehend, welchen Änderungszyklen die einzelnen Attributwerte unterworfen sind. Die entstehenden Dimensionen konstituieren sich aus Attributen, deren Attributwerte unterschiedlichen Änderungszyklen unterliegen. Eine Folge dieser unbedachten Attribute-Zusammenführungen ist eine stetig wachsende Anzahl an auf dieser Dimension beruhenden Objekten, die sich inhaltlich durch ein hohes Maß an unnötiger Redundanz auszeichnen. Die einzelnen Objekte unterscheiden sich nur in den Attributwerten derjenigen Attribute, die häufigen Änderungen unterliegen, während der Rest an Attributwerten unverändert bleibt. 15

16 Beispielsweise sind in einem normalisierten Datenmodell Produktdaten dem Ansatz einer einfachen Klassifikationshierarchie folgend in mehreren, miteinander in jeweiliger 1:n-Beziehung stehenden Klassen untergebracht. In klassischer Weise handelt es sich bei diesen Klassen um Produkt (n) (1) Produktgruppe (n) (1) Produktfamilie (n) (1) Produktkategorie. Ein Produkt ist exakt einer Produktgruppe zugeordnet, während eine Produktgruppe mehrere Produkte umfasst. Eine Produktgruppe wiederum ist genau einer Produktfamilie zugeordnet, während eine Produktfamilie aus mehreren Produktgruppen besteht u. s. w. Im Zuge der Denormalisierung werden die Attribute aus den Klassen Produkt, Produktgruppe, -familie und -kategorie in der Dimension Produkt zusammengeführt. In der betrieblichen Praxis ändern sich in der Regel produktspezifische Daten der Klasse Produkt, z. B. der Preis, häufiger und schneller als produktbezogene Gruppen-, Familien- oder Kategoriedaten (z. B. das Produkt VR ABC gehört der Produktgruppe Videorecorder, diese wiederum der Produktfamilie Video und diese wiederum der Produktkategorie Unterhaltungselektronik an). Kontext. Der Kontext dieses Problems ist im Hinblick auf die dimensionale Datenmodellierung allumfassend. Jede Umgebung (Problemdomäne), die wahrgenommen und zur Konstruktion von Dimensionen führt, die sich durch unterschiedliche Zyklen der Wertänderungen ihrer Attribute auszeichnen, ist Kontext dieses Problems. Lösung. Die Lösung dieses Problems ist nachfolgender Abbildung 3 zu entnehmen. # * * Dimension Dimension KEY Static Attributes Dynamic Attributes Split Dimension class # * * Dimension A Dimension A KEY Static Attributes Static Attributes Hierarchy Level 1,1 1,1 0,n 0,n # # * o Fact Table Dimension A KEY Dimension B KEY Facts Fact Attributes # * * Dimension B Dimension B KEY Dynamic Attributes Dynamic Atributes Hierarchy Level Abbildung 3: Pattern Dimensionsattributwerteänderung Wie aus der Abbildung ersichtlich ist, wird die ursprüngliche Dimension in zwei Dimensionen aufgeteilt. Eine Dimension (DIMENSION A) enthält die Attribute, deren Werte sich kaum ändern, während die andere Dimension (DIMENSION B) diejenigen Attribute aufnimmt, deren Werte sich häufiger zu ändern scheinen. 16

17 Um eventuellen durch die Aufspaltung bedingten Informationsverlusten bei Drill-Down und Roll-Up Operationen vorzubeugen, können sowohl für die statischen als auch für die dynamischen Attribute deren Hierarchielevels (STATIC ATTRIBUTES HIERARCHY LEVEL und DYNAMIC ATTRIBUTES HIERARCHY LEVEL) explizit in Form eines numerischen Wertes angegeben werden. Ein Hierarchielevel repräsentiert die Hierarchiestufe, auch Abstraktionsstufe (engl. level of granularity, LoG) genannt, inmitten einer Dimension, auf der sich eine bestimmte Attributgruppe befindet. Bezogen auf das vorherige Beispiel einer einfachen Produktkategorisierung beträgt die Hierarchiestufe der produktspezifischen Daten (Klasse Produkt) 0. Diese Hierarchiestufe stellt die höchste Stufe der Granularität (Detailliertheit) dar. Die Hierarchiestufe der Daten aus der Produktgruppe beträgt 1, aus der Produktfamilie 2 und aus der Produktkategorie 3. Informationen über die Hierarchiestufen werden bei Drill-Down- und Roll-Up- Operationen benötigt. Methode. Konkrete dimensionale Datenmodelle lassen sich auf Basis dieses Musters nach folgender Methode ableiten: Schritt E rklärung 1 Zusammentragen der Attribute einer Dimension. 2 Bestimmung von Faktoren anhand derer eine Diversifikation in statische und dynamische Attribute vorgenommen werden kann. 3 Aufteilung der ursprünglichen Dimension in zwei Dimensionen, wobei die eine Dimension die statischen und die andere Dimension die dynamischen Attribute beinhaltet. 4 Inbeziehungsetzen der beiden Dimensionen mit der Faktentabelle. Tabelle 2: Pattern Dimensionsattributwerteänderung: Methode 5.2 Mehrfachvorkommen von Dimensionsobjekten pro K ennzahl(en) bei vorgegebener G ranularität der Faktentabelle Eindeutiger Name. Viele-zu-viele Dimensionsobjekte bei gegebener Granularität der Faktentabelle. 17

18 Problem. Die Festlegung der Granularität (Detailliertheitsgrad) der Faktentabelle ist ein wesentlicher Schritt bei der Erstellung eines dimensionalen Datenmodells. Die Granularität der Faktentabelle bestimmt, was ein Datensatz in der Faktentabelle repräsentiert. Steht die Granularität der Faktentabelle aufgrund bevorstehender Analysen oder Berichte fest, so kann es Dimensionen geben, bei denen ein Objekt (Dimensionsdatensatz) pro Fakteneintrag mehrfach vorkommen kann. Das Nichterkennen und Nichtberücksichtigen dieser Situation, das heißt das Dimensionsobjekte mehrfach pro Kennzahl vorkommen, führt zu einer Verletzung der Granularität der Faktentabelle. Dies kann wiederum zu mutierten Kennzahlenwerten und somit zu falschen Ergebnissen in der Auswertung der multidimensionalen Daten. Die Mutation der Kennzahlenwerte äußert sich darin, dass a priori additive Fakten zu semiadditiven oder gar nicht-additiven Fakten verkommen, was erhebliche Konzeptionseinbußen nach sich zieht. Als Beispiel soll eine Rechnung im Gesundheitswesen dienen. Eine Rechnung besteht grundsätzlich aus mehreren Rechnungspositionen. Speziell im Gesundheitswesen verbergen sich hinter einer Rechnungsposition in der Regel die von mehreren Ärzten in einem bestimmten Zeitraum gestellten Diagnosen und damit einhergehenden Therapien. Arzt, Diagnose und Therapie sind wie Patient und Zeit Dimensionen im dimensionalen Datenmodell. Für Berichtszwecke im Rechnungswesen soll die Granularität der Faktentabelle auf eine Rechnungsposition fixiert sein. Das heißt, ein Datensatz der Faktentabelle repräsentiert eine Rechnungsposition. Eine unmittelbare Folge dieser Granularität ist das theoretische Mehrfachvorkommen von Ärzten, Diagnosen und Therapien pro Fakteneintrag. Eine Möglichkeit, dieses Problem des Mehrfachvorkommens von Dimensionsobjekten an einem Fakteneintrag zu umgehen, besteht darin, die Granularität der Faktentabelle auf Zeit Patient Arzt Diagnose "herunterzubrechen". Diese Lösung, die ein mehrfaches Einfügen des jeweiligen Primärschlüssels der entsprechenden Dimension (Arzt, Diagnose und Therapie) als Fremdschlüssel in die Faktentabelle bedeutet, stellt jedoch de facto eine Verletzung der ursprünglich festgelegten Granularität dar und soll demnach auch nicht weiter verfolgt werden. Kontext. Jede Umgebung (Problemdomäne), die wahrgenommen und zur Konstruktion von Dimensionen und Faktentabellen führt und bei der die Granularität der Faktentabelle a priori fixiert ist, ist Kontext dieses Problems. Die Festlegung der Granularität einer Faktentabelle ist einer der ersten Schritte und damit wesentlich in der Konzeption eines dimensionalen Datenmodells [Ki08, S. 246 f.], [KR02, S. 31], [IGG03, S. 121]. In jedem dimensionalen Datenmodell kann die Folge der festgelegten Granularität sein, dass bestimmte Dimensionseinträge mehrfach pro Faktum vorkommen. Lösung. Die Lösung dieses Problems ist in Abbildung 4 dargestellt. # * Dimension Dimension KEY Further Attributes Dimension Bridge 1,1 0,n # Dimension Group KEY # Dimension KEY 1,1 0,n # From Date o Thru Date * Further Attributes # * o Fact Table Dimension Group KEY Facts Fact Attributes 18

19 Abbildung 4: Pattern Viele-zu-viele Dimensionsobjekte Zwischen der ursprünglichen Dimension (DIMENSION) und der Faktentabelle (FACT TABLE) wird eine Brückendimension (DIMENSION BRIDGE) integriert. Der Primärschlüssel der Brückendimension besteht aus einem Surrogatschlüssel je Gruppe (DIMENSION GROUP KEY) und dem Fremdschlüssel (DIMENSION KEY) aus der ursprünglichen Dimension. Unter dem DIMENSION GROUP KEY werden die n-fach- Vorkommen der Dimensionseinträge subsumiert. Anstelle der einzelnen DIMENSION KEY-Primärschlüssel wird der Teil-Primärschlüssel DIMENSION GROUP KEY der Brückendimension an die Faktentabelle weitergereicht. Methode. Konkrete dimensionale Datenmodelle lassen sich auf Basis dieses Musters nach folgender Methode ableiten: Schritt E rklärung 0 Voraussetzung: Fixierte Granularität der Faktentabelle 1 Untersuchung der Dimensionen, ob Dimensionsobjekte mehrfach pro Faktum vorkommen können. 2 Falls ja, Integration einer Brückendimension zwischen der betrachteten Dimension und der Faktentabelle. 3 Bildung eines zusammengesetzten Primärschlüssels in der Brückendimension aus einem Gruppenschlüssel (Surrogatschlüssel) und dem Primärschlüssel der Dimension. 4 Weiterleiten des Gruppenschlüssels an die Faktentabelle. Tabelle 3: Pattern Viele-zu-viele Dimensionsobjekte: Methode 5.3 Rollenspielende Dimensionen Eindeutiger Name. Rollenspielende Dimension. Problem. Einem ontologischen Grundverständnis nach zeichnen sich real- und vorstellungsweltliche Phänomene neben ihrer unveränderlichen Wesensart durch ein veränderliches Verhaltensmuster (Rolle) aus [Gu92]. Ein typisches Beispiel hierfür ist eine Person, die im Laufe ihres Lebens eine Vielzahl unterschiedlicher Rollen bekleiden kann (Student, Mitarbeiter, Kunde etc.). Das Nichterkennen und Nichtberücksichtigen dieser Rollen bei der Konstruktion eines Datenmodells, das diese Phänomene abstrahiert repräsentiert, führt in der Regel zu unkontrollierter Redundanz der Daten. In diesem Zusammenhang sprechen [CZ97, S. 258] von einer "object reclassification anomaly". 19

20 Das Prinzip des veränderlichen Verhaltensmusters bzw. der Rolle lässt sich ebenfalls auf dimensionale Datenmodelle übertragen. Eine Dimension repräsentiert aufgrund ihres denormalisierten Charakters häufig nicht nur ein, sondern mehrere real- und/oder vorstellungsweltliche Phänomene. Übt ein Phänomen bzw. die gesamte Dimension unterschiedliche Rollen aus, so müssen diese Rollen berücksichtigt werden, um unkontrollierte Redundanzen in den dimensionalen Datenbeständen zu vermeiden und darüber hinaus für eine klarere Semantik der Dimensionen zu sorgen. Beispielsweise kann die Dimension Zeit die Rollen des Bestelldatums, des Lieferdatums oder des Rechnungsdatums spielen. Eine Dimension Flughafen kann zum Beispiel die Rollen Abflug- und Ankunft-Flughafen ausüben. Diese Beispiele zeigen, dass sich veränderliche Verhaltensmuster nicht nur auf Personen beschränken. Kontext. Der Kontext dieses Problems ist im Hinblick auf die dimensionale Datenmodellierung wiederum allumfassend. Jede Umgebung (Problemdomäne), die wahrgenommen und zur Konstruktion von Dimensionen führt, die unterschiedliche Rollen einnehmen können, ist Kontext dieses Problems. Lösung. Die Lösung dieses Problems ist in Abbildung 5 dargestellt. Role Playing Dimension # Dimension KEY * Further Attributes Create materialized Views Dimension Role A View # Dimension A KEY * Further Attributes Dimension Role B View # Dimension B KEY * Further Attributes Dimension Role C View # Dimension C KEY * Further Attributes 1,1 0,n 1,1 0,n # # # * o 1,1 0,n Fact Table Dimension A KEY Dimension B KEY Dimension C KEY Facts Fact Attributes Abbildung 5: Pattern Rollenspielende Dimension Aus der Abbildung geht hervor, dass die von einer Dimension ausgeübten Rollen im dimensionalen Datenmodell mittels materialisierter Sichten (Views) realisiert werden. Jeder einzelne Primärschlüssel (DIMENSION A KEY, DIMENSION B KEY, DIMENSION C KEY) der jeweiligen View-Dimension (DIMENSION ROLE A VIEW, DIMENSION ROLE B VIEW, DIMENSION ROLE C VIEW) geht in die Faktentabelle als Fremdschlüssel ein. Werden pro Fakteneintrag jedoch nicht alle Rollen von einer rollenspielenden Dimension ausgeübt, so müssen die diversen View-Dimensionen den Dummy-Datensatz "None" aufweisen, um die semantische Interpretation der Faktentabelle nicht zu gefährden. Methode. Konkrete dimensionale Datenmodelle lassen sich auf Basis dieses Musters nach folgender Methode ableiten: Schritt E rklärung 1 Untersuchung derjenigen Aspekte, die Einzug in eine Faktentabelle finden 20