Re: Constraints and Functional Dependencies

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1172333601.148573.19370_at_v33g2000cwv.googlegroups.com...
> On Feb 24, 6:41 am, paul c <toledobythe..._at_oohay.ac> wrote:
> > Marshall wrote:
> > > ...
> > > With such a system, a relation R with attribute a (which I will
> > > write as R(a)) having a as a foreign key into S(b) is expressed
> > > as follows:
> >
> > > forall R(a): exists S(b): a = b
> >
> > > So we can express foreign keys this way.
> > > ...
> >
> > I presume that if S had other attributes besides b, this definition
> > would mean that b doesn't need to be a so-called primary key? (That
> > would be okay with me.)
>

This is a digression, rather than another nit pick. The concept behind "primary key" adds nothing, mathematically, to the concept behind "candidate key". Any one of the candidate keys could be used as a foreign key, with equal effect.

In practice, it turns out to make data management easier if, wherever there are tables with multiple candidate keys, one of them is chosen as the so called "primary key", and all foreign key references to that table are made by way of that key.
But, again, there is nothing that is gained or lost in expressive power by adopting this convention. It's purely a matter of convenience. Received on Sat Feb 24 2007 - 23:08:35 CET