Re: domain questionnaire

Hi Jan,

> Before I begin with my remarks, first let me say that I'm a big fan of
> ORM and think it's one of the best data models around. So if I may
> sound a bit critical it's not because I'm trying to show that ORM is
> just another dialect of the ER model. I know it may have sounded as if
> that is what I said but all I said was that "it can be roughly
> described" as a dialect. So let me add to this that it is certainly not
> the case that ORM is *just* another dialect. There is really much more
> to it than that.

OK, I forgive you. <s> They are certainly both techniques for modeling data. Further, the ER model can be completely derived from the ORM, so there is a relationship.

In fact, you could call ER a dialect/derivative of ORM. <s>

> Which can be bug and a feature IMHO. I remember talking to some system
> analysts who thought it was great that they wouldn't have these lengthy
> discussions anymore about whether something was an attribute or an
> entity. But others disagreed and said that this was exactly what they
> didn't like about it because now their schemas would be cluttered with
> these relatively unimportant attributes.

They could be toggled off, much like how ER tools suppress attributes. The thing is, you are modeling a Universe of Discourse and in so doing, lots of "unimportant attributes" do need to be modeled. Whether or not they are displayed is another matter. Pragmatically speaking, page separation works well for this, particularly with ORM where you can have "important" facts on one page and "less important" facts on another.

> > In fact, because ORM value types cannot play functional roles, and it
> > is functional roles that determine mapping, ORM value types can never
> > map to ER entities, only as ER attributes. However, the converse is
> > not true.
>
> I'm afraid you've lost me here. What does it mean that 'value types
> cannot play functional roles'? Surely there can be fact types between
> entity types and value types? I don't even see a reason to forbid fact
> types between value types.

Yes, there can be facts between Entity types and value types. There cannot, however, be functional roles from value types to any type (entity or value). A (imprecise) definition is in order:

A functional role, for a binary fact type, is one that has a one-to-many uniqueness constraint. The object on the unique side (the "1" side) is said to be playing a functional role with the object one the non-unique (the "many") side. In this case, the Entity type can have one Value type, but the value type can be with more than one entity type. Why this is important is below.

> And why do you say that I cannot map value types to ER entities? I
> don't see what the use of such a mapping would be, but that is
> something else than saying that it cannot be done.

It is because value types have no semantics, just a value (number, character, date).

3

3 what? 3 degrees Celsius? 3 as a password? 3 as a number of children? March (3rd month)? C (3rd letter)?

Once you assign semantics to a value, it is an entity type. In fact, that was my previous point about reference modes. All entity types have a reference mode. Those reference modes could be a functional role to a value type. (I say "could be" because reference modes could be facts with other entity types, or composites of more than one fact, but for now, we'll consider the simple case.) And that is how you get the semantics.

The Sex(code) entity type is realized by the fact, Sex is identified by SexCode(). The semantics are not only in the object name (Sexcode) but also the predicate (is identified by).

In the ORM training course, we use the following example:

Two entity object types (among many) on the example are City(Name) and Person(Name). A sample City is named Darwin. A sample Person is named Darwin.

Since object types are, by definition, exclusive (no person can be a city), you are not allowed to ask the query, "Which Person is a City?" It is allowed to ask, "Which Person has a name that is also a City name?" (e.g. the string "Darwin")

Those semantics are extremely important. In the query, you are comparing the value types (in this case, the strings), not the entity types. It is the entity type that ensures whether or not it makes sense to perform the operation on the value types.

For example, you wouldn't want to add the orbital period of the earth about the sun to the percentage of water on the earth (the units don't match, you'd get over 100%, the resulting number means nothing, etc.). Aside from generating a number, that operation makes no semantic sense, and that is what the entity type does for you.

At the risk of eliciting groans, this keeps you from doing queries between the Apple(name) object and the Orange(name) object. <g>

As a side note, Entity types are effectively domains, while value types are, well, types. ORM handles domains; SQL (generally) handles types. And that causes problems, too.

> > Take for example, "Person(SSN) is of Sex(Code)". Both are ORM entity
> > types.
>
> Are they? I think you could also argue that 'sex code' is a value type
> and there is a fact type "Person(SSN) has Sex-code()". This is very

See my above comments on reference modes being facts themselves. Further, yes this is possible. However, only if it plays no functional roles. I realize I just made a circular argument. <s>

Again, it comes down to semantics. Values are just values, absent of semantics other than their value (e.g. "February 26, 2001").

> similar to (if not in fact the same to) the discussion in ER about
> wheter there should be an entity type Sex with attribute 'code' or
> whether 'sex code' should be an attribute of the entity type Person.

It ends up mapping to the same results, but I aver that it is not the same consideration.

In ER, you make an "arbitrary" decision as to an element's importance. In ORM, an element is just in facts with other elements, and the uniqueness constraints on those facts determine the element's importance (generally speaking, non-functional roles end up as "attributes")

I quoted "arbitrary" because it is theoretically arbitrary. In reality, the modeler, thinks about the possible functional roles the element may play and if it plays any (or if the modeler thinks it might), it becomes and entity. ER modelers would use different terms to describe this decision, but, in essence, that is what is being decided.

And that is why it is possible to make good models with ER; the modeler knows what they are doing. My argument is: good ER modelers are thinking about it just like ORM does -- whether they admit/realize it or not -- so why do it the hard way?

> > Now let's add another fact, "Sex(Code) abbreviates Sex Name()". Sex
> > Name() is the un-abbreviated string (e.g. "Male, "Female") ORM value
> > type.
>
> Well, when using an ER model I would add an extra derived attribute
> 'sex name' to 'Person' and indicate how it is derived. That's not
> something that would rob me of my lunch time. :-)

That's true, but then you'd have to add derived attributes between all associations that could be made via join/query, eh? <g>

Kind Regards,
Scot.

Partner, InConcept, Inc.

     http://www.inconcept.com

Editor, The Journal of Conceptual Modeling

     http://www.inconcept.com/JCM Received on Tue Feb 27 2001 - 02:30:56 CET