Database Reference
In-Depth Information
The ORM constraint notation is unambiguous and orthogonal. UML constraints don't
always meet these criteria. As a simple example, consider the exclusive-or constraint in
Figure 15(a). This verbalizes in ORM as:
each
Vehicle was purchased from
a
Company
or
leased from
a
Company
but not both
. In ORM, an exclusive-or constraint is an orthogonal
combination of an inclusive-or constraint (circled dot) and an exclusion constraint (circled
X), and may even be displayed as these two separate constraints if desired, as shown in Figure
15(b). Although UML lacks both an inclusive-or constraint and an exclusion constraint, it
does include an exclusive-or constraint as a primitive constraint, using the notation “{xor}”.
Unfortunately, the UML metamodel defi nes the xor constraint to apply between associa-
tions, not association ends. This leads to ambiguity when two roles are played by the same
class. For example, the xor constraint in Figure 15(c) is ambiguous, because formally we
have no way of knowing whether it means the constraint verbalized earlier, or the constraint
that each Company sold a Vehicle or leased a Vehicle but not both. Such constraints may
be disambiguated by adding an OCL expression (Warmer & Kleppe, 1999), but clearly the
metamodel should be altered to avoid such ambiguity in the fi rst place.
There are several other aspects of the UML metamodel that need improving to make
it more suitable for conceptual analysis. For example, associations should allow multiple
readings, and association classes should be able to be named using noun phrases distinct
from the verb phrases used for their underlying association. In spite of such problems, UML
is clearly superior to both ER and ORM for the detailed design of object-oriented code. Each
of the methods discussed in this chapter has its own strengths and weaknesses.
CONCLUSIONS
The ORM metamodels provided for IE, Barker ER and ORM clarify commonalities
and differences between the different data modeling notations. The use of non-derived con-
straints on derived fact types can be convenient, especially for expressing complex rules,
so long as the usage is controlled. Exclusive-or constraint notations in IE and Barker ER
are unorthogonal. The UML, IE and Barker ER approaches use multiplicity notations that
do not scale properly for n-ary associations.
ORM was designed for orthogonality and expressibility from the ground-up. The most
debatable aspect of ORM is that it avoids attributes in its base conceptual models, though
attribute-based models can be automatically derived from ORM models when desired
(Campbell et al., 1996). Combined with its richer constraint language, this tends to make
ORM diagrams larger than corresponding models in the other notations. This disadvantage
is a price many modelers are willing to pay to see the extra detail and domain connected-
ness. One advantage of ORM's role-based approach is that its small set of metaconcepts
and syntactical elements can specify a wide range of rules in a uniform way. In contrast,
attribute-based approaches often lose expressibility if fact types are modeled as attributes
instead of associations. For example, xor constraints in IE, Barker ER or UML can be ap-
plied only between association roles, not between attributes or between roles and attributes.
There is no reason in principle for this restriction, but pragmatically to remove such restric-
tions would add considerable complexity, requiring additional notations and metarules. The
same comment applies to the many additional kinds of constraint supported in ORM. This
suggests that the only effi cient way to achieve such expressibility without complexity is to
adopt an attribute-free approach, as in ORM.
