Business Advantages
ORM’s use of a natural language (e.g., English, but it works with any language) is the strongest reason to use ORM from a business user perspective. Although ORM’s diagrams are fairly intuitive they are in effect supplemental because the model is nearly entirely expressible in the fact verbalizations (as supplied by the business users in the first place) and by the derived verbalizations of the constraints on those facts.
You begin both ER and ORM diagramming by merely asking users to verbalize – in their own language – the facts they wish the new system to capture and provide some fact examples. From there, you use this input to form the structure of the model and the constraints on that structure. Notice how regardless of the technique, the same information is needed in order to correctly model the business/system.
Now, you need to verify this structure with the business users. In ER (or UML), this typically means you end up reviewing a diagram (or some sort of “data dictionary”) and need to explain what you mean by entity, relationship, attribute, foreign key, class, or association. And this is giving the information analyst the benefit of the doubt and assuming they aren’t discussing the even more esoteric concepts of tuples, relations, and normalization theory with their business users!
In ORM, you only need reproduce the (previously supplied) fact verbalizations and examples along with the (derivable) constraint verbalizations on these facts. The business users need only to review a textual document written in their own language.
Combining jargon-free modeling with the ability to annotate the diagram with example facts, which is cumbersome if not impossible with ER/UML but nonetheless useful when illustrating the concepts and verifying the constraints, and ORM is a clearly a great choice for conceptual modeling with business users.
Technical Advantages
In addition to the semantic advantages ORM offers when communicating with your business users, ORM also has a number of technical features which make it superior to traditional ER and UML diagramming (for static data structures).
Because ORM makes no distinction between an attribute and an entity/class, ORM constraints can be applied upon any role. For example, ER and UML notations typically lack a way to express if an attribute is mandatory based on another attribute (if A is supplied B must be supplied as well), if an attribute’s population is mutually exclusive of another attribute’s population (if A is supplied B cannot be and visa versa), or a series of attributes are in a disjunction such that at least one of them must be supplied (either A or B must be supplied, possibly both). Some ER notations and UML can often express these constraints upon relationship/association populations, but not upon attribute populations.
ORM also has a number of constraints not found in any other notation. For example, given the fact type “Person is parent of Person”, constraints can be applied to ensure that no person is a parent of themselves, no person is a parent of their grandchild (or great grandchild, and so on), and no person can be a parent of anyone who is a parent of that person (or any other similar cycle).
ORM can also express constraints across join paths that are impossible to express in ER/UML. For example, consider the fact types “Person works on Project”, “Project is sponsored by Department” and “Person works for Department”. These facts will usually create a structure of three or so entities that are related to each other. If we wanted to constrain the population such that no person could work on a project not sponsored by the department for which they work, it can be easily done in ORM, but not in ER/UML.
Similarly, ORM can express uniqueness constraints that span columns not in the same table, something that is not possible in ER/UML, as well as some other similar “join-based” constraints.
ORM’s technical advantages don’t rest solely on its rich constraint language, however. Remember that regardless of the notation, the same information is needed in order to create an accurate and complete model. The difference is that ORM captures more detail than every dialect of ER and UML. As such, the ER/UML diagrams of a model can be completely derived from the semantics already captured in the ORM model. This is, of course, assisted by the use of an ORM tool , but can easily be done manually as well.
In addition, because ORM is modeling elementary facts, and not clusters of attributes, ORM can be inherently mapped to a “fully” normalized structure . In other words, with the push of a button on an ORM tool, your logical model is completely derived and normalized.
ORM allows fact types of any arity, or number of roles. Most ER notations are intrinsically binary: exactly two entities participate in a relationship. This often causes arbitrary (and often, unnatural) entities to be created when three or more entities are inter-related. UML does offer n-ary (any arity) relationships between classes, although the underlying meta-model is inherently binary and as such some cardinality constraints cannot be expressed using UML’s n-ary association .
ORM object types are nothing more than semantic domains that can be easily re-used. Instead of creating multiple attributes of the same domain such as activation date, cancellation date, insert date, last update date, and so on, ORM would create one object type (Date), defined exactly once, that plays multiple roles (activation, cancellation, insert, update, and so on).
ORM fact structures are can be readily populated with sample data, something ER lacks but UML does have, albeit awkwardly implemented . Although the use of such data has been touched upon above, one more thing to consider is that once sample data is captured and populated, you now have actual real-world test data you can use to populate the resulting database schema too.
Finally, ORM diagrams are intrinsically more stable than their ER/UML counterparts. Changes to the constraints on ORM fact types can yield different ER representations, especially when it comes to the attribute-or-entity decision. For example, consider the fact type "Person drives Car". If a person drives only one car, car becomes an attribute of the person entity. If a person can drive more than one car but a car can be driven by only one person, person becomes an attribute of the car entity. If a person can drive more than one car and a car can be driven by more than one person, an intersection entity is applied to express this many-to-many relationship. In ORM, the base fact type, "Person drives Car", is unchanged; It is the constraints upon the fact type that are changed.