Skip to Content
Technical Articles
Author's profile photo Gregory Rohloff

SAP Datasphere Naming Convention in Action


1: SAP Datasphere Naming Convention in Action (Source: SAP)


Naming conventions help to establish a cross-functional structure and to maintain an overview in data warehouse projects. Since it is not always possible to predict how an existing project will develop, it is advisable to adhere to naming conventions consistently right from the start. In this blog post, suggestions are made for adhering to a consistent naming convention based on the example of the SAP Datasphere Data Challenge. These suggestions are meant as recommendations and can of course be customized along individual requirements. The focus of this blog post is on Modeling Objects and provides the reader with a quick overview of the topic – further resources are referenced.


Layer architecture for data warehouses

Modeling concepts for data warehouses are usually based on a layer architecture. Layers are logical groups of different entities (e.g. tables, views, data access controls, etc.). The following Figure shows a structure of such a layer architecture that has proven itself in practice.



Layered modeling approach (Source: SAP Datasphere First Guidance)


It is introduced within the new first guidance document development guidelines and naming conventions document which goes into further detail about each layer.

Recommended approach and considerations

The following considerations should be taken into account during the implementation of the Naming Convention. Depending on individual needs, this approach can be implemented for an entire SAP Datasphere Tenant or individual Spaces.


Before the artifacts of a project are created in the SAP Datasphere, essential contents of the project such as required subject areas should be roughly outlined. This is particularly important because the technical name of an object cannot be changed after it has been saved. Artifacts that have already been created would have to be replaced.

Setting the structure

In the next step, a uniform structure of the Naming Convention (for the technical names) should be defined and adhered to. The following structure serves as an example and can be used as a template:



Naming Convention Structure (Source: SAP Datasphere First Guidance)


1. Layers and variants

A common modeling approach is to use stacked models with different layers. Therefore, it is useful to recognize already in the name of the object to which layer it is assigned. This also applies to the object type and different variants of tables or views. Either numbers or letters are suitable for this purpose (e.g. “A” = Analytical; “R” = Reporting; “H” = Harmonization; “P” = Propagation).

2. Topic Area

In some cases several Topic Areas are stored in one Space (e.g. cost center as one area in a financial Space). Here it can be helpful to include the topic area in the name.

3. Object Name

The object name should describe the object itself. If necessary, more than six letters or characters can be chosen for the object name.

4. Number

Finally, it may be useful to append a two-digit number. This is especially relevant when multiple versions of similar artifacts are used for different purposes.


From these considerations, the above structure can be applied to two specific examples from the SAP Datasphere Data Challenge as follows:

1TR_EXC0_KBAQ01_01 – for a relational table for german car registrations in Q1 (Inbound Layer (1st))

4VA_EXC1_NCDEQ2_02 – for an analytical view for new registered cars in germany in Q2 (Reporting Layer (4th))


The following figure gives an overview of how the object types and variants can be abbreviated within a SAP Datasphere project.



Abbreviation Table (Source: Own Image)


Procedure during the SAP Datasphere Data Challenge

Figure 4 shows an example of a concrete use case of the naming convention and how it was implemented within the SAP Datasphere Data Challenge. In the following, the selected naming convention is explained using this example across the different layers.

Inbound Layer

Relational tables from the SAP Datasphere Data Marketplace are used as the data source within the inbound layer. Since this is the first layer, a “1” was used as a prefix. Since these are relational tables, “TR” was chosen for the naming of the object-variant combination in each case (see Figure 3). The Topic Area concerns tasks 1 and 2 of the SAP Datasphere Data Challenge, “EXC0” and “EXC1”. The Object Name was chosen individually, but should be as meaningful as possible despite the limitation of the number of characters.

Harmonization Layer

In our example, the relational tables of the inbound layer were further processed in the harmonization layer using filters and saved in a relational view. Analogous to the procedure within the inbound layer, a “2” and the combination “VR” for relational view were selected here.

Propagation Layer

The Propagation Layer represents the third stage and contains the Intelligent Lookup, hence the naming of the Layer – Object Type – Variant “3IL”.

Reporting Layer

The Reporting Layer contains the analytical view, “4VA”, which can be consumed for reporting purposes.



Naming Convention applied on different Layers of the Data Challenge (Source: Own Image)


This blog post is intended to provide a quick introduction to the topic of naming conventions within the SAP Datasphere. The above procedure serves only as a recommendation and orientation. Of course, a different naming convention can be selected if required. It is only important that the defined structure and the naming of the artifacts are consistently adhered to throughout the project.

Thanks for reading! I hope you find this post helpful. For any questions or feedback just leave a comment below this post.

Many thanks to Oliver Huth and Tim Huse for their great support in writing this blog post.

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

If you have questions about SAP Datasphere you can submit them in the Q&A area for SAP Datasphere in the SAP Community.

Assigned Tags

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


      I have few points to discuss:

      1) why business content proposed by SAP is not compliant to any of these logic?

      2) why every package of business content has its own naming convention

      3) i think VS is useless if used to identify a sql view... It is more useful to identify a view used as source for a DAC. V= view, S = security.

      4) please provide some folder structure in data builder, because it is nearly impossible to manage more than 1 real world project in the same space


      Author's profile photo Regis Zang
      Regis Zang

      Great point -  I think the Name convention and structure by LSA it is like "drawers" - and anyone used them with your good or not.----

      I really like to use LSA since SAP BW and I know for some developers was so boring. but indifferently if we have inheritances, packages and folders.

      My point of view it is a company decision.


      Author's profile photo Peter Haerle
      Peter Haerle

      Hi Gregory,

      thanks, this is very interesting.

      While at first glance these naming conventions sound reasonable, I fear the categorization used in this approach is tailored for specific analytical scenarios and may not be generally applicable, e.g. it does not support differentiating:

      • SAP vs. customer content
      • SAP data vs 3rd party data
      • Application internal vs. cross-application content (note that there might be even multiple 'cross' layers: SFSF core vs SFSF BTP, SFSF vs S/4, etc. etc.)
      • Content artefacts which are (re-)used in multiple “Layers”
      • What about scenarios which don’t require e.g. a “Propagation Layer”?
      • Commercialized content vs. "free" content
      • Content artefacts in HDLF vs HANA
      • Content artefacts used for AI scenarios
      • Content artefacts resulting from AI scenarios


      • Abbreviations for object types (VR, VD, etc. etc.) are redundant information.
        Better would be own namespaces for each object type.
      • How to handle future changes in the content structure?
      • How to deal with legacy content which does not follow this nomenclature?
      • How does this nomenclature apply to the "Data Product" concept?

      Any ideas how to tackle these (and probably) scenarios?

      Thanks and best regards,

      Author's profile photo Martin Kreitlein
      Martin Kreitlein

      Hello Gregory Rohloff,

      nice blog... but like Alberto mentions... a folder structure, which you can customize to your needs - like the Infoareas in BW, in the good old times - would be way more helpful than a pure list where you collect hundreds of objects in it and the only possibility to find what you need is the small search box, on the top right corner 🙁

      Honestly, why do you just ignore standards, which have proven to be helpful since years? I mean, even in Windows 10, you still have your folder structure.

      When will you open the Influence pages for everyone so that we can post neglected topics?

      Thanks and BR, Martin