很多人学数据模型时会卡在同一处：三要素的说法有好几种版本，一会儿是数据结构、数据操作、数据约束，一会儿又变成数据集合、数据结构、数据处理，看完不知道背哪个、更不知道怎么用。这篇只讲后一种划分，把三个词各自管什么、边界在哪、什么时候不适用一次说清，并给一套自查顺序，让你读完能拿它去拆一份实际的数据设计。
很多人学数据模型时会卡在同一处：三要素的说法有好几种版本，一会儿是数据结构、数据操作、数据约束，一会儿又变成数据集合、数据结构、数据处理。看完之后不知道背哪个，更不知道怎么拿来用。
这篇只讲后一种划分。三个词各自管什么、边界在哪、什么时候不适用，一次说清，最后给一套自查顺序。读完之后你至少能拿它去拆一份实际的数据设计，而不是停在名词上打转。
先搞清楚：为什么会有「集合—结构—处理」这种划分
先接受一件事：三要素的说法不止一种。偏数据库教材的版本常写成数据结构、数据操作、完整性约束；而「集合—结构—处理」这套更贴近从数据本身出发的理解路径，侧重数据从哪来、长什么样、被怎么用。两种划分不是对错关系，只是切分角度不同——一种切的是模型这个抽象工具，一种切的是数据这条线。
| 划分口径 | 三个要素 | 适合谁用 |
|---|---|---|
| 抽象工具视角 | 数据结构、数据操作、完整性约束 | 做表设计、写 schema、准备理论考试 |
| 数据视角 | 数据集合、数据结构、数据处理 | 做数据接入、清洗、口径梳理、交接文档 |
数据集合：先确定「有哪些东西被管」
数据集合回答的是范围问题：这个模型里到底涉及哪些对象，比如用户、订单、商品，以及哪些属性被纳入、哪些明确排除。范围没定，后面的结构和处理都会返工，所以这一步的产出应该是一份能对着核对的清单，而不是一句「大概就这些」。
- 把实体、字段、取值范围各写一行，标明哪个是主键、哪个允许为空
- 边界数据单独列：历史归档、外部导入、人工补录的数据要不要进，先写清楚
- 相邻系统里同名的字段要标出来源差异，避免口径打架
- 清单里加一列「谁负责确认」，把口头共识变成有人签字的记录
容易漏的恰恰是边界数据。一家 5 人小团队做报表，往往把手工 Excel 补录的数据也塞进集合里，但没人写清楚它算不算正式数据，结果统计口径隔一段时间就变一次，谁也说不清责任。
要注意的是，探索性分析阶段数据范围本来就模糊，这时候清单只当草稿用，别把它当成验收标准，否则会把还没想清楚的东西过早锁死。
数据结构：定义「这些东西之间怎么连」
数据结构管的是关系与层级：一张表内的字段类型，表与表之间的一对一、一对多、多对多，以及是走星型还是更规范化的拆分。它决定了你后面能不能顺畅地查、能不能方便地加。
- 先画关系图再动手把实体画成方框，连线写上基数，标出哪边可选、哪边必填，画完再对照真实数据抽几条核对。
- 检查层级是否混层日志流水、主数据、维度、事实各自归位，不要放在同一层里混着。
- 确认标识与分类分离一个字段不要既当唯一标识又当分类标签，这两件事对数据的要求不同。
- 留一份字段字典字段名、含义、类型、取值范围各一行，交给后面接手的人。
常见坑是把不同层级的东西混在同一层：日志流水和主数据放一起、维度和事实不区分，前期看着方便，后期查询会越来越别扭，改一处动全身。
不过也有例外：如果这批数据只做一次性统计、不进长期库，那用宽表堆着可能比认真建关系更省事。判断标准是这份数据要不要被反复查询和更新，会就认真建，不会就先图快。
数据处理：规定「数据进来之后怎么办」
数据处理覆盖写入、更新、校验、聚合、导出这些动作，本质是给数据定规则：什么时候写、谁有权限改、改了要不要留痕。这一块最容易被忽略的是约束和异常处理——重复数据怎么去、空值算不算有效、对不上的记录是退回还是先落库。
- 写入规则
- 什么触发写入、批量还是实时、写失败重试几次
- 校验规则
- 哪些字段必须过校验、不合规的记录落到哪
- 变更规则
- 谁能改、改前要不要审批、留不留历史版本
- 导出规则
- 谁可以导出、导出前要不要脱敏、导出频率怎么控
建议把处理规则写成可执行清单，每条规则后面跟上「谁来跑、多久跑一次、出错找谁」。规则只写在文档里而代码里没实现，是最常见的落差，所以每隔一段时间要拿实际链路对一遍。
处理规则会随业务变化，别把它写成永远不变的文档。按阶段更新更实际，但每次更新都要留下记录，否则半年后没人说得清某条规则是什么时候加上去的。
一套自查顺序：拿你手上的模型过一遍
三要素不是背出来就完事，关键是能拿它当检查表用。下面这个顺序从范围到规则逐个过，任何一步卡住都先别往下走，因为后一步会依赖前一步的结论。
- 第一步查集合范围、主键、必填项是否都写明了，有没有偷偷漏进来的外部数据。
- 第二步查结构关系图的基数和实际数据是否一致，有没有字段既当标识又当分类。
- 第三步查处理写入、更新、校验、导出四条链路各跑一次，看有没有规则只写在文档里、代码里没实现。
- 第四步做交叉检查集合里每个字段都应该能在结构里找到位置、在处理里找到规则，找不到的就是缺口。
交叉检查是最有价值的一步。很多模型看着完整，其实某个字段在集合里有、在结构里没落位、在处理里也没规则，等于挂在那儿没人管。发现这类字段就先别急着上线，回头补上归属。
如果你在对比不同数据工具或中转服务对同一份数据的支持情况，具体覆盖范围和当时的政策以站内页面为准，可以到 /sites 和 /tools/speed-test 核对当时的数字，别停留在旧印象里。
下一步把本文的自查顺序当成清单，去拆一份你手上真实的数据设计，遇到指标或工具对比的判断再回站内查当时的数字→常见问题
数据模型三要素到底该背哪个版本？
看你面对的场景。考试和教材按给定口径答，别混着写；做实际设计时，用「集合—结构—处理」更容易顺着数据走一遍，因为每一步都能落到清单和检查动作上。两个版本说的是同一个东西的不同侧面，不存在必须二选一。
三个要素里哪个最重要、该先做哪个？
顺序通常是集合先于结构，结构先于处理。范围没定清就去建关系，字段会反复加；结构没定稳就写处理规则，规则会频繁重写。但如果只是临时跑一次分析，跳过结构直接处理也合理，关键是把范围写清楚，避免结果对不上。
学了这套对我实际工作有什么用？
最直接的用处是查漏。拿到一份设计或一份数据需求，你可以按集合、结构、处理三条线各过一遍，缺字段、缺关系、缺规则会立刻显出来。很多返工不是因为技术难，而是因为一开始这三件事没人写清楚。
