Syntax of Associations

CDS provides extended support for treating relationships between entities. Such relationships are often reflected as foreign key relationships in the database, but in SQL the relations are often concealed behind non-trivial join conditions.

This is cumbersome and error-prone for application developers and requires considerable effort when joins are to be used.

The syntax of associations keeps the relations between data model entities visible. Path expressions and filtered associations make it easier to read the CDS View definitions, as well as the SELECT statements accessing the view.

Although associations and join look different, there is no difference in database level. Eventually, any association is translated into an ordinary join. But in the case of so-called exposed associations, it depends on the way a view is consumed. The join is only executed if the consumer requests data from the associated data source. This can have a positive effect on the performance and sometimes is referred to as “Join on Demand”.

At first glance, associations are just another syntax for defining joins. There is a small difference in the element list: in the element list of a join, specifying the data source for a field is only mandatory for non-unique field names. In the field list of a view with an association, all fields without an explicit source are taken from the primary data source. For all fields from the associated table, it is mandatory to specify the data source.

The SQL creates a statement of a CDS view definition that visualizes its technical realization. The SQL Create a statement for view definition above reveals, that on the database level, it is nothing more than a join definition.

When you define an association, you can use addition AS to specify an alias. This syntax looks very similar to the definition of aliases in the join syntax. But strictly speaking, it is not an alias for the data source but a name for the association.

The difference becomes clear when we look at the SQL Create statement again:

In the SQL Create statement, the association name is replaced by a more generic alias. This means that association name is only a semantic information. Specifically, a cardinality after key word ASSOCIATION is optional. If the cardinality is not explicitly defined, the cardinality “0..1” is implicitly used.

Associations and Cardinality

Syntax of Exposed Associations

Instead of accessing individual fields of the associated data source, a CDS view can place the association name itself in its element list. The association is then exposed to the consumer of the CDS view, which is either another CDS view or an ABAP Open SQL statement. The consumer of the view gets full access to all components of the associated data source.

There is a prerequisite for exposing an association: All fields used in the ON condition of the association must be part of the element list.

First, by exposing an association, you do not preselect the fields of the data source which you think might be of interest. You delegate this task to the consumer of the view. But there is an important technical difference that becomes relevant if the consumer chooses not to select any fields from the association.

The association above shows the SQL Create a statement for CDS views with the exposed association. You can see that in the case of an exposed association the SQL view does not immediately join the associated data source. The actual join of the data source is not done until the consumer accesses individual fields of the associated data source.

Template defineViewWithAssociation