| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: Attribute name prefixes, domains, joins, ISO 11179
archon wrote:
> 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.
Better, yes, but still bad. Which calendar do you use? With dates the ownership is more problematic than with codes. Who decided that you would be the authority?
Let's assume that those issues are settled:
Which aspects of the domain do you/we want
to see reflected in the domain name?
First think about that and then see if you
can fit those into the scheme of things promoted
by the naming standard.
> 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?
From an imaginary building consortium:
==table.column== ==type==
Loan.Intrestrate Percentage
Roof.Slope Percentage
> 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?
==table.column== ==type==
Loan.Intrestrate Percentage
Deposit.Intrestrate Percentage
>> Well, this is what the c.d.t. glossary currently says:
Using check constraints is one possible way of limiting the values to the set, defined by the domain.
> > Maybe it's best to
>
>> just spell it out if there is room for misinterpretation.
>> 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.
Disclosure: I didn't read much about ORM as it is now.
I read and was lectured about NIAM (Nijssens Information Analysis Method) in the 80's - and the 'role' concept stuck. Later I saw the ORM site and thought: Hey! This looks like NIAM. Reading on I found that ORM is NIAM's current incarnation.
> 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.
I never worked with a fully staffed metadata registry in place, but what you say looks feasible to me.
>> 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.
No, I don't know enough about ISO 11179 to argue for or against any of it.
I did spend some time on (thinking about and actually) naming things. In your OP I saw some dark spots I thought I could shed some light on.
>
>>> 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?
Which part of Requesting_Employee_Number, and of Approving_Employee_Number is the required (WorkOrder.) Property part?
Because you did not create the example yourself, you may find difficullty answering that. I'ld really like it more if you'ld come up with your own example.
> 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").
Let's interpret: Requesting_Employee_Number must denote the Employee who requested the workorder (or is in the process of requesting, see below).
Skipping '_Number' does not harm this interpretation: Requesting_Employee would still be interpreted as 'the Employee who requested the workorder', but - moving away from semantics for now - the Employee table could have multiple candidate keys so '_Number' might be necessary to disambiguate.
This makes _Number a qualifier term in the sense that it is "necessary to uniquely identify a data element" (ISO/IEC 11179-5:1995 (E) p 8 under 'qualifier term').
If somebody named it this way and we have to proceed from this - I'ld say so be it, I've seen worse.
However, if we are still in an earlier stage (say design for datacommunication) I would still have some remarks:
There is a difference between Approving and Approved. When it's 'Approving' do we really know whether the workorder has actually been approved by this entity? No, it could denote the entity to which the workorder has been sent to for approval.
Again, it's not your example, so it's hard to be sure what we are talking about.
If both are relevant 'Approved' denotes a more important data element than 'Approving', so in the example I'll assume that is what is meant.
I would try to purify to:
WorkOrder_Number
Requirements_Text
Requested_by_...
Approved_by_...
for _... find some agreed representation of any entity that can request or approve workorders in both our companies. This leaves out more assumptions about the database structure. (If both companies are really sure these workorders can forever only be requested by Employees, ok.)
> 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"?
Given this rule we can.
> 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 - 06:05:11 CST
 |
 |