Concepts of Database Management

Eighth Edition

Chapter 5
Database Design 1: Normalization
 What is Normalization?
• NORMALIZATION is a database design technique
that organizes tables in a manner that reduces
redundancy and dependency of data.
• Normalization divides larger tables into smaller
tables and links them using relationships.
• The purpose of Normalization is to eliminate
redundant (useless) data and ensure data is stored
logically.

2
 Database Normal Forms
• Normal forms:
– First normal form (1NF)
– Second normal form (2NF)
– Third normal form (3NF)
– Boyce-Code Normal Form(BCNF)
– Fourth normal form(4NF)
• Table in 1NF better than table in unmormalized form
• Table in 2NF better than table in 1NF, and so on
• In most practical applications, normalization achieves
its best in 3rd Normal Form.
3
 Unnormalized Form
• Unnormalized table contains a repeating group.
• The inner parentheses indicate that there is a repeating group.
Orders (OrderNum, OrderDate, (ItemNum, NumOrdered) )

repeating groups

Unnormalized table
4
 First Normal Form
• In most definitions of • A relation is said to be
the relational model in first normal form
– All data values should (1NF) if all data values
be atomic are atomic
– This means that table
entries should be single
values, not sets or
composite objects
 First Normal Form(1NF)
• To convert to a 1NF relation, split up any non-atomic values
Orders (OrderNum, OrderDate, ItemNum, NumOrdered)
• The primary key is the combination of OrderNum and ItemNum

Unnormalized form The first normal form

6
Problems in 1NF
• INSERT anomalies
– Can't add a order record with
no itemNum, because primary
key field does not accept the
NULL value
• UPDATE anomalies
– To change items for FD11, we
have to change two rows
• DELETE anomalies
– If we remove 51625, we
remove MT03 as well
 Database Anomalies
• Anomalies are avoided by the process of
normalization.
 What is a Function?
• A function relates each element of a set with exactly
one element of another set (possibly the same set).

9
 Functional Dependence(FD)

• Functional dependency is a constraint between two

sets of attributes from the database
• Column B is functionally dependent on column A
– Each value for A is associated with exactly one value of B
– This relationship is indicated by the representation below :
A→B
Where, the left side is called the determinant, and the right side
is the dependent.
– A functionally determines B
 Functional Dependence Examples
• SSN determines Name, Address and Birthdate. Given SSN, we
can determine any of the other attributes in the table.
SSN   —> Name, Address, Birthdate
• SSN and Course determine the date completed
(DateCompleted). This must also work for a composite PK.
SSN, Course  —>     DateCompleted
• ISBN determines Title.
ISBN  —>     TItle

11
 Functional Dependency Examples

• A relation of TEACH with a possible functional dependency

Text -> Course
• However, Course -> Text is NOT because one course value
“Data Structures” had two text values, Bartram and
Horowitz”
 Rules of Functional Dependencies
• Let A,B,C,D be subset of attributes of a
relation R.
­ Rule 1 (Union):
IF X determines Y and X determines Z
then X must also determine Y and Z
Example:
A -> B, A -> C, A -> D, A -> E
A -> BCDE
– Rule 2 (Reflexivity):
IF Y is a subset of X, THEN X determines Y
Example: AB -> B

13
 Rules of Functional Dependencies
• Rule 3(Augmentation):
IF X determines Y, THEN XZ determines YZ
for any Z 
Example:  IF A -> B Then AC -> BC

• Rule 4(Transitivity):
IF X determines Y, and Y determines Z,
THEN X must also determine Z
Example: A -> C and C -> D Then A -> D

14
 Keys
• Column A (or a collection of columns) is the primary key for a
relation R
– Property 1: all columns in R are functionally dependent on A
– Property 2: no subcollection of columns in A also have Property 1
• Super key: the set of attribute which can uniquely identify a
tuple
• Candidate key: the minimal set of attribute which can uniquely
identify a tuple
• Alternate keys: candidate keys not chosen as primary key

15
 Key Example
Customers(ID, Name, SSN, Address, DateOfBirth)
•SuperKeys
– ID
– SSN
– ID, Name
– ID, Name, SSN
– ID, Name, SSN, Address

•Candidate keys: ID, SSN

•If we choose ID as Primary key, SSN becomes an alternate key
 Prime & Non-prime attributes
• Prime attribute
– Attribute set that belongs to any candidate key
• Non-Prime attribute
– Attribute set does not belongs to any candidate key
• Example
Student_Project (studentID, projectID, studentName, ProjectName)
– Prime attribute: studentId, projectId
– Non-prime attributes: studentName, projectName
 Q&A

In the Customer table, is CustomerNum functionally

dependent on RepNum? No

18
• In the OrderLine table, is QuotedPrice functionally dependent
on OrderNum? No
• Is QuotedPrice functionally dependent on ItemNum? No
• On which columns is QuotedPrice functionally dependent?
(OrderNum, ItemNum)

19
 Item:

• Is category column the primary key for the Item

table? No
• Is the combination of ItemNum and Description the
Pk for the Item table? No, because ItemNum alone
has this property
20
 OrderLine:

• Is OrderNum the Pk for the orderLine table? No

• Is the combination of OrderNum and ItemNum
the pk for the OrderLine table? yes

21
 Second Normal Form
• Non-prime attribute: not part of primary key
• Table (relation) in second normal form (2NF)
– Table is in first normal form
– No non-prime attribute is dependent on only a portion of
primary key
• Dependency diagram: arrows indicate all functional
dependencies on next slide
– Arrows above boxes: normal dependencies
– Arrows below boxes: partial dependencies
• Partial dependencies: only on a portion of the primary key

22
Orders (OrderNum, OrderDate, ItemNum, Description, NumOrdered,
QuotedPrice)

FIGURE 5-8: Dependences in the Orders table 23

 Second Normal Form

• Functional dependencies:
OrderNum → OrderDate: Partial Functional Dependency
ItemNum → Description : Partial Functional Dependency
OrderNum, ItemNum → OrderDate, Descriptioon, NumOrdered,QuotedPrice

24
Anomalies

• Insert: if you add an item but there is no order, you can

not add because PK is orderNum and itemNum
• Update: the change to FD11 description require more
than one change
• Delete: if you delete order 51608, you will lose all info
about item CD33.
25
 Note
• When a table’s primary key contains only one
column, the table is automatically in 2NF because
there is no column to be dependent on only a
portion of the primary key

26
 Convert 1NF to 2NF
1. Identify primary key to the 1NF relationship
2. Identify functional dependencies in the relationship
3. If there is partial dependencies to the primary key,
delete and place it into new relationship with the
copy of its determinant
Convert 1NF to 2NF

1. Take each subset of the set of columns that makes up the PK; then begin a new
table with this subset as the PK
(OrderNum,
(ItemNum,
(OrderNum, ItemNum,
2. Place each of the other columns with its appropriate PK; place each PK with the
minimal collections on which it depends
(OrderNum, OrderDate)
(ItemNum, Description)
(OrderNum, PartNum, NumOrdered, QuotedPrice)
3. Give each new table a name that is descriptive of the table’s contents
Orders(OrderNum, OrderDate)
Item(ItemNum, Description)
OrderLine(OrderNum, ItemNum, NumOrdered, QuotedPrice)
28
 29
FIGURE 5-9: Conversion to second normal form
 Third Normal Form
• Table (relation) in second normal form (2NF)
• There is no transitive functional dependency
• Transitive functional dependency
– A is functionally dependent on B, and B is functionally
dependent on C.
– In this case, C is transitively dependent on A via B.

30
FIGURE 5-11: Dependencies in the Customer table
31
 Third Normal Form

• Functional dependencies:
CustomerNum → CustomerName, Balance, CreditLimit, RepNum,
LastName, FirstName
RepNum → LastName, FirstName

32
 Anomaly

• Insert: To add rep 87, rep 87 must represent at least one

customer.
• Update: The change of rep name requires more than one
changes.
• Delete: If you delete all customers of rep 45, you will lost all
info about rep 45.
33
 What is a determinant?
• Determinant: column(s) that determines another
column
• Examples
CustomerNum → CustomerName, Balance, CreditLimit, RepNum,
LastName, FirstName
=> Determinant: CustomerNum

RepNum → LastName, FirstName

=> Determinant: RepNum

34
 Convert 2NF to 3NF
1. For each determinant, remove from table the columns
that depend on this determinant
2. Create new table containing all columns from the
original table that depend on this determinant
3. Make determinant the primary key of new table
4. Give each new table a name that is descriptive of the
table’s contents

35
Convert 2NF to 3NF

1. For each determinant, remove from table the columns that depend on
this determinant
(CustomerNum,
(RepNum,
2. Create new table containing all columns from the original table that
depend on this determinant
(CustomerNum, CustomerName, Balance, CreditLimit, RepNum)
(RepNum, LastName, FirstName)
3. Make determinant the primary key of new table
(CustomerNum, CustomerName, Balance, CreditLimit, RepNum)
(RepNum, LastName, FirstName)
4. Give each new table a name that is descriptive of the table’s
contents
Customer(CustomerNum, CustomerName, Balance, CreditLimit, RepNum)
Rep (RepNum, LastName, FirstName) 36
Third Normal Form (cont.)

FIGURE 5-12: Conversion to third normal form (continued)

37
 Exercise 1
• Convert the following table to 3NF.
Student(sno, sname, advisorNum, adisorvName,
(courseNum, description, grade))

• Function dependencies:
–(sno, courseNum) -> sname, advisorNum, advisorName,
description, grade
–sno -> sname, advisorNum, advisorName
–advisorNum -> advisorName,
–courseNum -> description

38
 Exercise 1 – Solution
• 0NF
Student(sno, sname, advisorNum, adisorvName, (courseNum,
description, grade))
• 1NF: remove the repeating group
Student(sno, sname, advisorNum, adisorvName, courseNum,
description, grade))
• 2NF: Remove the partial FDs
Student(sno, sname, advisorNum, advisorName)
Course(courseNum,description)
Enrollment(sno, courseNum, grade)

• 3NF:Remove the transitive FD

Student(sno, sname, advisorNum)
Course(courseNum,description)
Advisor(advisorNum,advisorName)
StudentCourse(sno, courseNum, grade)
39
 Exercise 2

Functional Dependencies:
•orderNo, productNo -> orderName, custName, custAddr,
cityCountry, orderDate, desc, qty, unitPrice
•orderNo -> custNo, custName, custAdrd, orderdate
•productNo -> desc, qty, unitprice
•custNo -> custName, custAddr
 Exercise 2 solution:

• 0NF
ORDER(orderNo, custNo, name, address, orderdate, (productNo, desc, qty, unitprice))
• 1NF: remove repeating group
ORDER(orderNo, custNo, name, address, orderdate, productNo, desc, qty, unitprice)
• 2NF: remove the partial FDs
ORDER_LINE(orderNo, productNo)
ORDER(orderNo, custNo, custName, custAddr, orderdate)
PRODUCT(productNo, desc, qty, unitprice)
• 3NF: remove the transitive FD
ORDER_LINE(orderNo, productNo)
ORDER(orderNo, custNo, orderdate)
CUSTOMER(cusNo, custName, custAddr)
PRODUCT(productNo, desc, qty, unitprice)