Mehrdimensionale Datenmodellierung

Der einleitende Abschnitt der Arbeit legt den Fokus auf die Bedeutung der semantischen und logischen Datenmodellierung im Kontext mehrdimensionaler Datenbanken, insbesondere für Data Warehouses. Er betont die Notwendigkeit einer klaren und effizienten Kommunikation zwischen Fachbereichen und IT-Experten während des Modellierungsprozesses. Die Vermeidung von Missverständnissen durch die Verwendung unterschiedlicher Vokabulare wird als entscheidend für den Erfolg des Projekts hervorgehoben. Ein intuitives und leicht verständliches Datenmodell, das sowohl für Fachkräfte als auch für DV-Laien nachvollziehbar ist, wird als zentrales Ziel genannt. Die Herausarbeitung relevanter Begriffe wie Kennzahlen und Dimensionen im Aufbau eines Data Warehouses sowie die Anpassung an die Bedürfnisse der Endanwender werden als essentielle Aufgaben betont. Die Arbeit erwähnt die Verwendung von Microsoft SQL Server 2005 Beta 2 zum Zeitpunkt ihrer Erstellung, wobei die Limitationen dieser Beta-Version bezüglich der Analysefunktionalitäten erwähnt werden. Die Bedeutung einer einfachen, aber dennoch vollständigen Modelldarstellung wird unterstrichen, ebenso wie die Vermeidung von Informationsverlusten während des Entwicklungsprozesses, um Analyseeinschränkungen zu verhindern. Der iterative Prozess der Datenmodellierung, beginnend mit der Anforderungsanalyse über das semantische und logische Modell bis zur physischen Implementierung, wird beschrieben. Die Arbeit kündigt ihren Schwerpunkt auf der semantischen und logischen Datenmodellierung mit besonderem Fokus auf Star- und Snowflake-Schemata an.

Dieser Abschnitt befasst sich eingehend mit der semantischen Datenmodellierung und ihrer Bedeutung für die Kommunikation zwischen IT und Fachbereichen. Die Notwendigkeit eines einheitlichen Vokabulars und einer gemeinsamen Interpretation der verwendeten Begriffe wird hervorgehoben, um Missverständnisse zu vermeiden. Das Kapitel beschreibt die semantische Modellierungsebene als die der realen Welt am nächsten liegende Ebene und unterstreicht die Bedeutung der klaren Zuordnung von Bedeutung zu Zeichen und Symbolen. Am Beispiel der Vorwahl 0711 wird die semantische Interpretation von scheinbar bedeutungslosen Daten verdeutlicht. Der Abschnitt betont die Rolle des Fachkonzepts als Grundlage für das semantische Datenmodell und beschreibt, wie semantische Datenmodelle relevante Objekte der realen Welt mit minimalem Informationsverlust abbilden. Die Bedeutung der Anwendersicht bei der Definition relevanter Kennzahlen, Entscheidungsobjekte und deren Zusammenhänge wird hervorgehoben, da das semantische Schema die Schnittstelle zu den Benutzern darstellt. Es wird betont, dass die Darstellung des Modells übersichtlich und nicht überfrachtet sein sollte, um die Verständlichkeit zu gewährleisten – der Grundsatz „Start small, think big“ wird zitiert. Der Prozess der semantischen Datenmodellierung wird als systemunabhängige Phase beschrieben, in der konzeptuelle Anforderungen im Vordergrund stehen und die spätere Datenbanktechnologie noch keine Rolle spielt. Die Bedeutung der Modellqualität und die Verwendung der Anwenderterminologie in dieser Phase werden hervorgehoben. Das Entity-Relationship-Modell (ERM) von Chen (1976) wird als häufig verwendete Methode für die semantische Datenmodellierung vorgestellt, wobei Entitäten, Attribute und Beziehungen als Kernkomponenten erläutert werden. Die Notwendigkeit einer verbesserten Diskussion zwischen der Informationsverarbeitung und den Fachabteilungen wird hervorgehoben. Es wird ein Modellierungsworkshop als bewährte Praxis für die gemeinsame Erstellung des semantischen Datenmodells durch Entwickler und Anwender vorgeschlagen.

Dieser Abschnitt konzentriert sich auf die logische Datenmodellierung und den Übergang vom semantischen zum logischen Datenmodell. Hierbei wird die enge Verbindung zum Kriterium der unterstützten Dimensionstypen und deren Attribute in einem Datenwürfel betont. Nicht nur die Unterstützung verschiedener Hierarchien, sondern auch der Erhalt der semantischen Information dieser Hierarchien auf der logischen Modellebene ist von Bedeutung. Die Notwendigkeit, die zugrundeliegende semantische Hierarchie auf der logischen Ebene erkennen zu können, wird unterstrichen. Die Anpassung des logischen Datenmodells an die Speicherstruktur der zu verwendenden Datenbank wird erläutert und der Auswahlprozess des Datenbankmanagementsystems in diesem Kontext beschrieben. Der Abschluss des Workshops mit der Fachabteilung wird als Voraussetzung für den Übergang zur technischen Modellierung genannt. Die Arbeit erläutert das Star-Schema als Standardmodell zur Modellierung mehrdimensionaler Strukturen in relationalen Datenbanken. Sie beschreibt die Speicherung von quantifizierenden Informationen (Bewegungsdaten) in der Faktentabelle und qualifizierenden Informationen (Stammdaten) in den Dimensionstabellen. Die Anordnung der Dimensionstabellen um die zentrale Faktentabelle wird als satellitenartig beschrieben. Die typischen Abfragemerkmale des Star-Schemas – Abfrage vieler Datensätze der Faktentabelle mit anschließendem Join – und die Bedeutung der Performanceoptimierung bei der Aggregation werden hervorgehoben. Das Snowflake-Schema wird als Variante des Star-Schemas vorgestellt, die durch Normalisierung großer Dimensionstabellen Redundanzen reduziert und somit den Speicherbedarf verringert. Der erhöhte Verwaltungsaufwand durch die erhöhte Verknüpfungstiefe wird jedoch als Nachteil erwähnt. Die Praxis des Partial Snowflake-Schemas, bei dem nur große Dimensionstabellen normalisiert werden, wird ebenfalls beschrieben.

In diesem Abschnitt werden multidimensionale Strukturen und Datenhaltungsmethoden für Data Warehouses erörtert. Es wird der Vorteil der multidimensionalen Speicherung in einer Matrix (Datenwürfel) hervorgehoben, der einen direkten Zugriff auf die Zellen ermöglicht und die Berechnung und Analyse entscheidungsrelevanter Daten erleichtert. Die Arbeit erklärt die Funktionsweise multidimensionaler Datenbanken, die auf der Annahme basieren, dass alle Kombinationen von Dimensionen vorkommen, und im Voraus entsprechende Matrizen erzeugen. Der direkte Zugriff und die Effizienz multidimensionaler Kalkulationen werden als Hauptvorteile hervorgehoben, während die derzeitige Speicherplatzbeschränkung auf etwa 20 Gigabyte erwähnt wird. Der Unterschied zwischen MOLAP (Multidimensional OLAP) und ROLAP (Relational OLAP) wird erläutert: MOLAP speichert Daten physikalisch multidimensional, während ROLAP relationale Datenbanken mit multidimensionalen Auswertungswerkzeugen kombiniert und eine OLAP-Engine als Schnittstelle nutzt. Die Vorteile von MOLAP hinsichtlich der Abfragegeschwindigkeit aufgrund des direkten Zugriffs auf Dimensionselemente und voraggregierte Hierarchien werden dargestellt. Im Gegensatz dazu wird ROLAP als geeignet für sehr große Datenmengen (Terabyte) beschrieben. Die Arbeit fasst die beiden gängigen Speichermöglichkeiten in Data Warehouse-Systemen – relationale und multidimensionale Datenhaltung – zusammen. Die direkte Adressierbarkeit der Zellen in der multidimensionalen Speicherung wird als entscheidender Vorteil für die Analyse entscheidungsrelevanter Daten betont.

Die semantische Modellierungsebene steht der realen Welt am nächsten und stellt daher besondere Anforderungen an die Modellierung. Symbole und Zeichen sollen Aussagen über Phänomene der realen Welt treffen und müssen daher an bestimmte Bedeutungen geknüpft sein, um für den Menschen interpretierbar zu werden. Ein Beispiel hierfür ist die Ziffernfolge 0711, die erst im Kontext der Telekommunikation ihre Bedeutung als Stuttgarter Vorwahl erhält. Das Fachkonzept bildet die Grundlage für das semantische Datenmodell, indem es die Bedeutung handelnder Personen, ihrer Verpflichtungen, Rollen, Handlungen und Mitteilungen beschreibt. Semantische Datenmodelle ermöglichen die Abbildung relevanter Objekte der realen Welt mit geringem Informationsverlust und bilden die Schnittstelle zu den Benutzern. Auf dieser Ebene müssen aus Anwendersicht relevante Kennzahlen, Entscheidungsobjekte und ihre Zusammenhänge definiert werden. Die Datenqualität ist bereits auf dieser Stufe zu berücksichtigen. Fehlerhafte oder unvollständige Daten aus operativen Systemen führen zu ungenauen Analysen. Die semantische Datenmodellierung ermöglicht eine verbesserte Kommunikation zwischen Fachbereichen und IT. Ein Modellierungsworkshop mit gemeinsamer Beteiligung von Entwicklern und Anwendern wird als bewährte Praxis zur Erstellung des semantischen Datenmodells empfohlen. Die systemunabhängige Modellierung in dieser Phase ermöglicht Flexibilität, jedoch ist eine vollständige Systemunabhängigkeit nicht immer praktikabel, da Tool-bedingte Einschränkungen auftreten können. Die Vorteile einer semantischen Datenmodellierung umfassen neben der zentralen Koordination eine Effizienzsteigerung bei der Systementwicklung und eine höhere Nutzerzufriedenheit durch verbesserte Kommunikation.

Die logische Modellierungsebene folgt auf die semantische und bildet den Übergang zum konkreten Datenbankdesign. Der Erhalt der Informationen aus dem semantischen Modell ist eng mit der Unterstützung verschiedener Dimensionstypen und deren Attributen in einem Datenwürfel verbunden. Die Unterstützung verschiedener Hierarchien und der Erhalt der semantischen Information dieser Hierarchien auf der logischen Ebene sind essentiell. Das logische Datenmodell muss an die Speicherstruktur des gewählten Datenbankmanagementsystems angepasst werden. Die Entscheidung für das Ziel-DBMS sollte nach Abschluss des Workshops mit der Fachabteilung erfolgen, um die Anwender von der technischen Modellierung und Implementierung freizuhalten. Die Anwender werden erst in der Testphase wieder aktiv eingebunden. Die Arbeit erwähnt die Darstellung eines multidimensionalen Datenwürfels (Cube) aus relationaler Sicht als um die Semantik der Dimensionen erweiterte Relation. Die implizite Verknüpfung des Würfels mit Klassifikationshierarchien erlaubt eine präzise Spezifikation von Operationen und eine intuitive Abbildung multidimensionaler auf relationale Schemata. Kennzahlen werden aus Fakten durch arithmetische Operationen gewonnen, was einen Unterschied zum klassischen Datenbankansatz darstellt. Das Kapitel beschreibt ein multidimensionales Entity/Relationship-Modell (mE/R-Modell) mit einer zentralen Faktenrelation und referenzierenden Dimensionstabellen, die durch Ellipsen weiter spezifiziert werden können. Die Informationsbedarfsanalyse muss sich auf die Erstellung benutzerfreundlicher und leicht verständlicher Datenbankstrukturen konzentrieren, welche optimierte Abfrage-Performance ermöglichen (Update-Performance ist nicht unbedingt im Vordergrund).

Die physische Modellierungsebene umfasst die tatsächliche Implementierung des Datenmodells in der gewählten Datenbank. Die Arbeit erläutert die zwei gängigen Speichermöglichkeiten für Data Warehouses: relationale und multidimensionale Datenhaltung. Bei der multidimensionalen Speicherung sind die Zellen des Datenwürfels direkt adressierbar, was die Berechnung und Analyse entscheidungsrelevanter Daten vereinfacht. Die Arbeit diskutiert verschiedene Speicheransätze für physisch multidimensionale Datenbanksysteme: den Hypercube-Ansatz (alle Daten in einer Matrix) und den Multicube-Ansatz (Daten in mehreren Matrizen). Der Hypercube-Ansatz leidet unter Performance-Einbußen bei dünn besetzten Matrizen, während der Multicube-Ansatz Nachteile bei der Abfragegeschwindigkeit durch die Verknüpfung der Matrizen aufweist. Multidimensionale Datenbankmanagementsysteme (MDBMS) werden als besonders gut für die Datenanalyse geeignet beschrieben, da sie einen schnellen Datenzugriff und effiziente mehrdimensionale Kalkulationen ermöglichen. Die Arbeit hebt die Performancevorteile von MDBMS bei Datenmanipulationen hervor, weist aber auf die derzeitige Speicherplatzbeschränkung von etwa 20 Gigabyte hin. Der Einsatz relationaler Datenbanken in Verbindung mit multidimensionalen Auswertungswerkzeugen wird als Relationales OLAP (ROLAP) bezeichnet. ROLAP benötigt eine dreistufige Rechnerarchitektur mit einer OLAP-Engine als Schnittstelle zwischen Datenbank und OLAP-Funktionen. Im Gegensatz dazu wird Multidimensionales OLAP (MOLAP) beschrieben, bei dem Daten bereits physikalisch multidimensional gespeichert sind und keine zusätzliche Aufbereitung vor dem Zugriff benötigt wird. MOLAP bietet sehr schnelle Antwortzeiten bei Abfragen und Kalkulationen.

Das Star-Schema wird als Standardmodell für die Modellierung mehrdimensionaler Strukturen in relationalen Datenbanken beschrieben. Es zeichnet sich durch seine Einfachheit und gute Verständlichkeit aus, was zu seiner weiten Verbreitung beiträgt. Im Star-Schema werden messbare Daten (Bewegungsdaten) in einer zentralen Faktentabelle gespeichert, während qualifizierende Informationen (Stammdaten) in separaten Dimensionstabellen abgelegt werden. Diese Dimensionstabellen sind satellitenartig um die Faktentabelle angeordnet. Die Beziehungen zwischen der Faktentabelle und den Dimensionstabellen werden über gemeinsame Schlüssel definiert. Die Abfrage von Daten im Star-Schema beinhaltet typischerweise die Abfrage vieler Datensätze aus der Faktentabelle, verbunden mit Joins zu den relevanten Dimensionstabellen, um eine relativ kleine Ergebnismenge zu erhalten. Die Performanceoptimierung bei der Aggregation von Daten im Star-Schema spielt aufgrund der typischen Abfragemuster eine wichtige Rolle. Die einfache Struktur und das damit verbundene leicht verständliche Modell ermöglichen eine intuitive Abbildung multidimensionaler auf relationale Schemata. Die Verwaltung des Schemas ist relativ einfach, was zu seiner Beliebtheit bei Administratoren beiträgt, die mit relationalen Datenbankmodellen vertraut sind. Allerdings können große Datenmengen in den Dimensionstabellen zu Ineffizienzen führen.

Das Snowflake-Schema wird als Weiterentwicklung des Star-Schemas vorgestellt, um die in den Dimensionstabellen auftretenden Redundanzen zu reduzieren. Im Snowflake-Schema werden einzelne, große Dimensionstabellen nach den Regeln der Datenbanknormalisierung weiter zerlegt. Dies führt zu mehreren, kleineren Dimensionstabellen, die über gemeinsame Schlüssel miteinander und mit der (unveränderten) Faktentabelle verknüpft sind. Die Normalisierung reduziert den Speicherbedarf im Vergleich zum Star-Schema, da Redundanzen vermieden werden. Allerdings entsteht durch die erhöhte Verknüpfungstiefe der Dimensionstabellen ein höherer Verwaltungsaufwand. Die Vorteile des Snowflake-Schemas liegen im reduzierten Speicherbedarf und teilweise schnelleren Zugriffszeiten auf die Daten. In der Praxis werden oft nur sehr große Dimensionstabellen normalisiert (Partial Snowflake-Schema). Die Wahl zwischen Star- und Snowflake-Schema hängt von verschiedenen Faktoren ab, darunter der Größe der Dimensionstabellen, der Häufigkeit von Datenänderungen, und der benötigten Abfrageperformance. Ein Abwägungsprozess zwischen Speicherplatzbedarf, Verwaltungsaufwand und Abfragegeschwindigkeit ist notwendig, um das optimale Schema für ein bestimmtes Data Warehouse zu finden.

Die Arbeit vergleicht das Star-Schema und das Snowflake-Schema als zwei gängige Ansätze zur Modellierung mehrdimensionaler Datenstrukturen in relationalen Datenbanken. Das Star-Schema zeichnet sich durch Einfachheit und gute Verständlichkeit aus, während das Snowflake-Schema durch Normalisierung Redundanzen reduziert, aber auch die Komplexität erhöht. Die Wahl des geeigneten Schemas hängt von den spezifischen Anforderungen des Data Warehouses ab, wie z.B. dem Umfang der Daten, der Häufigkeit von Updates und der benötigten Abfrageperformance. Das Star-Schema profitiert von dem vorhandenen Know-how der Datenbankadministratoren im Umgang mit relationalen Datenmodellen. Die typischen Abfragen im Star-Schema beinhalten Joins über viele Datensätze, was die Optimierung der Aggregatgenerierung besonders wichtig macht. Das Snowflake-Schema bietet Vorteile bezüglich des Speicherbedarfs und kann zu schnelleren Zugriffszeiten führen, birgt aber einen höheren Verwaltungsaufwand aufgrund der erhöhten Verknüpfungstiefe. Häufig wird in der Praxis ein Kompromiss in Form von Partial Snowflake-Schemata angewendet, bei denen nur besonders große Dimensionstabellen normalisiert werden. Die Entscheidung für das jeweilige Schema erfordert eine Abwägung zwischen Komplexität, Performance und Speicherplatzbedarf.

Der Abschnitt behandelt die multidimensionale Datenhaltung als eine zentrale Methode zur Speicherung von Daten in Data Warehouses. Die direkte Adressierbarkeit der Zellen in einem Datenwürfel (Cube) wird als entscheidender Vorteil hervorgehoben, da dies die Berechnung und Analyse entscheidungsrelevanter Daten erheblich vereinfacht und beschleunigt. Die multidimensionale Datenhaltung spielt eine Schlüsselrolle bei der Entwicklung innovativer Konzepte für Data Warehouses. Die Arbeit erläutert, dass multidimensionale Datenbanken auf der Annahme basieren, dass alle Kombinationen von Dimensionen vorkommen und daher im Voraus entsprechende Matrizen (Cubes) erstellt werden. Die Adresse jeder Zelle in der Matrix lässt sich durch einfache arithmetische Operationen berechnen. Die Wahl der Datenhaltungsform (denormalisiert vs. normalisiert) für einzelne Dimensionen hängt von verschiedenen Faktoren ab: Änderungsfrequenz der Daten, Anzahl der Dimensionselemente, Anzahl der Klassifikationsstufen innerhalb einer Dimension und die Materialisierung von Aggregaten. Die Arbeit beschreibt zwei gängige Speicheransätze in kommerziellen Systemen: den Hypercube-Ansatz (alle Daten in einer einzigen Matrix) und den Multicube-Ansatz (Daten in mehreren, miteinander verknüpften Matrizen). Der Hypercube-Ansatz kann zu Performance-Einbußen bei dünn besetzten Matrizen führen, während der Multicube-Ansatz Nachteile bei der Abfragegeschwindigkeit aufgrund der Verknüpfungen aufweist. Die Wahl des optimalen Ansatzes hängt stark von den spezifischen Anforderungen der Anwendung ab.

Der Abschnitt beschreibt Online Analytical Processing (OLAP) als eine Technologie zur Analyse multidimensionaler Daten. Die Arbeit unterscheidet zwischen zwei Hauptansätzen: MOLAP (Multidimensional OLAP) und ROLAP (Relational OLAP). Bei MOLAP werden die Daten bereits physikalisch in multidimensionalen Strukturen gespeichert, was einen direkten Zugriff auf Dimensionselemente und voraggregierte Hierarchien ermöglicht. Dies führt zu sehr schnellen Antwortzeiten bei Abfragen und Kalkulationen. Im Gegensatz dazu verwendet ROLAP relationale Datenbanken als Datenspeicher und kombiniert diese mit multidimensionalen Auswertungswerkzeugen. Für die effiziente Bearbeitung von Anfragen wird eine OLAP-Engine als Schnittstelle zwischen der relationalen Datenbank und den Analysewerkzeugen implementiert. Diese Engine transformiert die relationalen Daten in multidimensionale Strukturen. Relationale Datenbanken haben sich als Datenspeicher sehr großer Datenmengen (Terabyte) bewährt, während die Speicherkapazität multidimensionaler Datenbanken (MOLAP) derzeit auf etwa 20 Gigabyte begrenzt ist. Die Wahl zwischen MOLAP und ROLAP hängt von der Größe der Datenmenge und den Anforderungen an die Abfragegeschwindigkeit ab. MOLAP ist vorteilhaft bei kleineren Datenmengen, die schnell analysiert werden müssen, während ROLAP für sehr große Datenmengen geeignet ist, die mit relationalen Datenbankmanagementsystemen effektiv verwaltet werden können.

Der Abschnitt erläutert das Konzept der Multidimensionalität im Kontext von Managementunterstützungssystemen. Abfragen und Analysen erfolgen nahezu immer über mehrere Dimensionen, daher der Begriff Multidimensionalität. Ein Beispiel hierfür ist die Abfrage des Umsatzes eines bestimmten Produkts (z.B. Notebook von HP) in einer spezifischen Region (z.B. Nordamerika) für ein bestimmtes Jahr (z.B. 2004). Die Speicherung und Analyse solcher Daten erfordert multidimensionale Datenhaltung, die durch den dreidimensionalen Datenwürfel (Cube) visualisiert werden kann. Multidimensionale Datenanalyse und mehrdimensionale Abfragen bilden die Grundlage von Data Warehouses. Obwohl die Kanten eines Datenwürfels in der Praxis selten gleich lang sind, hat sich die Würfel-Visualisierung als intuitives Modell etabliert. Multidimensionalität wird definiert als die Art der logischen Anordnung quantitativer Größen, die durch mehrere sachliche Kriterien beschrieben werden. Die Arbeit beschreibt die multidimensionale Matrix als eine effiziente Speicherstruktur für multidimensionale Daten. Die Adresse jeder Zelle in der Matrix lässt sich durch eine einfache Formel unter Verwendung der dimensionalen Werte berechnen. Im Kontext von relationalen Datenbanken wird oft eine Denormalisierung vorgenommen, um die Abfrageperformance zu verbessern, da relationale Datenbanken normalerweise in der dritten Normalform verwaltet werden, um Redundanzen zu vermeiden.

Die Zeitdimension wird als besonders herausfordernder Aspekt in der Data-Warehouse-Modellierung beschrieben. Im Data Warehouse stehen alle Dimensionen in einer Beziehung zur Zeitdimension, daher haben Änderungen in anderen Dimensionen Auswirkungen auf die Zeitdimension. Die Arbeit betont die Notwendigkeit besonderer Modellierungsmethoden für die Zeitdimension aufgrund ihrer Dynamik und der sich ändernden Merkmale aller Dimensionen. Saisonale Einflüsse und Lebenszyklusmodelle erfordern eine Berücksichtigung der unterschiedlichen Dynamik der Datenwerte. Während in manchen Perioden ständig aktuelle Werte benötigt werden, kann eine Kennzahl außerhalb der Saison über Monate hinweg den gleichen Wert behalten. Oft wird die Zeitdimension in zwei getrennten Dimensionen modelliert: eine für die Jahre und eine weitere für Monate und Quartale, um die Verwaltung zu vereinfachen. Die Erweiterung um ein weiteres Jahr ist im Fall getrennter Dimensionen einfacher, da nur die Jahresdimension erweitert werden muss. Die Modellierung der Zeitdimension muss die unterschiedliche Dynamik der Datenwerte berücksichtigen, um eine korrekte und effiziente Analyse zu gewährleisten. Das Design der Zeitdimension beeinflusst direkt die Möglichkeiten der Datenanalyse und sollte daher sorgfältig geplant werden.

Der Abschnitt beschreibt verschiedene Methoden zur Modellierung der Zeitdimension in Data Warehouses. Die Arbeit erläutert, dass die vorhandene Dynamik durch sich ändernde Merkmale aller Dimensionen besondere Modellierungsmethoden für die Zeitdimension erfordert. Die enge Verknüpfung aller Dimensionen mit der Zeitdimension bedeutet, dass jede Änderung eine Auswirkung auf die Zeitdimension hat. Besonders bei saisonalen Dimensionen (saisonale Entwicklung, Lebenszyklusmodelle) muss die unterschiedliche Dynamik der Datenwerte in der Modellierung berücksichtigt werden. In manchen Perioden sind ständig aktuelle Werte erforderlich, während in anderen Perioden eine Kennzahl über einen längeren Zeitraum den gleichen Wert behalten kann. Eine gängige Methode ist die Aufteilung der Zeitdimension in zwei separate Dimensionen: eine für die Jahre und eine zweite für Monate und Quartale. Dieser Ansatz vereinfacht die Verwaltung der Zeitdimension, insbesondere bei der Erweiterung um neue Jahre. Die Arbeit betont die Notwendigkeit, die spezifische Dynamik der Datenwerte für verschiedene Dimensionen und Zeiträume zu berücksichtigen, um die Datenqualität und die Aussagekraft der Analysen zu gewährleisten. Ein flexibles und anpassungsfähiges Datenmodell ist erforderlich, um den sich ändernden Anforderungen an die Datenanalyse gerecht zu werden.

Der Abschnitt beschreibt kurz die Datenhaltung im SAP Business Information Warehouse (BW), das auf einer relationalen Datenbankarchitektur basiert und üblicherweise das Star-Schema zur Modellierung der mehrdimensionalen Daten verwendet. Es wird erwähnt, dass das SAP BW ein erweitertes Star-Schema verwendet, das komplexer als das klassische Star-Schema ist. Das SAP BW zeichnet sich durch eine strikte Trennung von Stammdaten und Bewegungsdaten aus. Diese Trennung ermöglicht die übergreifende Verwendung von Stammdaten in mehreren Info-Cubes, während Bewegungsdaten nur einem einzelnen Info-Cube zugeordnet sind. Die Dimensionstabellen im erweiterten Star-Schema des SAP BW bilden die Verbindung zwischen der Faktentabelle und den Stammdatentabellen. Die Modellierung der Zeitdimension im SAP BW folgt im Wesentlichen den gleichen Prinzipien wie in anderen Data Warehouse-Systemen. Allerdings kann die Integration der Zeitdimension in das erweiterte Star-Schema des SAP BW aufgrund der spezifischen Architektur des Systems zusätzliche Komplexität mit sich bringen. Die Arbeit erwähnt die Arbeit von Michael Hahne zur grafischen Darstellung des erweiterten Star-Schemas im SAP BW mithilfe einer Schablonen-Datei in Microsoft Visio.

Der Abschnitt beschreibt die Datenhaltung im SAP Business Information Warehouse (BW). Im Gegensatz zu anderen Data Warehouse-Systemen, die verschiedene Modellierungsansätze verwenden könnten, basiert die Datenhaltung im SAP BW auf einer relationalen Datenbankarchitektur. Die Modellierung der mehrdimensionalen Datenhaltung erfolgt üblicherweise mit dem bekannten Star-Schema. Allerdings existieren spezifische Erweiterungen, die zu einem 'erweiterten Star-Schema' im SAP BW führen. Dieses erweiterte Schema ist deutlich komplexer als das klassische Star-Schema. Ein wichtiges Merkmal des SAP BW ist die strikte Trennung von Stammdaten und Bewegungsdaten. Stammdaten werden Info-Cube-übergreifend verwendet, während Bewegungsdaten nur einem einzelnen Info-Cube zugeordnet sind. Die Dimensionstabellen fungieren als Verbindungselemente zwischen der Faktentabelle und den Stammdatentabellen. Diese Architektur ermöglicht eine effiziente Datenverwaltung und -analyse, jedoch mit erhöhter Komplexität im Vergleich zum einfachen Star-Schema. Die spezifischen Erweiterungen des Star-Schemas im SAP BW sind auf die besondere Architektur und die Anforderungen des Systems zugeschnitten.

Im Kontext des SAP Business Information Warehouse (BW) wird ein erweitertes Star-Schema verwendet, das vom klassischen Star-Schema abweicht. Dieses erweiterte Schema integriert zusätzliche Tabellen und Beziehungen, um den spezifischen Anforderungen des SAP BW gerecht zu werden. Die Dimensionstabellen fungieren als Verbindungsknoten zwischen der Faktentabelle und den eingeführten Stammdatentabellen. Durch diese zusätzliche Struktur wird das Modell deutlich komplexer als das klassische Star-Schema. Die strikte Trennung von Stammdaten und Bewegungsdaten ist ein besonderes Merkmal des SAP BW. Stammdaten sind Info-Cube-übergreifend verwendbar, während Bewegungsdaten nur innerhalb eines spezifischen Info-Cubes zugänglich sind. Diese strikte Trennung verbessert die Datenverwaltung und ermöglicht die Wiederverwendung von Stammdaten, was die Effizienz und Konsistenz des gesamten Systems erhöht. Die Komplexität des erweiterten Star-Schemas im SAP BW erfordert ein tiefes Verständnis der SAP BW-Architektur und -Funktionalitäten. Die Arbeit erwähnt die Studien von Michael Hahne, der eine Schablonen-Datei auf Basis von Microsoft Visio entwickelt hat, um die grafische Darstellung des erweiterten Star-Schemas zu vereinfachen. Diese Schablone zielt darauf ab, die Modellierung und Dokumentation des komplexen Schemas zu vereinfachen.

Der Abschnitt vergleicht das erweiterte Star-Schema im SAP Business Information Warehouse mit dem klassischen Star-Schema. Das erweiterte Schema im SAP BW ist deutlich komplexer als das klassische Star-Schema, aufgrund der zusätzlichen Tabellen und Beziehungen für Stammdaten und die strikte Trennung von Stamm- und Bewegungsdaten. Die Dimensionstabellen übernehmen eine zentrale Rolle als Verbindungselemente zwischen Faktentabelle und Stammdatentabellen. Die Stammdaten werden systemweit wiederverwendet, während Bewegungsdaten nur innerhalb des jeweiligen Info-Cubes verfügbar sind. Diese Architektur des SAP BW erfordert spezifisches Wissen und Verständnis der Systemarchitektur und Datenstrukturen. Der Abschnitt erwähnt die Arbeit von Michael Hahne zur grafischen Darstellung des erweiterten Star-Schemas mit Microsoft Visio. Diese Schablone soll die Modellierung und Dokumentation vereinfachen. Die Arbeit legt nahe, dass eine einheitliche und standardisierte Modellierungsmethode für logische Ebenen im Kontext multidimensionaler Datenbanken, ähnlich dem Star-Schema für relationale Systeme, noch fehlt. Die Komplexität des erweiterten Star-Schemas im SAP BW zeigt die Notwendigkeit effizienter Werkzeuge und Methoden für die Modellierung und Verwaltung komplexer Data-Warehouse-Systeme auf.