在 ABAP Development Tools 里打开/dmo/adm_i_travel这样的 CDS View Entity 时，经常会看到一种很有代表性的写法，Travel 自己保存CustomerID，真正的客户姓名、地址、电话和邮件却放在另一张 Customer 视图里。Travel 没有通过传统 SQL 的显式JOIN把 Customer 永久焊接进来，而是定义了一个_Customerassociation。这正是理解现代 ABAP CDS 数据模型时一个很关键的切入点。传统 SQL 更习惯描述一次查询应该怎样把两张表连接起来，而 CDS association 更偏向描述两个业务实体之间存在什么关系。Travel 和 Customer 的关系并不是某一个查询临时产生的关系，它本来就是业务模型的一部分。一条旅行记录属于某个客户，Travel 里保存客户编号，Customer 里保存客户主数据。从数据建模的角度看，这个关系应该能够被下游 CDS View、RAP、OData 以及 UI Navigation 继续使用，而不是每经过一层 View 都重新写一次JOIN。SAP 官方对 association 的描述也正是这个方向。Association 在 ABAP CDS 中定义实体之间的结构关系，可以把它理解成一种预先声明的 join relationship。只有真正使用 association target 数据时，它才会实例化为数据库层的JOIN。这种模式经常被称为join-on-demand。/