Re: attribute name conflicts

On Jun 27, 9:30 am, paul c <toledobythe..._at_oohay.ac> wrote:
> paul c wrote:
> > Does it ever make sense within a
> given appl'n to have two different relations that use the same attribute
> name but with different types?
>
> p

It's common practice, though it's never *necessary*. What *is* necessary is to have multiple attribute names that draw values from the same domain. Use cases are easy to find; for example, on an order I want to keep track of the Shipped_Quantity and the Ordered_Quantity as distinct values, even though both are bound to a common domain, Quantity. Cases involving view columns are also easy to produce, for example any situation where a self-join is involved, e.g. if I join Employee to itself along the Manager foreign key, inevitably I will have a potential conflict of attribute names if I'm stuck using a single name in all circumstances for a particular domain. I suspect it is these use cases that led Codd to distinguish attribute names, which are effectively member names with meaning only within the scope of a relation. Another way to think about it is to consider programming languages such as Java; the domain name is like the type name, whereas the member name can be almost anything so long as it doesn't collide with another member name in the same scope. Once you accept that your column names are the equivalent of member names, there is no a priori reason *not* to re-use a member name with varying domains in different tables of the application. Received on Wed Aug 08 2007 - 22:23:42 CEST