General Information to
- CDS Queries: see Analytic CDS Queries
- CDS Hierarchies: see Using Hierarchy in CDS
CDS Hierarchy with Hierarchy Directory and External(Text) and Postable Hierarchy Nodes
The following example is based on the SFLIGHT scenario.
Definition of Hierarchy
Header
The annotation @ObjectModel.dataCategory: #HIERARCHY specifies the CDS view as a hierarchy. In this case, it is a Parent-Child Hierarchy(@Hierarchy.parentChild) where the following two definitions are important:
- recurseBy : '_parent': this means that the corresponding association defines the recursion fields, in this case they are nodeid and parentid
- directory: '_dir': this means that the corresponding association defines the hierarchy directory
Body of the view
Associations
- association ' _dir': the associated view defines the hierarchy directory - see Hierarchy Directory
- association '_parent': this association defines the recursion(parentid,nodeid), it refers to the view itself. See screenshot above. The fields nodeid and parentid define the recursion.
- association '_node': the associated view handles the texts of the nodes, see Node Texts; in BW context, these nodes(field nodename) would be called text nodes or nodes of external characteristics
- association '_planetype': the associated view defines the basis dimension Planetype of the hierarchy - see Dimension Planetype (texts and attributes, association to the heirarchy)
Attention:
The associated views defined in association '_node' and association '_planetype' must contain all node or plantype values available in the hierarchy view ZSTPE_Planetype_HIer. Otherwise the data model is inconsistent and hierarchy node selection can't work properly.
Source Table zstpe_planetyp_h
Source of this view is the table zstpe_planetyp_h with the following definition and content:
So, there are two hierarchies in this table, HIER1 and HIER2. If we e.g. check the first three rows, they can be interpreted the following way:
- node LEVEL1 is a child of the node ROOTNODE
- NodeA is a child of node LEVEL1
- the leaves(planetypes) A319-100 and A320-200 have LEVEL1 as their parent node
Checking Hierarchy with Transaction RSH1
It is also possible to use transaction RSH1 in order to take a look at the hierarchy. You need to enter the name of the characteristic(which is the 2C'SQLViewName' of the corresponding dimension), then you get a list of all available hierarchies displayed:
The nodes like 'NODE X' are handled in BW like so called nodes of external characteristics(see external characteristics).
Hierarchy used in CDS Cube
The dimension 'planetyp' is now used in a CDS view of dataCategory:#CUBE:
We run the so called adhoc query in Transaction RSRT: Query Monitor:
and then navigate to the Properties of Planetyp:
Two hierarchies are offered, we choose HIER1 and check the result:
Please compare the hierarchy with the content of the table above. In particular, note that A340-600 is a so called postable node, the other nodes are text nodes or nodes of external characteristics (see external characteristics), respectivelly.