A study guide for database theory normal forms

All of the jargon and confusingly said theories in textbooks and online resources are quite useless when you’re trying to learn database theory for the first time. Below is a really layperson-focused (almost mechanical) set of rules for when you’re trying to determine the normal form of a database table.

Visually, a functional dependency could look like any of the following forms:
A -> B
A -> BC
BC -> D
BC-> DE

BCNF

The left side of every functional dependency has to be a key

3NF

The left side of every functional dependency has to be a key
OR
The right side of every functional dependency has to be an attribute that is part of the key

2NF

For every non-key on the right side, you must end up with a key on the left side – either directly or by way of transitivity.

1NF

Basically anything that’s in tabular form.


If you need more help:

Functional dependency: a relationship between two attributes (ex: A -> B) where for two rows in a table, if they have the same value for A, then they must have the same value for B.

Determinant: the left side of a functional dependency

Resultant: the right side of a functional dependency

Key: an attribute that (with the complete set of functional dependencies) functionally determines every other attribute.

Composite (aka Compound) Key: a key that consists of two or more attributes

Candidate Key: one of possibly many keys (composite or not)

Primary Key: a candidate key that’s chosen as the key based on performance, storage concerns.

Prime Attribute: an attribute that is a part of a composite key.

If you want some examples and exercises, I highly recommend chapter 3 of A First Course in Database Systems.

Comments

comments