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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 26 Nov 2005 20:16:45 +0100
Message-ID: <4388b47f$0$11069$e4fe514c@news.xs4all.nl>

incog_au wrote:
> 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

And they even provide links to the ISO PDF's, great. Thank you.

>>> 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.

Earlier confusions around the terms 'type' and 'domain' in this group have lead to a list of common usages in the glossary.
See below.

>>> 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?

What's that, just a date? 'Just' appeals to some common understanding we have about it - and I claim we have that common understanding. It very effectively facilitates us to communicate about dates.

I also claim that that common understanding is not enough to have our (your and mine) automated systems communicate with eachother about dates.

I just :-) state that DCreatedDate is a bad name for a domain because being involved in a creation event does not in itself have any effect on what values are or are not in the set. It is bad because it suggests it does.

ProductCode and WarehouseCode are different fish. Make sure the ProductCode authority and the WarehouseCode authority publish the respective Codes. These authorities own the sets of values. I have no objections to these names as names for domains.

> 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.
>

Well, this is what the c.d.t. glossary currently says:

---

> [Domain]
> 1. Given a relation R, a domain is a set Sn such that
> for each tuple (A1, A2, ...An, ...Am) in R,
> An is an element of Sn.
>
> 2. A domain is a set of values: for example
> "integers between 0 and 255",
> "character strings less than 10 characters long",
> "dates".
> Sometimes used synonymously with type.
...
> [Type]
> " TYPES are sets of things we can talk about;
> RELATIONS are (true) statements bout those things."
> -- Chris Date, feb 2004
>
> 1. Set of possible values (i.e. IT equivalent of math 'domain').
> 2. Set of possible values plus
> all possible operators defined on them. (i.e. synonymous to Class
> if 'class' is meant to include a possible set of values).
>
> This is highly misunderstanding-prone area, so please
> take some care to be specific.
>
>
> [Type - 3rdM]
>
> In The Third Manifesto a type is:
> - a pattern (possible representation)
> - a domain for some operators (THE_xxx operators)
> - a codomain for some operators (the "constructors")
>
> There is a requirement for the 'domain' and the 'codomain'
> to be the same set.

---

Differentiating between (your numbers) (2) and (3) with type for (2) and domain for (3) is not going to get accepted, I suspect. I've heard 'basic types' used for (2) and UDT (user defined type) for (3). Personally whenever I see 'domain' I first think of (1). Maybe it's best to just spell it out if there is room for misinterpretation.

>>> 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 :)

What complication? Complication of what?

You stated that
"those attributes which form part of a
foreign key" ... "will certainly be named the same in the referencing table as they are in the referenced table" This practise causes trouble whenever there are more than one foreign keys between two tables. The practise of basing the name on roles avoids that trouble - it never arises.

> 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.

In the example 'PersonName' is meant to denote the type (UDT). The tables are Person and Game (should be Persons and Games if we go with the wikipedia interpretation of ISO 11179). The columns are Name, Black, White and Arbiter. The type (PersonName) is /not/ part of the column name.

Maybe you did not see
>> Both the type and the attribute have a name here. (you snipped it).

> 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.

Could you give a more explicit example? Received on Sat Nov 26 2005 - 13:16:45 CST