HANA DBintermediate
HANA Calculation Views
Building reusable, HANA-native data models using graphical and script-based calculation views in SAP HANA modeling tools.
A calculation view is HANA's own modelling layer, built visually rather than written. It predates ABAP CDS views and still matters wherever there is no ABAP layer.
A graphical calculation view is like a flowchart-based recipe where each station (node) does one clear step - trim, mix, bake - visually wired in sequence; a script-based calculation view is handing one station a free-form written recipe card because the step is too intricate to represent as a simple flowchart box, used only when genuinely necessary rather than by default.
Key Concepts
1
It is a graph of nodes, not a query.
projection pick, rename and filter columns from a source
join combine two sources
union stack compatible result sets
aggregation group and summarise
-> final node, which is what consumers query2
You wire them together in the modeller and the engine generates the execution plan. Because the structure
is declared, HANA can reorder and prune it — including skipping branches whose columns nobody selected.
3
Graphical or scripted. Graphical views are built entirely through nodes and are the recommendation:
readable, maintainable, and fully visible to the optimiser.
4
A scripted view embeds SQLScript for logic the nodes cannot express. It works, and it is opaque to the
optimiser, so SAP's guidance is graphical unless you genuinely cannot.
5
The semantic type matters for reporting tools. A view can be typed as a cube — measures and dimensions
declared — so a BI tool knows which columns to aggregate and which to group by.
6
That is the same measures-and-dimensions idea as the analytical annotations on CDS views. Both exist so a
reporting tool can present the model without being told separately what each column means.
7
Input parameters are a performance feature, not just a convenience. A variable filters at the output; an
input parameter can push a filter down into the nodes:
8
filter at the end read 40 million rows, aggregate, then keep one year
filter pushed down read one year's rows, then aggregate9
Same result, a fraction of the work. Views whose parameters are used only at the last node are a common and
easily missed performance problem.
10
How this relates to CDS views. Both model data over HANA, and which you use depends on what surrounds
them:
11
CDS views the strategic layer for ABAP development.
In transports, consumable by RAP, Fiori and
embedded analytics.
calculation views HANA-native data marts, BW/4HANA's own modelling,
and applications with no ABAP stack.12
In an S/4HANA extension project, CDS. In a standalone HANA data mart feeding a BI tool, calculation views.
Building an ABAP application on calculation views means giving up transport integration and everything the
ABAP layer provides — which is the answer to the question of why both exist.
13
What the interviewer is probing.1. "Why are calculation views the only type you should build now?" Probing: currency.
Stalls: "They are flexible." Moves up: attribute and analytic views are deprecated — calculation
views cover both and are what the modeller generates.
14
2. "What is the difference between a cube and a dimension view?" Probing: the modelling.
Stalls: "Nothing." Moves up: a cube has measures and is the thing you query; a dimension
provides attributes joined to it.
15
3. "Why avoid union nodes with constant mapping where possible?" Probing: the performance
detail. Stalls: "Style." Moves up: they can prevent pruning and push-down, so the engine
materialises more than needed — pruning configuration helps where it is unavoidable.
16
4. "What is the point of pushing filters down?" Probing: the principle. Stalls: "Speed."
Moves up: reducing rows at the lowest node means less data moves between engines, which is where
most calculation view performance comes from.