Warehouse designers have a rule that predates relational databases by decades: store each item in exactly one home location, and keep a separate, easily updated index of where that location is. It sounds obvious until you've worked in — or queried — a system that doesn't do this, where the same fact is duplicated in five places and updating one leaves the other four quietly wrong.
First normal form, first shelving rule
Database normalization formalises the same instinct into rules: don't repeat data across rows, separate facts that change independently into their own tables, and reference rather than duplicate. A warehouse that stores a product's price on every single unit's tag, rather than looking it up centrally at checkout, has exactly the update problem a first-year database course exists to prevent.
The cost of doing it properly
Normalization isn't free. A fully normalised warehouse requires a lookup step every time you want an answer — walk to the location, check the central price list, cross-reference. A fully normalised database pays the same tax in joins. Both disciplines eventually denormalise on purpose, in specific spots, once they know exactly which queries need to be fast and are willing to accept the duplication that speed requires.
Normalize until it hurts, denormalize until it works — the maxim holds whether the shelf is physical or virtual.
The parallel isn't decorative. Warehouse logistics and schema design were solving the same trade-off long before either discipline had a name for it.