The other half of the ER diagram is the relationship. A relationship is a model of the association between objects of one or more different entity types. You can do the same kind of formal language expansion for relationships that appeared in the above section "Entities and Attributes" for entities. Relationships show how each entity connects to other entities. They correspond to mappings between attributes of the different entities. These mappings can be objects in their own right, having properties and primary keys (more on that later in the section "ER Business Rules"). Figure 6-3 shows two entities, Person and
CriminalOrganization, mapped to one another with a relationship "plays a role in."
The ER relationship is omnidirectional; that is, each entity relates to all the other entities in the relationship and can "see" those entities. Each side of the relationship (the line connecting the diamond to the
rectangle) is a role, the function of the entity in the relationship. You can name each role for clarity, though you need not. Conventionally, you use verbs for relationship and role names and nouns for entity names. You then construct sentences with the appropriate subject and object.
Figure 6-4 shows the relationship between the Person entity and the Identification entity. From the person's perspective, a person is identified by a set of identification papers. From the identification perspective, an identification identifies a person. The person-side role name is therefore "is identified by," while the identification-side role name is "identifies." This active-passive mode naming is very common, though
certain kinds of relationships evade such easy naming. You can choose to name the relationship with one or the other role name or a separate name that makes sense in the context. In the case of Figure 6-4, the relationship is "identifies," which makes sense in the context.
Figure 6-3: A Relationship between Two Entities
Figure 6-4: Roles in a Relationship
Note
A common trap is to fall into the uniqueness fallacy when naming roles. For years, all names in a database had to be unique. There was no concept of scope, or name space. All database systems now let you scope most names to an appropriate level in the schema, so there is really no reason to make all attribute names unique. Role names (which may correspond to attribute names in the relational table or class) need not be unique either. The point of the role name is clarity: what the relationship means in the context of the entity. "Has" is often good enough, or you might want to include a noun object ("has an address," for example, in the relationship between Person and Address). In OO design, encapsulation upgrades this feature to a principle; names within a class should reflect the perspective of the class, not the unique names of all the other classes in the system. As you will see in Chapter 7, another way to think of role names is as class property names, which are of necessity scoped to the class and therefore unique only within the class.
IDEF1X dispenses with the diamonds and represents the relationships with just a labeled line. The crow's- foot notation similarly represents relationships. Figure 6-5 shows the "identifies" relationship in those notations.
Figure 6-6 illustrates a special relationship. The recursive relationship relates entity objects to others of the same type. In this example, you want to model the relationship between criminal organizations. A criminal organization can be a part of another criminal organization, or indeed several such organizations. Figure 6- 6 shows this relationship in Chen, IDEF1X, and crow's-foot notations.
A relationship can have properties of its own in addition to the entities that it relates. For example, you might want to have an attribute on the "plays a role in" relationship in Figure 6-3 that names the role (Boss, Underboss, Lieutenant, and so on). This feature of ER diagramming expands the semantics of the
relationship to considering the relationship as an object in its own right with its own properties. The classic example of this is marriage. A marriage is a relationship between two people that has legal properties as an object. You can model these objects as entities, but they are really relationships with all the associated semantics of relationships.
Figure 6-5: The "identifies" Relationship in IDEF1X and Crow's-Foot Notations
Figure 6-6: The Recursive Relationship in Various Notations
A relationship has several properties of interest to the database designer:
The number of objects that can participate in a role
The number of objects that must participate in a role
The number of entities that participate in the relationship
Whether the relationship is strong (independent) or weak (dependent)
These properties are the major way an ER diagram defines business rules, the subject of the "ER Business Rules" section that follows. Every dialect has a different way to express these constraints. First, however, there are some extensions to ER modeling that introduce a different kind of relationship: a semantic one.