Role of Hierarchies in CDS View
The main function of hierarchy in analytics is to collect all facts in order to provide an eminent overview with the option to access into the lower branch and nodes of the hierarchy.
A hierarchy is usually defined on the master data column that categorizes the facts it is not defined on the facts itself. Any master data entity or business entity which are need to arranged in a hierarchy is provided by a CDS View of analytical data category DIMENSION.
Generally, a distinct hierarchy view is needed and identified by data category HIERARCHY. The row represents the nodes of the hierarchy. The hierarchical relation between these nodes can be identified in two ways:
First is by self-associating the view with cardinality [1 : 0..1] pointing towards the parent node of the node
Secondly is by setting up two columns, first identifying the node as a child, which is mostly the key column of the node, and the second one identified as the related parent node.
Note:The root nodes do not have a parent node.
Mostly, the business entity instance is assigned to a single node in the hierarchy but depending on the analytical engine capabilities, it can be assigned to multiple hierarchy nodes, and these multiple assignments are considered by the engine while collecting the facts via hierarchy. For example, the analytical engine in ABAP can manage more than one assignments to leaf nodes.
Note: The hierarchy node relates to only one business entity instance. But this situation is not same for the current set of hierarchy where a node can be related to various business entity instance but allows a similar treatment of all nodes of a hierarchy.
Most frequently, there are more than one options of possible hierarchy for a business entity. These options must be represented as instances in the hierarchy directory from where a user can select the hierarchy according to his needs. The CDS view of data category DIMENSION represent these hierarchy directories. And the entries done in this hierarchy directory is used as the grouping of hierarchy nodes. At runtime, only the nodes of single hierarchy directory entry are considered which decrease the number of processed nodes and result in improved performance. The connection between the hierarchy directory and the hierarchy node view is modelled with an association between these two views, where all key elements of the hierarchy view must be included by the on-condition.
For example, if the user chooses a master data dimension for (hierarchical) drill-down and some measures from the fact view. Then the user must have to select one hierarchy from the hierarchy directory view or the hierarchy must be pre-selected by the analytical query. After selecting the hierarchy the engine read the hierarchy nodes and structure from the hierarchy node view for the selected hierarchy. Then the measures are collected from the fact view to the master date instance which are assigned to hierarchy nodes. The measures for unassigned master data instances can also be collected and shown at a virtual hierarchy nodes for not assigned values.
These values are recursively collected along with the hierarchy structure by analytical structure to the higher level nodes
The hierarchically collected measures are displayed for all visible nodes.
The following checklist helps the user to express their hierarchy in CDS.
All hierarchy nodes must be represented as the rows of a CDS view, the node view.
- All the nodes belonging to a hierarchy, including root nodes, inner nodes, and leaf nodes are known as
Hierarchy nodes. Also, each set element, e.g. each cost centre, is considered as a separate hierarchy node. - 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.
- The complete set of nodes could be divided into various individual hierarchies. The CDS view provides a list of hierarchies which is known the hierarchy directory for this node view. Every single node belongs to exactly one hierarchy, which can identified by one or multiple key fields of the node view. A hierarchy can have multiple root nodes. More than one sub-hierarchies given by a node and its descendants are available within a single hierarchy.
Hierarchy Node
Defining a foreign key association to Hierarchy Directory and also Hierarchy Node Text View as shown in the image below.
.jpg)
The Cost Center Hierarchy Node view must have associated with Cost Center Master View and the Cost Center Field is annotated with @ObjectModel.Hierarchy.assocation which indicates hierarchy availability for this master data entity.
The image below is the Hierarchy Directory grouping all the available hierarchies.
Hierarchy Directory Text view
Hierarchy Node View Text view
Analytical View
Below is the analytical view having a costs centre Hierarchy.
Office Analysis
