Intro

I have collected Q&A topics since about 2010. These are being put onto this blog gradually, which explains why they are dated 2017 and 2018. Most are responses to questions from my students, some are my responses to posts on the Linkedin forums. You are invited to comment on any post. To create a new topic post or ask me a question, please send an email to: geverest@umn.edu since people cannot post new topics on Google Blogspot unless they are listed as an author. Let me know if you would like me to do that.

2017-12-20

Why isn't ORM more popular?

2010 December on Linked In Adam Ralph asked:

About 4 years ago, I was tasked with designing a new data centric application. My first instinct was to draw a conceptual model. For previous projects, I'd used entity relationship modelling but I was keen to find out if there were any alternative approaches. Scouring the internet, I stumbled across ORM. I printed out Terry Halpin's article "Object Role Modeling: An Overview" and studied it over the next couple of days. The approach seemed rather compelling, especially given the natural language aspect. So, I worked my way through CSDP for part of the UoD for the application. The model which presented itself, with the automatic verbalization and relational model translation was so elegant that I have never looked back.

ORM has now become my starting and reference point for most of the work I do. Yet, I'm constantly surprised that no‑one else I encounter has even head of it. After four years, including a change of company (from one large blue chip to another) I still have not encountered a single person who has heard of ORM, let alone practiced it.

I believe ORM is by far the most expressive and natural data modeling technique currently available, so the question arises, why isn't it more popular?

EVEREST RESPONSE:

I am often asked this question.  It is addressed in my Advanced Database Design course which teaches ORM. Let me give you some reasons from my perspective.  Some reasons stem from the early years, others relate to the present state of data modeling practice.

In the early years in the Evolution of NIAM/ORM:

(1) CDC kept it proprietary.
(2) Few academics were involved (who need to publish to keep their jobs and get promoted!)
(3) Lack of strong vendor support
(4) Lack of good papers, text book, and inexpensive, viable tool to support NIAM.

ORM has its roots in the work of Sjir Nijssen, with later notable contributions by Terry Halpin.  In 1975 August in Germany I had the privilege of teaching a course with Sjir.  At that time we reviewed a couple of draft papers he had prepared on the work he was doing on the Kadaster project in the Netherlands while working for Control Data Corporation (CDC). The papers were published in 1976 and he called it “binary modeling.“  CDC closely guarded the method as valuable intellectual property and began offering Information Analysis services to clients (for a fee).  This became known as the Nijssen Information Analysis Method (NIAM).  Most of the papers were published in obscure journals so did not get out to a wide audience (unlike the seminal paper Ted Codd published in 1970 on the relational model of data).  CDC developed an automated tool to support NIAM, as did others in those earlier years but they did not become popular.  Most of the activity was in Europe with little exposure in the USA, except perhaps for my course in Advanced Database Design at the University of Minnesota which I have taught since 1971.  I came back from the 1975 encounter with Sjir convinced of the superiority of the modeling method over relational, ER, or CODASYL network modeling.  I was so excited that I incorporated it into my class. However, it was little more than a lecture or two.  There were no really good papers, no text book, and no viable tool. 

Then Sjir Nijssen went to the University of Queensland in Australia in 1983 as a visiting chaired professor.  There he hooked up with Terry Halpin who saw the superiority of NIAM.  Together they published the first comprehensive treatment of the modeling scheme which was renamed Object Role Modeling (ORM) in 1989. Then some others saw it as a better way to do data modeling and developed an ORM modeling tool (InfoDesigner from Serverware, to Asymetrix as InfoModeler, Visio, and finally Microsoft).  Finally we had a tool and a textbook.  I began teaching predominantly ORM in my Advanced Database Design class in early 1990s.  Today it is available wholly online.  Go to http://geverest.umn.edu  for more information.  The course is offered only in the spring, and 2011 begins on Jan 20.

(Terry and Sjir can validate and correct the information above).

Reasons for ORM‘s lack of popularity stemming from Current Data Modeling Practice - PART 1

() ORM is very difficult to grasp on your own by reading a book, without good training.  Adam, you are to be commended for taking the time and having the persistence to really dig into and understand ORM.  My course provides the necessary knowledge and skill to use ORM and its data modeling tool, NORMA.
  
() blind acceptance in the industry that ER/Relational data modeling is the best way for data modeling.  Practicing data modelers are always thinking in terms of ER diagrams as their data models, or worse, relational tables.  I call this “Table Think“ and the malady is “Tableitis.“


() Failure to recognize the problems inherent in the use of any record-based data modeling scheme, that is, based upon the formation of entity records or objects with a set of attributes.  Normalization is the way to detect and resolve some of these inherent problems.  Unfortunately, it is practically and theoretically impossible for any DBMS or data modeling tool to help the designer produce normalized structure, unless... they use ORM.   ORM does not distinguish the notion of entities/objects from that of attribute, everything is a domain or population of something (called an object, which is distinctly different from that in object-oriented modeling).  Object have attributes by virtue of the role they play in relationships with other objects.  Hence, ORM has two constructs – objects and roles (in relationships).

() Most practicing data modelers think they are doing a good job.  They do not realize or consider that there may be a better way.  My course is a hard sell to experienced data modelers.  But give me a chance to talk to them and it at least opens up the possibility of a better way.  I have had some skeptics start my course, but they soon get converted because ORM is so compelling.  I have even had some that go to the end of the class unconvinced, and come back to me months or years later to say they finally got it!  I thank former students, Kevin and Troy, for their postings on this discussion group.

() nearly all textbooks on database management or database design present only record-based data modeling schemes.  So we continue to perpetuate the myth that this is the way to go.

Reasons for ORM‘s lack of popularity stemming from Current Data Modeling Practice - PART 2

() Most published research studies comparing various data modeling schemes including ORM report that it is inferior.  Upon closer examination, we discover that the experiments were conducted by people who had incomplete knowledge and skill in ORM.

() ORM is often criticized as being bottom up and too detailed for conceptual modeling.  We hear this both from proponents and protagonists of ORM.  So we have subject area diagrams, or high-level ER diagrams.  That just means some of the underlying semantics are hidden in the presentation.  The attributes are still there, even if we only show entities and relationships.  Being too detailed or not is a matter of presentation, not modeling.  The goal of (conceptual) data modeling is to capture as rich a set of semantics as possible of the users' world being modeled.  But it is foolish to present it all at once (are your conference room walls papered with diagrams to show all the entities and attributes in your enterprise data model?)  Since humans have cognitive limitations, we present various abstractions of the model, eliminating parts or detail, to facilitate human understanding.

() All the major DBMSs are based on the relational data model(ing scheme) so we often model in tables.

() The annual ORM workshop held under the OnTheMove conferences does not get beyond a small group of very dedicated enthusiasts.

() Lack of vendor support.  With the acquisition of Visio 1999, Microsoft got the InfoModeler ORM tool.  They added it to the enterprise team editions of Visual Studio as Visio (not the same as is in the Office Suite).  Unfortunately, Microsoft has done nothing with the ORM tool.  It has essentially the same functionality as Visio got when they acquired InfoModeler 3.1.  Microsoft has not enhanced the functionality of the tool and provides no training in ORM or the use of the Visio tool.  Fortunately, there is a better alternative tool now available called NORMA -- open source and runs as a plug-in to Visual Studio.  With a valid ORM model, just push a button and NORMA generates a relational database guaranteed to be in fifth normal form, and ready for direct input as a data definition to any one of several popular DBMSs.  Nevertheless, NORMA still has much maturing to do.  It needs additional enhancement to become an industrial strength data modeling tool, and that is in the works at LogicBlox.

That was probably more reasons than you wanted.  If you desire a taste of or motivation for ORM, you can attend my Workshop entitled “Rethinking how we do data modeling“ at the DAMA Enterprise Data World conference (edw2011.wilshireconferences.com) , in Chicago, 2011 April 3-7.  I will also be giving a presentation entitled “Helping Business Users Understand Your Data Models."  More information is at my website: http://geverest.umn.edu . So the challenge is: how do we get the word out?

No comments:

Post a Comment

Comments to any post are always welcome. I thrive on challenges and it will be more interesting for you.