Re: Constraints and Functional Dependencies

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?
>> ...

http://groups.google.nl/group/comp.databases.theory/tree/browse_frm/thread/49a8420d5421274e/cb4221de81bf66a3?rnum=11&q=Constraints+and+Functional+Dependencies&_done=%2Fgroup%2Fcomp.databases.theory%2Fbrowse_frm%2Fthread%2F49a8420d5421274e%2F8d9829b9203e3cf2%3Flnk%3Dst%26q%3DConstraints%2Band%2BFunctional%2BDependencies%26rnum%3D1%26#doc_fa1d0708d55a935b

> 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
> position.

Etymological wars are not my idea of fun. Use RM.key if you need to.

> I think nothing at all should be read into the names.

I think that is an overly structuralist point of view.

>> 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?