Sie verwenden keine aktuelle Browser-Version. Deshalb wird die Webseite möglicherweise nicht korrekt dargestellt. Hier finden Sie weitere Hinweise.

Making changes in SAP HANA Calculation Views – Part 1

Inhaltsverzeichnis

Im Bereich der Datenmodellierung auf der SAP HANA Datenbank benutzen viele Anwender die Möglichkeit des Einsatzes von Calculation Views. Das Datenmodell wird dabei mit Hilfe einer graphischen Modellierung implementiert. Sobald eine Calculation View erstellt und aktiviert wurde, kann diese als Datenprovider/-quelle weiter benutzt werden (z.B. als Quelle in einem Composite Provider).

Abbildung 1 – Bsp. für eine Calculation View

Bei der Modellierung eines Calculation Views hat es sich bewährt, nicht die vorgegebene Struktur einer Calculation View zu verwenden, sondern ergänzend eine Aggregation/Projektion und einen Union hinter die Semantiks/Aggregation/Projektion zu hängen (siehe Abbildung 2).

Abbildung 2 – erweiterte Semantik Logik

Dies ermöglicht es dem Entwickler später beim Ausführen bzw. Testen der Calculation View, direkt in der „Aggregation_1“ Merkmale zu Test- und Debugzwecken zu filtern. Warum aber der Union sinnvoll ist, sehen wir uns jetzt an. Ein großes Problem in der Modellierung von Calculation Views sind Änderungen bzw. Erweiterungen des Modells. Hierbei sind nicht einfache Änderungen eines Namens, das Hinzufügen/Entfernen eines Merkmals oder das Anlegen/Ändern einer berechneten Spalte gemeint. Die Probleme entstehen beim Hinzufügen bzw. Erweitern des Modells mit neuen Daten oder beim Entfernen eines Joins. Dabei würde z.B. das in Abbildung 1 enthaltene Mapping entfernt werden und alle Benennungen und Aggregationen verloren gehen, was eine Neuanlage bzw. eine Umbenennung zur Folge hätte (siehe Abbildung 3).

Abbildung 3 – Neuer Join vorher
Abbildung 3 – Neuer Join nachher

Durch die Verwendung des o.g. Unions wird zwar das Mapping und die Verbindung von „2_18_Join“ entfernt, jedoch bleibt dabei die Struktur nach oben erhalten und muss nicht wieder umbenannt oder bearbeitet werden (siehe Abbildung 4).

Abbildung 4 – Einsatz eines UNION

Der Einbau des o.g. Unions hat sich in der Praxis bewährt, um bei Änderungen zusätzliche Aufwände zu sparen. Bei neuen Entwicklungen ist es daher sinnvoll, immer gleich Unions als „Puffer“ zwischen einzelne Joins zu erstellen.

Dieses Vorgehen ist bei neuen Entwicklungen sinnvoll und ratsam, aber was kann der Entwickler bei bereits bestehenden Calculation Views, die noch nicht so modelliert wurden und geändert werden sollen, tun? Diese Antwort gibt es im zweiten Teil dieses Blogs, in dem gezeigt wird, wie ein neues Modellieren und das Mapping stark vereinfacht bzw. umgangen werden kann.

Kostenloses Factsheet

SAP Analytics Cloud

Für viele Unternehmen ist die SAP Analytics Cloud (SAC) die erste Cloud-Lösung im Analytics-Bereich überhaupt. Von daher überrascht es nicht, dass schon vor der Implementierung der SAC regelmäßig die gleichen Fragen auftreten. Wir erklären Ihnen unseren Fahrplan für eine erfolgreiche SAC-Implementierung.

Nehmen Sie Kontakt zu uns auf!

    Mit der Erhebung, Verarbeitung und Nutzung meiner personenbezogenen Daten zur Bearbeitung meiner Anfrage erkläre ich mich einverstanden. Ich kann mein Einverständnis jederzeit ohne Angabe von Gründen widerrufen. Weitere Informationen finden Sie in unserer Datenschutzerklärung.

    Rufen Sie uns an
    +49 6173 3363 000

    Nagarro ES Newsletter
    Newsletter jetzt abonnieren!

    Besuchen Sie uns
    Alle Standorte ansehen

    SAP Analytics Summit

    Erfahren Sie exklusiv und aus erster Hand wie:

    • Allianz bei Finanzplanungsprozessen von der SAP Analytics Cloud profitiert
    • Tchibo das Kassenreporting mit der SAP Analytics Cloud revolutioniert
    • SAP hilft die Datenbasis für analytische Innovation zu schaffen
    • Unternehmen aktiv das CO2 Management mit SAP Analytics angehen können