Dimension interpretation

[olalov]

Hi,

Our business is asking for a new dimension, Region.
However, Region is interpreted differently among the business units. Region would be a collection of countries but the exact setup may differ.
A country could belong to one Region in business unit A but to another in business unit B.
Facts are only available on Region level (not country level) and facts are (so far) only local to the unit. Business unit A can measure e.g. delivery precision and unit B will measure e.g. customer satisfaction/profit/whatever...

THe business says they would benefit from using the dimension in our dashboards etc while still knowing that they interpret the dimension differently. What are the drawbacks and logical implications of this design?

Thanks,

ola

[VHF]

It sounds like you already understand the limitations. Drilling across business units won't be possible by region.

Make sure there is no possibility for confusion or accidently comparing apples with oranges! Ensure that every region in your dimension has an enterprise-unique name. i.e. you can't let Business Unit A have a "Northwest Region" and Business Unit B also have a (different) "Northwest Region". As long as the regions are unique and users understand they won't be able to drill across, you should be OK.

To bad your fact data doesn't arrive at the more granular country level!

[KS_EDW]

None really, if I understand it correctly…

Region would end up similar to a date dimension having several different fiscal years, season definitions, etc., or a time dimension having different shift definitions. Correct?

So you’d have basically a three column setup that has Country, Region BU A, and Region BU B?

I agree with VHF, in that, if the users acknowledge they can’t drill across... you’ll be golden. In fact, it may even do you some favors down the road, much like storing different fiscal years in the date dimension. In many cases for us this helps users recognize that there are differences in the calendars of the facts (quarters, BOFY, EOFY, etc.).

To make sure there isn’t an interpretation error, you could always name them distinctly different in the BI (hiding the other BU’s column) or create a rule in the metadata to force an invalid query response where the facts are joined by these two dimensional columns.

[Sponsored content]