Re: attribute name conflicts

paul c wrote:
> Bob Badour wrote:
>

>> paul c wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> paul c wrote:
>>>> ...
>>>
>>> ...
>>> Thanks, yes I did mis-type and meant it the way you put it.
>>>
>>> Regarding "capacity", I think I'd prefer for an app to use the three 
>>> different names: "volume", "weight" and "energy".  My main reason 
>>> (psychological) would be that I find it helpful to have as much 
>>> transparency as possible (as one might gather from reading my 
>>> frequent mis-typings) but a technical reason might be that then I 
>>> wouldn't need to deal with "exceptions" (I presume that an expression 
>>> like "A JOIN B" where A and B use the "capacity" attribute name for 
>>> different types would, in the purest sense, be considered not 
>>> well-formed, ie., it would not be strictly logical to give a result 
>>> such as "empty" or "false" for such an expresssion.)
>>
>>
>>
>> Whether such a join would cause an exception is a matter of applied 
>> psychology and not theory.

I should admit that this "psychological result" seems a little devious to me and I oughtn't to be so sneaky (or you might say I oughtn't to be so confused).

To try to explain, let me phrase the above in terms of predicates. Suppose A's predicate is "Supplier c of type t1 supplies Part d" and D's is "Supplier c of type t3 supplies Part d". The predicate of A JOIN B above might seem to be "Some Supplier c of type t1 supplies Part d OR Some Supplier c of type t3 supplies Part d". Or even "Some Supplier of unknown type supplies Part d".

But this seems obscure, actually worse than obscure, it seems mystical as far as the dbms is concerned. While a user might wilfully choose to interpret A JOIN B this way, they could also choose the join to mean "Some Manufacturer makes Part d", which seems a little silly, given the starting predicates. I think any app that doesn't assume agreement among users of its predicates must be inoperable.

It also seems contrary to the conventional conjunctive meaning of "and" because it introduces that "OR" to the result's predicate.

Whereas if A.c and B.c are of the same type, the predicate of A JOIN B could reasonably be "Some Supplier A.c supplies Part d and Some Supplier B.c supplies Part d and A.c = B.c", in other words "Some Supplier c supplies Part d". I couldn't fault a user who was aware of the predicates for both A and B for interpreting the join this way. Nor for saying "There is more than one supplier for Part d". But if the predicate of the join is that there is more than one supplier for Part d, I would think the result of the join ought to be empty.

If that is reasonable, it brings me to wonder what the header of the (empty) result ought to be. If the result is to be a single relation, I think it clear we can't show values in it for both A.c and B.c, so the header would have to have either the single attribute d or no attributes at all. Having no attributes seems to me to be a rather twisted way of thinking. For me it is like converting the query from one that is (at least partially) ABOUT Part's to one that is ABOUT a Query that is about Part's, a kind of second-order interpretation if you will. It seems to me that the intent of the query involves Part's (as well as a couple of other things - those two kinds of Supplier's and the result should aim say as much about as those things as it is possible to say in a single relation. This argues that it is reasonable for the result to have the single column named b, which is empty.

I also think I shouldn't have suggested Table_Dee or Table_Dum as possible answers since I think they are answers to a different query, one that might be "is the result of the join true or false?", not "what is the result of the join?".

Sorry this was so long, but it's where I'm lead once I make the "psychological" choice to try to avoid exceptions.

p Received on Thu Jun 28 2007 - 19:50:13 CEST