在一个真实的 SAP CDS 数据模型里，数据很少只经过一层 View 就直接暴露给应用。更常见的结构是底层 Interface View 负责数据建模，中间层承担业务语义，上层 Projection View 或 Consumption View 面向 RAP、OData、Fiori Elements 等消费者。这时很容易出现一个授权上的误判。底层 CDS View 已经有一套 DCL Access Control，开发者看到上层 CDS 又是从这个受保护的 View 读取数据，很自然地会认为底层的授权过滤会沿着 View Stack 一层层传递上来。实际上并不会。SAP 官方对 CDS Authorization Concept 的描述非常明确，CDS Role 只保护它直接引用的 CDS Entity。当一个受保护的 CDS Entity 被另一个 CDS Entity 当作数据源使用时，访问控制不会因为这种数据依赖关系而自动向上层传播。上层 Entity 如果也需要受到保护，就必须拥有自己的 Access Control。SAP 同时提供了专门的 inheritance condition，让上层 DCL 可以显式复用另一个 CDS Entity 已经存在的访问条件。这套机制对应的核心语法就是inheriting conditions from entity它解决的并不是简单的代码复用问题，而是多层 CDS 数据模型中授权规则如何保持一致的问题。本文使用 SAP 提供的 Travel 示例贯穿整个过程。底层/dmo/adm_i_travel_ac只允许访问 Age
