03.03 · Concept
Normalization vs Denormalization for ML
Choose between normalized and denormalized representations based on update frequency, query patterns, training cost, and leakage risk.
Normalised ML data keeps source facts canonical and joinable; denormalised data materialises training-ready rows. The right choice depends on how often inputs change, whether joins dominate training cost, how stable the access pattern is, and whether feature timestamps make prediction-time availability explicit enough to prevent leakage.
What this lesson answers
- normalised or denormalised features for model training
- when should ML training data be denormalised
- how does denormalisation create feature leakage
Notes
Normalization stores facts once and connects them through keys: users in one table, events in another, products in another. This is usually better when source data changes often, when correctness and consistency matter, and when multiple downstream uses need the same entities. For ML, normalized data can help reduce accidental duplication and make it easier to apply point-in-time joins, audit feature definitions, and avoid mixing labels or future information into training rows.
Common questions
- Is normalised data always safer for machine learning?
- No. Normalisation can make source facts easier to audit and can support point-in-time joins, but it does not guarantee correctness. Leakage can still happen if joins use the wrong timestamp, labels are mixed into features, or availability time is ignored. The schema helps, but the temporal logic matters more.
- When is a denormalised training table the better choice?
- Denormalisation fits when training repeatedly reads the same feature shape, feature logic is stable, and joins have become a major cost or reliability problem. A wide materialised table is simpler for model code to scan and reproduce, provided rebuilds, stale values, and feature provenance are managed deliberately.
- How should I decide between normalised and denormalised ML data?
- Start with update frequency, reuse, and query pattern. Frequently changing shared entities usually favour a normalised canonical model with controlled snapshots. Stable training workloads with expensive joins often favour denormalised outputs. In either design, record feature time, label window, and data availability time so prediction-time validity is testable.
Short definition: what is Normalization vs Denormalization for ML?