Re: Constraints and Functional Dependencies

From: paul c <>
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?
> ...

I don't think it is the same, rather it is the opposite - I don't think the definition assumes any keys at all. As I said, that's okay by me.

> 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

Original text of this message