Data Modeling with the Entity-Relationship Model - Database Processing: Fundamentals, Design, and Implementation - page 183

(a) Example Binary Relationship

EMPLOYEE SKILL

Qualification

(b) Example Ternary Relationship

Assignment

CLIENT ARCHITECT

Figure 5-4
Binary Versus Ternary
Relationships

PROJECT

In the original E-R model, relationships could have attributes. Today, that feature is no
longer used.
Relationships are given names that describe the nature of the relationship, as shown in
Figure 5-4. In Figure 5-4(a), the Qualification relationship shows which employees have which
skills. In Figure 5-4(b), the Assignment relationship shows which combinations of clients, ar-
chitects, and projects have been created. To avoid unnecessary complexity, in this chapter we
will show the names of relationships only if there is a chance of ambiguity.

By ThE Way Your instructor may believe that it is important to always show the name
of a relationship. If so, be aware that you can name a relationship from the
perspective of either of the entities or both. For example, you can name the relationship
between DEPARTMENT and EMPLOYEE as Department Consists Of; or you can name
it as Employee Works In; or you can name it both ways, using a slash between the two
names, Department Consists Of/Employee Works In. Relationship names are a neces-
sity when there are two different relationships between the same two entities.

A relationship class can involve two or more entity classes. The number of entity classes in
the relationship is the degree of the relationship. In Figure 5-4(a), the Qualification relationship
is of degree two because it involves two entity classes: EMPLOYEE and SKILL. In Figure 5-4(b),
the Assignment relationship is of degree three because it involves three entity classes: CLIENT,
ARCHITECT, and PROJECT. Relationships of degree two are referred to as binary relation-
ships . Similarly, relationships of degree three are called ternary relationships .
When transforming a data model into a relational database design, relationships of all
degrees are treated as combinations of binary relationships. The Assignment relationship in
Figure 5-4(b), for example, is decomposed into three binary relationships (can you spot them?).
Most of the time, this strategy is not a problem. However, some nonbinary relationships need
additional work, as you will learn in Chapter 6. All data modeling software products require
you to express relationships as binary relationships.

By ThE Way At this point, you may be wondering, “What's the difference between an
entity and a table?” So far, they seem like different terms for the same
thing. The principle difference between an entity and a table is that you can express
a relationship between entities without using foreign keys . In the E-R model, you can
specify a relationship just by drawing a line connecting two entities. Because you are
doing logical data modeling and not physical database design, you need not worry