食味里公司准备让AI回答一个看起来并不复杂的问题“川香鸡腿饭套餐在华南哪些门店可以卖如果12公斤装鸡腿肉停用会影响哪些商品”数字化部门把几套系统的表结构交给AI。POS里有商品表ERP里有产品表和物料表SRM里有供应商商品表WMS里还有库存商品表。每张表都有编码、名称、状态看起来只要把四张“产品表”连起来答案就应该出来。结果AI先把套餐、菜品、鸡腿肉和供应商包装都归成了“产品”又把WMS中库存为零解释成“商品已停用”。当团队追问“停售的是门店销售对象还是暂时没有可分配库存”时它答不上来了。问题不一定是字段缺失而是团队把数据模型当成了业务世界本身。数据模型记录业务在某个系统、某种处理目标下需要怎样存储和关联业务本体描述跨系统、跨流程仍然成立的对象、关系、状态、规则和行动含义。前者是投影后者是投影背后需要共享的语义。两者紧密相关却不能直接画等号。一、四张“产品表”其实在记录四种不同视角先看食味里新品上线后可能出现的四组记录。系统视角表中可能出现的记录系统为什么要记录它POS商品表川香鸡腿饭、川香双拼套餐、销售价、售卖状态点单、定价、促销和门店可售配置ERP产品/物料表菜品编码、配方引用、鸡腿肉12kg箱、库存基本单位计划、采购、成本和主数据管理SRM供应商商品表鲜达食品A—去骨鸡腿肉2kg×6、报价、MOQ、交期询报价、合同和供应关系管理WMS库存商品表MAT-CHKN-012、批次、仓库、待检/可用数量、效期入库、批次库存、分配和出库控制四张表可能都使用PRODUCT_ID、ITEM_CODE或“商品编码”但同名并不代表同义。POS的“商品”是顾客可选择的销售对象ERP中的“产品”可能混合菜品、饮料和套餐配置SRM中的“商品”是某供应商以特定包装和合同条件提供的供应商SKUWMS中的“商品”更接近可被收货、储存和分配的物料身份及库存记录。反过来同一个业务概念也可能分散在多张表。门店是否可以销售“川香鸡腿饭”不能只看POS商品状态还要看产品是否在总部启用、该门店是否建立可售关系、有效配方是否存在、关键物料是否有合格来源和可分配库存。业务上的一个判断被拆散在商品、门店范围、配方、供应商物料、批次库存和状态代码中。所以表不是对象清单字段也不是概念清单。表结构首先是某个应用解决自身问题的设计结果。二、一张表可以混合多个概念一个概念也可以散落多表数据库设计为了查询、性能、事务和开发便利经常会做两件事。第一件事是把多个业务概念压进一张表。例如POS商品表可能同时有ITEM_TYPE、RECIPE_ID、PRICE、STORE_SCOPE和SALE_STATUS。这些字段背后至少涉及销售商品、菜品、配方版本、价格、门店可售关系和状态。若AI按“一张表对应一个类”转换就会得到一个什么都能装、什么都说不清的“商品”大类。第二件事是把一个概念拆到多张表。食材物料的身份在ERP主档中供应来源在SRM映射表中库存处境在WMS批次表中配方用途在BOH或ERP配方明细中。任何单表都只呈现它在特定上下文中的一部分事实。这里要特别区分五类东西技术实体表、视图、API消息、缓存对象是系统实现结构。业务对象销售商品、菜品、食材物料、供应商SKU、库存批次具有可识别身份和业务后果。业务角色同一对象在某个关系或场景中的身份例如食材物料进入采购情境后被称为“采购物料”不一定要复制成新对象。状态对象持续一段时间的处境如已批准、冻结、可售、待检不能因为代码表中有一列状态就把每个状态建成独立对象。事件已经发生并导致理解或行动的事实如物料冻结生效、门店可售关系被暂停。事件可能只在日志或流水中出现并不在主表中。本体与面向对象模型都使用类和关系但软件设计重行为与实现本体设计重领域结构、语义和现实关系同一领域的本体类结构不必与软件类结构相同。这个判断同样适用于数据库表。三、概念模型、数据模型和本体到底各自回答什么商业分析里常见的几种模型可以放在一条逐步收敛的链条上但它们不是成熟度高低关系。模型回答什么主要内容业务概念模型业务怎样谈论领域术语、概念、主要关系业务本体人和机器共享什么含义对象、关系、状态、事件、规则、行动及约束概念数据模型方案管理哪些数据主题高阶实体、属性和关系逻辑数据模型数据怎样规范组织属性、主外键、基数和规范化结构物理数据模型在特定技术中怎样存取表、列、类型、索引、分区和约束这五类模型之间不是“业务越多越高级、技术越多越低级”的关系。一次完整分析可能同时需要它们业务概念模型帮助相关方说清楚业务本体固定跨场景语义概念和逻辑数据模型把解决方案的数据需求组织起来物理模型负责在具体平台中实现。真正的问题不是选哪一个取代其他模型而是每层是否回答了自己应该回答的问题并保留了向上追溯和向下落地的映射。BABOK把概念建模和数据建模视为不同但互补的技术前者组织领域词汇和关系后者描述解决方案使用的数据实体、属性及关系。PMI《商业分析指南》同样把范围、过程、规则、数据和界面模型看成根据分析目的组合使用的结构化表达。模型没有一种可以包办全部问题。本体比概念数据模型多关心三件事。一是跨场景含义。菜品在POS中是销售对象在研发中由配方定义在供应链中驱动物料需求但“菜品”不能随系统切换而变成四个彼此无关的概念。二是可计算约束。供应商SKU只能映射一个总部食材物料不同固定规格使用不同物料编码门店可售不等于总部启用。这些含义不只是外键能否连接还涉及适用范围、时间、状态和例外。三是判断与行动。《本体驱动的AI数据管理》提出“事实—事理—行动”事实层说明当前对象和状态事理层说明为什么能得出判断行动层限定可以做什么。数据库保存了STATUS0却未必说明0表示冻结还是停用、由谁决定、对采购和门店销售产生什么影响。四、字段、主外键和代码表是语义线索不是语义答案数据模型仍然非常重要。正确做法不是绕过表而是把它当作证据来源。1. 从表名和字段名找候选术语product、item、sku、material暴露了不同团队的用词。先登记原词、系统、表字段和样例值不急于统一翻译。名称相同要检查口径名称不同要检查是否指向同一业务身份。2. 从主键找“系统如何识别它”主键能帮助发现身份规则但主键不必等于企业级业务标识。POS商品码、ERP产品码和供应商SKU可以都是合法主键却分别识别销售记录、总部对象和供应方对象。映射工作要问它识别什么、在什么范围唯一、何时变化、历史是否保留。3. 从外键找关系候选RECIPE_ID提示菜品与配方存在关系MATERIAL_ID提示配方成分引用食材物料。但外键只证明当前数据结构允许连接不能自动回答关系名称、方向、业务基数和有效时间。例如套餐与产品是组成关系不是“套餐的产品字段”一个产品可以被多个套餐引用。4. 从代码表找分类和状态候选ITEM_TYPE1/2/3可能混合菜品、饮料、套餐三个业务类别STATUS0/1可能在不同系统分别表示停用、冻结或不可售。代码值必须回到定义、触发事件、允许动作和适用对象中核实。分类、角色和状态尤其容易被混为一谈。5. 从非空、唯一和检查约束找规则候选数据库约束反映已经实现的控制但不能直接上升为业务公理。有些约束只是技术选择有些业务规则因历史原因根本没有实现。BA要追问如果换系统这条限制仍成立吗违反后是业务上不允许还是当前程序暂不支持五、从数据到本体需要七步映射而不是一次转换我建议食味里采用下面的七步链。第一步按业务问题定范围。先回答“门店能否销售”“物料停用影响什么”而不是扫描所有表。企业本体建模方法强调从业务闭环切入对象承接事件关系扩展上下文逻辑形成判断行动闭环回写。第二步盘点数据投影。收集相关表、字段、主外键、代码、样例记录、接口消息和权威系统记录每个模型服务什么处理目的。第三步拆出候选语义。把技术实体区分为业务对象、角色、状态、事件、关系、规则和载体。AI可以批量生成候选但每项必须保留来源定位。第四步回到访谈和流程核实。商品、研发、采购、仓储和门店分别解释“产品”“物料”“库存品”沿新品上线和缺货停售流程确认它们何时出现、由谁维护、怎样改变。第五步用规则和反例裁决。用“一品多规格”“新旧物料切换”“库存为零但仍可采购”“总部启用但门店未准备”等反例检查身份、关系和状态边界。第六步建立显式映射。不追求一个数据库公共表取代所有系统而是记录“本体概念—系统实体—字段—转换规则—权威来源—时间有效性—核实状态”。Palantir Model Studio的资料显示数据集输入需要明确列映射训练运行还要保留配置版本、血缘和权限标记。这个工程思想同样适用于语义映射映射本身必须版本化、可追踪不能靠一次性脚本隐含处理。第七步用能力问题回放。AI能否从“川香鸡腿饭套餐”导航到菜品、有效配方、食材物料、供应商SKU、库存批次和门店可售关系能否区分缺货、冻结、停用和不可售回答失败就说明映射或本体仍有缺口。六、食味里的第一版跨系统映射经过映射团队没有建立一个万能“产品”类而是得到下面的业务结构业务含义主要系统投影核心关系销售商品POS商品与渠道配置可指向套餐或产品并在门店范围内可售产品菜品/饮料POS/ERP产品记录菜品通过有效配方使用食材物料直接采购饮料可关联成品饮料物料食材物料ERP物料主档被配方成分引用可存在新旧替代关系供应商SKUSRM供应商物料记录由供应商提供只映射一个总部食材物料库存批次WMS批次库存记录是某食材物料在某仓库、批次和质量状态下的库存事实“库存品”因此没有直接复制成一个与食材物料平行的对象。若它只是WMS对物料在库存情境中的称呼就作为角色或系统投影处理库存数量、批次、库位、质量状态则进入库存批次或库存事实。只有发现独立标识、生命周期和业务规则才升级为独立对象。这也符合本体建模的迭代原则不存在脱离用途的唯一正确分类。先建立足以回答能力问题的最小模型再用真实数据、反例和专家评审逐步修订。团队还要保留“暂不统一”的权利。若两个字段只有名称相似业务颗粒度、时间口径或使用目的尚未确认就先登记为待裁决映射。错误地合并两个概念通常比暂时保留两个系统投影更难修复因为错误语义会继续进入接口、指标、主数据和AI回答。七、本体不是来替换数据模型而是反向约束它本体建好以后数据模型不会消失反而会得到更清晰的设计依据。对主数据本体明确对象定义、身份和关系边界帮助决定哪些是共享基础属性哪些只是系统业务属性减少“什么都塞进产品主档”。对数据目录表和字段不再只有技术说明还能挂接业务术语、对象、状态、规则Owner和使用场景。搜索“食材物料”时可以找到ERP主档、SRM映射、WMS库存和配方明细而不是依赖表名猜测。对接口设计本体提供稳定的交换含义。Canonical Model不应只是又一套公共字段而应明确消息中的身份、关系、状态语义、有效时间和版本各系统保留自己的物理模型通过受治理映射连接共享语义。对AI和分析模型列映射不再只解决数据类型匹配还能说明训练数据中的item_id究竟代表菜品、门店销售商品还是食材物料。Palantir Model Studio区分训练数据、静态元数据、配置版本、训练任务、模型版本和实验工件提醒我们不要把一个“模型表”混成同一概念输入、产物、状态和血缘应各有身份。结语不要问“这张表对应哪个本体类”更好的问题是这张表在什么系统、为了什么处理目的投影了哪些业务对象、角色、状态、事件和关系这些含义中哪些跨场景仍然成立哪些只是当前实现数据模型擅长把数据组织得可存储、可查询、可处理业务本体擅长把不同投影重新连接到共享领域含义并把规则和行动边界显式化。前者不是低级版本后者也不是企业级大ER图。下一次看到PRODUCT表不要让AI直接生成“产品类”。先拿出《数据模型—业务本体映射表》逐项记录系统目的、业务身份、字段证据、关系、状态、权威来源和待确认问题再用《同名字段口径对照表》检查同名是否同义、异名是否同物。当四张“产品表”终于能够共同回答同一个业务问题而不是被强行合并成第五张表时业务本体才真正开始发挥作用。【案例说明】 “食味里餐饮总部”及文中的系统、表、编码、产品、物料、供应商和业务规则均为虚构案例用于方法演示不代表真实企业的数据结构或行业统一标准。