Facts and Dimensions in Oracle BI: Linking, Testing and Monitoring Data Quality

What is a fact

In Oracle BI, a “fact” is a measurable value, such as “Revenue,” displayed by the information model. This model gathers information from multiple database layers, applying preset definitions like security filters. This setup ensures that you see the precise sum of all amounts matching the underlying data (such as invoiced sales orders).

The Revenue shown above aggregates all relevant amounts from detailed data (e.g., individual invoiced sales order lines).

Dimension

In BI, a “dimension” breaks down data, like “revenue per year.” This concept is essential in Oracle BI: a fact is always connected to a dimension, and vice versa.

In this example, each revenue figure is linked not only to a year but also to other dimensions, such as the product. This shows that revenue is never separate from products or years—they are always connected.

The total revenue remains constant, meaning each revenue value is associated with both the Product and Year dimensions, and the connection works both ways. When we look at dimensions independently of facts, we illustrate that:

This shows that there are no dimensions, without facts.

Key questions

This raises a number of interesting questions:

• What if a certain product had no revenue in a specific year?
• What does this imply about the quality of core data?
• What does it suggest about transaction data quality?

What also consider:

• How can Oracle BI be tested and trusted?
• How can Oracle BI ensure the quality of master data?
• How can Oracle BI maintain the quality of transaction data?
• How can Oracle BI report revenue unrelated to products (e.g., revenue from services)

In Oracle JD Edwards, a property like “brand” for a product can be a category code, allowing items to fall outside certain categories. In Oracle BI, facts that don’t fit within a dimension can be classified as “unspecified,” keeping uncategorized data visible.

Conclusions

In de praktijk komt het op de volgende conclusies neer:

• In practice, this results in the following conclusions:
• Facts must connect to dimensions. To get insight into total revenue, whether from services or products, the Product dimension isn’t always relevant. If it is needed, a “Non-Conforming Dimension” can be set up to include services, though this approach is often avoided. Alternatively, results from different analyses can be displayed in a single view, ensuring all necessary information is accessible.
• Dimensions should connect to facts. In JD Edwards, the Customer dimension can pull data from the address book, but it’s better to only include customers who have sales orders. This ensures that only relevant customer data is displayed.
• Oracle BI must be testable. By comparing isolated facts with the sum of those facts across each dimension, data accuracy can be verified.
• Data quality management. This process monitors and ensures the quality of both master and transaction data.

Frequently Asked Questions

This approach often raises the following questions:

• How can I see which product groups had no revenue in a given year?
• How do I report total revenue with product groups where relevant?
• How do I report customers who generated no revenue in a specific period?
• How do I prevent certain master data from appearing in specific transactions?
• What if my data doesn’t align with the general ledger?

The next article in this series will address these questions.

Implementing a BI solution involves far more than creating reports or building dashboards. Cadran focuses on delivering the right information to the right people within the organization at the right time. This requires a thoughtful project approach to avoid BI implementation pitfalls. Ultimately, BI is about steering the organization effectively, and Cadran is your trusted partner for Business Intelligence and JD Edwards.