在 RAP 里设计一个稍微复杂一点的业务对象时，很快就会遇到一个问题，业务数据通常不是一张表能够表达完整的。一个销售订单有订单头，也有很多订单行。一个采购订单下面有项目，项目下面还可能继续挂账户分配。一个差旅申请下面有 Booking，Booking 下面又可能有 Supplement。到了 SAP S/4HANA 这样的企业系统里，这种父子结构几乎无处不在。如果只是从数据库建模角度观察，很容易把这些关系都理解成外键关系，或者认为用普通 CDS association 就够了。但进入 ABAP RESTful Application Programming Model，也就是 RAP 之后，事情发生了变化。RAP 不只是需要知道两张表能不能 Join，也不只是需要知道一个实体能不能导航到另一个实体。RAP 还需要知道，哪些 CDS entity 共同组成一个业务对象，哪个实体是业务对象入口，哪些实体属于它的组成部分，锁应该围绕谁建立，Draft 应该围绕谁组织，子实体通过什么路径创建，事务运行时应该把哪些节点看成同一个业务整体。这正是 CDS composition 出现的地方。SAP 官方对 RAP Business Object 的结构描述非常明确，一个业务对象从结构角度看，是由一棵通过 composition 相互连接的实体树组成的。树上的每一个节点都是 CDS entity，最顶层节点叫 root entity，它代表整个 Business Object。因此，在 RAP 语境下理解 composition，不能停留在「一个特殊的 association」这一层。更准确的理解应该是，composition 在 CDS 层声明业务对象内部