Junk dimension design
01

Input: first order, promo, gift

02

Group: related stable low-cardinality fields

03

Key: combination surrogate

04

Fact: one foreign key

05

Govern: unknown and valid combinations

Combine related flags, not every leftover attribute

Facts accumulate first-order, promotion, gift, source, and payment flags. A tiny dimension per field is excessive; leaving all in the fact becomes hard to govern.

Group stable, low-cardinality fields from one business process that are often analyzed together.

Screen fields before grouping

Small enums and booleans fit. High-cardinality text, rapidly changing attributes, master data, and sensitive values do not.

Every field must belong to the fact grain rather than a long-lived customer entity.

Control combination growth

The theoretical count multiplies field cardinalities. Load observed or permitted combinations and assess growth before adding a field.

Pre-generation works only for a small fixed space; otherwise generate on demand with uniqueness tests.

Keep atomic and readable meaning

Retain each atomic field and optionally add reviewed names such as promotional first order. Do not store only a concatenated label.

Separate unknown, uncollected, and not applicable instead of mapping all to false.

Test combinations and evolution

Exercise valid combinations, unknowns, new enums, retired fields, historical facts, and common filters while monitoring size.

BuildTable can support AI-friendly dimensions; combination generation, enum governance, and semantic naming need confirmation.

Use an admission checklist instead of a leftovers bucket

A candidate should share the fact grain, remain low-cardinality, be fixed with the event, lack an independent master-data lifecycle, and be useful in analysis. Customer tier, free text, device ID, and sensitive attributes do not fit simply because they are inconvenient.

Keep technical pipeline flags outside the business dimension and preserve normal dimensions for attributes with ownership, hierarchy, or history.

Quantify the combination space

The theoretical count multiplies cardinalities. Compare that space with observed combinations and growth before adding fields. Monitor unexpected expansion.

Pre-generate only a small, fixed valid space. Otherwise insert observed combinations with a uniqueness constraint and idempotent surrogate assignment.

Preserve atomic meaning and three-state logic

Keep every atomic column and use reviewed combination labels only as an additional grouping. A concatenated string is difficult to test, localize, or evolve.

Unknown, uncollected, not applicable, false, and explicitly no are not interchangeable. Record source and rule version so new logic does not rewrite history.

Evolve without breaking historical facts

Map old facts to unknown when a new attribute did not exist; do not default false and claim comparability. Retired columns remain interpretable for historical keys.

Split the dimension when attributes develop independent hierarchy, access, or cardinality. Use a dual-run and reconciliation window during migration.

Accept combinations and verify scope

Test valid and forbidden combinations, special values, new enums, retries, replay, and retirement. Reconcile atomic counts to source and monitor dimension size.

BuildTable may support AI-friendly dimension design, while discovery, key generation, enum governance, and migration need confirmation. A junk dimension is a tradeoff, not a universal target.

Public references

Build an AI-ready data foundation

Contact us to discuss your data modeling scenario and access BuildTable Desktop.

Contact us