SAP Datasphere - Modelling master data - best practice?

[#1]

Hi everyone,

while implementing a reporting area in Datasphere, maybe some of you regular asking the question what is the best way to model this or that. Also with new releases of Datasphere, some new features will be introduced which could make something easier.

Now I'm challenging with the question: What is the best way to model master data and texts?

Unfortunately I didn't find a hint in the Development Guidelines and Naming Conventions by klaus-peter.sauer4 and others.

Tables can have a semantic type (Dimension, Text). These tables could also have associations.

At the moment, I create separate dimension- and text-views. But there is often no logic behind and the source data is used 1:1.

• The benefit of using separate views is the flexibility. We can harmonize data, filter (if required). But what if it's not required?
• Should we use the semantic usage in tables if we although building views on top?
• Is a text-view recommended even if there is no separate text-table (like customer / KNA1 in an SAP ERP table) and we can use the semantic information text directly within a dimension-view?

The development guide has a strong focus on performance: "Keep it simple". Following this approach I would say that the possible overhead of additional views (if they are not required) should be avoided.

Questions over questions. I'm interested in your opinions. Maybe there is a official statement of direction by SAP regarding the modelling approach of master data within SAP Datasphere.

Best regards,

Dominic

[XaviPolo]

The main reason or advantage of tables or views with semantic "Text" is that they allow multiple languages to be used in the data (using the language column and the semantics "language") and the data will be filtered using the user's language at display time.

This is a complex thing to obtain if you do not use this type of model.

But when you only have one language they may not contribute too much, since you can implement the ID/Description operation using the semantics of the fields in the dimension.

Perhaps, I would emphasize that the associations, whether text or dimensions, allow by definition the "prunning join" in the database, that is, if the query is not using a field of the table to join, the join is not done.

This behavior can also be achieved by making joins in the views, but here it depends more on our expertise.

In my case, what I usually suggest is to use text views if there is multilingualism, and if not, to create the dimension view with the texts already included and the semantics defined in the view.

Regards,