ormsource.com

Most of my thesis work is on the isomorphic mapping of ORM to non-standard models under the Lowenheim Skolem theorem and on the premise that ORM has an infinite model.

One of the things that stands out with modern ORM research is that software ORM based ORM tools (such as NORMA) can generate source code based on an ORM model. This leads to the question, 'To what level of code generation can ORM based software tools generate code?'.

ORM and First Order Logic

The standard interpretation of ORM is as a First Order Logic by way of the isomorphic projection of ORM to a symbolic First Order Logic ('KL') in Terry Halpin's doctoral thesis.

Without going into the details, under this interpretation a software based ORM modeling tool may generate 'Create, Read, Update, Delete' (CRUD) type code mapped to a database (as in Object Relational Mapping) and generate code to enforce the various ORM constraints on the data.

That in itself is quite an accomplishment and may save a considerable amount of time (that would otherwise be spent coding).

I believe that is the level of code generation that can be achieved by an ORM based code generation tool.

Complications with ORM based code generation

The Currey Howard Correspondence poses some interesting limits on code generation using ORM.

The Currey Howard Correspondence intimates that for every piece of software there is a proof in mathematical proofs. When those proofs are first order logic, there is little problem and we would find that the programs/proofs represent CRUD type operations on data and constraint validation/enforcement.

It is when we consider that ORM has an infinite model and mappings to Higher Order Logic that we will find complications in generating code out of an ORM model. i.e. If an ORM model represents a Higher Order Logical model (in its interpretation), then the effective 'proof' to generate the software will be as relatively complex as the higher order logical model represented by the ORM model.

Proofs in ORM

An interesting consequence of being able to generate code from ORM, in that by virtue of that fact (and ORM tools can already generate code), is that that code represents a proof (by the Curry Howard Correspondence). This supports the theory that you may do proofs in ORM, all be they graphical proofs.

I hope this is  useful information to the ORM community.

I have often been critical of Terry Halpin's attack on the ER modeling language/methodology from a few ideological, philosophical, and business standpoints. While ORM/Niam approaches it's 20th year (under various incarnations, ORM 2 being the latest), the marketing message underlying 20 years of writing by Halpin is that ORM is superior and ER modeling is inferior. I have been critical of this approach from the min 1990's. In this article I will explain my position.

Dr Halpin doesn't have qualifications in Marketing, and marketing is a science as much as any. In the science of marketing and sales, and as many text-books attest (viz 'Corporate Combat', W. E. Peacock, 1986, Berkley), head-to-head frontal assaults on the opposition invariably end in tragedy. The tragedy for ORM, of course, is that