Resist the urge to hook a dimension up to a fact table when it actually should be a higher level in another dimension.
Consider the example of adding a vendor dimension to the sales fact where vendors really apply to products. Usually the reason given for this is "some access to sales require access to the vendor." The implementation would have vendors as a dimension to sales. This gives the wrong impression.
It's important to maintain the integrity of the dimensional model and not compromise it this way. If the model is compromised like this and you transform that schema into a cube, the default cube interface will display the vendor hooked up to sales. This could really confuse your users and those who set them up.
Rightfully, vendors belong as a higher-level hierarchy in the product dimension, which is really both a product and a product-vendor dimension. Each combination of hierarchies (1, 1-2, 1-2-3, etc.) in a dimension actually serves as a logical dimension itself.
Simple, correct relationships in the model are best for the user experience. The user can still get to the vendor for a sale using the vendor-product dimension.
For more information, check out searchCRM's Best Web Links on Data Warehousing.
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning editorial writers on the latest customer relationship management (CRM)and call center technology issues today. Our goal is to keep you informed on the hottest issues facing this fast-changing industry.
Hannah Smalltree, Editorial DirectorThis was first published in December 2001
Join the conversationComment
Share
Comments
Results
Contribute to the conversation