core practice · coding problem
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.
The mechanism
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.
Expected evidence
key ['orderId'], dep {determinant:['customerId'], dependent:'customerCity'} -> true (transitive dependency)Try this drill in the practice workspace →
Hints when you need them
- A determinant containing every key column is fine — that is just the key determining an attribute.
- A dependent that is part of the key is a different normal-form question; treat it as not a 3NF violation here.
Watch for these 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