DeltaMaster ist ein in vielerlei Hinsicht sprichwörtlich ausgezeichnetes Business-Intelligence-Frontend: Sein analytischer Funktionsumfang, die elegante Bedienoberfläche, State-of-the-Art-Visualisierungstechniken und vieles mehr sprechen für unser Produkt.

Um seine Stärken optimal ausspielen zu können, sind einige Aspekte im zugrundeliegenden OLAP-Datenmodell zu berücksichtigen. Es ist zu betonen, dass diese keineswegs proprietärer Natur sind, sondern mit den Empfehlungen der einschlägigen Fachliteratur (z.B. Kimball, Webb, siehe auch am Ende dieses Papiers) einhergehen.

Zu unterscheiden sind zwingende Voraussetzungen von optionalen bzw. wünschenswerten Charakteristika für den Direktzugriff auf bestehende OLAP-Systeme.

Obligatorische Modellierungsmerkmale:

• Alle zu analysierenden Daten sind in einer gemeinsamen Datenbank verfügbar und je nach Technologie in einem gemeinsamen (Hyper-)Cube zusammengefasst (Microsoft Analysis Services 2005/2008/2012: ein Cube mit beliebiger Anzahl MeasureGroups). DeltaMaster nutzt zum Zugriff den ADOMD.NET- oder OLEDB-Standard und analysiert innerhalb einer Sitzung normalerweise einen einzigen Cube. Mehrere Cubes innerhalb derselben Datenbank können der Sitzung hinzugefügt werden, es sind jedoch keine logischen Verknüpfungen im Frontend zulässig (cubeübergreifende Cockpits/Analysen oder Formeln).
• Es existiert genau eine Zeitdimension. Mehrere Zeitbezüge werden mit Hilfe einer Hilfsdimension dargestellt, d.h. die Daten werden in diesem Fall transponiert und teilweise dupliziert.
• Wo immer möglich, sollten Hierarchien anstelle flacher Listen modelliert werden. Bei strukturlosen Merkmalen empfiehlt es sich, Hilfsebenen z.B. aus Anfangsbuchstaben etc. abzuleiten und so Pseudo-Hierarchien zu bilden.

Optionale Modellierungsmerkmale:

• Es wird empfohlen, eine oder mehrere freie Hilfsdimension(-en) für Zeitberechnungen bereitzustellen. Microsoft nennt diesen Ansatz TimeUtility, Webb spricht von DateCalculations. Hintergrund ist in jedem Fall das Bestreben, die Duplikation von Kennzahlen zu den obigen Zwecken zu vermeiden. Gängige Praxis im Hause Bissantz ist die Trennung in die Dimensionen
  • “Periodenansicht” (für Zeitsprünge wie Vorperiode, Vorjahr und die Berechnung der jeweiligen Abweichungen)
  • “Kumulation” (zur Bildung von Zeitreihen für YTD/MTD, MAT etc.)
• Zur Trennung von Szenarien wie z.B. Ist- und Planwerten wird die Verwendung einer weiteren separaten Dimension (z.B. “Wertart”) empfohlen.

Allgemeine Hinweise:

• Die Modellierung hierarchischer Kennzahlenstrukturen (z.B. G&V-Schema) als Measures oder Dimension ist grundsätzlich wahlfrei.
• Parallele Hierarchien innerhalb einer Dimension sind erlaubt.
• Multiple Strukturen innerhalb einer Hierarchie sind erlaubt, jedoch meist nicht sinnvoll. Ein Beispiel ist die nach unserer Erfahrung vor allem in Alea-, TM1- und Essbase-Systemen gelegentlich praktizierte Modellierung der Dimension Zeit mit den Zweigen “Periodenwerte” und “YTD”. Diese Alternative steht im Widerspruch zur weitgehend ebenenbasierten Logik von MDX. Im Ergebnis sehen beispielsweise Sparklines mitunter unschön aus, weil einzelne Objekte (z.B. die Ebene Monat) Werte unterschiedlicher Semantik (nicht kumuliert und kumuliert) enthalten.
• Unbalancierte Hierarchien (auch bekannt als asymmetrische Dimensionen oder Parent-Child-Strukturen) sind erlaubt; viele Operationen und Bedienkonzepte sind jedoch ebenenbasiert und in solchen Strukturen schwieriger zu handhaben. Wichtig: Analyseergebnisse über “unvollständige” Ebenen sind in DeltaMaster dennoch stets inhaltlich korrekt!
• In der Regel haben alle Dimensionen ein All-Element, das Gesamtwerte ausweist; übliche Ausnahmen, in denen das Summenelement idealerweise auch zu entfernen ist, sind beispielsweise:
  • Wertarten (Plan vs. Ist)
  • Währungen (Lokal- vs. Konzernwährung)
  • Einheiten (Stück, kg, Meter, Liter, EUR etc.)

Eigenschaften spezifisch in Microsoft Analysis Services:

• Es wird empfohlen, möglichst keine “Manipulationen” in der DataSourceView in Form von Named Calculations und/oder Named Queries vorzunehmen, da ansonsten kein SQL-Durchgriff möglich ist, denn dieser erzeugt das Mapping zwischen OLAP-Cube und relationalen Quelldaten dynamisch auf dieser Basis.
• Jedwede Duplizität von Merkmalen sollte vermieden werden: Beispielsweise benötigen mehrere Hierarchien innerhalb einer Dimension, die in DeltaMaster als separate Dimensionen dargestellt werden und damit kombiniert (d.h. kreuztabelliert und verschachtelt) werden können, nicht jeweils das Schlüsselattribut als unterste Ebene.
• Zur Performanceoptimierung sind bei Bedarf Aggregationen und Partitionen zu verwenden.

Gerne besprechen wir mit Ihnen Details zu den oben genannten Aspekten mündlich. Rufen Sie uns einfach an oder senden Sie uns eine E-Mail!

Literaturempfehlungen

Chris Webb, Alberto Ferrari and Marco Russo: Expert Cube Development with Microsoft SQL Server 2008 Analysis Services, Packt Publishing 2009

Edgar F. Codd, S. B. Codd, C. T. Salley: Providing OLAP to User-Analysts: An IT Mandate. Codd & Associates, Ann Arbor/Michigan 1993

Kimball, R. (1996): The Data Warehouse Toolkit – Practical Techniques for Building Dimensional Data Warehouses, New York et al. (John Wiley & Sons) 1996

Mucksch, H.; Behme, W. (Hrsg., 1997): Das Data-Warehouse-Konzept – Architektur – Datenmodelle – Anwendungen, 2. Aufl., Wiesbaden (Gabler) 1997