Third Normal Form

Question

Post reply

Third Normal Form

Viewing 8 posts - 16 through 22 (of 22 total)

You must be logged in to reply to this topic. Login to reply

John Rees SSChasing Mays Points: 621 More actions · Answer 1

Hi Tom,

I was also confused about whether the 3NF example was in 2NF or not.

I had just submitted a really long question, but then saw your reply to James:

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.

This is a great summary, and IMO would be a good addition to the 2NF article.

Thanks, John

TomThomson SSC Guru Points: 104773 More actions · Answer 2

john.rees-894283 (7/28/2011)
Hi Tom,
I was also confused about whether the 3NF example was in 2NF or not.
I had just submitted a really long question, but then saw your reply to James:
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.
This is a great summary, and IMO would be a good addition to the 2NF article.
Thanks, John

Hi John,

Thanks for your input.

This is one of those times where I wish I had had people's comments before I published the 2NF article! It's not the first time, if you look at the comments you'll see that I needed a revision after one of the first few comments.

Tom

TomThomson SSC Guru Points: 104773 More actions · Answer 3

dogramone (7/28/2011)
Thanks for these articles Tom. I have ensure the application developers here are reading all of them. Of course the DBA's already get it but like a lot of small shops the DBAs don't do development and although there are a lot of senior developers they are all building to a OLTP style and are always making these common mistakes.
I'm anxiously looking forward to the next in the series and the Fourth and Fifth are for me as I've only ever gotten to 3.5 or what I was taught as Boyce Codd Normal Form.

Thanks for the encouragement; it's good to know that my attempts are appreciated.

Tom

James Goodwin Hall of Fame Points: 3691 More actions · Answer 4

James Goodwin

Hall of Fame

Points: 3691

July 29, 2011 at 6:52 am

#1360731

Tom,

Much clearer. Thanks for the response.

--

JimFive

vasu_kaladi SSC Rookie Points: 33 More actions · Answer 5

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.

vasu_kaladi SSC Rookie Points: 33 More actions · Answer 6

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

TomThomson SSC Guru Points: 104773 More actions · Answer 7

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

pjcrout SSChasing Mays Points: 648 More actions · Answer 8

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 :hehe:

Thanks Again!

Paul