Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Disadvantages ORM/UML/ER

Re: Disadvantages ORM/UML/ER

From: Scot A. Becker <scot_at_orthogonalsoftware.com>
Date: Thu, 9 May 2002 20:29:32 -0500
Message-ID: <vmFC8.1288$5a.51576@twister.kc.rr.com>


"Albert Vaeter" <a_vaeter_at_hotmail.com> wrote in message news:ce7804bc.0205091034.4143972a_at_posting.google.com...
> Thanks for the links. I've read some parts very fast to get an
> overview. Because that site is all about ORM I think it is a little
> bit coloured about the (dis)advantages.
>
> I hoped the newsgroupreaders could tell what they like or dislike
> about UML, ORM and ER. Maybe you can tell someting about your
> experiences?

Well if you are worried about biased sources, you may not want my input. I: am certified (by Terry) to consult and instruct in the use of ORM, use ORM as the basis of my consulting practice, write about the topic, train ORM, speak about ORM to DAMA groups and the like, was one of the reviewers for Terry's latest book on the topic, consider Terry a friend and trusted colleague, etc.

... just making a full disclosure before I opine. <g>

From a notational standpoint -- meaning from the point of view of comparing the techniques as a language -- Terry's articles can be taken with the same authority as any other academic writing. He does a very good job of decomposing the languages and comparing them on an "apples-to-apples" basis. For example, if you read some of his writings on UML, you'll see that certain types of constraints cannot be expressed using UML (*) but can be expressed by using ORM.

(*) UML supports the addition of a textual constraints, so technically any constraint that can be written down can be "expressed" in UML, but I am talking about expressing constraints with the _graphical_ language. BTW, ORM supports textual constraints as well, for the stuff not handled by its graphical language.

His subsequent conclusion (use ORM) could be taken as subjective and biased I suppose, although I happen to agree with it. But the assertions about the capabilities of the langauges stand, and if you can find errors in those comparisons, I'd like to see them (as would Terry, I am sure).

So... After comparing the languages themselves, ORM has them beat, at least for the purposes of data modeling. It is far more expressive than UML/ER forms. For example, you can express constraints that would be the equivalent of "attribute" constraints in UML/ER. An example might be "either attribute X is supplied or attribute Y is supplied, but not both". Some ER forms (e.g. Barker/Oracle) and UML support this or-constraint on _relationships_ -- but not attributes.

ORM's use of a natuaral language means I can validate models with no "training" of the user community. I never _have_ to explain what an Entity/Class/Object is. In that scenerio, I can just read the English sentences (of both model elements and constraints) and have the user validate them.

But the real argument about ORM vs. ER vs. UML usually doesn't focus on the ability of the language (any more than I would want to box Tyson, I suppose <g>). It usually focuses on more subjective things like clutter on the page, corporate standards on notations/tools/methods et al., or that fact that there are good modelers out there who can create good models in ER/UML.

When it comes down to how one prefers to work, it isn't always based on quantitative factors. I work better with the Rollins Band playing very, very loud. Others find my work environment disagreeable <shrug>. Fortunately, the music is loud enough to drown out thier whining. <s>

BTW, a recent but similar discussion on ORM has occured/is occuring on the DM-Discuss list that I and several others (including Mr. Tiseo) have posted to. I believe those posts are available without subscribing, so you might want to look for the group at yahoogroups.

If corporate standards or communication with non-ORM trained folks is the reason you don't want to use it, remember that ORM is essentially a collection of functional dependencies. This means you can derive the ER/UML view. Oh and by the way, that derivation is fully normalized.

Finally, I will say this: learing ORM will make you a better modeler even if you don't use it. Training your brain to think about data models using only two constructs (objects and their relationships to other objects) will keep you from making the errors associated with introducing the third concept, attributes (ala ER/UML). I aver that those good modelers I referred to (above, who use ER/UML to create those good models) ARE thinking in those terms and THEN are mapping them to Entites or Attributes (mentally, if not otherwise).

As you can see, I am quite rabid about my opinions on this matter and can rant for days. I have a few papers of my own avialable at my website that you might like to browse. Also, if you have any specific questions on ORM, feel free to post and I'd be happy to step back on the soapbox. <g>

Hope that helps,
Scot.



Scot A. Becker

Software Consultant & Founder
Orthogonal Software Corporation
http://www.orthogonalsoftware.com Received on Thu May 09 2002 - 20:29:32 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US