Re: attribute name conflicts

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 28 Jun 2007 15:34:06 GMT
Message-ID: <OxQgi.69635$NV3.50857@pd7urf2no>

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.

That intrigues me. Does that mean that you wouldn't object to the following interpretation of join?

First, assume the header of relation A is {<c,t1>,<d,t2>} and that of relation B is the same.

A:
<c,t1> <d,t2>
1 2

B:
<c,t1> <d,t2>
1 3

A JOIN B:
<c,t1> <d,t2>

1       2
1       3

This seems to give the same result as TTM's TD JOIN and I presume the same as SQL's inner or natural join.

Whereas if the header of B is {<c,t3>,<d,t2>}, with

A:
<c,t1> <d,t2>
1 2

B:
<c,t3> <d,t2>
1 3

I'm guessing that you might not object to this result:

A JOIN B:
<d,t2>
2
3

But I'm wondering if a psychological choice might also allow

(A JOIN B) = Table_Dum, or even

{A JOIN B} = Table_Dee,

as long as a dbms was consistent in its choice. Received on Thu Jun 28 2007 - 10:34:06 CDT