Junk dimension, or not?
Recognize a high-cardinality attribute that does not belong in a junk dimension.
Concept
junk-dimensions
The primary modeling idea this problem reinforces.
Requirements
1
Business needs the model must satisfy.
A team wants to fold customer email address into the same junk dimension that holds gift and promo flags, reasoning that "it is just another attribute."
Junk dimensions are for low-cardinality flags. Folding a high-cardinality attribute like email into them explodes the junk dimension to one row per distinct value, defeating the purpose.
- Pick the modeling choice that keeps the junk dimension small.
- The answer keeps high-cardinality attributes out of the junk dimension.
- The explanation cites cardinality as the deciding factor.
- Junk dimensions stay small because their attributes are low-cardinality.
- Email is effectively unique per customer.
- Treating any small set of columns as junk-dimension material regardless of cardinality.
- Exploding the junk dimension to one row per email.
- Leaving high-cardinality identifiers on the fact when they belong in their own dimension.
Cardinality-aware junk dimension use
Keep only low-cardinality flags in the junk dimension. A high-cardinality attribute like email belongs on the customer dimension, since a Kimball junk dimension would explode to one row per distinct value.
Optimizes for
- • Bounded junk-dimension size
- • Correct attribute placement
Trade-offs
- • Requires judging cardinality up front
Try the question first.
The discussion has other people's approaches and solutions. Give it a real attempt before you read them.