CST171—Normalization
1
Database Design—Normalization
CST171
2
Normalization
(Page 1)
 Normalization is a process that identifies potential problems, called update anomalies,
in the design of a relational database
 It is a structured method for correcting these problems
3
Normalization
(Page 2)
 The normal forms (the individual steps in the process in which at each point a table
has desirable properties) are:
First normal form (1NF)—no repeating groups exist
Second normal form (2NF)—first normal form and no non-key column is dependent
on a portion of the primary key
Third normal form (3NF)—second normal form and the only determinants are
candidate keys
Fourth normal form (4NF)—third normal form and no multi-valued dependencies
exist
4
Normalization
(Page 3)
 A table in first normal form is better than a table not in first normal form
 A table in second normal form is better than a table in first normal form, and so on
 The goal of normalization is a new collection of tables that is free of update anomalies
5
Functional Dependence
 Attribute B is functionally dependent upon attribute A (or a collection of attributes) if
a value for A determines a single value for B at any time
ProductID  Item, QuantityOnHand, Cost
In this example, the attributes ‘Item’, ‘QuantityOnHand’ and ‘Cost’ are functionally
dependent on attribute ‘ProductID’
6
Primary Keys
(Page 1)
 Attribute A (or a collection of attributes) is the primary key for relation (table) R if:
Property 1—All attributes in R are functionally dependent on A
Property 2—No subcollection of the attributes in A (assuming A is a collection of
attributes) also has Property 1
7
Primary Keys
(Page 2)
 The following example supposes that ‘ProductID’ and ‘Item’ together uniquely identify
each record
Product(ProductID, Item, QuantityOnHand, Cost)
 However a subcollection of the keys in this example can determine the nonkey
attributes
 Minimal collection of attributes is the primary key
Product(ProductID, Item, QuantityOnHand, Cost)
8
Primary Keys
(Page 3)
 Primary key alternate definition—minimal collection of attributes on which all nonkey
attributes are functionally dependent
Chosen as the main direct-access vehicle to individual rows (tuples)
 Candidate keys (also known as an alternate keys) are column(s) on which all columns
in the table are functionally dependent
Also could have been chosen as the primary key, but they are not
9
User Views
Page 1
Product(ProductID,
Chosen
as the main
Item,
direct-access
QuantityOnHand,
vehicle toCost)
individual rows (tuples)
in the table
attributes
are
are
functionally
functionally
dependent
dependent

Candidate
keys (also known as (Page
an alternate
keys) are column(s) on which all columns
CST171—Normalization
8
Primary
Keys
3)
Chosen
as have
the main
vehicle
to individual
rowsare
(tuples)
Also
could
beendirect-access
chosen as the
primary
key, but they
not
9
9
9
10
9
10
11
10
11
12
11
12
12
10
11
12
13
13
14
13
14
14
13
14
15
15
16
15
16
16
15
16
17
17
17
17
18
18
18
18
19
in the table are functionally dependent

Primary
Candidate
keykeys
alternate
(also known
definition—minimal
as an alternate
collection
keys) are
of column(s)
attributes on which all nonkey
columns
User
Views
Also
could have been chosen as the primary key, but they are not
in
the table
are
functionally
dependent
attributes
are
functionally
dependent

An end-users
view of the database
User
Views
Chosen
Also
could
as have
the main
beendirect-access
chosen as the
vehicle
primary
to individual
key, but they
rowsare
(tuples)
not
 Consists of the reports and screens that provide an interface and information to

Candidate
An
end-users
keys
view
(also
of
known
the
database
as
an
alternate
keys)
are
column(s)
on which all columns
User
Viewswho use the database system
personnel
in
the
table
are
functionally
dependent
 Consists of the reports and screens that provide an interface and information to
 Database
An end-users
professionals
view of the
work
database
backwards from user views to create the tables
personnel
Also could
who
have
usebeen
the database
chosen assystem
the primary key, but they are not

Consists
of
the
reports
and
screens
that provide an interface and information to
The
“Supplier
Cost” Report

Database
professionals
work
backwards
User
Viewswho use the database system from user views to create the tables
personnel
The
Cost”
 Database
professionals
work
backwards from user views to create the tables
An “Supplier
end-users
view
of Report
the
database

Consists
of
the
reports
and
screens
that provide an interface and information to
The “Supplier Cost”
Unnormalized
Relations
Report
personnel who use the database system

An “Supplier
“unnormalized
relation”
contains one or more repeating groups (multiple entries
The
Unnormalized
Cost”
Relations
Report
 Database
professionals
work backwards from user views to create the tables
for a single record)

An “Supplier
“unnormalized
relation”
contains one or more repeating groups (multiple entries
Unnormalized
Relations
The
Report
For example,Cost”
assuming
that there were more than one supplier for each product in
for a single record)
‘Product’ table:

Anthe
“unnormalized
relation”
contains one or more repeating groups (multiple entries
The
“Supplier
Report
For
example,Cost”
assuming
that there were more than one supplier for each product in
forSupplierCost(ProductID,
a single record)
Item, QuantityOnHand, Cost, ColorCode, Color, SupplierID,
the ‘Product’ table:
Unnormalized
Company)
For
example,Relations
assuming that there were more than one supplier for each product in
SupplierCost(ProductID, Item, QuantityOnHand, Cost, ColorCode, Color, SupplierID,
the
‘Product’
table:
The
‘Cost’, ‘SupplierID’
and
‘Company’
contain multiple
entries entries
 An
“unnormalized
relation”
contains
one attributes
or more repeating
groups (multiple
Company)
forSupplierCost(ProductID,
aRepeating
single record)
Item,
QuantityOnHand,
Cost,
ColorCode,
Color, SupplierID,
Group and ‘Company’ attributes contain multiple entries
The ‘Cost’, ‘SupplierID’
Company)
For
example, assuming that there were more than one supplier for each product in
Repeating
Group and ‘Company’ attributes contain multiple entries
First
Normal
The
the
‘Product’
‘Cost’, Form
‘SupplierID’
table:

A
relation
SupplierCost(ProductID,
(table)
is in first normal
Item, QuantityOnHand,
form (1NF) if it does
Cost,not
ColorCode,
contain any
Color,
repeating
SupplierID,
Group
First Repeating
Normal Form
groups
Company)

A relation
(table) is in first normal form (1NF) if it does not contain any repeating
First
Normal
The
ProductBySupplier(ProductID,
‘Cost’, Form
‘SupplierID’ and ‘Company’
Item, QuantityOnHand,
attributes contain
Cost,
multiple
ColorCode,
entriesColor,
groups
SupplierID,
Company)
 A relation
(table)
is
in
first
normal
form
(1NF)
if
it
does
not
contain
any
repeating
Repeating Group
ProductBySupplier(ProductID,
Item, QuantityOnHand, Cost, ColorCode, Color,
groups
Remove repeating group(s) by altering the primary key so that single records with
SupplierID, Company)
First
multiple
Normal
entries
Formbecome multiple
(one record for
each
multiple Color,
entry)
ProductBySupplier(ProductID,
Item,records
QuantityOnHand,
Cost,
ColorCode,
Remove repeating group(s) by altering the primary key so that single records with
SupplierID,
Company)
 The
‘ProductID’
and
‘SupplierID’
together
uniquely
identify
each
record
A relation
(table)
is
in
first
normal
form
(1NF)
if
it
does
not
contain
any
repeating
multiple entries become multiple records (one record for each multiple entry)
Remove repeating
group(s)
altering the primary key so that single records with
groups
The
Table
1NF bytogether

TheProduct
‘ProductID’
andin
‘SupplierID’
uniquely identify each record
multiple
entries
become
multiple
(one record for
each
multiple Color,
entry)
ProductBySupplier(ProductID, Item,records
QuantityOnHand,
Cost,
ColorCode,
The
Problems
Product
with
Table
1NF
in
1NF
 The
SupplierID,
‘ProductID’
Company)
and ‘SupplierID’ together uniquely identify each record
Remove
repeating
group(s)
by altering
the primary
single records with

Update—changes
tointhe
‘SupplierID’
requires
a changekey
to so
thethat
‘Company’
The Product
Problems
with
Table
1NF
1NF
multiple entries become
multiple
records the
(oneentry
record
for inconsistent
each multiple
entry)
 Inconsistency—there
is nothing
to prohibit
of an
‘SupplierID’

Update—changes
to the ‘SupplierID’ requires a change to the ‘Company’
Problems
with 1NF
 and
The ‘Company’
‘ProductID’
and ‘SupplierID’ together uniquely identify each record
 Inconsistency—there is nothing to prohibit the entry of an inconsistent ‘SupplierID’

Update—changes
Additions—what
happens
tointhe
‘SupplierID’
when thererequires
is a newa ‘Supplier’
change tobut
theno‘Company’
product ‘Item’ for it?
The
Table
1NF
andProduct
‘Company’
Inconsistency—therea is
nothing
to prohibit
the entry all
of references
an inconsistent
‘SupplierID’
 Deletions—deleting
product
‘Item’
could eliminate
to a ‘Supplier’

Additions—what
happens when there is a new ‘Supplier’ but no product ‘Item’ for it?
Problems
with 1NF
and ‘Company’
Functional
Dependencies
in ‘Item’
1NF could eliminate all references to a ‘Supplier’
 Deletions—deleting
a product
 Additions—what
when thererequires
is a newa ‘Supplier’
product ‘Item’ for it?
Update—changeshappens
to the ‘SupplierID’
change tobut
theno‘Company’

First normalDependencies
form:
Functional
in ‘Item’
1NF
 Deletions—deleting
Inconsistency—therea is
product
nothing
to prohibit
could eliminate
the entry all
of references
an inconsistent
to a ‘Supplier’
‘SupplierID’
ProductBySupplier(ProductID,
Item, QuantityOnHand, Cost, ColorCode, Color,
and
‘Company’

First normalDependencies
form:
Functional
SupplierID, Company) in 1NF
 Additions—what
happens whenItem,
thereQuantityOnHand,
is a new ‘Supplier’Cost,
but no
product ‘Item’
for it?
ProductBySupplier(ProductID,
ColorCode,
Color,
 Contains
First normal
the form:
following functional dependencies:
 Deletions—deleting
SupplierID, Company)
a product ‘Item’ could eliminate all references to a ‘Supplier’
ProductBySupplier(ProductID,
Item, QuantityOnHand,
ProductID
 Item, QuantityOnHand,
ColorCode, ColorCost, ColorCode, Color,

Contains the
following functional
dependencies:
Functional
Dependencies
SupplierID,
SupplierID
Company)
Company in 1NF
ProductID  Item, QuantityOnHand, ColorCode, Color
 Contains
theSupplierID
following functional
First
normal
form:
ProductID,
 Cost dependencies:
SupplierID  Company
ProductBySupplier(ProductID,
ProductID
 Item, QuantityOnHand,
Item, QuantityOnHand,
ColorCode, ColorCost, ColorCode, Color,
Determinants
ProductID,
SupplierID
 Cost (Page 1)
SupplierID,
Company)
SupplierID  Company

determinant
is any attribute
(ordependencies:
collection
of attributes) that determines another
A
Contains
theSupplierID
following
functional
Determinants
1)
ProductID,
 Cost (Page
attribute
 Item,
ColorCode,
Color that determines another

AProductID
determinant
is anyQuantityOnHand,
attribute (or
collection
attributes)
Determinants
(Page
1) keyofattributes
 In 1NF the determinants are the
primary
inall combinations of the
SupplierID  Company
attribute
key attributes:
 primary
A determinant
is any attribute (or collection of attributes) that determines another
 In
ProductID,
1NF the determinants
SupplierID are
Cost
the primary key attributes inall combinations of the
attribute
‘ProductID’
primary key attributes:
Determinants
(Page
1) key attributes inall combinations of the

In
1NF the determinants are the
primary
‘SupplierID’
‘ProductID’
primary
key
attributes:
 AThe
determinant
concatenation
is any attribute
of ‘ProductID’
(or collection
and ‘SupplierID’
of attributes) that determines another
‘SupplierID’
‘ProductID’
attribute
Determinants
(Page
2)‘SupplierID’
The concatenation of ‘ProductID’
and
 In
‘SupplierID’
1NF the determinants are the primary key attributes inall combinations of the
 Determinants for the ‘ProductBySupplier’ relation are:
Page 2
attribute
‘ProductID’
key attributes:
 primary
A determinant
is any attribute (or collection of attributes) that determines another
 In
1NF the determinants are the primary key attributes inall combinations of the
‘SupplierID’
CST171—Normalization
attribute
‘ProductID’
19
19
19
19
20
20
21
20
21
20
21
21
22
22
23
22
23
22
23
23
24
24
24
24
25
25
25
25
26
26
27
26
27
26
27
27
28
primary
key attributes:of ‘ProductID’ and ‘SupplierID’
The concatenation
 In
1NF the determinants are the primary key attributes inall combinations of the
‘SupplierID’
‘ProductID’
primary
key attributes:of ‘ProductID’
Determinants
(Page
2)‘SupplierID’
The concatenation
and
‘SupplierID’
‘ProductID’ for the ‘ProductBySupplier’ relation are:

Determinants
Determinants
(Page
2)‘SupplierID’
The concatenation of ‘ProductID’
and
‘SupplierID’
ProductID  Item, QuantityOnHand, ColorCode, Color

Determinants
for
the
‘ProductBySupplier’
relation are:
Determinants
(Page
2)‘SupplierID’
The concatenation
of ‘ProductID’
and
SupplierID
 Company
ProductID  Item, QuantityOnHand, ColorCode, Color

Determinants
for the ‘ProductBySupplier’
ProductID, SupplierID
 Cost (Page 2) relation are:
Determinants
SupplierID  Company
ProductID

Item,
QuantityOnHand,
ColorCode,
Color

common error
identifying
determinants
in 1NF
is to include nonkey attributes
A
Determinants
forin
the
‘ProductBySupplier’
relation
are:
ProductID, SupplierID
 Cost
SupplierID

Company
Although
it
may
seem
obvious
that
attribute
‘ColorCode’
is a determinant for ‘Color’
 Item,
QuantityOnHand,
ColorCode,
 AProductID
common error
in identifying
determinants
in 1NFColor
is to include nonkey attributes
ProductID,
SupplierID
 Cost
it should not
be identified
as such in 1NF
SupplierID
may
Company
Although it
seem obvious that attribute ‘ColorCode’ is a determinant for ‘Color’

A common error
in identifying determinants in 1NF is to include nonkey attributes
Dependency
Diagram
ProductID,
SupplierID
 Cost
it should not
be identified
as such in 1NF
Although it may seem obvious that attribute ‘ColorCode’ is a determinant for ‘Color’

A
common
error
in
identifying
determinants in 1NF is to include nonkey attributes
Dependency
Second
Normal
Diagram
Form
it should
not
be
identified as such in 1NF
Although it may seem obvious that attribute ‘ColorCode’ is a determinant for ‘Color’

A relation
is in
second
normal form (2NF) if it already is in first normal form and no
Dependency
Second
Normal
Diagram
Form
it should
not
be
identified as such in 1NF
nonkey attribute is dependent on only a portion of the key

A relation
is in
second
normal form (2NF) if it already is in first normal form and no
Dependency
Second
Normal
Diagram
Form
I.e. there
are
no
partial dependencies
nonkey attribute is dependent on only a portion of the key
A relation
is intables
second
normal
form
(2NF) if it already is in first normal form and no

The
following
are
subsets
of 1NF:
Second
Normal
Form
I.e. there
are no
partial dependencies
nonkey
attribute is dependent
on only a portion
of the key
Product(ProductID,
Item, QuantityOnHand,
ColorCode,
Color)
A relation
is intables
second
normal
form
(2NF) if it already is in first normal form and no
 The
following
are
subsets
of 1NF:
I.e.
there
are
no
partial
dependencies
Supplier(SupplierID,
Company)on only a portion of the key
nonkey
attribute is dependent
Product(ProductID,
Item, QuantityOnHand,
ColorCode, Color)
 The
following tables are subsets
of 1NF:
SupplierCost(ProductID,
SupplierID,
Cost)
I.e.
there
are
no
partial
dependencies
Supplier(SupplierID, Company)
Product(ProductID, Item, QuantityOnHand, ColorCode, Color)
 The
The
Product
followingTable
tablesinare
2NF
subsets
of 1NF:
SupplierCost(ProductID,
SupplierID,
Cost)
Supplier(SupplierID, Company)
Product(ProductID, Item, QuantityOnHand, ColorCode, Color)
The
Product
Table
Problems
with
2NFin 2NF
SupplierCost(ProductID,
SupplierID, Cost)
Supplier(SupplierID, Company)

Update—a
change
to
the
‘ColorCode’ requires a change to the ‘Color’
The
Product
Table
Problems
with
2NFin 2NF
SupplierCost(ProductID,
SupplierID, Cost)
 Inconsistency—there is nothing that will prohibit inconsistent ‘ColorCode’ and ‘Color’

Update—a
change
‘ColorCode’ requires a change to the ‘Color’
The
Product
Table
inthe
2NF
Problems
with
2NFto
values
 Inconsistency—there is nothing that will prohibit inconsistent ‘ColorCode’ and ‘Color’
Update—awith
change
to the ‘ColorCode’
change to the

Additions—what
happens
when there requires
is a newa‘ColorCode’
but ‘Color’
no product ‘Item’ for
Problems
2NF
values
it?
 Inconsistency—there is nothing that will prohibit inconsistent ‘ColorCode’ and ‘Color’
Update—a change
to the ‘ColorCode’
change to the
 Additions—what
happens
when there requires
is a newa‘ColorCode’
but ‘Color’
no product ‘Item’ for
values
 Deletions—deleting
a product ‘Item’ could eliminate all references to a ‘Color’
it?
 Inconsistency—there is nothing that will prohibit inconsistent ‘ColorCode’ and ‘Color’

Additions—what
when there(Page
is a new
but no product ‘Item’ for
Nonkey
Attributehappens
Determinants
1) ‘ColorCode’
 values
Deletions—deleting
a product ‘Item’ could
eliminate
all references to a ‘Color’
it?
Additions—what
happens
there(Page
is a new
‘ColorCode’
butnonkey
no product
‘Item’ for

Once
the
tables are
in 2NF,when
examine
each
of1)
them
to look for
determinants
Nonkey
Attribute
Determinants

Deletions—deleting
a product ‘Item’ could
eliminate all references to a ‘Color’
it?
(additional
attributes upon which other fields may be functionally dependent)

Once the
tables areDeterminants
in 2NF, examine (Page
each of1)
them to look for nonkey determinants
Nonkey
Attribute
 Deletions—deleting
a as
product
‘Item’ could
eliminate
all earlier
references
to a they
‘Color’
I.e. attributes
such
‘ColorCode’
that were
ignored
because
were not
(additional attributes upon which other fields may be functionally dependent)
elements
of the
primary
key
in 1NFeach of them to look for nonkey determinants

Once
the
tables
are
in
2NF,
examine
Nonkey
Attribute
Determinants
(Page
1) ignored earlier because they were not
I.e. attributes
such
as ‘ColorCode’ that
were
(additional
attributes
upon which other
fields may be functionally dependent)
Nonkey
Attribute
Determinants
elements
of the
in 1NF(Page

Once
the
tables
areprimary
in 2NF,key
examine
each of2)
them to look for nonkey determinants
I.e. attributes such as ‘ColorCode’ that were ignored earlier because they were not
(additional
attributes
upon
which
other
fields
may
be functionally
dependent)

Consider
the
following
table
which
is
in
second
normal
form (2NF):
Nonkey
Attribute
Determinants
elements
of the primary
key in 1NF(Page 2)
I.e. attributes suchItem,
as ‘ColorCode’
that were
ignored earlier
Product(ProductID,
QuantityOnHand,
ColorCode,
Color)because they were not

ConsiderAttribute
the following
table which is (Page
in second
normal form (2NF):
Nonkey
Determinants
2) exist:
elements
of nonkey
the primary
key independencies
1NF
 The
following
functional
Product(ProductID, Item, QuantityOnHand, ColorCode, Color)

Consider
thefollowing
table which is (Page
in second
normal form (2NF):
ColorCode
Color
Nonkey
Attribute
Determinants
2) exist:

The following
nonkey
functional dependencies
Product(ProductID,
Item,that
QuantityOnHand,
ColorCode,
Color)
It
is
important
to
note
although
‘ColorCode’
is a determinant,
it also is
 Consider
thefollowing
ColorCode
Color table which is in second normal form (2NF):
 The
following nonkey
functional
dependencies exist:
functionally
dependent
on ‘ProductID’
Product(ProductID,
Item,that
QuantityOnHand,
ColorCode,
Color)
It
is important to note
although ‘ColorCode’
is a determinant,
it also is
ColorCode  Item,
Color QuantityOnHand, ColorCode
ProductID
 The
following nonkey
functional
dependencies exist:
functionally
dependent
on ‘ProductID’
It is important
to note
that although ‘ColorCode’ is a determinant, it also is
Another
Dependency
Diagram
ColorCode
Color QuantityOnHand,
ProductID
 Item,
ColorCode
functionally dependent on ‘ProductID’
It isNormal
important
to note
that although
‘ColorCode’ is a determinant, it also is
Another
Third
Dependency
Diagram
(Page 1)
ProductID
 Form
Item, QuantityOnHand,
ColorCode
functionally dependent on ‘ProductID’

A relation
is inForm
third normal
form
(3NF)1)
if it is in second normal form and if the only
Another
Third
Normal
Dependency
Diagram
(Page
ProductID
 Item, QuantityOnHand,
ColorCode
determinants are candidate keys

A relation
is inForm
third normal
form
(3NF)1)
if it is in second normal form and if the only
Another
Third
Normal
Dependency
Diagram
(Page
 The correction
procedure
to place
tables in 3NF:
determinants are candidate keys

AIn
relation
any table
is inForm
where
third normal
there is
form
a(Page
determinant
(3NF)1)
if it isthat
in second
is not anormal
candidate
formkey,
andremove
if the only
from
Third
Normal

The correction
procedure to place
tables in 3NF:
determinants
are
candidate
the table the
columns
thatkeys
depend on this determinant
 AIn
relation
any table
is in where
third normal
there is
form
a determinant
(3NF) if it isthat
in second
is not anormal
candidate
formkey,
andremove
if the only
from
 The
Create
correction
a newprocedure
table containing
to placealltables
columns
in 3NF:
from the original table that depend on
determinants
are
candidate
the table the
columns
thatkeys
depend on this determinant
thisany
determinant
In
table where there is a determinant that is not a candidate key, remove from
 The
Create
correction
a newprocedure
table containing
to placealltables
columns
in 3NF:
from the original table that depend on
the table
columns that
depend key
on this
determinant
Make
the the
determinant
the primary
of the
new table
thisany
determinant
In
table where there is a determinant that is not a candidate key, remove from
Create
a
new
table
containing
all
columns
from
the original table that depend on
Third
Form
(Pagekey
2)this
theNormal
table
columns that
depend
on
determinant
Make
the the
determinant
the primary
of the
new table
Page 3
27
Third Normal Form
(Page 1)
CST171—Normalization
 A relation is in third normal form (3NF) if it is in second normal form and if the only
determinants are candidate keys
 The correction procedure to place tables in 3NF:
In any table where there is a determinant that is not a candidate key, remove from
the table the columns that depend on this determinant
Create a new table containing all columns from the original table that depend on
this determinant
Make the determinant the primary key of the new table
28
Third Normal Form
(Page 2)
 The following tables are subsets of 2NF:
Product(ProductID, Item, QuantityOnHand, ColorCode)
Color(ColorCode, Color)
Supplier(SupplierID, Company)
SupplierCost(ProductID, SupplierID, Cost)
29
Incorrect Decompositions
 Decomposition must be done using method described for 3NF
 Incorrect decompositions can lead to tables with the same problems as original table
30
Multivalued Dependencies and Fourth Normal Form
 3NF tables may still contain problems
Updates
Additions
Deletions
 Multivalued dependence of column B on column A
“B is multidependent on A”
“A multidetermines B”
Each value for A is associated with a specific collection of values for B, and this
collection is independent of any values for C
A→→B
31
Multivalued Dependencies and Fourth Normal Form (continued)
 Table (relation) in fourth normal form (4NF)
It is in third normal form
No multi-valued dependencies
 Converting table to fourth normal form
Split third normal form table into separate tables, each containing the column that
multi-determines the others
32
Avoiding the Problem with Multivalued Dependencies
 Slightly more sophisticated method for converting unnormalized table to first normal
form
Place each repeating group in separate table
Each table will contain all columns of a repeating group, and primary key of the
original table
Primary key to each new table will be the concatenation of the primary keys of the
original table and the repeating group
33
Application to Database Design
 Carefully convert tables to third normal form
 Review assumptions and dependencies periodically to see if changes to design are
needed
 Splitting relations to achieve third normal form tables creates need for an interrelation
constraint
Interrelation constraint: condition that involves two or more relations
34
The Invoice Report
Page 4
original table and the repeating group
Invoice(InvoiceNumber, CustomerNumber, Last, First, Street, City, State, ZipCode,
CST171—Normalization
33
Application to Database Design
45
46
34
35
36
37
47
48
38
49
50
39
51
52
53
54
55
40
56
57
41
58
59
InvoiceDate)
 Carefully convert tables to third normal form
The
Invoice
Table inand
3NF
 Review
assumptions
dependencies periodically to see if changes to design are
Invoice(InvoiceNumber,
CustomerNumber, InvoiceDate)
needed
Customer(CustomerNumber,
First,
Street,
City,
State,
ZipCode)
 Splitting relations to achieveLast
third
normal
form
tables
creates
need for an interrelation
Part(PartNumber,
PartDescription)
constraint
InvoiceDetail(InvoiceNumber,
Interrelation constraint: condition
PartNumber,
that involves
QuotedPrice,
two or
NumberShipped)
more relations
StepsThe
to 3NF
Invoice Report
1.
UnnormalizedInvoice
table Table
Unnormalized
2. Repeating group(s)
Invoice(InvoiceNumber, CustomerNumber, Last, First, Street, City, State, ZipCode,
3.InvoiceDate,
1NF (First Normal
Form) PartDescription, QuotedPrice, NumberShipped)
PartNumber,
4. Determinants and Functional dependencies
Repeating
Group
5. 2NF (Second
Normal Form)
PartNumber,
PartDescription,
NumberShipped
6. Non-Key Determinants
andQuotedPrice,
Functional dependencies
7.
3NF
(Third
NormalForm)
Form)
1NF
(First
Normal
InvoiceDetail(InvoiceNumber,
CustomerNumber, Last, First, Street, City, State, ZipCode,
The Class Roster Report
InvoiceDate, PartNumber, PartDescription, QuotedPrice, NumberShipped)
The Unnormalized Roster Table
Determinants
and Functional
Dependencies
Roster(Crn, CourseNumber,
CourseName,
Room, Days, Time, FacultyName, FacultyID,
InvoiceNumber
→
StudentID, StudentLast,
StudentFirst)
The Roster Table in 3NF
PartNumber →
CourseOfferings(Crn, CourseNumber, Room, Days, Time, FacultyID)
Student(StudentID,
StudentLast,
InvoiceNumber, PartNumber
→ StudentFirst)
Roster(Section, StudentID)
Faculty(Faculty ID, FacultyName)
Course(CourseNumber,
CourseName)
InvoiceDetail(InvoiceNumber,
CustomerNumber, Last, First, Street, City, State, ZipCode,
InvoiceDate,
PartNumber,
PartDescription, QuotedPrice, NumberShipped)
The Book
Report
Determinants
and Functional
The Unnormalized
Book TableDependencies
InvoiceNumber →BookTitle,
CustomerNumber,
Last, First,
Street, City,Price,
State,AuthorNumber,
ZipCode,
Book(BookCode,
PublisherCode,
PublisherName,
InvoiceDate
AuthorName)
PartNumber →
The Book Author Table in 1NF
The
Book Table
in 1NF →
InvoiceNumber,
PartNumber
Book(BookCode, BookTitle, PublisherCode, PublisherName, Price, AuthorNumber,
AuthorName)
InvoiceDetail(InvoiceNumber,
CustomerNumber,
Last, First, Street, City, State, ZipCode,
The Book Table in 2NF
(Page 1)
InvoiceDate, PartNumber, PartDescription, QuotedPrice, NumberShipped)
The Book Table in 2NF
(Page 2)
Determinants and Functional Dependencies
The
Book Table
2NF
InvoiceNumber
→in
CustomerNumber,
Last, First, Street, City, State, ZipCode,
InvoiceDate
Book(BookCode, Book Title, PublisherCode, PublisherName, Price)
PartNumber → PartDescription
Author(AuthorNumber,
AuthorName)
Book-Author(BookCode, AuthorNumber)
InvoiceNumber, PartNumber →
The Book Table in 3NF
Book(BookCode, BookTitle, PublisherCode, Price)
Publisher(PublisherCode, PublisherName)
InvoiceDetail(InvoiceNumber, CustomerNumber, Last, First, Street, City, State, ZipCode,
Author(AuthorNumber, AuthorName)
InvoiceDate, PartNumber, PartDescription, QuotedPrice, NumberShipped)
Book-Author(BookCode, AuthorNumber)
Determinants and Functional Dependencies
Review Question No. 8
InvoiceNumber → CustomerNumber, Last, First, Street, City, State, ZipCode,
InvoiceDate
The
Unnormalized Student Table and in 2NF
PartNumber → PartDescription
Student(StudentID,
StudentName, Major, AdvisorID, AdvisorName, AdvisorOffice,
AdvisorPhone, Credits, ClassStanding)
Page 5