Re: Constraints and Functional Dependencies

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:45e09029$0$327$e4fe514c_at_news.xs4all.nl...
> Cimode 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.
>
> > Critisicm.
> >
> > First: If I apply the above definition, all relations R that have the
> > same values than S will be considered primary key for S.
>
> Obviously you did not yet read the responses to the OP when you wrote
> this. By now you may have. This is the same point paul c raises in his
> second reply to the OP, stated another way, right?
>
> One minor nitpick: The distinction between *primary* key and other
> keys is considered to be a practical choice for implementing DBMS's.
> As long as there is no established theoretical
> need for this distinction, we can just use these:
> key and candidate key (candidate key if there are more keys).
>

Big fleas have little fleas, upon their backs to bit 'em, And little fleas have lesser fleas, so on ad infinitum.

A nitpick on your nitpick:

The distinction between *primary* key and other candidate keys is considered to be a practical choice for database design, and is therefore supported in some DBMS's. Received on Wed Feb 28 2007 - 16:45:05 CET