Using Associations and Compositions

Associations are used to define relationships between entities.

In the example shown in figure Association from Books to Authors, the association between Books and Authors is defined through the author element in the Books entity. This element creates a link to the Authors entity, which establishes a relationship where you can navigate from a Books entity to the associated author to retrieve more details such as the author's name.

The to-one association Books:author in the sample code is a so-called managed association, where foreign key fields and on conditions are automatically added behind the scenes.

Based on the primary key of the target, i.e. the Authors entity, CDS automatically adds the foreign key field author_ID to an SQL database upon activation (see figure Generated Foreign Key Field) and implicitly adds the corresponding join condition.

In addition to managed associations, we can also use unmanaged associations. Unmanaged associations explicitly specify arbitrary join conditions in their on clause, which refer to available foreign key fields.

Next, we will examine an example of a to-many association.

An author can write any number of books, i.e. an author can be associated with none, one, or multiple books.

Figure Association from Authors to Books shows how such to-many associations are defined in a CDS model.

The relationship between the Authors entity and the Books target entity is specified by the books element in the Authors entity. The syntax Association to many Books indicates that an author is associated with any number of books.

In the on condition, the association name books is used as an alias for the Books target entity to be linked. The clause on books.author = $self specifies that the author field in the Books entity is used to create the link to the Authors entity. $self is a placeholder that refers to the current instance of an author.

In general, an expression according to the following pattern is specified in the on condition for to-many associations:

<assoc>.<backlink> = $self

The backlink can be any managed to-one association on the many side that points back to the one side.

In addition to associations, CAP also supports the modeling of compositions.

Associations relate entities that can exist independently of each other - such as authors and books.

Compositions, on the other hand, represent contained-in relationships and are used to model document structures. They frequently show up in to-many header-child scenarios - such as orders and order items.

Composition means the child entity (order items) is part of a whole and cannot exist independently of the parent entity (order). The child entity is contained in the parent entity and can only be accessed via the parent entity.

Figure Example of a Composition demonstrates how compositions are defined in CDS. The composition shown defines a one-to-many relationship between Orders and OrderItems. The syntax is very similar to the definition of a one-to-many association. The only difference is the clause Composition of instead of the clause Association to on the one side (compare the association between authors and books above).

The CAP runtimes treat compositions differently from associations in some respects. Among other things, there are the following special features for compositions:

• Cascaded delete

  The deletion of an order would also result in the deletion of all its order items due to the composition relationship.

• Deep insert

  In the generated OData service, both an order and the contained order items can be created via one single POST request.

Next, let's look at how associations can be exposed in service interfaces.

You can add associations like regular elements to the select list of a view (as select from) or projection (as projection on). A select * includes all associations.

Figure Exposing Projections shows the two projections AdminService.Books and AdminService.Authors from our scenario, which are exposed via the AdminService. The effective signature of the AdminService.Books projection contains an author association with the same properties as the author association of the com.sap.learning.Books entity. Similarly, the signature of the AdminService.Authors projection contains a books association with the same properties as the books association of the com.sap.learning.Authors entity.

The AdminService shown in figure Exposing Projections exposes the two projections on the entities from the underlying data model.

When exposing related entities, the associations are automatically redirected. This ensures that clients can navigate between the projected entities as expected (see figure Redirected Associations). This means that AdminService.Authors.books points to AdminService.Books - and not to com.sap.learning.Books. Similarly, AdminService.Books.author refers to AdminService.Authors - and not to com.sap.learning.Authors.

In the generated OData service, the published associations are available as navigation properties with the same name.

Figure Generated Navigation Properties shows the corresponding excerpt from the service metadata document. The entity type Books has a navigation property author, and the entity type Authors has a navigation property books.

Watch the video to see how to add associations to the domain model.

Next, we will look at how entity definitions can be extended with new elements using so-called aspects.