SAP Modeling

Rather than querying raw tables directly, you build views that join, filter, aggregate and enrich data, then applications and reports consume the views. On HANA the modern modeling artifact is the calculation view (and, in the ABAP world, CDS views), designed to run efficiently in the HANA engine.

• Calculation views: the current, flexible standard (graphical or SQLScript).
• (Legacy) Attribute & analytic views: older types now unified into calculation views.
• CDS views (ABAP): the SAP-application modeling layer, executed on HANA.

A calculation view is a graph of nodes, each transforming what the one below it produced, and knowing the node types makes any model readable.

Projection selects columns and filters rows. The most important node in practice, because filtering early is what keeps the rest cheap.

Join combines two sources. The join type and cardinality matter more here than in ordinary SQL, because the engine uses cardinality to decide whether it can skip the join entirely when no column from one side is requested.

Union stacks sources with matching structures, which is how data from several tables or several years is combined.

Aggregation groups and sums. Placing it as late as possible and letting the engine push it down is usually right.

Rank picks the top or latest per group, which is how a current record is selected from a history table.

The view has a semantics node at the top, where columns are labelled as attributes or measures, hierarchies are defined, and the view is marked for consumption.

The two things that most affect performance are filtering early and letting aggregation happen at the bottom. A model that pulls everything up and filters at the top defeats the engine.

Good models are layered and reusable, base views close to tables, composite views on top, so logic is defined once and reused. Push filtering and aggregation as low as possible, and design for the consumption pattern (transactional lookup vs analytical aggregation).

The layering has a practical payoff worth stating. Base views close to the tables absorb structural change, so when a table gains a column or a field is renamed, one view changes and everything above it carries on. Composite views combine those into business objects. Consumption views add the semantics a reporting tool needs. Writing one flat view per report is faster today and produces a landscape where a single table change breaks dozens of objects.

A practical rule that follows from the layering: a view should have one reason to change. A base view changes when its table changes. A composite view changes when the business object's definition changes. A consumption view changes when a report needs something different. When one view changes for all three reasons, it is doing three jobs.

Forty minutes, and it teaches the performance lesson by demonstration rather than assertion.

1. Create a projection view over one table, selecting a handful of columns with a filter.
2. Add a join to a second table for a description, and set the cardinality honestly.
3. Add an aggregation grouping by a couple of attributes and summing a measure.
4. Preview the data, then look at the generated SQL and the execution plan.
5. Now request only the columns from the first table. If the cardinality is set correctly, the plan should show the join being skipped entirely, because nothing from that side was needed.
6. Move the filter from the projection to the top of the model and compare the plan again. More rows travel further, and the difference is visible.

Step five is the one worth internalising: correct cardinality is not documentation, it is what allows the engine to do less work.

Models are consumed by Fiori/analytics via OData, by reporting tools (SAC), and by ABAP. In S/4HANA, CDS is the primary modeling layer for application data, while native calculation views serve broader HANA use cases.

Where the data sits in S/4HANA, the modelling layer is increasingly CDS in ABAP rather than views built in HANA directly, because CDS views are transportable ABAP objects with authorisation built in. Native HANA modelling remains the answer on a standalone HANA database, in side-car scenarios and in data warehousing on HANA. Knowing which approach a landscape uses is the first question rather than an afterthought.

A view that returns everything to everyone is a data protection problem wearing a performance solution's clothes, and modelling has its own authorisation mechanism.

Analytic privileges restrict which rows a user sees from a view, by value. A sales manager sees their region; a controller sees their company code. The restriction is defined against the view's attributes and attached to it, so it applies wherever the view is consumed.

They come in two forms. Static privileges hold fixed values, which is simple and means a change requires maintenance. Dynamic privileges resolve the values at runtime, usually from a table mapping users to what they may see, which scales to an organisation that changes without a privilege change every time.

The critical detail is that a view marked as not applying privileges returns everything. That setting exists for base views intended to be consumed only by other views, and it is a mistake on anything a person can query directly.

Where the data sits in an ABAP system, access control is expressed in CDS instead and reuses the authorisation objects the application already has, which is one of the strongest arguments for modelling there rather than natively when the option exists.

• Native HANA views or CDS. On an ABAP system, CDS is transportable, carries authorisation and is the strategic direction. Native modelling suits standalone HANA, side-car and warehouse scenarios.
• How many layers. Base, composite and consumption is the pattern that survives change. One flat view per report is faster now and breaks on the first table change.
• Where calculations live. In the model, so every consumer gets the same answer, or in the reporting tool, so each report can differ. The first is nearly always right for anything a business argues about.
• Naming. A convention that marks the layer, because a landscape of views nobody can categorise becomes unmaintainable faster than a mediocre convention applied consistently.

• Querying raw tables instead of reusable views.
• Monolithic views instead of layered, reusable ones.
• Aggregating late instead of pushing it down.

• Wrong cardinality on a join. Setting it optimistically to allow pruning produces wrong results when the data does not match the claim.
• Filtering at the top of a deep model. Everything below did full work first.
• Modelling without authorisation. A view without analytic privileges returns everything to anyone who can run it. See the HANA database and procedures for the surrounding pieces.

• Calculated columns doing work that belongs in a filter. The calculation runs on every row before anything is discarded.

Building a view is the easy half, and designing a layered model that performs and can be maintained is the part you do in the course.

The habit that separates a working model from a slow one is filtering as early in the graph as possible and letting aggregation happen at the bottom. Reading the execution plan once, and seeing where rows stop travelling, teaches that faster than any guideline.