>>So let's have BCNF;
>>Luckily I dealt with this one the other day, and so far I feel strong ;) However, I know I am challenging here, and expected some response. So :
>>
>>BCNF is all about candidate keys, at least, it looks like it. Looking for the good examples and explanations is rather difficult (I found the other day), but, in the end I found some (over the Internet). Now I'd like to ask you Jim, prepare me some (whatever NF) indluding CK's, and I will work it out for you. Agreed ? when I can I win, when I can't you win. Not that someone wants to win, but I'm prepared, and I state that BCNF doesn't even exist. Reading the description(s) carefully, it's already in the definition itself. Your turn.
>
>Peter,
>
>Ok the design for a database requires that all tables have a non-meaningful Primary key (Surrogate PK). Below is the design of the customer table;
>
>CustID I PK
>CustNo C(10) CK
>Name C(35)
>...
>
>Virtually every table in this database will have a PK and some other cobination of fields that could be the PK (defined as CK).
>
>You are correct in that BCNF to fix a violation will require that certain CKs be removed to new entities, however it is BCNF does not disallow the existance of a CK.

Jim, you came up with about the only example of where BCNF in some fuzzy area leads to generated keys, but which IMHO says nothing more than that the generated key is needed. Not that the remainder atributes are Candidate Keys; They just are not, because they won't be unique anyhow. Right ?

Sadly your example just doesn't allow to remove the CKs to new entities (as you state yourself). I'd say that at a glance I recognized that we both intepreted this sthuff just the same, and some nice discussion will workout this to some extend not so much known. I'd suggest to let it rest, but anyhow I'd like to "fight" over this. It intgreges me. If you have the better example, I'd be pleased ...