Arguments against the Use of ORM (and their Rebuttals)
by Scot Becker

INTRODUCTION
Given the fact that Object-Role Modeling (ORM) isn't the trendiest method for database analysis and design, I spend a lot of my time recommending and subsequently defending my analysis method of choice. This article is an attempt to answer - hopefully once and for all - the most common arguments against the use of ORM.

ARGUMENT #1
We're an ER/Win (or Designer, or Data Architect, or whatever) shop. Using ORM would mean we have to go with Microsoft^® Visio^®.

REBUTTAL
I care about getting the job done right. I care about making sure my client's requirements are gathered correctly, accurately, precisely, and quickly. I care that the resulting design meets those requirements. I don't care what CASE tool you use.

Defining how it is that you gather requirements based on the CASE tool that you plan use to generate the DDL is, frankly, silly. The two issues have nothing in common.

Analysis is about figuring out what the problem is. Design is about figuring out how to solve the problem. The tool you use to capture your analysis and design models implements how you want to document the analysis and design.

Make your logical and physical models in whatever tool(s) you want. Don't even use a tool, for all I care. Etch it on stone tablets, draw it in PowerPoint (I have seen this done), tattoo it on your forehead, if you want, just THINK first!

ARGUMENT #1b
Visio isn't an enterprise level tool. We have meta-data repositories and whole departments whose sole function it is to worry about attribute names.

REBUTTAL
Good for you. And, you are probably right, Visio isn't very good at these things (yet?). However, if the structure isn't right, if the requirements are not accurate, and if the project fails/dies because the underlying models are not correct, your repository is absolutely worthless and exists as nothing but bureaucratic red tape.

I know a lot of meta-data people probably just spit coffee all over their monitor after reading that last bit. Don't get me wrong, these functions are important, but they are only meaningful if they are right. Worry about being correct first. Now that you have that, specify the model in your standard tools and repositories.

This is, incidentally, what I do every day at my client sites. Most of them do not have Visio as their standard tool. I use Visio for my working models; my environments with which I think. I don't worry a whole lot about notes, standardized column names, and etc. until I get the model fairly complete. Then, I simply add it to ER Win, Designer, or whatever the Standards Policeú have deemed the deliverable tool.

It doesn't even take that long to re-enter the models, most of the time. In fact, one is usually working on a handful of tables at a time. Re-entering them into the chosen documentation tool takes, what, five minutes? And if you are doing a big bang effort, and have to re-enter scores of table, most tool vendors provide automation interfaces and other ways to import/export the models. For example, you could always download Orthogonal Toolbox.

Easy, eh?

ARGUMENT #2
ORM models are too verbose and they take up too much space.

REBUTTAL
The first point to make is that given the use of an ORM tool, generating the more compact and concise ER model is very, very easy. You literally push a single button. Big deal.

However, there is a more fundamental rebuttal to this argument. ORM models are verbose; I admit it. In fact, they are so verbose, they capture tons of constraints that ER's logical perspective can't even express. ORM captures "attribute level" constraints as well as set comparison constraints like subsets and exclusionary rules.

ER, generally speaking, does not. In essence, really, the more detailed anything is - indeed, the more you have to say about anything -- the more verbose it is.

Thus, I am often dumbfounded by this argument. It needs to be rephrased a bit in order to clearly spell out the fault of this argument. Instead of saying, "ORM models are too verbose", the argument should be phrased, "ORM does too good of a job documenting my system." See how silly that sounds?

Thus, one has a tradeoff; do you want something that completely specifies the problem, or do you want the model to fit nicely on one sheet of paper?

You answer determines how good your system will be.

ARGUMENT #3
You can create a virtually perfect model in ER and/or UML. Lots of people do; folks who are better known and more respected than you, Mr. Becker.

REBUTTAL
There are several points I'd like to address here. First, I too can create good models in ER and UML. However, I find I make less mistakes if I use ORM; as will you, I guarantee it. The simple act of learning how to model in ORM will make you a better ER modeler. I've told this to just about everyone I've ever mentored and/or taught ORM to and every one of them have later agreed with me. Learning ORM teaches your brain how to think about the problem.

The second point I'd like to address flows naturally from the first: Those folks who are real good at ER and UML pretty much think in the same manner, they just don't realize it. To be really good at ER modeling, one must think about the world in terms other than entities and attributes in order to have them correctly implemented in the terms of ER modeling (i.e. is this and entity or an attribute?). In other words, they think about objects and the roles they play. ORM just makes this thought process formal. So, assuming you are a good modeler, you are going to think about objects and roles anyway. Why not use a method that guarantees you will do this correctly? The Conceptual Schema Design Procedure (CSDP) virtually ensures success. Why do it the hard way?

ARGUMENT #4
The world is going UML; some people argue that traditional ER modeling is dead. Why should I learn another data-centric technique?

REBUTTAL
History will prove me correct on this, but for now, I aver: data-centric techniques are not dead, and if you want your project/product/program to last, you will account for data centric concerns such as integrity at the persistence layer.

This is really the topic of a much longer discussion, but ORM is a natural fit into the UML process flow, particularly at the analysis stage. I am doing this right now with great success.

UML tends to be too design and implementation centric. The exception being use cases whose narrative style is a natural fit with ORM's use of the natural language. ORM can document the "what" (data, static constraints, etc.) and use cases can document the "how" (process, dynamic rules, etc.).

If you use use cases and ORM (plus, perhaps, other business-rule centric techniques) in the analysis stage, your analysis artifacts will be better formed, more consistent, more accurate, and more concise. From there, design can worry about solving the problem. And that (application) design is often best specified in the UML particularly if your application architecture is complex. By the way, logical models are nice to have at this point as well.

The point is that ORM and UML are not mutually exclusive; they can be used in tandem, and the overall results are astoundingly better.

ARGUMENT #5
No large system has ever used ORM.

REBUTTAL
My response is always, "My clients would disagree."

ARGUMENT #6
Sure, ORM may capture more rules, but it places those rules at the database level, where they are cumbersome to change. We're using the latest and greatest whiz-bang .Net/J2EE distributed architectures, and...

REBUTTAL
You are mixing implementation concerns with analysis and design concerns. This is a fatal mistake. The requirements (business rules) exist whether or not you want to implement them at the database level. Capture the requirements first, and then decide what you are going to do about them.

ARGUMENT #7
My users won't understand yet another diagram type.

REBUTTAL
First, I think you underestimate the intelligence of your users (which is, frankly, a problem all in itself). In my experience, they pick up the notation very quickly.

Second, you don't have to show them the notation. In that case, don't show them the ER either (hint: If they can't understand ORM, they won't understand ER either!). ORM is rooted in the natural language. Show them sentences. If they don't understand the English (or whatever your natural language is) sentences, then your business is facing a more fundamental problem than your modeling notations and you should be focusing all of your energy on making your workforce literate before you attempt to improve your IT systems.

That's a bit tongue in cheek, I admit, but in all seriousness, users adapt to ORM very quickly. They like ORM's use of sentences just as much as they are comfortable with the narrative style of use cases.

CONCLUSION
Making the choice to use ORM is making the choice to think first and document second. ER can be derived from the ORM. Design and implementation can be derived (and, of course, adapted) from the ORM. Use ORM as an analysis technique and I guarantee you will better capture your requirements.

And that is what it is all about... isn't it?