Re: attribute name conflicts

From: <>
Date: Wed, 08 Aug 2007 13:42:09 -0700
Message-ID: <>

On Jun 30, 8:03 am, "Brian Selzer" <> wrote:
> "paul c" <> 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. Received on Wed Aug 08 2007 - 22:42:09 CEST

Original text of this message