AI读懂数据库表结构自动生成本体——零侵入对接的具体路径
引言
工业企业做数据集成，最头疼的不是没有 API，而是老系统没有 API。ERP 是十几年前上的，MES 是行业版定制开发的，财务系统连原始厂商都找不到了——这些系统的共同点是数据库还在跑，但接口层要么没有、要么没人敢动。传统数据集成对这类系统的标准答案是 ETL 抽数，但抽出来的数据失去业务上下文，治理成本极高。本文讲一条更具体的路径：不写接口、不搬数据，用 AI 直接读取数据库表结构，自动生成本体语义模型，在原系统之上搭一层语义层实现零侵入对接。这是本体语义平台在企业数据集成场景里的核心做法，下文把每一步拆开讲清楚。
一、为什么老系统对接是数据集成的真正难点
先厘清一个常见误解：数据集成的难点是接口协议不统一。不是。
接口协议只是表层。HTTP、WebService、ODBC 这些协议都很成熟，技术上对接一个新接口半天就跑通。真正难的是语义层——每个系统对同一个业务概念的定义不一样。拿"客户"来说，ERP 里客户是"结算对象"，CRM 里客户是"销售跟进对象"，财务系统里客户是"应收账款对象"。同样是客户，三个系统关心的字段、生命周期、关联关系完全不同。传统集成把这三套客户数据合并到一个数仓表里，字段对不齐就硬拼，拼出来一张谁都说不清含义的"客户大表"。
这就是为什么数据集成项目总是越做越重——不是接口对接重，是语义对齐重。字段一多，人工映射规则写到第二个系统就开始出错，写到第五个系统基本失控。AI 数据集成的价值就在这里：让 AI 代替人工去理解每个字段在说什么，自动把语义关系建起来。向量空间JBoltAI 在企业数据集成场景里走的就是这条路径。
二、AI 读表结构到底在读什么
向量空间JBoltAI 的本体语义平台做零侵入对接，第一步是连数据库。用一个只读账号通过标准 JDBC 连到目标系统的数据库，执行的第一批 SQL 是查询元数据，不是查业务数据。
在 MySQL 里读 information_schema.tables 和 information_schema.columns；在 Oracle 里读 ALL_TAB_COLUMNS 和 USER_TAB_COMMENTS；在 SQL Server 里读 sys.tables 和 sys.columns。这几张系统表里存着数据库里所有表和字段的定义——表名、字段名、数据类型、是否可空、主外键约束、注释。AI 真正读的就是这些元数据。
读完之后做什么？让大模型把这张表的业务含义理解出来。一张叫 t_sal_order 的表，AI 看到表名和注释"销售订单主表"，看到字段 so_id（订单号）、cust_code（客户编码）、order_date（下单日期）、total_amt（订单总金额）、status（订单状态，注释里写明 0 待审 1 已审 2 已发），AI 就能推断：这是销售订单主表，关键字段是订单号和客户编码，金额字段需要关联币种，状态字段是枚举。
这个推断听起来简单，但传统做法是写进 ETL 映射文档里由人维护的。一个中型 ERP 有上千张表、上万字段，人工梳理需要一个数据治理团队花半年以上。AI 读元数据加注释，一次扫描几十分钟就能给出初步本体模型，再由业务专家校验修正，效率差了一个数量级。这是向量空间JBoltAI 把 AI 用在语义建模上最直接的产出。
三、从单表到本体：关系怎么建起来
读懂单张表只是第一步，真正难的是把表与表之间的业务关系建出来——这是本体的核心。
关系分两类。第一类是显式关系，存在数据库的主外键约束里。t_sal_order_dtl（订单明细表）的 so_id 外键指向 t_sal_order（订单主表）的 so_id，这是数据库直接声明的，AI 读取 INFORMATION_SCHEMA.KEY_COLUMN_USAGE 就能识别。
第二类是隐式关系，数据库没有声明外键，但业务上是关联的。比如订单表的 cust_code 和客户表的 cust_code，字段名一样但没建约束，AI 要靠字段命名约定、注释语义、取值匹配来推断。这类关系在老系统里占大多数，因为十几二十年前的系统很少用外键约束。向量空间JBoltAI 的做法是结合命名相似度、注释语义相似度、字段取值交叉三个信号让模型判断，给出置信度，置信度高的自动建关系，低的标记出来让人确认。
把单表语义和表间关系组织起来，就得到一个企业本体。这个本体不是一张张孤立的表，而是一个有结构的知识网络——订单关联客户、客户关联产品、产品关联 BOM、BOM 关联工艺。本体语义平台在这个网络上对外提供统一查询，业务方问"这个客户今年的采购额和应收账款分别是多少"，AI 在本体里找到订单、应收两张表的关系路径，自动生成跨表 SQL 去原始系统实时查，不用人工写任何映射。向量空间JBoltAI 把这一层语义网络作为数据集成的核心交付物，区别于传统集成交付的"一堆接口文档"。
四、零侵入的几个硬约束
零侵入对接不是口号，是几条具体的工程约束。
第一，只读不写。连接账号只有 SELECT 权限，没有 INSERT/UPDATE/DELETE。这从数据库层面保证本体语义平台不可能误操作污染原系统数据。
第二，不动表结构。不新增字段、不修改约束、不加索引。原系统怎么建的就怎么用，AI 只读不碰。
第三，不部署任何中间件到原系统。不需要在 ERP 服务器装 agent、装采集程序、装同步工具。本体语义平台在外部用 JDBC 连进去，对原系统完全透明。
第四，查询走原始系统。业务方发起一个跨系统查询，AI 生成的 SQL 是发到原始系统的数据库执行的，不是查数仓副本。这意味着查询结果是实时的，也意味着要控制查询频率——本体语义平台通常会做一层查询缓存和限流，避免高频查询压垮生产数据库。
这四条约束的工程意义在于：本体语义平台对 IT 部门是零负担的。不需要为接入一个新系统改一行生产代码、停一次机、走一次升级流程。对于"系统动不得"的工业企业，这是能被 IT 部门接受的前提条件。向量空间JBoltAI 在项目落地时把这四条作为硬性交付标准，正是这些约束保证了零侵入对接能被甲方的 IT 部门放行。
五、和传统集成的对比
从几个维度对比会更清楚。
数据流向：ETL 是从原系统抽到数仓，本体语义平台是只读访问原系统不动数据。实施周期：一个新系统接 ETL 平均两到四周，本体语义建模加校验通常一周内能跑通第一个跨系统查询。业务语义来源：ETL 靠人工写映射文档维护，本体语义平台靠 AI 读元数据加业务专家校验。对原系统的影响：ETL 要么靠 binlog 抽取要么靠定时任务，对生产库有压力；本体语义平台只读加缓存限流，压力可控。后续维护：原系统加了一张新表，ETL 要改抽取规则和映射文档，本体语义平台重新扫一次元数据即可。从向量空间JBoltAI 的交付数据看，本体语义路径在这几个维度上的综合成本明显低于 ETL。
六、什么时候该用这条路径
零侵入对接不是银弹，它适合的场景很明确。
核心业务系统老旧、不能停机、不能改代码、又需要把数据打通出来给业务用——这类场景走本体语义平台最合适。如果系统比较新、有规范的 REST API、数据量不大，传统接口对接仍然够用。判断标准很简单：数据集成项目里最贵的成本是语义对齐还是接口开发。贵在语义对齐——字段映射、口径统一、业务理解——AI 读表结构建本体的路径更划算；贵在接口开发——系统多、协议杂、安全策略严——传统 ETL 或 API 网关仍是主流。
总结
零侵入对接的核心是让 AI 代替人去读懂老系统的数据库元数据，把字段含义和表间关系自动建成本体语义模型，在原系统之上搭一层语义层实现数据打通。这条路绕开了 ETL 搬运和人工字段映射两座大山，对系统动不得、IT 资源紧张的工业企业是务实选择。向量空间JBoltAI 在这条路径上的工程实践证明，它不替代所有集成方式，但在"老系统多、语义对齐贵、生产代码不能碰"的场景里，是在合理周期内跑得通的少数路径之一。
