Example: Various Relation Scenarios
The combination of the 'Relation attribute may be empty' and 'Instances are relation dependent' settings is of utmost importance when it comes to real-life situations modelling.
Note: Please note that unlike the Illustrative Example, which describes an existing relation used in Valuemation, these examples are purely hypothetical. The situations they model, however, represent many possible relation uses.
Let's now create hypothetical combinations of these settings on the Source Object Type side and discuss their consequences:
Hypothetical Settings - case 1
Setting / Operation
|
Consequences
|
Relation attribute may be empty: TRUE
|
It is possible to have a "standalone" Contract Item, that is a Contract Item linked to "No Contract".
|
Instances are relation dependent: TRUE
|
The assignment of Contract Item(s) to the Contract is not changeable
|
EDIT assignment
|
Once the Contract Item is assigned to a Contract, this assignment cannot be changed-including the assignment to "No Contract"
|
DELETE Contract
|
If a Contract is deleted, its Contract Item(s) must also be deleted. Although the Contract Relation Attribute may be empty (making the No Contract assignment possible), the assignment cannot be changed - which means that the Contract Item "must die" with the Contract. Another aspect of this combination is that you may start with assigning the Contract Item to "No Contract", but the "Instances are relation dependent:TRUE" setting makes subsequent assignments to another (existing) contract impossible.
|
|
Hypothetical Settings - case 2
Setting / Operation
|
Consequences
|
Relation attribute may be empty: TRUE
|
It is possible to have a "standalone" Contract Item, that is a Contract Item linked to "No Contract".
|
Instances are relation dependent: FALSE
|
The assignment of Contract Item(s) to the Contract is changeable
|
EDIT assignment
|
It is possible to edit the Contract Item - Contract assignment
|
DELETE Contract
|
If a Contract is deleted, its Contract Item(s) can "survive" as standalone or it may be assigned to another Contract.
|
|
Hypothetical Settings - case 3
Setting / Operation
|
Consequences
|
Relation attribute may be empty: FALSE
|
It is not possible to have a "standalone" Contract Item, that is the Contract Item must always be assigned to a Contract.
|
Instances are relation dependent: FALSE
|
The assignment of Contract Item(s) to the Contract is changeable
|
EDIT assignment
|
It is possible to edit the Contract Item - Contract assignment
|
DELETE Contract
|
Contract Item(s) must always be assigned to a Contract and it is possible to change the assignment. Thus if a Contract is deleted, its Contract Items will have to be assigned to another Contract.
|
|
In the light of the hypothetical examples, let's revisit the real relation used in Valuemation:
Contract Item is part of Contract - case4
Setting / Operation
|
Consequences
|
Relation attribute may be empty: FALSE
|
It is not possible to have a "standalone" Contract Item, that is the Contract Item must always be assigned to a Contract.
|
Instances are relation dependent: TRUE
|
The assignment of Contract Item(s) to the Contract is not changeable
|
EDIT assignment
|
Once the Contract Item is assigned to a Contract, this assignment cannot be changed.
|
DELETE Contract
|
Contract Item(s) must always be assigned to a Contract and it is not possible to change the assignment. If a Contract is deleted, it will not be possible to assign its Contract Items to another Contract (including the "No Contract" assignment, which is also prevented by the "Relation attribute may be empty: FALSE" setting. This combination essentially prevents the user from inadvertently starting with a "No Contract" assignment which they would not be able to change later on.
|
|
Cases 1 to 4 analyzed settings made on the Source Object Type side. Settings on the Target Object Type side can be seen as an analogy.
The checkbox "Relation attribute is collection" (described in the "Creating n:1 or 1:n Relations" topic) is available only for the Target Object Type side. This means that when creating a relation, the source object type is the object type whose instances form a collection containing more that one component.
|