Formally speaking

Target : 2nd year STPI-2A (3rd and 4th years could read)

I- Set constraints (contraintes ensemblistes)

Set constraints (SC) are logical formulae attached to basic MCD model to define some (extra) properties by using mathematical expressions.During modelling, and as engineer you should be be able to map world realities onto "intuitive" concepts to build your models. A mathematical framework is a must if you would atach a rigorous meaning to those concepts.

II- Exclusion constraint

The constraint,labeled {x}, is displayed by connecting the relevant association-ends by a straight lines and a dashed line to the pivot (constraint target).

The basic model offers the following interpretation:

1. An owner possesses one or more properties.A property is owned by one and only one owner
2. A lodger rents one or more properties.A property is rented by one ore more lodgers

What does exactly the exclusion constraint express ?

To_rent[PROPERTY] ∩ Possess[PROPERTY] = ?.

But cardinalities are offering the following constraints:

Cardinality (1,1) on the first role: Possess is a total function defined over PROPERTYxOWNER

Cardinality (0,n) on the second role: "To rent" is a relation. Some properties are not rent.

thus:

To_rent[PROPERTY] ? Possess[PROPERTY]

We have now two "conflicting or contradictory" constraints:

• To_rent[PROPERTY] ? Possess[PROPERTY].
• To_rent[PROPERTY] ∩ Possess[PROPERTY] = ?.

The only solution available is when :To_rent[PROPERTY] = ?

Conclusion: With this constraint, we can't rent any property!

III- Who do need an exclusion constraint ?

What does exactly the exclusion constraint express ?Here, the constraint does not relate to one of the roles but to the associated couples

To_rent[PROPERTY,OWNER] ∩ Possess[PROPERTY,LODGER] = ?.

• To rent is defined over: PROEPRTYxLODGER
• Possess is defined over: PROPERTYxOWNER

But, this fact should be considered carefully! We know that the two sets "To rent" and "Possess" are DIFFERENT sets in nature.

Elements of the set "To rent" are "coming" from ROEPRTYxLODGER, Elements of the set "Possess" are coming from PROPERTYxOWNER : The set of owners is different from the set of lodger. By definition we have :

To_rent[PROPERTY,OWNER] ∩ Possess[PROPERTY,LODGER] = ?.

Conclusion: in this case, the exclusion constraint is redundant

Consider the same model with the exclusion constraint put this way:

Do we need frankly this constraint?. The answer is NO. As by definition (the base model) we have two sets that are different by nature : OWNER and LODGER. So,the following expression is true by definition:

To_rent[OWNER] ∩ Possess[LODGER] = ?

Conclusion: in this case, again, the exclusion constraint is redundant.

IV- Inclusion constraint

Comments on the inclusion constraint:

• The inclusion has two sources: B and C and a target A
• The inclusion has two pivots : X and Z

What we are saying with this inclusion? Before answering, it is important to recall:

• B is the set of couples of type{(Xi,Yi)}
• C is the set of couples of type {(Yi,Zi)}
• A is the set of couples of type {(Xi,Zi)}

The inclusion constraint is saying: all X's getting involved in B {(Xi,Yi)}with Yi involved in C, should be part of X's involved in A {(Xi,Zi)}

Let me reformulate again this constraint: The set of elements extracted from the paths X-Y and Y-Z should be part of the set of elements extracted from the path E1-E2.

Suppose

• A= { (x1,z1), (x2, z1),(x3, z1),... }
• B= { (x1,y1), (x2,y1)},
• C ={(y1,z1)}

If I join B to C on y1, we will have the set {(x1,z1), (x2,z1)} which is part of set A.

We express the constraint with the following expression:

(B ? C)[X, Z] ? A[X, Z]

• ? : Joint operator
• ? : Inclusion Operator

V- Totality constraint

Consider this MCD model:

The basic model offers the following interpretation:

1. An E2 possesses one or more properties.A property is owned by one and only one E2
2. An E3 rents one or more properties.A property is rented by one ore more E3

Suppose the two entities E2 and E3 have many things in common.You decide to merge E2 and E3 in one Entity E:

But in this case each E should possess and rent!We need to express the following facts:

• An e could possess but not rent
• An e could rent but not possess
• An e could possess and could rent at the same time
• An e should at least be an owner (possess) or a tenant (rent). One of them.

To "repair" the MCD we need to modify cardinalities of E and add totality constraint:

If the totality constraint is not specified, there could be E who do not possess and do not rent, in contradiction with the stated management rule. formally the constraint could be stated this way:

Possess[E] ∪ To_rent[E] = E

It is not compulsory to possess an E1 (minimum cardinality equal to 0 on the role of E in the association "Possess"), it is not compulsory to rent an E1 (cardinality equal to 0 on the role of E in the association "To rent") but it is mandatory to have one of the two roles (total constraint linking the roles of E).

VI- Conclusion

Some rules you need to observe:

1. You don't have to use the exclusion constraint between sets if those sets are different in nature as their intersection is empty by definition
2. Exclusion constraint and inclusion constraint (implied by cardinality equal to 0) are contradictory.
3. Sometimes you have to relax the cardinalities to add totality constraint in conformance with management rule.

My Question is: Suppose your client needs you to avoid that e in E, who possesses e1 in E1, could rent e1.

Look at this this visual. It shows what we need to avoid :