>> In this case, we don't need to define the party ids in the >> PartyRelationship, because the PartyRole entity has them. All we do is >> we reference PartyRole(s). > > If I understand, you are suggesting to extend/use PartyRole in place of > PartyRelationship; why not using PartyRelationship instead?
Not exactly ! I am suggesting to use BOTH for a PartyRelationship. A party that has a Role of Type MANAGER, can be involved in a MANAGE relationship. In the current setup, any party can get engaged in any relation. So the Party "John Black", does not need to have the PartyRole "Customer" in order to have a relationship with DEF inc. And similarly, ABC inc does not need to have EMPLOYER ROLE in order to have an EMPLOYMENT relationship with other Party. The relationship is defined by two roles. Each role is defined by Party and RoleType. > >> >> >>> Summary: >>> * "party role": the roles that a given party *can* play >>> * "party relationship": the actual roles played by a given party (with >>> respect to other parties). >>> >> >> This clarifies it. But don't we find this confusing ? Why does someone >> get involved into a DEVELOPER relationship if she does not have the >> DEVELOPER PartyRole ? > > It can't. The process should look like: > 1) add developer information to a party and add the DEVELOPER role to it; > this means that now the party can play the role of a developer in some party > relationship > 2) create one or more party relationship where the party is a developer for > some other party > Perfect. So we are on the same page here. This is how I would model it. But the current model doesn't enforce this constraints. It allows the party "Mary" to be involved in a relationship that with "DEVELOPER" RoleType. Please note that she does not have DEVELOPER Role, but the PartyRelationship entity has the fields "roleTypeIdFrom" and "roleTypeIdTo" which allows to break this constraints, and create confusion.
