过去二十多年企业数据建模的发展路径其实非常清晰。关系数据库强调范式设计目标是减少冗余、保证事务一致性数据仓库强调维度建模目标是支撑统计分析近年来的数据湖、Lakehouse以及数据中台本质上都是在解决数据存储、计算和共享的问题。虽然技术不断演进但有一个前提始终没有改变数据模型的消费者始终是程序而不是AI。程序知道如何访问数据库也知道如何理解数据库。开发人员在编写系统时已经把大量业务知识写进了代码。订单如何关联客户、合同如何关联项目、发票如何关联收入这些规则通常并不完全体现在数据库设计中而是散落在应用逻辑、接口服务、ETL流程甚至开发规范里。因此多年来企业并没有觉得这是一种问题。直到AI开始直接面对数据库。很多企业在部署智能问数、AI分析助手或者Agent时都会遇到一个现象。模型生成的SQL没有语法错误数据库能够正常执行但返回的结果却不符合业务预期。最初很多团队把原因归结于模型能力不足。后来模型不断升级从GPT到Claude从DeepSeek到各种行业模型SQL生成能力已经越来越成熟这类问题却依然存在。这说明真正的瓶颈并不在SQL生成而是在SQL生成之前。AI面对数据库时首先看到的是Schema。它知道有哪些表、有哪些字段、字段是什么类型也可能知道部分主外键关系。但Schema描述的是数据库的物理结构而不是企业真正的数据模型。这两者并不是一回事。举一个典型的企业场景。一家企业同时拥有CRM、ERP和财务系统。三个系统都保存了客户信息。CRM里的客户用于销售管理ERP里的客户用于订单履约财务系统里的客户则对应结算主体。从数据库角度来看它们可能属于三张完全不同的表。字段名称不同编码规则不同甚至数据维护人员也不同。但是对于业务人员来说它们描述的是同一个业务对象只是在不同业务阶段承担不同职责。这种认知来自长期的业务经验而不是数据库Schema。对于AI而言它只能看到三张结构不同的数据表却不知道它们之间描述的是同一个实体。于是当用户提出统计客户收入这样的业务问题时AI首先要解决的不是SQL如何写而是应该使用哪一个客户。真正困难的地方并不是查询而是理解。事实上这种情况并不仅仅存在于客户数据。产品、供应商、项目、合同、设备、员工……几乎所有核心业务对象都可能分散在多个业务系统之中。传统的数据建模更多关注数据如何存储而较少关注这些业务对象如何表达。因为过去真正消费这些数据的是应用程序。程序知道调用哪一个接口知道访问哪一张表也知道如何处理不同系统之间的数据差异。AI却没有这些背景知识。它面对的是数据库而不是整个企业的软件系统。因此AI第一次把企业长期隐藏起来的数据建模问题暴露了出来。这也是为什么越来越多企业开始重新关注业务实体。过去讨论数据治理更多关注字段标准、编码规范、数据质量和一致性。今天企业开始重新思考另一个问题如何让AI知道不同系统里的数据其实描述的是同一个业务对象这个问题已经超出了传统数据建模的范畴。它要求企业不仅管理数据还要管理数据之间的关系以及这些关系背后的业务含义。未来的数据模型不再只是描述数据存放在哪里还需要描述业务对象是什么对象之间如何关联哪些关系经过业务验证哪些定义才是企业真正认可的口径。这些能力过去更多依赖开发人员和业务专家共同维护。未来它们需要成为企业数据基础设施的一部分。很多人认为大模型的发展会逐渐解决企业数据理解的问题。我并不完全认同。模型的推理能力当然会越来越强但推理并不能替代企业自身的业务知识。一个模型可以猜测客户与订单之间存在关联却无法凭空知道哪一种关联才符合企业真实的业务规则。它可以生成一条能够执行的SQL却无法保证这条SQL符合企业长期形成的业务定义。因此未来企业AI竞争的重点或许不会是谁拥有参数更多的模型而是谁能够把几十年沉淀下来的业务知识真正沉淀到数据体系之中。AI没有改变数据库。真正改变的是我们开始重新思考数据模型应该服务于谁。过去它服务于应用程序。而今天它开始服务于AI。