3. 权限数据模型深入

SAP 权限体系并不是一张“用户—权限”的平面表，而是由用户主数据、角色定义、权限对象值、字段值以及授权对象目录共同构成的多层数据模型。理解这套模型的关键，在于分清“谁拥有什么角色”“角色允许什么”“系统实际检查什么”这三件事分别落在哪些表里。本节围绕 AGR_USERS、AGR_DEFINE、AGR_1251、AGR_1252、USR04、USOBT、USOBX 等核心表，说明它们的字段含义、关联关系以及在权限治理中的典型查询用途。

一、用户与角色的分配层：AGR_USERS 与 USR04

AGR_USERS 是“用户—角色”分配表，核心字段包括 MANDT（客户端）、AGR_NAME（角色名）、UNAME（用户名）、FROM_DAT 与 TO_DAT（有效期起止）、ORG_FLAG 等。它回答的是“某用户被分配了哪些角色、在什么时间范围内有效”。在治理中，AGR_USERS 是排查“谁拥有高权限角色”的第一入口，也是离职、转岗、临时授权到期检查的基础表。

USR04 则是“用户—授权对象值”的分配表，字段包括 MANDT、UNAME、PROFILE（权限参数文件）、OBJCT（授权对象）、AUTH（授权名）、AKTPS（激活状态）、BEGDA/ENDDA（有效期）等。它记录的是用户层面直接获得的授权值，而非通过角色间接获得的部分。AGR_USERS 与 USR04 的区别很重要：前者是角色分配，后者是用户级授权，二者共同构成用户的实际权限来源。治理查询中，常把 AGR_USERS 与 USR04 联合使用，识别“角色之外还额外开了哪些权限”的例外情况。

二、角色定义层：AGR_DEFINE

AGR_DEFINE 是角色主数据表，字段包括 MANDT、AGR_NAME（角色名）、PARENT_AGR（父角色）、CREATE_USR、CREATE_DAT、LANGU、AGR_TYPE 等。它描述角色的基本属性、层级关系和创建信息。AGR_DEFINE 与 AGR_USERS 通过 AGR_NAME 关联，可以回答“某角色被分配给了多少用户”“角色是否还有父角色继承关系”。在职责分离治理中，AGR_DEFINE 常用于识别角色命名规范、角色类型（单一角色/复合角色）以及角色是否被废弃但仍被分配。

三、权限值层：AGR_1251 与 AGR_1252

AGR_1251 是角色权限值表，也是最常被查询的核心表之一。字段包括 MANDT、AGR_NAME、OBJECT（授权对象）、AUTH（授权名）、FIELD（字段名）、LOW（低值）、HIGH（高值）、DELETED（删除标记）等。它记录角色在某个授权对象、某个字段上允许的取值范围。例如，角色 Z_FI_AP 在授权对象 F_BKPF_BUK 的字段 BUKRS 上，LOW=1000、HIGH=1999，表示只允许访问公司代码 1000 到 1999 的会计凭证。

AGR_1252 是组织级别权限值表，字段包括 MANDT、AGR_NAME、OBJECT、AUTH、FIELD、LOW、HIGH 等，专门存放组织层级字段（如公司代码、工厂、采购组织、销售组织）的授权值。它与 AGR_1251 的区别在于：AGR_1251 覆盖所有授权字段，AGR_1252 聚焦组织级别字段，便于快速检查组织权限的分配范围。治理中，AGR_1251 用于分析功能权限，AGR_1252 用于分析组织权限，两者结合才能完整还原角色的权限边界。

四、授权对象目录层：USOBT 与 USOBX

USOBT 是授权对象默认值表，字段包括 OBJCT（授权对象）、AUTH（授权名）、FIELD（字段名）、DEFA（默认值）等。它定义每个授权对象在角色维护时建议的默认值，帮助管理员快速生成权限。USOBX 是授权对象检查表，字段包括 OBJCT、AUTH、FIELD、CHECKFLAG（检查标志）等，用于控制某个授权对象在运行时是否执行权限检查。USOBX 中的 CHECKFLAG 若为“X”，表示该对象参与权限检查；若为空，则表示不检查。治理中，USOBT 用于核对默认值是否被滥用，USOBX 用于确认关键对象是否真正被系统检查，避免“看似有权限、实际不检查”或“检查过严导致业务中断”的问题。

五、关联关系与治理查询用途

这些表之间的关联关系可以概括为一条主线：用户通过 AGR_USERS 获得角色，角色通过 AGR_DEFINE 定义，角色权限值存放在 AGR_1251 和 AGR_1252 中，而 USR04 记录用户级额外授权，USOBT 和 USOBX 则定义授权对象的默认值与检查规则。治理查询通常沿着这条主线展开。

例如，要排查“某用户是否拥有跨公司代码的过账权限”，可以先在 AGR_USERS 中按 UNAME 查出所有 AGR_NAME，再在 AGR_1251 中按 AGR_NAME 和 OBJECT='F_BKPF_BUK' 查询 LOW/HIGH 范围，最后在 AGR_1252 中确认组织级别字段 BUKRS 的授权值。如果 LOW 和 HIGH 覆盖了多个公司代码，就说明该角色存在跨组织权限，需要进一步评估是否违反职责分离要求。

再如，要检查“某个敏感授权对象是否真正被系统检查”，可以在 USOBX 中按 OBJCT 查询 CHECKFLAG。如果 CHECKFLAG 为空，说明该对象不参与运行时检查，即使角色中配置了权限值也不会生效；如果 CHECKFLAG 为“X”，则说明检查生效，需要确保权限值配置正确。这个判断在权限治理中非常关键，因为很多“权限看起来开了但实际没生效”或“权限没开但系统仍拦截”的问题，根源都在 USOBX 的检查标志上。

六、实际查询示例

以下示例展示如何通过 ABAP SQL 查询某用户通过角色获得的所有公司代码权限。假设用户名为 ZTEST_USER，授权对象为 F_BKPF_BUK，字段为 BUKRS：

SELECT a.agr_name, b.object, b.field, b.low, b.high
  FROM agr_users AS a
  INNER JOIN agr_1251 AS b
    ON a.agr_name = b.agr_name
  WHERE a.uname = 'ZTEST_USER'
    AND b.object = 'F_BKPF_BUK'
    AND b.field = 'BUKRS'
    AND b.deleted = ''
  INTO TABLE @DATA(lt_result).

查询结果中，每一行代表该用户通过某个角色获得的公司代码范围。如果同一用户通过多个角色获得不同范围，需要合并判断实际可访问的公司代码集合。治理中，这类查询常用于职责分离矩阵的自动比对，例如“拥有供应商主数据修改权限的用户，是否同时拥有付款审批权限”。

最后需要强调，这些表是权限治理的底层数据基础，但直接查询时要注意客户端字段 MANDT 的过滤、删除标记 DELETED 的排除以及有效期 FROM_DAT/TO_DAT 的判断。只有把这些条件都纳入查询逻辑，才能得到准确、可用的治理结论。