Explain HANA Calculation Views in SAP

42 / 65

HANA DBintermediate

HANA Calculation Views

Building reusable, HANA-native data models using graphical and script-based calculation views in SAP HANA modeling tools.

Calculation views are the traditional HANA-native modeling layer (distinct from and predating ABAP CDS views, though conceptually similar) and they still come up in HANA-specialist interviews and in landscapes where HANA is used as a standalone data mart or by non-ABAP consuming applications, so understanding them - and how they relate to CDS views - is expected of anyone claiming HANA modeling experience.

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

A calculation view is built in HANA's web-based modeling tools (or historically in HANA Studio/Eclipse) as a graph of nodes: projection nodes (selecting/renaming/filtering columns from a source), join nodes (combining multiple sources), union nodes (stacking compatible result sets), and aggregation nodes (grouping and summarizing), wired together visually, with the final node exposed as the view's queryable output. Calculation views come in two flavors historically distinguished as different types - graphical calculation views (built purely through the visual node editor, the recommended and more maintainable modern default) and script-based calculation views (using an embedded SQLScript block for logic too complex to express graphically), with SAP's guidance being to prefer graphical modeling wherever feasible and drop to script only when genuinely necessary.

A key semantic setting is the view's type - a plain "Data Model" calculation view versus a "Cube"/"Dimension" style semantic type (relevant to OLAP-style consumption from BI tools) which determines how the view is presented to reporting tools expecting a defined measures-and-dimensions structure, echoing the same measure/dimension distinction seen in ABAP CDS analytical annotations. Variables and input parameters let a calculation view accept runtime filter values or parameterized logic (e.g., a fiscal year variable that restricts a partition-pruning-friendly filter early in the execution plan), which matters for both usability and, if used correctly, materially better performance versus filtering only at the final output stage.

A senior-level answer clarifies the relationship to ABAP CDS views for those working in an embedded S/4HANA/BW context: CDS views are the strategic modeling layer for ABAP-based application development going forward (versionable in ABAP transport, consumable by RAP/Fiori/embedded analytics), while calculation views remain relevant for non-ABAP HANA-native data marts, SAP BW/4HANA's underlying HANA modeling, or standalone HANA applications without an ABAP layer - so the choice depends heavily on whether the surrounding architecture is ABAP-based or not.