Surrogate Key Database Design

The database design for the View Ridge database using surrogate keys is shown in Figure 6-37. Notice that two identifying relationships (TRANS-to-WORK) and (WORK-to-ARTIST) have been changed to nonidentifying relationships represented by dashed lines. This was done because once ARTIST has a surrogate key, there is no need to keep ID-dependent keys in WORK and TRANS. Realize that WORK and TRANS are both weak entities even though they are no longer ID-dependent.

Notice that (LastName, FirstName) in ARTIST has been defined as an alternate key. This

Figure 6-36

notation indicates that (LastName, FirstName) has a UNIQUE constraint, which ensures that

Initial View Ridge Gallery

artists are not duplicated in the database. Similarly, (Title, Copy) in WORK is defined as an

Database Design

alternate key so that a given work cannot appear more than once.

ARTIST LastName

LastName (FK)

FirstName (FK) CREATES/CREATED_BY LastName FirstName

PURCHASES/SOLD_TO

FirstName (FK)

ACQUIRED

FirstName AreaCode

DateAcquired

Title

Title (FK)

Copy

LocalNumber

Nationality Street

Copy (FK)

Medium

DateOfBirth

City DateDeceased

Email (FK)

CUSTOMER_ARTIST_INT LastName (FK)

FirstName (FK)

HAS_INTEREST_IN

Email (FK)

ADMIRED_BY

Part 2 Database Design

CUSTOMER CustomerID

ARTIST LastName

TRANS

WORK

CREATES/CREATED_BY ArtistID FirstName AreaCode

PURCHASES/SOLD_TO

LastName (AK1.1) LocalNumber

FirstName (AK1.2) Street

DateAcquired

Title (AK1.1)

AcquisitionPrice

Nationality City

Copy (AK1.2)

DateSold

Medium

DateOfBirth State

SalesPrice

Description

DateDeceased ZipPostalCode

AskingPrice

ArtistID (FK)

WorkID (FK)

Country

CustomerID (FK)

Email (AK1.1)

CUSTOMER_ARTIST_INT CustomerID (FK)

ArtistID (FK)

HAS_INTEREST_IN

ADMIRED_BY

Figure 6-37

Final View Ridge Gallery

The foreign key placement is a straightforward application of the techniques described in

Database Design

this chapter, but note that the foreign key CustomerID in TRANS can have null values. This specification allows the creation of a TRANS row when a work is acquired, before any customer has purchased the work. All other foreign keys are required.

Minimum Cardinality Enforcement for Required Parents

According to Figure 6-28(a), for each relationship that involves a required parent, we need to decide:

• Whether to cascade or prohibit updates of the parent’s primary key • Whether to cascade or prohibit deletions of the parent • How to obtain a parent when a new child is created

Because there is no consistent means of documenting these actions in commercial database design products, we will use the templates in Figure 6-28 to document our decisions. Figure 6-38 summarizes the relationships in the View Ridge database design.

Because all tables have surrogate keys, there is no need for any update cascade behavior for any parent. However, some update actions on child tables must be restricted. For example, once a WORK (child) is assigned to an ARTIST (parent), it is never to change to another parent. Because this database is used to record purchases and sales, View Ridge management never wants to delete any data that are related to a transaction. From time to time, they may remove prior year’s data in bulk, but they will do that using bulk data transfer and not as part of any application.

Hence, any CUSTOMER, WORK, or ARTIST row that is related to a TRANS row is never to

be deleted. Note, however, that rows of CUSTOMERs who have never made a purchase and rows of ARTISTs whose works have never been carried in the gallery can be deleted. If either a CUSTOMER or ARTIST is deleted under these circumstances, the deletion will cascade to rows in the intersection table CUSTOMER_ARTIST_INT.

Figure 6-38

Relationship

Cardinality

Summary of View Ridge

Database Design

Nonidentifying 1:N M-O

WORK

TRANS

Nonidentifying 1:N M-M

CUSTOMER

TRANS

Nonidentifying 1:N O-O

CUSTOMER

CUSTOMER_ARTIST_INT Identifying

1:N M-O

ARTIST

CUSTOMER_ARTIST_INT Identifying

1:N M-O

Chapter 6 Transforming Data Models into Database Designs

Finally, referential integrity actions are necessary for obtaining a parent WORK when a TRANS record is created and a parent ARTIST when a WORK record is created. In both cases, the policy will be for the application program to provide the ID of the required parent at the time the WORK or TRANS record is created.

All these actions are documented inFigure 6-39, where each part is based on the template for required children shown in Figure 6-28(a). Note that there is no diagram for the CUSTOMER-to-TRANS relationship, because that is an O-O relationship without a required parent (or child).

Figure 6-39

ARTIST

Action on ARTIST

Action on WORK

Actions to Enforce Minimum

Is Required

(Parent)

(Child)

Cardinality for Required

Get a parent.

Modify key or

Prohibit—ARTIST uses a

foreign key

surrogate key.

Delete

Prohibit if WORK exists—

None.

data related to a transaction is never deleted (business rule). Allow if no WORK exists (business rule).

(a) For the ARTIST-to-WORK Relationship

WORK

Action on WORK

Action on TRANS

Is Required

Get a parent.

Modify key or

Prohibit—WORK uses a

foreign key

surrogate key.

Delete

Prohibit—data related to

None.

a transaction is never deleted (business rule).

(b) For the WORK-to-TRANS Relationship

CUSTOMER

Action on CUSTOMER

Action on

Is Required

(Parent)

CUSTOMER_ARTITST_INT

Get a parent.

Modify key or

Prohibit—CUSTOMER

foreign key

uses a surrogate key.

Delete

Prohibit if TRANS exists—

None.

data related to a transaction is never deleted (business rule). Allow if no TRANS exists (business rule)—cascade delete children.

Part 2 Database Design

ARTIST

Action on ARTIST

Action on

Is Required

(Parent)

CUSTOMER_ARTITST_INT

Get a parent.

Modify key or

Prohibit—ARTIST uses a

foreign key

surrogate key.

Delete

Prohibit if TRANS exists—

None.

data related to a transaction is never deleted (business rule). Allow if no TRANS exists (business rule)—cascade delete children.

Figure 6-39

Continued (d) For the ARTIST-to-CUSTOMER_ARTIST_INT Relationship

Surrogate Key Database Design