Association Relationships

As we discussed in Chapter 5, an association relationship is subtly close to an N:M relationship between two strong entities. The only difference between the two types of relationships is that an association relationship has one or more attributes that pertain to the relationship and not to either of the entities. These attributes must be added to what would otherwise be the intersection table in the N:M relationship. Figure 6-12(a) shows the association relationship data model created in Figure 5-22. In this example, the association of a company and a part carries an attribute named Price.

The representation of such a relationship using a table is straightforward. Just create a table that is ID-dependent on both of its parents and place the Price attribute in that table. The result for the example in Figure 6-12(a) is the table:

QUOTATION (CompanyName, PartNumber, Price)

This table appears in the database design in Figure 6-12(b). Like all ID-dependent relationships, the parents of an association table are required. The parents may or may not require

Figure 6-11

• Representing N:M Relationships

Four Uses for ID-Dependent

• Association Relationships

Entities

• Multivalued Attributes • Archetype/Instance Relationships

Chapter 6 Transforming Data Models into Database Designs

QUOTATION PartNumber

CompanyName Price

(a) Association Pattern Data Model from Figure 5-22

QUOTATION PartNumber (FK)

Figure 6-12

CompanyName (FK)

Using ID-Dependent Price Entities in an Association

Relationship (b) Association Pattern Database Design

the rows of the association table, depending on application requirements. In Figure 6-12(b), a COMPANY need not have any QUOTATION rows, but a PART must have at least one QUOTATION row.

The table that represents the association entity looks very much like an intersection table; the only difference is the presence of the Price attribute.

Because of the attribute, the need for association tables, such as QUOTATION, will appear in user requirements. Somewhere there will be a form or a report that has the attribute Price. However, the need for intersection tables never appears in the users’ world. Such tables are an artifact of the relational model, and no form, report, or other user requirement will indicate the need for one.

Intersection tables complicate the construction of applications. They must be processed to obtain related rows, but they never directly appear on a form or report. In Microsoft Access they are frustratingly difficult to mangle into the form and report design tools. You will see more about this in later chapters. In any case, for now under- stand the key difference between association and intersection tables: Association tables have user data, but intersection tables do not.

Part 2 Database Design

As shown in Figure 6-13, association entities sometimes connect more than two entity types. Figure 6-13(a) shows the association relationship among the CLIENT, ARCHITECT, and PROJECT entities from the data model we created in Figure 5-23. When there are several participants in the association, the strategy just shown is simply extended. The association table will have the key of each of its parents, as shown in Figure 6-13(b). In this case, the ASSIGNMENT table has three foreign keys and one nonkey attribute, HoursWorked.

In both of these examples, it is only coincidence that the association tables have only one nonkey attribute. In general, an association table can have as many nonkey attributes as necessary to meet user requirements.

Figure 6-13

ARCHITECT Using ID-Dependent Entities

CLIENT

ArchitectName in an Association

Relationship Among Three

ClientName ArchitectName ProjectName

HoursWorked

PROJECT ProjectName

StartDate Budget

(a) Association Pattern Data Model from Figure 5-23

ASSIGNMENT ClientName (FK)

ArchitectName (FK) ProjectName (FK)

HoursWorked

PROJECT ProjectName

StartDate Budget

(b) Association Pattern Database Design

Chapter 6 Transforming Data Models into Database Designs

PHONE_CONTACT

CompanyName

CompanyName (FK)

Contact

PhoneNumber Using ID-Dependent Entities

Figure 6-14

PhoneNumber

to Store Multivalued

(b) Database Design to Attributes

(a) Data Model with Multivalued

Attributes from Figure 5-29

Store Multivalued Attributes

Association Relationships