The ORM Foundation

What is the best way to model a user-defined data type? I tried the approach outlined below, which also is shown in the image that I uploaded.

I would like to invite comments on the approach and learn what others have done. 

• I created a custom data type called PersonalName, which has two attributes: FirstName and LastName.

• I used the ORM Reference Mode Editor to create a (Popular) Custom Reference Mode called "PersonalName", which I then used as the reference scheme for a Customer entity.

• I also wanted to show the structure of the custom data type, so I created a PersonalName entity with Id as the reference scheme with a data type of "object ID". I then showed that PersonalName comprises FirstName and comprises LastName. 

Can you explain why you want to start by defining an object type that has a user defined type as a reference scheme?

Other comments: 

A "Customer" is a role that is played by a "Person" (where a Person can be a legal entity such as a Company or Government department)

In my experience, customers are usually identified by means of a Customer Number.
A Customer can be either a human person or legal person 

Here is one way to model this:

Person(.nr) has two mutually exclusive subtypes - LegalPerson and HumanPerson  

Person(.nr) has Customer(.nr)
HumanPerson() has FirstName()
HumanPerson() has LastName() 
HumanPerson() was born on Date()

LegalPerson() has LegalName()
LegalPerson() was created on Date() in Jurisdiction(.name) 

You could choose a different reference scheme for Person as explained in section 5.3 (Page 174) of Information Modeling and Relational Databases (Second Edition - 2008) 

 After a bit of thought, I made this model which I hope is of help.

Ken

 Ken,

Your example and citation are very helpful. Thank you.

The reason that I am interested in how to represent a user-defined data type is that I am using an ORM model to capture the conceptual view of a database that is implemented in Cassandra, and the application development team has proposed using a user-defined type (UDT).  The proposed UDT would contain personal name fields, so I simply pulled that out to illustrate the concept.  For a Cassandra example, please refer to "Creating a user-defined type (UDT)" on the DataStax site at this location:

https://docs.datastax.com/en/cql/3.3/cql/cql_using/useCreateUDT.html

In the reference scheme example that you mentioned from section 5.3 of the Information Modeling book (see my uploaded figure), the alternate reference scheme name, surname, is a data value rather than an entity type.  I was thinking that in order to represent a user-defined data type in ORM, I would need somehow to refer to an entity, which is where I hit a roadblock. Would it be possible, for example, to refer to the set of elements that you modeled for Person as a whole, so that "Person" could be a new data type? The list of data types in ORM does not seem to allow us to reference concepts that we define in the model, such as Person. I was only able to make such a reference using the reference scheme editor. My work-around was to create a diagram for user-defined types and then use the custom reference-scheme name wherever I needed to refer to that user defined type.    

OK - here is an outline of "where I am coming from" on this one. 

When creating an object-role model an ORM analyst starts by listening to people that we call "domain experts" and looking at the forms that they use to communicate information.

A "domain expert" is someone who knows a lot about the topic to be modeled. For example, if you want to model a railway then the domain experts are those people who know all about railways, If you want to model a telecommunications system then you talk to the people who know all about the telecommunications system to be modeled and so on.

The ORM analyst then creates a set of sentences and constraints and validates them with domain experts by asking "Is this true?.
This is how the ORM conceptual model is created.

Now I may need to get out more but I have never yet heard a non-IT domain expert talk about "User Defined Types" or "data types" or anything similar. What they talk about are railways, hospitals, telecoms, schools, ships, buildings and so on.
So with a view to furthering this important discussion, please will you educate me by giving a "domain expert sentence" that includes the term "User Defined Type".

 If your text means that you are only interested in "Human Persons", then the object-role model is much simpler.

Here is the verbalization for the fact type "Person has CustomerNr with Company"

Maybe I'm missing something, but I still don't see where a domain expert would say something about a UDT.

A domain expert would speak at the type level, e.g., by referring to "a payer" for a claim. A payer always has a first and a last name among other attributes. For example, both the party responsible for a claim payment and the party making that payment would be of type "payer".

Normally I would consider "payer" to be a role that a person plays, but I also could consider it to be a complex data type (implemented as a user-defined [data] type). Norma supports a data type of "Other: Object ID," which I think would be equivalent to allowing me to refer to a set of entities in my model that correspond to a custom (user-defined) data type that I defined. The advantage to me in so doing is that I could better represent the way in which the end user and the development team are thinking of this concept. Granted, I don't need to do this, because the standard fact types that you suggested can accomplish the same thing at the conceptual level. Nonetheless, I would like to have the option of defining and referring to a complex data type, because when I work with teams that use object-oriented approaches and NoSQL databases, it would help me communicate and validate design ideas more clearly. 

A payer always has a first and a last name among other attributes.

Is this true?
For example: If you sell something via Amazon, then Amazon collects the “Payment” from the “Buyer”, deducts a percentage and then pays the rest to you.

In this scenario, the “Buyer” plays the role of “Payer” because the Buyer pays money to Amazon. Then Amazon becomes a Payer” when the Amazon company pays you your money from the sale.
But Amazon does not have a “First Name” nor does it have a “Last Name”.

(This is why I introduced the concept of “Legal Person” in my earlier model)

Norma supports a data type of "Other: Object ID," which I think would be equivalent to allowing me to refer to a set of entities in my model that correspond to a custom (user-defined) data type that I defined.

In Norma, the data type for an “ObjectID” is “bigint” so this points to an OID such as GUID. As I understand it, an OID may point to a node in a hierarchy and that node may have Properties.  

And - I just had a quick chat with Matt about your requirements. He is a lot busy right now but this is what he said:
“I have posted before on ORM Foundation about how to hijack a data type. I think I did something like put an obviously out of range precision on a double then tweak the DIL datatype generator.”
I had a quick search of the Forum but I could not find Matt’s post. Maybe you can find it?

Anyway, the implication is that it is possible to do what you want by writing code in NORMA.
Are you interested in doing that?

I think this reply (ed. the "OK - here is an outline of "where I am coming from" " one) is spot on.

The intended use of ORM is to model *business* stuff at the *conceptual* level.

User defined data types are clearly a component of *logical db design*, which is distinct from conceptual business modeling, and should and can come only *after* the business concepts have been outlined precisely enough.

Using ORM to document notions/details of "user defined data types" seems stretching it beyond its intended use/scope.

"The intended use of ORM is to model *business* stuff at the *conceptual* level."

That's true - but it does depend on what you mean by the term "business" 

For example you can design an object-role model from statements such as:

The database type with the name of SQL Server can be queried with the language called SQL.
The database type with the name of Cassandra uses user defined types.

In other words, you could talk about user defined types if you are talking about the "business" universe of discourse called "database technology"

In summary, if you can say it in valid sentences, then you can model it with ORM.
That's why I prefer to use the term "Universe of Discourse" rather than the culturally overloaded term "Business".

Of course.

And do you think this was the OP's case ?  That his business problem was the database design itself ?

Or would you rather think his business problem was the original business problem that his database was part of the solution for ?

 " his business problem was the original business problem that his database was part of the solution for "

Yes Erwin, of course I agree with you on this one. 

The posts suggest that for "some reason" John was trying to force a database specific feature into the conceptual model - which, as you say, is not appropriate. However, some people seem to find it hard to distinguish between an ORM conceptual model and the technical solution so I tend to take things slowly.

 ORM recognizes three kinds of object types: entity type (e.g. Country); domain value type (e.g. CountryCode) often shortened to "value type", and data type (e.g. string). Value types carry more semantics than data types (e.g. the CountryCodes 'CH'and 'DE' are based on Latin and German respectively, but the same does not apply to the character strings 'CH' and 'DE').

Thank you, Terry. That answers my question about NORMA's functionality, and your suggested work-arounds would work well for me.

I agree with all the posted comments on the separation of conceptual and logical/physical modeling concerns, and usually follow them in my own practice. I simply needed a compromise approach in this instance. 

Ken, I would would like to participate in the development group. It probably will take me a month or two to get up to speed.

I've been a great fan of ORM for many years. It is one of the most expressive modeling languages that I know, and business users especially like it. I've recently started informally studying ontology, and see many connections between ORM and the underlying design principles of the upper level ontology, BFO (Basic Formal Ontology).