DATA NORMALIZATION
CS 260
Database Systems
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
Introduction

Database normalization is a process used to
generate a schema that is without unnecessary
redundancy while allowing information to be
retrieved easily
 It
consists primarily of breaking tables into smaller
tables to remove redundant data that can lead to
anomalies

The results of the normalization process allow
schemas to be described as adhering to a
particular “normal form”
Introduction

Normalization requires domain specific knowledge
in order to identify “functional dependencies”
 Some
of this may be expressed in an ER model, but not
always


Normalization is particularly useful for addressing
and fixing an existing (and possibly poorly
designed) database schema
Normalization allows for a design that is free of
insertion, update, and deletion anomalies
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
Anomalies

Insertion anomaly
 Occurs
when inserting a new record causes data to
become inconsistent
 In
the following example, an insertion anomaly occurred
when Franklin T. Wong’s employee record was first inserted

His department manager’s SSN was entered incorrectly
 Occurs
also when a new record cannot be inserted due
to missing data
 In
the following example, an insertion anomaly would occur
if an attempt was made to insert a record for a new project
in the EMPLOYEE-PROJECTS table

Cannot be inserted if it doesn’t have any associated employees
Anomalies
EMPLOYEE (SSN, Ename, Bdate, Address, Dnumber, Dname, DMgrSSN)
SSN
123456789
EName
Smith, John B.
Bdate
09-Jan-55
333445555
999887777
987654321
666884444
Wong, Franklin T.
Zelaya, Alicia J.
Wallace, Jennifer S.
Narayan Ramesh K..
08-Dec-45
19-Jul-61
19-Jun-31
15-Sep-52
453453453
987987987
888665555
English, Joyce A.
Jabbar, Ahmad V.
Borg, James E.
31-Jun-62
29-Mar-59
10-Nov-27
Address
731 Fondren, Houston,
TX
638 Voss, Houston, TX
3321 Castle, Spring, TX
291 Berry, Bellaire, TX
975 FireOak, Humble,
TX
5631 Rice, Houston, TX
980 Dallas, Houston, TX
450 Stone, Houston, TX
Dnumber
5
DName
Research
DMgrSSN
333445555
5
4
4
5
Research
Administration
Administration
Research
333444555
987654321
987654321
333445555
5
4
1
Research
Administration
Headquarters
333445555
987654321
888665555
EMPLOYEE-PROJECTS (SSN, ProjNumber, Hours, ProjName, ProjLoc)
SSN
123456789
123456789
666884444
453453453
453453453
333445555
333445555
333445555
333445555
EName
Smith, John B.
Smith, John B.
Narayan, Ramesh K.
English, Joyce A.
Meadows, Joyce A.
Wong, Frank
Wong, Frank
Wong, Franklin T.
Wong, Franklin T.
ProjNumber
1
2
3
1
2
2
3
10
20
Hours
32.5
7.5
40.0
20.0
20.0
10.0
10.0
10.0
10.0
ProjName
ProductX
ProductY
ProductZ
ProductX
ProductY
ProductY
ProductZ
Computerization
Reorganization
ProjLocation
Stafford
Sugarland
Houston
Bellaire
Sugarland
Bellaire
Houston
Stafford
Houston
Anomalies

Update anomaly
 Occurs
when some but not all instances of a data value
are updated
 In
the following example, an update anomaly occurred if an
attempt to update Joyce English’s records was made to
accommodate her last name change

This was updated in the EMPLOYEE table and in one record in the
EMPLOYEE-PROJECTS table, but not in the second record in the
EMPLOYEE-PROJECTS table
 An
update anomaly may also have occurred if an attempt
was made to change Project X’s location to “Bellaire”

Project 1’s related data was missed in the update
Anomalies
EMPLOYEE (SSN, Ename, Bdate, Address, Dnumber, Dname, DMgrSSN)
SSN
123456789
EName
Smith, John B.
Bdate
09-Jan-55
333445555
999887777
987654321
666884444
Wong, Franklin T.
Zelaya, Alicia J.
Wallace, Jennifer S.
Narayan Ramesh K..
08-Dec-45
19-Jul-61
19-Jun-31
15-Sep-52
453453453
987987987
888665555
English, Joyce A.
Jabbar, Ahmad V.
Borg, James E.
31-Jun-62
29-Mar-59
10-Nov-27
Address
731 Fondren, Houston,
TX
638 Voss, Houston, TX
3321 Castle, Spring, TX
291 Berry, Bellaire, TX
975 FireOak, Humble,
TX
5631 Rice, Houston, TX
980 Dallas, Houston, TX
450 Stone, Houston, TX
Dnumber
5
DName
Research
DMgrSSN
333445555
5
4
4
5
Research
Administration
Administration
Research
333444555
987654321
987654321
333445555
5
4
1
Research
Administration
Headquarters
333445555
987654321
888665555
EMPLOYEE-PROJECTS (SSN, ProjNumber, Hours, ProjName, ProjLoc)
SSN
123456789
123456789
666884444
453453453
453453453
333445555
333445555
333445555
333445555
EName
Smith, John B.
Smith, John B.
Narayan, Ramesh K.
English, Joyce A.
Meadows, Joyce A.
Wong, Frank
Wong, Frank
Wong, Franklin T.
Wong, Franklin T.
ProjNumber
1
2
3
1
2
2
3
10
20
Hours
32.5
7.5
40.0
20.0
20.0
10.0
10.0
10.0
10.0
ProjName
ProductX
ProductY
ProductZ
ProductX
ProductY
ProductY
ProductZ
Computerization
Reorganization
ProjLocation
Stafford
Sugarland
Houston
Bellaire
Sugarland
Bellaire
Houston
Stafford
Houston
Anomalies

Deletion anomaly
 Occurs
when a record is deleted to remove some data
instance, but other data was inadvertently deleted as
well
 In
the following example, a deletion anomaly would occur if
Franklin T. Wong’s records are removed from the EMPLOYEE
and EMPLOYEE-PROJECTS tables

Now data regarding the “Computerization” and
“Reorganization” projects are gone
Anomalies
EMPLOYEE (SSN, Ename, Bdate, Address, Dnumber, Dname, DMgrSSN)
SSN
123456789
EName
Smith, John B.
Bdate
09-Jan-55
333445555
999887777
987654321
666884444
Wong, Franklin T.
Zelaya, Alicia J.
Wallace, Jennifer S.
Narayan Ramesh K..
08-Dec-45
19-Jul-61
19-Jun-31
15-Sep-52
453453453
987987987
888665555
English, Joyce A.
Jabbar, Ahmad V.
Borg, James E.
31-Jun-62
29-Mar-59
10-Nov-27
Address
731 Fondren, Houston,
TX
638 Voss, Houston, TX
3321 Castle, Spring, TX
291 Berry, Bellaire, TX
975 FireOak, Humble,
TX
5631 Rice, Houston, TX
980 Dallas, Houston, TX
450 Stone, Houston, TX
Dnumber
5
DName
Research
DMgrSSN
333445555
5
4
4
5
Research
Administration
Administration
Research
333444555
987654321
987654321
333445555
5
4
1
Research
Administration
Headquarters
333445555
987654321
888665555
EMPLOYEE-PROJECTS (SSN, ProjNumber, Hours, ProjName, ProjLoc)
SSN
123456789
123456789
666884444
453453453
453453453
333445555
333445555
333445555
333445555
EName
Smith, John B.
Smith, John B.
Narayan, Ramesh K.
English, Joyce A.
Meadows, Joyce A.
Wong, Frank
Wong, Frank
Wong, Franklin T.
Wong, Franklin T.
ProjNumber
1
2
3
1
2
2
3
10
20
Hours
32.5
7.5
40.0
20.0
20.0
10.0
10.0
10.0
10.0
ProjName
ProductX
ProductY
ProductZ
ProductX
ProductY
ProductY
ProductZ
Computerization
Reorganization
ProjLocation
Stafford
Sugarland
Houston
Bellaire
Sugarland
Bellaire
Houston
Stafford
Houston
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
Functional Dependence

Functional dependence
 Functional
dependence occurs when the values of one
or more attributes (A) in some entity unambiguously
determine the values of one or more other attributes (B)
 Notation:
A
B
 In other words, if we know the values of all attributes in set
A, then we can uniquely identify the values of all attributes
in set B

These sets can consist of one or more attributes
Functional Dependence

Strategies for determining functional dependence

For each field, ask if its value can be determined if the
values of one or more other fields are known


Is the field dependent on one or more other fields
For each field, ask if its value is known, can the values of
any other fields be identified

Is the field a determinant for one or more other fields
Group functional dependencies with the same determinant
into a single relation
 The following types of functional dependencies can be
ignored




{A, B}
{A, B}
{A, B}
A
B
{A, B}
Functional Dependence

Super Keys
A
super key is a set of attributes (possibly consisting of
a single attribute) that uniquely identifies a record
 Example
 In
the CANDY_CUSTOMER table in our candy database,
{cust_id} is a super key



{cust_id, cust_name} is also a super key
{cust_id, cust_type} is also a super key
Any combination of attributes in CANDY_CUSTOMER that
includes a super key is also a super key
Sample Database (CANDY)
CANDY_CUSTOMER CUST_ID
CUST_NAME
CUST_TYPE
CUST_ADDR
CUST_ZIP
CUST_PHONE USERNAME PASSWORD
1 Jones, Joe
P
1234 Main St.
91212 434-1231
jonesj
2 Armstrong,Inc.
R
231 Globe Blvd.
91212 434-7664
armstrong
3 Sw edish Burgers
R
1889 20th N.E.
91213 434-9090
sw edburg
4 Pickled Pickles
R
194 CityView
91289 324-8909
pickpick
5 The Candy Kid
W
2121 Main St.
91212 563-4545
kidcandy
6 Waterman, Al
P
23 Yankee Blvd.
91234
w ateral
7 Bobby Bon Bons
R
12 Nichi Cres.
91212 434-9045
bobbybon
8 Crow sh, Elias
P
7 77th Ave.
91211 434-0007
crow el
9 Montag, Susie
P
981 Montview
91213 456-2091
montags
10 Columberg Sw eets W
239 East Falls
91209 874-9092
columsw e
1234
3333
2353
5333
2351
8900
3011
1033
9633
8399
CANDY_PURCHASE
PURCH_ID
CANDY_CUST_TYPE
PROD_ID
CUST_ID
PURCH_DATE DELIVERY_DATE POUNDS
STATUS
1
1
5
28-Oct-04
28-Oct-04
3.5 PAID
CUST_TYPE_ID
CUST_TYPE_DESC
2
2
6
28-Oct-04
30-Oct-04
15 PAID
P
Private
3
1
9
28-Oct-04
28-Oct-04
2 PAID
R
Retail
3
3
9
28-Oct-04
28-Oct-04
3.7 PAID
Wholesale
4
3
2
28-Oct-04
5
1
7
29-Oct-04
29-Oct-04
3.7 NOT PAID
5
2
7
29-Oct-04
29-Oct-04
1.2 NOT PAID
5
3
7
29-Oct-04
29-Oct-04
4.4 NOT PAID
6
2
7
29-Oct-04
W
CANDY_PRODUCT
PROD_ID
PROD_DESC
PROD_COSTPROD_PRICE
3.7 PAID
3 PAID
1 Celestial Cashew Crunch
$
7.45
$
10.00
7
2
10
29-Oct-04
14 NOT PAID
2 Unbrittle Peanut Paradise
$
5.75
$
9.00
7
5
10
29-Oct-04
4.8 NOT PAID
3 Mystery Melange
$
7.75
$
10.50
8
1
4
29-Oct-04
4 Millionaire’s Macadamia Mix
$
12.50
$
16.00
8
5
4
29-Oct-04
5 Nuts Not Nachos
$
6.25
$
9.50
9
5
4
29-Oct-04
29-Oct-04
1 PAID
7.6 PAID
29-Oct-04
3.5 NOT PAID
Functional Dependence

Candidate Keys

A candidate key is a super key with a minimal set of
attributes

Unlike a primary key, a table can potentially have more than one
candidate key


So a primary key is a candidate key, but a candidate key is not
necessarily a primary key
Example

In the CANDY_CUSTOMER table in our candy database, {cust_id}
is a candidate key


The addition of any other attributes in this set would be a super key,
but not a candidate key
If usernames also must be unique, then {username} is also a
candidate key
Sample Database (CANDY)
CANDY_CUSTOMER CUST_ID
CUST_NAME
CUST_TYPE
CUST_ADDR
CUST_ZIP
CUST_PHONE USERNAME PASSWORD
1 Jones, Joe
P
1234 Main St.
91212 434-1231
jonesj
2 Armstrong,Inc.
R
231 Globe Blvd.
91212 434-7664
armstrong
3 Sw edish Burgers
R
1889 20th N.E.
91213 434-9090
sw edburg
4 Pickled Pickles
R
194 CityView
91289 324-8909
pickpick
5 The Candy Kid
W
2121 Main St.
91212 563-4545
kidcandy
6 Waterman, Al
P
23 Yankee Blvd.
91234
w ateral
7 Bobby Bon Bons
R
12 Nichi Cres.
91212 434-9045
bobbybon
8 Crow sh, Elias
P
7 77th Ave.
91211 434-0007
crow el
9 Montag, Susie
P
981 Montview
91213 456-2091
montags
10 Columberg Sw eets W
239 East Falls
91209 874-9092
columsw e
1234
3333
2353
5333
2351
8900
3011
1033
9633
8399
CANDY_PURCHASE
PURCH_ID
CANDY_CUST_TYPE
PROD_ID
CUST_ID
PURCH_DATE DELIVERY_DATE POUNDS
STATUS
1
1
5
28-Oct-04
28-Oct-04
3.5 PAID
CUST_TYPE_ID
CUST_TYPE_DESC
2
2
6
28-Oct-04
30-Oct-04
15 PAID
P
Private
3
1
9
28-Oct-04
28-Oct-04
2 PAID
R
Retail
3
3
9
28-Oct-04
28-Oct-04
3.7 PAID
Wholesale
4
3
2
28-Oct-04
5
1
7
29-Oct-04
29-Oct-04
3.7 NOT PAID
5
2
7
29-Oct-04
29-Oct-04
1.2 NOT PAID
5
3
7
29-Oct-04
29-Oct-04
4.4 NOT PAID
6
2
7
29-Oct-04
W
CANDY_PRODUCT
PROD_ID
PROD_DESC
PROD_COSTPROD_PRICE
3.7 PAID
3 PAID
1 Celestial Cashew Crunch
$
7.45
$
10.00
7
2
10
29-Oct-04
14 NOT PAID
2 Unbrittle Peanut Paradise
$
5.75
$
9.00
7
5
10
29-Oct-04
4.8 NOT PAID
3 Mystery Melange
$
7.75
$
10.50
8
1
4
29-Oct-04
4 Millionaire’s Macadamia Mix
$
12.50
$
16.00
8
5
4
29-Oct-04
5 Nuts Not Nachos
$
6.25
$
9.50
9
5
4
29-Oct-04
29-Oct-04
1 PAID
7.6 PAID
29-Oct-04
3.5 NOT PAID
Functional Dependence

Functional dependence is often illustrated for a
table using a dependency diagram
 This
diagram identifies the fields whose values
determine the values of other fields
 Arrows are drawn from the “determinant” fields to the
“dependent” fields

We’ll see examples of these as we discuss normal
forms in more detail
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
First Normal Form

First normal form (1NF)
A
database table is in 1NF if it meets the following
requirements:
 It
does not contain any multivalued attributes
 It does not contain any inappropriately complex attributes
 Solution
for converting a database table to 1NF
 Replace
multivalued attributes with multiple records
 Replace complex attributes with atomic attributes
First Normal Form

1NF example
 Non-1NF
Proj#
1
ProjName
Satellite
Table
Emp#
101, 102,
104
EmpName
News, John; Senior, David;
Ramoras, Ann
 Corresponding
Proj#
1
1
1
ProjName
Satellite
Satellite
Satellite
 This
Emp#
101
102
104
JobType
Elect Eng,
Comm Tech,
Comm Tech
ChgPerHour
65, 60, 60
Hours
13, 16, 19
1NF Table
EmpName
News, John
Senior, David
Ramoras, Ann
JobType
Elect Eng
Comm Tech
Comm Tech
ChgPerHour
65
60
60
Hours
13
16
19
assumes that an EmpName will never need to be
searched, sorted, or formatted according to first/last names
First Normal Form

Functional dependencies of 1NF table
Proj#
1
1
1
2
2
ProjName
Satellite
Satellite
Satellite
WAN
WAN
Determinants
Emp#
101
102
104
101
104
EmpName
News, John
Senior, David
Ramoras, Ann
News, John
Ramoras, Ann
JobType
Elect Eng
Comm Tech
Comm Tech
Elect Eng
Comm Tech
ChgPerHour
65
60
60
65
60
Hours
13
16
19
17
25
Dependents

{Proj#}
{ProjName}

{Proj#, Emp#}
{ProjName, EmpName, JobType, ChgPerHour, Hours}

{Emp#}
{EmpName, JobType, ChgPerHour}

{JobType}
{ChgPerHour}
Candidate key(s): {Proj#, Emp#}
First Normal Form

Corresponding dependency diagram
Proj#
1
1
1
2
2
ProjName
Satellite
Satellite
Satellite
WAN
WAN
Emp#
101
102
104
101
104
EmpName
News, John
Senior, David
Ramoras, Ann
News, John
Ramoras, Ann
JobType
Elect Eng
Comm Tech
Comm Tech
Elect Eng
Comm Tech
ChgPerHour
65
60
60
65
60
Hours
13
16
19
17
25
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
Second Normal Form

Second normal form (2NF)
A
database table is in 2NF if it meets the following
requirements:
 It
is in 1NF, and
 All non-prime attributes depend on all attributes of each
candidate key (no “partial dependencies”)
A
“non-prime” attribute is one that does not belong to
any candidate key of the table
 As a result, if all of a table’s candidate keys consist of
only single attributes, and it is already in 1NF, then it is
already in 2NF
Second Normal Form

Non-2NF table (previously seen table in 1NF)
Proj#
1
1
1
2
2
ProjName
Satellite
Satellite
Satellite
WAN
WAN
Emp#
101
102
104
101
104
EmpName
News, John
Senior, David
Ramoras, Ann
News, John
Ramoras, Ann
JobType
Elect Eng
Comm Tech
Comm Tech
Elect Eng
Comm Tech
ChgPerHour
65
60
60
65
60
Hours
13
16
19
17
25
Non-prime attributes dependent on only a part of the lone candidate key
Second Normal Form

Solution for converting a table to 2NF
Convert it to 1NF (if it’s not already in 1NF)
 Create a table for each of the functional dependencies that
involved only a part of the candidate key



If a M:M relationship exists between the entities that are
now in separate tables or the relationship has attributes


Those candidate key components should now be candidate keys in
their new tables
Create a linking table containing each of those candidate key
components, as well as any attributes that were originally
dependent on the entire candidate key
Otherwise, add a foreign key appropriate for the
relationship type
Second Normal Form

Corresponding 2NF tables
Proj#
1
1
1
2
2
Emp#
101
102
104
101
104
Hours
13
16
19
17
25
Emp#
101
102
104
EmpName
News, John
Senior, David
Ramoras, Ann
Proj#
1
2
ProjName
Satellite
WAN
JobType
Elect Eng
Comm Tech
Comm Tech
ChgPerHour
65
60
60
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
Third Normal Form

Third normal form (3NF)
A
database table is in 3NF if it meets the following
requirements:
 It
is in 2NF, and
 All non-prime attributes are dependent only on every
candidate key in the table (no “transitive dependencies”)
 Solution
for converting a table to 3NF
 Convert
it to 2NF (if it isn’t already in 2NF)
 Create a table for each of the offending functional
dependencies and join appropriately to the original table
Third Normal Form

Non-3NF table (previously seen tables in 2NF)
Proj#
1
1
1
2
2
Emp#
101
102
104
101
104
Hours
13
16
19
17
25
Emp#
101
102
104
EmpName
News, John
Senior, David
Ramoras, Ann
Proj#
1
2
ProjName
Satellite
WAN
Non-prime attributes:
EmpName
JobType
ChgPerHour
JobType
Elect Eng
Comm Tech
Comm Tech
ChgPerHour
65
60
60
Violates 3NF
Transitive dependency
Emp# -> JobType -> ChgPerHour
Non-prime ChgPerHour depends on
the non-prime JobType attribute
Third Normal Form

Corresponding 3NF tables
Proj#
1
1
1
2
2
Emp#
101
102
104
101
104
Hours
13
16
19
17
25
Emp#
101
102
104
EmpName
News, John
Senior, David
Ramoras, Ann
Proj#
1
2
ProjName
Satellite
WAN
JobType
Elect Eng
Comm Tech
Comm Tech
JobType
Elect Eng
Comm Tech
ChgPerHour
65
60
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
Boyce Codd Normal Form (BCNF)

Boyce Codd normal form (BCNF)
A
database table is in BCNF if it meets the following
requirements:
 It
is in 3NF, and
 Every determinant in the table is a candidate key
 It’s
uncommon for a table to be in 3NF but not BCNF
 3NF
adds restrictions between non-prime attributes and
candidate keys while BCNF adds restrictions between
candidate key components
 For a table to be in 3NF but not BCNF, it must contain two or
more overlapping composite candidate keys

A component of one of these candidate keys must determine a
component of another candidate key to be in 3NF but not BCNF
Boyce Codd Normal Form (BCNF)

Non-BCNF table (3NF)
TENNIS COURT BOOKING
Court
Time Slot
Rate Type
1
1
SAVER
1
3
SAVER
1
4
STANDARD
2
1
PREMIUM-B
2
4
PREMIUM-B
2
5
PREMIUM-A
SAVER and STANDARD
rate types apply to court
1 while PREMIUM-A and
PREMIUM-B rate types
apply to court 2
Candidate Keys
{Court, Time Slot}
{Rate Type, Time Slot}
Offending Functional Dependency
{Rate Type} -> {Court}
Boyce Codd Normal Form (BCNF)

Solution for converting a table to BCNF
 Convert
it to 3NF (if it isn’t already in 3NF)
 Create a separate table for the offending functional
dependency and join appropriately to the original
table
TENNIS COURT BOOKING
Rate Type
TENNIS COURT RATES
Time Slot
Court
Rate Type
SAVER
1
1
SAVER
SAVER
3
1
STANDARD
STANDARD
4
2
PREMIUM-A
PREMIUM-B
1
PREMIUM-B
4
2
PREMIUM-B
PREMIUM-A
5
Normal Forms

Other normal forms exist as well
 4NF
 5NF
 6NF




These either rarely occur or are more theoretical
1NF through BCNF are adequate for practical use
Table derivations from ER diagrams usually result in
a 3NF design
Dependency diagrams can be used for revisions
and verification
Overview




Introduction
Anomalies
Functional dependence
Normal forms
 1NF
 2NF
 3NF
 BCNF

Denormalization
Denormalization

Normalization results in more tables for the same
data which increases processing complexity
 Complex
joins require more processing
 Increased disk I/O for select, insert, update, and delete
operations as well

If performance is significantly impacted, a
database schema may need to be “denormalized”
 Tables
may be combined into fewer tables or views
may be created to prevent the need for joins and
multiple table inserts, updates, and deletes
Class Exercise

Convert the following table into BCNF
INVOICE
Invoice
Customer
Name
Address
Part
Price
Quantity
1001
43
Jim Jones
12 Main St.
Screw, Nut,
Washer
0.10, 0.05,
0.05
200, 300,
100
1002
55
John Smith
13 Main St.
Screw, Brace
0.10, 5.00
100, 1
1003
43
Jim Jones
12 Main St.
Saw
12.00
10
Class Exercise

Is the table in 1NF?
 Suppose
customer names may be searched and sorted
according to first and last names
 It contains multivalued attributes as well as
inappropriately complex attributes, so it is not in 1NF
 Solution for converting a database table to 1NF
 Replace
multivalued attributes with multiple records
 Replace complex attributes with atomic attributes
 It may make sense to add fields to the table’s primary key
Class Exercise
INVOICE (old)
Invoice
Customer
Name
Address
Part
Price
Quantity
1001
43
Jim Jones
12 Main St.
Screw, Nut,
Washer
0.10, 0.05,
0.05
200, 300,
100
1002
55
John Smith
13 Main St.
Screw, Brace
0.10, 5.00
100, 1
1003
43
Jim Jones
12 Main St.
Saw
12.00
10
INVOICE (new)
Invoice
Customer
FName
LName
Address
Part
Price
Quantity
1001
43
Jim
Jones
12 Main St.
Screw
0.10
200
1001
43
Jim
Jones
12 Main St.
Nut
0.05
300
1001
43
Jim
Jones
12 Main St.
Washer
0.05
100
1002
55
John
Smith
13 Main St.
Screw
0.10
100
1002
55
John
Smith
13 Main St.
Brace
5.00
1
1003
43
Jim
Jones
12 Main St.
Saw
12.00
10
Class Exercise

Is the table in 2NF?


Identify the table’s functional dependencies
There are non-prime attributes that depend on components of
candidate keys, so it is not in 2NF


Invoice
{Invoice} -> {Customer, FName, LName}
{Part} -> {Price}
Customer
FName
LName
INVOICE
Address
Part
Price
Quantity
1001
43
Jim
Jones
12 Main St.
Screw
0.10
200
1001
43
Jim
Jones
12 Main St.
Nut
0.05
300
1001
43
Jim
Jones
12 Main St.
Washer
0.05
100
1002
55
John
Smith
13 Main St.
Motor
52.00
1
1002
55
John
Smith
13 Main St.
Brace
5.00
1
1003
43
Jim
Jones
12 Main St.
Saw
12.00
10
Class Exercise

Solution for converting a table to 2NF
 Convert
it to 1NF (if it’s not already in 1NF)
 Create a table for each of the functional dependencies
that involved only a part of the candidate key
 Those
candidate key components should now be candidate
keys in their new tables
 Create
a linking table containing each of those
candidate key components, as well as any attributes
that were originally dependent on the entire candidate
key
Class Exercise
INVOICE (old)
Invoice
Customer
FName
LName
Address
Part
Price
Quantity
1001
43
Jim
Jones
12 Main St.
Screw
0.10
200
1001
43
Jim
Jones
12 Main St.
Nut
0.05
300
1001
43
Jim
Jones
12 Main St.
Washer
0.05
100
1002
55
John
Smith
13 Main St.
Screw
0.10
100
1002
55
John
Smith
13 Main St.
Brace
5.00
1
1003
43
Jim
Jones
12 Main St.
Saw
12.00
10
INVOICE (new)
Invoice
1001
INVOICE-PART (new)
Customer
FName
43
Jim
LName
Jones
Address
Invoice
Part
12 Main St.
1002
55
John
Smith
13 Main St.
1003
43
Jim
Jones
12 Main St.
Quantit
y
1001
Screw
200
1001
Nut
300
1001
Washer
100
1002
Screw
100
1002
Brace
1
1003
Saw
10
PART (new)
Part
Price
Screw
0.10
Nut
0.05
Washer
0.05
Brace
5.00
Saw
12.00
Class Exercise

Are the tables in 3NF?

There are non-prime attributes (FName, LName, Address) that depend
only on something other than all candidate keys, so it is not in 3NF
INVOICE (new)
Invoice
INVOICE-PART (new)
Customer
FName
1001
43
Jim
Jones
12 Main St.
1002
55
John
Smith
13 Main St.
1003
43

Jim
LName
Jones
Address
12 Main St.
Invoice
Part
Quantit
y
1001
Screw
200
1001
Nut
300
1001
Washer
100
1002
Screw
100
1002
Brace
1
1003
Saw
10
PART (new)
Part
Price
Screw
0.10
Nut
0.05
Washer
0.05
Brace
5.00
Saw
12.00
Solution for converting a table to 3NF


Convert it to 2NF (if it isn’t already in 2NF)
Create a table for each of the offending functional dependencies and join
appropriately to the original table
Class Exercise

3NF Conversion
INVOICE (old)
Invoice
INVOICE-PART (okay)
Customer
FName
1001
43
Jim
Jones
12 Main St.
1002
55
John
Smith
13 Main St.
1003
43
Jim
LName
Jones
CUSTOMER (new)
LName
Address
12 Main St.
Invoice
Part
1001
Screw
200
1001
Nut
300
1001
Washer
100
1002
Screw
100
1002
Brace
1
1003
Saw
10
INVOICE (new)
Address
Quantit
y
Customer
FName
Invoice
Customer
43
Jim
Jones
12 Main St.
1001
43
55
John
Smith
13 Main St.
1002
55
1003
43
PART (okay)
Part
Price
Screw
0.10
Nut
0.05
Washer
0.05
Brace
5.00
Saw
12.00
Class Exercise

Are the tables in BCNF?
 Every
determinant in all tables is a candidate key, so
they are in BCNF
CUSTOMER
Customer
FName
43
Jim
55
John
INVOICE
Invoice
Customer
1001
43
1002
55
1003
43
PART
LName
INVOICE-PART (okay)
Address
Part
Jones
12 Main St.
Screw
0.10
Smith
13 Main St.
Nut
0.05
Washer
0.05
Brace
5.00
Saw
12.00
Price
Invoice
Part
Quantit
y
1001
Screw
200
1001
Nut
300
1001
Washer
100
1002
Screw
100
1002
Brace
1
1003
Saw
10