# 结果总览员工结果表设计文档

**模块**: 初核项目详情 - 结果总览
**日期**: 2026-03-20
**状态**: 已确认

## 一、背景

当前结果总览页已接通的查询包括：

- 风险仪表盘
- 风险人员总览
- 模型预警次数统计
- 命中模型涉及人员

现状中，这些查询依赖 `ccdi_bank_statement_tag_result`、`ccdi_bank_statement`、`ccdi_base_staff`、`ccdi_staff_fmy_relation` 的运行时连表归并与聚合。页面访问时会重复执行重 SQL，导致响应时间偏长，尤其是模型区和风险人员总览区块。

本轮目标是新增一张结果总览结果表，把“项目内每个员工的模型触发情况”预先沉淀下来，再基于该表编写页面查询 SQL，避免结果总览页面运行时直接连回源表。

## 二、目标

本次设计目标如下：

1. 新增一张结果总览员工结果表，记录项目内每个员工的结果快照。
2. 员工亲属的流水异常命中需归并计入该员工本人。
3. 页面查询只依赖项目表和结果总览员工结果表，不再运行时连 `标签结果表 + 流水表 + 员工表 + 亲属表`。
4. 命中结果写库成功后，在同一事务内按项目整块重算结果总览员工结果表。
5. 保持当前页面统计口径不变，尤其是模型卡片 `warningCount` 仍定义为原始标签命中次数。

## 三、范围

### 3.1 本次范围

- 设计结果总览员工结果表结构
- 设计员工本人和亲属命中的归并口径
- 设计命中结果写库后的同步重算链路
- 设计结果总览 4 类查询从结果表取数的方案
- 后续输出前后端实施计划与实施记录

### 3.2 不在本次范围

- 不覆盖结果总览风险明细区块
- 不引入异步刷新、缓存或消息队列
- 不做增量更新，只做按项目整块重算
- 不新增多张平行结果表
- 不保留中高风险 TOP10 区块及其专用查询设计

## 四、当前口径约束

本次设计确认以下业务口径：

1. 结果表粒度为 `项目 + 员工`，一行代表一个项目内一个归并后的员工结果。
2. 员工亲属的流水异常命中，必须归并到对应员工本人名下。
3. 命中结果写库成功后，结果表需要在同一事务内同步重算完成。
4. 重算方式采用“按项目整块重算当前已接通区块所需数据”。
5. 模型卡片中的 `warningCount` 定义保持现状，为原始标签命中次数，而不是员工人数或规则去重数。

## 五、方案对比

### 5.1 方案 A：直接存页面结果快照

做法：

- 按项目保存仪表盘、风险人员总览、模型卡片、模型人员列表等页面结果快照

问题：

- `命中模型涉及人员` 存在 `ANY / ALL / keyword / deptId / pageNum` 等动态筛选
- 一旦直接存页面结果，筛选和分页要么退化为内存处理，要么继续依赖复杂 JSON 查询
- 无法满足“先保存员工触发情况，再根据结果表写 SQL”的要求

### 5.2 方案 B：单表保存项目内每个员工的结果快照

做法：

- 新增一张结果总览员工结果表
- 以 `project_id + staff_id_card` 为唯一口径
- 每行保存员工基础信息、风险统计、模型命中快照、规则命中快照
- 页面查询全部基于该表聚合或筛选

优点：

- 符合“先存员工触发情况，再写页面 SQL”的要求
- 页面查询可以收敛为单表查询
- 兼容 `ANY / ALL`、关键字、部门、分页等动态筛选
- 与当前统计口径兼容，不需要改业务定义

缺点：

- 命中结果写库后需要按项目整块重算该表
- 表中会存在部分汇总冗余字段和 JSON 快照字段

### 5.3 方案 C：多张专用结果表

做法：

- 仪表盘、风险人员、模型卡片、模型人员分别建独立结果表

问题：

- 不符合本轮“创建一张结果总览结果表”的目标
- 数据维护面更大，DDL 和重算逻辑更分散

### 5.4 推荐方案

采用方案 B：新增一张“结果总览员工结果表”，以员工为核心粒度预聚合，再由页面查询基于该表出数。

## 六、结果表设计

建议表名：

- `ccdi_project_overview_employee_result`

建议主键与唯一性约束：

- 主键：`id`
- 唯一键：`uk_project_staff (project_id, staff_id_card)`

建议字段如下。

### 6.1 基础标识字段

- `project_id`
- `staff_id_card`
- `staff_id`
- `staff_name`
- `staff_code`
- `dept_id`
- `dept_name`

### 6.2 风险统计字段

- `rule_count`
  - 该员工命中的规则数，按 `rule_code` 去重
- `model_count`
  - 该员工命中的模型数，按 `model_code` 去重
- `hit_count`
  - 该员工归并后的原始标签命中总次数
- `risk_level_code`
  - 依据现有规则推导 `HIGH / MEDIUM / LOW`
- `top_rule_code`
- `top_rule_name`
- `risk_point`
  - 按命中次数降序、规则编码升序拼接规则名

### 6.3 模型与规则快照字段

- `model_codes_csv`
  - 员工命中的全部模型编码，逗号分隔，统一按编码排序
- `model_names_json`
  - 员工命中的模型名称数组
- `hit_rules_json`
  - 员工命中的规则数组，元素建议至少包含：
    - `ruleCode`
    - `ruleName`
    - `riskLevel`
    - `modelCode`
    - `modelName`
    - `hitCount`
- `model_hit_summary_json`
  - 员工按模型汇总的数组，元素建议至少包含：
    - `modelCode`
    - `modelName`
    - `warningCount`
    - `ruleCount`
    - `hitRuleList`

其中：

- `warningCount` 表示该员工在该模型下的原始标签命中次数
- `hitRuleList` 用于页面“异常标签”展示

### 6.4 审计字段

- `create_by`
- `create_time`
- `update_by`
- `update_time`

## 七、员工归并与重算链路

### 7.1 归并口径

员工结果重算时，继续沿用当前结果总览链路中的归并规则：

1. 员工本人命中，归并到本人。
2. 当命中对象为空或为亲属对象时，通过流水身份证号或亲属身份证号映射到员工本人。
3. 无法归并到员工本人的命中记录，不进入结果总览员工结果表。

本轮不调整归并逻辑，只把这一步从页面查询阶段前移到结果表重算阶段。

### 7.2 重算触发时机

触发点放在命中结果写库成功之后、事务提交之前。

触发顺序固定为：

1. 写入当前项目标签结果
2. 删除当前项目历史员工结果
3. 基于当前项目全量标签结果，按员工归并口径重算员工结果
4. 批量插入新的员工结果
5. 同事务刷新项目表中的高/中/低风险人数
6. 提交事务

### 7.3 重算方式

本次采用按项目整块重算，不做增量更新。

原因：

- 需求已明确接受按项目整块重算
- 这样实现路径最短，且避免增量口径漂移
- 同事务内先删后插更容易保证一致性

## 八、页面查询改造方案

改造后，结果总览页查询只依赖：

- `ccdi_project`
- `ccdi_project_overview_employee_result`

### 8.1 风险仪表盘

来源：

- `ccdi_project.target_count`
- 员工结果表按 `risk_level_code` 的人数统计

查询方式：

- 高风险人数：结果表中 `risk_level_code = 'HIGH'`
- 中风险人数：结果表中 `risk_level_code = 'MEDIUM'`
- 低风险人数：结果表中 `risk_level_code = 'LOW'`
- 无风险人数：`target_count - high - medium - low`

### 8.2 风险人员总览

来源：

- 员工结果表单表查询

返回字段：

- `staff_name`
- `staff_id_card`
- `dept_name`
- `hit_count`
- `risk_level_code`
- `model_count`
- `risk_point`

排序延续现有口径：

- 风险等级
- 模型数
- 规则数
- 员工身份证号

### 8.3 模型预警次数统计

来源：

- 员工结果表中的 `model_hit_summary_json`

查询逻辑：

1. 先按项目过滤员工结果表
2. 展开每位员工的模型汇总
3. 按 `modelCode` 聚合

统计口径：

- `warningCount` = 各员工该模型 `warningCount` 求和
- `peopleCount` = 命中该模型的员工人数

排序口径：

- `warningCount desc`
- `model_code asc`

### 8.4 命中模型涉及人员

来源：

- 员工结果表中的 `model_codes_csv`
- `model_names_json`
- `hit_rules_json`
- `model_hit_summary_json`

筛选规则：

- `keyword`：匹配员工姓名或工号
- `deptId`：精确匹配部门
- `modelCodes`：
  - `ANY`：命中任一所选模型即可
  - `ALL`：必须同时命中全部所选模型

实现建议：

- `ANY / ALL` 筛选优先基于 `model_codes_csv`
- `modelNames` 和 `hitTagList` 展示基于 JSON 快照组装

这样可以把：

- 结构化筛选
- 模型条件判断
- 分页排序

都控制在结果表层完成，避免回源连表。

## 九、索引建议

为保证页面查询稳定，建议增加如下索引：

- 唯一键：`(project_id, staff_id_card)`
- 普通索引：`(project_id, risk_level_code)`
- 普通索引：`(project_id, dept_id)`
- 普通索引：`(project_id, staff_name)`
- 普通索引：`(project_id, staff_code)`

本轮先不扩展模型专用索引，优先依赖整项目重算后的结果表降本。如果后续 `model_codes_csv` 筛选成为瓶颈，再评估是否引入模型筛选辅助列。

## 十、测试与验收口径

本次设计的验收以“结果表口径与当前业务口径一致”为准，重点验证：

1. 同一项目下，结果表员工数应等于当前可归并出的员工数。
2. 员工亲属的流水异常命中必须归并到员工本人。
3. 风险仪表盘的高/中/低人数与结果表按等级统计一致。
4. 风险人员总览展示字段与结果表字段映射一致。
5. 模型卡片 `warningCount` 必须等于原始标签命中次数汇总。
6. 模型卡片 `peopleCount` 必须等于命中该模型的员工人数。
7. 命中模型涉及人员在 `ANY / ALL / keyword / deptId` 条件下的结果，必须与旧逻辑一致。

## 十一、结论

本次设计采用“单张结果总览员工结果表”作为结果总览页的唯一预聚合载体。

核心结论如下：

1. 结果表粒度为 `项目 + 员工`。
2. 员工亲属命中统一归并到员工本人。
3. 命中结果写库成功后，同一事务内按项目整块重算结果表。
4. 页面查询不再直接运行重连表聚合 SQL，而是基于结果表聚合或筛选。
5. 模型卡片 `warningCount` 继续保持原始标签命中次数口径。

该方案满足“最短路径实现、口径一致、页面查询降本”的目标，后续可据此输出前后端实施计划并进入实现阶段。