Re: BCNF: superkey or candidate key ?

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.

• Jan Hidders