Skip to Content
Author's profile photo Daniel Spokoinyi

Public Dimensions in SAC – manage query volume & master data management with imported data

Hello world,


after a few successful implementations of SAC at customers with imported data in- memory. I thought I would share my experience of working with Public Dimensions.

In SAC different connections are possible, all with specific use cases: in my projects at CTAC, I worked with Public dimensions, with a BW import connections, SQL & ERP infosets, and in each case it showed to be added value!

As there is already a great Blog posted on working with Public Dimensions, I will focus on some other aspects of using Public Dimensions, which have to do more with the back end set up and the advantages for the data load.


Main Advantages of working with Public Dimensions


  1. Reduced data load
  2. Easy separate modelling of dimensions (hierarchies, attributes) in separate back end queries
  3. Master data can be scheduled separately in the back end 
  4. A better structure of master data attributes under each dimension 
  5. Reusability between different models

Reduced data load

A reduced data load of Columns is a major advantage on optimising queries importing data into SAC. It is only necessary to take the corresponding key of the Public Dimensions, which limits the amount of Lookups of corresponding data entries for the query.

At one of our customers this was crucial, as we quickly went against the limit of data cells allowed to be transferred from BW to SAP AC, and it substantially reduced the running time of a query.

Separate Master Data Modelling 

The advantage of separately modelling Hierarchies and attributes allows users to create a certain logic in the back end and transfer this logic to the front end.

Hierarchies in SAC are parent- child, maintained by having a  unique Child- ID which is unique for each level (best to use a unique compounded key which can be found in the data query as well) and a corresponding parent column.

Note:The parent- ID have also to be mapped as children ID’s. Might be a bit confusing in the beginning, maybe it will even change in future.

Note 2 for the users of BW: you will need to map all your attributes and hierarchies as characteristics of an infoObject.

For the hierarchies, we created a DSO where we mapped the different Hierarchy ID levels with the corresponding +1 parent level, and used this DSO as a characteristic of a new InfoObject.

These can be added to existing Public Dimensions, or new one’s can be created. Here an example


Clear Structure of Master Data Attributes 

For a self- service tool, a clear structure of all Dimensions and attributes is very important, to guide the end user to the right items, and allow them to easily navigate through your data.

Attributes of Master Data items are a great way to provide this structures, where the BW characteristics of Info- Objects easily can be transferred into SAP Analytics Cloud.

Here an example, where we have separated the attributes linked to a Material Group with attributes associated with a Material Sales Group and mapped each one of them in a Public dimension



To mention, there are 2 clear disadvantages of using attributes versus dimensions:

  1. Attributes can currently not be used in the explorer, or in Geo Maps as dimensions
  2. If you need the ID and the Text of attributes (For sorting purposes), you have to map those as separate attributes, which makes the oversight less good.

Scheduling in the back end

I experience this as a major advantage of using Public Dimensions.

As mentioned above, it reduces the data loads of transactional data, while also allowing you to create dedicated queries for the Master Data items.

In certain cases it might be not necessary to load the master data daily. Keep in mind: if you load transactional data, when the master data has not been loaded yet, all unknown master data ID’s not yet mapped in the Public Dimension will be rejected.

I would suggest to schedule the master data daily before the load of the transactional data

In this example, there were 2 rows rejected because of a “new unknown member” linked to a Public Dimension.


Summary: When best to use Public Dimensions

I would recommend using Public dimensions when

  • Having several attributes linked to a Master Data Item
  • Creating more complex Hierarchies in the back end
  • Having Master Data which needs to be reused
  • Having trouble with data loading sizes


Into the future


It is my hope that also SAP will continue to invest in the Public Dimensions, I find it a great way to manage master data, and hope that attributes will soon become available in the explorer and Geo Maps (worth a vote on

I also hope that SAP will introduce more specific features which will make working with Public Dimensions easier (empty all fields, Flat Hierarchies, easy to navigate through attributes).

Final Comments 

So, from me: I highly recommend you to start using Public Dimensions for your master data.

Hope this Blog will help to understand some more features.

Any questions, ideas, disagreements…. let’s have a discussion below. Especially if you want to add some more best practice to it!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Clement LENGLET
      Clement LENGLET

      Great blog.

      One additional con to using public dimensions is that not all standard datasources are supported for scheduling refresh. For example it is not possible to schedule based on a SAP ERP (ECC) connection.

      In that case you will need to use a private dimension and use transactionnal data load based on Infoset or SAP Queries which does also create missing members and their attributes. At least one measure is required but it can be created on the fly by duplicating a column and filling it with zeroes. Sames goes for other dimensions which you can fill automatically with # member or by creating another dummy column.

      Author's profile photo Daniel Spokoinyi
      Daniel Spokoinyi
      Blog Post Author

      Hi Clement,


      We have used Odata services for our customer with a SAP ERP connection, and it worked very well for the master data.

      Author's profile photo Facundo Veiga
      Facundo Veiga

      Hi Daniel,


      Thank you for the post, I have the same question that say Miguel below, do you have some detail of how to implement the Odata services in ECC for connect with SAC?


      Thanks in advance.


      Best regards



      Author's profile photo Miguel Forniels Moreno
      Miguel Forniels Moreno

      Hi Clement,

      Thanks for your blog. I am working with SAP ERP and SAC and I need to load data to public dimesion. Could you tell me some details about how to implement my purpose with Odata services? Any how-to guide? My SAP ECC version is 7.4.

      Thanks in advance,


      Author's profile photo Miquel Fornieles Moreno
      Miquel Fornieles Moreno

      Sorry, my question is for Daniel Spokoinyi.



      Author's profile photo Pavel Afanasiev
      Pavel Afanasiev

      here is something that I can't figure out if possible in SAC - the notion of Transitive attributes?


      I've created public dimensions, and one of my challenges is that I need to create a dimension1 as an attribute of another dimension2 and then link it to the transactional data.  There are reason for this:

      1. we need to reflect the current assignment of Dimension1, even if we have to realign the data.
      2. we need to apply a hierarchy on dimension1

      the approach is the following: we have 2 public dimensions: Cost Center and Employee.  Both have hierarchies on them and additional attributes/properties.

      There is an employee that is assigned to a cost center to identify ownership, and we want to aggregate them into a higher level leader using the hierarchy on Employee.  What we are trying to do is create a model where we can have nested dimensions (Cost Center being the only dimension in the model), as every time there is a change in the Employee assignment to Cost Center, we don't want to drop and reload the fact table

      any thought?