Analytical CDS Views for Cubes and Dimensions

An analytical CDS view is an ordinary CDS view entity that carries the annotation marking it as a cube or a dimension, borrowing terminology from BW modeling without being a BW object. A cube view exposes measures, numeric fields flagged with a default aggregation behaviour such as sum or count, alongside characteristics used to slice those measures. A dimension view exposes descriptive attributes for a business entity, typically with an association to a text view and sometimes a hierarchy. The one fact that causes most confusion: the view's own SQL statement is usually unaggregated, row-level data. Grouping and summing do not happen inside the CDS SELECT; they happen when a consumer, most often an OData service using an aggregation transformation, issues a request that groups by certain fields. Open the view in the ABAP Development Tools data preview and it looks like plain detail rows. The aggregation only appears once the analytical consumption path is exercised.

Reach for an analytical CDS view when the requirement is a KPI tile, an analytical list page, an overview page card, or any Fiori app that needs totals, counts or averages sliced by dimensions such as sales organization, material group or period, especially over large transactional tables. It is also the right layer when embedded analytics tools need a multidimensional source without staging data into BW. It is the wrong tool for a transactional list report that just needs filtered detail rows with no aggregation; a plain CDS view entity or a basic or composite interface view is lighter and easier to debug. It is also the wrong tool when the volumes are small enough that a transactional app can compute the number client-side, or when the business logic genuinely needs BW's time-dependent hierarchies, currency translation types and multi-provider blending, in which case a real BW query is a better fit than force-fitting a cube annotation onto a CDS view.

Below the analytical CDS view sit the basis tables or a table function providing the detail data, plus dimension views supplying master data and text. Above it sits an OData service, usually OData V4 with analytics support, exposed through a service definition and binding, which is what Fiori elements analytical list pages, overview page cards and smart business KPI tiles actually query. Analysis for Office and other embedded analytics clients can also reach the same cube through the InfoAccess protocol without a custom OData layer. In terms of what it supersedes: it is the S/4HANA-era replacement for hand-built HANA native analytic and attribute views, and for many custom ABAP reports that used to aggregate in a loop. It does not replace BW query modeling for genuinely multidimensional, hierarchy-heavy reporting; the two coexist, with analytical CDS views handling the lighter, embedded, near-real-time cases.

A sales overview KPI tile needs net order value and open quantity by sales organization and material group, refreshed against live order data. The cube view selects from the sales order item detail source, exposes net value and quantity as measures with default aggregation set to sum, exposes sales organization and material group as characteristics, and carries associations to a customer dimension view and a material dimension view, each of which in turn associates to a text view for the description in the logged-on language. Currency handling uses the amount annotation referencing the transaction currency field so downstream consumers know which field carries the unit. The cube view is exposed through a service definition as an OData V4 analytical service. The Fiori overview page card is configured against that service using an aggregation transformation requesting a group-by on sales organization with a sum of net value. Nothing in the cube view's own SQL groups anything; the grouping request comes from the OData call the card issues at runtime, and the database performs the aggregation when that call is processed.

Analytical CDS views are the standard, supported way to build custom embedded analytics content on S/4HANA and sit comfortably within a clean core approach when built as extensions on top of released CDS view entities rather than by modifying standard cube or dimension views directly. Reworking a standard SAP-delivered analytical view in place is discouraged; the clean core path is to build a new custom cube view that consumes released extension points or released views, and to expose it through its own service definition. Where compatibility views exist to bridge older query-based reporting objects, they are a migration aid, not a long-term modeling target for new development.

Development ownership sits with the ABAP or CDS developer who models the cube and dimension views and their measures. Functional ownership sits with whoever defines the KPI logic, currency handling and expected aggregation behaviour, typically an FI, SD or controlling functional consultant. Handover should include the annotated view source, the service definition it is exposed through, and a written statement of what each measure's aggregation and currency conversion is supposed to do, so a later reviewer does not have to reverse-engineer it from the annotations alone.

Read cds annotations and where they take effect to understand how the cube and dimension markers actually change runtime behaviour rather than design-time appearance. Read performance of nested cds views before chaining cube views to dimension views several levels deep. Read odata query options and server side paging and odata v2 versus odata v4 for sap developers to understand how the aggregation transformation that actually triggers grouping is expressed on the wire. Read cds compatibility views in s4hana if the project involves an older query-based object being bridged forward.