Talk:Boyce-Codd normal form/Archive 1
 | This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
example not in 1NF
I think the example is not in the First Normal Form, because "Ornate Small" isn't atomic - it should be split into "Ornate", "Small"
simplyfied example
The e-mail address shouldn't be in the table since it would've been removed in the 1st form (you can 'calculate' the data so no need to store it somewhere). Something alike : the total price of a order isn't stored in a db but calculated with your bought products,quantity,discount etc...
latest simplified example
I removed the latest simplified example because it featured a part-key dependency (email address was dependent on student id). A table with a part-key dependency does not even meet Second Normal Form, much less Boyce-Codd Normal Form. It would be more suitable, therefore, as an example to illustrate what Second Normal Form is about. --Nabav 15:09, 16 November 2006 (UTC)
Boyce-Codd NF is silly
The examples shown are not in 3NF. The two columns cited as erroneous do not depend upon the whole of the key and they do not depend on nothing but the key. The discussion admits this in some detail yet somehow cites the original table as being in 3NF. Makes no sense.
Either Boyce-Codd NF is silly or this is not an example of BCNF.
Tqbfjotld 14:49, 20 February 2007 (UTC)
The example is not in 3rd normal form
Because we have a functional dependency Range Code -> Stock Category. —The preceding unsigned comment was added by 75.17.59.188 (talk) 20:16, 3 March 2007 (UTC).
You'll be relieved to hear I've changed the example
I am older and wiser now than when I produced the original example. I have provided a better one now, with what I hope is a clear explanation of why it falls short of BCNF but meets the requirements of 3NF. --Nabav 19:22, 10 May 2007 (UTC)
Still not in 3NF
The example is still not in 3NF. Formally, a table is in 3NF if for every functional dependecy (FD) X→A one of the following is true:
- FD is trivial, or
- X is a superkey, or
- A is a part of some key
For FD {Check-in Date, Check-out Date}→{Number of Nights} neither {Check-in Date, Check-out Date} is a superkey nor {Number of Nights} is a member of some key. Therefore the example is incorrect.
Changed it again!
Well, this has been a learning experience. Once again I've changed the example, and I've corrected the definition of 3NF in the 3NF article. --Nabav 14:28, 2 June 2007 (UTC)