Re: BCNF: superkey or candidate key ?

Jan Hidders wrote:
> Jan Hidders wrote:
> > Jan Hidders wrote:
> > > David Cressey wrote:
> > > >
> > > > Here's what's behind my question. relational tables with at most 1 non-key
> > > > column is where the great debate about NULLs becomes moot. If you want to
> > > > leave the non-key column NULL, then just omit the row. Of course, you need
> > > > another table with just the primary key to keep track of which of the
> > > > possible primary keys are in existence.
> > >
> > > Why the restriction to at most 1 non-key column? It doesn't matter how
> > > many non-key columns there are: you can always apply that
> > > transformation if the nullable column is not part of a candidate key.
> > >
> > > One might even argue that in theory the restriction to non-key columns
> > > is not really necessary. In that case you just need to introduce a more
> > > complex database constraint to replace the candidate key constraint.
> >
> > That final statement of mine is actually a bit misleading, it is more
> > the FDs that arrive in the nullable column that you should worry about,
> > so let me clarify. An example:
> >
> > R(A, B, C, D) with FDs AB->C and CD->B, and C nullable
> >
> > Observe that the CKs are AB and AC.
>
> That should of course be: the CKs are ABC and ACD.

*sigh* the CKs are AB*D* and ACD

I'm going to get a coffe now. :-)

• Jan Hidders