CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Modellierung in SAP HANA – Teil 1

Unternehmen verwenden zunehmend SAP HANA. Auf diesen Trend ist DeltaMaster gut vorbereitet, denn auf SAP-HANA-Modelle kann man damit schon seit Längerem zugreifen. Um zu gewährleisten, dass Dimensionen und Analysewerte in DeltaMaster richtig erkannt und dargestellt werden, sind bei der Modellierung einige Dinge zu beachten. Der Blogbeitrag beschreibt die Vorgehensweise für die korrekte Modellierung einer Dimension in SAP HANA.

In zwei Tagen zum Data Warehouse in der Jackentasche

Die Bissantz ERP Solutions zeigen, was mit KI-basierter Data-Warehouse-Modellierung in­zwischen möglich ist. So standardisiert wie möglich, so individuell wie nötig entsteht in kürzester Zeit ein komplett fertig paketiertes Business-Intelligence-System – mit allen not­wendigen Ver­arbeitungs­schritten, vom Laden der Daten aus SAP ERP bis zur auto­matischen Daten­versorgung mobiler Endgeräte.

Information Views

Information Views sind Objekte, über welche Daten abgefragt werden können. Darauf können z.B. Filter, Joins oder Aggregationen angewendet werden. Information Views können mit SQL-Views verglichen werden.

Es gibt drei Typen von Information Views:
– Attribute View
– Analytic View
– Calculation View

Attribute und Analytic Views

Attribute- und Analytic Views wurden bis Version SPS 11 von SAP HANA verwendet. Die Modellierung von Dimensionen wurde mithilfe von Attribute Views realisiert und die Modellierung von Fakten
mithilfe von Analytic Views. Seit Version SPS 12 soll die Nutzung dieser Objekte möglichst vermieden werden, aus Kompatibilitätsgründen werden sie aber weiter unterstützt.

Calculation View

Seit Version SPS 12 werden Calculation Views sowohl für die Modellierung von Dimensionen als auch von Fakten verwendet. Über die Option „Data category“ kann unterschieden werden, ob die Calculation
View für ein Dimensions- oder Faktenobjekt genutzt werden soll. Es gibt drei Möglichkeiten:

– Data Category = Dimension
– Data Category = CUBE mit Option „With Star Join“
– Data Category = CUBE ohne Option „With Star Join“

Umgebung

Die Modellierung eines multidimensionalen Models kann in mehreren Benutzer-Interfaces realisiert werden, eine davon ist das SAP HANA Studio. Dort ist es möglich, sich mit einer laufenden Instanz von SAP-HANA zu verbinden.

Nach der Verbindung wird das HANA-System wie folgt dargestellt.

Abb. 1: SAP HANA Studio – Administration Console

Wichtig sind die Ordner „Catalog“ und „Content“. Der Ordner „Catalog“ enthält die Quellen für Dimensionen und Fakten.

Abb. 2: SAP HANA Studio – Catalog

Der Ordner „Content“ enthält die sogenannten „Packages“, z.B. „BC_CHAIR“, in denen die multidimensionalen Objekte abgelegt sind.

Abb. 3: SAP HANA Studio – Content

Namenskonvention

Wir empfehlen für die zu erstellenden Objekte folgende Namen zu verwenden:

– CVD_[Dimensionsname] für Dimensionen, CVD steht für Calculation View vom Typ Dimension
– CVC_[Measuregruppenname] für Measuregruppen, CVC steht für Calculation View vom Typ Cube

Diese Namenskonvention wird auch von SAP empfohlen.

Modellierung von Dimensionen

Der erste Schritt für die Modellierung einer Dimension ist die Erstellung einer neuen Calculation-View (rechte Maustaste auf das Package – New – Calculation View)

Abb. 4: Neue Calculation View

Im nächsten Fenster kann der Name der Dimension (z.B. CVD_KUNDE) und die Labelinformation (z.B. Kunde) eingegeben werden. Wenn „Label“ gefüllt ist, wird dieser als Name der Dimension in DeltaMaster erkannt. Zudem kann hier der Typ bzw. die „Data Category“ der Calculation View festgelegt werden, in unserem Fall „Dimension“.

Abb. 5: Calculation View für eine Dimension

Als nächstes wird ein graphischer Editor mit den zwei Objekten: „Semantics“ und „Projection“ angezeigt. Die Quelltabelle der Projektion kann per Drag-Drop aus dem Ordner „Catalog“ übernommen werden. Anschließend werden im Detailfenster auf der rechte Seite alle Spalten der Quelltabelle gelistet, hier können die gewünschten Spalten (einzelne oder alle) mit der Option „Add To Output“ bzw. „Add All To Output“ selektiert werden.

Abb. 6: Information View – Projection

In „Semantics“ werden semantische Einstellungen definiert. Im Reiter „Columns“ können folgende Einstellungen vorgenommen werden:

– Key: Schlüssel-Spalte der Tabelle (z.B. KundeID)
– Label: Das Label ersetzt den Namen der Spalte, wenn es gefüllt ist. Wichtig für Spalten, die Hierarchieebenen bilden.
– Label Column: Hier können zwei Attribute verbunden werden (z.B. ID und BEZ)

Abb. 7: Information View -Semantics (Columns)

Hierarchien werden im Reiter „Hierarchies“ definiert. Hier kann der Name, z.B. Kunde_Hierarchie, und die Labelinformation eingegeben werden. Auch hier gilt: Wenn im Feld Label etwas eingegeben wurde, wird dieser Eintrag als Name der Hierarchie in DeltaMaster erkannt und angezeigt. Die Spalten, die die Hierarchie bilden, können mithilfe des Knopfes „Add“ hinzugefügt werden. Die Reihenfolge der Spalten bestimmt die Reihenfolge der Ebenen.

Abb. 8: Information View -Semantics (Hierarchies)

Für flache Dimensionen ist die Erstellung einer Hierarchie nicht zwingend notwendig, allerdings empfehlenswert, da nur in Hierarchien die Möglichkeit besteht, das per Default angelegte All-Element zu deaktivieren. Das ist z.B. für die Dimensionen Wertart oder Kumulation sinnvoll. Diese Option kann unter „Advanced“ – „Root Node Visibility“, Option „Do Not Add Root Node“ verwaltet werden.

Abb. 9: Information View -Semantics (Hierarchies)

Schließlich kann die Definition der Dimension durch die Option „Save and Activate“ übernommen und gespeichert werden.

Abb. 10: Save and Activate