Von Any DB zu SAP HANA DB

Nachdem wir auf unserer Reise durch die SAP HANA Welt im Blog-Beitrag Begriffsdschungel HANA – Was leistet die HANA DB? einen Blick auf die SAP HANA Datenbank geworfen haben, dürfte aufmerksamen Lesern aufgefallen sein, dass die Datenbank verstärkt ein Thema für den SAP Anwender geworden ist. Warb die SAP früher damit, mit fast jeder Relationalen Datenbank (Any-DB) zusammenarbeiten zu können, bedeutete dies auch, dass es wenig Berührungspunkte für den SAP Anwender mit der Datenbank gab.

Selbst beim Thema SAP Business Warehouse (SAP BW), was eng mit Daten und der Datenmodellierung wie z. B. Sternschema und Tabellen (Fakten-, Dimensionstabellen) verbunden ist, hatte der Anwender i.d.R. kaum Kontakt zur Datenbank.

Jetzt die große Wende der SAP: Der Ansatz, jede Datenbank zu unterstützen, wird komplett aufgegeben; die SAP setzt voll auf SAP HANA als einzige Datenbank für alle Anwendungen.

Im Bereich SAP BW kennt man die Problematik, mit großen Datenmengen und Performance-Fragestellungen arbeiten zu müssen. Aus diesem Grund gab es bereits in der Vergangenheit Lösungsansätze mit spezialisierten Datenbanken wie dem SAP BW Accelerator (SAP BWA).

Nach der HANA-Euphorie, das Thema Performance endlich gelöst zu haben, kamen vermehrt Stimmen auf, die behaupteten, dass das SAP BW nicht mehr gebraucht wird. Data Warehousing ginge auch ohne SAP BW, ganz allein mit HANA Native.

Wie der Begriff „native“ schon vermuten lässt, nutzt man keine zusätzlichen Tools zur Datenmodellierung wie z. B. das SAP BW, sondern nur die Funktionen und
Werkzeuge, die das SAP HANA System selbst zur Verfügung stellt.

Die Entwicklung eines Data Warehouses und Berichtswesens wird also direkt innerhalb des SAP HANA Systems realisiert.

Bedeutet das, dass man jetzt jede Tabelle und Referenz eines Sternschemas auf der Datenbank selbst anlegen und definieren muss?

SAP HANA bietet sowohl einen sehr ausgereiften grafischen Editor als auch einen Script Editor. Diese graphischen Werkzeuge erzeugen SQL und auch jegliche Kommunikation mit der SAP HANA Datenbank erfolgt letztlich in SQL. Daher wird der Ansatz auch als SAP HANA SQL Data Warehousing bezeichnet. Als Objekte kommen insbesondere Grafische Calculation Views, Funktionen und Prozeduren zum Einsatz.

Auch wenn die SAP HANA DB ein sehr leistungsstarkes Datenbanksystem ist, bietet es doch auch Funktionen und Möglichkeiten, die über eine reine Datenbank hinausgehen. Hintergrund ist die Einführung eines eigenen Anwendungsservers SAP HANA Extended Application Services (kurz XS) oder SAP HANA Extended Application Services Advanced (kurz XSA, seit Ende 2015). Dies ermöglicht eine eigene Entwicklungsumgebung (SAP Web IDE) sowie die Anbindung der verteilten Quellcodeverwaltung Git, die Full-Stack-Entwicklung auf der SAP HANA Plattform erlaubt.

Hierdurch können auch die Data Warehouse Strukturen sehr agil entwickelt werden. Die SAP Web IDE mit dem zugrundeliegenden XS/XSA und der Möglichkeit, Entwicklung- und Laufzeitumgebungen zu differenzieren sowie der verteilten Quellcodeverwaltung GIT, eignet sich hervorragend zum Aufbau eines leistungsfähigen Data Warehouses. Damit unterstützt SAP HANA SQL Data Warehousing die DevOps Philosophie, die wiederum die agile Softwareentwicklung ermöglicht. Bei der Datenmodellierung ist man weitestgehend frei, ob man Multidimensional (Sternschema), die dritte Normalform oder Data Vault für sein Modell bevorzugt. Insbesondere die Data Vault Methode unterstützt die sich auch im Data Warehousing immer stärker verbreitenden agilen Entwicklungsverfahren.

Ohne toolbedingte Einschränkungen bestehen maximale Freiheitsgrade bei der Modellierung und erhöhte Flexibilität bei der Implementierung. Notwendige Daten liegen direkt vor oder können mit datenbankeigenen Tools sehr leicht repliziert oder angebunden werden. Die Transformationslogik kann performant direkt auf der Datenbank definiert und ausgeführt werden. Für die native HANA Modellierung gibt es keine Einschränkungen in der visualisierten Datenaufbereitung. Auch können beliebige Reporting-Tools genutzt werden, da der Zugriff auf die native Datenbank stattfindet.  

Für das Thema Advanced Analytics bietet die SAP HANA Plattform den Vorteil, dass die entsprechende Analytics Engine bereits voll integriert ist. Der Aufbau und der Betrieb des Data Warehouses kann nach agilen Prinzipien erfolgen. So ist der Anwender stärker und früher involviert und die Entwicklung kann schneller auf die Anforderungen und Rückmeldungen der Anwender reagieren. Zusätzliche Lizenzkosten, wie z. B. bei SAP BW, fallen nicht an.

Es spricht also viel für den nativen SQL-Data-Warehousing Ansatz. Was spricht dagegen oder was fehlt?

Hat man bisher noch keine Data Warehouse Lösung wie z. B. das SAP BW, spricht wohl nichts dagegen, den nativen HANA SQL Data Warehousing Ansatz zu wählen. Altbekannte Gründe wie die physikalische Trennung von Transaktionalen und Analytischen Daten, speziell wenn die Daten aus vielen verschiedenen Vorsystemen kommen, sind nach wie vor nicht zu vernachlässigen. Der Ansatz, das Data Warehouse direkt dort aufzubauen, wo die auszuwertenden Daten liegen, klingt reizvoll, widerspricht aber dem oben genannten, klassischen DWH Dogma der physikalischen Trennung.

Anders sieht es aus, wenn bereits ein SAP BW über lange Zeit im Einsatz ist. Unter SAP BW/4HANA hat sich viel geändert und der Großteil der Anwendung wurde in die SAP HANA DB und damit näher an die Daten verlegt. SAP BW ist offener und agiler geworden. Weiterhin bietet SAP BW umfangreichen Business Content für spezifische Modelle und Extraktionen aus den SAP Anwendungen per Knopfdruck an. Services wie Historisierung, Delta-Handling, Request-Management, Hierarchien, Mehrsprachigkeit, Mehrwährungsfähigkeit, Prozessketten und einiges mehr, sind im SAP BW "out of the box“ verfügbar und bieten einen umfangreichen Mehrwert, der für native HANA Warehouses erst noch generiert werden muss.

Weiterhin stellt sich die Frage: Was ersetzt die BW Query des SAP BW als zentrales Werkzeug zur Definition von komplexen Abfragen in einem nativen SQL Data Warehouse?