Talk:Second normal form/Archive 2

Archive 1

Archive 2

An example of an un-normalised table should be given in the 1NF article. The same example should be continued, and the evolution of this non-NF table to a 3NF table(s) should be clearly shown in the subsequent 2NF and 3NF articles. This will improve the quality of each article, and help novice users and or beginners to database normalisation in clearly understanding the difference between 1/2/3NF and the steps needed to convert one to another.

iTommy 14:58, 8 May 2007 (UTC)

The trouble is that although beginners typically believe that a table is normalized step-by-step into 1NF, then into 2NF, then into 3NF, etc., actually this is not the case. Normalization is not an iterative process. There is no evolution. It's very important that novices understand this, rather than having the misconception reinforced. For a deliberately contrived example in which we pretend it is an iterative process, see the Database Normalization article; but as a general rule the examples ought not to imply that a designer visits the lower normal forms one by one on the way to the higher. --Nabav 21:48, 9 May 2007 (UTC)

I'm beginner, but I see some inconsistency. In the table "Employees' Skills" the candidate key is {Skill} isn't it? (according to the definition in candidate key) Of course the {Employee, Skill} is logically sound, but we needed to say something more, for instance to show other possible table. But for me - having shown only this one table - the sentence "The table's only candidate key is {Employee, Skill}" is misleading.

You are quite right - the rows shown in Employees' Skills were consistent with the candidate key being {Skill}. I have corrected the example now by adding an extra employee who shares a skill with another; this means there is no longer any unclarity about the candidate key. Thanks for pointing out the ambiguity. --Nabav 18:29, 16 May 2007 (UTC)

I am begginner too but I think now the statement that there is only one candidate key is incorrect. {Skill,Location} is now a candidate key too as it uniquely identifies records and neither Skill nor Location does it. 212.87.13.76 20:39, 25 May 2007 (UTC) Jacek 25 May 2007 (GMT+2)

Reading carefully the Set theoretic formulation it says that the determination of a candidate key must consider all possible (permissible) tables. So if someone says {Employee,Skill} is the only candidate key, and told us nothing more, we just have to accept that. However, the example is misleading, since we expect to be able to verify for ourselves that the there is only one candidate key, and, as Jacek points out, we can't. --03:05, 28 May 2007 (UTC)

Yes, you are right on both counts. Example has now been changed. --Nabav 21:36, 3 June 2007 (UTC)

The 4th table doesn't seem to be in 2NF: {Tournament, Winner} is also a candidate key for the table, but {Winner Date of Birth} is dependent only on {Winner}. shuricub 17:48, 13 June 2007 (UTC)

I think this is getting out of hand! {Tournament, Winner} is not a candidate key. To say it was a candidate key would be to say: a player can only ever win a given tournament once; after that, he can't win the tournament any more. But of course, there is no such rule; the semantics of the situation are obvious (in any given year, a tournament is won by whoever it's won by). Although it's easy enough to tweak the data in the example tables to make it absolutely blindingly clear which combinations of attributes cannot be candidate keys, I'm a bit worried that doing so is tending to reinforce an incorrect belief about what a candidate key is. When the semantics of the example are clear (as I believe they are in this case), the candidate key or keys should be clear. That is, they should be clear so long as people understand the definition of "candidate key". A candidate key is guaranteed to uniquely identify not just the rows that are in the table right now, but all possible rows. --Nabav 21:54, 19 June 2007 (UTC)