SAP Datasphere Analytic Model Series – User Experi...

philine · ‎05-09-2023

Introduction

The SAP Datasphere Analytic Model Series is intended to provide you with useful guidance on how to utilize the new Analytic Model to leverage the potential of your data landscape. The Analytic Model allows for rich analytical modelling in a targeted modelling environment and will be THE go-to analytic consumption entity for SAP Datasphere.

This article is the ninth in the blog post series and showcases the User Experience of analytic modelling and how to navigate the Analytic Model interface in SAP Datasphere.

So far, the following blogs have been published:

Blog Post #1: Introducing the Analytic Model in SAP Datasphere

Blog Post #2: Data Model Introduction

Blog Post #3: Motivation and Comparison with the Analytical Dataset

Blog Post #4: Calculated and Restricted Measures

Blog Post #5: Exception Aggregation

Blog Post #6: Variable Usage

Blog Post #7: Time Dependency for Dimensions and Texts

Blog Post #8: Data Preview

Blog Post #9: User Experience and Navigation Paradigm

Blog Post #10: Multi Fact

Overall User Experience and Navigation

In general, the user experience of analytic modelling is aligned with the general SAP Datasphere modelling paradigm with the graphical canvas on the left and a properties panel with details on the currently selected object on the right.

Figure 1 - Functionality Overview within the Analytic Model Interface

Now this is straight-forward and simple. No uncertainties there.

One important catch is to understand what we mean by “currently selected object”.

If you click anywhere on the canvas or into the blue area called “Fact Sources”, you are effectively selecting the Analytic Model’s outer shell, i.e. what it exposes to the world or how SAP Analytics Cloud sees it. These are its measures, its dimensions, its variables and its filters.

Figure 2 - Properties of the Analytic Model itself

This is the place to

Change the Business Name of Analytic Model

Add calculated, restricted & count distinct measures

Add variables and

Add filters.

Because this is the “outer shell” of the Analytic Model and reflects how SAP Analytics Cloud sees the data in SAP Datasphere, it also adopts SAP Analytics Cloud terminology.

Because SAP Analytics Cloud calls anything that can be used for filtering & drilling a “dimension”, the Analytic Model consciously adopts the same term as well. So while the rest of SAP Datasphere uses the term “dimension” only to denominate a view of a certain type and call all its columns “attributes”, the Analytic Model entirely aligns with SAP Analytics Cloud terminology here. This is also why Figure 2 shows 13 dimensions in the listing whereas the canvas obviously only contains 4-dimension views that feed into the Analytic Model: those 13 are the dimensions including all their attributes – but since SAC allows to drill & filter along these attributes and thus calls them “dimensions”, the Analytic Model follows suit.

By the same token, the Analytic Model aligns with SAP Analytics Cloud on what to call data collected from end-users via prompts: in SAP Analytics Cloud, these are called “variables”, and this is also why the Analytic Model adopts this term. This is thus dissimilar from the term used in the SAP HANA world, because there, “variables” & “input parameters” have a slightly distinct meaning.

We are aware that both choices may be a cause of confusion at times, but we see the Analytic Model as the translator or intermediary between the BI world of SAP Analytics Cloud and the data world of SAP Datasphere and SAP HANA and feel that this role is best conveyed by aligning SAC terminology & Analytic Model terminology.

Let’s continue with our navigation journey.

When users now click on the fact source, its properties are displayed.

Figure 3 - Properties of the Fact Source

Here, you can

Set the “alias” of the fact node, though this is really only reflected in the respective canvas node

Add / remove measures that the fact node exposes to the Analytic Model. The Analytic Model will show them as “source measures”

Add / remove dimensions that are directly associated to the fact source.
If the associated dimension is …
- itself of semantic usage “Dimension”, users can choose its attributes and add them as dimensions to the Analytic Model, i.e., something SAC can eventually drill & filter by
- itself of semantic usage “Text”, the respective attribute of the fact will now also expose a translatable description
- itself of semantic usage “Hierarchy”, the respective attribute of the fact will now also offer a hierarchy to use in displaying the data

Add / remove attributes of the fact source. They will appear as “dimension” in the Analytic Model listing. Attributes can also be renamed wrt. technical name & business name by clicking on the > sign to the right of the attribute name

If the fact source itself has an input parameter, users can choose to either set it to a fixed value (“set to”) or to map it to a variable of the Analytic Model (“map to”). If no suitable variable exists yet, a new one can be created. It’ll have the same name as the input parameter, but they can be renamed in the Variable Section of the Analytic Model

Figure 4 - Mapping Input Parameters of the Fact Source to Variables of the Analytic Model

Here, the terminology decision mentioned above becomes very apparent: what is called “input parameter” in the context of relational view modelling is now exposed as “variable” in the context of analytical modelling and of SAC consumption.

If we now switch to a dimension node like Product ID, the properties panel adjusts again.

Figure 5 - Adjustment of the properties panel when selecting a dimension node

The properties panel of the dimension shows where we are via the breadcrumb (AW_W_IP / Product ID). It points out that the source object itself is called MCT_Products and users can immediately open it in a second tab by clicking on the link for MCT_Products or by choosing the arrow icon in the context pad of the canvas (the one above the dustbin). It also points out that the dimension has a single key (Product) whose value in the Fact Source will be used to perform the join at query execution time.

In the properties panel for dimensions (like here the Product ID), users can do a couple of things

Rename the alias under which the dimension group appears in the Analytic Model. By default, this name (Product ID) is taken from the field name used in the source object (here: the fact source V_MCT_OpportunityItems_IP). We chose this as a default name because the fact oftentimes has more semantics to it (“Product ID”) than the dimension itself (which might just use ID or MATNR for the column instead). We’ll see the relevancy of this in an upcoming post on associations with compounded keys.

Select which associations to add. Adding them will have the same effect as outlined above for associations originating in the fact source.

Add / remove attributes. These will appear as drillable dimensions in the Analytic Model and be grouped under a common dimensions whose name is the Alias.To make this more concrete by help of the screenshot above: the Analytic Model will have a grouping node “Product ID” that contains the nodes for ProductCategory, ProductGroup and ProductManager as leaves).

Please note that you can always inspect a node’s data by opening the data preview icon in the icon bar. This is regularly overlooked but can be very helpful in order to understand the source data in the participating entities. It also showcases quite interestingly how relational worlds (a node and its record-by-record data) come together in an Analytic Model. The latter combines all these sources into a query-able whole that SAP Analytics Cloud then consumes. To preview that “whole”, the Data Preview in the top right is used, because it gives you the analytical perspective on the data whereas the preview on the bottom gives the relational (record by record) preview of the participating views or tables.

Figure 6 - Data Preview when selecting a dimension node

Conclusion

This blog discussed the User Experience of analytic modelling in SAP Datasphere, the important difference between the Analytic Model as a whole and the parts or entities it relies on on the other hand. Because of this difference, certain modelling actions can only be done in certain areas of the environment and this change is also reflected in the terminology. Many Thanks to jan.fetzer for the collaboration on this blog post.

Thanks for reading! I hope you find this post helpful. For any questions or feedback just leave a comment below this post. Feel free to also check out the other blogposts in the series.

Best wishes,

Philine