Have a question? ask www.kenlet.com
Home  |  FAQ  |  About  |  Contact  |  View Source   
 
SEARCH:
 
BROWSE:
    My Hood
Edit My Info
View Events
Read Tutorials
Training Modules
View Presentations
Download Tools
Scan News
Get Jobs
Message Forums
School Forums
Member Directory
   
CONTRIBUTE:
    Sign me up!
Post an Event
Submit Tutorials
Upload Tools
Link News
Post Jobs
   
   
Home >  Tutorials >  Database >  Database Normalization part II -- Second and Third Normal Forms
Add to MyHood
   Database Normalization part II -- Second and Third Normal Forms   [ printer friendly ]
Stats
  Rating: 3.93 out of 5 by 15 users
  Submitted: 12/11/01
Greg Hendricks (gregaryh@byu.edu)

 

Database Normalization Part II


In our last installment, we discussed what database normalization is and how
to get our tables into first normal form.  


In this installment, we will talk about normalization in the second and third
normal forms.  Since normalization is progressive, that is each normal form
builds on the previous forms, we assume that our tables are already in first
normal form.  For a review of first normal form, see the previous tutorial
labeled "Database Normalization."


Second Normal Form


The second normal form applies only to tables with multiple field primary
keys.  Take the following table for example.


Rep ID* Rep First Name Rep Last Name Client ID* Client Time With Client
TS-89 Gilroy Gladstone 978 US Corp 14 hrs
TS-89 Gilroy Gladstone 665 Taggarts 26 hrs
TS-89 Gilroy Gladstone 782 Kilroy Inc. 9 hrs
RK-56 Mary Mayhem 221 Italiana 67 hrs
RK-56 Mary Mayhem 982 Linkers 2 hrs
RK-56  Mary  Mayhem 665 Taggarts 4 hrs

This table is already in first normal form.  It has a primary key
consisting of Rep ID and Client ID since neither alone can be considered a
unique value.  


The second normal form states that each field in a multiple field primary key
table must be directly related to the entire primary key. Or in other words,
each non-key field should be a fact about all the fields in the primary key.
Only fields that are absolutely necessary should show up in our table, all other
fields should reside in different tables.  In order to find out which
fields are necessary we should ask a few questions of our database.  In our
preceding example, I should ask the question "What information is this
table meant to store?" Currently, the answer is not obvious. It may be
meant to store information about individual clients,  or it could be
holding data for employees time cards.  As a further example, if my
database is going to contain records of employees I may want a table of
demographics and a table for payroll.  The demographics will have all the
employees personal information and will assign them an ID number.  I should
not have to enter the data twice, the payroll table on the other hand should
refer to each employee only by their ID number. I can then link the two tables
by a relationship and will then have access to all the necessary
data.  


In the table of the preceding example we are devoting three field to the
identification of the employee and two to the identification of the
client.  I could identify them with only one field each -- the primary
key.  I can then take out the extraneous fields and put them in their own
table.  For example,  my database would then look like the following.


Rep ID* Client ID* Time With Client
TS-89 978 14 hrs
TS-89 665 26 hrs
TS-89 782 9 hrs
RK-56 221 67 hrs
RK-56 982 2 hrs
RK-56 665 4 hrs

The above table contains time card information.


Rep ID* First Name Last Name
TS-89 Gilroy Gladstone
RK-56 Mary Mayhem

The above table contains Employee Information.


Client ID* Client Name
978 US Corp
665 Taggarts
782 Kilroy Inc.
221 Italiana
982 Linkers

The above table contains Client Information


These tables are now in normal form.  By splitting off the unnecessary
information and putting it in its own tables, we have eliminated redundancy and
put our first table in second normal form.  These tables are now ready to
be linked through relationship to each other. 


Third Normal Form


Third normal form is the same as second normal form except that it only
refers to tables that have a single field as their primary key.  In other
words, each non-key field in the table should be a fact about the primary key.
Either of the preceding two tables act as an example of third normal form since
all the fields in each table are necessary to describe the primary key. 


Once all the tables in a database have been taken through the third normal
form, we can begin to set up relationships.  In out next installment, we
will discuss relationships and how using them allows us greater flexibility in
our database.



Return to Browsing Tutorials

Email this Tutorial to a Friend

Rate this Content:  
low quality  1 2 3 4 5  high quality

Reader's Comments Post a Comment
 
Excellent topic to discuss.....

It seems to mee that alot of developers don't seem to know what "normalization" is. Frankly it is the key to an efficient DB and the difference between good work and pointless work.

--Cheers!!
-- Aaron Roberts, December 12, 2001
 
Wonderful... this will help on my IS exam!
-- D P, December 12, 2001
 
Do you have plans for illustrating the higher normal forms? 3NF has always been said to be "good enough for practical implementation". But how does the 4NF contribute to database design and what are its drawbacks that support the above statment?
-- Danny Chow, December 12, 2001
 
problem with the higher normal forms is you pay a huge penalty on performance because you are joining so many tables.

I believe most databases that need to be very performant are implemented using 2nd or 3rd normal forms.
-- John Gallardo, December 12, 2001
 
Thank you for explaining normalizationh, I didn't understand it as well before.
-- Chris Roberts, December 12, 2001
 
Very good info. Thanks.
-- Reid Jonasson, December 14, 2001
 
don't forget about BCNF...

The idea of normalization is kinda silly in my mind...If you design an ER diagram first, you're guaranteed 3NF. Oh well. I still give you a five :)
-- Seth Peck, December 17, 2001
 
I feel that 3NF should be explained in more detail. Perhaps an example?

In other words, I do not see how it is significantly different from 2NF.
-- Steven Padfield, December 28, 2001
 
How does this normalization affect the database and overall system performance,
since it produce more table and columns?
-- Adrianus Suheryadi, January 07, 2002
 
great work!
-- Siyan Li, January 12, 2002
 
Nice work.
I'm hoping you'll further explain the other forms of database normalization.
-- Yusno Yunos, February 11, 2002
 
Good job!!
-- Mihir Patel, February 15, 2002
 
Interesting tutorial.
-- Brian Simoneau, March 04, 2002
 
5 Stars *****

Great job! This is exactly what I was looking for. I've been working on some normalization exercises for some time and needed some additional clarification.
-- Ammon Beckstrom, March 11, 2002
 
Not bad. What about Boyce-Codd though ;)?
-- some guy, April 30, 2002
 
very helpful article.
-- Kurt Charoen, April 16, 2003
 

Copyright © 2001 DevHood® All Rights Reserved