Extensions to ORM

Cour coding of entities and facts

PeterC — Sat, 11 Feb 2012 08:43:28 GMT

For anyone who may be interested....

For most of my projects I use colour coding to visually distinguish a 'basic attribute' of an entity or fact within a model.

Example 1 - Modifying an existing (production) model.

Existing and unchanged: entity - black line, yellow fill; fact - black line work.
Proposed Modified: entity - dark blue line, pale blue fill; fact - dark blue line work.
Proposed New: entity - dark green line, pale green fill; fact - dark green line work.
Proposed Deleted: entity - red line, pink fill; fact - red line work.

Example 2 - Comparing two overlapping systems (eg one system provides data for another)

Common between both systems: entity - black line, yellow fill; fact - black line work.
System 1: entity - dark blue line, pale blue fill; fact - dark blue line work.
Change required to 1: entity - dark green line, pale green fill; fact - dark green line work.
System 2: entity - red line, pink fill; fact - red line work.
Change required to 2: entity - purple line, mauve fill; fact - purple line work.
....And a big red 'X' overstamped on items to be deleted.

cheers

Temporal modeling through "one at a time" uniqueness constraints

Clifford Heath — Mon, 30 Aug 2010 02:52:17 GMT

I've been thinking of exploring temporal modeling through introducing "one at a time" uniqueness constraints. That is, where the mapping takes care of the mapping of the history of a given N-ary fact type, by internally injecting a time role into the fact type, and enforcing the time roles to model uniqueness at a point in time. The point here being that generated data access code can have a simple API to the "current" data, and another API to access the full history.

This seems to be a remarkably simply way to handle a large class of temporal modeling problems.

Does anyone see problems with this as a conceptual modeling notion?

There is obviously the need for mapping options, because it can be mapped many ways and you need to choose the most appropriate one. Perhaps we don't need to discuss the pragmatic concerns in this thread; start another if you'd like to discuss that.

UUID vs URI

pcarbonn — Wed, 04 Aug 2010 08:11:44 GMT

In this simplified metamodel for ORM, UUID are used to identify elements in the model. This contrasts with RDF which uses Universal Resources Identifiers (URI). This observation led me to the following thought: what if ORM used URI too ? What if type identifiers were prefixed with a web address, implicitly or explicitly ?

It would enable the "interoperability" of ORM models, one ORM model being able to refer to another one. It would also make ORM more RDF-like, with similar applications. And possibly make ORM the next generation of RDF ?

Any thoughts ?

Expressiveness of conceptual modelling languages and using it, or not

Maria (Marijke) Keet — Wed, 20 Aug 2008 10:45:51 GMT

Dear All,

One of those recurring topics is ORM being more expressive than, say, EER and UML, and, moreover, that such expressivity is necessary for good conceptual modelling. Another argument in the discussion is that “most modellers don’t use the additional modelling options anyway” so that one could, in most cases, do with a less expressive language so as to reap more benefits from computation. Aside from [1], does anyone have hard data to back up either one of the claims, or has an x amount of models that could be made available for analysis?

Note that even [1] has some methodological gaps so that it does not entail the conclusion of the latter (using a less expressive variant of ORM), because there is still the main question why did the modellers not, or to a very limited extent, use the ‘fancy’ features of ORM. For instance, was the tool not intuitive and too cumbersome to add the more complex constraints, what was the background of the modellers, did they know such constraints were available, did they understand those un(der)used constraints, what was the quality of the models and the resulting software?

[1] see section 5, table 2 in Smaragdakis, Y., Csallner, C., Subramanian, R. Scalable automatic test data generation from modeling diagrams. In: ASE'07, Nov. 5-9, Atlanta, Georgia, USA. 4-13.

Best regards,

Marijke

Formalizing object models using predicate logic

Antonio Jose Rosado — Mon, 14 Jul 2008 15:33:26 GMT

I am not sure this is the right place for this question.

I am using ORM for fuzzy conceptual query languages, i.e., languages that can deal with fuzzy terms such as "young", "most", "similar to", etc.

I have read formalization of ORM diagrams using the KL language.

Since I am working with an OODBMS, I have to face with the problem of convertion between ORM/KL and ODL. Hence, I was looking for some papers discussing the interpretation of predicate logic into object models.

Anyone has some references on the subject?

Thanks,

Antonio Rosado.

Proposal for ORM 2 Object Shape Variant

Brian Nalewajek — Wed, 28 May 2008 15:48:29 GMT

This post accompanies a file upload to the NORMA library folder.

The file is in the form of a proposal for a variant to the standard ORM 2 Object Shape. It's hoped that such a variant will allow ORM modelers an alternative display style for situations where many Fact Types have one or two objects in common.

Comments and suggestions are welcome.

BRN..

Finding Euclid in ORM

VictorMorgante — Tue, 01 Apr 2008 09:54:05 GMT

My company does research into ORM. At the moment we’re considering the virtues of an extension to ORM.

Of course, doing so (creating an extension to ORM) is no small feat, because the likelihood of counter-example and inconsistency must be taken into very careful consideration; as does the notion of working with the rest of the community to bring benefit and consensus to the majority.

I find it funny and very interesting that we live in a time where there is still consideration of extensions to ORM. ORM v2 is not a few years old, and ORM itself only decades.

The axioms of ORM, I would have thought, would have all been settled by now, but even at last year's (2007) conference, further extensions were considered.

It’s hard to know when things will settle down. For my money, I peg ORM to be here in 2000 years, in much the same way as Euclid’s Geometry, and because of the atomic nature of the methodology. With the very axiomatic nature of ORM, I see many of the axioms as being rock solid, and fit to stand the test of time.

What prompted me to write this, is that it is almost certain that new ways of using ORM will be found, and in as much as we have ‘Non-Euclidian Geometry’, there will be ‘Non-Halpinian ORM’. I find that very profound and scary in a way, because there will be debate. But it will be the ‘usefulness’ of variants and extensions to ORM that will prove their worth.

I don’t know what those uses/extensions are yet (we consider only ‘one’), but it will be great to watch it unfold. I’m really interested in what other people see, and what they think it means for the ‘common meta-model’ as it unfolds.

Penny for your thoughts.

Extending the vision of extensions to ORM. Your viewpoint most welcome

VictorMorgante — Thu, 27 Mar 2008 09:15:55 GMT

I was speaking with a colleague of mine the other day about work we are doing with an ORM meta model, and how people are starting to use ORM meta models to investigate ways of melding 'relational schemas' with 'functions' (viz Dr Morgan's 2007 ORM conference work on Business Process Modeling and ORM).

My friend said "Oh, your making a graphical programming language?!"

In researching Dr Halpin's paper entitled "Join Constraints" (which can be found on Dr Halpin's web site (orm.net) concludes with an invitation to discuss, research [and possibly even debate] the further extensions to ORM.

On reflection I found myself thinking that my colleague was right to some extent [to my mind]....
i.e. the more you add higher level logic to a inherently graphical notation, the more it becomes like a graphic programming language.

I'm interested in hearing other people's opinions on this, and envisaging a what a 'software tool' would look like that did this.

1. Is it NORMA, coupled to Visual Studio?
2. Or is it something else entirely?
3. And do people want it?
4. What are the benefits over ORM diagrams for data modeling, business rule repositories for higher order logic [within those rules], and just 'code' for even more complex logic?

If this is something that interests you, or you think you have an insight worth sharing with the rest of the community, perhaps this is a good forum and thread to investigate that?