I have a logical/physical question that I'm hoping I can get some opinions around. I have three entities, a Customer Credit Card keyed by a Customer Id and a Credit Card Number, A Customer Agreement keyed by a Customer Id and an Agreement Id, and a Customer Credit Card Agreement to resolve a many-to-many relationship between the Customer Credit Card and the Customer Agreement with a key of Customer Id, Credit Card Number, and Agreement Id. There is also a Customer entity and an Agreement entity.

Is this the proper way to model a many-to-many relationship where both entities contain the same attribute, with the same value, as part of the key (Customer Id)?

With only one Customer Id in Customer Credit Card Agreement, how would RI (DB2)know which of the two tables to use from Customer Credit Card Agreement? Does the question make sense?

You would need two foreign keys in Customer Credit Card Agreement:

1) (Customer Id, Credit Card Number) referencing Customer Credit Card

2) (Customer Id, Agreement ID) referencing Customer Agreement

Some people would prefer to have 2 Customer ID columns in the table, with a check constraint to ensure they are the same. Seems kind of redundant though!