Junk Dimensions
When a business process generates several low-cardinality flags and indicators (e.g., "Payment Method", "Order Status", "Is Expedited"), putting them directly in the fact table can create "column bloat" (an excessively wide table with too many individual boolean/integer columns). However, creating a separate dimension table for each individual flag results in too many foreign keys.
A junk dimension (frequently labeled as a transaction profile dimension) solves this by grouping all these miscellaneous flags into a single dimension table. The fact table then only needs one foreign key pointing to the combined row.
The junk dimension does not need to be a Cartesian product of all the attributes' possible values, but should contain only the combinations that actually occur in the source data.
Example (Order Flags Junk Dimension):
| junk_key | order_status | payment_method | is_expedited |
|---|---|---|---|
| 1 | Pending | Credit Card | Yes |
| 2 | Pending | Credit Card | No |
| 3 | Completed | PayPal | Yes |
The fact table stores junk_key = 1 instead of three separate text flags.