The ORM Foundation

Being new to ORM I am wondering if it is possbile to make ORM value types redundant? Having read http://www.proace.com/2010/02/17/orm-basics-entities-values-roles-and-facts/, I do understand there is a difference between value and entity types in the UoD, but is it really needed?

Why not have one object type, draw values and entities the same and let users interpret which object type (value/entity) it is.

Hi Michel,
You ask a very good question. So why should we bother to have value types and entity types?
Before I answer that question, I'd like to comment on the part of your suggestion that relates to "user interpretation".

michel:

let users interpret which object type (value/entity) it is.

Object-role models are formal models. In other words they are intended NOT to be "open to interpretation" in the way that you mention. When a modeler builds an object-role model the role of the user is to "validate" the model rather than to "interpret" the model. That's why ORM tools have a "verbalizer" that can display logically consistent sentences constructed from one or more facts. This technique means that the user (we use the term "domain expert") is then presented with the option of reading the verbalized fact and saying either "Yes, that is a true fact" or "No, that is not a true fact". If the domain expert rejects the verbalization, then the modeler changes the model until the domain expert agrees that the fact in question is "a true fact".

Now to the difference between entity types and value types.
On pages 65 & 66 of Terry Halpin's 2008 "Big Brown Book" he explains:

"A value is a constant that is self identifying in the sense that when you see the constant written down in some context, you always know what is being referred to. As a result, values can be referenced directly without needing to itentify them with a description."

"Conceptually, an entity ... is referenced in an information system by means of a definite description."

As an example, consider the fact Person(name) has Height (inches).
In this fact, "Person" is an entity and "Height" is a value.
Let's look at two instances of this fact:

Bob has height of 182 inches
Mary has height of 172 inches    

In this context, you might reasonably ask "Who is Bob?" or "Who is Mary?"
However, you are not likely to ask:  "What do you mean when you say height of 182 inches? because most people know what "height in inches" means.

Hope this helps.
Ken       

Dear Ken,

Thanks for answering this quickly! Please let us discuss further. Taking your example, what would be invalid, if I were to make "height" an entity type? Besides *being open to interpretation* and a different notation (dotted lines), what would be different (in the output of ORM)?

Michel,

By making "height" an entity type, you would be implicitly saying that you could point to something and say "Look at that Height".
This is not logical because "height" is a property of something else. Height is not something that exists independently of the thing that has the property of "height".

michel:

and a different notation (dotted lines), what would be different (in the output of ORM)?

More than a notation
ORM is not "just a notation" as your question seems to imply.
ORM is a way of representing statements in first order predicate logic in a graphical form.
The basic component of an object-role model is the "elementary fact" which is made up of objects playing roles with respect to each other.
So, ORM's graphical model is itself a representation of a set of elementary facts and related constraints.

Regarding the "output" of ORM:
The graphical model itself is an "output" of the ORM modeling process and an "output" of the facts in the underlying object-role model.

Ken

Ken Evans:

On pages 65 & 66 of Terry Halpin's 2008 "Big Brown Book" he explains:

Terry Halpin:

"A value is a constant that is self identifying in the sense that when you see the constant written down in some context, you always know what is being referred to.

When I see the character sequence '12/04/2010', I don't know whether I'm seeing just a string, or a representation of a date (and which date? 12th April or 4th December?). Here, it's the *context* that makes it clear; the character sequence doesn't tell me that I'm seeing a date, it merely tells me which date I'm seeing, given that I already know from the context whether American or European date formats are being used.

michel:

what would be invalid, if I were to make "height" an entity type?

Nothing would be invalid, as long as you provide a way to distinguish one height from another. There is no intrinsic identity for a height, or for any other entity type.

When you model height as a value type, say representing it as a real number, written in a certain numerical notation, and interpreted in metres, that notation provides the identifier which distinguishes one height value from another.

If you wish to model height as an entity type, you must still provide a means for distinguishing one height from another. Entity types are different in that they have no written form. I cannot write a Person, though I can write their name. So if you model height as an entity type, you must provide identification in the form of role(s) the height plays. Those roles may be played by either other entities (which must be identified) or by value types. So ultimately, you cannot get rid of value types; they ground the entity identification mechanism.

 In ORM, I would model Height as an entity type with a unit-based reference mode. For example, Height(cm:) or Height(inches:). Height is based on a unit type or dimension, called "Length". Instances of other entity types (e.g. Width, Distance, Circumference) based on the same unit type (Length in this case) can then be meaningfully compared (if their units differ, you need to specify a unit conversion rule).  

Cheers

Terry

Terry, you say 

Terry Halpin:

In ORM, I would model Height as an entity type with a unit-based reference mode. For example, Height(cm:) or Height(inches:). Height is based on a unit type or dimension, called "Length". Instances of other entity types (e.g. Width, Distance, Circumference) based on the same unit type (Length in this case) can then be meaningfully compared (if their units differ, you need to specify a unit conversion rule).  

While I agree that Height is not a simple value type (it is not self-identifying), I'm afraid I don't see that it is actually an entity type:

1. You can't point to a Height and say, "look, there's Height 60 inches" in the same way you could point to "Person named John Saunders"
2. What happens when the Height changes? My brother is an inch taller than I am. If he loses an inch with age, do we suddently both share the same Height instance? What happens to the original instance? Is it now orphaned?

I'm glad to be able to use unit-based reference modes, as they make it clear which values can be compared; and I'm glad to have General reference modes, as they allow me to create conceptual domains (I can have entities StudentsInGradeEight(StudentCount) and StudentsInGradeNine(StudentCount), and make it clear that they can be compared). But I don't really see that these amount to entity types. They seem to be more "value types with additional meta-data".

Please help me discover what I'm missing here. Some of my confusion may be due to the fact that I started with ORM1 in VEA, but having read the Brown Book repeatedly, I'm still not quite getting this.

Thanks, John

 Hi John

   Regarding your point (1) "you can't point to a height in the same way you can point to a person", I agree. However, please note that entities may be abstract, they don't need to be concrete. Lots of entity types are abstract, e.g. Course, Preference, Purpose, etc.

  Regarding your point (2) "what happens when the height changes?", the height itself does not change. Instead, at one time a person may have one height and at another time may have a different height. If a height is no longer used in any fact type, then there is no need to retain it in the population. However, if you wish you can retain it by making Height independent.

   Hope this helps.

Cheers

Terry

Terry, it helps, all right. It helps blur the distinction between entity and value types even more!

What, then, are left as the differences between value and entity types? The fact that a value type is a self-identifying constant, and that an entity is referenced by definite description? But then, I'm sorry, but Temperature 37 degrees Celcius is not an entity to me. It's a constant which requires additional metadata in order to identify it.

It's a value in a column in a row in a table. It's unlikely to ever be the "row" itself. When the temperature changes, I'm not going to search for an existing temperature row with the same value and then update my Patient row to point to this new Temperature row (possibly deleting the old Temperature row if it is no longer referenced). I'm just going to update the column value.

Now, I don't know if this "row" distinction is important from the point of view of logic, but it's a big part of how this particular old person thinks about values vs. entities (the Person named "John Saunders" has Age(y:) 52).

If there's anything you can do to help this old dog learn this new trick, I'll be glad to hear it. :-)

 Thanks, John

P.S. I made the mistake of doing a search for "definite description" yesterday, and rapidly ran away from what I found. I'm fortunate I didn't take a course in logic in school, as I'd no doubt have done worse than I did in statistics. :-)

hi John

  It sounds like you are defining "entity" as "something that you want to record information about". While that viewpoint is popular in some circles (e.g, ER), it has fundamental problems such as semantic instability. For example, most would agree that FamilyName is a value type, not an entity type. But now suppose we want to talk about family names, e.g. add the fact type FamilyName() is derived from Occupation(.name), with an instance being The FamilyName "Smith" is derived from the Occupation named "Blacksmith". Does this change a family name from being a value to being an entity?  Not in ORM -- a thing does not change its nature simply because you want to talk about it.

   Similarly, if you regard Temperature as a value type, and now add the fact type "Temperature is hot" does Temperature suddenly become an entity type?

Hope this doesn't cloud the waters even more

Terry

Terry,

It sounds like you're saying that a value type is an object type which requires no additional explanation. FamilyName "Smith" needs no further explanation. However, Temperature(celsius:) 37 requires specification of the units, and Person(.name) requires a value in order to identify the person. Do I have that right?

But I still don't like that changing the temperature is now, conceptually, a matter of changing which entity we're talking about. I don't know how to explain that without it sounding like we're "pointing to something else".

Hi John,

I'll throw a few comments in the bucket here.

First, I'll say that I've kept a pretty firm line in NORMA to focus on ObjectType instead of ValueType or EntityType. There are very few cases where we special case value type, and I believe we've removed all of these cases from the core model. For example, we used to treat a non-independent standalone (meaning it plays no roles) ValueType as not implicitly independent and an EntityType with no non-identifying roles as implicitly independent, but we've relaxed this restriction. An example of where we look is in tie-breaking situations in 1-1 RMAP cases, where we will absorb a ValueType into an EntityType.

A basic test I use for whether to use a ValueType or an EntityType with a simple identifier is whether changing the form of the value changes the meaning of the instance. For example, Gender is an entity because it doesn't matter if you use {M,F},{Male,Female},{male,female}, or {boy,girl} to identify your gender. The gender represented by 'M' is the same as the gender represented by 'Male'. Of course, additional context is needed to make the meaning of 'M'.

Similarly for Temperature, whether you use 37 centigrade or 98.6 Fahrenheit you still have the normal human body temp (depending on diet, vegetarians generally have a much lower normal temperature). So, while the representation of the value describing a given temperature depends on the chosen unit, the meaning does not change, which makes Temperature an entity, not a value.

-Matt

Matthew Curland:

A basic test I use for whether to use a ValueType or an EntityType with a simple identifier is whether changing the form of the value changes the meaning of the instance

I still don't think that this is sufficient. I can write the string "Hello, world" as "\x48\x65\x6c\x6c\x6f\x2c\x20\x77\x6f\x72\x6c\x64", and I can write the integer 1000 as 1E3. I realise that these are different encodings of the same value, but aren't Farenheit and Celcius also just different encodings for temperature?

This is a serious matter; a formal method such as ORM shouldn't have such a grey area in my opinion. I believe that the reason is that there actually is no fundamental distinction. If I write "Joe Bloggs", you probably know I'm referring to a person. If I write "Freddie Mac", you might know I'm not. Or maybe you don't. The point is that it's context-sensitive.

That's why I simply resort to saying that value types "have an agreed written form" and entity types don't. What constitutes agreement, and by whom, is a matter that is explicitly left to context, and that's as it should be. ORM cannot be effective in trying to draw a distinction that doesn't actually exist.

Matt wants to model this using data types (abstract types each having potentially multiple representations), and I have some sympathy with that, but I think it's just deferring the issue by resorting to modeling computer industry standard practice. It actually doesn't change anything, except to make explicit what is implicit in the implementations. I.e. it's ADA vs C - there's a place for such modeling, but the best it can do is reflect standard practice and extant hardware. I don't think it adds anything conceptually over just referring to the existing standards, so I don't think it belongs in a conceptual modeling language, however important it might be in a tool that performs mappings to existing systems and languages.

This, in a nutshell, is the core of the difference that Matt and I have over data types - one that is yet to be resolved in our meta-modeling efforts.

Hi Clifford, et al,

Please allow me to throw in my two pence / cents. I have always taught my students--and, it clears up ALL these conundrums, to say--that what we mean by "a value" is, "a character sequence". That's it, that's all that distinguishes a "value" from other kinds of things.

I believe this is also what Terry means by "value". Here is one, rather folksy way Terry has always taught in his courses, for distinguishing values from entities: "If you can type it into a computer, it's a value. If you can't, it's not."

So for example, Cliff, you are incorrect: "Hello, world" is definitely NOT the same value as "\x48\x65\x6c\x6c\x6f\x2c\x20\x77\x6f\x72\x6c\x64". The two sequences do not even have the same number of characters (the latter has 4 times as many characters as the former). And no, you CAN'T "write the integer" 1000 (which is WHICH integer? 8, in binary? One thousand, in decimal? or...?) What you can write is a character sequence, such as "one thousand" or "1000" or "8" (which are three, not two, different values!).

Which brings us back to the reason that has always been given, for why it's important to distinguish entity types from value types: It's to remind - indeed, to force - the modeler to give a reference mode or scheme, for each entity type. If we fail to give an entity type one of these, we don't really know which entity is referred to by a given value stored in the database. (You can only store values, not entities, in a database: I once tried to stuff my dog into a database, and he has never forgiven me :-)

Cheers, Andy