Outrigger dimensions
Decide when one dimension may reference another (an outrigger) versus over-snowflaking.
Concept
dimensional-modeling-basics
The primary modeling idea this problem reinforces.
Requirements
1
Business needs the model must satisfy.
A store dimension needs demographic attributes for the store’s county that are themselves a slowly maintained, reused set. The team debates embedding the county demographics directly on the store dimension or referencing a shared demographics dimension as an outrigger.
An outrigger is a dimension referenced by another dimension. Used sparingly for a reused, independently maintained attribute cluster it is fine; used everywhere it snowflakes the model and hurts usability.
- Pick the outrigger decision that balances reuse against usability.
- The answer uses an outrigger only for the reused, independently maintained cluster.
- The explanation warns against general snowflaking.
- An outrigger is a dimension referenced by another dimension.
- Reserve it for a reused, separately maintained attribute cluster.
- Snowflaking every dimension attribute into outriggers.
- Copying the reused demographics onto every dimension that needs them.
- Treating outriggers as always-bad or always-good rather than situational.
Sparing use of an outrigger dimension
Reference a shared demographics dimension from the store dimension only because it is a reused, independently maintained cluster. Do not snowflake ordinary attributes this way. That restraint is what makes it a Kimball outrigger.
Optimizes for
- • Reuse of a maintained attribute cluster
- • Avoiding duplicated demographics
Trade-offs
- • Adds a join behind the dimension
- • Overuse snowflakes and hurts usability
Try the question first.
The discussion has other people's approaches and solutions. Give it a real attempt before you read them.