数据建模三层架构：概念模型、逻辑模型、物理模型怎么分

AI 能力越强，企业数据治理的真实水平就越藏不住。模型能不能训好，报表能不能统一，指标能不能对齐，接口能不能稳定，本质上都绕不开：数据到底有没有被系统地设计过。很多企业不是没有数据，而是口径混乱、关系不清、落地随意——越用数据，越容易出问题。

在数据治理体系里，数据建模是不能跳过的关键环节。它不是画几张表那么简单，而是把业务规则、数据关系和技术实现真正串起来。很多人有概念，但一到概念模型、逻辑模型、物理模型这三层就容易混在一起。本文一次性讲清它们分别解决什么问题、彼此什么关系，又该怎么在项目里用起来。

对国内企业来说，更贴合的做法是用 VeryReport ETL / 数据中心把多源数据接入、清洗、映射与任务调度管起来，再沉淀为可复用数据集，供 BI、复杂报表与 Vera 同源使用——建模不只停在纸面。配套：数据仓库建设完整链路、数据治理四件事、数据资产管理、数据集概述、数据中心主题。

导航：ETL · BI 自助分析 · Vera AI · 复杂报表 · 定价 · 30 天试用 · 帮助文档 · 产品社区

VeryReport数据建模与ETL：从业务共识到可运转数据底座

一、概念模型：先把业务讲明白

很多团队一提建模就直接建表，上来就讨论字段类型、主键、分区——忙了半天，发现核心业务对象都没统一。订单包含哪些状态？客户和会员是不是一个概念？产品和商品是不是一回事？一开始说不清，后面做得越快，返工往往越大。

概念模型的重点不在技术实现，而在业务抽象。它回答：企业在经营哪些核心对象，对象之间什么关系，业务规则最基本的边界在哪里。你可以把它理解为业务世界的数据蓝图——首先面向业务、产品、数据团队之间的共识，而不是开发。

通常要做：识别核心实体（客户、订单、商品、门店、供应商、合同、活动等）；明确实体关系（客户多订单、订单多商品、商品属品类）；统一核心名词（用户/客户/会员/消费者哪些同义、哪些不是）；划定业务边界（售后归交易域还是服务域，库存锁定算库存还是订单）。

这一层做得好，最大价值不是模型漂亮，而是后面所有人说的是一套话。数据治理最怕的不是技术难，而是每个人理解的业务不是同一个版本。业务变化快、系统又多的企业里，销售系统与客服系统里的「客户」含义可能完全不同——没有概念模型先统一，逻辑模型很容易变成系统字段拼盘。

跨系统集成时尤其明显：CRM、ERP、订单各自独立，真正打通才发现同样叫客户编号，规则并不一致。这时可用 VeryReport ETL 先把分散数据接入并初步梳理，再反过来校验业务对象定义是否统一——概念模型不再停留在纸面讨论，而是能结合真实数据发现命名冲突、主数据重复和边界重叠。说得再直接一点：概念模型是先用数据语言把业务世界翻译清楚；它不负责最后怎么建库，但决定后面会不会越做越乱。

多源业务系统接入：概念层统一客户订单商品等核心对象

VeryReport ETL设计器：接入梳理校验业务对象定义

二、逻辑模型：把业务规则变成可管理的数据结构

概念模型回答「有什么」，逻辑模型回答「怎么组织」。这一层进入更细的设计，但仍不直接绑定某一种数据库实现。核心任务是把概念对象拆成可管理的数据实体、属性与关系，并明确约束——介于业务理解与技术落地之间，最容易体现建模能力。

画 ER 图不算错，但不完整。真正有价值的逻辑模型，是把业务规则映射成清晰、稳定的数据结构。通常要处理：实体有哪些属性（订单要不要支付/发货/退款状态）；一对一、一对多还是多对多（订单与商品常需订单明细承接）；哪些必须唯一（会员号、合同号）；哪些允许为空；历史变化如何记录（客户等级、部门变更、价格变动）。

最见功力的不是字段列得多完整，而是结构是否稳定、规则是否清晰。很多报表难做、指标难统一，根源都在逻辑模型没设计好。例如分析复购率，看起来只要订单表；若客户身份未统一，测试单、赠品单、拆单合单规则也没梳理，指标一定会反复打架——不是 BI 不行，而是逻辑模型没有把业务规则沉淀进去。可参考智能问数与指标口径、数据治理四件事。

设计原则：面向业务稳定性（为报表临时加字段很容易，系统一变就成历史包袱）；面向复用（客户、商品、组织尽量统一设计）；面向治理（可读、可追溯、可维护，比短期能跑更重要）。成熟团队会在这一层同步定义数据标准与口径规范——逻辑模型稳定后，数仓分层、指标体系、主数据都会顺畅很多；反过来逻辑模型是散的，再补治理成本极高。

三层关系可以记：概念模型统一语言，逻辑模型固化规则，物理模型真正落库。中间这一层看起来不显眼，实际上最关键——业务能不能被准确翻译成数据结构，主要就看这里。在 VeryReport 里，逻辑规则往往沉淀为数据集加工与指标定义，供看板与问数共用（见数据集概述）。

逻辑模型落地为数据集加工：口径规则可复用可追溯

数据中心能力：建模治理与BI报表问数同源

三、物理模型：让模型跑起来，而且跑得稳、跑得快

到了物理模型，建模进入落地阶段。前面两层讲清业务与结构，这一层必须面对数据库、引擎、性能、存储和开发规范。简单说，就是把逻辑模型转成最终可执行的数据库设计：建哪些表、字段类型、主键、索引、分区、同步与更新策略——不只是把表落出来，更是为稳定性、查询效率和维护成本负责。

通常涉及：表结构（宽表/主题表、明细/汇总）；字段类型；主键与索引；分区分桶；更新机制（全量、增量、拉链、快照、近实时）；命名与开发规范。为什么逻辑图画得挺好、上线却不理想？因为物理模型不是简单翻译，而是带着技术约束做实现优化。高频查询、低频更新、超长文本全塞一张表，性能往往出问题；主数据跨多源同步若主键策略没设计好，很快重复、断档、覆盖错误。

这一层最考验业务理解与技术实现的结合：不能只顾性能把规则做丢，也不能只顾结构完美不顾运行成本。真实项目里还会牵扯数据集成与任务编排——ERP、CRM、门店、电商汇入数仓，核心表不仅要建出来，还要持续稳定更新。靠大量手写脚本短期能做、长期维护吃力；源头字段变了、接口调了、增量规则变了，整条链路就容易故障。

这种场景下，VeryReport 的价值很容易体现：不是只解决单点同步，而是把多源异构接入、数据开发、任务调度和链路管理串起来。字段映射、清洗、增量同步、任务依赖统一管理后，物理模型就不只是设计稿，而是能真正持续运转的交付结果。系统多、源头杂、变更多的企业尤其需要——物理模型的难点从来不只是建表，而是长期稳定地把数据放到该在的位置上。数仓分层实践见数据仓库建设完整链路。上手：30 天试用 · 定价 · www.veryreport.com/product/etl。

物理模型持续运转：多源同步调度与增量链路统一管理