# 图谱开发决策记录

记录当前已确认的资金流图谱和关系图谱开发口径，作为后续开发、验收和跨对话延续的依据。

## 1. 页面嵌入位置

- 图谱功能先嵌入项目详情页的“专项排查”页签。
- 现有前端入口为 `ruoyi-ui/src/views/ccdiProject/components/detail/SpecialCheck.vue`。
- 页面在项目详情内承载，但资金流图谱本身不按 `project_id` 过滤。
- 查询入口以全局身份证号 `cret_no` 或员工姓名为准。

## 2. 图谱表结构原则

- 建表逻辑尽量保持图谱平台已验证过的 SQL 逻辑。
- 不重新设计统一点表/边表。
- 表名保留图谱平台 SQL 中的五张结果表：
  - `lx_fund_flow_subject_node`
  - `lx_fund_flow_account_node`
  - `lx_fund_flow_own_account_edge`
  - `lx_fund_flow_detail_edge`
  - `lx_fund_flow_sum_edge`
- 不在五张图谱表中增加 `project_id` 作为查询过滤口径。
- 一条流水可能存在于多个项目中，资金流图谱按全局资金关系构建，避免项目维度导致重复建点或重复算边。

## 3. 五张表职责

| 表名 | 作用 |
| --- | --- |
| `lx_fund_flow_subject_node` | 主体点，表示人员、企业、名称代理主体 |
| `lx_fund_flow_account_node` | 账户点，表示具体账号或名称代理账户 |
| `lx_fund_flow_own_account_edge` | 主体到账户的持有关系 |
| `lx_fund_flow_detail_edge` | 账户层逐笔资金交易边 |
| `lx_fund_flow_sum_edge` | 主体层资金汇总边，前端默认展示 |

关键点：

- 一个人可能有多个账号，所以必须保留主体点、账户点、持有边三层结构。
- 前端默认展示主体层汇总边，不默认展示全部账户层明细边，避免节点过多。
- 点击汇总边后，再查询账户层逐笔流水。

## 4. 构建逻辑

构建逻辑以 `tupu/资金流图谱代码/lanxi_liushui_no_relation_simplified.sql` 为主。

重要口径：

- 项目内 SQL 尽量和图谱平台原 SQL 保持一致。
- 先导入一部分“所有员工流水明细”作为图谱基座。
- 这部分基座数据视为已验证、绝对正确，不应被后续构建流程随意清空或覆盖。
- 后续从 `ccdi_bank_statement` 拉取新增流水时，需要先和图谱基座做一致性判断。
- 如果 `ccdi_bank_statement` 中的流水已经能在图谱基座中匹配到一致流水，则不同步进图谱，避免重复计入。
- 如果没有匹配到一致流水，则按原图谱 SQL 逻辑增量插入图谱。

保留的核心口径：

- 本方证件号 `cret_no` 必须存在。
- 对手方名称必须存在，空值、空串、`0` 过滤。
- 金额必须有效，支出和收入统一成 `amount` 与 `flag`。
- 支出 `flag = 1`，收入 `flag = 2`。
- 明细去重，避免重复流水导致金额和笔数翻倍。
- 同名归并只作用于主体层，不改变账户节点和账户明细边。
- 无账号但有名称的对手方，按原 SQL 逻辑生成名称代理账户和名称代理主体。

一期先不展开追溯能力。需要为后续追溯预留字段和逻辑口子：

- `source_table`
- `penetrate_level`
- 后续可扩展 `FIRST`、`LEVEL1` 等来源。

## 4.1 基座与增量同步口径

图谱表不是“清空重建”的临时结果表，而是承载已验证图谱基座和后续增量的正式结果表。

基座数据：

- 来源为先导入的所有员工流水明细。
- 按原图谱平台 SQL 生成五张 `lx_*` 表。
- 基座数据作为可信结果保留。

增量数据：

- 来源为后续 `ccdi_bank_statement`。
- 拉取后先按原 SQL 的流水标准化和去重口径生成候选流水。
- 候选流水和既有 `lx_fund_flow_detail_edge` 做一致性比对。
- 已存在一致流水时跳过，不插入图谱。
- 不存在一致流水时，再增量生成账户点、主体点、持有边、明细边和汇总边。

一致性比对建议使用稳定业务特征，而不是 `project_id`：

- 本方账号
- 本方户名
- 对手方账号
- 对手方户名
- 交易日期
- 金额
- 收支方向 `flag`
- 摘要 `user_memo`
- 银行流水号或交易流水号，如果有

增量插入要求：

- 点表按 `object_key` 去重插入。
- 持有边按 `object_key` 去重插入。
- 明细边先判重，未存在才插入。
- 汇总边需要按主体对和方向重新聚合或局部 upsert，不能简单追加导致金额翻倍。

## 4.2 ODPS 基座同步到 MySQL

当前真实部署口径：

- 原图谱 SQL 已在 ODPS 中有一份结果。
- ODPS 结果只涉及行内流水。
- ODPS 已经产出五张图谱结果表。
- 可以先将 ODPS 中五张结果表一次性同步到纪检 MySQL。
- MySQL 同步建表脚本记录在 `sql/ccdi/graph/01_lx_fund_graph_mysql_ddl.sql`。
- 生产数据库表结构变更由人工单独执行，不跟随测试环境或应用发布自动更新。
- 项目内保留 SQL 文件，用于本地验证、评审和生产手动执行参考。

同步后的 MySQL 五张表继续使用原图谱表名：

- `lx_fund_flow_subject_node`
- `lx_fund_flow_account_node`
- `lx_fund_flow_own_account_edge`
- `lx_fund_flow_detail_edge`
- `lx_fund_flow_sum_edge`

同步要求：

- ODPS 到 MySQL 首次同步只做基座装载。
- 基座装载完成后，后续不再通过清空五张表重建处理。
- ODPS 字段和 MySQL 字段同名的按显式字段列表导入。
- MySQL 侧新增字段如 `family_relation_type`、`summary_object_key`、`source_table`、`penetrate_level`、`bank_statement_id`、`bank_trx_number` 可为空。
- `lx_fund_flow_sum_edge.detail_ids` 在 MySQL 中使用 `LONGTEXT` 接收 ODPS ARRAY 同步后的 JSON 或字符串表示，前后端查询不强依赖该字段。

## 4.3 MySQL 后续增量方式

后续新增数据都在纪检 MySQL 内处理：

- 来源表为 `ccdi_bank_statement`。
- 增量逻辑从 `ccdi_bank_statement` 抽取候选流水。
- 候选流水按原图谱 SQL 口径标准化、过滤、生成 object_key。
- 先和既有 `lx_fund_flow_detail_edge` 做一致性判重。
- 已存在一致流水时不插入图谱。
- 不存在一致流水时，才增量插入点、账户、持有边、明细边。
- 汇总边 `lx_fund_flow_sum_edge` 按主体对和方向重新聚合或局部 upsert。

调度建议：

- 一期建议做每日定时调度，不建议一开始做实时。
- 推荐使用 RuoYi/Quartz 定时任务，每天凌晨或低峰期执行。
- 同时保留后台手动触发能力，便于首次补跑、排查和修复。
- 实时同步不是不能做，但没有必要优先做；实时会增加事务、锁、重复判断和汇总边更新复杂度。

推荐执行节奏：

1. ODPS 五张结果表一次性同步到 MySQL。
2. MySQL 跑一次家庭关系补充和 `summary_object_key` 回填。
3. 每日 Quartz 调度从 `ccdi_bank_statement` 抽取新增候选流水。
4. 候选流水与 `lx_fund_flow_detail_edge` 判重。
5. 未命中重复的流水增量入图。
6. 更新对应主体层汇总边。
7. 前端始终只基于 MySQL 五张 `lx_*` 图谱表查询展示。

## 4.4 数据库变更执行边界

数据库表结构改动属于生产库手工变更，不纳入测试环境自动更新。

后续开发分工：

- SQL 文件由代码库保留，作为生产手工执行依据和本地验证依据。
- 生产执行由人工确认后单独处理。
- 后端开发默认这些表在目标库中已经存在。
- 前端开发不感知数据库变更，只调用后端接口。
- 测试环境如没有这五张表，需要手动执行 SQL 后再联调。
- 应用发布包不自动执行这些 DDL。

## 5. 家庭关系

家庭关系是本次项目内新增能力，参考 `tupu/资金流图谱代码/资金流图谱_家庭关系补充.sql`。

处理原则：

- 不改变资金方向。
- 不改变主体归并逻辑。
- 不改变账户层明细边生成逻辑。
- 只在资金边上增加家庭关系标注。

匹配规则：

- 交易任意一侧可映射到员工主体。
- 员工主体必须有身份证号。
- 对手方姓名命中 `ccdi_staff_fmy_relation.relation_name`。
- 同一员工和同一关系人姓名只有一个 `relation_type` 时才标注。
- 多个关系类型冲突时不打标，避免误判。

建议补充字段：

- `lx_fund_flow_detail_edge.family_relation_type`
- `lx_fund_flow_sum_edge.family_relation_type`

## 6. 查询逻辑

搜索主体：

```sql
select *
from lx_fund_flow_subject_node
where idnocfno = #{keyword}
   or name like concat('%', #{keyword}, '%');
```

查询主体层资金图：

```sql
select *
from lx_fund_flow_sum_edge
where from_key = concat('idno_node/', #{objectKey})
   or to_key = concat('idno_node/', #{objectKey})
order by amount desc, total_trans_cnt desc
limit #{limit};
```

点击汇总边查询逐笔流水：

```sql
select *
from lx_fund_flow_detail_edge
where summary_object_key = #{sumObjectKey}
order by trx_date desc
limit #{offset}, #{pageSize};
```

说明：

- 原图谱平台 `detail_ids` 可以保留。
- MySQL 分页查询建议增加 `summary_object_key`，用于从汇总边直接查明细边。
- `summary_object_key` 是查询优化字段，不改变原图谱平台点边模型。

## 7. 前后端开发边界

后端负责：

- 从五张 `lx_*` 图谱结果表读取数据。
- 按身份证号或姓名定位主体。
- 返回主体层图谱节点和汇总边。
- 支持点击资金汇总边分页查询逐笔流水。
- 透出家庭关系字段。
- 空表或脏数据时返回空结果，不让前端报错。

前端负责：

- 在“专项排查”页签中呈现图谱展示区域。
- 支持身份证号或员工姓名搜索。
- 支持“资金图谱 / 关系图谱”页签。
- 一期资金图谱做实，关系图谱可先保留入口。
- 默认展示主体层资金汇总图。
- 点击边展示逐笔流水明细。
- 展示图谱明细边中已写入的家庭关系标签，如配偶、父母、子女。

## 8. 基座保护与异常数据处理

图谱表承载已验证基座，不按“可随意清空重建”设计。人工可以维护或清理异常数据，但默认应保护已有基座。

处理要求：

- 后续增量同步不得清空五张 `lx_*` 表。
- 增量同步前必须先判断候选流水是否已存在于 `lx_fund_flow_detail_edge`。
- 已存在一致流水时跳过，避免重复金额和重复笔数。
- 人工清理异常边后，后端查询需要能容忍局部缺失数据。
- 边表有、点表缺失时，后端过滤无法匹配节点的边，不让前端报错。
- 明细边为空时，点击汇总边提示暂无逐笔流水。
- 如果人工确实清理了部分图谱数据，后续增量插入仍需按 `object_key` 和流水一致性规则防重。

## 9. UI 风格

固定设计口径：

- 浅色系统风格。
- 正式后台质感。
- 与当前纪检系统色调保持一致，蓝、白、灰为主。
- 朝图谱平台式交互靠齐。
- 不做黑色大屏。
- 不做网感、霓虹、炫光科技风。
- 图谱画布使用浅灰白背景，边界清楚。
- 搜索区放在顶部，支持身份证号和姓名。
- 页签为“资金图谱”和“关系图谱”。
- 明细使用右侧抽屉或下方面板展示，优先保证字段清楚和分页性能。

## 10. 后续开发顺序

建议顺序：

1. 先落项目内 SQL：DDL、构建 SQL、家庭关系补充 SQL、索引 SQL。
2. 先支持已导入员工流水明细作为图谱基座。
3. 增加 `ccdi_bank_statement` 到图谱表的增量同步逻辑。
4. 增量同步必须先和既有 `lx_fund_flow_detail_edge` 做一致性判重，已存在则不同步。
5. 后端接口改为读取五张 `lx_*` 图谱表。
6. 前端在“专项排查”页签接入图谱展示区域。
7. 完成资金图谱搜索、展示、点击边查明细。
8. 增加家庭关系标签展示。
9. 验证基座保护、增量防重、一个人多个账号、家庭关系命中等场景。

## 11. 当前代码进度与偏差

截至 2026-05-28，项目内已经做过一版一期资金流图谱代码，但这版实现口径与当前最终方案不完全一致，后续需要重构而不是直接当最终版。

已完成过的代码：

- 后端新增 `CcdiFundGraphController`，接口路径为 `/ccdi/project/fund-graph/graph` 和 `/ccdi/project/fund-graph/edge-detail`。
- 后端新增 DTO/VO：`CcdiFundGraphQueryDTO`、`CcdiFundGraphEdgeDetailQueryDTO`、`CcdiFundGraphVO`、`CcdiFundGraphNodeVO`、`CcdiFundGraphEdgeVO`、`CcdiFundGraphStatementVO`。
- 后端新增 Mapper 和 Service：`CcdiFundGraphMapper`、`ICcdiFundGraphService`、`CcdiFundGraphServiceImpl`、`CcdiFundGraphMapper.xml`。
- 前端新增接口文件 `ruoyi-ui/src/api/ccdi/fundGraph.js`。
- 前端新增组件 `ProjectAnalysisFundFlowTab.vue`。
- 前端已在 `ProjectAnalysisDialog.vue` 中接入资金流图谱页签。

旧版已验证情况：

- `mvn -pl ccdi-project -am compile -DskipTests` 通过。
- `npm run build:prod` 通过。
- 真实库只读校验过项目 33 和姓名样例，能查出资金边，点击边能查逐笔流水。
- 曾修正 MySQL 8 保留词别名 `rows` 和字符集排序规则不一致问题。

当前偏差：

- 旧版接口是实时从 `ccdi_bank_statement` 聚合资金图谱，不读取五张 `lx_*` 图谱结果表。
- 旧版查询带项目上下文，当前最终口径是不按 `project_id` 过滤，以全局 `cret_no` 或姓名为入口。
- 旧版前端接在项目分析弹窗 `ProjectAnalysisDialog`，当前最终入口应放在“专项排查”页签。
- 旧版没有按图谱平台五表基座和增量同步口径处理。
- 旧版没有家庭关系标注。

后续处理原则：

- 可复用旧版的图谱展示、点击边查明细、分页表格等前端交互经验。
- 可复用旧版 DTO/VO 中适合前端展示的字段，但字段来源需要改为五张 `lx_*` 表。
- 后端 SQL 必须从实时聚合 `ccdi_bank_statement` 改为读取 `lx_fund_flow_subject_node`、`lx_fund_flow_account_node`、`lx_fund_flow_own_account_edge`、`lx_fund_flow_detail_edge`、`lx_fund_flow_sum_edge`。
- 前端入口需要从项目分析弹窗迁移或重做到“专项排查”页签。
- 旧版文件在重构时应谨慎处理，避免影响当前项目分析弹窗已有功能。

## 12. 页面查询与汇总表最新决策

最新决策：

- 纪检平台资金流图谱页面不强依赖 `lx_fund_flow_sum_edge`。
- 页面查询以 `lx_fund_flow_detail_edge` 为事实表，由后端按当前查询条件实时聚合。
- 前端不做金额和笔数聚合，只负责渲染后端返回的节点、边和明细。
- `lx_fund_flow_sum_edge` 如生产侧不需要兼容图谱平台页面，可以不作为纪检页面必需表。
- 如果 ODPS 已有 `lx_fund_flow_sum_edge`，可以选择不同步到 MySQL，或同步后仅作为参考缓存，不作为纪检页面查询依据。

原因：

- 用户每次查询通常以一个人为中心，一跳图谱范围可控。
- 用户需要按 `trx_date` 任意筛选时间范围。
- 全量 `lx_fund_flow_sum_edge` 不能准确表达任意时间段内的金额和笔数。
- 每天新增明细后维护汇总表会增加复杂度。
- 后端从明细边实时聚合能保证筛选结果准确，且比前端聚合更可靠。

后端聚合口径：

1. 用身份证号、姓名或 `object_key` 定位主体点。
2. 查询该主体名下账户。
3. 从 `lx_fund_flow_detail_edge` 查询这些账户相关流水。
4. 按 `trx_date`、金额、方向、家庭关系等筛选条件过滤。
5. 后端将账户层明细边聚合为主体层资金边。
6. 返回前端用于图谱展示。

时间筛选字段：

- 所有时间筛选基于 `lx_fund_flow_detail_edge.trx_date`。
- 不用 `lx_fund_flow_sum_edge.first_trx_date` 或 `lastest_trx_date` 判断筛选结果。

## 13. 节点穿透最新决策

节点穿透以 `lx_fund_flow_subject_node.object_key` 为唯一标识，不按姓名穿透。

口径：

- 实名主体按原 SQL 逻辑生成 `object_key`，即 `md5(trim(idnocfno))`。
- 用户点击节点后，可选择“以此节点为中心查询”或“展开此节点”。
- 默认不自动穿透，避免图谱过长和误展开。
- 后端按被选节点的 `object_key` 查询其账户和流水。
- 节点是否可穿透由后端返回 `canExpand` 控制。

允许穿透：

- 有明确身份证号或证件号的实名主体。
- 有明确账户归属、能通过 `lx_fund_flow_own_account_edge` 找到账户的主体。

默认不穿透：

- 只有名称、没有证件号、没有明确账户归属的名称代理主体。
- 无法通过 `object_key` 准确定位账户集合的节点。

交互建议：

- 一期做“设为中心查询”，即点击节点后重新以该节点为中心画一跳图。
- 后续再做“在当前图上追加展开”，避免一期图谱状态管理过复杂。

## 14. 最终减法版决策

本节覆盖前文早期关于五张表、`lx_fund_flow_sum_edge`、关系图谱页签的旧设想。后续开发以本节为准。

本节为 2026-05-28 资金流图谱减法版决策，重点是不依赖 `lx_fund_flow_sum_edge`。关于关系图谱页签，后续已在第 16 节更新为“保留关系图谱能力”，以第 16 节为准。

必要表：

- `lx_fund_flow_subject_node`
- `lx_fund_flow_account_node`
- `lx_fund_flow_own_account_edge`
- `lx_fund_flow_detail_edge`

不依赖：

- `lx_fund_flow_sum_edge`

页面查询：

- 输入身份证号、姓名或点击节点 `object_key`。
- 后端定位主体点。
- 后端查询主体持有账户。
- 后端从 `lx_fund_flow_detail_edge` 按账户、`trx_date`、金额等条件实时聚合资金边。
- 前端只渲染后端返回的资金节点、资金边和逐笔明细。

家庭关系：

- 只作为资金流图谱中的标签展示。
- 家庭关系识别在图谱构建或数据加工阶段完成，并写入 `lx_fund_flow_detail_edge.family_relation_type`；后端查询接口只读取并返回该字段，不实时匹配家庭表。
- 如果生产构建需要按对手方户名匹配 `ccdi_staff_fmy_relation.relation_name`，应在构建 SQL 中完成，并控制同名误判风险。
- 有明确 `relation_cert_no` 的家庭关系人按实名主体处理，`object_key = md5(trim(relation_cert_no))`。
- 用户点击该节点时，可按该节点 `object_key` 设为中心继续查询。

测试数据：

- 测试 DDL 为 `sql/ccdi/graph/01_lx_fund_graph_mysql_ddl.sql`。
- 测试数据脚本为 `sql/ccdi/graph/02_lx_fund_graph_seed_test_data.sql`。
- 测试数据只写四张必要表。
- 测试数据来源于 dev 库 `ccdi_bank_statement` 和 `ccdi_staff_fmy_relation`。
- 原始流水表不被修改。

## 15. 前后端与页面交互设计

默认查询：

- 默认查询全部流水，不默认带交易日期过滤。
- 用户选择交易日期后，后端才按 `lx_fund_flow_detail_edge.trx_date` 过滤。
- 时间过滤不查汇总表，直接从明细边实时聚合。

后端接口建议：

```text
GET  /ccdi/project/fund-graph/search
GET  /ccdi/project/fund-graph/graph
GET  /ccdi/project/fund-graph/edge-detail
POST /ccdi/project/fund-graph/manual-edge

GET /ccdi/project/relation-graph/search
GET /ccdi/project/relation-graph/graph
GET /ccdi/project/relation-graph/suspected-enterprises
```

接口职责：

- `search`：按身份证号或姓名查主体点，返回候选主体列表。
- `graph`：按主体 `object_key` 查询一跳资金图，默认全部流水，可选日期、金额、方向过滤。
- `edge-detail`：点击资金边后，分页查询该边下的逐笔流水。

`graph` 入参：

```text
objectKey     必填，主体 object_key
startDate     可选，交易开始日期
endDate       可选，交易结束日期
amountMin     可选，最小金额
amountMax     可选，最大金额
direction     可选，1支出、2收入
limit         可选，默认20
```

`graph` 返回：

```text
centerNode    当前中心主体
nodes         图谱节点
edges         聚合后的资金边
summary       当前查询范围的总金额、总笔数、家庭关系边数量
```

节点字段：

```text
objectKey
nodeKey       idno_node/{object_key}
name
idNo
nodeType      PERSON / PROXY
canExpand
relationType  如果是家庭关系节点，返回配偶/父亲/母亲等
```

边字段：

```text
edgeKey
fromKey
toKey
fromName
toName
direction     1支出、2收入
amount
transactionCount
firstTrxDate
lastTrxDate
familyRelationType
```

`edge-detail` 入参：

```text
fromObjectKey
toObjectKey
direction
startDate
endDate
pageNum
pageSize
```

页面交互：

- 页面位置：项目详情“专项排查”页签。
- 页面标题：图谱展示。
- 展示“资金流图谱”和“关系图谱”两个页签。
- 搜索区只保留必要控件：身份证号/姓名、交易日期、查询、重置。
- 默认空态提示：请输入身份证号或姓名查询资金流图谱。
- 查询后画一跳图，中心节点为当前人员。
- 边上只显示金额和笔数，家庭关系用标签显示。
- 点击资金边，右侧抽屉展示逐笔流水。
- 点击节点，提供“设为中心查询”；默认不自动穿透。
- 只有 `canExpand = true` 的节点展示“设为中心查询”。

性能口径：

- 前端不聚合金额和笔数。
- 后端只围绕一个主体的账户集合查明细边。
- 默认全部流水也只查当前主体相关边，不扫全表。
- 必须使用 `lx_fund_flow_own_account_edge.from_key`、`lx_fund_flow_detail_edge.from_key/trx_date`、`lx_fund_flow_detail_edge.to_key/trx_date` 索引。
- 后端 SQL 参数比较需要显式 `COLLATE utf8mb4_general_ci`，避免当前库连接排序规则和表排序规则不一致。

当前 dev 测试数据：

```text
测试身份证号：617673198109148314
测试 object_key：以 `MD5('617673198109148314')` 为准
主体点：10
账户点：14
持有边：14
明细边：72
```

测试覆盖：

- 默认全部流水聚合。
- 日期范围筛选聚合。
- 支出方向 `flag = 1`。
- 收入方向 `flag = 2`。
- 家庭关系标签：配偶、父亲、母亲。
- 普通对手方：支付宝、淘宝、美团、财付通、小店、银行转账。
- 点击家庭关系节点按 `object_key` 设为中心查询。

## 16. 2026-05-29 最新验收口径

本节为当前最新口径，用于覆盖前文早期变更记录中的冲突描述。

当前图谱功能保留两类能力：

- 资金流图谱：作为专项排查中的核心图谱能力，读取 `lx_fund_flow_subject_node`、`lx_fund_flow_account_node`、`lx_fund_flow_own_account_edge`、`lx_fund_flow_detail_edge`，并叠加 `lx_fund_flow_manual_edge` 手工资金流向。
- 关系图谱：保留页面页签和接口能力，读取 `lx_rel_node`、`lx_rel_family_edge`、`lx_rel_stock_edge`、`lx_rel_represent_edge`，支持家庭关系、股东持股、法定代表人关系和疑似同名企业召回。

当前页面入口：

- 项目详情“专项排查”页签展示完整图谱工作台，包含“资金流图谱”和“关系图谱”两个页签。
- 项目分析弹窗“资金流向”页签展示简版资金流图谱。
- 项目分析弹窗“关系图谱”页签展示简版关系图谱。

当前接口入口：

```text
GET  /ccdi/project/fund-graph/search
GET  /ccdi/project/fund-graph/graph
GET  /ccdi/project/fund-graph/edge-detail
POST /ccdi/project/fund-graph/manual-edge

GET /ccdi/project/relation-graph/search
GET /ccdi/project/relation-graph/graph
GET /ccdi/project/relation-graph/suspected-enterprises
```

当前数据库执行口径：

- 新环境可参考 `sql/ccdi/graph/01_lx_fund_graph_mysql_ddl.sql` 和 `sql/ccdi/graph/03_lx_relation_graph_mysql_ddl.sql`。
- 已建资金流图谱表的环境使用 `sql/ccdi/graph/06_lx_fund_graph_existing_table_supplement.sql` 补字段和补索引，不删除、不重建、不清空基座数据。
- 已建关系图谱表的环境使用 `sql/ccdi/graph/03_lx_relation_graph_mysql_ddl.sql` 中的补充逻辑补字段和补索引。
- 生产 DDL 和补充 SQL 都由人工确认后手动执行，不随应用发布自动执行。

当前验收样例：

```text
资金流图谱测试身份证号：617673198109148314
关系图谱测试身份证号：330101198001010011
```
