Beyond fulfilling 1NF and 2NF requirements, reaching 3NF normalization comes down to really one thing. You must remove columns that are not solely dependent on the table’s primary key. This is where some DB designers start to get confused. It’s easiest to evaluate 3NF failures by analyzing each column, one at a time.
Consider a basic users table:
| id | first_name | state | country |
| 1 | Tim | California | United States |
| 2 | John | New York | United States |
In practice, the state and country names would be stored in separate tables and referenced here as foreign keys. But for the purpose of illustration they are shown this way.
To determine if this table meets 3NF requirements we can consider each column. ‘id’ is the primary key. ‘first_name’ is the user’s first name and is fully dependent on the id. Is the ‘state’ column dependent only on the primary key? No, the state is dependent on the country. There is a relationship between the state and country that’s independent of the user’s primary key. This table has failed our 3NF evaluation.
