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 1 2 Viansa Pinot Noir 2005 2 Ravenwood Chardonnay 2004 1 1 Cline 1 Chablis 2008 1 Kunde Chenin Blanc 2006 1 … … No winner! Customer and Salesperson • Customer Salesperson 1 2 Viansa Smith 1 1 Ravenwood Adams 2 1 Cline Johnson 1 1 Kunde Carlin 1 1 Ravenwood Fisher No winner! Salesperson and Branch • Salesperson Branch 1 1 Smith Cotati 1 2 Adams Windsor 1 1 Johnson Guernville 1 1 Carlin Petaluma 1 Fisher And the winner is… Salesperson and Branch • Salesperson Branch 1 1 Smith Cotati 1 2 Adams Windsor 1 1 Johnson Guernville 1 1 Carlin Petaluma 1 Fisher And the winner is… SALESPERSON (only one match per row) Foreign Key in Salesperson • Salesperson repID (primary key) 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 table 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 1 2 Viansa Smith 1 1 Ravenwood Adams 2 1 Cline Johnson 1 1 Kunde Carlin 1 1 Ravenwood 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 Relationship 3 1 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 1 2 Adams The Transition table breaks the 3 1 Ravenwood Many-To-Many relationship into a… 4 1 Carlin 1 5 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 Data • 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 composite key, in the cotext of relational databases, 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 .