Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

CDS views provide a very flexible way to create a transient query to run on Analytic Engine. There are some basic rules to follow in data modeling.

The picture below helps to understand the idea behind it:

As CDS query runs on Analytic Engine (in BW, it is called OLAP Engine), the data model should still align with traditional BW assumptions. CDS views just provide a faster, easier, more flexible way to build up such a data model.

The upper part of this picture shows the traditional objects in a typical BW system: To report on a BW system: InfoProivders are built by using Modeling Tool for BW on HANA, or RSA1 for BW on other DBs. Then BW queries are built on these InfoProviders by using Query Designer, either Bex Query Designer or Query Designer in Modeling Tool.

It is similar for a transient query to run on the Analytic Engine in a non-BW system such as S/4HANA. The lower part of the picture shows this: InfoProviders should be built by using CDS views, then CDS queries are built on top of it by using CDS views, but with different annotations. (Note: So far planning are not supported in CDS yet.)

CDS views are just a new tool to build the data model for Analytic Engine. The only difference is: with traditional tools like RSA1, Query Designer or Modeling Tool, the boundary of different objects are well defined in the tools. The tools guide end users to build a valid model. However, CDS views is much lighter tool with strong capability, by reducing the ETL (Extraction, Transformation, Loading) effort, a data model can be built very conveniently by typing some CDS scripts. But the boundary of the objects are blurred. The explicit restrictions defined in traditional BW tools become implicit rules for users to follow in order to build a valid model. Although there is no terms like 'InfoProvider', 'Query' in the CDS transient objects world, nevertheless users still need to bear this picture in mind while modeling a business scenario. With the concept, you will understand and know: where to define what .

Basic Rules

Here are some implicit rules in data modeling, you may get various error when activate the CDS view if they are broken:

  1. Unions and Joins (including associations) can only be defined in CDS views of InfoProvider layer (with annotation @Analytics.dataCategory:#...). With only one exception: valueHelp association for a CDS query parameter which is not available in the provider view, can be defined in CDS query view.
  2. CDS queries (with annotation @Analytics.query:true) can be extended, but only query elements can be added into the extended view. Additional unions and joins need to be defined in InfoProvider layer.
  3. Some BEX query features are not supported in CDS query yet (such as 'Access Type for Result Values as Master Data'). In this case, instead of define a CDS query, you can define a BW query on the CDS InfoProvider in Modeling Tool to use these OLAP features.  Read more.
  4. CDS parameter only supports single value.
  5. Filters should be defined in a query CDS view. An InfoProvider CDS view should not contain parameters except for currency conversion. Parameters on InfoProvider level don't support semantics. Cube CDS views with parameters are mapped to HANA-table functions instead of HANA views. This might lead to significant performance impact .
  6. Don't use a BW InfoObject generated data element in a CDS view, always use the basic data element which is directly defined in DDIC (SE11). Generated data element will cause problems in life cycle management. Because generated data element is created when activating the InfoObject. If you use the data element n a CDS view and transport the CDS-view and the newly created InfoObject at the same time, an error is raised in the target system. DDIC objects (that is CDS) are activated before the BW Objects activation. So the generated data element will not be available.
  7. If a join (or an association) is defined on fields with domain using alpha conversion or data type NUMC, it must:
    a) make sure both fields in two tables have exactly the same length
    b) the data in both fields follows the alpha conversion rule: for example, for a char(2) field, there is no '1' stored in this field, it should be stored as '01'.
    Otherwise the data model will run into various issues and get unexpected query results. See Note 2789339.
  8. Association to a Dimension view or text view with parameters is not supported.

Notes:

  • 2551243 CDS modeling considerations in BW

Examples:  

Modeling

Getting Start

CDS reporting needs to define at least 2 CDS views as below:

For data stored in cluster tables or other encrypted data, a tool is needed to extract data into a transparent table for embedded reporting.  

Examples:

InfoProvider CDS Modeling

Here are more details about modeling considerations in different situations:  

  • InfoObject (@Analytics.dataCategory: #DIMENSION and measures/key figures)
  • InfoProvider (@Analytics.dataCategory: #CUBE)

 

 

  • No labels