Re: domain questionnaire

Hi Jan,

> As far as the absence of attributes is concened, I am still not very
> sure whether that is really true. In some sense ORM does have
> attributes but they call them fact types between lexical and non-lecial
> object types, but these are drawn in the same way as other fact types.
> So in that sense you only have relationships/fact types and no
> attributes.

ORM's distinction of LOTs (lexical object types) and NOLOTs (non-lexical object types) -- or better yet, 'entity' types and 'value' types -- has more to do with the reference scheme of the object type than its relative importance (entity or attribute, in ER parlance).

(Because of the constant re-use of "entity", "attribute", and object in the computing industry to mean slightly different things, please forgive my explicit notational referencing below.)

ORM entity object types are identified by a ORM value object type. ORM value object types are identified solely by their value (e.g. string, number, date, opera aria, et al).

For example, take the ever-so-trivial fact, "Person(SSN) has Middle Initial". The capitalized terms are ORM object types, the "has" makes up the forward reading of the fact predicate. The term in parenthesis (SSN) is the reference mode. The lack of a reference mode on the "Middle Initial" ORM object type indicates it is a ORM value object type. Explicitly, we could write it as, "Person(SSN) has Middle Initial()" to mean the same thing.

As a side note, reference modes are actually fact types (e.g. "Person is identified by SSN()", where Person is an ORM entity type, and SSN is a ORM value type, and there is a special uniqueness constraint on this fact to indicate that SSN is the reference mode for Person).

When determining reference schemes, you have to think about how you would distinguish one instance of the ORM object type from another. People, as physical beings, can be distinguished from each other (although not always by appearance).

However, a person is an abstract concept in a data system. We cannot actually shove a person into a MS SQL Server table (although, depending on how bad of a day one was having, that might be a cool feature <g>). Thus, we come up with an alternate reference scheme, such as Social Security Number (SSN), Employee ID, whatever.

Now, as to Middle Initial object type, how does one identify one instance of a middle initial from another? Solely by its value. Mine is "A", someone else's is "G", and so on. The (in this case, string) value itself identifies the object type, and thus, no other reference mode is needed.

Therefore, Person is an ORM entity type, and Middle Initial is an ORM value type. Further, in this case the ORM entity type would map as an ER entity and the ORM value type would map as an ER attribute of the Person ER entity. More specifically, the ER entity Person would have two ER attributes, SSN (key) and Middle Initial.

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.

Take for example, "Person(SSN) is of Sex(Code)". Both are ORM entity types. The Sex ORM object type is referenced by a Code (e.g. "M" and "F"). Given only this fact and the above fact, we would get on ER entity (Person) that now has three ER attributes (SSN, Middle Initial, and Sex Code). Thus, the ORM entity object type mapped as an ER attribute.

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.

The addition of this fact to the mix now gives us (read: maps to) two ER entities (Person and Sex) who have ER attributes SSN, Middle Initial, Sex Code and Sex Code, Sex Name, respectively.

Because of its functional role with Sex Name, the Sex ORM entity type now maps as an ER entity. Because of its (that is, Sex's) non functional role with Person, an ER relationship is mapped between the two ER entities (on a physical level, this would imply FK's and so on).

Now... (Pausing to mount my soap box)

If one was modeling in ER, and the first two facts came along, the (perhaps given these trivial examples, inexperienced) modeler might be tempted to create one ER entity -- "Person" -- with a PK of "SSN" and a "Sex Code" (ER) attribute.

Then, a month later, the user says, "Oh... you know what? <Insert some name of a person you don't like here> in <insert the name of a department you don't like here> is a bit dense, and doesn't understand that "M" really means "Male" and "F" really means "Female". So, could we actually _spell out_ the sex on the drop down thingy in this screen?"

Always aiming to please, the ER modeler returns to his/her desk, creates the Sex (ER) entity, adds the ER attributes, removes the Sex Code from the Person (ER) Entity, adds the relationship between Person and Sex, and so on.

Also aiming to please, the ORM modeler simply adds the new fact ("Sex(Code) abbreviates Sex Name()") and leaves for an early lunch -- after stopping by to invite the ER modeler along (ORM modelers, by nature, are exceedingly friendly... and like lunch).

Sadly, the ER modeler is too busy changing his/her model to come along and has to eat another one of those terrible vending machine sandwiches at his/her desk.

<eg&duck>

HTH,
Scot.

Partner, InConcept, Inc.

     http://www.inconcept.com

Editor, The Journal of Conceptual Modeling

     http://www.inconcept.com/JCM Received on Sat Feb 24 2001 - 18:20:18 CET