Re: attribute name conflicts
From: Brian Selzer <brian_at_selzer-software.com>
Date: Thu, 09 Aug 2007 03:33:31 GMT
Message-ID: <fWvui.13359$eY.12475_at_newssvr13.news.prodigy.net>
>> "paul c" <toledobythe..._at_oohay.ac> wrote in message
>>
>> news:vFwgi.68094$NV3.49519_at_pd7urf2no...
>>
>>
>>
>> > Bob Badour wrote:
>> >> paul c wrote:
>> >> ...
>> >> Did you perhaps mistype and mean: "Does it ever make sense within a
>> >> given
>> >> application (as opposed to within a given db) to have two different
>> >> *attributes with identical names* that identify different
>> >> types/domains?"
>>
>> >> If so, I would say: Yes, absolutely. While I would expect the much
>> >> more
>> >> common case is for similarly named attributes to have the same type, I
>> >> can imagine all sorts of cases where one might use the same name for
>> >> different types of things.
>>
>> >> Capacity might mean a volume in one case, a weight in another case and
>> >> stored energy in a third case.
>>
>> > 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.)
>>
>> It would indeed be malformed. An attribute name denotes a role that a
>> particular domain plays within a relation. A natural join (which is what
>> I
>> assume you are referring to by A JOIN B) joins relations on a common set
>> of
>> role-qualified domains, but Capacity in the operands A and B do not draw
>> their values from the same domain. Assuming that A and B do not share
>> any
>> other attributes, the result should therefore be the product of A and B,
>> but
>> the role names in the product would not be unique, so the result would
>> not
>> be valid.
>>
>> It should be noted that if attribute names are unique throughout the
>> database schema, that is, if the scope of the name of an attribute is
>> extended from denoting a role that a domain plays within a single
>> relation
>> to denoting a role that a domain plays throughout the entire database,
>> then
>> the expression "A JOIN B" would always be a valid expression (provided,
>> of
>> course, that relation schemata A and B are defined).
>>
>> > p
Date: Thu, 09 Aug 2007 03:33:31 GMT
Message-ID: <fWvui.13359$eY.12475_at_newssvr13.news.prodigy.net>
<Doug_McMahon_at_yahoo.com> wrote in message news:1186605729.019646.115780_at_e16g2000pri.googlegroups.com...
> On Jun 30, 8:03 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "paul c" <toledobythe..._at_oohay.ac> wrote in message
>>
>> news:vFwgi.68094$NV3.49519_at_pd7urf2no...
>>
>>
>>
>> > Bob Badour wrote:
>> >> paul c wrote:
>> >> ...
>> >> Did you perhaps mistype and mean: "Does it ever make sense within a
>> >> given
>> >> application (as opposed to within a given db) to have two different
>> >> *attributes with identical names* that identify different
>> >> types/domains?"
>>
>> >> If so, I would say: Yes, absolutely. While I would expect the much
>> >> more
>> >> common case is for similarly named attributes to have the same type, I
>> >> can imagine all sorts of cases where one might use the same name for
>> >> different types of things.
>>
>> >> Capacity might mean a volume in one case, a weight in another case and
>> >> stored energy in a third case.
>>
>> > 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.)
>>
>> It would indeed be malformed. An attribute name denotes a role that a
>> particular domain plays within a relation. A natural join (which is what
>> I
>> assume you are referring to by A JOIN B) joins relations on a common set
>> of
>> role-qualified domains, but Capacity in the operands A and B do not draw
>> their values from the same domain. Assuming that A and B do not share
>> any
>> other attributes, the result should therefore be the product of A and B,
>> but
>> the role names in the product would not be unique, so the result would
>> not
>> be valid.
>>
>> It should be noted that if attribute names are unique throughout the
>> database schema, that is, if the scope of the name of an attribute is
>> extended from denoting a role that a domain plays within a single
>> relation
>> to denoting a role that a domain plays throughout the entire database,
>> then
>> the expression "A JOIN B" would always be a valid expression (provided,
>> of
>> course, that relation schemata A and B are defined).
>>
>> > p
> > Not if A and B are the same table. Consider Employee joined on > Manager to itself. > You will be forced to alias columns to ensure a distinct name is given > for every > result column. >
The result of a natural join of a relation to itself is the relation. In order to join on only some of the attributes, you have to rename them, and then you're not joining the relation to itself. You're joining a derived relation to the original relation. Received on Thu Aug 09 2007 - 05:33:31 CEST