Wie Sie auf Basis Ihres SAP HANA Datenbanksystem komplexe Analysen auf sehr großen Datenbeständen ohne Vorberechnung durchführen!
Mit Ihrer bestehenden Analytics Lösung können Sie bereits typische Fragestellungen beantworten, wie:
- Umschlagshäufigkeit und Bestandsreichweite für Artikel
- Bestandsbewertung mit diversen Preisen
- Simulation von Preisänderungen
Können Sie diese Fragestellungen aber auch unter folgenden Randbedingungen beantworten:
- Berechnung auf maximal granularer Datenbasis?
- Zu beliebigen Stichtagen?
- Für alle Artikel und Betriebe gleichzeitig?
- Ohne Vorberechnung?
Mit dem Einsatz eines SAP HANA Datenbanksystems schaffen Sie die Grundlage für derartige Analysemöglichkeiten. Aber erst mit einer geschickten Nutzung der neu zur Verfügung gestellten technischen Möglichkeiten, lassen sich auch komplexe Analysen auf sehr großen Datenbeständen ohne Vorberechnung durchführen. Das folgende Projektbeispiel veranschaulicht das Potential:
Wie aber lassen sich Lösungen mit SAP BW auf einem SAP HANA Datenbanksystem erstellen, die eine derartige Leistungsfähigkeit aufweisen?
In meinem Blog „Next Level Analytics – Teil 1“ bin ich zunächst auf die Lösungsarchitektur eingegangen und hatte empfohlen, folgende vereinfachte Architektur zu realisieren:
- Reportingschicht: Composite Provider bilden virtuelle Sichten auf die in der Harmonisierungsschicht gespeicherten Daten. Composite Provider können auch für den Informationsbedarf spezieller Anwendergruppen zugeschnitten werden.
- Harmonisierungsschicht: Alle Daten werden in der Original-Granularität (keine Verdichtung) gespeichert. Die erforderliche Business Logik wird auf die Daten der Eingangsschicht angewendet, d.h. sie werden typischerweise um zusätzliche Informationen angereichert. Sie bilden die maximal notwendige Datenbasis für alle Reportinganforderungen.
- Dateneingangsschicht: Alle Daten werden unverfälscht, vollständig und in der Original-Granularität (keine Verdichtung) gespeichert.
Innerhalb der Harmonisierungsschicht kann die Business Logik auf zwei grundsätzlich unterschiedlichen Wegen implementiert werden:
- Über eine Transformation, die Daten in ein Datenziel überführt und sie dort speichert.
- Über Calculation Views, Table Functions, AMDP’s und andere Objekte, die Business Logik lediglich zur Laufzeit einer Abfrage ausführen, die Ergebnisse aber nicht mehr speichern.
Wie kann ich aber entscheiden, welcher Weg für welche Konstellation der richtige ist?
Ein erstes Kriterium ist sicherlich das eigene technische Know How. Bin ich und / oder mein Team bereits in der Lage, mit diesen Objekten zu arbeiten? Wenn nicht, müssen zunächst die erforderlichen Kenntnisse über Schulungen erworben werden. Weil die mit diesen Objekten erzielbaren Ergebnisse wirklich überragend sind, lohnt sich der Aufwand.
Ein anderes Kriterium ist die Datenmenge, die im System physisch gespeichert werden muss. Unter dem Ansatz Next Level Analytics soll die Speicherung von Daten auf ein erforderliches Minimum reduziert werden.
Für die Anwender einer analytischen Lösung spielt natürlich die Antwortzeit der Auswertungen eine wichtige Rolle. Hier sind die Erwartungen durch die Verfügbarkeit der HANA Technologie erheblich gestiegen. Um es vorwegzunehmen: Wenn Sie sich für ein Design entschieden haben, in dem sehr viel und komplex über virtuelle Objekte zur Laufzeit berechnet wird, Ihre Datenmenge aber gleichzeitig extrem groß ist, werden Sie unzureichende Antwortzeiten bekommen. In diesen Fällen müssen dann doch einzelne, vorberechnete Daten redundant gespeichert werden.
Design für das Beispiel der flexiblen Bestandsbewertung mit unterschiedlichen Preisen
Versuchen wir für das Beispiel der flexiblen Bestandsbewertung mit unterschiedlichen Preisen ein Design zu entwerfen, ergeben sich u.a. folgende Überlegungen: Neben verschiedenen Stammdaten wie Artikel und Werk müssen sicherlich die einzelnen Preise und Materialbewegungen mit ihren Zu- und Abgangsmengen gespeichert werden. Falls erforderlich, können sowohl Preise als auch Materialbewegungen mit zusätzlicher Business Logik innerhalb von Transformationen angereichert werden. Aber diese Daten bilden die Grundlage für unsere Lösung zur flexiblen Bestandsbewertung und müssen daher gespeichert werden.
Wie steht es aber mit der Bewertung einer Menge mit verschiedenen Preisen gültig an einem Stichtag? Müssen auch diese Daten wie früher vorberechnet und gespeichert werden? Nein, mit dem Einsatz von Calculation Views können diese Berechnungen zur Laufzeit der Abfrage durchgeführt werden!
Das vereinfacht dargestellte Design basiert dann auf einer Reihe von:
- Info-Objekten mit Attributen
- aDSO Objekten für die verschiedenen Preise
- Einem aDSO für die Materialbewegungen
- Mehrfach geschachtelte Calculation Views
- Einem Composite Provider mit einem Calculation View
- Einer Query zur Anzeige der bewerteten Bestände zum Stichtag
Preise bzw. Konditionen werden i.d.R. auf unterschiedlichen Ebenen gepflegt: So können z.B. Einkaufspreise nicht nur vom Lieferanten, sondern auch vom zu beliefernden Werk, Staffelmengen und anderen Kriterien abhängen. Für Verkaufspreise gibt es neben einem Standardpreis evtl. Shop-spezifische Preise oder Aktionspreise bei Werbemaßnahmen. Alle Preise gelten typischerweise immer für einen Zeitraum, was bei der Suche nach gültigen Preisen zu einem Stichtag ebenfalls berücksichtigt werden muss.
Nehmen wir an, wir speichern zeitabhängige EK- und VK-Preise in jeweils einem aDSO, wobei sich unterschiedliche Preistypen (Standard, Aktion, etc.) im aDSO über ein Merkmal auseinanderhalten lassen. Über zwei Zeitmerkmale (gültig von, gültig bis) wird der Gültigkeitszeitraum für jeden Preis beschrieben.
Für die Materialbestände unterstellen wir hier ein sehr vereinfachtes Verfahren, in dem wir den Bestand zu einem Stichtag über die Summe aller Zu- und Abgänge bis zum gewünschten Stichtag berechnen können. Auch wenn typische Szenarien ein aDSO mit Bestandskennzahlen, Stützpunkten, Komprimierung und historischen Materialbewegungen nutzen, bleiben wir hier bei dem einfachen Verfahren.
Mit dem Einsatz von Calculation Views verlassen wir die Ebene der komplexen Applikationsobjekte, die über die bekannte Workbench modelliert und administriert werden. Stattdessen wechseln wir zur Ebene der Datenbankobjekte, die uns zwar Vorteile in der Verarbeitungsgeschwindigkeit bieten, die aber auch ein tieferes technisches Verständnis von Datenstrukturen voraussetzen. Innerhalb des HANA Studios bzw. der Eclipse Umgebung verwenden wir auch eine neue Perspektive zur Modellierung: SAP HANA Modeler.
Im dritten Teil der Next Level Analytics Serie werden wir uns mit der Datenmodellierung und der Erstellung von Calculation Views im HANA Studio bzw. Eclipse beschäftigen.
