Database Reference
In-Depth Information
CLIENT
ARCHITECT
ClientName
ArchitectName
Email
Phone
Office
Email
ASSIGNMENT
ClientName
ArchitectName
ProjectName
HoursWorked
PROJECT
Figure 5-23
Association Pattern Data
Model for the Ternary
Relationship in Figure 5-4
ProjectName
StartDate
Budget
Associations can occur among more than two entity types. Figure 5-23, for example,
shows a data model for the assignment of a particular client to a particular architect for a
particular project. The attribute of the assignment is HoursWorked. This data model shows
how the ternary relationship in Figure 5-4(b) can be modeled as a combination of three binary
relationships.
The Multivalued attribute Pattern
In the E-R model as used today,
5
attributes must have a single value. If the COMPANY entity
has PhoneNumber and Contact attributes, then a company can have at most one value for
phone number and at most one value for contact.
In practice, however, companies can have more than one phone number and one contact.
Consider, for example, the data entry form in Figure 5-24. This particular company has three
phone numbers; other companies might have one or two or four or whatever. We need to cre-
ate a data model that allows companies to have multiple phones, and placing the attribute
PhoneNumber in COMPANY will not do it.
Figure 5-25 shows the solution. Instead of including PhoneNumber as an attribute
of COMPANY, we create an ID-dependent entity, PHONE, that contains the attribute
PhoneNumber. The relationship from COMPANY to PHONE is 1:N, so a company can have
multiple phone numbers. Because PHONE is an ID-dependent entity, its identifier includes
both CompanyName and PhoneNumber.
Figure 5-24
Data Entry Form with a
Multivalued Attribute
5
The original E-R model allowed for multivalued attributes. Over time, that feature has been ignored, and today
most people assume that the E-R model requires single-valued attributes. We will do so in this text.
Search WWH ::
Custom Search