Here is the continuation of Rudy's answer. See part 1.
Here again is the sample data introduced in the first part of this answer:
Team Member Person 111 Alpha 111 JJ JJ John 222 Beta 111 LL KK Karl 333 Gamma 222 KK LL Linda 444 Delta 222 MM MM Mary 333 JJ 333 LL 333 MM
As for changing the associations, there are two types of changes to consider. The first is straightforward, and involves changing the value of a primary key. If for some reason you wanted to change Karl's primary key from KK to something else, all you need to do is just update the Person table, and the action will be either cascaded or prohibited, depending on whether you specified ON UPDATE CASCADE or ON UPDATE RESTRICT. Note that RESTRICT is the default that comes into effect whenever a foreign key is declared. Since there are no ON UPDATE clauses in the above example, you cannot change Karl's primary key.
The other change to an association is also straightforward. Suppose Linda wants to leave Alpha and join Beta. The application logic that implements this change can choose between these strategies dealing with the Member table:
update the existing row 111LL to 222LL
delete the existing row 111LL and insert a new row 222LL
In both of these cases, relational integrity will be enforced to ensure that the updated or new Member row has valid foreign key values to both Team and Person tables.
So everything hinges on declaring foreign keys. If you didn't have the foreign keys declared, then you could delete Mary from the Person table and yet leave MM rows in the Member table, or you could change Karl's primary key to something else and yet leave KK rows in the Member table.
Always declare foreign keys, and if the business logic of the application allows it, go ahead and declare ON DELETE/UPDATE CASCADE actions where appropriate.