Re: foreign key constraint versus referential integrity constraint

From: Bob Badour <>
Date: Sun, 25 Oct 2009 17:07:25 -0300
Message-ID: <4ae4b001$0$23741$>

paul c wrote:

> Bob Badour wrote:

>> paul c wrote:
>>> Bob Badour wrote:
>>>> paul c wrote:
>>>>> Bob Badour wrote:
>>>>> ...
>>>>>> You asked about semantic joinability. Semantically, the join works
>>>>>> if like-named attributes have an equality comparison defined and
>>>>>> not if they don't.
>>>>>> ...
>>>>> In RT, how could they not define equality?
>>>> What reason would one have to define an equality comparison to
>>>> compare employee ids with department ids or with names? Or charge
>>>> with current or potential? Or age with price?
>>> None in theory, I thought you were talking about attributes in the
>>> same domain.
>> Nope. Natural join doesn't care about attributes in the same domain
>> per se. It compares like named attributes regardless of domain.
>> TTM explains when and how the most specific types can differ and still
>> have an equality comparison return true: they must share some common
>> supertype other than the universal supertype. In this case, the MST of
>> the join will be the most specific common supertype. If the MSTs of
>> the original relations are mutually exclusive, the body will be empty.
>> If not, the join body will consist of values drawn from subtypes of
>> both MSTs and that appear in both relations.
>> Otherwise, the body of the join will be empty and the type of the like
>> named attribute will be the universal supertype. As a type with a set
>> of values and a set of operations, the universal supertype's set of
>> values is the union of all values, and its set of operations is empty.
>> I expect most implementations would treat an attribute with the
>> universal supertype as an error, or at least complain loudly with a
>> warning.
> I can't make much comment on type theory, which I think is optional, not 
> essential to RT.  Appendix A, the relational underpinning of TTM, 
> doesn't depend on MST's or inheritance, just set membership except that 
> set equality crops up for unions of headings, as far as I can tell.  It 
> does say, eg., in the <AND> definition: "It is required that if <A,T1> 
> 'is member of' Hr1 and <A,T2> 'is member of' Hr2, then T1 = T2" (edited 
> quote).  I presume those qualified attributes are the "like named" ones 
> you mean.  While I wouldn't argue when you say "it compares like named 
> attributes regardless of domain", TTM does require that the "state is 
> set" beforehand, Appendix A uses the qualification to ensure that the 
> type for both attributes is the same.

Which still leaves Keith with the same answer: data types or domains determine the semantics of joinability. In a system that supports specialization and generalization, the attributes have to share a common supertype. In a system that does not support specialization and generalization, the types must be the same. Received on Sun Oct 25 2009 - 21:07:25 CET

Original text of this message