从只读数据库到语义层：一次可复核的解析过程

一个可用于分析的语义层，至少要说明四件事：有哪些业务对象、每个对象一行代表什么、对象之间按什么字段关联、每个指标怎么算。数据库本身只直接提供其中一部分。表名和字段名提供线索，数据类型限定取值范围，主键和外键则是判断记录粒度与关联路径的直接依据。

因此结构事实的完整性，决定了语义层能不能从一个可靠的起点开始。这里有一个容易被忽略的细节：产品建议用只读账号接入生产库，而 PostgreSQL 的 information_schema 约束视图按权限过滤——一个只有 SELECT 权限的账号在其中读不到任何主键与唯一约束，外键却仍可从系统目录读到。若解析程序从前者取约束，真实部署下拿到的主键会长期为空，而开发环境用属主账号连接时一切正常。

这类差异不会报错，只会让语义层缺少判断粒度的依据，进而由模型自行推断。改用系统目录读取约束后，同一个只读账号可以完整取到主键与唯一约束，其中包含由三个字段构成的复合主键——这正是判断“一行代表什么”的关键证据。

解析过程按三层组织，各自回答不同的问题。第一层是接入与授权：连接凭据保存在本地设备，不上传云端；每次问数由云端签发一份限定范围的只读授权，写明本轮可访问的关系清单、行数与字节上限、有效期，并绑定当前会话。授权到期后需要重新确认，界面会在发送前拦下并说明原因。

第二层是结构映射与版本管理。扫描只读取数据库目录，不读取样本行；结果整理为一份结构快照，包含每张关系的字段、类型、注释、主键、唯一约束和经过范围过滤的外键，并计算内容哈希后发布为一个版本。重新扫描时按上一版本做条件更新，因此并发或重复操作不会覆盖已发布的结果。

第三层是取数与沉淀。模型不编写 SQL，而是填写一份结构化查询：关系名、字段、聚合方式、筛选条件、分组与排序都是受约束的字段，由端侧编译为参数化语句并在本机执行。语义层本身是一份可读文件，包含业务对象、关系、指标、代码值与业务术语，每一条都标注证据来源与确认状态；人工确认过的条目不会被后续运行改写。

下面是一次完整运行的记录，环境为演示数据库，共 9 张表、1303 行示例数据，接入账号仅有查询权限。第一步是接入：填写主机、库名、Schema 与只读账号，先做连接校验，再保存到本地设备。密码与物理连接详情不会离开这台设备。

第二步是结构扫描。扫描完成后可以逐张查看识别出的关系及其字段数、行数估算与占用空间。这一步只读取数据库目录，界面上标注的行数来自统计信息估算，不是逐行统计的结果。

第三步是授权。点击开始问数后，界面给出本轮授权的范围与上限，并说明仅查询、不修改数据；确认后才可发送。第四步是建立语义并取数：按结构事实整理业务对象与指标，用真实数据核对每一条口径，再以结构化查询取回分组结果。

第五步是核对。返回的四个责任单位的报验合格率，与直接对同一张表执行分组聚合得到的结果逐行一致，其中一个班组的合格率低于其余三个。第六步是沉淀：语义层文件写入资料库，状态为待审核，等待业务人员确认后再作为后续问数的复用依据。

当前的语义层解决的是单张关系上的口径一致问题。工业场景的多数问题需要跨表回答——从销售订单追到生产任务，再追到质量检验记录。因此下一步是受控关联：只允许沿已发布的外键与唯一约束连接，关联路径由结构版本决定，而不是由模型临时判断。主键与唯一约束能被完整读到，是这一步的前提。

第二步是命名指标。把合格率、按期完成率这类口径写进语义层并在查询时解析，可以避免每次分析各自重算。第三步是按语义层收窄授权范围：目前一次授权包含全部已扫描关系，按业务对象收窄后，授权范围会更贴近实际问题。

再往后是本体层。语义层描述的是一个数据源内部的对象与口径；本体层需要跨数据源描述同一业务实体，说明同一台设备在生产系统、质量系统和运维系统中的对应关系，以及这些关系随时间的变化。这一步的难点不在查询构造，而在如何让跨系统的实体对应关系被确认、被记录、并在源系统变化时保持有效。

需要说明当前的边界：语义层已经可以在演示环境中完整跑通并复核，但尚未在多个生产环境中长期运行；跨表关联、命名指标与本体层均在规划中。产品能力的推进以可核对的运行记录为准，而不是以功能清单为准。