Der „SAP HANA Modeler“
Im vorherigen Teil der Next Level Analytics Serie beschäftigten wir uns mit den ersten Schritten der Datenmodellierung und der Erstellung von Calculation Views im HANA Studio bzw. Eclipse.
Für die nächsten Schritte wechseln wir jetzt in die Perspektive „SAP HANA Modeler“, um dort den virtuellen Teil der Lösung zu definieren. Unser Ziel ist es ja, auf Basis der persistierten Grunddaten alle notwendigen Berechnungen zum Ausführungszeitpunkt der Abfrage durchzuführen.
Beginnen wir mit einem Calculation View, der uns die an einem beliebigen Stichtag gültigen Einkaufspreise aus den zeitabhängigen Konditionen berechnet.
Folgende Punkte soll der Calculation View leisten:
- Aus dem allgemeinen Konditionswert sollen mehrere spezifische EK-Preise abgeleitet werden.
- Dafür muss für jeden Konditionstyp eine spezifische Kennzahl erstellt werden: z.B. für den Konditionstyp ZNNE soll es die Kennzahl ZNNE_PREIS geben. Diese Kennzahl hat dann ausschließlich bei Datensätzen mit dem Konditionstyp ZNNE einen Wert, bei allen anderen Konditionsarten hat sie den Wert 0.
- Der Anwender soll einen Stichtag eingeben, so dass nur diejenigen Konditionen berücksichtigt werden, die an diesem Stichtag gültig sind.
- Der Stichtag soll als Vorschlagswert den Vortag anbieten.
- Die so gebildeten EK-Preise entsprechen dem jeweiligen Konditionswert, wenn bei einer Preisanfrage sämtliche Merkmale abgefragt werden. Werden bei einer Preisanfrage Merkmale weggelassen und damit Datensätze verdichtet, soll der Durchschnittspreis berechnet werden.
Im ersten Schritt fügen wir eine Projektion in den neuen Calculation View ein und ordnen ihr den externen SQL-View von dem aDSO „ZCOND_EK“ zu. Der externe SQL-View ist an seiner Endung „8“ zu erkennen, die hinter dem technischen Namen des aDSO folgt. Die externen SQL-Views bieten für jede Kennzahl immer die interne und externe Darstellung an. Für die weiteren Berechnungen verwenden wir aber immer nur die interne Darstellung, erkennbar an der Endung „__INT“.
Nachdem wir den externen SQL-View für unsere Projektion ausgewählt haben, stehen uns alle seine Spalten zur Auswahl zur Verfügung. Indem wir eine Spalte aus dem Angebot auswählen, definieren wir die Ausgabe von dem Knoten Projektion. Die Liste der Ausgabespalten ist dann wieder das Angebot an Eingabespalten für den folgenden Knoten.
Wir wählen die folgenden Spalten aus:
Damit wir immer nur diejenigen Datensätze aus dem aDSO selektieren, die am gewünschten Stichtag gültig sind, benötigen wir einen eingabebereiten Input Parameter. Mit diesem Input Parameter können wir dann die Datensätze über die Merkmale GUELTIG_VON und GUELTIG_BIS filtern.
Bei der Definition des Input Parameters vergeben wir einen technischen Namen, hier IP_STICHTAG, und einen Datentyp, hier NVARCHAR mit der Länge 8, weil SAP diesen Datentyp für Tage verwendet, wenn die Datenbanktabellen zu einem aDSO generiert werden.
Über den Parametertyp „DIRECT“ ermöglichen wir es dem Anwender, einen Wert für den Parameter einzugeben. Den Vorschlagswert berechnen wir über einen kleinen SQL Ausdruck, der vom aktuellen Datum einen Tag abzieht und das Ergebnis in der SAP internen Darstellung formatiert anzeigt.
Wir können jetzt die am Stichtag gültigen Datensätze filtern, indem wir für die Spalte GUELTIG_VON festlegen, dass der Wert von GUELTIG_VON im Datensatz kleiner oder gleich dem Input Parameter ist, während der Wert von GUELTIG_BIS im Datensatz größer oder gleich dem Input Parameter sein soll.
Den daraus generierten Filterausdruck für die Projektion kontrollieren wir im Ausgabebereich des Knotens:
Die Ausgabe der Projektion sieht jetzt folgendermaßen aus, nachdem wir den Namen der Spalten „KOND_VAL__INT“ auf „KOND_VAL“ geändert haben:
Schauen wir uns Beispieldaten für einen Artikel auf dieser Projektion an, erkennen wir die verschiedenen Konditionstypen unterschiedlicher Lieferanten mit ihren Gültigkeitszeiträumen für einen bestimmten Konditionswert.
Wir wollen unsere Projektion jetzt dahingehend erweitern, dass wir aus dem allgemeinen Konditionstyp und -wert spezifische Kennzahlen für die einzelnen Konditionstypen ableiten. Wir erreichen dies über die Definition von „Calculated Columns“, die neben einem Namen und Datentyp auch eine mehr oder weniger komplexe Berechnungslogik enthalten.
Für die Berechnung eines EK-Netto-Netto Preises prüfen wir den Konditionstyp auf den Wert „ZNNE“. Nur wenn der Datensatz diesen Konditionstyp enthält, übernehmen wir den allgemeinen Konditionswert als unseren EK-Netto-Netto Preis. Bei allen anderen Konditionstypen setzten wir den Wert auf Null.
Ganz wichtig dabei: wir erweitern jeden Datensatz aus dem aDSO um diese Preis-Spalte! Immer wenn die Bedingung erfüllt ist, enthält die Preisspalte einen Wert, ansonsten haben alle anderen Datensätze hier nur den Wert Null.
Für die spätere Berechnung von Durchschnittspreisen definieren wir uns einen zusätzlichen Zähler, der in jedem Datensatz den Wert 1 bekommt, in dem der Konditionstyp „ZNNE“ und der Konditionswert gefüllt ist. In allen anderen Datensätze steht hier der Wert Null.
Für den ZNNE-Preis benötigen wir auch noch eine spezifische Spalte für die Währung: Abhängig vom Konditionstyp im Datensatz übernehmen wir die allgemeine Währung oder setzten den Initialwert für alle anderen.
Nach genau diesem Muster definieren wir weitere calculated columns für die Konditionstypen ZLPR und ZRKP, so dass wir insgesamt folgende zusätzliche Spalten in unserer Projektion haben.
Der Knoten Projektion ist jetzt vollständig definiert und liefert uns die zu einem Stichtag gültigen EK-Konditionen, wobei jeder Datensatz um Konditionstyp spezifische Spalten ergänzt ist.
An diesen Beispieldaten sehen wir u.a. den Effekt, dass unseren berechneten Spalten nur für einige Datensätze einen Wert haben.
Indem wir die Projektion mit dem Knoten Aggregation verbinden, stehen uns alle Spalten aus dem Ausgabebereich der Projektion in der Aggregation zur Verfügung. Wir übernehmen alle Spalten in die Aggregation und können uns jetzt um die Durchschnittsberechnungen kümmern.
Standardmäßig ist für alle Kennzahlen in der Aggregation die Summierung als Aggregationsverhalten eingestellt. Das würde aber dazu führen, dass wir Preise aufaddieren sobald wir Datensätze verdichten und mit derartigen Werten können wir nichts weiter sinnvoll berechnen.
Da wir auch auf dem Aggregationsknoten wieder Calculated Columns definieren können, haben wir die Möglichkeit, Durchschnittspreise zu berechnen. Wir teilen dazu den kumulierten Preis durch den kumulierten Zähler, wobei wir allerdings darauf achten müssen, eine Division durch Null zu verhindern. Der Zähler wurde ja in Abhängigkeit vom Konditionstyp gesetzt und kann daher durchaus den Wert Null haben.
Für die konditionsspezifische Währung reicht es, die berechnete Spalte aus der Projektion zu verwenden.
Auf diese Weise definieren wir weitere calculated columns für die restlichen Konditionstypen.
Abschließend setzen wir auf dem Knoten Semantik die passenden Typen (Merkmal / Kennzahl) für alle Spalten, so dass alle Objekte, die diesen Calculation View verwenden, das passende Verhalten für jede Spalte anwenden können.
Für die finalen Preise (ZNNE_PREIS) und deren spezifische Einheiten (ZNNE_CURR) haben wir noch diverse Hilfsspalten (CC_ZNNE_PREIS, CC_ZNNE_WHRG, …), die bei der Verwendung des Views nur stören und irritieren würden. Indem wir diese Spalten verstecken / ausblenden, gestalten wir den Ausgabebereich von unserem View übersichtlicher.
In der Gesamtübersicht sehen wir noch einmal die drei Knoten in unserem Calculation View.
Die folgenden Beispieldaten liefert unser View für einen Artikel und einen Stichtag. Abhängig vom Konditionstyp sind wieder nur bestimmte berechnete Spalten in einem Datensatz gefüllt. Die Werte entsprechen aber dem jeweiligen „Originalwert“, da wir gerade sämtliche Merkmale in der Anzeige sehen.
Entfernen wir jetzt aber Merkmale (Lieferant , Gültig ab) aus den Anzeige, bekommen wir Durchschnittspreise (242,05 + 481,53) / 2 = 361,79.
Im nächsten Teil der Serie zeigen wir Ihnen, wie wir den Calculation View für die Verkaufspreise aufbauen.