Kimball Forum
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Bus Matrix Documentation

4 posters

Go down

Bus Matrix Documentation Empty Bus Matrix Documentation

Post  ccioffi Tue Sep 16, 2014 8:36 am

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

ccioffi

Posts : 7
Join date : 2014-03-28

Back to top Go down

Bus Matrix Documentation Empty Re: Bus Matrix Documentation

Post  nick_white Tue Sep 16, 2014 12:15 pm

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.

nick_white

Posts : 364
Join date : 2014-01-06
Location : London

Back to top Go down

Bus Matrix Documentation Empty Re: Bus Matrix Documentation

Post  BoxesAndLines Tue Sep 16, 2014 2:49 pm

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.
BoxesAndLines
BoxesAndLines

Posts : 1212
Join date : 2009-02-03
Location : USA

Back to top Go down

Bus Matrix Documentation Empty Re: Bus Matrix Documentation

Post  ngalemmo Tue Sep 16, 2014 4:20 pm

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
ngalemmo

Posts : 3000
Join date : 2009-05-15
Location : Los Angeles

http://aginity.com

Back to top Go down

Bus Matrix Documentation Empty Re: Bus Matrix Documentation

Post  ccioffi Wed Sep 17, 2014 10:23 am

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?

ccioffi

Posts : 7
Join date : 2014-03-28

Back to top Go down

Bus Matrix Documentation Empty Re: Bus Matrix Documentation

Post  ngalemmo Wed Sep 17, 2014 1:55 pm

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.
ngalemmo
ngalemmo

Posts : 3000
Join date : 2009-05-15
Location : Los Angeles

http://aginity.com

Back to top Go down

Bus Matrix Documentation Empty Re: Bus Matrix Documentation

Post  Sponsored content


Sponsored content


Back to top Go down

Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum