BI – We have to face the facts

Oracle BI – Thoughts (3) – Cadran publishes a series of articles about the ideas surrounding Oracle Business Intelligence in combination with Oracle JD Edwards. In these articles various considerations and reflections are discussed, which can be helpful in making the right decisions in the implementation and application of both systems. The previous article discussed the star scheme and the definition of facts and dimensions. This third article looks at the interplay between these two..

Fact

If an independent fact is used within Oracle BI, the measured value is shown as it is brought up by the logical information model (Common Enterprise Information Model) from the presentation layer of the Repository. This is subject to all the definitions that underlie this and that have been realized in the model. But there is no further discrimination in any way other than through possible security-based data filtering.

The Revenue shown above is a summation of all amounts of all relevant underlying details (eg invoiced sales order lines).

Dimension

As soon as the word “per” comes into play, we speak of a dimension that can be put into this.

In this example, the Revenue per Year is given. Here a very essential starting point of Oracle BI is addressed. This means that a fact must always be related to an associated dimension and vice versa. This becomes clearer when the Brand component is removed from the Products dimension.

The total Revenue remains the same. This implies that every amount that is included in the Revenue can be related to the Product dimension and to the Year dimension, but also the other way around. If we look at the dimensions of facts, we show that to:

This shows that there are no dimensions, without facts.

Issues

This raises a number of interesting issues:

What if a certain item in a specific year has not been sold?
What does this say about the quality of master data?
What does this say about the quality of transaction data?

Again everything stands or falls with definition and the way in which Oracle BI presents the unambiguous truth. This leads to the following issues:

How can Oracle BI be tested and trusted?
How can Oracle BI monitor the quality of master data?
How can Oracle BI monitor the quality of transaction data?
How can Oracle BI report on sales that can not be related to products (such as Revenue from services)?

If we translate this to Oracle JD Edwards, then the Brand attribute of the Product dimension could be a category code (eg SRP1) of the item master (F4101). This may involve more values than those related to products, let alone related to invoiced order lines in a given year. Oracle JD Edwards also has the option of a blank category code, which makes it possible to not include articles in this group.

This also starts with the definition and the translation of the Oracle JD Edwards implementation questions to its interpretation in Oracle BI (see previous articles in this series).

Within Oracle BI, facts that can not be related to dimensions could be collected under the denominator unspecified (or via so-called Non Conforming Dimensions, which will be discussed in the next article).

Conclusions

In practice, it comes down to the following conclusions:

Facts must be related to dimensions. If insight into the total Revenue is desired, regardless of whether this concerns services or products, then this may not be relevant with the Product dimension. If this is the case, then a safety net will be required to accommodate services here. There is then Non Conforming Dimensions, which is undesirable in the base (more about this in the next article). As an alternative, the results of multiple analyzes can be shown in a single overview, so that this desired result can indeed be presented.
Dimensions must be related to facts. Translated to JD Edwards, the dimension Customer could be fed by using the address book (F0101) limited to search type C. However, it is clearer to start from the customers who are actually related to sales orders. Only these can provide customer sales-related information. This excludes that a sale to a person who happens to have a different address book type is not shown.
Oracle BI needs to be tested and controlled by connecting separate facts with the sum of that fact against each dimension.
The quality of tribal and transactional data is also demonstrated in this way and can also be monitored in this way.

Yes, but…

And of course there are a number of ‘Yes But’ issues:

What if I want to know which item groups have had no sales in a given year?
What if I want to report all sales and, where applicable, want to mention the product group?
What if I want to report on customers who have not generated sales in a certain period?
What if I want to prevent certain master data from occurring in certain transactions?
What if I can not find a connection with my ledger?

These issues will be discussed in the following article in this series.

The implementation of a BI solution is more than the implementation of a software solution. Cadran’s vision is focused on determining the right information that is available to the right people in your organization at the right time. A thorough project approach is very important to prevent the pitfalls of such an implementation. BI is not about developing reports or creating nice dashboards. BI is about managing your organization and Cadran is your partner when it comes to Business Intelligence and JD Edwards. Do you want to know more?

Author: Rick Brobbel
BI Consultant at Cadran Consultancy