Re: foreign key constraint versus referential integrity constraint
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 25 Oct 2009 17:07:25 -0300
Message-ID: <4ae4b001$0$23741$9a566e8b_at_news.aliant.net>
>> 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.
Date: Sun, 25 Oct 2009 17:07:25 -0300
Message-ID: <4ae4b001$0$23741$9a566e8b_at_news.aliant.net>
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