4.3. Associations between Entity Types
Whenever an IS has to manage the data of more than one entity type, it is very likely that there are associations between some of them. For instance, in the following class diagram, there is an association between the entity types movies and directors, assigning a director to a movie.
An association between two or more entity types classifies relationships between entities of those types. For instance, the association movies-are-directed-by-directors, which is visualized as a connection line between the two involved entity types in the class diagram shown in Figure 4-4 above, classifies the relationships Pulp-Fiction-is-directed-by-Quentin-Tarantino, Star-Wars-is-directed-by-George-Lucas and Dangerous-Liaisons-is-directed-by-Stephen-Frears.
In general, associations are relationship types involving two or more entity types. An association between two entity types is called binary, while associations between more than two entity types are called n-ary (with the special case of 3-ary associations called ternary). Since n-ary associations rarely occur in information modeling projects, we do not consider them and we will simply say 'association' instead of 'binary association'.
An association between two entity types can be read in both directions. The association movies-are-directed-by-directors associates
a director with a movie, when read from left to right;
the movies directed by a director with this director, when read inversely (from right to left).
Normally, associations are read from left to right or top-down.
Associations may have a name, like "are directed by" in the class diagram shown in Figure 4-4 above. Such a name is only meaningful when it is supplemented by the names of the two entity types connected by the association, leading to a full name like movies-are-directed-by-directors.
Associations may also have a name for reading them in inverse direction (normally, from right to left). For instance, the association club-m embers-chair-committees, shown below in Figure 4-9, has the inverse name "are chaired by", allowing to read it as committees-are-chaired-by-club-members.
In addition to, or instead of, a name, an association may have names for its ends, which are also called role names because they denote the roles played by entities that participate in a relationship. For instance, the association people-buy-from-companies shown in Figure 4-11 below has names for both ends of the association, for people playing the role of customers, and for companies playing the role of suppliers.
Exemplar Models
Examples of entities and relationships between them can be described with the help of an exemplar model, also called object diagram in UML. We can for instance describe the director Quentin Tarantino together with a few movies he has directed, as shown in Figure 4-5.
This model describes four objects, one of type directors and three of type movies, as well as three relationships between them (called "links" in UML).
Attributes versus Associations
In the model shown in Figure 4-1, the information about the director of a movie is modeled in the form of an attribute holding the names of movie directors, while in the model of Figure 4-4, this information is modeled in the form of an association with the entity type people, such that we may store and retrieve further information about a director, in addition to the director's name.
This example illustrates a general pattern: whenever we do not need more information about entities of a certain type except their name, then these entity types need not be included in a conceptual model, and instead of using an association with such an entity type for being able to represent relationships with its entities, we can take a simpler approach and use attributes that hold the names of these entities.
Multiplicity Constraints and Functionality Types
Associations are characterized by multiplicity constraints, which restrict the possibilities of how many instances of one of the two associated classes can be linked to an instance of the other one. In the example of Figure 4-4, the association has the multiplicity expression 1..*, where the asterisk stands for unbounded (or many), at the side of the entity type movies, and 1, standing for exactly one, at the side of the entity type directors.These multiplicities mean that we have a many-to-one association between movies and directors, which captures the modeling assumptions that
- each movie has exactly one director,
- each director has directed one or more movies.
More precisely speaking, a multiplicity expression is a pair of numbers l..u specifying a lower bound l and an upper bound u, which constrain the number of associated entities to be at least l and at most u. The lower bound is also called minimum cardinality, and the upper bound is also called maximum cardinality. The multiplicity expression 1 is an abbreviation of 1..1 ("at least one" and "at most one"), while the multiplicity expression * is an abbreviation of 0..* ("zero or more"). Notice that the multiplicity expression * (or 0..*) means that there is no constraint (any number is admitted).
A binary association is functional, if it assigns at most one instance of one of the two involved entity types to an instance of the other type. A functional association has at least one functional association end (an association end with a multiplicity of either 0..1 or 1). When both ends of an association are functional, it has a functionality type of one-to-one. When only one end is functional, its functionality type is many-to-one or one-to-many, depending on the reading direction of the association. Since the association shown in Figure 4-4 assigns exactly one entity of type people as director to an entity of type movies, it's an example of a functional (many-to-one) association, as exactly one implies at most one.
An association end is non-functional, when its maximum cardinality is greater than 1. In most cases, a non-functional association end has the multiplicity * or 1..*. When both ends of an association are non-functional, its functionality type is many-to-many.
The following table provides an overview about the different cases of functionality of an association:
| Functionality type | Meaning |
|---|---|
| many-to-one | functional |
| one-to-many | inverse functional |
| one-to-one | both functional and inverse functional |
| many-to-many | neither functional nor inverse functional |
When we don't consider the reading direction of an association, it is functional in the first three cases, and non-functional in the last case.
An example of a many-to-many association is shown in Figure 4-6
Notice that this association does not define any maximum cardinality constraints, since both association ends allow any number of associated instances.
Associations May Have Attributes
For instance, the association movies-have-actors shown in Figure 4-6 would be more informative if it would state which role is played by which actor. For instance, in "Pulp Fiction", John Travolta plays the role of "Vincent Vega".
The attribute role cannot be added to the entity type movies, nor can it be added to the entity type actors. It has a value for each relationship of the association. Consequently, role is an attribute of the association, which can be modeled in a UML class diagram with the help of an association class, as shown in Figure 4-7.
An example of an actor playing zweitwo roles in two movies is shown in Figure 4-8.
The meaning of such a model will become more clear when it is shown how to implement it either in the form of classes of an OO program or in the form of relational database tables.
Verbalizing Multiplicity Constraints
Multiplicity constraints can be expressed in plain English, which helps to communicate their meaning to business domain (or subject matter) experts who are in charge to validate them in the analysis phase of an IS development project.
After a requirements analyst or database designer has expressed multiplicity constraints in a conceptual information model using the notation of UML class diagrams, they have to be validated by getting the confirmation of business domain experts. When these subject matter experts are not familiar with UML class diagrams, the constraints captured in the model can be verbalized, that is, they can be expressed using unambiguous English sentences. This approach has been pioneered by Richard Barker[1] and Terry Halpin who has published a series of articles on "Verbalizing Business Rules"[2].
The association club-members-chair-committees, shown below in Figure 4-9, has the multiplicity 0..1 at its right hand side end.
An association end with multiplicity 0..1 is functional, but not total. Its functionality constraint can be verbalized in the following way:
(RF+) Club members chair at most one committee.
where "R" stands for the right hand side association end and "F+" stands for being functional. This can also be expressed in negative form:
(RF'+) Club members must not chair more than one committee.
Notice that any constraint may be verbalized in both positive and negative form. The positive form of a constraint can be illustrated by a sample population of the association (that is, a set of exemplary relationships) satisfying the requirement expressed by a constraint. The negative form of a constraint can be illustrated by a counter-example that violates the constraint.
Consider the following table. Its first three rows represent an admissible population illustrating the positive form of the above functionality constraint, while the fourth row, in red, represents a counter-example that illustrates the negative form of that constraint.
| club-members-chair-committees | |
|---|---|
| Peter Miller | Finance Committee |
| Susan Smith | Recruitment Committee |
| Sarah Anderson | Advisory Committee |
| Sarah Anderson | Foreign Relations Committee |
The conceptual information model shown above in Figure 4-9 provides also a verb phrase, "are chaired by", for reading the association inversely as committees-are-chaired-by-club-members. This inverse reading allows verbalizing the multiplicity constraint expressed for the left hand side end of the association with the multiplicity 1 as "exactly one" (functional and total). This constraint can be verbalized in the form of the following two sentences:
(LT+) Committees are chaired by at least one club member.
(LF+) Committees are chaired by at most one club member.
where "LT+" and "LF+" stand for the left hand side association end being total and functional.
Like the multiplicity expression 1..1 can be abbreviated by 1, the two sentences (LT+) and (LF+) can be abbreviated by the following sentence:
(LT+F+) Committees are chaired by excactly one club member.
The sentences (RF+) and (LT+F+) together verbalize both the functionality and totality constraints implied by the multiplicities specified at both ends of the association club-members-chair-committees.
Exercise: Consider the association moons-orbit-planets shown in Figure 4-10 below. Verbalize the multiplicity constraint expressed for its right hand side end.
How to Clarify the Absence of Constraints
When analyzing the system requirements in an IS development project, the goal is not only to identify constraints, but also to clarify the absence of constraints.
The partiality (or non-totality) of the right hand side end of the association club-members-chair-committees, shown in Figure 4-9 above, can be verbalized in the following way:
(RT-) Club members may chair no committee.
where "RT-" stands for the right hand side association end being not total (or, in other words, optional).
Likewise, the non-functionality of the left hand side end of the association moons-orbit-planets, shown in Figure 4-10 above, can be verbalized in the following way:
(LF-) Planets may be orbited by more than one moon.
In the next example, shown in Figure 4-11, both ends of the association people-buy-from-companies have the multiplicity zero or more and, consequently, the association's functionality type is many-to-many, so it does not have any functionality constraint.
In addition, since both association ends have a lower multiplicity of 0, they are not total, but partial. Consequently, the association does neither have a functionality nor a totality constraint. This can be verbalized in the following way:
(RT-) People may buy from no company.
(RF-) People may buy from more than one company.
(LT-) Companies may sell to no person.
(LF-) Companies may sell to more than one person.
Association end names (also called Drole names), like customers and suppliers in Figure 4-11 above, allow an alternative verbalization:
(RT-) People may have no company as supplier.
(RF-) People may have more than one company as supplier.
(LT-) Companies may have no person as customer.
(LF-) Companies may have more than one person as customer.