First Normal Form
- Eliminate repeating groups in individual tables.
- Create a separate table for each set of related data.
- Identify each set of related data with a primary key.
Notice how we’re breaking that first rule by repeating the url1 and url2 fields? And what about Rule Three, primary keys?
Rule Three basically means we want to put some form of unique, auto-incrementing integer value into every one
of our records. Otherwise, what would happen if we had two users named Joe and we wanted to tell them apart?
When we apply the rules of the First Normal Form we come up with the following table:
Rule Three basically means we want to put some form of unique, auto-incrementing integer value into every one
of our records. Otherwise, what would happen if we had two users named Joe and we wanted to tell them apart?
When we apply the rules of the First Normal Form we come up with the following table:
| users | ||||
| userId | name | company | company_address | url |
| 1 | Joe | ABC | 1 Work Lane | abc.com |
| 1 | Joe | ABC | 1 Work Lane | xyz.com |
| 2 | Jill | XYZ | 1 Job Street | abc.com |
| 2 | Jill | XYZ | 1 Job Street | xyz.com |
Now our table is said to be in the First Normal Form. We’ve solved the problem of url field limitation,
but look at the headache we’ve now caused ourselves. Every time we input a new record into the users table,
we’ve got to duplicate all that company and user name data. Not only will our database grow much
larger than we’d ever want it to, but we could easily begin corrupting our data by misspelling some of
that redundant information. Let’s apply the rules of Second Normal Form:
but look at the headache we’ve now caused ourselves. Every time we input a new record into the users table,
we’ve got to duplicate all that company and user name data. Not only will our database grow much
larger than we’d ever want it to, but we could easily begin corrupting our data by misspelling some of
that redundant information. Let’s apply the rules of Second Normal Form:
