Re: Constraints and Functional Dependencies

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.

> One does not
> define foreign keys according to other foreign keys values but only to
> degree one relations.
>
> Proof:

Who cares about proofs these days ;-)
A reductio ad absurdem, no less.
Cimode++

> Consider R, S, P relation with P being the pk of R and S
(pk should be defined by now, or at least announced)
> R
> a0 a1
> 1, A
> 2, A
> 3, B
> 4, C
>
> S
> b1 b2
> 10, A
> 20, A
> 30, B
> 40, C
>
> P
> c
> A
> B
> C
>
> replaced a by a2 and b by b2
>
> forall R(a2): exists S(b2): a2 = b2 --> Satified for both R and
> P...is S a foreign key of R: no.

... because P is not really key to S. QED.

> Second reason: the formalism R(a) *may* lead to the confusion between
> relation variable and attribute...

:-)

(I noted a different possible confusion)

[snip] Received on Sat Feb 24 2007 - 20:22:33 CET