Skip to Content
Technical Articles
Author's profile photo Philine Apholz

SAP Datasphere Analytic Model Series – Motivation & Comparison with the Analytical Dataset



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 third in the blog post series and highlights the motivation for the new artifact and draws comparisons to the Analytical Dataset conceptually as well as w.r.t. feature details.

So far, the following blogs have been published:

Let’s start by taking a closer look at what an Analytical Dataset “really” is.


Properties of the Analytical Dataset (ADS)

Views modelled as a graphical or SQL view are initially always of the semantic usage “Relational Dataset”. This implies that upon deployment, a relational, SQL-consumable database view will be created in the HANA cloud database powering SAP Datasphere.

At some point in time, users can select to change the semantic usage to “Analytical Dataset”. This enables some additional features in the view’s design-time that are important for subsequent consumption of the view by SAP Analytics Cloud. These new features consist of mainly:

  • Classification of view columns as either attribute or measure (including its aggregation type)
  • Possibility to add semantic type information to columns. This way, modelers can add a usage context that classifies a column for example as label, currency, unit, business date (relevant for time-dependency) etc.
  • Adding of associations to other entities like text or dimension objects

For a good example of this, please load the example data model of the blog series and inspect its exact properties w.r.t. semantic types & associations between entities.


On deployment of the Analytical Dataset, there will now be TWO runtime artefacts generated on SAP HANA Cloud, namely

  1. An analytical, SAC-consumable star schema
  2. A relational, SQL-consumable database view

Figure 1: Runtime artefacts of Analytical Datasets


Both of them come under the name of the Analytical Dataset itself, but

  • one allows for relational queries, typically via SQL (e.g. when using an OpenSQL schema) and “lives” on HANA’s SQL engine. Its data is displayed when you preview the Analytical Dataset in the View Builder
  • the other one allows for analytical queries and “lives” on SAP HANA’s Multi-Dimensional Services (MDS) engine. It is queried by SAP Analytics Cloud via the Information Access (InA) protocol.


For the comparison with the Analytic Model, let’s focus on the analytical star-schema artefact only.

Since the focus of the Analytical Dataset was always to make analytical consumption of the underlying view data extremely simple, it needed to make sacrifices with regards to the complexity of the analytical modelling itself. Concretely, these are:

  • Measures in Analytical Datasets always use standard aggregations only.
    These are SUM, MAX, MIN, COUNT and NONE. Other, more complex measures can be built in SAP Analytics Cloud stories
  • Users cannot decide which columns and associations are provided.The system automatically exposes all measures & attributes of the Analytical Datasets and always includes all first-level dimensions into the star schema also. By first-level dimensions we mean dimensions that are directly associated to the Analytical Datasets. If those associated dimensions themselves bear associations to yet other dimensions, then these will not be included. We’ll look at example cases further down in the post.


Motivation of the Analytic Model

The Analytic Model now goes beyond the analytical capabilities of the Analytical Dataset and introduces a full-fledged modelling environment that allows for a richer, targeted modelling of the properties of the analytical consumption by SAP Analytics Cloud.

If we try to heal these shortcomings within the Analytical Dataset editor, the design-environment of the Analytical Dataset would become overly complex while further mixing relational and analytical modelling in the same object. SAP therefore consciously decided to fully separate relational from analytical modelling, which lead to the introduction of the Analytic Model. This provides unique capabilities and a targeted modelling environment, including:

  • Modelling of calculated measures, restricted measures and count distinct measures
  • Modelling of exception aggregation behaviour on source measures and restricted measures
  • Explicit decision of which measures and attributes to include
  • Explicit decision of which dimensions – first-level or nth level – to include
  • Analytical Data Preview for immediate, integrated testing of the current state of modelling and data with full support for slicing & dicing, filtering, hierarchy support, pivoting & much more
  • Name changes for attributes & dimensions
  • Design of which information to collect from end-users via variable prompts
  • Global filter support
  • Etc.


Aggregation Behavior – Head-to-Head Comparison

While the Analytical Dataset provides base measures with base aggregation types only, Analytic Models allow for sophisticated modelling including calculations after aggregation, restricted measures, count distinct measures as well as exception aggregation.

Figure 2: Aggregation Behavior in Analytic Model (left) & Analytical Dataset (right)


Choice of Dimensions – Head-to-Head Comparison

The Analytical Dataset represents a “default cube”. It exposes all first-level dimensions automatically, but none of the deeper levels (in the screenshot: only MCT Products). By default, this is wise since nested dimensions lead to potentially long joins at runtime paths that can weigh heavy on performance. Since many models, particularly SAP standard models imported from SAP S/4 HANA include dozens to hundreds of dimensions, many of them nested, dedicated pruning is absolutely required.

Figure 3: Analytical Datasets only include first-level associations


Modellers of Analytic Models can indeed consciously select (“prune”) which dimensions and attributes to expose (in the screenshot: all). If selected, such nested dimensions are offered on the top-level of the SAP Analytics Cloud dimension dialog. Technically, this means that the snow flake schema is simplified to a star schema and that the system automatically takes care of the joins required to achieve this.

If associated dimensions are included, their node name is taken from the respective source field (in the screenshot: e.g. Product Manager in MCT Products or Manager in MCT Employees), however this can be adapted by the modeller in the details dialog of the dimension properties in the Analytic Model editor.


Figure 4: With Analytic Model, users can choose which reachable dimensions to include


Data Preview

Analytical Datasets only offer a relational data viewer (i.e. by record), forcing users to build a SAC story to check their data and modelling. Analytic Models, however, have a built-in analytical data viewer with rich attribute/measure selection, filtering and pivoting, hierarchy support and many more features.

The View Builder used for creating the Analytical Dataset includes a data preview, but it only shows the relational artefact of the Analytical Dataset. If users want to check the results of their analytical modelling (e.g. of the information around measures/attributes, semantic types and associations), they will typically build a story in SAP Analytics Cloud to see it.

The new Analytic Model however has a built-in analytical Data Preview that provides rich functions, such as:

  • Flexibly choose relevant attributes & measures to place them in columns or rows; drag & drop to re-arrange
  • Set flexible filters on any attribute or measure incl. value help
  • Display of hierarchies or flat presentation
  • Change sorting, filtering, totals, unbooked values & display behavior (e.g. ID and/or description, number formatting, etc.)
  • Preview without need to deploy first

Figure 5: Data Preview Comparison in Analytic Model (left) & Analytical Dataset (right)



For the terminology used in the Analytic Model, SAP chose to align with the terminology of SAP Analytics Cloud. This means that

  • data collected from reporting users via prompts is called “Variables”. Analytical Datasets however talk about “Input Parameters” because they will eventually be parameters of the relational HANA view that is generated. Analytical Datasets have no equivalent to the Restricted Measure variables, Filter variables & Key Date variables of Analytic Models though.
  • any column exposed by the Analytic Model for drill-down is a “Dimension” and this is also how they’ll be presented in SAP Analytics Cloud when choosing e.g. rows or columns of an SAC widget. In Analytical Datasets, the individual columns are known as “Attributes” and dimensions are the entities that are associated from it.

We understand that the terminology difference is subtle, but it is due to the position of the Analytic Model as a mediator between the worlds of relational artefacts (and their terminology) and their analytical consumption in SAP Analytics Cloud (with its slightly different terminology).


Analytical Datasets or Analytic Models – which one should I choose?

With Analytic Models being the cleaner and more feature-rich way of exposing data for analytics, SAP is clearly positioning Analytic Models as THE go-to alternative for analytic consumption. You should definitely try them out for yourself and start experimenting to experience their benefits. Since Analytical Datasets will not go away in the near future, however, there is no immediate rush regarding this.

To make messaging and modelling even clearer, SAP will very soon introduce a new semantic usage, “Fact”, that looks and feels identically to an ADS in the design-time. The core difference is though that Facts will only deploy as relational objects and not as analytical objects. The analytical part should be modelled on top in the form of Analytic Models.

Once Facts are introduced, SAP will increasingly discourage the usage of Analytical Datasets also in the modelling environment. For example, warnings will be issued when new Analytical Datasets are created with information to instead use the combinations of Facts (for the relational part) and Analytic Models (for the analytical portion). The SAP Help Documentation will give additional guidance here.



This blog introduced how the Analytic Model differs from Analytical Datasets, with its superior functionality in many regards, but especially in the realms of measure modelling, dimension modelling, user interaction and data previewing. Many thanks to Jan Fetzer for the collaboration on this blogpost.

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,



Further Links


Find more information and related blog posts on the topic page for SAP Datasphere.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Thomas Bodenmueller-Dodek
      Thomas Bodenmueller-Dodek

      Great blog and a good head-to-head comparison.

      BR Thomas

      Author's profile photo Ahmed Ali Khan
      Ahmed Ali Khan

      Great Blog and thanks for sharing this valuable information.


      I am still confused when to go for which modelling comparing SAP HANA Cloud Modelling vs SAP Datasphere.


      I believe it's a very thin line on choosing any of these two but if you can share some blogs some evidences which can help customers to choose when to choose SAP HANA Cloud Modelling vs SAP Datasphere modelling it would be really helpful.

      Author's profile photo Philine Apholz
      Philine Apholz
      Blog Post Author

      Hi Ahmed,

      Thank you for your comment.

      From an approach perspective we recommend to always start with modeling inside of SAP Datasphere leveraging the Data Builder Graphical and Scripted. In case functionality is required that cannot be covered by the internal modelers, such as Data Anonymization, complex scripting functionality, and advanced Calculation View modeling, then customers should diverge towards the Open SQL schema and the SAP HANA Deployment Infrastucture (HDI). However, you should keep in mind when orchestrating the flow of data by the means of View Persistencies, etc. that only objects which are part of SAP Datasphere native modeling can be used.

      Hope this helps!

      Best regards,


      Author's profile photo Ahmed Ali Khan
      Ahmed Ali Khan

      Hin Philine,


      Thanks for your answer, I am just curious to know have you or anyone you know faced any such situation where SAP Datasphere capabilities were not enough and you have to go SAP HANA HDI approach, If can you can share what was that scenario it would be really helpful to help customers to choose from these two in a better way.


      Best Regards


      Author's profile photo Ian Dempsey
      Ian Dempsey

      Great blog explaining the comparison between the two models in detail! Thanks for the examples with screenshots as well.




      Author's profile photo praveen kumar
      praveen kumar

      Great blogs and thanks for sharing

      Author's profile photo Tanka RaviChandra
      Tanka RaviChandra

      Great Blog and thanks for sharing the valuable information. I have one question : What artifact will it generate when we deploy the analytics model and how to view it ?

      Author's profile photo Philine Apholz
      Philine Apholz
      Blog Post Author

      Hi Tanka,

      Thank you for your comment.

      When deploying an Analytic Model, a set of artefacts are created that represent the runtime for executing analytical queries as well as a description for SAC on how to consume the analytic object and post correct queries against it. Technically, you’ll see a set of column views in the HANA Database Explorer (provided you created a DB user in space management). The other objects are internal and not accessible.

      Hope this helps!

      Kind regards,