# Re: Constraints and Functional Dependencies

Date: Sat, 24 Feb 2007 20:22:33 +0100

Message-ID: <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).

> 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