Difference in HDI modeling compared to repository modeling

In HDI modeling the last node (Default node) of Calculation Views shows a different aggregation behavior
than it shows for Calculation Views in the old HANA repository.
Differences can occur when
a) filters are applied on measures in the end user query
b) the end user query requests a different aggregation behavior than the behavior defined in the
Default node, i.e., the last node below the Default node
The overall motivation for a different treatment of the Default Node in HDI was to make the Default
Node overwritable by the end user query to avoid unexpected aggregation behaviors. This
overwriting of the modeled aggregation which leads to a kind of transparency of the Default Node to
the end user query will be discussed in more detail under b)

Case a) filter on measures used in the end user query

If a filter is applied on a measure in the end user query and the last Node (“Default Node”) in the
Calculation View that is used in this end user query is an aggregation then the filter can either be
applied before or after the aggregation of the Default Node.
In the old repository the filter was applied after the aggregation. In HDI the filter will be applied
before the aggregation. The reason behind this change is that given the intended “transparency” of
the Default Node to the end user query as mentioned above, filters of end user queries should also
“pass through” the Default Node to make the behavior more consistent from an end user
perspective.
The old, i.e., the behavior of the old repository can still be achieved by a slight change to the model.
We will illustrate the difference in behavior between old repository and new HDI behavior and a
modeling option to restore the old behavior with the first example.

Examples
Use the following statements to create a table and fill the table with values. This table will be used
throughout the examples:

create column table tableWhereFilterOnMeasure (article NVARCHAR(20),sales int);

insert into tableWhereFilterOnMeasure values ('Bike',400);
insert into tableWhereFilterOnMeasure values ('Bike',700);
insert into tableWhereFilterOnMeasure values ('Bike',1100);
insert into tableWhereFilterOnMeasure values ('Car',10000);
insert into tableWhereFilterOnMeasure values ('Car',35000);
Example a)
Create a Calculation View in SAP HANA Studio (old repository) with Default Node of type Aggregation and
consume this table:
Apply a filter on SALES for values larger than 1000 by running the following query:
SELECT
"ARTICLE",
SUM(sales)
from
"_SYS_BIC"."…/ON_TABLEWHEREFILTERONMEASURE"
WHERE
sales > 1000
GROUP BY
"ARTICLE"
If you filter on the measure “SALES” for Calculation Views in the old repository then the filter will be
applied after aggregation has taken place. This means that first the measure of all Bikes and Cars are
summed up to result in

Applying the filter for sales > 1000 afterwards will not remove entries because all aggregated values are
above 1000. Therefore, you will see the following results being returned:

Now let’s turn to modeling in HDI and recreate the same model in SAP Web IDE for SAP HANA:
Running the same query will return different results:

The reason is that now the filtering for sales>1000 is done before the aggregation. Therefore, the values
400 and 700 of Bike are filtered out first, which leaves only one value for Bike to be aggregated:

If the old behavior should be restored an aggregation node can be put below the Default node and by this
force the aggregation to happen before the filtering. The reason that this works is that the filter on
measures only “passes” the Default Node but not further aggregation nodes below:

leads to:

In sum, modeling the view in SAP HANA Studio will apply the filter after the Default Node aggregation.
Modeling in SAP Web IDE for SAP HANA will apply the filter before the Default Node aggregation. If you
want to achieve the old SAP HANA Studio behavior you will need to add an additional aggregation node
below the Default Node.
Case 2. Aggregation behavior for measures
If an end-user query defines a different aggregation function than is defined in the Default Node the
behavior of models created in SAP HANA Studio will calculate the user query aggregation after the Default
Node aggregation. Models created in SAP Web IDE for SAP HANA will replace the Default Node
aggregation with the aggregation of the user query.

As an example let’s use the model from above but change the aggregation of the Default Node to "Count"

Running the same query from above but without the filter to avoid confusing effects of a) and b)

SELECT
"ARTICLE",
SUM(sales)
from
"_SYS_BIC"."…/ON_TABLEWHEREFILTERONMEASURE"
GROUP BY
"ARTICLE"

will lead to:

What happens is that Count is first executed resulting in 2 for Car and 3 for Bike. This is afterwards
summed up as requested by the SQL query. Given that the SQL Query does not remove a column and thus
keeps the same aggregation columns the result does not change anymore by the SUM aggregation.
However, it might come as a surprise to the end user to see Count values while the end user query
requests SUM values. Also the other way around would be surprising. Imagine the Default Node
aggregation of SUM is followed up by a Count defined in the end user query. In this case Count would
work on the summed values and therefore only return 1 for each ARTICLE.
This surprising behavior has thus been changed in HDI and if you run the same query on the same model
but deployed in HDI you will see the following results when the end user query requests SUM:
The aggregation “SUM” that has been defined in the user query has replaced the aggregation behavior of
the Default Node.
Analogously, if the end user query requests Count you will, irrespective of the aggregation defined in the
Default Node see:

Again, if you wanted to reproduce the old behavior you would need to add another aggregation node
before the Default Node. This will force the aggregation defined in the lower aggregation node to be
executed and not being overwritten by the aggregation that is defined in the user query:

Even if the end user query requests SUM the result will contain the Count values (followed up by the SUM
defined in the end user query)