Modeling and Designing Databases - Learning MySQL - page 120

Passenger

1

Makes

N

Booking

N

1

Flight Is for

Figure 4-8. The intermediate booking entity between the passenger and flight entities

some key information for entities that are dependent on other entities. For example, if
we wanted to store the names of our customers' children, we could create a child entity
and store only enough key information to identify it in the context of its parent. We
could simply list a child's first name on the assumption that a customer will never have
several children with the same first name. Here, the child entity is a weak entity, and
its relationship with the customer entity is called an identifying relationship . Weak en-
tities participate totally in the identifying relationship, since they can't exist in the da-
tabase independently of their owning entity.
In the ER diagram, we show weak entities and identifying relationships with double
lines, and the partial key of a weak entity with a dashed underline, as in Figure 4-9. A
weak entity is uniquely identified in the context of its regular (or strong ) entity, and so
the full key for a weak entity is the combination of its own (partial) key with the key of
its owning entity. To uniquely identify a child in our example, we need the first name
of the child and the email address of the child's parent.
Figure 4-10 shows a summary of the symbols we've explained for ER diagrams.

Entity Relationship Modeling Examples
Earlier in this chapter, we showed you how to design a database and understand an
Entity Relationship (ER) diagram. This section explains the requirements for our three
example databases— music , university , and flight —and shows you their Entity Re-
lationship diagrams:

• The music database is designed to store details of a music collection, including the
albums in the collection, the artists who made them, the tracks on the albums, and
when each track was last played.