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

mAsterdam wrote:

> 87 Suiss franks - is the naming part freely available somewhere?

Joe C has posted extracts of it in this and other groups on occasion, and you can find some info at wikipedia http://en.wikipedia.org/wiki/ISO-11179

>> 3) The attributes have three letter prefixes, same problem as (2).
> exposing the type / domain.

Exposing the underlying type, not the domain or "representation", see more of what I mean below where I answer that question.

>> The obvious first list, using a D prefix to distinguish between the
>> domains and the attributes themselves, is...
>> DProductCode, DProductName, DProductCreatedDate, DWarehouseCode,
>> DWarehouseName, DWarehouseCreatedDate

> The type/domain doesn't care about the context - a value is either
> in the defined set or not.
> The domain/type names can/should only reflect the defined set
> of values. In these names there is context.

Yes, but this is really the heart of what I am driving at. Surely "DProductCode" and "DWarehouseCode" are different domains, the are not the same domain in different contexts, because the rules for what could be a ProductCode are likely to be different from what could be a WarehouseCode. Perhaps I have misunderstood your point here.

> DCreatedDate still holds context, so it assiociates with something
> different than just the set of values. It doesn't name the domain,
> it names something else.

By context, I guess you mean that its a "Created" date, without context it would just be a date, right?
But there are different rules for a created / inserted date than other dates you might want to store. It cannot be earlier than the installation date of the system. When the row is inserted, it has to be "now". And given the requirements of the hypothetical system, it does not have a time component. These extra rules differentiate the underlying type (date) from the domain (createdDate).

> What, to you, is the difference between type and domain?

Yes, I guess I should have made my own particular use of the word "Domain" clear at the start. There does not seem to be a standard definition, so we get in a situation where we have 3 things to talk about, being
1) The potentially infinite set of abstract mathematical values that coud potentially be used. Eg, "Integers", or "Dates". 2) The finite subset of (1) being those values that can be represented by a computer using a certain number of bits and a way of interpreting those bits. Short, long, float, datetime, etc. 3) The finite subset of (2) being those values that are "allowed" given the system specific meaning of the attribute. Eg, datetime plus constraits check no_time_component(), check greater_than_1_jan_2005()

I generally use "Domain" to refer to (3), and "Type" to refer to (2). The reason for this is that as a general programmer it is clearer to me to have 2 different terms reprsenting these 2 different things, and since I was a programmer first and a database designer second, the word "type" became linked to machine types, not database attributes.

>> This question does not refer to those attributes which form part of a
>> foreign key, because these will certainly be named the same in the
>> referencing table as they are in the referenced table 

> Why?
>
> The name of the foreign key should reflect a role.
>
> Person:
> Person.Name PersonName.
>
> Game:
> Game.Black PersonName references Person,
> Game.White PersonName references Person,
> Game.Arbiter PersonName references Person.

True, that is a complication I didn't really want to raise :) But my response to it is that what we are adding to the attribute name, here, is a "qualification term" according to ISO 11179. Hence my use of the word "implies" in "type + name implies domain" and not "type plus name equals domain". A human reading an attribute called "white person name" would presumably not have any problem understanding that a white person name is still a person name. To use a simplified counterexample, if you called it "white male name" then we have a different class term and a different domain. I guess I'm suggesting that qualification terms can regularly (but perhaps not always) be excluded when considering which domains exist, and when they can be excluded is usually clear from the semantics. Received on Sat Nov 26 2005 - 04:00:49 CET