Association Masterclass
Lesson 4 of 15 – Association Lazy Loading & CDS Compiler Behavior
So far, we've learned how to create Associations and navigate them using path expressions. One important question still remains.
If Associations eventually become SQL JOINs, why doesn't SAP simply generate the JOIN immediately?
The answer lies in one of the smartest design decisions of ABAP CDS: Lazy Loading.
Learning Objectives
By the end of this lesson you will be able to:
- Explain Association Lazy Loading.
- Understand how the CDS compiler evaluates Associations.
- Predict when SQL JOINs will be generated.
- Understand why Associations improve reusability.
- Think like the CDS compiler instead of thinking in SQL.
Prerequisites
- Completion of Lessons 1–3.
- Understanding of Association syntax.
- Knowledge of Association Navigation.
Introduction
Developers who come from traditional SQL backgrounds often expect an Association to behave exactly like a JOIN. They assume that as soon as an Association is defined, SAP immediately joins both business objects.
That assumption is incorrect.
An Association is not a SQL JOIN. It is simply metadata describing a reusable relationship between two business objects. At the time the CDS View is activated, no SQL JOIN is generated merely because an Association exists.
Instead, SAP waits until a consumer actually requests data from the target business object. Only then does the CDS compiler decide whether a SQL JOIN is necessary.
Architect Perspective
One of the biggest mindset changes when learning ABAP CDS is moving away from thinking in terms of SQL JOINs.Instead, think in terms of business relationships.
Associations define relationships.
The CDS compiler decides when those relationships should become SQL.
What is Lazy Loading?
Lazy Loading is a software design principle in which work is postponed until it is actually required.
Rather than retrieving every possible piece of related information, the system retrieves only the data requested by the current consumer.
SAP applies exactly the same principle to Associations.
association [0..1] to I_Customer as _Customer
on $projection.SoldToParty = _Customer.CustomerAt this point, SAP knows that a relationship exists between Sales Orders and Customers.
However, the compiler still does nothing because no customer fields have been requested.
Traditional SQL Thinking
In traditional SQL, the developer explicitly decides which tables should be joined.
SELECT
so.SalesDocument,
c.CustomerName
FROM SalesOrder so
LEFT OUTER JOIN Customer c
ON so.SoldToParty = c.CustomerAs soon as this query executes, the database must perform the JOIN because the developer explicitly requested it.
Association Thinking
ABAP CDS follows a completely different philosophy.
association [0..1] to I_Customer as _Customer
on $projection.SoldToParty = _Customer.Customer
{
key SalesDocument,
SoldToParty
}Although the Association exists, no Customer fields are requested.
Therefore, the compiler has no reason to generate a SQL JOIN.
Compiler Decision
The relationship is stored for future use, but the target business object is not accessed because no consumer requires it.
INSIDE THE CDS COMPILER
No Navigation Found
💭 Compiler Thought Process
An Association exists, but no path expression references any fields from the target business object.
Compiler Decision Flow
Read the CDS View.
Detect the Association definition.
Validate the relationship condition.
Search for path expressions.
No navigation found.
No related data required.
✅ Final Compiler Decision
Skip SQL JOIN generation and execute the query using only the source CDS View.
⚡ SQL Optimization Insight
Associations themselves have almost no runtime cost. The compiler postpones SQL generation until a consumer actually navigates the relationship.
What Changes When an Association is Navigated?
Let's compare two nearly identical CDS Views.
The only difference is that the second CDS View accesses a field from the Association.
{
key SalesDocument,
SoldToParty
}No fields from the Customer business object are requested.
{
key SalesDocument,
SoldToParty,
_Customer.CustomerName
}That single additional line completely changes how the CDS compiler processes the query.
The CDS Compiler Decision Process
Every time a CDS View is consumed, the CDS compiler evaluates whether related business objects are actually required.
| Compiler Check | Decision |
|---|---|
| Association exists? | ✅ Yes |
| Path expression used? | Only if a target field is requested. |
| Target data required? | Compiler evaluates the requested elements. |
| SQL JOIN generated? | Only when navigation requires it. |
This decision process happens automatically. As developers, we simply define relationships and navigate them when necessary.
Conceptual SQL Generated by the Compiler
Although developers never write the SQL JOIN explicitly, the CDS compiler eventually transforms the Association into SQL when it is required.
SELECT
SalesDocument,
SoldToParty,
CustomerName
FROM I_SalesDocument
LEFT OUTER JOIN I_Customer
ON SoldToParty = CustomerThis SQL is shown only to help understand the compiler's behavior. The exact SQL generated by SAP HANA may differ depending on optimization performed by the database.
Performance Benefits of Lazy Loading
Lazy Loading offers several important advantages over eagerly joining every related business object.
| Benefit | Explanation |
|---|---|
| Better Performance | Unnecessary JOINs are avoided. |
| Reusable CDS Views | Different consumers navigate only the Associations they need. |
| Cleaner Code | Relationships are defined once instead of repeating JOIN logic. |
| Better Maintainability | Business relationships remain centralized. |
Real Project Example: Manage Sales Orders Fiori Application
Customer Name is not displayed on the overview screen, so the Association remains unused and no SQL JOIN is generated.
Later, when the user opens the Object Page or requests additional customer information, the CDS View navigates
_Customer.CustomerName.Only then does the CDS compiler generate the SQL JOIN required to retrieve customer master data.
Architect Perspective
Technical Architect InsightOne of the biggest advantages of SAP's Virtual Data Model is that CDS Views are designed for multiple consumers.
A reporting application, a RAP service, a Fiori application and an analytical query can all consume the same CDS View while navigating completely different Associations.
The compiler generates SQL specifically for the current consumer rather than executing every possible JOIN upfront.
💡 SAP Best Practice
Navigate them only when related data is required.
Let the CDS compiler decide when SQL JOINs should be generated instead of trying to optimize the SQL manually.
❌ Common Mistakes
- Assuming Associations automatically improve performance.
- Believing SQL JOINs are never generated.
- Thinking Associations store data.
- Navigating Associations even when related fields are not required.
What is Lazy Loading in ABAP CDS?
Answer: Lazy Loading postpones SQL JOIN generation until data from the target Association is actually requested.
Why doesn't the CDS compiler immediately generate SQL JOINs for every Association?
Answer: Because Associations represent reusable relationship metadata. The compiler generates JOINs only when a consumer navigates the Association through a path expression.
How does the CDS compiler decide whether an Association should become a SQL JOIN?
Answer: The compiler evaluates the requested elements of the CDS View. If no path expression accesses the target business object, the JOIN is skipped. If navigation occurs, the compiler generates the required SQL JOIN.
💡 Key Takeaway
Associations are intentionally lazy.
Defining an Association simply records a reusable business relationship. It does not retrieve any data.
When a path expression accesses fields from the target business object, the CDS compiler transforms that relationship into the appropriate SQL JOIN.
This compiler-driven approach is one of the key reasons SAP's Virtual Data Model remains reusable, maintainable and performant.
In the next lesson, we'll build on this understanding by exploring Association Cardinality, one of the most important concepts for correctness, performance and generated SQL behavior.