Skip to Content

Hierarchies in CDS views

Why do we need Hierarchies?

The main purpose of a hierarchy in analytics is to aggregate facts and provide a high-level overview with the option to drill into the lower hierarchy branches and nodes. Facts are represented as CDS analytical views, which are identified by the analytical data category CUBE provided as CDS view annotation.

A hierarchy is usually not defined on the facts themselves but on some master data column that categorizes the facts. This master data entity, or any business entity that should be arranged in a hierarchy, is given by a CDS view of analytical data category DIMENSION.

In general, a separate hierarchy view is needed, identified by data category HIERARCHY. Its rows represent the nodes of the hierarchy. The hierarchical relation of these nodes can be specified in two ways:

By two sets of columns, one identifying a node as child, often the key columns of the node, and the other one identifying the related parent node

By a self-association of the view with cardinality [1 : 0..1] pointing to the parent node of the node

Root nodes are those nodes which have no parent.

Usually, a business entity instance is assigned to just one node in a hierarchy. Depending on the capabilities of the analytical engine, it could be assigned to multiple hierarchy nodes, and the engine would consider this multiple assignment when aggregating facts via the hierarchy. The analytical engine in ABAP, for example, can handle multiple assignments to leaf nodes.

Note that a hierarchy node relates to just one business entity instance. This is different than in current set hierarchies, where a node can relate to many business entity instances, but allows for a unified treatment of all nodes of a hierarchy.

Often there is not just one possible hierarchy for a business entity but several alternatives. These should be represented as instances in a hierarchy directory from which a user can select the hierarchy he wants to see. The hierarchy directory is represented by a CDS view of data category DIMENSION. An entry of the hierarchy directory is used as grouping of hierarchy nodes. At runtime, only the nodes of a single hierarchy directory entry are considered. This reduces the number of processed nodes and improves performance. The connection between the hierarchy node view and the hierarchy directory is modeled with an association between these two views, where the on-condition must include all key elements of the hierarchy view.

Assume that the user has chosen a master data dimension for (hierarchical) drill-down and some measures from the fact view. Then he has to select one hierarchy from the hierarchy directory view (or the hierarchy might be pre-selected by the analytical query). Then the engine reads hierarchy nodes and structure from the hierarchy node view for the selected hierarchy (or uses cached information). Afterwards, the measures are aggregated via the fact view to those master data instances that are assigned to hierarchy nodes. Measures for unassigned master data instances can also be aggregated and shown at a virtual hierarchy node for unassigned values.

The analytical engine recursively aggregates these values along the hierarchy structure to higher level nodes

The hierarchically aggregated measures are displayed at all visible nodes.

The following check-list helps to express your hierarchy in CDS.

All hierarchy nodes must be represented as the rows of a CDS view, the node view.

  1. Hierarchy nodes are all nodes belonging to a hierarchy, including root nodes, inner nodes, and leaf nodes. For those readers familiar with set hierarchies: also each set element, e.g. each cost center, is considered as a separate hierarchy node.
  2. For each node, a single parent node is specified in the node view. Nodes without a parent are considered root nodes. A node cannot have more than one parent. Therefore, all hierarchies are strict. Each chain of parents must be acyclic, and therefore end at a root node.
  3. The complete set of nodes can be divided into several individual hierarchies. The list of hierarchies is given by a CDS view, the hierarchy directory for this node view. Each node belongs to exactly one hierarchy, identified by one or multiple key fields of the node view. A hierarchy can have multiple root nodes. Within a single hierarchy, multiple sub-hierarchies are available, given by a node and its descendents.


Analytical View

The below is your analytical view, which has a costs center Hierarchy.

Hierarchy Node

Define a foreign key association to Hierarchy Directory and also Hierarchy Node Text View as below.

The Cost Center Master View should have the association to the Cost Center Hierarchy Node view. Also, Cost Center Field is annotated with @ObjectModel.Hierarchy.assocation indicating that a hierarchy is available for this master data entity.

Below is the Hierarchy Directory grouping all the available hierarchies.

Text view for Hierarchy Directory.

Text view for Hierarchy Node View.

Analysis for office


For system setup, Analysis for office setup please refer to the below blog post.

You must be Logged on to comment or reply to a post.
    • You need to create services on top of your views and consume the same in an application to update the data in the tables

      • Hi Karul,

        Can you please shed some light on  ”  You need to create services on top of your views and consume the same in an application to update the data in the tables”.We moved to ECC on HANA and leveraging CDS views and got struck here and not sure how to proceed way forward.



    • Hi Kumail,

      In S4/HANA all set definitions are now stored in new HRRP* tables. The SAP VDM views assume the hierarchy data (GL Accounts, Cost Centers, Profit Centers, etc.) is stored in the new HRRP* tables.

      SAP provides a program to replicate the FI Financial Statement Version hierarchies and the FI-SL based sets (SETHEADER, SETLEAF, etc.) to the new HRRP* tables.

      There are two programs to do this:

      1. First you have to specify with hierarchies (“sets”) you want to replicate to the HRRP tables. To do so, use tcode HRY_REPRELEV.
      2. Next, you have to to the actual replication of the set data. To do so, use tcode HRRP_REP.

      These tcodes are also included in IMG: Financial Accounting (New) -> Financial Accounting Global Settings (New) -> Tools -> Set Report Relevancy for Hierarchies (and Replicate Runtime Hierarchies).

      There is also a Fiori app/tile to perform the replication.

      Good luck!


    • Hi Georg,

      I am not sure, Semantically the two are different things and hence has different offerings but I think that creating hierarchies is a feature supported in HANA CDS as well.



  • Hi Kayur,

    thanks for your posting.

    Can this feature of ABAP CDS be replaced with CONNECT BY function of oracle?




  • Hi,

    thanks for the great post!  The hierarchy works quite well for me.

    I didn’t manage however, to use a parameter to select a Hierarchy version dynamically.

    Do you have a hint for me to solve that issue?


  • Hello Kayur, hello everyone!

    Is it also possible to create my own hierarchy? I want to create a hierarchy which consists of Companycode > Banks > Bankaccounts.

    I saw two different blog-entries where someone created a custom hierarchy – but this was single field related hierarchy. In the first example there was a hierarchy for organization units ( one unit is the parent of another one) and the second example was for employees, where one employee could be the manager of another one. This information was also located in one database table.

    But my 3 components are different in there datatype, e.g. a bank is not a companycode or a bankaccount. I need something like as Masterdata Hierarchy.

    In the end I want to create a SAP Analytics Cloud Story, where I can see my profit per companycode and I want to drill down to the bank, to see the distribution of my profit. Or is using hierarchies for this function the wrong way to proceed?

    Does anyone knows how to create such a hierarchy/drilldown functionality with ABAP CDS Views? We are using a live data connection, therefore the hierarchy has to be defined in the underlying datamodel  – it is not possible to do this in the cloud.

    Thank you very much!

    Best regards, Thorsten