Value Object Type vs. Entity Object Type

A student asks:
... I'm still somewhat confused about when to use an entity type object and when to use a value type object. Let's take an example. Suppose we have two related columns of data:

Day      Day

Code    Name

Su           Sunday

M            Monday

T              Tuesday

W            Wednesday

Th           Thursday

F              Friday

Sa           Saturday

    It seems that there might be two ways to represent such a 1:1 relationship. We might have a fact statement with two entity type objects, written as:            

DayCode(.code) has DayName(.name)

or an entity type object and a value type object, written as:       

DayCode(.code) has DayName()

In either case, the predicate constraints could be unique/mandatory on both objects.  While both fact statements seem to have the same results, what are the advantages and disadvantages of using one or the other in such a situation?

EVEREST RESPONSE: 

Good question. I refer you to Halpin [2008], pages 10, 65, and 95. He doesn't say much about this but perhaps enough to understand the idea. . A value object type is a constant. It is self-identifying, that is, when you see the value written down, you (the user community) always know what is being referred to. So in your example, we always know what day of the week is referred to by either your DayName or DayCode. Each could be a value object type. In each of these two examples, what you really have is merely a string constructed from some alphabet. There is another population here and that is the “days of the week”. That would be a non-lexical object type (NOLOT). Then we can use a name or code to refer to the day of the week. We will pick one of them to be the reference mode for day of the week. And if that is always sufficient and unambiguous, we can make it a value object type… Let me take you through the thinking to answer your question. Everything we want to include in the database can initially be thought of as a NOLOT. (See slide# ORMod.42, which is essential to understanding this distinction which is made in Slide 43). Then we can ask, what are the different ways of referring to those things?  Each of those would be a separate object type. If we pick one of those, the day of the week can be referenced directly (with the name or code) and hence there is no need for some other scheme for identifying or referencing days of the week. Of course, the choice of identifier must be unique, ubiquitous, etc. (as discussed in class, slide# ERel.38)... NOTE that a value object type can also be a number. That includes all the number types we talked about in class. Also note that the string of numeric digits is actually referring to some point on a scale (that is the NOLOT), which can have various arithmetic properties (cardinal, interval, ordinal, nominal). We have to know what the base is in determining the number from the string of digits. For example, '10' is a very different number (the NOLOT) depending on the base, be it binary, or octal, or decimal. The representation of the number will be some chosen lexical object, constructed from some naming scheme. Again, in a particular context, the string of digits may be sufficient to always, and unambiguously refer to (represent) the number value, for all the users in that community. Hence, we could make the number a value object type… As you can see, this is not always hard and fast, depending on the user context. For example, we may be interested in how days of the week are referenced in other languages. Further, we may want to relate these to the days in some calendar other than the Gregorian calendar, which is used by most of the English speaking world. So you see, we really have to go back to thinking of the day (no longer of the week since other calendars may not have the concept of a week) as a NOLOT, apart from how it is referenced. The value object type is only used when values in a particular referencing scheme are sufficient and always unambiguous to refer to members of the NOLOT population. The NOLOTs are always there in the world being modeled. The naming and reference scheme are our own constructions. The conundrum is that we have no way to refer to members of the underlying NOLOT population (the semantics) without using the lexical handle (the syntax). As we said last week, we can only see or represent the semantics through the syntax… What is the advantage? The use of value types can simplify our model. We can let the value itself (the lexical representation) be the object. It is sometimes a convenient shorthand… Again, thank you for asking the question. It has given me an opportunity to think it through more clearly, I hope. Sorry for being so long winded.