Oracle als Softwareanbieter verfügt über zwei eigenständige, vollwertige OLAP-Datenbanken in seinem Portfolio. Es lohnt sich daher, die technischen Unterschiede wie auch die Positionierung im Markt näher zu untersuchen. Umso schöner, dass es DeltaMaster dem Anwender einfach macht, mit beiden Datenbanken zu arbeiten.

Seitdem Hyperion von Oracle gekauft wurde, existieren im Oracle Konzern zwei OLAP-Datenbanken: Die OLAP-Option von Oracle (kurz: Oracle OLAP) und Oracle Essbase (ehemals Hyperion Essbase). Auch wenn vordergründig damit zwei sehr ähnliche Produkte angeboten werden, so existieren doch zahlreiche sehr deutliche technische Unterschiede, die von Oracle auch zu einer unterschiedlichen Positionierung im BI-Markt genutzt werden. Diese Unterschiede beleuchtet der folgende Blogbeitrag und erläutert zudem, wie beide OLAP-Systeme in Verbindung mit DeltaMaster genutzt werden können.

Technologische Abgrenzung – die Beraterbrille

Historisch betrachtet, wurde die Oracle OLAP Option frühzeitig in die Oracle Datenbank-Suite integriert, wohingegen Hyperion Essbase bis zum Kauf von Hyperion durch Oracle in 2007 als eigenständige Datenbank positioniert war (und auch heute noch ist). Diese Historie schlägt sich auch in den technischen Merkmalen nieder: So kann die Oracle OLAP Option lediglich eine Oracle Datenbank als direkte relationale Quelle verwenden; Oracle Essbase dagegen ist offen für die direkte Integration jeglicher relationaler Datenbankquellen. Auch die Anwendergruppen, die aktiv OLAP-Datenmodelle definieren und weiterentwickeln, sind entsprechend unterschiedlich: Während die Oracle OLAP Option primär Datenbank- und IT-Administratoren adressiert, die oftmals unternehmensweite Anwendungen betreuen, so spricht Oracle Essbase eher den technisch versierten Fachanwender an und wird damit in vielen Fällen auch in bereichsspezifischen Szenarien eingesetzt.

Oracle OLAP ist eine Oracle-Datenbank-zentrierte Technologie, wohingegen Oracle Essbase als klassische Zwischenschicht (‚Middle Tier’) in heterogenen Datenbank-Architekturen fungiert.

Letztendlich handelt es sich jedoch bei beiden OLAP-Datenbanken um echte multidimensionale (MOLAP) Datenbanken und die Integration verschiedenster Datenquellen ist faktisch in beiden Fällen möglich: Im Fall von Oracle Essbase direkt und bei der Oracle OLAP Option indirekt durch Integration in eine relationale Zwischenschicht einer Oracle Datenbank.

Für uns als Endanwender, die über ein geeignetes Frontend derartige OLAP-Datenbanken für Analysen nutzen möchten, stellt sich jedoch aus technischer Sicht die Welt von Oracle OLAP und Oracle Essbase sehr unterschiedlich dar. Grund dafür: Oracle Essbase verfügt über eine MDX-Schnittstelle, wie sie auch für andere OLAP-Datenbanken Verwendung findet, wohingegen Oracle OLAP eine (historisch bereits länger existierende) Abfragesprache, die OLAP DML, als Basis verwendet. Doch halt, das ist nur ein Teil der Wahrheit, denn Oracle OLAP kann auch anders: Abfragen auf den OLAP-Würfel sind direkt per SQL möglich. Was bedeutet das in der Praxis? Während für Oracle Essbase Frontend-Technologien einsetzbar sind, die MDX als Abfragesprache nutzen, dann aber meist nicht gleichzeitig umfangreichere Kommunikationsmöglichkeiten mit relationalen Datenbanken vorweisen, so existieren auf der anderen Seite zahlreiche relationale Reporting-Frontends, die auf SQL-Abfragen angewiesen sind und damit die Oracle OLAP Option mitnutzen können.

Damit teilt Oracle den Markt für seine OLAP-Datenbanken aufgrund deren technischer Basis bereits ein gutes Stück weit auf: Für Datenbank-Spezialisten mit SQL-Know-how bietet sich die Nutzung der Oracle OLAP Option an, wohingegen Analysespezialisten mit MDX-Frontends sich der Oracle Essbase Variante zuwenden können.

Aber warum macht es überhaupt Sinn, eine OLAP-Datenbank über SQL ansprechen zu wollen? Dafür muss man den Hintergrund zahlreicher Datawarehouse-Anwendungen verstehen, die im Oracle-Umfeld bereits existieren. Hier dominieren relationale Datawarehouse-Architekturen, die oftmals mit der Zielsetzung eines unternehmensweiten Datenspeichers angelegt sind bzw. werden. Star-Schemata bzw. in manchen Fällen Snow-Flake-Schemata werden von Datenbankspezialisten mit relationalem Know-how erzeugt und gepflegt. Die gleichen Personen pflegen zudem oftmals die Oracle-Datenbanken der operativen Systeme (z.B. ERP, WMS, PPS, CRM, TMS). Zu Reportingzwecken werden in diesen Data-Warehouse-Szenarios entsprechend relationale Frontend-Technologien verwendet. Vorteil aus der Sicht des Anwenderunternehmens: Alle Datenbanken können von den Oracle-Spezialisten mit einheitlichem Know-how bearbeitet werden. Nachteil: Abfrageperformanz im Data Warehouse wird rein relational recht schnell zu einem Problem, das auf relationaler Ebene insbesondere über die Erzeugung von „Materialized Views“, also Sichten, die als Tabellen abgespeichert werden, gelöst wird. Prinzipiell gilt jedoch, dass die Erzeugung von Materialized Views durchaus aufwändig ist, zudem nicht alle potenziellen Aggregationen mit vertretbarem Aufwand (Speicherplatz, Arbeitsaufwand für Definition und Pflege, etc.) definiert werden können. Und zusätzlich gilt, dass sich typische analytische Berechnungen wie Periodenabweichungen, Kumulationen und gleitende Durchschnitte im rein relationalen Umfeld nur aufwändig (und wenn, dann durchaus leistungskritisch) realisieren lassen.

An dieser Stelle setzt das Konzept der Oracle OLAP Option an: Da sie tief in die Oracle-Datenbankwelt integriert ist und ihre Inhalte über SQL dem Endanwender (bzw. auch dem Datenbank-Administrator) zur Verfügung gestellt werden können, dient die Oracle OLAP Option als Beschleuniger (weniger Materialized Views) und als Aufwertung (mehr analytischer Tiefgang ohne administrativen Aufwand bei hoher Performanz) zur klassischen relationalen Oracle-Datenbank. Mit dem Vorteil, dass für die Nutzung der Daten auf die bestehenden SQL-Kenntnisse einer sehr großen Zahl von Datenbank-Spezialisten zurückgegriffen werden kann. Technisch ist das durch eine automatische Übersetzung (Rewrite) der SQL-Anfragen durch die Oracle Datenbank in Abfragen für die Oracle OLAP Option realisiert. Damit unterscheidet es sich von dem einfacheren Konstrukt, mehrdimensionale Abfragen (z.B in MDX) über einen SQL-Aufruf auszulösen, wie es z.B. in T-SQL (vgl. „Export von OLAP-Daten in eine SQL-Tabelle“) möglich ist.

Da die Oracle OLAP Option jedoch eine vollständige OLAP-Datenbank mit eigener multidimensionaler Abfragesprache (OLAP DML) bereit hält, stellt sich natürlich die Frage, ob nicht OLAP-Frontends direkt auf diese Schnittstelle, die über eine besonders hohe Abfrageperformanz verfügt, zugreifen können. In der Tat ist dies möglich, so unterstützt DeltaMaster mit einer eigenen Schnittstelle über OLAP DML die Oracle OLAP Option (vgl. „Analysieren und Berichten auf Oracle OLAP mit DeltaMaster“). Parallel gibt es derzeit Entwicklungsbestrebungen durch einen Schnittstellen-Drittanbieter eine MDX-Schnittstelle zur Oracle OLAP Option zu erstellen. Da sich diese Schnittstelle aber zum einen nur auf die Datenbank-Version 11g bezieht und zum anderen zunächst auf Microsoft Excel fokussiert, bleibt die native DML-Schnittstelle von DeltaMaster (ab Version 10g nutzbar) ein technisches Alleinstellungsmerkmal.

Zusammenfassend bietet die folgende Tabelle einen Überblick über die diskutierten technischen Unterschiede zwischen Oracle OLAP Option und Oracle Essbase:

Marktpositionierung – die Vertriebsbrille

Die technische Unterscheidung sowie der typische Anwenderkreis (Datenbankadministratoren vs. Fachanwender) schlägt sich in der Positionierung der beiden Produkte nieder. Dabei lassen sich folgende Faktoren für die Einordnung unterscheiden (vgl. Oracle Whitepaper zu dem Thema):

Zielsetzung der Lösung

Oracle Essbase wird insbesondere für analytische Anwendungen im fachbereichsnahen Umfeld eingesetzt. Gerne gerade auch dann, wenn es um Plan- und Forecast-Anwendungen geht. Das Schlagwort des Enterprise Performance Management, also einer analytisch hochwertigen Entscheidungsunterstützung, erfordert danach zumeist die Integration verschiedenster Datenquellen in sehr aufgabenspezifischen OLAP-Lösungen.

Die Oracle OLAP Option hingegen soll nach dem Willen von Oracle relationale Datenbanken beschleunigen und analytisch erweitern, sodass relationale Data-Warehouse-Szenarios mit hoher Zentralisierung von Daten, Metadaten und Verarbeitungslogiken, von Endanwendern umfassender genutzt werden können.

Käufer der Lösung (= Prozesstreiber)

Der Käufer der Lösung, der im Zweifel auch bereits der Ansprechpartner während des Vertriebsprozesses ist, muss für Oracle Essbase im Fachumfeld gesucht werden, während die Oracle OLAP Option eher die IT anspricht. Letztere sowohl unter operativen Gesichtspunkten (Beschleunigung) als auch unter dem Gesichtspunkt einer einheitlichen IT-Architektur, die ggf. bereits auf Oracle-Produkten basiert und mit der OLAP Option lediglich fortgeschrieben wird, was zu einer leichteren Akzeptanz im IT-Umfeld führen kann.

Die Käufer (Fachbereich vs. IT) verbinden entsprechend unterschiedliche Interessen mit der Anschaffung: Im Fachbereich wird die leichte Integration neuer Datenquellen (durchaus ohne IT-Unterstützung) sowie die umfängliche Unterstützung von Planungsanwendungen und Office-Produkten als Vorteil von Oracle Essbase positioniert. Die IT hingegen wird das zentralisierte Datenmanagement, die einheitliche Rechtevergabe und die Nutzung bestehender IT-Infrastruktur als Vorteil für einen Einsatz von Oracle OLAP sehen. Die Vorteile der einen Lösung sind im Endeffekt jedoch genauso die Nachteile der jeweils anderen Lösung. Mit diesem Widerspruch, der im Zweifel jeweils auch vom „anderen Käufertyp“ ins Feld geführt wird, muss Oracle aber offenbar leben, sodass unabhängige Beratungshäuser hier dazu raten, beide Varianten unvoreingenommen dem Kunden zu zeigen und diesen entscheiden zu lassen. Diverse Szenarios werden z.B. hier gegenübergestellt.

Endanwender der Lösung

Oracle selbst unterscheidet nochmals die Endanwender der Lösung, die für Oracle Essbase eher als Analysten positioniert werden, die umfangreiche, tiefergehende Datenanalysen und ggf. What-If-Analysen zur Entscheidungsvorbereitung benötigen. Die OLAP-Option über den Weg „SQL-Anbindung“ wird dagegen für Endanwender von Standardberichtsanwendungen positioniert. Das heißt, Endanwender, die sich einfachere Datenauswertungen (z.B. pivotisierend) zusammenstellen, oder diese aber vorkonfiguriert in standardisierten Anwendungen konsumieren, sind die Zielgruppe.

Preisgestaltung

Beide OLAP-Datenbanken haben natürlich ihren Preis, der sich bei der OLAP Option aus der Oracle Database Enterprise Edition und der OLAP Option zusammensetzt. Für beide Datenbanken gibt es Lizenzen “pro Nutzer” sowie alternativ Prozessorlizenzen, Details finden sich in der offiziell verfügbaren Preisliste.

Als Fazit der Marktpositionierung, wie sie Oracle für die beiden OLAP-Datenbanken vornimmt, ist letztlich die folgende Aussage zu sehen:

Oracle OLAP wird als Beschleuniger für existierende Oracle-fokussierte relationale Data-Warehouse-Datenbanken gesehen, wohingegen Oracle Essbase in heterogeneren Umfeldern, gerne auch fachbereichsnah, für Analyse und Planungslösungen eingesetzt werden soll.

Es ist wichtig, diese Perspektive von Oracle zu verstehen, um Marktauftritt sowie Technologieweiterentwicklung im OLAP-Umfeld bei Oracle korrekt bewerten zu können. Daneben tritt die DeltaMaster-spezifische Sichtweise, die ein einheitliches Frontend für beide Datenbanken zur Verfügung stellt:

DeltaMaster als Frontend für Oracle OLAP und Oracle Essbase – die Endanwendersicht

Bissantz DeltaMaster kann mit beiden Datenbanken (in getrennten Sitzungen) direkt Verbindung über die nativen Schnittstellen aufnehmen. Für Oracle OLAP erfolgt diese über die DML-Schnittstelle (also nicht über SQL) und bietet damit eine besonders hohe Abfrageperformanz gegenüber der Datenbank. Eine detaillierte Anleitung für Oracle OLAP findet sich im Blogbeitrag „Analysieren und Berichten auf Oracle OLAP mit DeltaMaster“. Bei Oracle Essbase erfolgt die Verbindung dagegen über die MDX-Schnittstelle. Im Folgenden wird ein kurzer Überblick gegeben, mehr Details finden sich hier.

Seit der Version 5.3.2 unterstützt DeltaMaster den Zugriff auf Hyperion System 9 BI+ Analytic Services („Hyperion Essbase“) über die ADOMD.NET-Schnittstelle. Als technische Voraussetzung auf Seiten von Essbase müssen die folgenden Komponenten von Hyperion System 9 installiert sein:

• Hyperion System 9 Shared Services
• Hyperion System 9 BI+ Analytic Provider Services
• Hyperion System 9 BI+ Analytic Services, Version 9.3 oder höher

Der Zugriff von DeltaMaster auf Essbase ist nur über ADOMD.NET 8.0 möglich, standardmäßig verwendet DeltaMaster jedoch ADOMD.NET 9.0. Daher sind vor Verwendung der Schnittstelle zwei Dateien im DeltaMaster-Installationsverzeichnis („C:\Programme\DeltaMaster 5.4.1“ oder ähnlich) auszutauschen:

• AnalysisServices.AdomdClient.dll (Version 8.0)
• dll (für ADOMD.NET 8.0)

Ansonsten erfolgt die Verbindung von DeltaMaster mit der Datenbank über “Analysemodell erstellen” so wie für andere MDX-basierte OLAP-Datenbanken auch.