When would you denormalise a data model?

Normalisation optimises for write consistency and storage. Denormalisation optimises for read performance and query simplicity. Analytical systems are read-heavy and written by controlled pipelines, so the trade usually favours denormalisation.

Concretely, denormalise when:

• The model is analytical. Star schemas are deliberately denormalised, and dimension tables are wide on purpose.
• The join is on the hot path. If every query traverses the same three tables, collapsing them removes work from every query.
• Storage is cheap relative to compute, which is the normal situation in a columnar warehouse where repeated values compress heavily.
• Writes are controlled. A pipeline that rebuilds a table cannot create the update anomalies normalisation protects against.

Keep it normalised when writes are frequent and uncontrolled, when the duplicated attribute changes often, or when a compliance requirement demands a single source of a field.

A strong answer names the trade explicitly rather than asserting a preference. The follow-up is usually "what do you lose?" — and the answer is update anomalies and storage, both of which are manageable in a pipeline-fed analytical model and dangerous in a transactional one.

Mentioning that columnar engines dictionary-encode repeated values, so the storage cost of a wide dimension is much smaller than it looks, tends to land well.