Dimensionen ergeben sich aus den relevanten Eigenschaften einer Information. So ist eine monatliche Gewinn- und Verlustrechnung (GuV) bereits zweidimensional: die Buchungsdaten und eine zeitliche Dimension. Läßt sich die GuV außerdem noch hinsichtlich verschiedener Geschäftsbereiche und gebietsbezogen betrachten, ergibt sich daraus eine dritte und vierte Dimension. Grundsätzlich sollten die Dimensionen so gewählt werden, daß sie möglichst viele Kombinationen erwarten lassen.

Zielt die Analyse etwa historischer Daten auf Erfolgsfaktoren oder auf interessante Abweichungen ab, spricht man von Data-Slicing. Beim Data-Dicing werden die so erzielten Querschnitte aus unterschiedlichen Perspektiven betrachtet. Benötigt der Anwender Details für seine Analyse, muß er von den konsolidierten Daten zu den Einzelheiten vorstoßen können. Den Vorgang bezeichnet man als Drill-down. Den Manager interessiert das Grundsätzliche, der Controller aber will Details.

Damit die verschiedenen Unternehmensbereiche unterschiedliche Interessen befriedigen können, die Ergebnisse sich jedoch nicht widersprechen, schaffen sich viele Unternehmen eine universelle Datenbasis, ein Data-Warehouse, oder abteilungs- und aufgabenbezogene Data-Marts an. Sie enthalten konsolidierte Daten aus unterschiedlichen Unternehmensapplikationen.

Von einer Abteilung zur nächsten unterscheiden sich die Geschäftsmodelle manchmal so stark, daß verschiedene Data-Marts mit unterschiedlichen Ausprägungen erforderlich sind. So kann das Controlling ein Geschäftsmodell vielleicht mit vier Dimensionen bestimmen: Organisationseinheiten, Zeit, Kostenarten und Szenarien. Das Modell für den Vertrieb ist aber sechsdimensional: Produkte, Kunden, Regionen, Absatzkanal, Konten, Zeit und Szenarien.

Synergien können sich trotzdem ergeben. Dafür müssen Data-Marts gebündelt werden. Dabei machen eingeschränkte, abteilungsorientierte Sichtweisen der prozeßorientierten, funktionsübergreifenden Sichtweise Platz. In homogenen DV-Systemen lassen sich die Data-Marts auf der Basis von OLTP-Systemen (OLTP = Online Transaction Processing) koppeln. Bei different strukturierten Datenquellen bedarf es einer eigenen Schicht, die es erlaubt, die Daten abzugleichen.

Dabei braucht es mehrere Schritte, um die aktuellen operativen Daten in die applikationsneutrale Zwischenschicht zu überführen. Es reicht nicht, die Daten lediglich zu replizieren, sie müssen auch auf Konsistenz und Vollständigkeit überprüft werden.

Die Anwender entscheiden, welche Daten sie benötigen, wie oft diese zu aktualisieren, zu sichern und zu überprüfen sind. Die Transformation der Daten umfaßt demnach eine Restrukturierung, Neudefinition, Neuberechnung und Zusammenfassung von Datenfeldern. Dabei ist es hilfreich, die entsprechenden Kriterien und Regeln als Metadaten in Datenkatalogen oder Programmbibliotheken festzuhalten.

Um Mehrdimensionalität abbilden zu können, müssen die weitverbreiteten relationalen Datenbank-Management-Systeme mit Hilfe von sogenannten Star- oder Snowflake-Schemata verändert werden. Beide Konzepte haben eine Denormalisierung der Daten zur Folge und müssen manuell eingerichtet werden.

Das Sternschema reduziert in der Regel die Komplexität der Datenmodelle und die Anzahl der Verknüpfungen (Joins) durch den Aufbau von Fakt- und Dimensionstabellen. Dabei sind beschreibende Dimensionstabellen sternförmig um eine zentrale, numerische Fakttabelle angeordnet. In ihr stehen die Transaktionen.

Das Schneeballsystem entsteht, wenn die Dimensionstabellen Schlüsselattribute erhalten. Mit ihrer Hilfe lassen sich die Dimensions- sowohl mit Attributstabellen verknüpfen, in denen die beschreibenden Informationen über Dimensionselemente stehen, als auch mit der Fakttabelle. Die Schlüssel verkürzen die Zugriffszeit, machen das System aber komplexer.

Performance-Probleme können bei beiden Schemata auftreten. Eine sogenannte SQL-Engine, die zwischen Endbenutzer und den abgeleiteten Daten implementiert wird, hilft dabei, Leistungseinbußen zu vermeiden. Für die Engine kommen mehrere Optimierungsmechanismen in Frage: Stichproben (Sampling), Ermittlung des kartesischen Produktes über die Dimensionstabellen, gleichzeitiges Verknüpfen von mehr als zwei Tabellen (Multiple Joins) und Bitmap-Indizierung.

Im Gegensatz zu relationalen sind mehrdimensionale Datenbanken für die Kombination verschiedener Sichten und Dimensionen konzipiert. Anders als in relationalen Datenbank-Management-Systemen werden lediglich aggregierte Werte gespeichert.

Die wichtigste Strukturkomponente ist eine mehrdimensionale Zell-Matrix oder ein Array-Würfel, der durch Dimensionen definiert ist. Der Inhalt der Zellen eines Datenwürfels entspricht quantitativen Werten. Die Indizes, die getrennt von den Daten gespeichert sind und die Dimensionen verknüpfen, werden beim Aufbau des Geschäftsmodells automatisch angelegt.

Multidimensionalen Datensystemen stehen zur Berechnung von Kennzahlen und Strukturen folgende Berechnungsarten zur Verfügung: Aggregation, Matrix- und Cross-Dimensional-Kalkulation, Aware-Funktionen sowie die prozedurale Kalkulation. Unter Aggregationen versteht man einfaches, vertikales Summieren von Daten. Tage werden zu Wochen, Wochen zu Monaten oder einzelne Kunden zu Kundengruppen und Kundengruppen zu Kundenkategorien addiert.

Matrix-Kalkulationen erlauben komplexere Verknüpfungen, beispielsweise für die Berechnung von absoluten und prozentualen Abweichungen. In Cross-Dimensional-Berechnungen zum Beispiel von Produkt- und Marktanteilen greifen die Anwender auf beliebige Werte aus dem kompletten Würfel zu. Für Prognosen, Statistiken und Zeitreihen eignen sich insbesondere Aware-Funktionen. Den prozeduralen Kalkulationen liegen Unternehmensregeln zugrunde..

Roland Markowski ist Geschäftsführer der Arbor Software GmbH, Hamburg.