

0 / 2 embers
0 / 3000 xp
click for more info
Complete a lesson to start your streak
click for more info
Difficulty: 6
click for more info
Not enough gems
Cost: 6 gems
1: Table Relationships
incomplete
2: One to Many
incomplete
3: Many to Many
incomplete
4: Database Normalization
incomplete
5: Normal Forms
incomplete
6: First Normal Form (1NF)
incomplete
7: Second Normal Form (2NF)
incomplete
8: Third Normal Form (3NF)
incomplete
9: Boyce-Codd Normal Form (BCNF)
incomplete
10: Normalization Review
incomplete
11: Query Practice – Users & Banks
incomplete
Back
ctrl+,
Next
ctrl+.
This lesson's interactive features are locked, please to keep using them
A table in third normal form (3NF) follows all the rules of second normal form, and one additional rule:
Notice that this is only slightly different from second normal form. In second normal form we can't have a column completely dependent on only part of the primary key, and in third normal form we can't have a column that is entirely dependent on anything that isn't the primary key.
In this table, the primary key is simply the id column.
| id | name | first_initial | |
|---|---|---|---|
| 1 | Lane | l | [email protected] |
| 2 | Breanna | b | [email protected] |
| 3 | Lane | l | [email protected] |
This table is in second normal form because first_initial is not dependent on a part of the primary key. However, because it is dependent on the name column, it doesn't adhere to third normal form.
The way to convert the table above to 3NF is to add a new table that maps a name directly to its first_initial. Notice how similar this solution is to 2NF.
| id | name | |
|---|---|---|
| 1 | Lane | [email protected] |
| 2 | Breanna | [email protected] |
| 3 | Lane | [email protected] |
| name | first_initial |
|---|---|
| Lane | l |
| Breanna | b |
The same exact rule of thumb applies to the second and third normal forms.
Optimize for data integrity and data de-duplication first by adhering to 3NF. If you have speed issues, de-normalize accordingly.
This rollout of business accounts is really causing some headaches for our development team. The companies table has been a disaster. Our database architect pointed out that the idea behind the size field is redundant.
If a company has more than 100 employees, we consider it "large," otherwise it's "small." That's something we can calculate from the num_employees field, rather than storing it separately.
Remember the IIF function and the AS clause.