Talk:Boyce–Codd normal form

message: Isn't the person, shop type, nearest shop example a schema in the form {AB → C, AC → B} and not {AB → C, C → B} as stated? If nearest shop determined shop type (C → B), then surely the stated anomaly could not happen.  —Preceding unsigned comment added by 213.248.204.74 (talk) 09:23, 17 February 2009 (UTC)
replies: text: Hi, I think you've subtly misunderstood what is meant by a functional dependency.  Shop Type is functionally dependent on Nearest Shop because logically, in the real world, a single shop ought to have exactly one shop-type.  The point about functional dependencies though is that depending on how you've designed your tables, you might have a situation where the table can accommodate data that fails to respect one or more functional dependencies.  This possibility of this situation IS the anomaly.  So in this example, we want to respect the functional dependency C → B, but even if we enforce all the candidate keys we cannot guarantee that C → B will be respected.  --Nabav (talk) 14:33, 21 February 2009 (UTC)
replies: text:  "because logically, in the real world, a single shop ought to have exactly one shop-type"  Since When? I know plenty of shops that do more than one thing, and hence could have more than one type. (Also, a cynical pedant would point out that "logically, in the real world" is a contradiction in terms.) I do think this is a bad example ...  —Preceding unsigned comment added by 94.193.94.243 (talk) 13:25, 17 June 2009 (UTC)
replies: text: All right: poor phrasing on my part in my previous comment.  The upholding of certain functional dependencies is an aspect of the way a database represents the real world.  For example, we might have an Employee table that upholds the functional dependency {Employee} → {Current Work Location}.  Now, someone might complain that this representation distorts reality because actually, an Employee might have a desk at each of two different locations, dividing his time between the two.  Fair enough: but by designing our database in such a way as to uphold {Employee} → {Current Work Location}, we are simply saying that an Employee can never have multiple Current Work Locations in our representational schema.  Depending on how the database is to be used, this may well be a perfectly good design choice.  In designing databases, we aren't striving to represent absolutely every nuance of reality; instead we're striving to represent a particular domain in a way that's useful for particular purposes.  Thus even though it is true that tomorrow someone might open a shop called "Steve's Bakery & Opticians", this possibility should not necessarily prevent us from designing a database that upholds the functional dependency {Shop} → {Shop Type}.  I will add to the article an explicit statement that we're treating a shop as always having exactly one type.  --Nabav (talk) 07:29, 27 June 2009 (UTC)

text: == A way out? ==
Although 3NF is not BCNF for {AB->C,C->B} is true. There is a way out in this example. Just create a more generic datamodel. We would have to record the distance to each shop. And if we need the closest shop we need to udpate our queries. create a table [person, shop, distance] and a talbe [shop, shoptype]. Wouldn't this be possible for every 3NF that is not BCNF????  —Preceding unsigned comment added by 85.144.94.32 (talk) 11:21, 7 August 2009 (UTC)
replies: text: There's always more than one way to model a situation, and yes: modelling the situation in a different way can often make these problems (problems of insufficient normalization) disappear.  Your suggestion would have that effect.  So would a model in which we recorded the latitude and longitude of each person's home, and the latitude and longitude of each shop, and the shop type of each shop.  (Writing the necessary query could be awkward, but in principle we've got all the information we need.)  What I would say however is that both of these suggestions require the database to capture extra information (about distances, about latitudes and longitudes) which the original example was not trying to capture.  Therefore I don't think these sorts of suggestions throw much light, in a general way, on the issues discussed in the article.  --Nabav (talk) 08:40, 15 August 2009 (UTC)

text: == Naming things ==
As Zaniolo's new normal form is used in the article to illustrate how the representation failures of BCNF can be avoided at the same time as fixing the anomalies that BCNF was intended to fix, and Zaniolo's paper defining that normal form is referenced, why not give that normal form its name Elementary Key Normal Form (EKNF) since that's what Zaniolo called it in the paper that defined it, rather than leaving it nameless?  — Preceding unsigned comment added by Michealt (talk • contribs) 18:58, 27 May 2011 (UTC)
thread_title:  3NF but not BCNF 

message: In the tennis court example, splitting the tables as shown does not allow you to prevent scheduling SAVER and STANDARD rates (both for Court 1) with the same Start Time.71.165.187.242 (talk) 19:41, 23 July 2008 (UTC)
replies: text: Right you are.  Well, my track record of coming up with edifying BCNF examples is terrible.  Here, what I was going for was a table meeting 3NF but not BCNF, a table which could then be decomposed into tables meeting BCNF.  In fact, as your comment highlights, my decomposition doesn't do what I thought it did.  Is this one of those cases (as in the "Achievability of BCNF" section) where BCNF is unachievable?  Can anyone come up with an example that doesn't suffer from this problem?  The Tutor/Student example in a previous version of this article (see discussion) did not suffer from the problem ... but was judged not to be very enlightening.  Frankly, though, the Tutor/Student example, awkward as it was to explain and justify, now seems better than this example - which just does not work.  I welcome other people's thoughts on example-construction.  --Nabav (talk) 22:37, 23 July 2008 (UTC)
replies: text: Ok: panic over, hopefully.  I've altered the BCNF solution so that it doesn't suffer from the problem described above.  The new solution incorporates an entirely new attribute, Member Flag - having a Member Flag is quite natural in modelling this particular situation.  Because of the Member Flag attribute, this is not a decomposition.  But it is in BCNF, and it does work (unless someone spots another flaw ...)  The candidate keys in the solution are such as to ensure all the functional dependencies are respected.  New functional dependencies introduced (and respected), are, as I hope should be obvious given the candidate keys specified, {Rate Type} → {Court, Member Flag} and vice-versa, as well as Member Flag's dependency on both candidate keys in Today's Bookings.  --Nabav (talk) 07:07, 24 July 2008 (UTC)
replies: text:  A minor point which I believe might make the Tennis example a little clearer.  Currently the table "Today's Court Bookings" adheres to 2NF and 3NF because all attributes belong to candidate keys.  It might be a little clearer if they did not so that you could demonstrate non-trivial functional dependence on something that is not a candidate key in the non-BCNF table and contrast it to non-trivial functional dependence on only candidate keys in the BCNF tables after you have BCNF-normalised.  I think this contrast would help to highlight the difference between 3NF and BCNF.  —Preceding unsigned comment added by 84.203.32.235 (talk) 14:29, 21 January 2010 (UTC)
replies: text:  I don't get it.  To me it's simply : Something is rotten in the state of Denmark. I agree with my fellow "71.165.187.242".  As I see it, you can still book a SAVER and a STANDARD at 9:00 and both will met on court 1.  Maybe it's me... don't know.  Here my view, maybe it doesn't show what you want to explain but... A "Booking" is an event that has a court and a time. The key is "Court" and "Start Time".  "Rate Type" has nothing to do up there since it depends on "Court" and "Member Flag" not on the event "Booking".  What you need to know is who's booking the court.  This event owns a place, a time and someone (the facts); not a place, a time and .. a rate (to fix the rate you need to know first who will be there).    I'm wrong ? - Elavoie 01:09, 5 Oct. 2011  — Preceding unsigned comment added by 70.30.170.84 (talk) 05:11, 5 October 2011 (UTC)
thread_title:  Tennis Example 

message: The amended (so that it meets BCNF) design of the tennis example is illogical.  It may meet BCNF, but to me a more logical solution would be:
Member Type Court	                	
Court (PK)       	Member Flag (PK)	Rate Type
1                	Yes             	SAVER
1                	No              	STANDARD
2                	Yes             	PREMIUM-A
2                	No              	PREMIUM-B
Today's Bookings	           	               	
Court (PK)      	Member Flag	Start Time (PK)	End Time (PK)
1               	Yes        	9:30           	10:30
1               	Yes        	11:30          	12:30
1               	No         	14:00          	15:30
2               	No         	9:30           	10:30
2               	Yes        	11:30          	12:30
2               	Yes        	14:00          	15:30
We have two courts (i.e. 1 and 2). we can allow each court for either member or non member at a time. if it is understood that a court should be allowed for a fix duration then here we can select either (court,start time) as a key or (court,end time) as a key and if it is not then we need to focus on that a start time should not be overlap with or before end time. the member flag is not need to take as a key because we have a court and we can allow it to either a member or to a non member. 
This solution seems more straightforward to answer the common question "What courts are booked today?".  — Preceding unsigned comment added by Derekwork (talk • contribs) 21:01, 16 February 2011 (UTC)
thread_title:  Better Amendment Exists For Tennis Court Example? 

message: According to candidate key's definition (and even intuitively), I don't see why {Court, Start Time} and {Court, End Time} are NOT candidate keys.  So I included them back.
As a matter of fact, the paragraphs after that make more sense when these two superkeys are ALSO candidate keys.
If someone could mathematically prove that they are not candidate keys, please rectify my change.
石庭豐 (talk) 15:54, 30 April 2011 (UTC)
thread_title:  Can't see why {Court, Start Time} and {Court, End Time} are NOT candidate keys 

message: The article states
> It is NP-complete, given a database schema in third normal form, to determine whether it violates Boyce–Codd normal form.
However I can't see how this could be true based on the Wikipedia definition of NP-complete. One of the features of NP-complete is that the solution can be validated quickly but in this case the "solution" is a boolean value so surely if the solution can be validated quickly then the maximum time needed is 2x "quickly"? Mjaggard (talk) 10:31, 8 February 2023 (UTC)
thread_title:  NP Complete?