VDM analytical star
Most of the VDM is organized by layer — basic, composite, consumption. Analytics is the part that is organized by shape. Reporting and dashboard workloads expect a star schema: a central fact table surrounded by dimensions, with texts and hierarchies hanging off the dimensions. SAP encoded that shape directly into the CDS annotation vocabulary, and Atlas’s planner reads the annotations to decide which node is which.
How the view types line up
Section titled “How the view types line up”The central view of an analytical plan is a cube, identified by
@Analytics.dataCategory: #CUBE. It carries the measures — amounts,
quantities, counts — and it holds the keys that join out to the
dimensions. Cubes are where the numbers live.
A dimension — @Analytics.dataCategory: #DIMENSION — is a
business object you can filter by or slice by. Customer, material,
plant, calendar date. Dimensions are usually just renamed and
annotated versions of the relevant basic or composite view, brought
into the analytical star so the engine can find them.
A text view uses @ObjectModel.representativeKey to declare that
its rows are language-dependent descriptions of some business object.
One product has one key and dozens of translated names; the text view
is how the engine knows which name to use given the reader’s language.
A hierarchy view — @Hierarchy.parentChild — models the kind
of rollup that matters for management reporting. Profit centers inside
divisions inside regions. Atlas treats hierarchies as virtual
extensions of their dimensions and includes them in the plan graph
when the task implies a rollup.
A query view — @Analytics.query: true — sits on top. It
declares filters, variables, restricted key figures, default
drilldowns. Unlike every other view in the VDM, a query view is not
executed on the database. The analytic engine interprets the query’s
logic and rewrites it into selections against the cube and dimensions.
The query view is a specification; the engine is what runs.
Why the split matters for Atlas
Section titled “Why the split matters for Atlas”When you ask Atlas for an analytical task, the classifier places the output on the star. That placement changes every downstream decision.
If the output is a number that aggregates across rows — sum, average, count — Atlas is building a cube. If it is a filter criterion or a grouping dimension, Atlas is building a dimension (or pulling in an existing one). If it is a ranked list with language-dependent names, Atlas is wiring a text view into the consumption. If the task implies a rollup — top performers by region, cost by division — Atlas pulls in a hierarchy.
The gates that run against an analytical plan are shape-specific too. Measures must only live on cubes; representative keys must only live on text views; hierarchies must only attach to dimensions. Violations are easy to introduce if you try to ignore the shape; Atlas’s gates catch them before generate can emit them.
The elegant consequence
Section titled “The elegant consequence”Because the query view is a specification and not an execution, two things follow. First, Atlas can change the query’s logic without invalidating the cubes and dimensions underneath — the engine recompiles at runtime. Second, the query view is small — most queries are a few dozen lines of specification — which is exactly the kind of artifact a reviewer can read in one sitting. A plan that builds a new analytical view is usually a large cube or dimension change and a tiny query; the query is where Atlas expects the human review to concentrate, and the plan graph makes that expectation visible.