Previous Topic

Book Contents

Book Index

Next Topic

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:

Help Image

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.

See Also

Examples

Example: Contract Item - Contract Relation in Detail

Example: N:M Relationship

Example: Time Related N:M Relationship

Example: Cost Center "is managed by" Person

Example: Organizational Unit "is managed by" Person

Example: Person "works for" Organizational Unit

Example: Person "is assigned to" Cost Center

Example: System "is of" System Type