Re: Attribute name prefixes, domains, joins, ISO 11179

mAsterdam wrote:

>> I assume that no meaningful join of Loan and Deposit can be made on
>> InterestRate, but if that's the case, then are these attribute names
>> misleading? 

Misleading with respect to the suggestion that the columns are meaningfully joinable since they have the same name and type.

> Not all things possible are meaningful. Or is that to simpleminded?

True enough. But to me at least, it's not just possible, it's suggestive.

>> wrong there. In any case, the same arguments about "dropping the term
>> is allowed (but not always required!) in order to find relationshps"
>> still applies.

I mean that given the iso breakdown of
"class/qualifier/property/representation" we can look for "probably related" columns if they have the same class and representation term, regardless of qualifier and property term.

> I never worked with sql server. Doesn't it have schemas ?

Not sure what you mean by schemas here.

>> and not lose any information. But I'm not so sure about that.

That's correct, yeah. In other words, I think the name "Widgets.Nbr" conveys less information than "Widgets.WidgetNbr". The former only tells us that the number attribute is one of the attributes on the Widgets table. You might be able to have a "Nbr" even if you dont have a widget. The latter tells us that not only is the attribute on the widgets table, but it is also part of the widget class of thing. You cannot have a "WidgetNbr" without a widget.

> What do you mean with "owned" in this context?

As above, "X owned by Y" = "X cannot exist without Y". I'm not talking about the existence of the column itself, since that would be a truism: clearly the widgets table as we have chosen to define it cannot exist without the attributes we have chosen to give it, otherwise it wouldn't be that table! Rather, I'm talking about the logic that tells us what we can and cannot choose as attributes. You can't have the "WidgetNbr" attribute in any table unless you have a widget somewhere (where "somewhere" might not even be in the database, but it must exist in the universe we are trying to model). You can't have the PaintCode attribute in the Widgets table unless you have Paints somewhere. Hence any PaintCodes in the database belong to the "Paint" class of thing.

> Hm.... if you go form columname 'Nbr' to attributename by prefixing the
> singular objectname 'Widget' - why don't you do the same for
> TopHalfPaintCode to get WidgetTopHalfPaintCode?

Because that suggests the paint code is part of the widget class of thing, but you can have paint codes without widgets.

> There is another interpretation to this:
> The object you are painting is not the Widget, but another object
> (which for convenience does not have a seperate table in your
> database), namely the Widget_TopHalf. What is a part and what
> is a whole depends on point of view.

Good point.

>> "WidgetTopHalfPaintCode", which would contradictingly contain two
>> different class terms ("Widget" and "Paint").

The "rule" I'm referring to is just the 11179 standard, which to me suggests that a name can only have one Class Term.

>> I'm sure number is a representation term in this example. It gives us
>> some idea of what kind of values will be in the column. I would
>> interpret a "number" attribute to be an identifying attribute, so
>> either a PK, CK or FK column, with alphanumeric data on which math
>> operations are invalid, but which can be sorted in a meaningful order.
>> Invoice number, contract number, etc.

The attribute name isn't just for machines to interpret, it's also there to help people who are not familiar with the database understand what is being stored within it. The Representation Term does not replace the domain/type definition, it just helps us to understand at a glance what kind of values we will find in that column.

>> But does that make sense? Given that number is usually indicative of a
>> key attribute, and if we are using such keys in a system, you'd end up
>> with a whole bunch of attributes in different relvars all called just
>> "number". How would you know which joins were meaningful?

No, for the purpose of the discussion I'm only interested in attribute names from a human's point of view. And what you say is true, a human could select from the table if they wanted to see the kind of values stored in an attribute, and they could read the table definition to discover which attributes were the foreign keys. Indeed they could disambiguate any attribute of any name by checking all of the type definitions, external predicates, etc. But this doesn't mean I would be justified in calling my tables "T1, T2, Tx" and my columns "C1, C2, Cx" just because a human could, with enough work, decode what it all meant. Clarity is the objective here. Received on Wed Nov 30 2005 - 03:27:32 CET