自动化数据库理解（Automated Database Understanding）· 用 AI/LLM/深度学习/血缘分析自动推断表的用途与关系
版本： v1.0 ｜ 日期： 2026-07-06 ｜ 状态： 已定稿
文档定位： 这是整个 AI Native 数据体系的第零层上游文档 。下游的《Schema-RAG-Patterns.md》（检索路由）、《Multi-Source-Ontology-Federation.md》（多源联邦）、《Ontology-Implementation-Patterns.md》（本体构建）都假设"表的用途与关系"已知；本文回答这个最前置的问题：面对一个几百表（分表上万）的数据库，怎么用元数据、数据、查询日志、血缘、深度学习、LLM 自动推断每张表干什么用、表与表什么关系？ PDM（PowerDesigner 物理数据模型）是多种输入源之一，作为先验融入，不是唯一焦点。
目录
- [§0 问题定义：自动理解一个"陌生"的大库](#§0 问题定义：自动理解一个"陌生"的大库)
- [§1 四类输入源及其可信度](#§1 四类输入源及其可信度)
- [§2 核心方法：四层叠加管线](#§2 核心方法：四层叠加管线)
- [§3 把 PDM 作为先验融入](#§3 把 PDM 作为先验融入)
- [§4 关系发现的深度：从显式到隐式到语义](#§4 关系发现的深度：从显式到隐式到语义)
- [§5 表用途推断：从命名到语义](#§5 表用途推断：从命名到语义)
- [§6 置信度与人工复核](#§6 置信度与人工复核)
- [§7 规模与工程化](#§7 规模与工程化)
- [§8 选型与分阶段推进](#§8 选型与分阶段推进)
- [§9 反模式](#§9 反模式)
- [§10 与已有文档的关系](#§10 与已有文档的关系)
- [§11 总结：三个判断](#§11 总结：三个判断)
- 参考资料
0. 问题定义：自动理解一个"陌生"的大库
企业数据团队常面对这样的场景：接手一个几百张表（加上分表实例上万）的生产库，要在短时间内搞清楚"每张表干什么用、表之间什么关系"。可能是新员工 onboard、可能是接手遗留系统、可能是为 AI/BI 建数据目录。靠人工逐表读 DDL、问老人、画 ER 图，几十张表还行，几百上千张就不可行。
自动化的目标： 给定一个数据库，自动产出一份带置信度的数据目录：每张表的用途描述、表间关系（PK-FK/语义关联/上下游）、业务域归类，每条结论标注多可信。
为什么"自动"难：四个根本障碍：
| 障碍 | 表现 | 后果 |
|---|---|---|
| 规模 | 几百表 + 分表上万 | 人工不可能，必须自动化 + 分层 |
| 异构 | 关系库 + API + 文档，结构形态不一 | 统一理解难 |
| 语义鸿沟 | ord_hdr_2024 这种命名看不出"订单头表" |
光靠元数据不够，需语义推理 |
| 约束缺失 | 高吞吐库为性能不建 DB 级 FK | 关系藏在数据/行为里，不在 schema 里 |
本文核心论点： 自动数据库理解不是单一技术，而是四类技术叠加的管线：元数据统计打基础、血缘分析给上下游、关系挖掘补隐式关联、LLM 补语义用途。PDM 等既有文档作为先验融入并校准，但不替代自动分析（因为先验可能过时）。下文展开。
1. 四类输入源及其可信度
自动理解能用什么"原料"？四类输入源，各自的可信度与提供的信息不同：
| 输入源 | 提供什么 | 可信度 | 限制 |
|---|---|---|---|
DB 元数据 （information_schema） |
表/列/类型/真实约束 | 最高（客观事实） | 只有结构，无语义；约束可能缺失（PDM-only） |
| 数据本身（采样） | 值域、分布、基数、枚举 | 高（客观） | 扫描贵、隐私敏感、大表需采样 |
| 查询日志/SQL/ETL | 实际怎么 JOIN/使用的 | 中高（行为真相） | 只覆盖被查过的；应用层逻辑看不到 |
| PDM/API 文档/既有目录 | 用途描述、声明的关系、业务域 | 中（可能过时） | 80-90% 准确，约束部分更不可靠 |
关键认知：没有单一源够用。 DB 元数据最客观但无语义；数据客观但贵；日志是行为真相但只覆盖被查的；PDM 有人工语义但可能过时。真实系统必须多源融合：这正是本文管线的核心。
PDM 在这里的定位： 它是"先验"（prior），提供人工写的用途与关系，能极大降低自动分析的难度（比从零推断强百倍）。但它不能当全真：那 10-20% 过时部分若不校准会污染下游。§3 专门讲怎么融入。
2. 核心方法：四层叠加管线
四类技术不是互斥，而是层层叠加，每层补上层的不足。先给总览，再逐层展开。
原始数据库(DDL + 数据 + 查询日志 + 可选 PDM)
│
▼ 第一层:元数据与统计(基础画像)--- 客观、全自动
│ 列画像、候选键、事实/维度分类
▼ 第二层:血缘分析(上下游)--- 客观、有工具
│ SQL/ETL 解析 → 表级+列级依赖图
▼ 第三层:关系挖掘(隐式关联)--- 半自动、需校验
│ IND 检测 + ML/DL FK 发现 + 列名语义
▼ 第四层:LLM 语义理解(用途)--- 半自动、人工兜底
│ DDL+样本+关系 → 用途描述、业务域、关系解释
▼
自动化数据目录(用途+关系,带置信度,可追溯)2.1 第一层：元数据与统计（基础画像）
这是所有分析的地基，客观且全自动。光看 DDL 和统计量就能回答很多。
能做什么：
- 列画像：每列的基数（唯一值数）、空值率、值域、类型、分布。本身暗示用途（唯一值数≈行数→候选主键；空值率高→可选字段）。
- 候选键发现：唯一性检测找候选主键。
- 事实/维度表分类：事实表多外键 + 度量值，维度表多描述字段。按列模式识别。
- 列聚类 ：把语义相同的列归到同一"属性"。ACM 的"Automatic discovery of attributes"是奠基工作 1；Azure Synapse 的 Auto Schema Discovery 是工业实现 2。
限制： 只看"形状"看不出"语义"。cust_id 和 customer_id 统计相似但元数据不知是同一概念。需第三/四层补。
2.2 第二层：血缘分析（上下游关系）
血缘回答"数据从哪来、到哪去"，是关系分析里最可靠的一类：从代码静态推导，不靠猜。
能做什么：
- 表级血缘：哪张表 JOIN/INSERT 哪张表，形成有向图。
- 列级血缘 ：某输出列由哪些输入列经什么变换（投影/聚合/拼接）而来。PuppyGraph 的说法很到位："表级血缘告诉你两个数据集相关；列级血缘告诉你改一个字段的实际爆炸半径 " 3。
工具栈（成熟）：
- DataHub ：用 SQLGlot 解析 SQL，自动提取列级血缘 4。区分转换列、透传列、重命名列（dbt Labs 定义）5。
- OpenLineage ：开放标准，从 Airflow/Spark/dbt 运行时采集 6。
- dbt：从项目 DAG 原生生成分血缘。
- Datafold/Monte Carlo/Acceldata ：商业工具，解析 SQL+Python 构建依赖图 7。
限制： 只发现显式写在代码里的关系。应用层 JOIN（代码里拼的）挖不到，需第三层补。
2.3 第三层：关系挖掘（隐式关联）
这是研究最活跃的领域：发现没有显式声明的关系（隐式外键、语义关联）。当 DB 没建 FK 约束（很多高吞吐生产库确实没有），这层是主力。
核心思路两步走：
- 包依赖检测（IND） ：找"列 A 的值都在列 B 出现"的候选对。Bauckmann 的高效 IND 检测是经典 8；条件 IND（CIND）区分"覆盖"与"完整"条件，能分离"关系存在但数据脏" vs "关系本身失效" 9。
- ML 分类 ：对每个 IND 候选用二分类判断是否真外键。Rostin 的经典 ML 方案 10；Jiang 的 Holistic PK/FK 同时检测两者利用互依赖 11；Zhang VLDB 处理复合外键 12。
深度学习的角色： Trummer (arXiv 2021) 直接问"深度神经网络能不能从列名预测数据相关性？ " 13。把 NLP 引入关系挖掘：光看列名（cust_id vs customer_id），用语言模型判断是否同源实体。这是列名语义 + 值域统计 + 数据类型的多模态判断，比纯 IND 准。
工业工具： Hackolade 纯从元数据推断 PK/FK 14；ChartDB 用 AI Agent 分析 schema 给外键建议 + 置信度 15。
限制： IND 检测大表上 O(n²) 列对比较，需采样；隐式外键有假阳性（值域碰巧包含），需 LLM 或人工复核。
2.4 第四层：LLM 语义理解（用途）
前三类回答"什么形状、从哪来、关联哪些"，但回答不了"这张表干什么用"。这是 LLM 的独占领域。
LLM 能做什么：
- 用途描述生成：喂"表名+列名+注释+几行样本"，生成"这是订单事实表，记录每笔交易头信息"。
- 业务域归类：分到销售/库存/客户域：直接对应 Schema RAG 文档 §3.2.1 的域分类。
- 关系语义解释：不只说"orders 和 customers 有 FK"，还说"orders.cust_id 指向客户主数据，每张订单属一个客户"。
- 歧义消解 ：
date列是创建还是更新日期？样本 + 列名 + 上下文让 LLM 判。
与前三类的协同： LLM 不是替代前三类，而是消费它们的结果。典型：血缘给 orders→customers 连接 → 关系挖掘确认 cust_id 是 FK → LLM 综合 DDL+样本+这些关系，生成完整用途描述。
前沿： 2024-2025 的 ReMatch（检索增强 schema 匹配）、RelationalAI Superalignment 都是 LLM + 检索做 schema 语义理解。Flatiron 的 DATA-VALID 框架给 LLM 抽取数据建立了分级验证方法 16；Palantir 的 LLM schema matching 是多源核对实践 17。
限制： LLM 会幻觉；样本数据可能含敏感信息（需脱敏）；跨表全局一致性难保证（需本体约束，见配套本体文档）。
3. 把 PDM 作为先验融入（不是替代自动分析）
PDM 是宝贵的先验：有人工写的用途、声明的关系、业务域归类。用好它能让自动分析事半功倍，但绝不能"全信"。
3.1 PDM 提供什么先验
- 用途描述：表/列的业务含义（最难得的语义信息）。
- 声明的关系：PK-FK 连线、关系基数（1:N/M:N）。
- 约束：CHECK、UNIQUE、NOT NULL。
- 业务域结构：PDM 通常按业务域组织表。
这些先验把自动分析的起点从"零"提升到"80-90% 完成"：剩下的 10-20% 是要校准的。
3.2 PDM 的可信度问题
PDM 不是全真，三类常见问题：
| 问题 | 表现 | 占比 |
|---|---|---|
| 模型过时 | PDM 停在旧版，库已加表/改列/删字段 | 最大（5-10%） |
| 关系错误 | FK 标错/漏标，尤其软外键没进 PDM | 次大（3-7%） |
| 语义过时 | 表用途已变（订单表加了退款行） | 小但隐蔽（2-3%） |
更棘手的：约束只在 PDM、不在 DB。 高吞吐库为性能故意不建 DB 级 FK/CHECK，只画在 PDM 里。这让普通 drift 检测（PDM vs information_schema）失效：DB 里压根没这条约束，diff 出"PDM 有 DB 没有"是预期的。这是配套文档《PDM-Constraint-Validation.md》专门处理的难题。
3.3 三源交叉验证 PDM
PDM 每条声明用三路独立证据验证，三路吻合则高置信，冲突则低置信进人工：
PDM 声明(如:orders.cust_id → customers.id 是外键)
│
├── 证据①:数据服从性(IND 包含检测)
│ cust_id 的值 98% 在 customers.id 里 → 支持
│ 只有 30% 包含 → 存疑
├── 证据②:血缘行为(SQL 实际怎么 JOIN)
│ 日志里频繁 JOIN → 支持;从没 JOIN → 存疑
└── 证据③:LLM 语义判断
列名/注释/样本支持同源 → 支持
│
▼ 投票 → 置信度分级
三路一致 → 高置信(自动采信)
两路一致 → 中置信(待审)
冲突 → 低置信(人工复核)为什么三路： 每路有盲区：数据碰巧包含会假阳性、血缘只看显式 SQL、LLM 会幻觉。三路独立投票，盲区互相覆盖。Palantir 的 schema matching with LLM 就是这种多源核对 17。
3.4 增量校准而非全量重建
不要因 PDM 有错就抛弃重算。正确做法是增量校准：保留 PDM 正确的 80-90%，只修正那 10-20%：
- 模型过时 → PDM vs DDL diff，全自动补齐（最高 ROI 的第一步）。
- 关系错误 → IND + ML 验证已标 FK、发现漏标 FK（见配套 PDM-Constraint-Validation 文档的 FK 校验工程化）。
- 语义过时 → LLM 重判核心表用途，与 PDM 比对。
PDM 的正确定位： 它是"高置信先验 + 待校准目标"的统一体。先用它打底（省去从零推断的成本），再用三源验证揪出过时部分。这个"先验 + 校准"思路比"无 PDM 从零推断"和"PDM 全信"都优。
4. 关系发现的深度：从显式到隐式到语义
表间关系不是单一概念，按发现深度分四层，可信度递减但覆盖递增：
| 层次 | 关系类型 | 怎么发现 | 可信度 | 覆盖 |
|---|---|---|---|---|
| 显式 | DB 约束声明的 FK | 读 information_schema |
最高 | 低（很多库没建） |
| 声明 | PDM/API 文档画的关系 | 解析 PDM | 中高（可能过时） | 中 |
| 隐式 | 数据包含（IND）/SQL JOIN 模式 | IND 检测 + 血缘 | 中（需校验） | 高 |
| 语义 | LLM 判定同源实体 | 列名/语义推理 | 中低（会幻觉） | 最高 |
关键洞察：层次越深，覆盖越广但可信度越低。 显式 FK 最可信但很多库没有；语义关系覆盖最广但需人工复核。生产系统四层叠加：先用高可信的显式/声明，不够再用隐式补，最后 LLM 兜底语义。
配套文档分工： 显式 + 声明层（含 PDM-only 约束校验）详见《PDM-Constraint-Validation.md》；隐式层（IND/ML FK 发现）是本文 §2.3；语义层是本文 §2.4。本文给全景，配套文档深化最难的子题。
5. 表用途推断：从命名到语义
表的用途推断与关系发现平行，也分多个信号层：
5.1 命名模式
- 事实表 ：名含
_fact/_hdr/_txn/_log，多外键 + 度量列。 - 维度表 ：名含
_dim/_master/_type，多描述性字段。 - 桥接表 ：名含
_map/_link/_xref，主要两列都是外键。 - 历史/日志表 ：名含
_history/_log/_audit，有 timestamp + 操作类型。
5.2 列模式
- 度量列：数值型（amount/count/price），用于聚合。
- 键列 ：
_id/_code/_no后缀，唯一或近唯一。 - 描述列：长文本（name/description/remark）。
- 时间列 ：
created_at/updated_at/timestamp。
5.3 样本数据推断
- 枚举值 ：
status列样本是{active,closed,pending}→ 状态枚举列。 - 分布：某列值高度集中（95% 是同一个值）→ 可能是默认值或低基数维度。
- 格式 ：
email/phone/uuid格式暗示列用途。
5.4 LLM 综合生成
把 5.1-5.3 的信号 + DDL + 样本喂 LLM，生成自然语言用途描述。这是各信号的"综合器"，能把"事实表 + 有 amount 列 + status 枚举"综合成"订单交易事实表，记录每笔订单的金额与状态"。
python
def infer_table_purpose(table, stats, samples, llm):
"""综合多信号让 LLM 生成用途描述。"""
signals = {
"ddl": table.ddl,
"naming": classify_naming(table.name), # 事实/维度/桥接
"column_patterns": analyze_columns(stats), # 度量/键/描述/时间
"sample_distinct_values": top_values(samples, n=10),
}
return llm.generate(
context=f"表 {table.name} 的信号:\n{signals}",
target="purpose_description", # 一句话用途 + 业务域归类
)工程要点： 样本要脱敏（尤其 PII）；LLM 输出要低温度 + 结构化；生成的用途描述与 PDM（若有）比对，冲突进待审。
6. 置信度与人工复核
每条自动产出的用途/关系都带置信度，这是"可信自动化"的关键。
6.1 置信度来源
- 显式 DB 约束 → 自动高置信。
- 三源一致 → 高置信。
- 单源或冲突 → 中低置信。
- LLM 生成 + 无其他证据 → 中低置信。
6.2 分级处置
| 置信度 | 处置 |
|---|---|
| 高 | 自动入目录 |
| 中 | 待审队列（批量人工 review） |
| 低 | 标记 + 不入主目录，或标"推测" |
6.3 标注回流（闭环）
人工复核的结果回流成训练/校准数据：LLM 判错的用途、ML 漏判的 FK，喂回模型持续提升。这是 DATA-VALID 框架的核心：验证不只是把关，也是反馈 16。
7. 规模与工程化
几百表 + 分表万上的规模，工程化是落地关键。
7.1 分表合并
订单表按月分 → order_202501... 上百张。归并到逻辑表 orders，目录只认逻辑表。物理分表通过元数据目录管理，查询时按时间范围只查相关分表（对应联邦文档 §5.1 的分表合并 + 跨度熔断）。
7.2 优先级与增量
- 优先级：按"价值 × 风险"排序，先分析 top 20% 高价值表（覆盖 80% 查询路径）。
- 增量：只处理自上次后变更的部分（DDL diff 触发、数据大变化触发）。
7.3 采样降成本
大表 IND/FK 检测全量是 O(n²)，必须采样：小样本（1%）快速筛查存疑关系，对存疑的大样本（10%）或全量复核。Kruse BTW 2015 讨论了 IND 检测的扩展 18。
7.4 持续监控
把用途/关系分析做成周期任务，定期复检 + 突变告警。这比一次性分析更能抓住漂移（对应本体文档附录 D 的演化与漂移检测）。
8. 选型与分阶段推进
8.1 决策树
先问:有没有 PDM/既有文档?
│
├─ 有 PDM(先验)
│ └─ 先 PDM vs DDL diff(全自动补过时) → 再三源校准关系 → LLM 补用途
│
└─ 无 PDM(从零)
│
├─ 规模?
│ ├─ 中小(几十到几百表) → 四层管线全跑
│ └─ 大(上千到万) → 优先级排序 + 采样 + 分表合并
│
└─ 有查询日志/ETL? ─ 是 → 血缘层优先(最可靠的关系来源)
└─ 否 → 元数据 + IND + LLM 起步8.2 分阶段路线图
| 阶段 | 做什么 | 置信度 | 产出 |
|---|---|---|---|
| 阶段 0 | 元数据 + 统计（若有 PDM，先 PDM vs DDL diff） | 最高（自动） | 基础画像 + 库的真实现网结构 |
| 阶段 1 | 血缘解析（SQL/ETL），建表/列级依赖图 | 高（自动） | 上下游关系，最可靠的关系层 |
| 阶段 2 | IND + ML 关系挖掘，验证/发现 FK | 中（采样+ML） | 隐式关系补全，中置信进待审 |
| 阶段 3 | LLM 重判核心表用途（top 20% 高价值表） | 中（人工兜底） | 语义用途层，覆盖核心域 |
| 阶段 4 | 长尾表 + 持续漂移监控 | 持续 | 全覆盖 + 自动发现新漂移 |
关键节奏： 阶段 0 立刻能做且全自动，先拿到"真实现网"打底。很多人卡在"PDM 不准不敢用"或"库太大无从下手"，其实第一步只需元数据 + DDL diff，投入产出比最高。
9. 反模式
反模式 1：把 PDM 当全真直接用
❌ PDM 全信，灌进目录/RAG 不校准。
后果： 10-20% 过时部分污染下游，多跳走错、用途描述错。
正确： PDM 是先验，每条过三源验证标置信度（§3）。
反模式 2：因 DB 没约束就放弃关系发现
❌ "information_schema 查不到 FK，这库没结构。"
后果： 错失隐式关系（IND/血缘/语义），退回手工。
正确： 没显式 FK 就用 IND/SQL JOIN/LLM 发现隐式关系（§2.3 + §4）。
反模式 3：只靠 LLM 做全部理解
❌ 把所有 DDL + 样本丢给 LLM，让它"自己理解"。
后果： 幻觉、跨表不一致、大库 token 爆炸、无客观校验。
正确： LLM 是第四层，消费前三层（元数据/血缘/关系）的结果做综合，不是替代（§2.4）。
反模式 4：全量深查不采样
❌ 几千列对所有列对跑全量 IND。
后果： 成本爆炸，周期不可行。
正确： 分层采样 + 优先级排序 + 增量校验（§7）。
反模式 5：一次性分析不持续
❌ 做过一次理解，以后不管。
后果： 持续漂移，老结果过时。
正确： 周期性复检 + 突变告警，把理解做成持续数据质量任务（§7.4）。
10. 与已有文档的关系
| 已有文档 | 本文关系 |
|---|---|
| 《Schema-RAG-Patterns.md》 | 本文是其 Schema Catalog 的自动构建层------catalog 的用途/关系字段来自本文管线。无本文则 catalog 靠手写 |
| 《Multi-Source-Ontology-Federation.md》 | 本文是其数据契约（DPROD）的发现基础------契约的 schema/关系可从本文管线产出 |
| 《Ontology-Implementation-Patterns.md》 | 本文是其模式 F（隐式本体）的自动化采集------把"DBA 手写 columns_hint"升级为"管线自动生成 + 校准" |
| 《PDM-Constraint-Validation.md》 | 本文 §3/§4 的深化子专题------专门处理 PDM-only 约束（只在模型不在 DB）的校验 |
不重复： 本文不重述 PDM-only 约束的工程细节（见配套 PDM 文档）、不重述 schema 向量化的检索侧（见 Schema RAG）。新内容： 四层叠加管线、四类输入源可信度、PDM 先验融入、关系发现四层深度、表用途推断信号层、置信度与闭环。
11. 总结：三个判断
判断 1：自动数据库理解是四类技术叠加，不是单一银弹
元数据统计、血缘分析、关系挖掘、LLM 语义，四类各有盲区，叠加才完整。任何单一技术（无论多强的 LLM）都不够：LLM 没有客观校验会幻觉，IND 没语义看不出用途，血缘只覆盖显式 SQL。管线思维是关键：每层补上层不足，最后产出带置信度的目录。
判断 2：PDM 是先验不是真理，融入而非依赖
有 PDM 是幸运（省去从零推断），但 80-90% 准确度意味着 10-20% 会毒。正确做法是"先验打底 + 三源校准"：用 PDM 的正确部分，用数据/血缘/LLM 揪出过时部分。无 PDM 也能做（四层管线从元数据起步），只是更费力。
判断 3：置信度分级是可信自动化的命门
自动化必然有错。差别在于：无置信度的自动化会把错当对，默默污染下游；带置信度的自动化把"确定的自动入目录、存疑的进待审、人复核后回流"。置信度让自动化从"全或无"变成"分级渐进"，这是企业可接受自动化的前提。
最后的话： 几百表的大库看起来吓人，但只要认清"四类技术叠加 + 多源融合 + 置信度分级"，就能把人工不可及的规模变成自动化可处理的问题。PDM 等既有文档是加速器不是依赖，LLM 是综合器不是银弹。本文的四层管线 + 分阶段推进，是这条路线的决策与实施框架，产出的目录直接喂给下游的 Schema RAG、联邦、本体，构成完整的 AI Native 数据理解体系。