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):
-
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).
-
UML models exclusion/equality/subset constraints between associations instead of roles (bad idea).
-
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