Database Normalization

What is Normalization
 Normalization allows us to organize
data so that it:
• Allows faster access (dependencies
make sense)
• Reduced space (less redundancy)
 Normal Forms
 Normalization is done through
changing or transforming data into
various Normal Forms.
 There are 5 Normal Forms but we
almost never use 4NF or 5NF.
 We will only be concerned with 1NF,
2NF, and 3NF.
 For a database to be in a normal
form, it must meet all requirements
of the previous forms:
• Eg. For a database to be in 2NF, it must
already be in 1NF. For a database to be
in 3NF, it must already be in 1NF and
2NF.
 Sample Data
Manager Employees
Fatma Sayed, Tariq
Abdulaziz Tafla, Mohammed
Ali Sarai, Miriam

 This data has some problems:

• The Employees column is not atomic.
 A column must be atomic, meaning that it
can only hold a single item of data. This
column holds more than one employee
name.
 Manager Employees
Fatma Sayed, Tariq
Abdulkaziz Tafla, Mohammed
Ali Sarai, Miriam

 Data that is not atomic means:

• We can’t easily sort the data
• We can’t easily search or index the data
• We can’t easily change the data
• We can’t easily reference the data in
other tables
 Manager Employee1 Employee2
Fatma Sayed Tariq
Abdulaziz Tafla Mohammed
Ali Sarai Miriam

 Breaking the Employee column into

more than 1 column doesn’t solve
our problems:
• The data may look atomic, but only
because we have many identical
columns storing a single piece of data
instead of a single column storing many
pieces of data.
• We still can’t easily sort, search, or
index our employees.

• What if a manager has more than 2

employees, 10 employees, 100
employees? We’d need to add columns
to our database just for these cases.

• It is still hard to reference our

employees in other tables.
 Manager Employee1 Employee2
Fatma Sayed Tariq
Abdulaziz Tafla Mohammed
Ali Sarai Miriam

 By the way, what would be a good

choice of a Primary Key for this
table?
 First Normal Form
 1NF means that we must:
• Eliminate duplicate columns from the
same table, and
• Create separate tables for each group of
related data into separate tables, each
with a unique row identifier (primary
key)
 Let’s get started by making our
columns atomic…
 Atomic Data
 By breaking each
tuple of our table
into an entry for Manager Employee
each employee, we Fatma Sayed
have made our Fatma Tariq
data atomic. Abdulaziz Tafla
 What would be the Abdulaziz Mohammed
primary key? Ali Sarai
Ali Miriam
 Primary Key
 The best primary Employee Manager
key would be the Sayed Fatma
Employee column. Tariq Fatma
 Every employee Tafla Abdulaziz
only has one Mohammed Abdulaziz
manager, therefore Sarai Ali
an employee is Miriam Ali
unique.
 First Normal Form
 Congratulations! Employee Manager
 The fact that all Sayed Fatma
our data and Tariq Fatma
columns is atomic Tafla Abdulaziz
and we have a Mohammed Abdulaziz
primary key means Sarai Ali
that we are in 1NF! Miriam Ali
 First Normal Form Revised
 Of course there ID Employee ManagerID
may come a day 1 Sayed 7
when we hire a 2 Tariq 7
second employee 3 Tafla 8
or manager with 4 Mohammed 8
the same name. To 5 Sarai 9
avoid this, let’s use 6 Miriam 9
an employee ID 7 Fatma
instead of their 8 Abdulaziz
name. 9 Ali
 1NF: Before and After

Manager Employees ID Employee ManagerID

Fatma Sayed, Tariq 1 Sayed 7
Abdulaziz Tafla, Mohammed 2 Tariq 7
Ali Sarai, Miriam 3 Tafla 8
4 Mohammed 8
5 Sarai 9
6 Miriam 9
7 Fatma
8 Abdulaziz
9 Ali
Moving to Second Normal Form
 A database in 2NF must also be in
1NF:
• Data must be atomic
• Every row (or tuple) must have a
unique primary key
 Plus:
• Subsets of data that apply to multiple
rows (repeating data) are moved to
separate tables
CustID FirstName LastName Address City State Zip
1 Bob Smith 123 Main St. Tucson AZ 12345
2 John Brown 555 2nd Ave. St. Paul MN 54355
3 Sandy Jessop 4256 James St. Chicago IL 43555
4 Maria Hernandez 4599 Columbia Vancouver BC V5N 1M0
5 Gameil Hintz 569 Summit St. St. Paul MN 54355
6 James Richardson 12 Cameron Bay Regina SK S4T 2V8
7 Shiela Green 12 Michigan Ave. Chicago IL 43555
8 Ian Sampson 56 Manitoba St. Winnipeg MB M5W 9N7
9 Ed Rodgers 15 Athol St. Regina SK S4T 2V9

This data is in 1NF: all fields are atomic and the CustID
serves as the primary key
 But let’s pay City State Zip
attention to the Tucson AZ 12345
City, State, and Zip St. Paul MN 54355
fields: Chicago IL 43555
• There are 2 rows of Vancouver BC V5N 1M0
repeating data:
one for Chicago, St. Paul MN 54355
and one for St. Regina SK S4T 2V8
Paul. Chicago IL 43555
• Both have the same Winnipeg MB M5W 9N7
city, state and zip Regina SK S4T 2V9
code
 The CustID determines all the data in the
row, but U.S. Zip codes determines the
City and State. (eg. A given Zip code can
only belong to one city and state so
storing Zip codes with a City and State is
redundant)

 This means that City and State are

Functionally Dependent on the value in
Zip code and not only the primary key.
 To be in 2NF, this repeating data
must be in its own table.
 So:

• Let’s create a Zip code table that maps

Zip codes to their City and State.
• Note that Canadian Postal Codes are
different: the same city and state can
have many different postal codes.
 Our Data in 2NF
CustID FirstName LastName Address Zip
1 Bob Smith 123 Main St. 12345
Customer Table

2 John Brown 555 2nd Ave. 54355

3 Sandy Jessop 4256 James St. 43555
4 Maria Hernandez 4599 Columbia V5N 1M0
5 Gameil Hintz 569 Summit St. 54355
6 James Richardson 12 Cameron Bay S4T 2V8
7 Shiela Green 12 Michigan Ave. 43555
8 Ian Sampson 56 Manitoba St. M5W 9N7
9 Ed Rodgers 15 Athol St. S4T 2V9

Zip City State •We see that we can actually save

Zip Code Table

12345 Tucson AZ 2 rows in the Zip Code table by

54355 St. Paul MN removing these redundancies: 9
43555 Chicago IL customer records only need 7 Zip
V5N 1M0 Vancouver BC code records.
S4T 2V8 Regina SK
•Zip code becomes a foreign key in
M5W 9N7 Winnipeg MB the customer table linked to the
S4T 2V9 Regina SK primary key in the Zip code table
 Advantages of 2NF
 Saves space in the database by
reducing redundancies
 If a customer calls, you can just ask
them for their Zip code and you’ll
know their city and state! (No more
spelling mistakes)
 If a City name changes, we only
need to make one change to the
database.
 Summary So Far…
 1NF:
• All data is atomic
• All rows have a unique primary key
 2NF:
• Data is in 1NF
• Subsets of data in multiple columns are
moved to a new table
• These new tables are related using
foreign keys
 Moving to 3NF
 To be in 3NF, a database must be:
• In 2NF
• All columns must be fully functionally
dependent on the primary key (There
are no transitive dependencies)
 OrderID CustID ProdID Price Quantity Total
1 1001 AB-111 50 1,000 50,000
2 1002 AB-111 60 500 30,000
3 1001 ZA-245 35 100 3,500
4 1003 MB-153 82 25 2,050
5 1004 ZA-245 42 10 420
6 1002 ZA-245 40 50 2,000
7 1001 AB-111 75 100 7,500

 In this table:
• CustomerID and ProdID depend on the
OrderID and no other column (good)
• Stated another way, “If you know the OrderID,
you know the CustID and the ProdID”
 So: OrderID  CustID, ProdID
 OrderID CustID ProdID Price Quantity Total
1 1001 AB-111 50 1,000 50,000
2 1002 AB-111 60 500 30,000
3 1001 ZA-245 35 100 3,500
4 1003 MB-153 82 25 2,050
5 1004 ZA-245 42 10 420
6 1002 ZA-245 40 50 2,000
7 1001 AB-111 75 100 7,500

 But there are some fields that are

not dependent on OrderID:
• Total is the simple product of
Price*Quantity. As such, has a transitive
dependency to Price and Quantity.
• Because it is a calculated value, doesn’t
need to be included at all.
 OrderID CustID ProdID Price Quantity Total
1 1001 AB-111 50 1,000 50,000
2 1002 AB-111 60 500 30,000
3 1001 ZA-245 35 100 3,500
4 1003 MB-153 82 25 2,050
5 1004 ZA-245 42 10 420
6 1002 ZA-245 40 50 2,000
7 1001 AB-111 75 100 7,500

 Also, we can see that Price isn’t

really dependent on ProdID, or
OrderID. Customer 1001 bought AB-
111 for $50 (in order 1) and for $75
(in order 7), while 1002 spent $60
for each item in order 2.
 OrderID CustID ProdID Price Quantity Total
1 1001 AB-111 50 1,000 50,000
2 1002 AB-111 60 500 30,000
3 1001 ZA-245 35 100 3,500
4 1003 MB-153 82 25 2,050
5 1004 ZA-245 42 10 420
6 1002 ZA-245 40 50 2,000
7 1001 AB-111 75 100 7,500

 Maybe price is dependent on the

ProdID and Quantity: The more you
buy of a given product the cheaper
that product becomes!
 So we ask the business manager and
she tells us that this is the case.
 OrderID CustID ProdID Price Quantity Total
1 1001 AB-111 50 1,000 50,000
2 1002 AB-111 60 500 30,000
3 1001 ZA-245 35 100 3,500
4 1003 MB-153 82 25 2,050
5 1004 ZA-245 42 10 420
6 1002 ZA-245 40 50 2,000
7 1001 AB-111 75 100 7,500

 We say that Price has a transitive

dependency on ProdID and Quantity.
• This means that Price isn’t just determined by
the OrderID. It is also determined by the size
(or quantity) of the order (and of course what
is ordered).
 OrderID CustID ProdID Price Quantity Total

 Let’s diagram the dependencies.

 We can see that all fields are
dependent on OrderID, the Primary
Key (white lines)
 OrderID CustID ProdID Price Quantity Total

 But Total is also determined by Price

and Quantity (yellow lines)
• This is a derived field
(Price x Quantity = Total)
• We can save a lot of space by getting
rid of it altogether and just calculating
total when we need it
 OrderID CustID ProdID Price Quantity

 Price is also determined by both

ProdID and Quantity rather than the
primary key (red lines). This is called
a transitive dependency. We must
get rid of transitive dependencies to
have 3NF.
 OrderID CustID ProdID Price Quantity

 We do this by moving the transitive

dependency into a second table…
 By splitting out the
table, we can
quickly adjust our OrderID CustID ProdID Quantity
price table to meet
our competitor, or
if the prices
changes from our
suppliers. ProdID Quantity Price
 OrderID CustID ProdID Quantity ProdID Quantity Price
1 1001 AB-111 1,000 AB-111 1 75
2 1002 AB-111 500 AB-111 101 60
3 1001 ZA-245 100 AB-111 501 50
4 1003 MB-153 25 ZA-245 1 42
5 1004 ZA-245 10 ZA-245 11 40
6 1002 ZA-245 50 ZA-245 51 35
7 1001 AB-111 100 MB-153 1 82

 The second table is our pricing list.

 Think of Quantity as a range:
• AB-111: 1-100, 101-500, 501 and more
ZA-245: 1-10, 11-50, 51 and more
 The primary Key for this second table is a
composite of ProdID and Quantity.
 OrderID CustID ProdID Quantity ProdID Quantity Price
1 1001 AB-111 1,000 AB-111 1 75
2 1002 AB-111 500 AB-111 101 60
3 1001 ZA-245 100 AB-111 501 50
4 1003 MB-153 25 ZA-245 1 42
5 1004 ZA-245 10 ZA-245 11 40
6 1002 ZA-245 50 ZA-245 51 35
7 1001 AB-111 100 MB-153 1 82

 Congratulations! We’re now in 3NF!

 We can also quickly figure out what
price to offer our customers for any
quantity they want.
 To Summarize (again)
 A database is in 3NF if:
• It is in 2NF
• It has no transitive dependencies
 A transitive dependency exists when one
attribute (or field) is determined by another
non-key attribute (or field)
 We remove fields with a transitive
dependency to a new table and link them by
a foreign key.
 Summarizing
 A database is in 2NF if:
• It is in 1NF
• There is no repeating data in its tables.
 Put another way, if we use a composite
primary key, then all attributes are
dependent on all parts of the key.
 And Finally…
 A database is in 1NF if:
• All its attributes are atomic (meaning
they contain only a single unit or type of
data), and
• All rows have a unique primary key.