Definition

• This is the process which allows you to remove out

redundant data within your database.
• This involves restructuring the tables to
successively meeting higher forms of
Normalization.
• A properly normalized database should have the
following characteristics
• Scalar values in each fields
• Absence of redundancy.
• Minimal use of null values.
• Minimal loss of information.
A Table in the Report Format
Redundant Information in Tuples and Update
Anomalies
• Information is stored redundantly
• Wastes storage
• Causes problems with update anomalies
• Insertion anomalies
• Deletion anomalies
• Modification anomalies
 Informal Design Guidelines for Relational
Databases
• What is relational database design?
• The grouping of attributes to form "good" relation schemas
• Two levels of relation schemas
• The logical "user view" level
• The storage "base relation" level
• Design is concerned mainly with base relations
• What are the criteria for "good" base relations?
 Levels of Normalization
• Levels of normalization based on the amount of
redundancy in the database.
• Various levels of normalization are:
• First Normal Form (1NF)
• Second Normal Form (2NF)

Number of Tables
Redundancy
• Third Normal Form (3NF)
• Boyce-Codd Normal Form (BCNF)
• Fourth Normal Form (4NF)
• Fifth Normal Form (5NF)
• Domain Key Normal Form (DKNF)

Most databases should be 3NF or BCNF in order to avoid

the database anomalies.
Levels of Normalization
1NF
2NF
3NF
4NF
5NF

Each higher level is a subset of the lower level

 First Normal Form (1NF)
A table is considered to be in 1NF if all the fields contain
only scalar values (as opposed to list of values).
Example (Not 1NF)

ISBN Title AuName AuPhone PubName PubPhone Price

0-321-32132-1 Balloon Sleepy, 321-321-1111, Small House 714-000-0000 $34.00

Snoopy, 232-234-1234,
Grumpy 665-235-6532

0-55-123456-9 Main Street Jones, 123-333-3333, Small House 714-000-0000 $22.95

Smith 654-223-3455
0-123-45678-0 Ulysses Joyce 666-666-6666 Alpha Press 999-999-9999 $34.00

1-22-233700-0 Visual Roman 444-444-4444 Big House 123-456-7890 $25.00

Basic

Author and AuPhone columns are not scalar

 1NF - Decomposition
1. Place all items that appear in the repeating group in a
new table
2. Designate a primary key for each new table produced.
3. Duplicate in the new table the primary key of the table
from which the repeating group was extracted or vice
versa.
Example (1NF) ISBN AuName AuPhone

0-321-32132-1 Sleepy 321-321-1111

ISBN Title PubName PubPhone Price 0-321-32132-1 Snoopy 232-234-1234

0-321-32132-1 Balloon Small House 714-000-0000 $34.00 0-321-32132-1 Grumpy 665-235-6532

0-55-123456-9 Main Street Small House 714-000-0000 $22.95 0-55-123456-9 Jones 123-333-3333

0-123-45678-0 Ulysses Alpha Press 999-999-9999 $34.00 0-55-123456-9 Smith 654-223-3455

1-22-233700-0 Visual Big House 123-456-7890 $25.00 0-123-45678-0 Joyce 666-666-6666

Basic
1-22-233700-0 Roman 444-444-4444
Table in 1NF
 Functional Dependencies
1. If one set of attributes in a table determines another
set of attributes in the table, then the second set of
attributes is said to be functionally dependent on the
first set of attributes.

Example 1

ISBN Title Price Table Scheme: {ISBN, Title, Price}

0-321-32132-1 Balloon $34.00 Functional Dependencies: {ISBN}  {Title}
0-55-123456-9 Main Street $22.95 {ISBN}  {Price}
0-123-45678-0 Ulysses $34.00

1-22-233700-0 Visual $25.00

Basic
 Functional Dependencies
Example 2
PubID PubName PubPhone Table Scheme: {PubID, PubName, PubPhone}
1 Big House 999-999-9999 Functional Dependencies: {PubId}  {PubPhone}
2 Small House 123-456-7890
{PubId}  {PubName}
{PubName, PubPhone}  {PubID}
3 Alpha Press 111-111-1111

Example 3
AuID AuName AuPhone
1 Sleepy 321-321-1111
Table Scheme: {AuID, AuName, AuPhone}
2 Snoopy 232-234-1234 Functional Dependencies: {AuId}  {AuPhone}
3 Grumpy 665-235-6532 {AuId}  {AuName}
4 Jones 123-333-3333
{AuName, AuPhone}  {AuID}
5 Smith 654-223-3455

6 Joyce 666-666-6666

7 Roman 444-444-4444
 FD – Example
Database to track reviews of papers submitted to an academic
conference. Prospective authors submit papers for review and
possible acceptance in the published conference proceedings.
Details of the entities
• Author information includes a unique author number, a name, a
mailing address, and a unique (optional) email address.
• Paper information includes the primary author, the paper number,
the title, the abstract, and review status (pending,
accepted,rejected)
• Reviewer information includes the reviewer number, the name, the
mailing address, and a unique (optional) email address
• A completed review includes the reviewer number, the date, the
paper number, comments to the authors, comments to the
program chairperson, and ratings (overall, originality, correctness,
style, clarity)
 FD – Example
Functional Dependencies
• AuthNo  AuthName, AuthEmail, AuthAddress
• AuthEmail  AuthNo
• PaperNo  Primary-AuthNo, Title, Abstract, Status
• RevNo  RevName, RevEmail, RevAddress
• RevEmail  RevNo
• RevNo, PaperNo  AuthComm, Prog-Comm, Date,
Rating1, Rating2, Rating3, Rating4, Rating5
 Second Normal Form (2NF)
For a table to be in 2NF, there are two requirements
• The database is in first normal form
• All nonkey attributes in the table must be functionally dependent on the
entire primary key
Note: Remember that we are dealing with non-key attributes

Example 1 (Not 2NF)

Scheme  {Title, PubId, AuId, Price, AuAddress}
1. Key  {Title, PubId, AuId}
2. {Title, PubId, AuID}  {Price}
3. {AuID}  {AuAddress}
4. AuAddress does not belong to a key
5. AuAddress functionally depends on AuId which is a subset of a key
 2NF - Decomposition
1. If a data item is fully functionally dependent on only a part of the
primary key, move that data item and that part of the primary
key to a new table.
2. If other data items are functionally dependent on the same part
of the key, place them in the new table also
3. Make the partial primary key copied from the original table the
primary key for the new table. Place all items that appear in the
repeating group in a new table
Example 1 (Convert to 2NF)
Old Scheme  {Title, PubId, AuId, Price, AuAddress}
New Scheme  {Title, PubId, AuId, Price}
New Scheme  {AuId, AuAddress}
Reduce into 2NF
Reduction to 2NF
 Third Normal Form (3NF)
This form dictates that all non-key attributes of a table must be functionally
dependent on a candidate key i.e. there can be no interdependencies
among non-key attributes.

For a table to be in 3NF, there are two requirements

• The table should be second normal form
• No attribute is transitively dependent on the primary key

Example (Not in 3NF)

Scheme  {Title, PubID, PageCount, Price }
1. Key  {Title, PubId}
2. {Title, PubId}  {PageCount}
3. {PageCount}  {Price}
4. Both Price and PageCount depend on a key hence 2NF
5. Transitively {Title, PubID}  {Price} hence not in 3NF
 3NF - Decomposition
1. Move all items involved in transitive dependencies to a new
entity.
2. Identify a primary key for the new entity.
3. Place the primary key for the new entity as a foreign key on the
original entity.

Example 1 (Convert to 3NF)

Old Scheme  {Title, PubID, PageCount, Price }
New Scheme  {PubID, PageCount, Price}
New Scheme  {Title, PubID, PageCount}
 Boyce-Codd Normal Form (BCNF)
• BCNF does not allow dependencies between attributes that belong to candidate keys.
• BCNF is a refinement of the third normal form in which it drops the restriction of a non-
key attribute from the 3rd normal form.
• Third normal form and BCNF are not same if the following conditions are true:
• The table has two or more candidate keys
• At least two of the candidate keys are composed of more than one attribute
• The keys are not disjoint i.e. The composite candidate keys share some attributes

Example 1 - Address (Not in BCNF)

Scheme  {City, Street, ZipCode }
1. Key1  {City, Street }
2. Key2  {ZipCode, Street}
3. No non-key attribute hence 3NF
4. {City, Street}  {ZipCode}
5. {ZipCode}  {City}
6. Dependency between attributes belonging to a key
 BCNF - Decomposition
1. Place the two candidate primary keys in separate
entities
2. Place each of the remaining data items in one of the
resulting entities according to its dependency on the
primary key.
Example 1 (Convert to BCNF)
Old Scheme  {City, Street, ZipCode }
New Scheme1  {ZipCode, Street}
New Scheme2  {City, Street}
• Loss of relation {ZipCode}  {City}
Alternate New Scheme1  {ZipCode, Street }
Alternate New Scheme2  {ZipCode, City}
Exercise:
• DB(Pno,PName,appNo,time,doctor)
• Pno -> PName
Pno,appNo -> Time,doctor
Time -> appNo

• DB(Pno,PName,appNo,time,doctor)
• DB(Pno,PName,appNo,time,doctor)
• -seems no repeating groups. So is in 1NF

• DB(Pno,appNo,time,doctor)
• R1(Pno,PName)
• No partial Dependencies. So 2NF
• No Transitive dependencies so… 3NF
BCNF
• Every determinant is a candidate key.
• What’s going on here???
• DB(Pno,appNo,time,doctor)
• R1(Pno,PName)
• DEPENDENCIES:
• Pno -> PName
Pno,appNo -> Time,doctor
Time -> appNo
• Then we may reduce the relation to:
• DB(Pno,time,doctor)
R1(Pno,PName)
R2(time,appNo)
 Decomposition – Loss of
Information
1. If decomposition does not cause any loss of information it is
called a lossless decomposition.
2. If a decomposition does not cause any dependencies to be lost
it is called a dependency-preserving decomposition.
3. Any table scheme can be decomposed in a lossless way into a
collection of smaller schemas that are in BCNF form. However
the dependency preservation is not guaranteed.
4. Any table can be decomposed in a lossless way into 3rd normal
form that also preserves the dependencies.
• 3NF may be better than BCNF in some cases

Use your own judgment when decomposing schemas

Example:
Example: