Database normalization

The same ZIP stored with two cities is not a data-entry quirk. It is a transitive dependency waiting to lie.

The problem

A single Employee table held ID, name, street, city, state, ZIP, department, manager ID, position, and salary. Employee ID determines the row. Two facts did not depend on the employee; they depended on another non-key column.

ZIP → City, State. Chain: Employee ID → ZIP → City, State. In the sample, ZIP 32829 was typed as both Anytown and Sometown. 32831 had the same contradiction.
Department → Manager ID. IT always pointed at 1015; Sales at 1021. Manager is a property of the department, not of Dickens vs Poe.

Position does not determine salary here: two Vice Presidents, two salaries. The data disproved a dependency that looked tidy on a whiteboard.

What 3NF looks like

Keep on Employee

Emp ID, name, street, ZIP (FK), Dept (FK), position, salary. One person, one row, no city typed twice.

Split out

ZIP (ZIP, city, state). Department (department, mgr ID). Update the ZIP once; every employee in that ZIP follows.

So what

Analysts inherit 1NF dumps from HR and PMS exports. Finding the transitive dep is how you stop a dashboard from averaging two cities for one ZIP. This is the same instinct as not inventing store location on a lab rental table that does not have it.