Background:

In an agile data mart solution, we build few attribute views, one more analytic view and few calculation views (if any). All attributes (master data or dimensions) and measures (facts or key figures) may not be readily available in the underlying table. That's when we consider building calculated attributes or calculated measures.

Problem Statement:

1. Calculated Attribute:

As of HANA SP06 (Revision 69), we can build calculated attributes (YEAR) in the context of Attribute View (AT_VIEW) as shown below.

However, if this Attribute View is used in an Analytic View, It will actually be created as a Calculation View.

See below. The AN_VIEW is actually an calculation view (wrapper) and AN_VIEW/olap is the analytic view. Without the calculated attribute, there would been only one view AN_VIEW (without "/olap" in the name) as an analytic view

So since the wrapper calculation view is created, there will be data transfer between OALP engine (analytic view) and CALC engine (calculation view). Hence impact on perforamance.

Alternately, if you create the calculated attribute in the Analytic View (instead of defining in the Attribute View), You'll also have the exact same issue.

2. Calculated Measure:

*** THIS IS NOT A ISSUE ANYMORE *** (at least as of HANA SP06 Revision 69)***

Before HANA SP06 (Revision 69), If you create an Calculated Measure (In an Analytic View) referencing an Attribute as shown in the example below (attribute EFF_DATE is referenced in the calculation), It will also create the wrapper calculation view.

However I've good news for you. This is not a issue anymore (at least as of HANA SP06 Revision 69).

3. Input Parameter & UOM/Currency Conversion: If your Analytic View still has Input Parameter and UOM/Currency conversion, it will still create a wrapper calculation view, since these calculation still occur in the calculation engine.

Please see SAP Note 1993033 for more details.

Solution Options:

Possible solution options for Calculated Attributes are

• Option A: Materialize the column in the underlying table: Create an additional column in the underlying table and expose this column as an attribute. Use data service (or other ETL tools) to load data to the table.

• Option B: Create a calculated column in the underlying table: Use ALTER sql-statement to create a virtual column in the underlying table and expose this column as an attribute. This is similar to option A, however data is not being loaded into this column

     altertable"ABANI"."ZT_TEST

     add ("ZZYEAR"NVARCHAR(4) generated always as '2010');

• Option C: Create calculated attributes in the context of a calculation view (if you have one)