父子结构

在 XpertAI 平台中，为了更灵活地表示组织、人员、分类等具有自引用关系的业务结构，支持使用 父子层级结构（Parent-Child Hierarchy）进行建模。这种结构与传统的多层级维度不同，它不需要预定义固定的层级数量，而是通过一张自关联的数据表，动态构建出任意深度的层级关系。

🎯 功能说明

父子层级结构只包含一个逻辑层级，但每个成员都可以指定其“父成员”，从而形成一棵动态生成的树状结构。这种结构特别适用于以下典型业务场景：

组织架构：每位员工可能有一个直接上级（主管），而主管本身也是员工，形成上下级关系；
产品分类：某些子分类可以不断嵌套在其他分类下，层级深度不固定；
地理区域：行政区域可能以“国家 > 州 > 市 > 区”等多层结构嵌套，但有些路径层级更深或更浅；
菜单结构或知识树：用于导航、文档分类等。

🔑 关键要素

在构建父子层级结构时，需配置以下几个关键字段：

字段	说明
成员标识（ID）	唯一标识每个成员，用于建立父子关系。
父成员标识（Parent ID）	指定当前成员的上级是谁，通常引用同一张表中的其他成员。
空父节点值	如果某个成员没有上级（如组织顶层、根分类），可用特定值标识其为顶层节点，例如 `0`、`-1` 或空字符串等。
闭包表（可选）	预先计算并存储所有“祖先-后代”对的表，用于提升多层级查询的性能，尤其在大数据量下尤为有效。

父成员字段

该字段用于指定每个成员的“父级成员编号”，是建立上下级关系的关键字段。

作用：定义当前成员的直接上级是谁。
要求：通常为维度主键的外键，自引用同一张数据表。
数据类型：需与成员主键一致（例如都是整数或字符串）。
典型用途：组织架构中的“主管ID”、分类中的“上级分类ID”。

📌 示例

员工表中：employee_id = 1002，supervisor_id = 1001 表示员工 1002 的直接上级是员工 1001。

顶层节点标识值

用于指定“没有上级”的成员应使用的特殊值，系统将此类成员视为树的根节点或顶层节点。

作用：识别哪些成员没有上级，是整棵层级结构的起点。
常见取值：
- null（空值）
- 0
- -1
- 空字符串 ''
建议：应保持一致性，并根据实际数据库情况选择可索引的值（如避免使用 null 造成索引失效）。

📌 示例

若某条记录的 parent_id = 0，表示该成员没有上级，是顶层节点。

自定义父级表达式

用于在父子层级中以自定义逻辑定义父子关系，替代直接引用某列。

作用：提供更灵活的方式处理特殊的父子逻辑；
适用场景：
- 父级关系依赖多个字段组合判断；
- 需要在父子映射中做字段转换、格式处理或条件过滤；
表达方式：通常为 SQL 表达式或平台支持的计算字段逻辑。

📌 示例场景

如果父子关系由 CONCAT(region_code, '-', parent_id) 构成，可使用表达式：CONCAT(region_code, '-', parent_id) 来识别父成员。

🔒 注意：使用 自定义父级表达式 时，请确保逻辑正确且具备良好的可读性，否则可能影响层级正确性或性能。

闭包表

在父子层级结构中，若层级较深或成员数量较多，系统在进行聚合计算（如薪资总和、子节点计数）时，性能可能会受到影响。为解决这一问题，建议为父子结构配置闭包表（Closure Table），以显著提升分析性能。

闭包表是一张额外的数据表，记录了所有成员与其祖先之间的关系，无论其距离为多少层。

简单来说，原始数据中只记录了“直属上级”，而闭包表中则补充了“所有祖先”关系，形成完整的树状路径。

🛠 闭包表结构设计

一个典型的闭包表通常包含以下字段：

字段名	描述
ancestor_id	上级成员 ID
descendant_id	当前成员 ID
distance	上下级之间的层级距离（可选）

📌 示例：

ancestor_id	descendant_id	distance
1	1	0
1	2	1
1	3	2
2	3	1
3	5	1

表示：成员 1 是成员 3 的祖先，距离为 2；成员 2 是成员 3 的直接上级，距离为 1。

🧩 配置建议

保持字段一致性 闭包表中的成员 ID 字段应与维度表保持类型一致（如均为整数或字符串）。
设置主键与索引 建议为 (ancestor_id, descendant_id) 建立唯一索引，提升关联性能。
同步更新机制 闭包表需在每次成员结构更新（如新增/删除关系）后同步更新。此过程可通过数据库脚本、ETL 工具等自动化实现。

🔄 闭包表的更新方式

平台不会自动维护闭包表，建议在数据加载过程中使用以下方法之一：

ETL 工具生成闭包表（如：Kettle / DataStage / Airbyte 等）；
数据库中构建递归存储过程，用于批量生成祖先-后代关系；
持续增量更新逻辑：针对新增成员，仅补充新增路径。

📌 示例：MySQL 中的闭包构建逻辑（伪代码）

-- 初始插入所有成员自身
INSERT INTO closure (ancestor_id, descendant_id, distance)
SELECT id, id, 0 FROM employee;

-- 递归插入祖先-后代关系
WHILE(存在新的子节点) {
  INSERT INTO closure (...)
  SELECT ...
}

🧠 为什么使用父子层级？

与传统固定层级结构相比，父子层级具有以下优势：

✅ 支持不规则层级：每条路径的深度可以不同，灵活适配实际业务；
✅ 易于维护：只需管理一张自关联的表，不必定义多个层级字段；
✅ 结构直观：通过父子关系即可推导出完整的层级树；
✅ 更少冗余：避免为不必要的层级留空，提高数据清晰度。

🚀 应用示例

员工结构图
- 每位员工记录中包含其“主管员工编号”；
- 顶层管理者（如 CEO）无上级，其父字段为 0；
- 构建的树状图可以用于权限控制、组织报表等分析。
动态菜单
- 每个菜单项可设置上级菜单；
- 无需预设固定的“一级、二级、三级”字段；
- 更适合构建支持任意深度嵌套的系统导航结构。
产品多级分类
- 某些分类路径可能为“家电 > 厨房电器 > 榨汁机”，有些仅为“家电 > 空调”；
- 父子层级可自动适配这种不规则路径。

⚙ 性能优化建议

对于层级较深或数据量大的场景，推荐启用 闭包表（Closure Table）方式，将所有祖先-后代关系预先计算，能极大提升分析速度；
确保成员标识和父成员标识字段建立索引，以优化查询效率；
顶层节点应使用统一的标识值（如 0 或 -1）避免遗漏。

🎯 功能说明​

🔑 关键要素​

父成员字段​

顶层节点标识值​

自定义父级表达式​

闭包表​

🛠 闭包表结构设计​

🧩 配置建议​

🔄 闭包表的更新方式​

🧠 为什么使用父子层级？​

🚀 应用示例​

⚙ 性能优化建议​