Databases Reference
In-Depth Information
Given names
Surname
M
Number
Customer
Buys
Email address
Timestamp
N
Telephone number
Name
Product
Postal address
Price
Street address
Product ID
City
ZIP code
Country
Figure 4-4. The ER diagram representation of the customer and product entities, and the sale
relationship between them.
times change their names; in some applications, such as police databases, this is of
particular interest, and so it may be necessary to model a many-to-many relationship
between a person entity and a name entity. Redesigning a database can be
time-consuming if you assume a relationship is simpler than it really is.
In an ER diagram, we represent a
relationship set
with a named diamond. The cardin-
ality of the relationship is often indicated alongside the relationship diamond; this is
the style we use in this topic. (Another common style is to have an arrowhead on the
line connecting the entity on the “1” side to the relationship diamond.) Figure 4-4 shows
the relationship between the customer and product entities, along with the number
and timestamp attributes of the sale relationship.
Partial and Total Participation
Relationships between entities can be optional or compulsory. In our example, we
could decide that a person is considered to be a customer only if they have bought a
product. On the other hand, we could say that a customer is a person whom we know
about and whom we hope might buy something—that is, we can have people listed as
customers in our database who never buy a product. In the first case, the
customer
entity
has
total participation
in the bought relationship (all
customer
s have bought a product,
and we can't have a
customer
who hasn't bought a product), while in the second case
it has
partial participation
(a
customer
can buy a product). These are referred to as the
