The Foreign Key Game

Only One Can Win Wine Brokerage Customer + Variety

• Customer Variety Viansa Pinot Noir Ravenwood Chardonnay Cline Chablis Kunde Chenin Blanc Ravenwood Pinot Noir Customer + Variety + Vintage

• Customer Variety Vintage Viansa Pinot Noir 2005 Ravenwood Chardonnay 2004 Cline Chablis 2008 Kunde Chenin Blanc 2006 Ravenwood Pinot Noir 2005 Customer and Variety+Vintage

• Customer Variety Vintage Viansa Pinot Noir 2005 Ravenwood Chardonnay 2004 Cline Chablis 2008 Kunde Chenin Blanc 2006 … … Customer and Salesperson

• Customer Salesperson Viansa Smith Ravenwood Adams Cline Johnson Kunde Carlin Ravenwood Fisher Salesperson and Branch

• Salesperson Branch Smith Cotati Adams Windsor Johnson Guernville Carlin Petaluma Fisher Primary keys for All

• Variety/Vintage: vID • Customer: customerID • Salesperson: repID • Branch: branchID Customer and Variety+Vintage

• Customer Variety Vintage Viansa 1 2 Pinot Noir 2005 2 Ravenwood Chardonnay 2004 1 1 Cline 1 Chablis 2008 Kunde 1 Chenin Blanc 2006 1 … …

No winner! Customer and Salesperson

• Customer Salesperson Viansa 1 2 Smith Ravenwood 1 1 Adams 2 1 Cline Johnson Kunde 1 1 Carlin Ravenwood 1 1 Fisher

No winner! Salesperson and Branch

• Salesperson Branch Smith 1 1 Cotati Adams 1 2 Windsor 1 Johnson 1 Guernville 1 Carlin 1 Petaluma Fisher 1

And the winner is… Salesperson and Branch

• Salesperson Branch Smith 1 1 Cotati Adams 1 2 Windsor 1 Johnson 1 Guernville 1 Carlin 1 Petaluma Fisher 1

And the winner is… SALESPERSON (only one match per ) Foreign Key in Salesperson

• Salesperson repID () repName branchid (foreign key) Primary Key in Branch

• Branch branchID (primary key) branchName branchID branchName 1 Cotati 2 Windsor 3 Guernville 4 Petaluma Primary and Foreign Key in Salesperson • Salesperson repID (primary key) repName branchid (foreign key) repID repName branchID 1 Smith 1 2 Adams 2 3 Johnson 3 4 Carlin 4 5 Fisher 2 Primary and Foreign Key in Salesperson branchID branchName 1 Cotati 2 Windsor 3 Guernville 4 Petaluma repID repName branchID 1 Smith 1 2 Adams 2 3 Johnson 3 4 Carlin 4 5 Fisher 2 Primary Key in Branch (no foreign key)

• Branch branchID (primary key) branchName branchID branchName 1 Cotati 2 Windsor 3 Guernville 4 Petaluma Primary and Foreign Key in Branch WRONG! • Branch branchID (primary key) branchName repID branchID branchName repID 1 Cotati 1 (Smith) 2 Windsor 2 (Adams) 2 Windsor 5 (Fisher) 3 Guernville 3 (Johnson) 4 Petaluma 4 (Carlin) Closer Look at Variety+Vintage

• Variety Vintage Pinot Noir 2005 Chardonnay 2004 Chablis 2008 Chenin Blanc 2006 …. Chenin Blanc 2008 Pinot Noir 2006 Closer Look at Variety+Vintage

• Variety Vintage Pinot Noir 2005 Chardonnay 2004 Chablis 2008 Chenin Blanc 2006

One-To-Many

• This relationship is the only one with a clear winner in the Foreign Key game. Each row from A can have many matches (the loser) but in table B, each row from table B can have one and only one row match in the other table (the winner) One-To-One

• This type of relationship produces a tie in the Foreign key game. Each row in both tables match one and only one row in the other table. Since both win the foreign key, we have a tie.

Tie Breaker Rule

• If each row must match one and only one row (a match is guaranteed), consider combining the tables into one table. Otherwise, randomly choose one table to win the foreign key. • If it is possible that a row in one table will match zero rows in the other table, it loses the foreign key game. The other table wins the foreign key. One-to-One Tie Breaker

• To break the tie, look closer at the relationship. Here’s an example:

Customer RewardsMembers Viansa Viansa Ravenwood Cline Cline Kunde Ravenwood One-to-One Tie Breaker

Customer RewardsMembers Viansa Viansa Ravenwood (no match) Cline Cline Kunde (no match) Ravenwood (no match)

And the winner is … RewardsMembers Foreign Key in Optional Participant

• Customer RewardsMembers custID (primary key) RewardID (primary key) customerName custID (foreign key) custID customerName RewardID custID 1 Viansa 1 1 2 Ravenwood 2 3 3 Cline 4 Kunde

Rewards may have other info, like reward amount, membership date, etc. Foreign Key in Customer WRONG • Customer RewardsMembers custID (primary key) RewardID (primary key) customerName RewardID (foreign key) custID customerName RewardID RewardID 1 Viansa 1 1 2 Ravenwood NULL 2 3 Cline 2 4 Kunde NULL

Causes empty values which is less efficient and may have an effect on queries Many-To-Many

• This relationship has no winner at all in the Foreign Key game. Each row from table A can have many matches. In table B, each row from table B can have many matches.

Many-To-Many Arbitration

• For tables to relate, there must be a primary key- foreign key combination. In the case of a many- to-many relationship, though, there is no foreign key winner. To make the relationship happen anyway, we need an arbiter, or as it is officially called, a transition table. • In the case of a many-to-many relationship, the transition table wins the foreign key. In fact, it wins two—one from each table. • Both tables in the many-to-many relationship lose the foreign key to a transition table. Customer and Salesperson

• Customer Salesperson Viansa 1 2 Smith Ravenwood 1 1 Adams 2 1 Cline Johnson Kunde 1 1 Carlin Ravenwood 1 1 Fisher

No winner! Customer and Transition Tables custID customerName 1 Viansa

2 Ravenwood

3 Kline

4 Kunde

custID repID 1 1 2 2 3 1 3 3 4 4 Customer and Transition Tables Foreign Key Game

1 custID customerName 1 Viansa

The Transition table breaks the 1 2 Ravenwood Many -To-Many relationship into a…

2 3 Kline

1 4 Kunde

custID repID 1 1 1 1 2 2 One-To-Many 1 3 1 Relationship 1 3 3 1 4 4

Transition Table wins Salesperson and RepID RepName 1 Smith Transition 2 Adams 3 Ravenwood 4 Carlin 5 Fisher custID repID 1 1 2 2 3 1 3 3 4 4 Salesperson and Transition RepID RepName Foreign Key Game 1 2 Smith 2 1 Adams The Transition table breaks the 3 1 Ravenwood Many-To-Many relationship into a… 4 1 Carlin 5 1 Fisher

custID repID 1 1 1 One-To-Many 2 2 1 Relationship 3 1 1 3 3 1 4 4 1 Transition Table wins again! Finalized Customer and Salesperson Arbitration

custID customerName repID repName 1 Viansa 1 Smith 2 Ravenwood 2 Adams 3 Kline 3 Johnson 4 Kunde 4 Carlin 5 Fisher custID repID 1 1 2 2 3 1 3 3 4 4

Since the Transition table won the foreign key from both Customer AND Salesperson, it holds both keys.

Transition Table May Also Have Relevant • In our example, a transition table separates Customer and Salesperson. It holds the key for customer and the key for salesperson. • When would the customer and the salesperson come together? Is there data relevant to that interaction? • What about a sale? The transition table could represent each sale (between a customer and a salesperson) and could have its own data relevant to the sale, such as: – Sales total – Date of sale

Sale Table

Composite Primary Key: A , in the cotext of relational , is a combination of two or more columns in a table that can be used to uniqely identify each row in the table. Uniqueness is only guaranteed when the columns are combined; when taken individually the columns do not guarantee uniqueness.

Transition tables generally have a composite primary key.

Unique value in custID repID custID + repID 1 1 2 2 3 1 Sales(custID, repID) 3 3 Primary key: custID, repID 4 4 Foreign key: custID Foreign key: repID

The primary key of the transition table is a composite primary key. The primary key is custID + repID

Transition Table Becomes Sales Table

• Sales Table custID (custID + repID = primary key) repID salesTotal saleDate