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
- Recommended approach and considerations
- Procedure during the SAP Datasphere Data Challenge
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.
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:
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.
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.
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.
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.
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.
The Propagation Layer represents the third stage and contains the Intelligent Lookup, hence the naming of the Layer – Object Type – Variant “3IL”.
The Reporting Layer contains the analytical view, “4VA”, which can be consumed for reporting purposes.
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.