自动化数据库理解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 自动推断每张表干什么用、表与表什么关系PDMPowerDesigner 物理数据模型是多种输入源之一作为先验融入不是唯一焦点。目录§0 问题定义自动理解一个陌生的大库§1 四类输入源及其可信度§2 核心方法四层叠加管线§3 把 PDM 作为先验融入§4 关系发现的深度从显式到隐式到语义§5 表用途推断从命名到语义§6 置信度与人工复核§7 规模与工程化§8 选型与分阶段推进§9 反模式§10 与已有文档的关系§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商业工具解析 SQLPython 构建依赖图 [7]。限制只发现显式写在代码里的关系。应用层 JOIN代码里拼的挖不到需第三层补。2.3 第三层关系挖掘隐式关联这是研究最活跃的领域发现没有显式声明的关系隐式外键、语义关联。当 DB 没建 FK 约束很多高吞吐生产库确实没有这层是主力。核心思路两步走包依赖检测IND找列 A 的值都在列 B 出现的候选对。Bauckmann 的高效 IND 检测是经典 [8]条件 INDCIND区分覆盖与完整条件能分离关系存在但数据脏 vs “关系本身失效” [9]。ML 分类对每个 IND 候选用二分类判断是否真外键。Rostin 的经典 ML 方案 [10]Jiang 的 Holistic PK/FK 同时检测两者利用互依赖 [11]Zhang VLDB 处理复合外键 [12]。深度学习的角色Trummer (arXiv 2021) 直接问深度神经网络能不能从列名预测数据相关性 [13]。把 NLP 引入关系挖掘光看列名cust_idvscustomer_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 vsinformation_schema失效DB 里压根没这条约束diff 出PDM 有 DB 没有是预期的。这是配套文档《PDM-Constraint-Validation.md》专门处理的难题。3.3 三源交叉验证 PDMPDM 每条声明用三路独立证据验证三路吻合则高置信冲突则低置信进人工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 枚举综合成订单交易事实表记录每笔订单的金额与状态。definfer_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,n10),}returnllm.generate(contextf表{table.name}的信号:\n{signals},targetpurpose_description,# 一句话用途 业务域归类)工程要点样本要脱敏尤其 PIILLM 输出要低温度 结构化生成的用途描述与 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建表/列级依赖图高自动上下游关系最可靠的关系层阶段 2IND ML 关系挖掘验证/发现 FK中采样ML隐式关系补全中置信进待审阶段 3LLM 重判核心表用途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。管线思维是关键每层补上层不足最后产出带置信度的目录。判断 2PDM 是先验不是真理融入而非依赖有 PDM 是幸运省去从零推断但 80-90% 准确度意味着 10-20% 会毒。正确做法是先验打底 三源校准用 PDM 的正确部分用数据/血缘/LLM 揪出过时部分。无 PDM 也能做四层管线从元数据起步只是更费力。判断 3置信度分级是可信自动化的命门自动化必然有错。差别在于无置信度的自动化会把错当对默默污染下游带置信度的自动化把确定的自动入目录、存疑的进待审、人复核后回流。置信度让自动化从全或无变成分级渐进这是企业可接受自动化的前提。最后的话几百表的大库看起来吓人但只要认清四类技术叠加 多源融合 置信度分级就能把人工不可及的规模变成自动化可处理的问题。PDM 等既有文档是加速器不是依赖LLM 是综合器不是银弹。本文的四层管线 分阶段推进是这条路线的决策与实施框架产出的目录直接喂给下游的 Schema RAG、联邦、本体构成完整的 AI Native 数据理解体系。参考资料编号来源主题链接[1]ACM DLAutomatic Discovery of Attributes in Relational Databases列聚类https://dl.acm.org/doi/10.1145/1989323.1989336[2]Microsoft Azure SynapseIntroducing Automatic Schema Discoveryhttps://techcommunity.microsoft.com/blog/azuresynapseanalyticsblog/introducing-automatic-schema-discovery-with-auto-table-creation-for-complex-data/3068927[3]PuppyGraph7 Best Automated Data Lineage Tools列级血缘爆炸半径https://puppygraph.com/learn/automated-data-lineage-tools[4]DataHubExtracting Column-Level Lineage from SQLSQLGlot 解析https://datahub.com/blog/extracting-column-level-lineage-from-sql/[5]dbt LabsUnderstanding Data Lineage转换/透传/重命名列https://www.getdbt.com/discover/understanding-data-lineage[6]Monte CarloThe Ultimate Guide to Data Lineagehttps://montecarlo.ai/blog-data-lineage[7]DBMS Tools22 Best SQL Lineage Toolshttps://dbmstools.com/categories/sql-lineage-tools[8]HPI (Bauckmann)Efficiently Detecting Inclusion Dependencieshttps://hpi.de/fileadmin/user_upload/fachgebiete/naumann/publications/PDFs/2007_bauckmann_efficiently.pdf[9]ICDE (Bauckmann 2012)Discovering Conditional Inclusion Dependencies覆盖 vs 完整https://dl.acm.org/doi/10.1145/2396761.2398580[10]ResearchGate (Rostin)A Machine Learning Approach to Foreign Key Discoveryhttps://www.researchgate.net/publication/221035501_A_Machine_Learning_Approach_to_Foreign_Key_Discovery[11]HPI (Jiang 2019)Holistic Primary Key and Foreign Key Detectionhttps://hpi.de/oldsite/fileadmin/user_upload/fachgebiete/naumann/publications/PDFs/2020_jiang_holistic.pdf[12]VLDB (Zhang 2010)On Multi-Column Foreign Key Discoveryhttps://vldb.org/pvdb/vol3/R72.pdf[13]arXiv (Trummer 2021)Can Deep Neural Networks Predict Data Correlations from Column Names?https://arxiv.org/pdf/2107.04553[14]HackoladeInfer Primary Keys and Foreign Key Relationshipshttps://hackolade.com/help/InferPrimaryKeysandForeignKeyRel.html[15]ChartDBAI Foreign Key Detectionhttps://chartdb.io/blog/foreign-keys-in-databases-importance-and-ai-detection[16]Flatiron HealthDATA-VALID FrameworkLLM 抽取数据验证方法论https://resources.flatiron.com/publications/ensuring-reliability-of-curated-ehr-derived-data-the-validation-of-accuracy-for-llm/ml-extracted-information-and-data-valid-framework[17]Palantir BuildSchema Matching and Data Validation Using LLMshttps://build.palantir.com/platform/ee5c0f4d-8c21-4987-be51-612973a03c99[18]BTW (Kruse 2015)Scaling Out the Discovery of Inclusion Dependencieshttps://btw-2015.informatik.uni-hamburg.de/res/proceedings/Hauptband/Wiss/Kruse-Scaling_Out_the_Discovery_of.pdf