The ORM Foundation

A formal foundation is needed to ensures unambiguity and executability (e.g. to automate the storage, verification, transformation and simulation of models) and allow formal proofs of equivalence and implication between models. Although ORM richer, graphical constraint notation provides a more complete diagrammatic treatment of schema transformations, use of textual constraint languages can partly offset this advantage. For their data modeling constructs, ORM, ER and UML may be given adequate formal foundation. (pg 61)

I know that this is not exactly what you talk about, but the word "formal" reminded me a question what I wanted to ask long time ago. So my question is: What is meant by criteria "formal foundation"?

Does formal mean that there is a modeling language documentation, it is executable as relational data structures or....I could not find a good literature about this topic as well.

For me it seems that most of the modeling languages (or at least ER, ORM and UML) have formal foundation which means that this can not be a criteria for modeling language (or at least not criteria for comparing different langugages).

V.K

V.K.

Formal generally references to an unambiguous mapping to an underlying formal language. Terry's PhD focused on formalizing ORM in terms of first order typed predicate logic, along with formal proofs in logic that different ORM constructs were logically equivalent. Terry considers ORM to be a very thin skin on top of logic, and there are direct mappings between concepts on the two sides. For example, an ORM ObjectType maps to an individual in logic, and a FactType maps to a predicate. There are similar mappings for representing ORM models in relational calculus (the formalization of the relational structure).

The goal of formalization is to completely eliminate ambiguity and, hence, make it easier to execute the model. ORM does not assume that an attempt will be made to execute it using relational structures. In fact, there is no assumption of any target execution language or bias towards logical data structure, simply that the logic is well-formed. Of course, a solid logic foundation is incredibly important because systems such as the relational model and OOP also have logic at the core of their formal underpinnings.

In attribute-based systems such as ER and UML you see an inherent bias towards a relational implementation structure. Although these models may designate themselves as conceptual, they are really conceptual/logic hybrids because they express the models in terms of higher-level implementation structures, not elementary facts. You will also see some divergence in the UML and ORM formalization that causes problems in UML mapping to logic. Some examples (I'm not trying for completeness here):

1. The UML metamodel treats objectification (reification in UML) as a subtype of both Association and Class. This is a no-no in logic, where individuals and predicates are non-overlapping. (See section 10.5 for a detailed discussion on objectification).
2. UML models exclusion/equality/subset constraints between associations instead of roles (bad idea).
3. UML combines uniqueness and mandatory notions into one multiplicity notion. This works fine for binary relationships, but completely breaks down for ternary and higher relationships.

Having a directly executable ORM model is obviously a great goal. The work the NORMA team is doing with LogicBlox produces declarative Datalog models from the ORM model and then directly executes the datalog (the datalog execution systems are currently proprietary, but are used to run very large data intensive systems through a SaaS model). However, ORM models can also be executed by mapping them to other structures (relational model, class models, etc). The ultimate goal is to support all interactions with the data through the conceptual model so that the users and developers do not need to worry about the back end implementation. Once all communication with the underlying data is done at the conceptual level, it doesn't really matter if the model is executed directly or if the model is used to generate other implementation artifacts that are then executed.

The logic strength of the meta model is certainly one ingredient in evaluating a modeling language, but an argument at this level can get very esoteric very quickly on obscur geek points. For a language choice, the main criteria for a modeling language is the ability to effectively represent the model as expressed by the domain expert, and allow the domain expert to verify the correctness of the model. ORM is by far and away the best modeling language in this area. For tool choice, you also need to consider what can be generated directly from the tool. Obviously, NORMA is not yet where it needs to be in this area (capital is hard to come by these days), but modeling with ORM puts us in a unique position of being able to generate other modeling constructs (UML, ER, OWL, etc) that can then be used as input for other generation systems.

-Matt

 Matt,

I'm not interested debating Terry third-hand with you here, if I have a question for Terry or want his input I'll contact him directly.

My input was my own and was intended to provide a usable tip to someone that may have wrestled with the distinction between a sub-type and a role.  The approach that I recommend and that I've followed is to have a role-type and a role-performance object to track performance of a role by a person or an organization over time.

 I haven't read either of the two copies of Terry's new book that I bought because I haven't had time and I read the first book (although admittedly it was about fifteen years ago).

Good luck with NORMA.

Hi Brian Good to see you active on the forum. I've been bogged down with setting and grading final exams, so only just now looked at this thread.
You are right in treating role types (e.g. Employee) as different from normal subtypes (which are typically rigid, e.g. Person). I use the term "role subtypes" to talk about them rather than saying they are not subtypes at all. Finer classifications are made by some others (e.g. distinguishing roles from phases). There is a basic discussion of role subtypes vs rigid types in the second edition (the "big brown book') -- see pp. 427-430. I have more extensive publications on this topic, if you'd like to e-mail me directly for more details on that. Returning to the question about formal foundations, I simply mean that expressions in the modeling language (graphical or textual) should be transformable into a formal logic language, such as first-order logic (in ORM we add some aspects from other logics), so that formal proofs can be made to determine things like whether one schema is equivalent to another. Cheers Terry