Re: Constraints and Functional Dependencies
Date: Sat, 24 Feb 2007 23:26:51 +0100
paul c wrote:
> mAsterdam wrote:
>> paul c wrote: >>> mAsterdam wrote: >>>> paul c 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: >> (i) >>>>>> forall R(a): exists S(b): a = b >>>>>> >>>>>> So we can express foreign keys this way. >>>>>> ... >>>>> >>>>> I presume that if S had other attributes besides b, this definition >>>>> would mean that b doesn't need to be a so-called primary key? >>>>> (That would be okay with me.) >>>> ...b should be a (candidate) key of S, ... >>> >>> My question is why? Why should b be a key of S? You could answer >>> "why not?" and I don't have a theoretical answer for that, other than >>> the possibility, as Marshall hinted at, that requiring it to be a key >>> isn't possible except on a relation-by-relation basis unless we just >>> arbitrarily state it is always so, in which case my question remains >>> "why?". >> >> Because (i) should, as Marshall stated, express >> the notion of foreign key, specifically a foreign key to S. >> I b is not a key of S, I don't see how it can. >> >> Cimode even gave a proof that it can't. >> Don't you agree? >> Is the proof flawed? >> ...
> I don't know where to look for Cimode's proof
> but I think what Marshall
> defined is what I call a "reference", which seems more general than
> Codd's original foreign key, ie., doesn't exclude the possibility of the
> reference being a key in the referenced table, if the person who
> declares the reference so desires.
Yes, a reference (I like the term) is what the (i) defines when there b is not required to be a key of S. It is not what Marshall said he intended it to define.
> I take it that you want to read
> "foreign key" literally and insist that the reference involve a key
> defined for example, the way Marshall defined a key.
No need. I think it is clear.
> If I read you
> right, that's okay by me but I think "reference" encompasses "foreign
> key" in a way that never diminishes any table a designer who wants to be
> literal declares at the same as it allows the rest of the table definers
> much more leeway.
> The term "key" is a bastard in the first place. It seems to have been
> inherited from the times when hardware recognized keys by their physical
Etymological wars are not my idea of fun. Use RM.key if you need to.
>> I think I do understand the need/wish to be able to have >> this kind of constraint. >> It would be stretching the concept of foreign key, no?
> As I suggested, I think that point of view is overly literal.
Received on Sat Feb 24 2007 - 23:26:51 CET