SAP Calculation views

A calculation view defines a data model, sources, joins, aggregations, calculated columns, filters, that HANA executes efficiently in-engine. Modern HANA unifies the older attribute/analytic view types into calculation views, which can be built graphically (a flow of nodes) or with SQLScript for complex logic.

Worth clarifying the history, because older material references types that no longer matter. Attribute views and analytic views were separate object types in earlier releases and have been deprecated: calculation views absorbed both. Encountering them in an existing landscape means legacy content, and new modelling uses calculation views regardless of whether the requirement looks like a dimension or a cube.

• Dimension: master-data-like, for attributes/lookups.
• Cube (with star join): analytical, with measures and aggregation, for reporting.

The category is not cosmetic. A cube exposes measures that a reporting tool can aggregate and offers a star join to its dimensions. A dimension exposes attributes for lookup and filtering. A reporting tool reading a view expects one or the other, and a view categorised wrongly either offers no measures to aggregate or offers aggregation on something that should not be summed.

A third state exists and matters: a view with no data category. That is the right setting for an intermediate view consumed only by other views, since it is not meant to be reported on directly. Setting a category on every view, including the base layers, is a common habit that produces objects reporting tools offer to users who should never see them.

A calculation view is a graph read bottom to top, and the arrangement matters more than the individual nodes.

Projection selects columns and filters rows, and it belongs as low as possible. Filtering early is the single most effective thing in the whole model.

Join combines sources. The cardinality setting is the one to get right: declaring it honestly lets the engine skip the join entirely when nothing from that side is requested, and declaring it optimistically to gain that produces wrong results when the data does not match the claim.

Aggregation groups and sums, and it works best when the engine can push it down rather than being forced to happen at a fixed point.

Union stacks matching structures, which is how several sources or several years combine.

Rank selects the top or latest per group, which is how a current record is picked from a history table without a subquery.

The semantics node sits at the top, labelling columns as attributes or measures, defining hierarchies and marking the view for consumption.

The failure to avoid is a tall model with the filter at the top: everything below did full work first.

Layer calculation views (reusable base views consumed by higher ones), push filters and aggregation down toward the sources, minimise expensive joins, and expose only needed columns. Good design keeps them fast and reusable; poor design (huge single views, late aggregation) makes them slow.

The layering pays off for a specific reason. A base view close to the tables absorbs a structural change, so when a column is renamed one view changes and everything above it keeps working. A landscape of flat views, each written for one report, breaks in forty places instead.

Forty minutes, and it makes the performance advice measurable rather than theoretical.

1. Create a projection node over one table, select a handful of columns and add a filter.
2. Add a join to a second table and set the cardinality to match the data honestly.
3. Add an aggregation grouping by two attributes and summing one measure.
4. Set the data category and mark the measures in the semantics node.
5. Preview the data, then read the generated SQL and the execution plan.
6. Request only columns from the first table. With correct cardinality the plan should show the join pruned, because nothing from that side was needed.
7. Now move the filter to the top of the model and compare plans. More rows travel further, and the difference is visible.

Calculation views are consumed by SQL, reporting tools and applications. In the SAP application world, CDS views are often preferred for application data (they integrate with ABAP and generate optimised HANA execution), while calculation views serve broader native-HANA and data-warehouse scenarios.

The choice between the two comes down to where the data lives. On an ABAP system, CDS is transportable, carries authorisation through the application's own objects, and is the strategic direction, so new modelling goes there. Native calculation views remain right on a standalone HANA database, in side-car scenarios and where non-ABAP tools are the consumers. See HANA modelling for the wider approach and ABAP CDS for the alternative.

A view hardcoded to one company code or one year is a view per company code and year. Parameters are what avoid that.

An input parameter is a value passed in when the view is queried, and it can be used anywhere in the model: in a filter, in a calculated column, in a join condition. Because it is applied inside the model, filtering on a parameter happens early rather than at the top.

A variable is a filter on a column, offered to the user by a reporting tool, and it is simpler and less flexible.

The useful distinction: a parameter can drive a calculation, a variable can only restrict a column. Currency conversion is the classic parameter case, where the target currency and the conversion date are passed in and the model does the conversion, rather than materialising one view per currency.

Parameters can be mandatory or carry a default, and they can be derived from a table so the user picks from valid values.

The design habit worth forming: before creating a second view that differs from the first by one filter, ask whether that filter should be a parameter on the first.

• Where the model lives. CDS on an ABAP system, native calculation views on a standalone or side-car HANA. Mixing both in one landscape without a rule produces two answers to the same question.
• How many layers. Base, composite and consumption survives change. Flat views per report do not.
• Parameters or separate views. Parameterising is more work once and avoids a view per variation.
• Where calculations live. In the model, so every consumer agrees, or in the reporting tool, so each report can differ. The first is right for anything the business argues about.

• Monolithic views instead of layered/reusable.
• Late aggregation hurting performance.
• Exposing unnecessary columns/joins.

• Cardinality set to enable pruning rather than to describe the data. It is a promise to the optimiser, and breaking it returns wrong numbers rather than an error.
• Calculated columns doing work before filtering. The calculation runs on every row that the filter would have discarded.
• No analytic privilege. The view returns everything to anyone who can run it. See procedures and the CDS reference.

• A view built for one report and then reused. It carries that report's assumptions, and the second consumer inherits them without knowing.

Building a view is straightforward, and designing a layered model that prunes, filters early and carries its own authorisation is the part you do in the course.

The two things that decide whether a model performs: filter at the bottom, and set cardinality honestly. Everything else is detail by comparison, and both are visible in the execution plan in about a minute.