Association and Composition

Home > Metamodelling Concepts > Association and Composition

Uni-/bidirectional associations and compositions can be used to model relationships between entity classes. Moreover you may use unidirectional associations to model a relationship from an attribute class to an entity class.

Association

You can provide one or two role names for an association. An unidirectional association possesses only one role name, a bidirectional association has two role names.

Both sides of an association can be marked with a multiplicity other than "0..*". Accordingly you can model one-to-one, one-to-many or many-to-many associations. Above all the multiplicity constraints are fine grained: lower and upper limits can be exactly specified. If the upper limit of a multiplicity constraint is greater than 1 you can choose the type of collection, i.e. either "Set" or "Vector".

If the source class of an association is identical to the target class and there is only one role name defined, that association can be declared as "self-connected". Then the association is by definition bidirectional as it points to itself. You could use this to model e.g. a "Person" class with the self-connected association "spouse".

Associations may be used in the context of attribute classes as well. Then they have to be unidirectional, because attribute objects cannot be referenced by definition.

Composition

Compositions are specialised associations and have similar characteristics, but the involved entity classes play different roles. One entity class is called composite class; the other one is called part class.

Please notice first of all that the “weak” constraint for entity classes is interrelated with the concept of compositions.

  • The "weak" constraint for entity classes dictates that a weak entity must be always connected to a composite entity; otherwise it would be automatically deleted by the object container.
  • The composition is likewise a constraint for the part entities: a part entity may only be linked to at most one composite entity.

Altogether this yields to the following:

  • A strong part entity may only be linked to at most one composite entity.
  • A weak part entity must be linked to exactly one composite entity.

You might ask yourself whether you couldn’t model that with simple "0..1" and "1..1" multiplicity constraints as well? No, you can’t.

  • First of all the "weak" constraint for entity classes is interrelated with compositions and not with multiplicities.
  • Secondly compositions model interdependencies between entity class relationships: a part entity may be linked to at most one composite entity. This rule applies not only in the context of a single composition; it also does if a part entity class is involved in two or more compositions.

By the way, in the context of compositions it makes no sense to restrict the part entities in terms of multiplicity constraints because the only suggestive multiplicity would be "0..1" which is implicit.

In SDL associations and compositions are represented by Java class members. There are some special annotations as well.

  • @association - unidirectional association
  • @association (mult="") - unidirectional association with multiplicity constraint
  • @association (foreign = "") - bidirectional association
  • @association (mult="", foreign="") - bidirectional association with multiplicity constraint
  • @composition (foreign = "") - bidirectional composition
  • @composition (mult="", foreign = "") - bidirectional composition with multiplicity constraint
  • @notnull - notnull constraint (shortcut for 1..1 or 1..* multiplicity)

Here are a few examples:

  • Bidirectional association with multiplicity constraint
    @entity class Person {
        @association (foreign="parents") Set<Person> children;
        @association (mult="0..2", foreign="children") Set<Person> parents;  
    }
    
  • Bidirectional composition
    @entity class DataClass {
        @composition(foreign = "belongsTo") Set<DCMethod> methods;
    }
    
    @entity class DCMethod {
        @association (foreign="methods") DataClass belongsTo;
    }
    
  • Self-connected association
    @entity class Person {
        @association (foreign="spouse") Person spouse;
    }
    

Next chapter: Inferred Field

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.