Quite a number of important points here...
the data type at the concept level should be independent of the target system
This is a nice idea. It is implemented in VEA in the form of "Portable" data types. But I think that there may be hidden problems with this approach...
even if there is a one to one mapping between the two.
Now this is one of the problems. I don't see how there can be one-to-one mapping between something that is potentially a one-to-many mapping.
For example, in the case of DDL, at some stage you have to choose a driver for a specific database.
Different databases have different data type sets.(e.g. DB2/ Oracle/SQL Server 2000/SQL Server2005/SQL Server 2008)
For example, if my concept model says that Object X is identified by ID, and that ID’s sole purpose is to uniquely identify each instance of X, then conceptually I’m not interested in what ID is, it just has to be a unique value; but I am very interested in how it’s implemented.
Very interesting observation.
To paraphrase Shakespeare, "To OID or Not to OID? That is the question."
In the Relational Model paradigm, data is identified by its content. The concept of the OID is nowhere to be found.
You identify a "Unique instance of X" by saying that "this row in this table is unique".
This maps back to the "fact-oriented" nature of ORM.
In ORM, instances of fact types are represented by rows in tables. No OID's required!
In 2006, Ted Neward, wrote an interesting piece about the incompatibilities between Object-Orientation and the Relational Model in which he explains that "Object-Relational mapping is the Vietnam of Computer Science". http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
(If this link does not work, just Google "The Vietnam of Computer Science")
In his informative blog, Jeff Attwood makes the following observation: (Note in this text the term "ORM" means "Object-Relational Mapping")
"Personally, I think the only workable solution to the ORM problem is to pick one or the other: either abandon relational databases, or abandon objects. If you take the O or the R out of the equation, you no longer have a mapping problem." http://www.codinghorror.com/blog/archives/000621.html
My own view is a bit different. I think that OO is very useful, however like all things it has its place.
For example, it seem to me that if you are going to develop a transaction based system, then it's best to proceed as follows:
1: Define an object-role model.
2: Generate a relational schema & database.
3: Write code to interact with the database.
Now to return to data types and conceptual models:
The way you have expressed your perception of your hypothetical application domain about (permissible values “seven”, “pi”, and “e”) is to talk as though the value type come first. This is not the case with ORM because the basis of an object-role model is the elementary fact
Thus, the objects that have data types only exist within the context of an elementary fact.
This is in contrast to what I call the "lexicographer's approach" that sees some kind of "dictionary of terms" as an independent artefact.
To be sure, when you create an object-role model, you end up with a "dictionary of ORM objects" and very useful it is too.
However, this dictionary is derived from the set of facts, not the other way around.
So, in your seven, pi and e example, these "things" would exist in the object-role model because they participate in an elementary fact.
And therefore, "Seven wrote in the ShipsLog" on StarDate 5401.2", is just as correct as "On StarDate 5401.2, the ShipsLog contained seven entries."
The difference in the meaning of the term "seven" becomes clear by examining each fact instance.
And I don't understand your claim that a postive number is not an option in NORMA.
You just define the object as numeric and define its value range in a way that says that it cannot be less than zero.