Dr. Nicolas Bissantz entwirft seit mehr als zwölf Jahren Software für analytische Anwendungen und ist Gründer und geschäftsführender Gesellschafter von Bissantz & Company. Sein Partner, Dipl.-Inf. Michael Westphal entwickelte bereits 1993 eine OLAP-Applikation. Den Begriff, geschweige denn kommerzielle OLAP-Produkte gab es damals noch nicht. Michael Westphal leitet die Projektmannschaft von Bissantz & Company und modelliert täglich relationale und OLAP-Anwendungen. Dipl.-Inf. Guido Schrage ist Chefentwickler des Unternehmens. Er entwirft und programmiert Standardsoftware für OLAP-Anwendungen.
Bissantz Als wir anfingen, wunderten wir uns oft über die OLAP-Modelle, die uns bei Kunden begegneten. Von der symmetrischen Vorstellung eines Datenwürfels mit voneinander unabhängigen Achsen war das weit entfernt. Das waren ziemlich windschiefe Hütten.
Schrage Stimmt, in der Regel war für jeden Standardbericht, den man abbilden wollte, ein eigener Teilwürfel gebildet worden. Der wiederum war das Abbild einer relationalen Tabelle. So hatte man z.B. einen Würfel für Produkte und Jahre und einen Würfel für Kunden und Jahre. Was fehlte, war sich vorab Gedanken darüber zu machen, dass Kunden und Produkte über Aufträge und die Zeitachse miteinander verbunden sind und sich damit in einem Würfel darstellen und analytisch fassen lassen.
Westphal Ja, ich erinnere mich. Als wir mit DeltaMaster starteten, hieß es oft: ‚Da müsst ihr hin, die haben eine OLAP-Datenbank mit 20 Würfeln’. Bei näherer Betrachtung stellte sich dann heraus, das oft kein einziger davon ein analytischer, respektive analysetauglicher OLAP-Würfel war. Das ist aber eine ganze Weile her. Inzwischen hat sich die mehrdimensionale Denkweise im Controlling etabliert.
Bissantz Ich glaube, die Verfahren, die wir damals entwickelten, nötigten uns ganz von selbst ein Verständnis für mehrdimensionale Datenbanken auf. Wer nur seine vorhandenen Berichte abgebildet haben wollte, verpasste erstmal die Pointe von OLAP.
Westphal Unsere Navigationsverfahren ebenso wie PowerSearch, suchen nach Auffälligkeiten über alle Dimensionen hinweg. Wenn es nur zwei Dimensionen gibt, ist das fad, also achteten wir peinlich genau darauf, alle interessanten Auswertungsdimensionen (Kunden, Produkte, Regionen, Händler, Vertrieb usw.) auch als Achsen im OLAP-Modell abzubilden.
Schrage Übrigens auch erst einmal unabhängig von OLAP. Das kam erst später. Betrex, der Urvater von DeltaMaster war mehrdimensional, ohne OLAP zu sein. Als wir dann auf kommerzielles OLAP mit für damalige Verhältnisse unglaublicher Performance zugreifen konnten, waren wir ziemlich aus dem Häuschen.
Westphal Betrex konnte zunächst nur 8.000 Datensätze verarbeiten. Das hatte auch ein bisschen mit dem Betriebssystem zu tun. Mit dem ersten 32-Bit-Windows waren es dann 40.000 und die erste Version von DeltaMaster hatte dann eigentlich keine relevanten Beschränkungen mehr, da wir das Datenhandling der OLAP-Datenbank überließen und der Client selbst dann nicht mehr der Flaschenhals war.
Bissantz Es gab noch andere Probleme, die in schöner Regelmäßigkeit auftraten. Wie war das noch mal mit der Zeitdimension und den Attributen?
Westphal Mit der Zeitdimension, Zeitanalysedimension und der Wertartdimension lassen sich viele Dinge automatisch anstellen. So kann man automatisch kumulierte oder Abweichungswerte anlegen. Dazu muss das System die Dimensionen aber kennen oder erkennen. In MIS Alea gab es aber keine separaten Dimensionen für Zeit, Analysewerte oder Wertarten. In Microsoft Analysis Services gab es dann die Measure-Dimension, aber das Produkt war 1996 ja noch nicht auf dem Markt. Oft stießen wir auch auf Würfel mit getrennter Zeitdimension, weil sich sonst Berichte mit Jahren auf der einen und Monaten auf der anderen Achse nicht darstellen ließen, was häufig gefordert wurde. Man kann auch heute noch darüber streiten.
Schrage Ich hab da was in Planung…
Westphal Mit den Attributen war es so: Eine Abhängigkeit wie etwa die Farbe als Eigenschaft eines Produktes, musste als Dimension modelliert sein, um damit Auswertungen machen zu können. In relationalen Datenbanken wäre die Farbe aber ein Attribut. Attribute gab es sehr früh auch in OLAP, sie waren aber nicht als Auswertekriterium verwendbar. Das wiederum veranlasste uns zum Konzept der virtuellen Hierarchie. Für die ABC-Analyse hatten wir es ohnehin schon, also übertrugen wir es jetzt auf Dimensionsattribute. Das passiert alles in einer eigenen Schicht. Wir lesen die Attribute aus und bilden daraus eine Hierarchie, die sich genauso analysieren lässt wie „echte“ Dimensionen.
Schrage Seit dem SQL Server 2000 von Microsoft werden Attributdimensionen auch serverseitig unterstützt. In der Version 2005 wurde das nochmals verbessert. Man hat inzwischen also eine stärkere Mischung von Eigenschaften einer OLAP- und einer relationalen DB.
Bissantz Kommen wir jetzt endlich einer Datenbank näher, die relational und OLAP ist? Ich warte darauf schon lange. Aus relationaler Sicht ist OLAP ein 10-Jahres-Workaround.
Schrage Mag sein, aber die Fortschritte sind zunächst gewaltig gewesen. Wir nehmen OLAP immer noch aus Performancegründen und weil OLAP-spezifische Techniken kaum in relationalen Front-ends zu finden sind (Slice and dice, Drill etc.).
Westphal Was OLAP immer noch ausmacht, ist eine Form der Modellierung, die näher an der späteren Analyse ist. Pivotisieren ist ins OLAP schon eingebaut. In reinem SQL bemüht man dazu vergleichsweise umständliche Skripten. Das gleiche gilt für dimensionsübergreifende berechnete Werte, z.B. die kumulierte Abweichung zum Vorjahr. In OLAP sehr einfach, in SQL ziemlich umständlich. Dem Anwender kann es aber egal sein, er muss nur wissen, was er später kreuztabellieren will, daraus ergeben sich die nötigen Dimensionen und Hierarchien.
Bissantz Fasziniert hat mich, dass wir auch die Deckungsbeitragsflussrechnung mit OLAP-Bordmitteln, sprich MDX, der Standardabfragesprache für mehrdimensionale Datenbanken, abbilden konnten. Allerdings ist die Formel auch ziemlich lang. Zehn Seiten, wenn ich mich nicht irre.
Westphal Das Statement für die wirklich komplexe Flussrechnung besteht aus reichlich Definitionen von berechneten Werten, die dann in einer schnellen Abfrage gemeinsam von der OLAP-Datenbank bereitgestellt werden. Die kumulierte Abweichung zum Vorjahr wäre in MDX ein Einzeiler, in SQL hingegen ein komplexer und damit laufzeitintensiver Befehl mit mehreren Unterabfragen.
Schrage In DeltaMaster haben wir eine Schicht für benutzerdefinierte Berechnungen, damit der Controller nicht jedes Mal die IT-Abteilung braucht, wenn er das Modell ein bisschen nachjustieren will. Diese Schicht arbeitet inzwischen durchgängig mit MDX. Das ist deutlich performanter und eleganter, als es in SQL je sein könnte.
Bissantz Trotzdem erwarten wir doch, dass Hersteller wie Oracle die Vorteile relationaler und mehrdimensionaler Datenbanken auf längere Sicht wieder zusammenbringen. Augenscheinlich wird daran bei Oracle gearbeitet.
Schrage Oracle bietet seit kurzem eine MDX-ähnliche Logik in SQL für schnelle Abfragen gegen relationale Datenbanken an. Und im SQL Server 2005 sehen wir ebenfalls Tendenzen, dass OLAP und relationale Datenbanken stärker zusammenwachsen. Zum Beispiel muss jetzt jede Dimension einen eindeutigen Primärschlüssel haben, wodurch Auswertungsfehler durch uneindeutige Daten ausgeschlossen werden.
Bissantz Vor einiger Zeit unterschieden sich die diversen OLAP-Datenbanken noch sehr deutlich in ihrer Eignung für Planungsaufgaben. Eine besondere Rolle spielt dabei die Fähigkeit, geänderte Daten schnell in die Datenbank zurückschreiben zu können, um anschließend gleich mit geänderten Zahlen weiterzuarbeiten. Andererseits haben wir Planungskunden für alle Plattformen, die wir unterstützen, das scheint also mal wieder heißer gekocht, als gegessen zu werden.
Schrage Realtime-Datenbanken wie TM1 oder MIS Alea schreiben schneller, das heißt aber nicht, dass die Analysis Services deswegen langsam sind. Die Rückschreibtabelle wird getrennt vom Würfel gehalten und die Datenbank sorgt dann selbst dafür, dass die Rückschreibtabelle eingelesen wird.
Westphal Diese Trennung hat den Vorteil, dass man die Plandaten relational sichern und relational weiterverarbeiten kann, z.B. wenn sie zurück in die operativen Systeme sollen. Für mich spielt die Musik aber nach wie vor am Front-end für die Planung. Intelligente Eingabelogiken wie die Fixierung von Werten beim so genannten ‚Splashen’, die automatische ‚Weiterleitung’ der Eingabe, oder die Eingabe auf berechneten Elementen (z.B. Preis oder Umsatz) bietet noch keine OLAP-Datenbank. Das machen wir immer noch im Front-end. Hintergrund: Egal ob ich die Menge oder den Preis oder sogar nur den Durchschnittspreis auf aggregierter Ebene ändere, die Ergebnisse werden mathematisch und kaufmännisch sauber durchgerechnet. In Excel wäre das ohne Makroprogrammierung völlig undenkbar.
Bissantz Obwohl sich viel getan hat, vertrauen wir also immer noch auf sehr viel Logik im Front-end. Mir fällt dazu auch die Multilingualität ein, die uns ganz schön Arbeit gekostet hat.
Schrage Multilingualität wird von Analysis Services 2005 gut unterstützt. Volle Multilingualität geht aber über mehrsprachige Daten weit hinaus. Dimensionen, Ebenen und Kennzahlen sind eben nur ein kleiner Teil der Applikation. Soll alles mehrsprachig sein, also auch Berichtsnamen, Namen von selbst berechneten Werten, Kommentare usw., natürlich auch die Bedienung, dann gehört das ganze doch wieder ins Front-end.
Westphal Wir gehen in einigen Dingen ja auch deswegen einen eigenen Weg, weil wir mehrere OLAP-Datenbanken unterstützen und manche davon wichtige Features überhaupt nicht anbieten. Und wir müssen nicht warten bis Microsoft dieses oder jenes tut. Multilingualität haben wir seit Jahren drin. Aktuell haben wir auch in der Planung deutlich mehr an Rückschreibelogik im Front-end, als der SQL-Server bietet.
Schrage Zeitanalyseelemente wie YTD und rollierende Durchschnitte, prozentuale Vorjahresabweichungen etc. kann man jetzt auch in AS 2005 anlegen. Wir unterstützten das schon länger und sind immer noch ein wenig weiter, wir sind flexibler, die Formeln funktionieren auch bei Multiselektion, also dann, wenn man einen Doppelmonat betrachtet.
Bissantz Applikationen mit ihren offensichtlichen und weniger offensichtlichen Bindungen an Dateninhalte zementieren das darunter liegende Datenmodell. Darin unterscheiden sich relationale und OLAP-Datenbanken nicht voneinander. Was tun wir, um ohne Änderung der Datenbank auf der Ebene der Applikation das gedankliche Modell, das in den Daten steckt, an aktuelle Fragestellungen anzupassen?
Schrage Das Hinzufügen weiterer Würfel zur Laufzeit ist eine erste Hilfe. Inzwischen können das andere auch. Mehrere Cubes legt man übrigens aus denselben Gründen an, aus denen man auch mehrere Tabellen in Datenbanken anlegt: weil die Daten inhaltlich nicht zusammen passen. Beispiel: Währungsumrechnung im einen und Rechnungsdaten in einem anderen Würfel. Die meisten OLAP-Datenbanken verknüpfen die Würfel über einen virtuellen gemeinsamen Würfel, den das Front-end wie einen einzigen Würfel ansprechen kann. Alternativ kann das Front-end mehrere Würfel zusammenbringen. Dabei gelten die gleichen Voraussetzungen.
Bissantz Wo finden wir derzeit am meisten Potenzial für weitere Beschleunigung?
Westphal Die Bestimmung der Dimensionalität der vorliegenden Informationen und damit die Konzeption der OLAP-Würfel ist immer noch ein sehr wichtiger Teil eines Projekts. Dies unterscheidet sich allerdings nicht sehr vom sauberen Aufbau einer relationalen Datenbank. Generell ist es für viele Anwender wichtig, zwischendurch das entstehende Modell real im DeltaMaster zu sehen. Dadurch hat man schon mehrere Zyklen bis das endgültige Modell steht. Das ist transparent, kostet aber Zeit.
Bissantz Mehrere Zyklen? Implementiert man dabei nicht jedes Mal den ETL-Prozess neu, der ja immer noch den größten Teil der Projektressourcen verschlingt?
Westphal Ja, aber wenn man sich den ETL-Prozess genau ansieht, ist das ja größtenteils Fleißarbeit, die ich gerne der Maschine überlasse, daher haben wir vor zwei Jahren angefangen, unser Projekt- und Modellierungswissen in Software zu packen. Wir definieren zunächst das OLAP-Modell und ordnen dann die Basisdaten (Rohdaten bzw. importierte operative Daten) den Dimensionen und Fakten bzw. Würfeln zu.
Aus diesen Informationen generieren wir dann automatisch das relationale Schema, Datenprüfroutinen, den ETL-Prozess und die OLAP-Datenbank. Gerade in der OLAP-Datenbank spart man sich dabei unzählige, immer wiederkehrende Mausklicks.
Dadurch können wir uns in Workshops jetzt viel stärker auf die Inhalte konzentrieren und vertrödeln nicht wertvolle Zeit mit Schreiben von SQL-Code und anderen Routinearbeiten. In der Regel ist damit nach einem halben Tag eine erste Anwendung fertig. Das Metamodell ist gleichzeitig Modelldokumentation. Was das bedeutet, weiß jeder, der an einem Modell weitermachen musste, das er nicht selbst gebaut hat.
Bissantz Alles in allem ist OLAP wohl immer noch ein Workaround, bis relationale und mehrdimensionale Modellierung und Abbildung zusammengewachsen sind. Aber das wird noch dauern. Bis dahin, gilt es, das nötige Know-how so in die Produkte zu integrieren, dass es auch Nicht-Experten zur Verfügung steht. Mit unserem DeltaMaster Modeler gehen wir ja genau diesen Weg.
Westphal Genau, und alles, was man noch nicht in die Produkte bekommt, muss man eben schulen, dafür schulen wir unsere Kunden ja in den OLAP-Seminaren.
