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

mAsterdam wrote:

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

I'm still having difficulty seeing a difference. Is this simply a distinction between extensional and intensional/intentional (Date/Celko) definitions? If I were to call myself the "authority on the creation dates which are allowed for a product in the system", I could publish my set of dates which have no time component and which are larger than 1 Jan 2005, and call that the allowable set of creation dates for the system. Would that then make "CreatedDate" a better name for a domain?

Something that might help me understand you position better might be if you gave me your thoughts on these questions: by your understanding of how domains and attribute names are (or are not) related, could two different relvars in a system each have an attribute of the same domain, and not be inherently relatable on those attributes? What about if they are the same domain and the attributes have the same name? Can you even have two different attributes with the same domain and the same name, or does this violate a rule of some kind?

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

Thanks for this. I guess the origin of my use of the term came from my intepretation of the following:

"Relations are defined over types (also known as domains); a type is basically a conceptual pool of values from which actual attributes in actual relations take their actual values. With reference to the simple departments-and-employees database [...] there might be a type called DNO ("department numbers"), which is the set of all valid department numbers" - Date, Database in Depth.

For me, the inclusion of the word "valid" in that extract suggested that check constraints and other restrictions on what is "valid" were an explicit part of what defined the domain.

 > Maybe it's best to
> just spell it out if there is room for misinterpretation.

I'm sure you're right :)

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

I have read a little about ORM, but not as much as I should have. Regardless, I think the same result comes about with the inclusion of "qualification" terms. In 11179-speak, the "class term" is the same, and the "representation term" is the same, and we know that the type (machine type + check constraints etc) should be the same. Since our attribute names are built using certain rules (iso 11179), we can determine from looking at a name which parts are qualification terms, and we can mentally exclude them if we are looking for related attributes in other relvars.

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

Thanks, yes, I did miss that. But now we have neither a class term, nor a representation term, in our attribute name. All that is left is the qualification term. Surely this would get confusing since qualification terms are not derived from class terms and therefore different classes of things may have attributes with the same qualification terms, but where the values come from entirely different domains (under any definition of domain). Are you arguing against the suggestions of iso 11179? I'm not saying that would be inherently wrong, since the real thrust of my post is not really about domains, but more a question on naming convetions :)

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

Sure, lets take the wiki example itself:

"columns on the Work_Orders table would be expressed as:

    WorkOrder_Number
    Requirements_Text
    Requesting_Employee_Number
    Approving_Employee_Number"

Here, we have two attributes which both reference a table "Employees". The qualification terms are "Requesting" and "Approving", but these do not change the fact that the values in these columns come from the domain of "Employee Numbers". When attempting to find this relationship with Employees, the qualification terms can be dropped, and we end up with a column name which is the same as the PK of Employees ("Employee_Number").

I have to say, ISO 11179 is not very clear about one point, which was a source of confusion for me. To quote the wiki entry on the WorkOrders example

"For Requirements_Text, the full name (i.e., the name that goes in the registry, or data dictionary) is WorkOrder_Requirements_Text; the Object part is omitted because it is declared in the WorkOrders table".

Given this rule, why can't we call "WorkOrder_Number" simply "Number"? Is it because we also have "Employee_Number", which would also shorten simply to "Number", and then we would have an abiguity even though the columns are from different tables? If so, then surely you have to allow for the possibility that some time in future, something else might also have a Requirements_Text, causing the same ambiguity. Or is the "WorkOrder" component of the name "WorkOrder_Number" actually part of the representative term? Is the full attribute name in the data dictionary really "WorkOrder_WorkOrder_Number", and does the representative component "WorkOrder_Number" actually reflect the domain? Received on Sun Nov 27 2005 - 03:50:26 CET