Opportunity to define an entity as a dimension and as a tree entity
In some particular cases, reporting requirements might put the developer in front of a dilemma: define information either as an entity or as an infocube. Below is an example that shows strong and weak points of both approaches.
Let’s take the example where the reporting requirement is to Report KPIs:
- each KPI is an info-cube
- layout is aligned vertically with no dimension by row
- calculated KPIs are done with block algorithm
- each KPI is an item of the dimension “KPI” of a single info-cube
- layout is aligned horizontally and KPI dimension is by row
- calculated KPIs are done with item rule or rule++
Approach 1 (Infocube)
- It’s easy to create reports containing operations between the Infocubes (not only sum, but even % ratios, actual prices and so on)
- If you need a report with only one KPI, you have to take the infocube without any additional selection
- It’s very friendly and understandable for the unskilled users: one piece of information equals one infocube - choose it!
- Every time you need to calculate a KPI you need to define multiple blocks with all the factor infocubes into the dataview layout
- If you have lot of them it could be very complex and cumbersome defining the layout structure
- Since the datareader SQL clauses are different for each of them, you need to create one datareader for each infocube and load them separately
Approach 2 (Entity)
- The numbers of different KPIs do not affect the layout complexity
- Only one infocube for all the information needed to isolate single information (e.g. Credit Notes). It is enough to use the SELECT on “KPI” entity
- Since the datareader SQL clause is unique, you need to create one datareader for the infocube and load it all at once
- Performance is generally better.
- To refresh one KPI figure it is mandatory to re-load the whole cube unless you apply the “Use Current Selection” option
- Unskilled users could forget to select the interested KPI and they will get meaningless data
- Reporting requirements could somehow drive the choice : Approach 1 gives all the flexibility for the by row dimension and drilling capability, Approach 2 implies having the KPIs as the most nested break-down level (i.e. you can’t have a single KPI broken down by another by row dimension) ; additionally drill is not admitted on “by rule” calculated KPI.
- With Approach 2 for each report it is needed to define a selection on one or more Info (KPIs). And this could be a source of mistakes and have an impact on the reporting maintenance.
- With approach 1 in order to minimize the number of calculated blocks inside the dataview layout it is recommended to perform dataflow processes and populate a new calculated infocube (e.g. Net Sales)
- Attention : if you have to implement data entry process the Approach 1 will use Data Entry by block and reverse algorithm the Approach 2 will require Data Entry by Row and Rule++