把现有 SQL 表关系映射为知识图谱

向量搜索遇到需要沿多层关系推导的企业问题，是否就得采购图数据库、迁移业务数据？作者的回答是：先看看现有 SQL 库。主键、外键和关联表里，已经藏着一部分可用的实体与关系。

这篇短文提出的是一条改造路径：把数据库结构映射成语义图，再补上来源约束和答案引用。方向有参考价值，但原文没有展示完整实现或效果数据，不能把它当成经过充分验证的迁移方案。

SQL 表里已经有关系，为什么还要做映射

作者针对的是多跳问题：答案需要沿着几层关系才能找到，单靠文本相似度检索难以处理其中的业务逻辑。

他的判断是，团队不必一上来就请图数据库顾问、购买专用产品，再把事务表搬进 Neo4j 或 Neptune。现有数据库已经记录了不少关系：

• 主键可以帮助识别实体。
• 外键可以作为有方向关系的线索。
• 关联表可以承载实体之间的连接。

但表结构不会自动变成业务知识。例如，外键能说明两条记录存在关联，却未必说明这种关联在业务上叫什么、是否仍然有效。

已有 SQL schema 是构建语义图的起点，不是完成品。

作者建议增加一个自动映射层，把这些结构投影成实体和带类型的关系。原文没有明确这个投影是查询时生成，还是同步到另一个存储中，因此不能据此认定整个方案不需要额外的图存储。

从结构到可信答案，中间还缺哪些规则

作者给出的流程可以拆成四步：通过 information_schema 发现数据库结构，挑选高价值表映射为实体，把外键映射为带类型的关系，再为数据变化和答案补上约束。

这里有两个容易被忽略的选择。

首先，不是所有表都值得进入图。作者强调的是「高价值表」，而非整库机械转换。哪些表代表业务实体、哪些只是实现细节，仍需要业务判断。

其次，关系存在不等于关系可信。原文举出的约束是「职位变更需要来源」，并要求每个答案引用它依据的节点。前者约束数据如何进入图，后者让回答可以追溯。

作者还引用了 W3C 在 2012 年发布的 R2RML 标准，说明关系数据库到语义表示的映射已有历史基础。不过，有标准可参考，只能支撑这条技术路线并非新发明，不能证明当前团队的映射质量或问答效果。

Cypher 的坑在于：变化的属性不该决定边的身份

原文最具体的工程经验，是一个 MERGE 使用问题。

作者指出，如果把 role 属性写进关系的 MERGE 匹配条件，角色变化时可能产生重复边。因为原来的边不再符合新的属性条件，操作就可能创建另一条边。

他给出的模式是：先对不包含 role 等可变属性的边执行 MERGE，再通过 ON CREATE / ON MATCH SET 设置属性。

需要盯住的是：哪些字段定义关系的身份，哪些字段只是关系当前的状态。

这是作者明确转述的踩坑经验，但原文没有提供完整 Cypher 代码、数据库版本或复现过程。此外，如果业务需要保留角色变更历史，直接更新同一条边也未必合适，需要另行设计历史记录。

我的判断

这篇最有用的提醒，是在引入新基础设施之前，先盘点 SQL 库中已有的关系。对于结构清楚、外键维护较好的业务系统，这能帮助团队缩小建模范围。

它的前提也很明显：数据库结构必须足够接近真实业务。常见的软关联、跨系统身份、历史脏数据，都不能靠读取 schema 自动解决。原文提到完整文章还讨论了主数据管理（MDM）的限制，但这里没有展开，无法判断作者如何处理这些问题。

另外，关系查询不一定需要知识图谱，已有 SQL 联表也值得作为对照；向量搜索则仍可承担文本检索。该短文没有给出准确率、延迟、成本或方案对比数据，所以「优先利用现有 schema」是合理的工程建议，「这样做效果更好」仍需验证。

能拿来做什么

• 在 Node 服务对应的数据库里，先通过 information_schema 盘点实体表、外键和关联表，选一条真实业务关系链做最小验证。
• 给 AI 问答准备一组需要多跳关联的问题，对照现有 SQL 查询和拟建的图方案，记录答案是否正确、是否能追溯到依据。
• 如果使用 Cypher，检查 MERGE 是否把 role 等可变属性当成关系身份，并明确属性变化时应该更新状态还是保留历史。
• 为关系变更保留来源，并让回答引用依据节点；先把可追溯链路跑通，再扩大映射范围。