CDS Associations Part 1: Source, Target, ON Condition and Cardinality

📌 KEY POINTS
✅ An association is a declared relationship — it is joined only when someone uses it.
✅ Syntax: association [cardinality] to Target as _Alias on <condition>.
✅ Use $projection (or the source alias) in the ON condition and expose the field used in it.
⚠️ Cardinality must describe the real data — wrong cardinality causes wrong results and slow plans.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

• Part 1 — declaring an association (this lesson)
• Part 2 — path expressions: how associations become joins
• Part 3 — to-one vs to-many: semantics and performance
• Part 4 — associations vs compositions in RAP
• Part 5 — troubleshooting duplicates, missing data and slow queries

Prerequisite: CDS Views Parts 1–3.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT AN ASSOCIATION IS
A join says "combine these two sources now". An association says "these two entities are related like this" and leaves it to the consumer whether to follow the relationship. That makes one view reusable: a list that needs only order numbers never pays for the customer join, while an object page can follow _Customer to show the name.

━━━━━━━━━━━━━━━━━━━━
▶ THE SYNTAX, PIECE BY PIECE
association [0..1] to ZI_Customer as _Customer
on $projection.Customer = _Customer.Customer

• [0..1] — cardinality: how many target rows per source row (Part 3).
• to ZI_Customer — the target: another CDS entity (not a table in clean designs).
• as _Customer — the alias. Convention: start with an underscore.
• on … — the join condition. The source side uses $projection.<element> (the element name in your view) or the source alias; the target side uses _Alias.<element>.

📌 REMEMBER: every source field used in the ON condition with $projection must be in the element list.

━━━━━━━━━━━━━━━━━━━━
▶ EXPOSING THE ASSOCIATION
Declaring the association is not enough for consumers. Add the alias to the element list:
{ …, Customer, _Customer }
Now other views, ABAP SQL and OData can follow it. If you only need it inside this view (e.g. to read one field), you may use it in a path without exposing it.

━━━━━━━━━━━━━━━━━━━━
▶ CARDINALITY NOTATION

• [0..1] or [1] — to-one (at most one / exactly one target row).
• [0..*] or [*] — to-many.
• [1..*] — at least one.

If you omit it, the default is [0..1] — never rely on the default; always write it.
💡 TIP: newer releases also offer a more readable cardinality syntax (e.g. "association of many to one"). Use it if your system supports it; the meaning is the same.

━━━━━━━━━━━━━━━━━━━━
▶ ASSOCIATIONS WITH EXTRA CONDITIONS
The ON condition can contain more than key equality, e.g. a language condition:
association [0..1] to ZI_OrderStatusText as _StatusText
on $projection.OverallStatus = _StatusText.Status
and _StatusText.Language = $session.system_language
Such a condition turns a to-many text table into a to-one association.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Open ZI_SalesOrder (from CDS Views).
2. Add associations to the customer, the items and the status text as in the code example.
3. Expose them in the element list; activate.
4. Open Data Preview, select a row, and use "Follow Association" to navigate — no join was written.

✅ CHECKPOINT: you can declare, expose and navigate an association. Part 2 shows exactly what SQL is generated when you use it.

A project had one "universal" sales order view with inner joins to customer, material, plant and status texts. Every consumer — list report, API and three analytics queries — paid for all joins, and orders with a missing plant disappeared entirely because of the inner join.
The team rebuilt it as an interface view with associations and only the header fields. Each consumer now follows only the associations it needs. The list report became several times faster, and the "missing orders" defect vanished because unused associations are no longer joined at all.

• Using hard joins where an association would let consumers decide.
• Using a field with $projection in the ON condition without adding it to the element list.
• Forgetting to expose the association, so consumers cannot navigate.
• Omitting cardinality and relying on the default.
• Declaring a text association without a language condition, making it to-many.
• Pointing associations at tables instead of CDS entities.

• Model relationships as associations in interface views.
• Always state cardinality explicitly and correctly.
• Name associations with a leading underscore and a business name.
• Add language or validity conditions to make text and time-dependent relations to-one.
• Expose associations that consumers need; keep internal ones unexposed.

Questions: "What is a CDS association?", "How is it different from a join?", "What is $projection?", "Why must you specify cardinality?"
Strong answer: an association is a declared relationship that becomes a join only when used (path expression or $expand). $projection refers to elements of the current view in the ON condition, and those elements must be in the element list. Cardinality documents the business relation and influences correctness and optimization; the default [0..1] should never be relied on. Mention text associations with a language condition as a practical example.