Datenmodellierung: Multidimensionale Ansätze

Die Arbeit beginnt mit der Definition von sechs Grundsätzen ordnungsgemäßer Modellierung. Besonders wichtig ist der Grundsatz der Richtigkeit, der sowohl syntaktische (Konsistenz und Vollständigkeit im Bezug zum Metamodell) als auch semantische Richtigkeit (struktur- und verhaltenstreue Abbildung der Realität, Widerspruchsfreiheit) umfasst. Die Einhaltung dieser Grundsätze ist essentiell für die Qualität und Zuverlässigkeit des entwickelten Datenmodells im Data Warehouse. Ein konzeptionelles Modell, das diese Grundsätze berücksichtigt, bildet eine solide Basis für die spätere Umsetzung im Informationssystem und garantiert die Integrität der Daten. Die Berücksichtigung dieser Grundsätze wirkt sich direkt auf die Datenqualität und die späteren Analysen aus. Ein fehlerhaftes Modell führt zu inkonsistenten Ergebnissen und erschwert die Entscheidungsfindung auf Basis der Daten.

Die konzeptionelle Modellierung wird als fachlich orientiertes Modell beschrieben, das unabhängig vom Ziel-DBMS ist. Diese Unabhängigkeit ermöglicht eine benutzernahe Darstellung und erleichtert die Diskussion zwischen Fach- und IT-Abteilung. Konzeptionelle Modelle dienen als Grundlage für Data Dictionaries, Repositories und unterstützen Endanwender bei der Navigation im Datenpool. Ihre Systemunabhängigkeit sichert die Langzeitgültigkeit und vereinfacht Modifikationen an Datenstrukturen. Der Koordinationseffekt wird hervorgehoben, da bei schrittweiser Entwicklung von Data Warehouses ein unternehmensweites Datenmodell alle Aspekte integriert und somit als zentraler Bauplan für alle Entwickler fungiert. Inmon's Unterscheidung zwischen 'corporate data model' und 'enterprise data model' wird erwähnt, abhängig vom Umfang der abgedeckten Unternehmensbereiche. Die konzeptionelle Ebene legt den Grundstein für ein robustes und skalierbares Data Warehouse.

Der Aspekt der Nicht-Volatilität von Daten im Data Warehouse (DWH) wird erläutert. Daten werden nach fehlerfreier Übernahme in der Regel nicht mehr geändert. Änderungen sind nur bei Fehlern in der Datenübertragung oder bei nachträglichen Korrekturen in den operativen Systemen erlaubt. Diese Nicht-Volatilität gewährleistet die Nachvollziehbarkeit von Analysen. Weiterhin werden strukturelle Anomalien wie unvollständige Verdichtung und parallele Hierarchien in multidimensionalen Datenmodellen diskutiert. Parallele Hierarchien entstehen, wenn Dimensionselemente nach verschiedenen Kriterien gruppiert werden. Holthuis empfiehlt hier, zwei unabhängige Dimensionen zu bilden, um fehlerhafte Konsolidierungen zu vermeiden. Diese Anomalien stellen Herausforderungen für die Datenmodellierung dar und erfordern sorgfältige Planung und Modellierung, um Datenintegrität und korrekte Analysen zu gewährleisten. Eine adäquate Datenmodellierung muss diese Herausforderungen berücksichtigen, um die Qualität und Zuverlässigkeit der Daten zu sichern.

Für einen adäquaten Modellierungsansatz werden zwei wichtige Anforderungen formuliert: Erstens muss der Ansatz ein strukturiertes Vorgehensmodell beinhalten, um eine systematische und nachvollziehbare Modellierung zu ermöglichen. Zweitens sollte der Ansatz durch ein geeignetes Werkzeug unterstützt werden, um den Modellierungsprozess zu vereinfachen und zu beschleunigen. Diese Anforderungen zielen darauf ab, die Effizienz und Qualität des Modellierungsprozesses zu steigern und sicherzustellen, dass das resultierende Datenmodell den Bedürfnissen des Unternehmens entspricht. Die Wahl des richtigen Vorgehensmodells und die Verwendung geeigneter Werkzeuge sind daher entscheidend für den Erfolg eines Data-Warehouse-Projekts. Die Unterstützung durch ein Werkzeug vereinfacht die Modellierung und reduziert das Risiko von Fehlern.

Das MERM wird als Erweiterung des ER-Modells nach Chen vorgestellt, das von Sapia, Blaschka, Höfling und Dinter 1998 entwickelt wurde. Ziel war es, die bestehenden Konstrukte zu erweitern, um qualifizierende und quantifizierende Daten zu unterscheiden und Verdichtungen zwischen Dimensionsebenen darzustellen – etwas, was mit dem ursprünglichen Modell nicht möglich war. Neue grafische Elemente wie Fakt-Beziehungen, Dimensionsebenen und Rolls-Up-Beziehungen wurden hinzugefügt. Fakt-Beziehungen repräsentieren Fakten und verbinden Dimensionsebenen, wobei direkt verbundene Ebenen als atomar bezeichnet werden. Dimensionsebenen spiegeln qualifizierende Daten wider, während quantitative Daten durch Attribute der Fakt-Beziehung repräsentiert werden. Ein Mangel des MERM ist die fehlende Möglichkeit, abgeleitete Kennzahlen und deren Berechnungsregeln darzustellen. Es wird lediglich für einzelne Dimensionsebenen, nicht für die Dimension als Ganzes, ein Symbol angegeben.

Die ADAPT-Methode wird als ein Ansatz zur Modellierung multidimensionaler Datenstrukturen beschrieben. Im Gegensatz zu anderen Modellen bietet ADAPT einen höheren Abstraktionsgrad und ist nicht von einem spezifischen Datenbanksystem abhängig. Wichtige Modellierungsobjekte sind Dimensionen (mit hierarchisch angeordneten Ebenen und Roll-Up-Funktionen) und f-Tabellen (zur Zuordnung von Kennzahlen zu Dimensionsebenen). Drill-Down und Roll-Up-Operationen werden über Dimensionspfade gesteuert. Die ursprüngliche ADAPT-Version umfasste sechs Dimensionstypen (aggregierend, sequentiell, etc.), die in der aktuellen Version nicht mehr enthalten sind. Die verschiedenen Beziehungstypen (Connector, Strict-Precedence, Loose-Precedence, etc.) ermöglichen die genaue Darstellung von Hierarchien und Abhängigkeiten zwischen Objekten, einschließlich Subset-Objekten für die exakte Abbildung von Beziehungen zwischen Obermengen und Teilmengen.

Die mUML-Methode nutzt das static structure diagram der UML (Klassendiagramm) zur Darstellung. Dimensionsebenen und Fakten werden als Klassen modelliert, Attribute und abgeleitete Kennzahlen werden explizit angegeben. Von den UML-Verbindungen werden Assoziation, Komposition und Generalisierung verwendet, wobei Dimension-, Roll-Up- und Shared-Roll-Up-Stereotypen für spezielle Beziehungen eingesetzt werden. Das Kubenstrukturmodell, entwickelt von J. Schelp et al., unterscheidet sich von anderen Modellen durch das Fehlen eines zentralen Faktenelements. Betriebswirtschaftliche Variablen werden in einer eigenen Dimension dargestellt, die n Dimensionen sind kreisförmig angeordnet. Dimensionselemente werden mit Segmenten verbunden, wobei in der atomaren Sicht alle Elemente, auch in der verdichteten Sicht für die Kennzahlendimension, vollständig angegeben werden können. Zusätzliche Attribute, z.B. Berechnungsvorschriften, können hinzugefügt werden. Beide Methoden bieten verschiedene Ansätze zur Modellierung multidimensionaler Datenstrukturen im Data Warehouse.

Das Semantische Data Warehouse Modell (SDWM), vorgestellt von Michael Böhnlein 2001, ist ein konzeptionelles Datenmodell speziell für multidimensionale Datenstrukturen im Data Warehouse. Ein wesentlicher Unterschied zu anderen Modellen besteht in der Möglichkeit, Sichten auf Teile des Gesamtmodells zu erstellen, um komplexe Modelle verständlicher zu machen. Es existiert ein Meta-Modell zur Überprüfung von Konsistenz und Vollständigkeit. Das Modell unterscheidet zwischen Basiskennzahlensicht (nur Basiskennzahlen) und Datenstruktursicht (Basis- und abgeleitete Kennzahlen, Dimensionen, Schnittstellen und Beziehungen). Semiaggregierbarkeit von Kennzahlen wird durch Kantenbeschriftungen angezeigt. Nicht-dimensionale Attribute werden separat dargestellt. Das SDWM ermöglicht eine strukturierte und übersichtliche Modellierung komplexer multidimensionaler Datenstrukturen.

Die Arbeit beschreibt den SAP Business Content als vorkonfigurierte Informationsmodelle, die auf konsistenten Metadaten basieren und rollen- sowie aufgabenbezogen sind. Diese vorgefertigten Modelle werden als 'generic data models' bezeichnet und bieten den Vorteil, dass sie speziell für Branchen entwickelt wurden und somit ähnliche Daten und Informationsbedürfnisse von Unternehmen derselben Branche abdecken. Der Aufbau eines eigenen Datenmodells ist zeitaufwendig (2-3 Jahre), während der Business Content eine sofort verfügbare Lösung darstellt. Er kann als Template für andere Firmen verwendet werden und beschleunigt somit den Data Warehouse Aufbau erheblich. Der Business Content dient als effiziente Alternative zum aufwendigen Erstellen eines individuellen Datenmodells, insbesondere in zeitkritischen Projekten.

Der SAP Business Content umfasst betriebswirtschaftliche Lösungen wie Rollen, Arbeitsmappen, Queries, InfoSources, InfoCubes, ODS-Objekte, Kennzahlen, Merkmale und Fortschreibungsregeln sowie Extraktoren für verschiedene SAP-Systeme und andere Anwendungen. Einige Objekte sind branchenspezifisch, andere bereichs- und funktionsspezifisch. Der Business Content kann mit oder ohne Anpassungen übernommen oder als Beispiel für selbst erstellten Business Content dienen. Die Flexibilität des Systems ermöglicht Anpassungen an individuelle Anforderungen, während gleichzeitig ein sofort einsetzbares Grundgerüst zur Verfügung steht. Die Kombination aus vorgefertigten Komponenten und Anpassungsmöglichkeiten bietet eine optimale Balance zwischen Effizienz und Individualisierung.

Im SAP Business Warehouse (BW) werden Merkmalswerte durch eine Stammdaten-Identifikationsnummer (SID) eindeutig bezeichnet. Dies unterscheidet sich vom klassischen Starschema, wo Merkmale direkt in den Dimensionstabellen angelegt werden. Die Kapselung der Merkmale durch SIDs ermöglicht deren übergreifende Gültigkeit und Nutzung über mehrere InfoCubes. Das Löschen von Stammdaten ist nur eingeschränkt möglich, um Datenkonsistenz zu gewährleisten. InfoObjekte umfassen Merkmale mit Texten und Stammdaten (Master Data) sowie Kennzahlen (Fluss- oder Bestandsgrößen mit optionalen Einheiten). Zeiten werden als eigene InfoObjekttypen behandelt, wobei die Verwendung der vom Business Content bereitgestellten Zeitmerkmale empfohlen wird. Hierarchien werden über bebuchbare (Merkmalsausprägungen) und nicht bebuchbare Knoten (zur Strukturierung) definiert, wobei die Aggregation der Kennzahlwerte auf Hierarchieknoten erfolgt. Die Verwendung von SIDs und InfoObjekten verbessert die Datenverwaltung und -konsistenz im SAP BW.

InfoCubes dienen der Speicherung multidimensionaler Daten im SAP BW nach dem Prinzip des erweiterten Sternschemas. Sie ermöglichen eine effiziente Speicherung und Analyse von Bewegungsdaten in Fakten- und Dimensionstabellen und bieten umfassende analytische Funktionen. Die physische Datenablage unterscheidet zwischen Standard- und transaktionalen BasisCubes, virtuelle Datenablagen sind Remote und Virtuelle Cubes. Eine besondere Form der Aggregation ist die Bestandsveränderung, bei der Bestandskennzahlen nicht direkt gespeichert, sondern aus Zugangs- und Abgangsdaten berechnet werden. Es werden Bestandskennzahlen mit Bestandsveränderung und mit Zu- und Abgängen unterschieden, wobei auch ein zeitliches Bezugsmerkmal und mehrere sachliche Bezugsmerkmale definiert werden können. Die Währungsaggregation erfolgt nach der Standard- und Ausnahmeaggregation. InfoCubes bilden die zentrale Komponente für die Datenanalyse und -speicherung im SAP BW.

Die Umfrage umfasste neun teilweise unvollständig ausgefüllte Fragebögen. Nur drei Projekte konzentrierten sich auf Enterprise Data Warehousing mit dem Ziel einer einheitlichen Datenbasis für alle reportingrelevanten Daten im gesamten Unternehmen. Die restlichen sechs Projekte beschränkten sich auf bereichsspezifische Data Warehouses. Bemerkenswert ist, dass bei drei der befragten Unternehmen das Data Warehouse nicht dem Ideal eines 'Single Point of Truth' entspricht, was auf eine unzureichende Datenintegration hindeutet. Die Ergebnisse zeigen eine klare Tendenz zu bereichsspezifischen Lösungen anstatt einer vollständigen unternehmensweiten Datenintegration. Die geringe Anzahl der vollständig unternehmensweiten Projekte deutet auf Herausforderungen bei der Umsetzung von Enterprise Data Warehousing hin.

Nur fünf der Befragten nutzten ein Referenzmodell, und lediglich drei ein explizites Vorgehensmodell für die Datenmodellierung. Zwei Projekte, die ein Vorgehensmodell einsetzten, verwendeten auch ein Referenzmodell. Ein zwingender Zusammenhang zwischen der Nutzung beider Modelle lässt sich aufgrund der geringen Stichprobengröße nicht statistisch belegen. Die Datenmodellierung und -pflege wurde bei sechs Teilnehmern organisatorisch geregelt; auffällig ist, dass alle, die ein Referenzmodell einsetzten, auch eine organisatorische Regelung für die Datenmodellierung hatten. Dies deutet auf einen möglichen Zusammenhang hin, der jedoch aufgrund der geringen Datenmenge nicht abschließend bestätigt werden kann. Die fehlende systematische Anwendung von Referenz- und Vorgehensmodellen zeigt Verbesserungspotential in der Praxis.

Die Konsistenzsicherung erfolgte in den untersuchten Projekten durch verschiedene Methoden: technische Überprüfungen (Summen- und Plausibilitätskontrollen) und Berechtigungskonzepte (Änderungen nur durch autorisierte Personen). In einigen Fällen wurden unternehmensweite Definitionen für Merkmale und Kennzahlen festgelegt, und das Datenmodell wurde in Kooperation zwischen IT und Fachbereichen definiert. Ein Projekt setzte ein Qualitätssicherungsteam ein. Ein Projekt verwendete den SAP Business Content. Bei zwei Befragten war die Konsistenz nicht sichergestellt, ein weiteres Projekt pflegte das Datenmodell nur bei Software-Updates nach. Die Ergebnisse unterstreichen die Notwendigkeit einer klaren Verantwortlichkeit und systematischen Maßnahmen zur Sicherstellung der Datenkonsistenz.

Ein Mangel an durchgängigen Modellierungstools für alle drei Entwurfsebenen wird festgestellt und durch die Umfrageergebnisse bestätigt, da die meisten Befragten verschiedene Tools verwendeten. Die Arbeit schlägt die Verwendung von ADAPT als konzeptionelles Modell vor, welches dann über geeignete Transformationsschritte auf das logische Modell von Michael Hahne übertragen werden könnte. ADAPT wird aufgrund ähnlicher Symbole in der grafischen Darstellung und der Verfügbarkeit von Visio-Templates als geeignet erachtet. Die automatische Anlage von Datenstrukturen im BW mittels XML wird als idealer zukünftiger Ansatz genannt. Der Mangel an integrierten Tools und die Notwendigkeit einer effizienten Transformationslogik zwischen konzeptionellen und logischen Modellen werden als wichtige Punkte für zukünftige Verbesserungen in der Data Warehouse Modellierung hervorgehoben.