一个 SAP Fiori Elements 列表页里，计量单位字段从后端返回EA，业务人员期待看到的是「件」，英文登录用户期待看到的是Each，德文登录用户可能希望看到对应的德文描述。EA适合程序处理，却不适合直接交给业务人员阅读。类似情况还会出现在产品状态、订单类型、运输方式、国家代码、付款条件、库存地点和业务伙伴角色等字段上。如果我们把这些代码和描述全部塞进同一张业务表，数据模型很快就会变得混乱。一个代码可能对应十几种语言，新增一种语言还可能要求调整表结构。更麻烦的是，同一段文本会被大量业务记录重复保存，既浪费空间，也增加了翻译和维护成本。成熟的 SAP 数据模型通常把稳定的标识代码和依赖语言的描述文本分开存储。业务实体保存EA、KG、PC这一类稳定值，文本实体保存代码在不同语言下的名称。ABAP CDS 文本关联正是连接这两个世界的语义桥梁。通过@ObjectModel.text.association，我们可以声明某个字段的描述来自哪一个文本视图。OData 服务运行时会依据消费者的登录语言自动选择相应文本，不需要在 CDS 视图里额外定义语言参数，也不需要显式使用会话属性进行过滤。SAP 官方文档将这种机制定义为通过文本关联直接获取语言相关文本。文本关联不是普通的表连接从 SQL 角度观察，文本关联看起来很像业务表与文本表之间的一次连接。只要把产品状态代码与文本表中的状态代码匹配起来，再附加语言条件，似乎就能得到描述。但 CDS