Store each fact once so it can never disagree with itself — or copy it everywhere so nobody has to join.
Write your address in one address book and everything points at it, or write it on every envelope. The first is easy to change; the second is faster to post.
It's the reason the warehouse schema shouldn't look like the app schema, and the reason copying data can be correct rather than sloppy.
Normalization removes duplication: every fact lives in exactly one place, so updating a customer's address is one write and there is no way for two copies to disagree. That is precisely what a transactional system needs. Denormalization does the opposite: it copies the address next to every order, so a query that wants both reads one table. That is precisely what an analytical system needs, because the join it avoids would otherwise shuffle terabytes across a cluster. The rule is not 'normalize good, denormalize bad' — it is that normalization optimises for writes and correctness, denormalization optimises for reads, and you pick per system based on which one you do more of.
Normalization stores every fact exactly once, so writes are cheap and updates can't create contradictions — right for OLTP. Denormalization duplicates data so reads need no joins — right for OLAP, where reads dominate and the duplicated copy is immutable history anyway. The cost of denormalizing is that a change has to be rewritten everywhere it was copied.
Normalization vs. Denormalization (Hands On) | Events and Event Streaming — Confluent, 2:12