The ORM Foundation

Hi Josue

Various versions of an ORM 1 metamodel have been published, e.g.

Cuyler, D. & Halpin, T. 2003, 'Metamodels for Object-Role Modeling', Proc. EMMSAD’03: 8th IFIP WG8.1 Int. Workshop on Evaluation of Modeling Methods in Systems Analysis and Design, Velden, Austria (June).

You can access this paper at http://www.emmsad.org/2003/Final%20Copy/26.pdf

While we have a metamodel for ORM2 as supported in NORMA (Natural ORM Architect), this is not yet publically available.

We are working with PNA on a new common metamodel for ORM that we hope to present to the ORM community for discussion and ratification some time later this year.

Cheers

Terry

I have a doubt about the way the EntityType and FacType instances are modeled in the NORMA ORMMetamodel. I know the related file is quite old, so I’m wondering whether someone might comment on the correctness of the following uniqueness constraints:

• One FactTypeInstance has many FactTypeRolInstance AND one FactTypeRoleInstance has one FactTypeInstance
• One EntityTypeInstance has many EntityTypeRolInstance AND one EntityTypeRoleInstance has one EntityTypeInstance

No, this is correct. Each of the complex instances (EntityTypeInstance, FactTypeInstance) is populated based on the roles in the instance. For the FactTypeInstance, this is each Role in the FactType. For the EntityTypeInstance, this is each Role in the preferred identifier for EntityType. However, the roles are not directly referenced. Rather, they are referenced through the relationship between the role and the instance used for that role within the context of the other complex instance.

Each of these RoleInstances references a Role and an ObjectTypeInstance. However, the fact types you have highlighted just form regular collections, where each complex instance has a collection of the role instances used to populate it. This is not many-to-many because a role instance is populated explicitly for the complex instance that contains it. Another complex instance, even one using the same role/value combination, gets a new role instance.

If a constraint is missing, it is an external uniqueness enforcing that each role is used once only for each EntityTypeInstance/FactTypeInstance. In a fully populated model there is also an equality constraint enforcing that each role in the EntityTypeInstance.EntityType.PreferredIdentifier.RoleCollection/FactTypeInstance.FactType.RoleCollection is used once. In a partially populated model these would be subset constraints.

I'm attaching an extended snippet of this part of the metamodel that adds support for externally identified objectified FactTypes, subtype population, and relationships between an instance for an objectified FactType and the corresponding instance for the objectifying EntityType. It doesn't have all of the external constraints mentioned in the previous paragraph, however.

-Matt

Sorry, Reiner, I thought about this some more and you're absolutely right that there is a problem here. The difference between what NORMA currently does and what is represented here is that the 'Role has entitytype- ObjectTypeInstance' and 'Role has facttype- FactTypeInstance' are actually implemented as bags with a separate identifier. So, the change to the metamodel to match the current implementation is to switch the objectification to the coreferenced form (FactTypeRoleInstance is for Role, FactTypeRoleInstance has ObjectTypeInstance) with no uniqueness constraint, and then add the external uniqueness to make each role unique within a FactTypeInstance.

A better metamodel would probably be to objectify 'FactTypeInstance populates Role' (FactTypeInstanceRolePopulation) and 'EntityTypeInstance populates Role' (EntityTypeInstanceRolePopulation) with spanning uniqueness in both cases, then define '*InstanceRolePopulation targets ObjectTypeInstance' to associated the instances. There is also an equivalent ternary form that does the same thing.This gives an equivalent conceptual model to the coreferenced form without the external uniqueness.

In practice, switching this in the NORMA implementation model would be a huge amount of work and isn't worth doing because conceptually they are very close. However, if I modeled it from scratch today, I would probably take the second form instead of the first.

Thanks for pointing this out. I'll update my previously attached model in an earlier post.

-Matt

PS In general, the metamodel(s) in the source tree are not either accurate or up to date.

Josue Portal:

I'm using the NORMA metamodel

Not many people other than those building or extending NORMA have actually used the metamodel implied by the XML saved by NORMA to a .orn file... but I have. I would caution you; it is very much an implementation model, not a conceptual one, and it isn't remotely normalized. As well as cross-referencing everything in both directions, it also contains many implicit objects that are only required to support NORMA's internal processing.

I built ActiveFacts around a purely conceptual metamodel that's derived from NORMA and which is defined in ORM2 diagrams created in NORMA. In some cases I use terminology from SBVR, or incorporate ideas for extensions to the model (such as units). This metamodel has been thoroughly validated as conforming to all aspects of ORM2 as expressed in NORMA - the proof being that any ORM2 model in NORMA may be processed into a constellation of metamodel fact instances, and from there, generated into various artefacts including CQL, normalised SQL, and object-oriented code. The emitted CQL may be re-compiled into the same metamodel instances and generated again into the same SQL and code. The only restriction is some additional constraints on the content of fact type readings, necessarily imposed because CQL is plain text, and there is no ability to quote words to remove their normal meaning. One or two corner facets of the language are incompletely implemented, but are still correctly covered by the metamodel.

The ActiveFacts metamodel is published at http://dataconstellation.com/ActiveFacts/examples. This metamodel, authored in NORMA, is generated to CQL. The CQL is generated to Ruby (an object-oriented scripting language) and the generated Ruby code is used to represent the intermediate result of processing models in ORM and CQL - that is, the CQL compiler is self-bootstrapped.

Certain elements of my model are being changed right now, in particular the Feature type was there to support synonyms (now removed) and will be removed when I introduce the objectified fact type Term, which is where a "Vocabulary applies a Name to a Concept". This replaces the need for explicit synonyms and makes the Concept independent of the Names used to refer to it. In my opinion, ORM2 confounds the Concept and the Term into ObjectType, an error that SBVR corrects.

Regardless, I'd like to commend my metamodel for your consideration and I look forward to any suggestions for improvement.

 For that matter, I'd like to see more folk here actually using ActiveFacts Constellation Query Language to construct models, and giving me feedback. The SQL generation I support is on a par with that generated by NORMA, though there are some differences. The Ruby code is adequate for the internal use in the (very demanding!) compiler but is not yet hooked up to function as database runtime code; that's what I'm working on at present. Following that I'll implement the Query part of CQL, which is capable of expressing queries that cannot be written in SQL, yet still read as plain language.

I'm not sure where to start on this. Of course the XML is an implementation file. The data being stored is a model based on an ORM metamodel, not the ORM metamodel itself. You can consider the XML schema to be a logical form of .ORM, not a conceptual form.

An .ORM file is a hierarchical XML file. Last I checked normalization theory referred to a relational model. You can emulate a relational model in XML, but you end up with no tested. If you mean by non-normalized that some data is stored twice, then so be it. Some data is derived--any derived attributes start with an _ and are easily recognized as such. The only data I can think of that is stored bidirectionally is role players (stored with both the role and the ObjectType), preferred identifiers (stored with the ObjectType and the UniquenessConstraint), and the list of internal uniqueness constraints stored with a FactType (fully derivable from attributes on the constraints). This is a far cry from 'everying cross-referencing in both directions'.

Yes, there are implied objects store in the file. However, claiming these are just for internal NORMA processing is also a stretch. There are two types of implied objects:

• Implied mandatory constraints are added if an ObjectType plays no non-existential mandatory roles. This is a long-established ORM metarule that is not specific to NORMA.
• Binary fact types implied by an objectification, and objectifications implied by a spanning uniqueness on a binary FactType. This simply provides a coreferenced form of the model. We use a compacted form via the RoleProxy mechanism, but the concepts are 100% ORM. Also, whether you want to acknowledge it or not, there is a relationship between a role player of an objectified fact type and the objectifying entity type. This is also what is represented by the implied fact types. These fact types and roles are necessary when specifying join paths, derivation rules, query sets, etc. They are not just there for 'internal NORMA processing'. There are elements that we use for internal processing, but these are generally recreated on load and not serialized with the model.

The metamodel we're using does not in anyway preclude adding alternative names from different perspectives and languages. Assigning a primary name to an ObjectType (which, by the way, we do not use as a primary identifier, and it is only deontically unique in the model) does not mean that we think an ObjectType is equivalent to an SBVR Term, or that multiple names cannot be used for the object type.

-Matt

First of all, I should say that NORMA is fantastic and I'm not in any place to belittle your achievement. Whatever you need to store in a .ORM file is fine by me. I'm also aware that the format is somewhat dictated to you by the default serialization of the DSL tools, based on your object model. It is however not clear that, since you only interact with the ORM file through the window of that serialization, you can even see what the issues are. I certainly don't think that your list is exhaustive, but I'm not about to crawl through my code to find the many oddities it must cope with. As I said, they don't matter... unless you think that .ORM is the right file format for interchange.

You'll be aware that for more than two years now I've been trying to get some discussion happening about a metamodel for ORM2, in ORM2, that we can all agree on. Visible progress, as far as I have seen, has been limited to the material that I alone have published. I've never had a single line of email that commented on any feature of my metamodel, which has been published for almost two years, being used to convert .ORM files for most of that time. Why not? Don't we believe that ORM2 is the best way to do modeling? Doesn't this matter? Before starting to construct my own metamodel, I spent some time playing with the one published with NORMA, and I don't believe that it's been used as more than a repository for thoughts about ORM2. There's no evidence that it's ever been validated as effective as a basis for interchange.

If ORM2 is effective for anything, it must at least be shown to be effective at modeling itself. If we don't do that, it's just evidence that we aren't prepared to "eat our own dog-food".

Useful though the .ORM format defined through object modeling and the DSL tools is, I firmly believe it shouldn't be considered as an interchange format. It's high time we started down the path of tool interoperability and at least agreed a proper metamodel.

Clifford Heath:

I've never had a single line of email that commented on any feature of my metamodel

Actually that's not quite true. On occasion I've been stuck and have asked specific questions about fragments of the model and have had answers from Terry and sometimes Matt. Also, before I started my model in ORM2, I made a relational model and had extensive feedback on that from Terry, which was highly valued... But no response to the ORM2 metamodel as a whole.

Sorry for the lack of detail previously.

Hi Clifford,
Thanks for your valuable contributions. 

Clifford Heath:

You'll be aware that for more than two years now I've been trying to get some discussion happening about a metamodel for ORM2

Clifford Heath:

If ORM2 is effective for anything, it must at least be shown to be effective at modeling itself.

Ken

Ken Evans:

ORM2 metamodel is that it may still be the subject of a  lenghthy "debate"

Actually I rather think that both parties are extremely busy with other things, aware that they have some differences that are difficult to reconcile, and have little taste for a drawn-out debate that might still yield no agreement. For the same reason, though I'm eager to talk about it, I hope I've improved the field by just doing it.

My metamodel won't be to everyone's taste, but at least it works. It's not just a diagram; it's code. I process it directly (or via CQL) into Ruby code which is then actually used by all of the ActiveFacts tools, forming the intermediate representation. That the tools work is a demonstration that the metamodel is sufficiently correct to be usable. Actually, I find the generated API to be incredibly effective, and it can be generated for any ORM2 model.

I have a goal to extend my metamodel to support the requirements management process (history, rationale and review), an extensive query capability surpassing SQL's power, and business process modeling. I have one offer of collaboration; are there any others? Perhaps someone wants to try to add full SBVR support? Or other aspects I haven't mentioned? Bear in mind however; implementation is the fire that tests any model. It's fine to chuck ideas around, but they cannot be known to work until an implementation has tested them.

Ken Evans:

that the language in which a metamodel is expressed need not be the same as that of any particular "target language".

That's absolutely true in the general case (though it's nice when general-purpose programming languages can do it), but here if anywhere the opposite principle should apply. If we mean to present the structure of sets of ideas, it's important that we can structure the presentation in the same way.

Hi Clifford

I share your desire to have a common ORM2 metamodel that can be used to facilitate exchange of models between different ORM tools. As you know, I initiated a by-invitation-only forum long ago to achieve this objective, but that was discontinued after it became clear that consensus was not going to be easily obtained in this way.

For some time now, the NORMA team has been working with PNA to come up with a draft common metamodel that could be opened up for discussion by the wider ORM community. That draft is not yet in a suitable state for wider discussion, but I am hopeful that some useful proposal will come out of this collaboration.

Thanks again for your excellent work on developing ORM-based tools.

Terry

Terry Halpin:

the NORMA team has been working with PNA to come up with a draft common metamodel

That's good news indeed. I wait with bated breath.

Terry Halpin:

I am hopeful that some useful proposal will come out of this collaboration

That comment reflects the pragmatism I hope for. A model can be enormously detailed and accurate, yet completely unusable. I'm sure that mine errs on the other side, the side of pragmatism. Somewhere in between we can have a true model that's also useful.

Terry Halpin:

... developing ORM-based tools.

As I've indicated in other messages recently, I think fact orientation offers the best hope for the software industry to start fixing a trillion-dollar problem, and it's up to us to show them how... not to just debate about angels on pinheads. I know you're motivated that way too! If we delay too long, progress will bypass us. In fact, SBVR is close to making that a current reality. The software industry is basically a fashion industry, and we need to create sexy solutions to real problems to stay current. They don't want a better way to design an SQL database... but there are many things they do want and need which fact orientation can deliver. I'd like to see all the tools moving in some of those directions, and being delivered in a way that allows them to be effectively deployed into existing enterprises.