Third Normal Form Problems can still exist with tables that are in second normal form.

Consider the following Customer table:

Customer ( CustomerNum, CustomerName, Balance, CreditLimit, RepNum, LastName, FirstName)

The functional dependencies in this tale are as follows: CustomerNum > CustomerNAme, Balance, CreditLimit, RepNum, LastName, FirstName RepNum > LastName, FirstName

CustomerNum determines all the other columns. In addition, RepNum

determines LastName and FirstNAme.

When the primary key of a table is a single column, the table is automatically in second

normal form. Thus, the

Customer table is in second normal form.

C C Num Name
148 282 356 408 524 608
Als
Appliance

Credit Rep Last First Limit Num Name Name

$ 6550
$431.20 $5785

$7500
$10000

20 35 65 35 20 65

Kaiser Hull Perez Hull Kaiser Perez

Valerie Richard Juan Richard Valerie Juan

and Sport
Brookings

Direct
Fergusons

$7500

The Everything Shop Klines Johnsons

Department

$5285. $5000.0 25 0 $12762 $15000 $2106 $10000

Store

687

Appliance

Lees Sport and

$2851

$5000

35

Hull

Richar d

725

Deerfields

Seasons

Four

$248

$7500

35

Hull

Richar d

842

All Season

$8221 $7500.0 20 Kaiser Valeri 0 e

This redundancy creates the same set of problems that you examined in the first normal form Orders table. In addition to the problem of wasted space, you have similar update anomalies as follows:

1.

Updates A change to the name of a sales rep requires not one

change to the table, but several,

making the update process cumbersome.

2. Inconsistent data. There is nothing about the design that would prohibit a sales rep from having two different names in the database. In fact, if the same sales rep represents 20 customers, he or she could have 20 different names in the database.

3. Additions In order to add sales rep 87 (Mary Daniels) to the database, she must already represent at least one customer. IF she has not yet been assigned any customers, you must add her record and create a fictitious customer for her to represent. Again, this is not a desirable solution to the problem.

4. Deletions If you deleted all the customers of sales rep 35 from

the database, you would lose all information concerning

sales rep 35.

These update anomalies are due to the fact that RepNum determines LastName and FirstName, but RepNum is not the primary key. As a result, the same RepNum and consequently the same LastName and FirstName can appear on many different rows.

Definition: Any column that determines another column is called a determinant. Definition: A table is in third normal form (3NF) when it is in second normal form and the only determinants it contains are candidate keys.

Customer Table It is not in third normal form.

The following method corrects the deficiency in the Customer table and in all tables having similar deficiencies.

For each determinant that is not a candidate key, remove from the table the columns that depend on this determinant.

Create a New table containing al the columns from the original

table that depend on this determinant.

Make the determinant the primary key of this new table.

Customer Num 148 282 356 408 462 524 608 687 725

CustomerName
Als Appliance and Sport Brookings Direct Fergusons The Everything Shop Bargains Galore Klines Johnsons Department Store Lees Sport and Appliance Deerfields Four Seasons

Balanc CreditLim RepNum it e

$6550.00 $431.40 $5785.00 $5825.25 $3412.00 $12762.00 $2106.00 $2851.00 $248.00 $7500.00 $10000.00 $7500.00 $5000.00 $10000.00 $15000.00 $10000.00 $5000.00 $7500.00 20 35 65 35 65 20 65 35 35

RepNum LastName
20 35 65 Kaiser Hull Perez

FirstName
Valerie Richard Juan

Conversion to third normal form

Incorrect Decompositions It is important to note that the decomposition of a table into two or more third normal form tables must be accomplished by the method indicated in the previous section, even though there are other possibilities that at first glance might seem to be legitimate.

Customer ( CustomerNum, CustomerName, Balance, CreditLimit, RepNum, LastName, FirstName) is replaced by Customer ( CustomerNum, CustomerName, Balance, CreditLimit, RepNum) Rep (CustomerNum, LastName, FirstName)

Customer Num 148 282 356 408 462 524 608 687 725

CustomerName
Als Appliance and Sport Brookings Direct Fergusons The Everything Shop Bargains Galore Klines Johnsons Department Store Lees Sport and Appliance Deerfields Four Seasons

Balanc CreditLim RepNum it e

$6550.00 $431.40 $5785.00 $5825.25 $3412.00 $12762.00 $2106.00 $2851.00 $248.00 $7500.00 $10000.00 $7500.00 $5000.00 $10000.00 $15000.00 $10000.00 $5000.00 $7500.00 20 35 65 35 65 20 65 35 35

CustomerNum 148 282 356 408

LastName Kaiser Hull Perez Hull

FirstName Valerie Richard Juan Richard

462 524
608 687 725 842

Perez Kaiser
Perez Hull Hull Kaiser

Juan Valerie
Juan Richard Richard Valerie

Consider, for example, the redundancy in the storage of sales reps names, the problem encountered in changing the name

of a sales rep and the difficulty of

adding a new sales rep who

represents no customers.

In addition, because the rep number and names are in different tables, you have actually split a functional dependence across two different tables. Thus, this seemingly valid decomposition is definitely not a desirable way to create third normal form tables.

There is another decomposition that you might choose. Customer (CustomerNum,

CustomerName, Balance,
CreditLimit, LastName, FirstName)

CustomerN um

CustomerName
Als Appliance and Sport Brookings Direct Fergusons

Balan CreditLim it ce
$6550.00 $431.40 $5785.00 $7500.00 $10000.00 $7500.00

LN
Kaiser Hull Perez

FN
Valeri e Richar d Juan

148 282 356

408
462 524 608 687 725

The Everything Shop

Bargains Galore Klines Johnsons Department Store Lees Sport and Appliance Deerfields Four Seasons

$5825.25
$3412.00 $12762.00 $2106.00 $2851.00 $248.00

$5000.00
$10000.00 $15000.00 $10000.00 $5000.00 $7500.00

Hull
Perez Kaiser Perez Hull Hull

Richar d
Juan Valeri e Juan Richar d Richar d

RepNum LastName
20 35 65 Kaiser Hull Perez

FirstName
Valerie Richard Juan

Second incorrect decomposition of the Customer Table