Bus Matrix Documentation

We are attempting to reverse engineer our BI Reporting & Analytics platform into documentation utilizing the Bus Matrix. We are not sure if we should document the reported metric or the metric as constructed in the fact table. For example if you have a fact table with a metric such as "Customer Count", and on a report utilizing that fact table we may have metrics such as U.S. Customer Count, Europe Customer Count, South America Customer Count, etc. which is simply the Customer Count metric grouped by a geography attribute. The confusion is if we are going to use this bus matrix as a tool to communicate with the business, they will not understand customer count by itself, do we include the context in the metric as the metric is defined in the front end tool?

1. List customer count metric on bus matrix and explain detail available in dimensions
2. List out key reported metrics as displayed or set up in the BI platform
3. Create separate matrices for 1 and 2 above

If the core purpose for you to create the Bus Matrix is to communicate to the business then I would follow whatever approach is going to make the most sense to the business.
If you are using the Bus Matrix to document your DW (rather than your reporting tool) then I would include the physical measures and either include an explanation for business users or, alternatively, use a different document to communicate to your business users.

I only track the core metric. That's why you have the dimensions across the top, so you can see everything available for slicing and dicing as well as drilling across.

The purpose of the bus matrix is to diagram the dimensionality of each fact and its intersection with the dimensionality of other facts.

It is not intended to document the content of the data. I would use some other format.

ngalemmo wrote:The purpose of the bus matrix is to diagram the dimensionality of each fact and its intersection with the dimensionality of other facts.  

It is not intended to document the content of the data.  I would use some other format.

Thanks. The confusion in discussions we have had usually centers on what is a metric. (We know what it is from the definition of additive, semi-additive, non-additive) but for example when we have a generic metric like order_count which is used in an order fact to sum up total orders, that metric may be presented in a report or dashboard grouped by an attribute such as region so we end up with "North America Orders", "South America Orders" as labels on the report. Some in the organization feel that "North America Orders" is the metric, and some have even modeled it like that in our legacy data warehouse.

To that point above, raises another question, when is it appropriate to have metrics such as North America Orders, South America Orders in your fact instead of having a metric of Orders with an attribute of region? Obviously having metrics such as North America Orders, South America Orders makes your fact very inflexible if ever there should be a required change to the region definition in the business, but is there ever a valid use case for such a scenario?

That is the difference between atomic and aggregate facts. You always want to capture facts at the most detailed level available (atomic). Whither or not you create aggregates is a matter of usage frequency and performance.