You are not using a modern browser version. As a result, the website may not be displayed correctly. You can find more information here.

Making changes in SAP HANA Calculation Views – Part 1


In the area of data modeling on the SAP HANA database, many users benefit from the ability to use calculation views. Here the data model is implemented using a graphic modeling. As soon as a calculation view has been created and activated, it can still be used as a data provider/source (e.g. as a source in a composite provider)..

Figure 1 – Example of a calculation view

It has proven effective when modeling a calculation view not to use the predefined structure of a calculation view, but instead to add an aggregation/projection and a union behind the semantics/aggregation/projection (see Figure 2).

Figure 2 – extended semantics logic

This allows the developer to filter attributes directly in the “Aggregation_1“ later when running or testing the calculation view for testing and debugging purposes. But now we will see why the union makes sense. One major problem in the modeling of calculation views is changes or extensions of the model. Here we’re not talking about a simple name change, or the addition/removal of an attribute or the creation/change of a calculated column. The problems arise when adding or extending the model with new data or when removing a join. For example, here the mapping in Figure 1 would be deleted and all the names and aggregations would be lost, resulting in a creation of a new name or the change of a name (see Figure 3).

Figure 3 – New Join Before / After
Figure 3 – New Join Before / After

By using the union mentioned above, although the mapping and the union of “2_18_Join” is deleted, the upward structure remains and does not have to be renamed or edited (see Figure 4).

Figure 4 – Using a UNION

Over time, inserting the union mentioned above has proven effective in avoiding extra work when making changes. For newly developed products, it therefore always makes sense to create unions the same way as a buffer between individual joins.

This process is useful and makes sense for newly developed products, but what can the developer do for previously existing calculation views that were not modeled this way and need to be changed? An answer is provided in the second part of this blog, where we show how you can greatly simplify or get around the new modeling and mapping.

Nehmen Sie Kontakt zu uns auf!

    I hereby consent to my personal data being collected, processed, and used for the purpose of processing my inquiry. I may revoke my consent anytime without stating my reasons for doing so. More information can be found in our privacy statement.