-
Sometimes certain attributes don’t fit nicely into any dimension
- Payment method (Cash vs. Credit Card vs. Check)
- Bagging type (Paper vs. Plastic vs. None)
-
Create one or more “mix” dimensions
- Group together leftover attributes as a dimension even if not related
- Reduces number of dimension tables, width of fact table
-
Works best if leftover attributes are
- Few in number
- Low in cardinality
- Correlated
-
Other options
- Each leftover attribute becomes a dimension
- Eliminate leftover attributes that are not useful
A junk dimension is a collection of random transactional codes, flags and/or text attributes that are unrelated to any particular dimension. The junk dimension is simply a structure that provides a convenient place to store the junk attributes. A good example would be a trade fact in a company that brokers equity trades.
The need for junk dimensions arises when we are considering single level hierarchies. The only problem with the single level hierarchies is that you may have a lot of them in any given dimensional model. Ideally, the concatenated primary key of a fact table should consist of fewer than 10 foreign keys. Sometimes, if all of the yes/no flags are represented as single level hierarchy dimensions, you may end up with 30 or more. Obviously, this is an overly complex design.
A technique that allows reduction of the number of foreign keys in a fact table is the creation of "junk" dimensions. These are just "made up" dimensions where you can put several of these single level hierarchies. This cuts down the number of foreign keys in the fact table dramatically.
As to the number of flags before creating a junk dimension, if there are more than 15 dimensions, where five or more are single level hierarchies, I start seriously thinking about combining them into one or more junk dimensions. One should not indiscriminately combine 20 or 30 or 80 single level hierarchies.
Previous
TOC