Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

Third Normal Form Expand / Collapse
Author
Message
Posted Monday, August 1, 2011 8:42 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, January 16, 2014 5:51 AM
Points: 2, Visits: 41
Tom.Thomson (7/28/2011)
James Goodwin (7/28/2011)
The difference between 2NF and 3NF is that 2NF does not permit any non-prime attribute to have a dependency on something which is a proper subset of a candidate key, while in 3NF a non-prime attribute may not depend on anything which is not a superkey

My confusion is that the original table in the example is, then, not in 2NF because the phone number depends on something (Group) that is not the whole key, or in fact, even part of the key. So it seems that you took a table from 1NF to 2NF which was then trivially in 3NF (in the sense that no extra work was required to get it into 3NF).

What I would like to see is a table that is in 2NF converted into 3NF.
--
JimFive

Ah, a confusion about 2NF. You hit the crucial point when you said "or [not] in fact, even part of [the key]", because that is of course allowed by 2NF. There's nothing in 2NF to stop an attribute being dependent on some set of attributes that includes something that isn't part of a key. The rule is that if a non-prime attribute is dependent on something that is a subset of a key that subset must be the whole key. Or putting it another way, the whole key is not the only thing it can be dependent on, the rule is simply that it must never be dependent on a partial key. So the original table inthe 3NF article is indeed in 2NF.



Thanks for the articles on 1NF, 2NF and 3NF which I read with great interest.
I would like some more explanation on how the original table you started with in the 3NF article is already in 2NF. It would help if you could start with an example that is not even in 1NF and go only one step and get it to be 1NF and explain why that one is not yet in 2NF. Then make it 2NF and explain why it is not yet in 3NF before the final example where it is already in 3NF.
Vasu
Post #1151871
Posted Wednesday, August 10, 2011 4:37 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: 2 days ago @ 10:00 AM
Points: 8,551, Visits: 9,043
vasu_kaladi (8/1/2011)

Thanks for the articles on 1NF, 2NF and 3NF which I read with great interest.
I would like some more explanation on how the original table you started with in the 3NF article is already in 2NF.

The easy way to see that the original table is in 2NF is to look for candidate keys. Since we have a business rule that each city can contain only one depot and each depot serves only one of teh operating groups, clearly the city attribute is a single attribute candidate key. And since there's nothing in other columns from which we could be sure to deduce the city, there are no candidate keys that don't contain the city attribute, so that single attribute candidate key ios the only candidate key. Nothing can be dependent on a proper subset of that, so there are not any dependencies forbidden by 2NF - the table is in 2NF. (Every table where all candidate keys consist of a single attribute is in 2NF.)
It would help if you could start with an example that is not even in 1NF and go only one step and get it to be 1NF and explain why that one is not yet in 2NF. Then make it 2NF and explain why it is not yet in 3NF before the final example where it is already in 3NF.
Vasu

That would be whole new article. To do it properly it would need to go through a lot of transformations: not 1NF to 1NF to 2NF to 3NF to EKNF to BCNF to 4NF to 5NF to 6NF, so a very long article.


Tom
Post #1158129
Posted Thursday, October 13, 2011 10:03 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, December 12, 2013 10:21 AM
Points: 16, Visits: 78
I finally got around to reading this one! WooHoo! I've been following this normal form series, but I had forgotten about it until the other day and came back and re-read from the begining. Always a good read, and the subsequent discussions are always entertaining

I will say, this go has been a much more civil exchange of criticism and exposition... good job SSC Users! You've come a long way baby

Like some of the other users had mentioned, I too was at first thinking "Why does this seem exactly like what was just covered in 2NF?"

After reading your responses here, it became much clearer, mainly with the A-HA! moment of "The City alone is the key in the Sales_Depot table" due to the business rule of one depot per city, which ultimaltely means one record per city. Some how that had escaped me to start and I was thinking it was not a single attribute key for some reason. Upon realizing this, it made much more sense that before it was in 2NF, and by removing the Order Number only, it moved to 3NF since the order number was not dependent on city, but only group, however the group and address are directly dependent upon ONLY the city (the key), but not each other.

Looking forward to your next entry in the series!

BTW - Why is this not a Stairway, i.e. - "Stairway to Normalization"? Seems like it should be. Maybe when it's finished? Not sure how that works

Thanks Again!
Paul
Post #1190009
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse