Re: Constraints and Functional Dependencies

On Feb 24, 2:08 pm, "Walt" <wami..._at_verizon.net> wrote:
> "Marshall" <marshall.spi..._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.

Agreed.

> 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.

Can you list a few ways primary keys make things easier?

Marshall Received on Sun Feb 25 2007 - 06:42:12 CET