Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2343
  • Last Modified:

database normalization

I don't have a formal background in relational theory and I'm trying to get a better understanding of normalization.  I'm trying to find examples and more information on 1nf - 3nf, which seems to be appropriate for many smaller applications.  I want to get a good handle on these.

1NF - Eliminate Repeating Groups - Make a separate table for each set of related attributes, and give each table a primary key.

2NF - Eliminate Redundant Data - If an attribute depends on only part of a multi-valued key, remove it to a separate table.

3NF - Eliminate Columns Not Dependent On Key - If attributes do not contribute to a description of the key, remove them to a separate table.

Can anyone point me to some good resources.
0
-Dman100-
Asked:
-Dman100-
  • 2
  • 2
  • 2
  • +3
5 Solutions
 
dwhite365Commented:
OReilly SQL In a Nutshell has a short section covering normalization requirements that takes care of the practical aspects of it.
0
 
-Dman100-Author Commented:
anything online?  Examples?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
DireOrbAntCommented:
The wiki entry is quite nice, but you can scroll to the bottom and go to the "Further reading" and "External links" sections.

As for what you should apply to your project, the best answer I can give you is to try to understand all normal forms (there are more than 3), maybe excluding 6 ;) and to apply as much of them as possible. In a very small project, that won't get tons of hits/data and won't extend into a bigger apps, you can ignore most and get you projejct out though :)

Hope you find what you are looking for in there.
0
 
MohanKNairCommented:
0
 
david_levineCommented:
Are you looking to find out how to do it, why to do it, how do it for some specific example you have?

Doing it just to do it is fine for a classroom and fine for many real life examples, but there are valuable reasons to not do it too, depending on what your application is, how often data is updated, etc.

Theory is just theory and real life sometimes trumps theory.
0
 
-Dman100-Author Commented:
Thanks for the information.

No, this isn't for a classroom.  I work as a web developer and have been using SQL Server now for about 3 years.  Typically, most of my development has been data extraction, updates, inserts, deletions, etc.  I haven't done too much with actual modeling and design.  Albeit, I have done some design.

I'm getting more involved in the actual design and trying to expand my knowledge base on normalization and relational theory to help me be more effective in my development.

So, how to do it and why to do it certainly applies in my case.  I'm not completely in the dark to fundamental normalization concepts.

Does that help explain?
0
 
david_levineCommented:
Based on your past experience using SQL, you're likely well prepared for determining the application impact your design will cause. What needs to be done for a transactional application could be the same or very different from a design for a data warehouse application.

How the data will be used initially and built on over time helps determine the optimal plan of attack in designing a database.

I'm sure you already know, if the folks designing the tables you've been using are doing a good job, that most data elements reside in only 1 table with the keys of the records referenced in other tables. Lookup tables are typical in many applications and the keys to those records are stored in the other tables.

If you're looking for online references, a Google search for: practical database design
seems to turn up a lot of relevant links.

If you're looking for printed material, an Amazon book search on the same keywords turns up a bunch of what looks like pretty on topic references to learn or refer to:
http://www.amazon.com/exec/obidos/search-handle-url/103-0483154-2688667?%5Fencoding=UTF8&search-type=ss&index=stripbooks%3Arelevance-above&field-keywords=database%20design
0
 
gabesoCommented:
C J Date is a good writer on issues regarding relational databases see his books for an in-depth understanding of the relational model - as opposed to a vendor specific implementation of it (which of course all vendors support to various degrees of over-kill!)

If you are interested in understanding it you should investigate the concept of 'functional dependency' - which is the concept which underlies all of the normal forms.

A functional dependency is essentially a functional relationship between one value and another:

f(x) = y. If one x determines one y then you have a functional dependency between them - if one x determines many y's then you have a multivalued dependency between them.

If you start to analyze your information into "this determines that" so that you can follow a logical chain between one value and another you will have your information in a normal form i.e. it will be correct.

Tables just become dependencies collected together appropriately according to requirements of storage perhaps or other factors in your design.

0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
  • 2
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now