Jacopo, The way to enforce the constraints is to define the PartyRelationship between pair of PartyRoles, and NOT between partyIds and roleTypes. This is what I meant.
On Sun, Oct 12, 2014 at 2:54 AM, Mansour Al Akeel <[email protected]> wrote: >>> 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.
