Associations and Cardinality

Explanation

Associations define relationships between CDS views or entities. They are not exactly the same as always joining immediately. Associations can be exposed and consumed through path expressions. Cardinality tells the expected relationship, such as one-to-one or one-to-many. Wrong cardinality can create incorrect results, duplicates or performance issues. Associations are powerful for Fiori and RAP because they model navigation between business entities. But they must be designed carefully with correct keys and join conditions.

Code example

@EndUserText.label: 'Sales Order with Items Association'define view entity ZI_SalesOrderWithItems as select from vbak as Header association [0..*] to vbap as _Item on _Item.vbeln = Header.vbeln{ key Header.vbeln as SalesOrder, Header.auart as SalesDocumentType, Header.vkorg as SalesOrganization,  // Expose association for navigation to items. _Item} // Purpose:// Association [0..*] means one sales order can have zero to many items.// Use realistic cardinality. Wrong cardinality can mislead consumers.

Real project scenario

A sales order CDS exposed an association to items. A wrong [1..1] cardinality was used even though one order had many items, which caused confusion in consumption and incorrect assumptions in the UI model.

Common mistakes

- Using wrong cardinality. - Exposing too many associations. - Creating associations without proper key relationship. - Confusing association with mandatory immediate join.

Best practices

- Use correct cardinality. - Expose only meaningful associations. - Validate join condition. - Test result count and duplicates.

Interview angle

Interviewers often ask association vs join and cardinality. A good answer explains navigation, path expression and relationship modeling.