Issues with current model
The introduction of relations in the model aims to think a number of issues present in the current iteration:
Links are represented by 2 separate link-fields
The 2 sides of a link between 2 data-elements is represented by 2 separate link-fields. The fields are linked based on the assumption that the one-to-many field has a name corresponding to the
<name of the other data-element> + 's'.
This can lead to ambiguity in case there are multiple links. It also means that configuration of the link is spread out over the 2 links with no visual single representation in the model.
Limitations on multiplicity
In the current design, links are limited to one-to-many relations and many-to-many relations. One-to-one links cannot be represented.
Missing semantic information
Links are missing semantic information which can be necessary to activate certain behaviour. E.g. some links represent a composition, which means that deleting the container instance should trigger the deletion of the item instances.
A relation is a link between 2 or more data-elements. It is represented by fields in the member data-elements.
A 1-directional association represents a link where one of the members is not aware of the link.
There is always a source data-element and target data-element defined.
This shows how the task-element has an association with a data-element. A task-element has a target data-element, yet a data-element has no particular connection to the task-elements using this data-element.
A 1-directional association has the following member-ends:
A bidirectional association represents a relation that goes both ways.
A shared aggregation represents a relation where instances of one data-element can be a member of another container data-element.
A shared aggregation has the following member-ends:
A composite aggregation represent a relation where instances of one data-element are a part of another data-element.
A composite aggregation has the following member-ends: