Re: foreign key constraint versus referential integrity constraint
Date: Sun, 25 Oct 2009 19:55:34 GMT
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
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. Received on Sun Oct 25 2009 - 20:55:34 CET