Databases & Storage · core
Normalization
Functional dependencies, 1NF through BCNF, and the cases where denormalising is right.
Mental model
Normalisation removes update anomalies by making every fact live in exactly one place: if a non-key column depends on something other than the whole key, an update has to touch several rows and can leave them disagreeing. Third normal form is 'every non-key attribute depends on the key, the whole key, and nothing but the key'. Denormalisation is the deliberate reintroduction of duplication to avoid a join — legitimate when reads dominate and you own the write path that keeps copies consistent, indefensible when it is an accident.
How to study Normalization
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use the linked roadmap and primary implementation references to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Normalization with Secondary Indexes, Join Algorithms. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Spot the update anomaly and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
Schema review, and the reason a denormalised read model needs an owner for its write path.
Common mistakes
- Denormalising for performance before measuring whether the join was ever the problem
- Duplicating a value with no mechanism to keep the copies in sync, so they silently diverge
- Treating normal forms as a purity contest rather than a defence against anomalies
- Normalising append-only analytical tables where update anomalies cannot occur
Learn from primary sources
Use the linked roadmap context and practice prompt.
Practice and explain it back
Spot the update anomaly
Implement violatesThirdNF(columns, key, dependencies) -> boolean. `dependencies` is [{determinant: string[], dependent: string}]. Report a 3NF violation when a dependency's determinant is NOT a superset of the key AND its dependent is not itself part of the key — i.e. a non-key attribute determined by something other than the whole key.
Expected evidence: key ['orderId'], dep {determinant:['customerId'], dependent:'customerCity'} -> true (transitive dependency)
Open the interactive drill →Review prompts
- When is denormalising a schema a legitimate engineering decision rather than a shortcut, and what must you own if you do it?
Build evidence
Use a roadmap capstone to turn this concept into working evidence.