Association Masterclass
Lesson 6 of 15 ā TO ONE vs TO MANY Associations
In the previous lesson we learned that Cardinality represents the business relationship between two business objects.
This naturally leads to another important question.
If Cardinality is only metadata, why does SAP care whether an Association is TO ONE or TO MANY?
The answer lies in how the CDS compiler interprets your Association and the assumptions it can safely make while generating SQL.
Learning Objectives
By the end of this lesson you will be able to:
- Understand the difference between TO ONE and TO MANY Associations.
- Know why the CDS compiler treats them differently.
- Understand why TO MANY Associations have additional restrictions.
- Recognize typical business scenarios for each Cardinality.
- Prepare for generated SQL behavior in the next lesson.
Prerequisites
- Lessons 1ā5 of this Association Masterclass.
- Understanding of Cardinality.
- Basic Association Navigation.
Introduction
From a business perspective, the difference between TO ONE and TO MANYseems obvious.
However, from the CDS compiler's perspective, the difference is much more significant.
A TO ONE Association guarantees that navigation can never return more than one target record.
A TO MANY Association provides no such guarantee.
That single difference affects compiler validation, navigation, generated SQL and even which CDS constructs are permitted.
Architect Perspective
Don't think of TO ONE and TO MANY as syntax.Think of them as promises made to the CDS compiler.
TO ONE says:
"This navigation can never return more than one record."
TO MANY says:
"Multiple records may exist. Plan accordingly."
Understanding TO ONE Associations
A TO ONE Association guarantees that each source record is related to at most one target record.
association [0..1] to I_Customer as _Customer
on $projection.SoldToParty = _Customer.CustomerBusiness interpretation:
One Sales Order has at most one Sold-To Customer.
Since only one Customer can exist, the compiler can safely navigate fields such as:
_Customer.CustomerNameUnderstanding TO MANY Associations
A TO MANY Association represents a relationship where multiple target records may exist.
association [0..*] to I_SalesDocumentItem as _Item
on $projection.SalesDocument = _Item.SalesDocumentBusiness interpretation:
One Sales Order may contain many Sales Order Items.
Since multiple Items may exist, navigation behaves differently and the compiler cannot make the same assumptions that it can for TO ONE Associations.
Why the CDS Compiler Cares
Imagine the compiler receives the following navigation.
_Customer.CustomerNameThe compiler immediately knows that this navigation can return only a single CustomerName because the Association is TO ONE.
Now consider:
_Item.MaterialThe compiler now faces a completely different situation.
One Sales Order may contain several Materials because multiple Items can exist.
This uncertainty is the reason TO MANY Associations have additional restrictions compared with TO ONE Associations.
INSIDE THE CDS COMPILER
Reading Cardinality
š Compiler Thought Process
The compiler evaluates the declared Cardinality before deciding how navigation should behave.
Compiler Decision Flow
Read the Association.
Determine whether it is TO ONE or TO MANY.
Check the requested path expression.
Estimate how many target records may exist.
Choose the appropriate navigation semantics.
Continue SQL generation.
ā Final Compiler Decision
Cardinality directly influences how the compiler interprets Association navigation.
ā” SQL Optimization Insight
Correct Cardinality gives the compiler accurate information. Incorrect Cardinality may lead to unexpected navigation behavior and inefficient SQL.
Why TO MANY Associations Have Restrictions
This is one of the most frequently asked questions during interviews.
If Associations are just relationships, why are TO MANY Associations more restricted than TO ONE Associations?
The answer is simple.
The compiler cannot predict which of the many matching records should be used.
Consider the following relationship:
Sales Order 50000001
ā
Item 10
ā
Item 20
ā
Item 30Suppose you write:
_Item.MaterialWhich Material should be returned?
- Item 10?
- Item 20?
- Item 30?
The compiler has no deterministic answer.
That uncertainty is exactly why TO MANY Associations are treated differently.
Why TO MANY Associations Cannot Always Be Used in WHERE
One of the most common syntax errors developers encounter is trying to use a TO MANY Association inside a WHERE condition.
where _Item.Material = 'TG11'This is not supported because the compiler cannot guarantee that the Association returns only one record.
If three matching items exist, which one should be compared with'TG11'?
Architect Perspective
This behavior is not an arbitrary CDS restriction.It exists to prevent ambiguous SQL semantics and protect developers from accidentally producing incorrect results.
Generated SQL Perspective
Let's compare how the compiler views two Associations.
| TO ONE | TO MANY |
|---|---|
| Maximum one matching record. | Multiple matching records possible. |
| Safe for scalar navigation. | May produce duplicate source rows. |
| Compiler has deterministic semantics. | Compiler must consider multiplicity. |
Real SAP Examples
| Association | Cardinality | Why? |
|---|---|---|
| Sales Order ā Customer | TO ONE | A Sales Order has only one Sold-To Customer. |
| Sales Order ā Items | TO MANY | A Sales Order may contain many Items. |
| Billing Document ā Accounting Items | TO MANY | One Billing Document can create multiple Accounting Entries. |
Real Project Example: Why SAP Designed Associations This Way
ā¢ A Fiori List Report needs only Customer Name.
ā¢ A RAP service needs Sales Order Items.
ā¢ An Analytical Query needs both.
SAP defines both TO ONE and TO MANY Associations once. Each consumer navigates only the Associations it requires.
This makes SAP's Virtual Data Model highly reusable while allowing the CDS compiler to generate SQL appropriate for each consumer.
Architect Perspective
Technical Architect InsightMany developers think TO ONE and TO MANY exist only for documentation.
They don't.
The CDS compiler actively uses Cardinality information to validate path expressions, determine navigation semantics and optimize generated SQL.
Declaring incorrect Cardinality is effectively providing incorrect metadata to the compiler.
š” SAP Best Practice
Never declare a TO ONE Association simply to bypass syntax restrictions.
If the business relationship is genuinely TO MANY, model it as TO MANY and design your CDS View accordingly.
ā Common Mistakes
- Using TO ONE because it 'works'.
- Ignoring the actual business relationship.
- Using TO MANY Associations inside unsupported WHERE conditions.
- Assuming Cardinality affects only documentation.
Why are TO MANY Associations more restricted than TO ONE Associations?
Answer: Because multiple target records may exist. The CDS compiler cannot always determine a single deterministic result for navigation, filtering or scalar expressions.
Can incorrect Cardinality affect compiler behavior?
Answer: Yes. The CDS compiler trusts the declared Cardinality during validation and SQL generation. Incorrect Cardinality provides incorrect metadata, which can lead to invalid assumptions and unexpected behavior.
š” Key Takeaway
TO ONE and TO MANY are much more than different Cardinality values.
They tell the CDS compiler whether navigation is guaranteed to return at most one record or whether multiple matching records are possible.
This distinction directly influences compiler validation, generated SQL, supported language constructs and overall CDS behavior.
In the next lesson, we'll compare Associations with traditional SQL JOINs and identify when each approach is most appropriate in ABAP Cloud development.