今天我们打开一张 SAP Fiori 业务单据，数量字段显示为120 EA，计量单位代码没有错，数据库里的值也完全正常，可业务人员真正希望看到的是120 件，或者至少在EA旁边显示可读名称。类似问题在物料组、公司代码、销售组织、付款条件、运输方式等字段上反复出现。技术代码适合参与连接、筛选和接口传输，描述文本更适合人阅读。两者若被揉进同一个字段，主数据治理、翻译维护和接口稳定性都会受到影响。ABAP CDS 的文本关联正是为这种代码与文本分离的模型准备的。SAP 对文本关联的定义很明确。一个标识字段可以通过 CDS association 指向文本提供视图，文本通常依赖语言。字段带上@ObjectModel.text.association之后，SADL 会在 OData 暴露阶段把目标文本补充到引用实体，并按照 OData 消费者的登录语言自动过滤。CDS 视图不必为了这件事显式读取会话语言，也不必额外设计语言参数。这套机制看起来只是少写了一个join，真正的价值却在语义层。普通数据库连接只告诉运行时两组数据如何匹配，文本关联还告诉 SADL、OData 元数据和上层消费者，某个字段是业务标识，另一个字段是它的可读描述。代码仍然是稳定的技术键，文本可以按照语言变化。我们的服务模型因此不会因为中文名称、英文名称或德文名称不同而改变业务主键，也不会把翻译逻辑散落到每一个消费视图里。官方示例围绕计量单位展开。基础表T006保存计量单位代码，语言相关文本来自T006A。在业务数据中保存EA、