Re: Constraints and Functional Dependencies
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 24 Feb 2007 19:28:09 GMT
Message-ID: <dl0Eh.1124199$5R2.465965_at_pd7urf3no>
>
>
>
>
> 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?
> ...
Date: Sat, 24 Feb 2007 19:28:09 GMT
Message-ID: <dl0Eh.1124199$5R2.465965_at_pd7urf3no>
mAsterdam wrote:
> 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).
>
> Slightly more important: at this stage in the OP's
> argumentation the term (candidate) key has not yet been defined.
> ...
It looked to me as if the OP did define it. I've seen the same definition expressed in equivalent algebra here many moons ago.
p Received on Sat Feb 24 2007 - 20:28:09 CET