Re: Domain Definition

From: D Guntermann <guntermann_at_hotmail.com>
Date: Fri, 10 Jan 2003 21:23:26 GMT
Message-ID: <H8Ior1.8K0_at_news.boeing.com>

David,

Thank-you for your response....

"David Cressey" <info_at_dcressey.com> wrote in message news:mjgT9.18$Ep2.3088_at_petpeeve.ziplink.net...
> > Should a domain or collection of values be defined solely based on a
> default
> > system representation of values independent of associated meaning, or
> should
> > semantics of the values also play a part in determining and partitioning
> > domains?
>
> I think that semantics should be considered. In particular, if comparing
> two values is not meaningful, because of the semantics of the underlying
> subject matter, then the two belong in separate domains. If comparing
two
> values is frequently done, in the normal course of acting on the data,
> it's useful to treat them as coming from the same domain, if possible.

I tend to agree. But then let me pose this problem:

Suppose that a boolean type is available in some specific DBMS. This type has a domain of values that mean true/false (or alternatively expressed yes/no).

Now I define two relation (schema/variable/intention)s that incorporate this domain as part of the definitions of both the attribute in the heading and attribute value in the body of the relations:

EMPLOYEE(emp_id:emp_id, weight:integer,
canjumpononefootwhilewhistling:boolean,
PK: emp_id);

ISSUE_MESSAGE(msg_id:msg_id, pn:part_number, quantity:number, processed:boolean,
PK: msg_id);

Now some would state that the domain is based and should be based on type with a set of allowable/permissable values being either true of false, with a set of operators. But if I understand your response correctly, instead of defining a domain based on the fact that it is of type boolean, all of which give an indication of true of false for some state or proposition, you would define and specify the domain of the canjumpononefootwhilewhistling and processed attributes of the two relations across two differing domains? What would they be? I could see several various alternatives:

1. BooleanDomain = {true, false}
2. EmployeeCanDoIndicator = {can do, can't do} -and- IssueMessageStatesDomain = {processed, not processed} (though the type representation would actually be expressed as either true of false)

If you are indeed recommending something to the effect of defining domains similar to what is stated in 2), then wouldn't this pose problems if perhaps my database evolved to include a Return_Message relation that also had a process_state. One would have to determine whether process states of various message would be or should be compared/comparable (which I take to mean equivalant) in relation to meeting users' needs.

I imagine that if designers determine that the domain is indeed different, then a third domain would be required, even the the type (true or false) is the same.

3) EmployeeCanDoIndicator

     -and-
     IssueMessageStateDomain
     -and-
     ReturnMessageStateDomain

Otherwise, the IssueMessageStateDomain could be generalized....

4) EmployeeCanDoIndicator

     -and-
     MessageStateDomain

 with both the IssueMessage and ReturnMessage tuples being defined on a set of domains, one of which would be MessageStateDomain.

However, for 3) above, union compatibility would require that domain/type be the same for the process state flag. How can I say with a straight face that they are of the same type, but of different domains? In practice (versus theory), I see examples every day where there can be serious ambiguities in domain definition.

Greater elucidation would be greatly appreciated.

>
> Your example with DomaA and DomB is unclear in this regard.

I'm sorry you found the examples unclear. My question actually stems from a recent review of Peter Chen's "The Entity-Relationship Model-Toward A Unitified View of Data". In it, Chen notes that the semantics and role of the notion of the attribute in the ER and relational models are not exactly the same. Although I believe the differences are not that great, in Part 4 - An Analysis Of Other Data Models And Their Derivation From The Entity-Relationship Model, Chen notes that the same domain specified across two or more base relations might have different semantics that are not fully qualified or distinguished (this is not a problem for domains being specified in the same relation) like they are in the ER model. He thus seems to decouple, but link, the concept of type/domain from the concept of role/semantics. I am merely trying to reconcile the seeming inconsistency.

Refer to Chen's NO-OF-YEARS example and his observations and comparisons of how this pariticular attribute/domain is treated between the relational model and the ER model. In particular, he questions the treatment and comparison of the NO-OF-YEARS domain (set of values) when comparing EMPLOYEE and SHIP relations/conceptual entities.

> Let me take a
> different example.
>
> Social Security Numbers and Zipcodes can both be treated as 9 digit
numbers,
> if you disregard the hyphens.

Ouch, what about leading 0's...Do we really need to use numeric operators on the member values? The last thing I would do would be to define either as a number from either a logical or physical representation perspective...but that is neither here nor there.

Should they both be referred to a common
> domain, the domain of 9 digit numbers? My answer is no. I claim that
> referring them to the same domain obscures, rather than clarifies, the
> connection between the data and the subject matter.
>
>
I would again tend to agree, In fact, Fabian Pascal recently views on a related topic that run along similar lines. See "On the Distinction Between Domains (Model) and Representation (Implementation)" at http://www.dbdebunk.com. (http://www.pgro.uk7.net/domain_rep_0105.htm). But then when I take the definition of a domain in its strictest sense, the example given above would be restricted to a single domain of BOOLEAN, especially given the lack of support for type that is evident in today's SQL DBMS systems.

Thanks again, David.

Warmest Regards,

Daniel Guntermann Received on Fri Jan 10 2003 - 22:23:26 CET