9.4. Associations

UML uses Boolean attributes instead of unary relationships, but allows relationships of all other arities. Optionally, each association may be given at most one name. Association names normally start with a capital letter. Binary associations are depicted as lines between classes. Association lines may include elbows to assist with layout or when needed (e.g., for ring relationships). Association roles appear simply as line ends instead of boxes, but may be given role names. Once added, role names may not be suppressed. Verbalization into sentences is possible only for infix binaries, and then only by naming the association with a predicate reading (e.g., “Employs”) and using an optional marker “▸” to denote the direction.

Figure 9.10 depicts two binary associations in both UML and ORM. On the UML diagram, the association names, their directional markers, and some role names are displayed. In UML, association names are optional, but role names are mandatory. If a role name is not supplied, the role’s name is assumed to be the name of its class (e.g., “employee”). If two or more roles are played by the same class, the roles must be given different names to distinguish them (e.g., “buyer”, “acquisition”). In the ORM diagram, forward and inverse predicate readings are shown; at most one of these may be omitted. Role names are optional in ORM, and their display (in square brackets) may be toggled on or off.

Ternary and higher arity associations in UML are depicted as a diamond connected by lines to the classes, as shown in Figure 9.11(a). Because many lines are used with no reading direction indicator, directional verbalization is ruled out, so the diagram can’t be used to communicate in terms of sentences. This non-linear layout also often makes it impractical to conveniently populate associations with multiple instances, unless we use role names for column names. Add to this the impracticality of displaying multiple populations of attributes, and it is clear that class diagrams are of little use for population checks.

As discussed earlier, UML does provide object diagrams for instantiation, but these are convenient only for populating associations with a single instance. Adding multiple instances leads to a mess (e.g., Blaha and Premerlani 1998, p. 31). Hence, as noted in the UML Notation Guide, “the use of object diagrams is fairly limited”.

The previous section discussed how UML depicts multiplicity constraints on attributes. A similar notation is used for associations, where the relevant multiplicities are written next to the relevant roles. Figure 9.12(a) adds the relevant multiplicity constraints to Figure 9.10(a). A “*” abbreviates “0..*”, meaning “zero or more”, “1” abbreviates “1..1”, meaning “exactly one”, and “0..1” means “at most one”. If no multiplicity is supplied for an association role, “*” is assumed by default (unlike attributes, where 1 is the default multiplicity).

UML places each multiplicity constraint on the “far role”, in the direction in which the association is read. Hence the constraints in this example mean that each company employs zero or more employees, each employee is employed by exactly one company, each company acquired zero or more companies, and each company was acquired by at most one company.

The corresponding ORM constraints are depicted in Figure 9.12(b). Recall that multiplicity covers both cardinality (frequency) and optionality. Here the mandatory role constraint indicates that each employee works for at least one company, and the uniqueness constraints indicate that each employee works for at most one company, and each company was acquired by at most one company.

For comparison purposes, Figure 9.13 depicts the n:1 association Moon orbits Planet in various notations. The instance diagram in Figure 9.13(a) includes a sample population of moons (p = Phobos, d = Deimos, c = Callisto) and planets (v = Venus, m = Mars, j = Jupiter). For illustration purposes, the ORM diagram in Figure 9.13(e) also includes the sample object and fact populations. The population is significant with respect to multiplicity constraints. Each planet orbits exactly one moon, and the same planet may be orbited by zero or more moons.

The UML (Figure 9.13(b)) and Information Engineering (Figure 9.13(c)) approaches are similar because both express the constraints in terms of multiplicities/cardinalities. In contrast, Barker ER (Figure 9.13(d)) and ORM (Figure 9.13(e)) capture some constraints in terms of mandatory/optional roles and other constraints in terms of cardinality/uniqueness constraints. As shown later, the failure of UML to separate out these two kinds of constraint prevents it from graphically capturing various cases it might otherwise have handled.

For binary associations, there are four possible uniqueness constraint patterns (n:1, 1:n; 1:1 m:n) and four possible mandatory role patterns (only the left role mandatory, only the right role mandatory, both roles mandatory, both roles optional). Hence if we restrict ourselves to a maximum frequency of one, there are 16 possible multiplicity combinations for binary associations. The 16 cases are shown in Figure 9.14, in both UML and ORM.

UML allows multiplicity constraints with whole numbers other than zero or one, and also supports multiplicity lists or ranges (e.g., “1..7, 10”). For such cases, ORM uses frequency constraints instead of uniqueness constraints. ORM is more expressive in this regard, since it can apply such constraints to arbitrary collections of roles, not just single roles.

For an elementary n-ary association, each internal uniqueness constraint in ORM must span at least n - 1 roles. In UML, a multiplicity constraint on a role of an n-ary association effectively constrains the population of the other roles combined. For example, Figure 9.15(a) is a UML diagram for a ternary association in which both Room-HourSlot and HourSlot-Activity pairs are unique. For simplicity, reference schemes are omitted.

An ORM depiction of the same association is shown in Figure 9.15(b). The left-hand uniqueness constraint indicates that Room-HourSlot is unique (i.e., for any given room and hour slot, at most one activity is booked). The right-hand uniqueness constraint indicates that HourSlot-Activity is unique (i.e., for any given hour slot and activity, at most one room is booked). An extended version of this example was discussed in Section 1.2, where the ORM diagram better facilitated constraint checking by verbalization and population.

Because it covers some n-ary cases like this, UML’s multiplicity constraint notation is richer than the optionality/cardinality notation of typical ER. However there are many cases with n-ary associations where the multiplicity notation of UML is incapable of capturing even a simple mandatory role constraint, or a minimum frequency constraint above 1. In contrast, the mandatory, uniqueness, and frequency constraint notation of ORM can capture any possible constraint of this nature, on roles or role sequences, on predicates of any arity. So ORM is far richer in this regard.

For example, suppose we modify our room booking example to indicate that all activities have a room-hourslot booking and also have unique names as well as their identifying codes. The modified example, including reference schemes, is shown in Figure 9.16 in both UML and ORM. Because UML bundles both mandatory and uniqueness into a single notion of multiplicity, it cannot capture the constraint that each activity has a booking graphically. The best we can do is add a note, as shown in Figure 9.16(a). This constraint may be expressed graphically in ORM using a mandatory role constraint, as shown in Figure 9.16(b).

This deficiency in UML is a direct consequence of choosing to attach minimum multiplicity to a role other than the immediate role. For the same reason, UML multiplicity constraints are also unable to capture various ORM frequency constraints. In general, given any n-ary (n > 2) association, if an ORM mandatory or frequency constraint applies to at least 1 and at most n - 2 roles, this cannot be captured by a UML multiplicity constraint. Some examples of such cases are shown in Figure 9.17. Further discussion on such cases may be found in Halpin (2000c).

Unlike many ER versions, both UML and ORM allow associations to be objectified as first class object types, called association classes in UML and objectified associations or nested object types in ORM. UML requires the same name to be used for the original association and the association class, impeding natural verbalization of at least one of these constructs. In contrast, ORM nesting is based on linguistic nominalization (a verb phrase is objectified by a noun phrase), thus allowing both to be verbalized naturally, with different readings for each.

Although UML identifies an association class with its underlying association, it displays them separately, connected by a dashed line (see Figure 9.18(a)). Each person may write many papers, and each paper is written by at least one person. Since authorship is m:n, the association class Writing has a primary reference scheme based on the combination of person and paper (e.g., the writing by person ‘Norma Jones’ of paper 33). The optional period attribute stores how long that person took to write that paper.

Figure 9.18(b) shows an ORM schema for this domain. The objectified association Writing is marked independent (by the “!”) to indicate that a writing object may exist, independently of whether we record its period. ORM displays Period as an object type, not an attribute, and includes its unit.

UML allows any association (binary and above) to be objectified into a class, regardless of its multiplicity constraints. In particular UML allows objectification of n: 1 associations, as shown in Figure 9.19 (a). While this is allowed in ORM 2, it is often a case of poor modeling. For example, given that a moon orbits only one planet, an orbital period may be related directly to the moon without including the planet. So instead of objectifying, we could model the orbital period in UML as an attribute of Moon, or in ORM as an association between Moon and Period. Chapter 10 provides heuristic guidelines for applying objectification in modeling.

Earlier we saw that UML has no graphic notation to capture ORM external uniqueness constraints across roles that are modeled as attributes in UML. Hence we introduced a {UH} notation to append textual constraints to the constrained attributes. Simple cases where ORM uses an external uniqueness constraint for coreferencing can also be modeled in UML using qualified associations. Here, instead of depicting the relevant ORM roles or object types as attributes, UML uses a class, adjacent to a qualifier, through which connection is made to the relevant association role. A qualifier in UML is a set of one or more attributes whose values can be used to partition the class, and is depicted as a rectangular box enclosing its attributes. Figure 9.20 is based on an example from the official UML specification, along with the ORM counterpart.

Here each bank account is used by at most one client, and each client may use many accounts. In the UML model, the attribute accountNr is a qualifier on the association, effectively partitioning each bank into different accounts. In the ORM model, an Account object type is explicitly introduced and referenced by combining its bank with its (local) account number.

The UML notation is less clear and less adaptable. For example, if we now want to record something about the account (e.g., its balance) we need to introduce an Account class, and the connection to accountNr is unclear. For a similar example, see Fowler (1997, p. 92), where product is used with Order to qualify an order line association; again, this is unfortunate, since we would normally introduce a Product class to record data about products, and relevant connections are then lost.

As a complicated example of this deficiency, see Blaha and Premerlani (1998, p. 51) where the semantic connection between Node and nodeName is lost. The problem can be solved in UML by using an association class instead, although this is not always natural. The use of qualified associations in UML is hard to motivate, but may be partly explained by their ability to capture some external uniqueness constraints in the standard notation, rather than relying on nonstandard textual notations (such as our {Un} notation).

ORM’s concept of an external uniqueness constraint that may be applied to a set of roles in one or more predicates provides a simple, uniform way to capture all of UML’s qualified associations and unique attribute combinations, as well as other cases not expressible in UML graphical notation (e.g., cases with m:n predicates or long join paths). As always, the ORM notation has the further advantage of facilitating validation through verbalization and multiple instantiation.