Hi all,

I'm currently evaluating whether a relation is in 2NF. The relation is
defined as follows:
<Year | Winner Name | Winner Votes | Party | Home State> in the
context of an election. I've given a sample relation below.
1946 | MyName | 453 | MyParty | California
The primary key for this relation is 'Year'.

Now the question is whether this relation is in 2NF? What confuses me
is that some books say the following:
"Note that when a 1NF table has no composite candidate keys (candidate
keys consisting of more than one attribute), the table is
automatically in 2NF."

Now, let's evaluate the functional dependencies for this relation.
Year -> Winner Name
Year -> Winner Votes
Winner Name -> Party
Winner Name -> Home State

The definition for 2NF is as follows: "A 1NF table is in 2NF if and
only if, given any candidate key and any attribute that is not a
constituent of a candidate key, the non-key attribute depends upon the
whole of the candidate key rather than just a part of it." (Wikipedia)
which is consistent with the books I'm reading on databases.

Now as this relation doesn't have a composite primary key, it follows
that it is automatically in 2NF. But as we can see two non-prime
attributes (party & home state) are functionally dependent only a
subset of the primary key (the subset being the empty set). This must
imply that it is not in 2NF.

My question is, is this relation is 2NF or not?

Thanks,
g

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

On 8 feb, 17:21, gamehack <gameh... (AT) gmail (DOT) com> wrote:
A small note here: you should check if there is a composite
*candidate* key. It is in principle possible that the candidate key
you picked as primary keys is not composite while at the same time
there is another candidate that *is* composite, in which case the
relation could very well not be in 2NF.

They are not dependent on the empty set, but on the set {"Winner
Name"}, which is clearly not a proper subset of a candidate key. So no
2NF violation there.

-- Jan Hidders

gamehack wrote:

I am not sure where you read that. It sounds like a typo or a mistake.
Composite keys are important at the higher normal forms.