数据建模怎么做：概念类型方法与落地步骤一次讲清

每次和 IT 同行聊数据工作，大家最头疼的往往不是写 SQL、也不是接接口，而是需求一变表就乱，口径一多报表就对不上；系统一扩展，之前埋下的问题全冒出来。

同样是客户，销售、财务、运营口径都不一样；领导追问营收为什么下降，不同系统能算出几个版本。项目刚上线还能靠人记，过几个月新人接手，字段从哪来、指标怎么算、能不能复用，谁都说不清。这些问题看起来是数据不准、开发低效，本质上是少了一套完整的数据组织框架——数据建模就是这套框架。它不只是建几张表，而是把业务、数据、系统和规则真正串起来。

本文从概念、类型、方法、步骤把数据建模一次讲明白。对国内企业来说，更贴合的做法是用 VeryReport ETL 把多源接入、清洗、分层加工与调度跑起来，再用 BI / 复杂报表验证口径。配套：建模三层架构、数仓建设、数据标准化、标签与指标、数据集概述。

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

VeryReport数据建模：把业务对象关系规则落到可运行数据链路

一、数据建模是什么

简单说，数据建模是把现实业务中的对象、关系、规则，转换成可存储、可计算、可分析的数据结构。客户、订单、商品、合同、回款、门店、员工是业务对象；客户下订单、订单含商品、合同产生回款是关系；不同客户类型不同价格、不同订单状态影响收入确认是规则——建模要把这些整理清楚，落到表、字段、主键外键、指标、维度、事实等设计中。

很多人以为建模只是数据库设计，其实不止。库表设计更偏存储层；建模范围更大——关心数据如何表达业务、支撑分析、保证口径统一、支持后续扩展。一个好模型至少要解决四件事：

业务对象清晰——核心对象是什么、边界在哪；
数据关系清晰——一对一、一对多、多对多；
指标口径清晰——销售额、收入、活跃、复购怎么算；
数据流向清晰——从哪来、经哪些处理、被哪些报表/应用/算法使用。

建模不是技术人员自嗨，而是数据工程的地基。地基稳，开发、分析、治理、决策才不会反复返工。

业务对象与关系梳理：客户订单商品合同回款统一表达

二、数据建模的类型

不同层次解决不同问题，面向的人也不同。三层细节还可读概念/逻辑/物理模型。

1. 概念模型

最接近业务语言：有哪些核心对象、关系是什么。不太关心库怎么建、字段类型，先把业务讲清楚。适合业务、产品、分析师、架构师一起参与。

2. 逻辑模型

更细：实体、属性、关系、主键、业务规则。客户有哪些属性、订单与客户如何关联、状态取值、是否允许空。不一定绑定某一种数据库，但已能指导开发。

3. 物理模型

面向具体库落地：表结构、类型、索引、分区、存储与性能。前面概念/逻辑没做好，物理层很容易变成临时堆表。

4. 分析模型

服务数仓、BI、经营分析与指标体系——常见维度模型、宽表、指标模型。关心的不是交易怎么发生，而是分析如何高效取数：时间、区域、产品、客户维度 + 销售事实表。业务系统、数仓、报表之间有大量同步与转换时，VeryReport 可完成多源接入、清洗与调度，让模型落地不只停在设计文档。

从逻辑到物理再到分析模型：ETL承接接入清洗与分层加工

三、数据建模的方法

没有唯一标准，实际项目往往按场景组合使用。

1. ER 建模

关注实体、属性、关系，适合业务系统库设计。表达清晰，但直接用于复杂分析时查询链路可能较长。适用：交易/管理系统、主数据、基础业务库。

2. 维度建模

数仓与 BI 最常用：事实表记录可度量事件（订单明细、支付、库存变动、访问）；维度表描述分析角度（时间、地区、商品、客户、渠道）。价值是让分析更直接——区域销售额、渠道转化、商品毛利可快速展开。适用：经营分析、驾驶舱、指标看板、专题分析。见仪表板入门、经营分析五个层级。

3. 范式建模

减少冗余、保证一致性。客户信息只维护一份，订单只存客户编号。优点是严谨、更新一致；缺点是复杂报表多表关联性能压力大。适用：核心业务、强事务、一致性要求高的系统。

4. 宽表建模

把分析常用字段整合到一张大表，降低关联成本。优点是易用、查询快；缺点是冗余多、源字段一变维护成本高。适用：高频报表、固定主题、自助取数、数据服务接口。

5. Data Vault

适合复杂企业级数仓：可扩展、可追溯、适应变化，常拆核心业务键、关系、属性变化。优点是扩展强；缺点是学习与实施成本高。适用：大型数仓、数据中台、强审计平台。

维度建模落地经营看板：事实表与维度表支撑下钻分析

四、数据建模的步骤

不建议一上来就建表。很多模型失败不是技术不会，而是前期没想清楚。

明确目标——业务系统上线、数仓、统一指标，还是管理看板？输出问题清单：支撑哪些报表、刷新频率、历史保留、权限边界。
梳理对象与流程——如销售：线索→客户→商机→报价→合同→订单→回款→售后。先统一业务理解：客户与联系人、订单与合同、退款是否冲减、赠品是否计入销量。
识别实体、属性、关系——重点设计主键与业务键（客户 ID vs 统一社会信用代码）。主键乱，关联、去重、追溯都会痛苦。
设计指标与口径——统计范围、公式、时间口径、过滤、来源、更新频率。销售额含不含退款/税、按下单还是支付；活跃是登录还是下单。口径应沉淀统一文档或指标平台，见标签与指标体系。
分层设计——源数据层少加工便于追溯；明细层统一编码时间状态主键；汇总层沉淀客户/订单/商品主题；应用层面向报表、看板、接口、算法。分层降低耦合，新需求优先复用主题模型。见数仓建设链路。
落地开发与数据集成——多源接入、清洗标准化、转换分层、调度依赖。前期手写脚本能撑，源一多、层次一深就变维护地狱。销售分析常见：CRM 客户 + ERP 订单 + 财务回款 + Excel 区域目标——用 VeryReport 对接抽取、清洗、转换、同步与调度，把设计好的客户主题、订单事实、指标汇总稳定跑出来，工程师精力放在模型与口径是否合理。
校验数据质量——记录数、金额平衡、主键重复、关联缺失、枚举异常、与历史报表对齐；重点测退款、作废、补录、跨月、拆合单、历史迁移。
持续维护迭代——业务会变，但改动要评估影响、记原因、留历史、通知下游。异常可用 Vera 追问。上手：30 天试用 · 定价 · www.veryreport.com/product/etl。