数据建模的流派分化源于一对根本矛盾：写入侧要求一致性、更新局部性与无冗余；读取侧要求聚合性能、可理解性与历史保真。两者在同一结构中不可兼得，主流流派都是这对矛盾在不同前提下的取舍组合。
数据建模（Data Modeling）将业务逻辑转化为结构化的数据定义（实体、关系、约束），充当“业务语言”与“数据语言”之间的翻译器，是数据治理、数据架构与数据仓库建设的公共结构层。结构化表达、跨系统一致性、可演进性是所有流派的共同价值底座；模型层的粒度与口径决策会被下游结构性锁定，缺陷以冗余、口径冲突与结构不可维护的形式在下游放大。
数据几乎只服务于两种用途：操作型记录（OLTP）与分析型决策（OLAP）。前者按单条事务处理，优化写入与更新；后者按批量聚合处理，优化扫描与理解。目标函数分化后，“如何组织数据”不存在统一最优解：3NF 消除冗余以保障写一致，维度建模引入受控冗余换取读性能与可理解性——流派是目标函数的结构解，不是风格偏好。
数据建模沿概念、逻辑、物理三层抽象推进，构成同一结构从业务理解到技术实现的细化链——三层是过程框架，模型工件只落在一层，是否齐备取决于协作与评审对中间产物的需求：
flowchart LR
A[概念模型] --> B[逻辑模型] --> C[物理模型]
三层职责互补：概念层对齐业务认知，逻辑层承载评审依据，物理层落地实现。实践中前两层常被压缩跳过，缺失的代价是协作理解偏差与架构逐渐失控。
能力结构由建模转换链决定——业务现实 → 概念模型 → 逻辑模型 → 物理实现 → 长期演进，每个转换环节有对应的胜任条件；缺少哪种能力，失败就出现在哪个环节，且多数无法靠流程或工具补偿。
| 转换环节 | 核心能力 | 失败信号（能力缺失时） |
|---|---|---|
| 业务 → 概念 | 业务抽象：从需求识别实体、事件、关系与约束 | 模型与业务语言对不上，需求反复返工 |
| 概念 → 逻辑 | 结构设计与粒度定义：按目标函数选流派，先定粒度再定维度与度量 | 表能运行但答非所问；跨表口径冲突 |
| 逻辑 → 物理 | 物理化与分层：分区、索引、冗余、分层落地的工程判断 | 性能不达标，或为性能牺牲口径 |
| 演进（贯穿） | 一致性与治理：口径统一、命名规范、变更受控 | 模型随业务变化劣化，血缘断裂、不可追溯 |
两项能力不锚定于特定环节：沟通翻译——模型是业务与工程之间的契约，模型的可理解性与正确性同等重要；验证——用查询负载与数据剖析检验模型假设，而非依赖设计时的直觉。
同一结构无法同时满足写入保真与服务形态（见“本质”），分层的解法是以空间换矛盾：让数据沿流向逐层完成结构转换，每层承担一次取舍。建模决策因此发生在层间分工——粒度、口径、冗余各层各就其位：
flowchart TB
ODS --> DWD --> DWS --> ADS
各层的建模驱动方式不同（ODS 保留源结构、DWD 业务过程驱动、DWS 分析主题驱动、ADS 场景驱动），建模方法流派则贯穿全层选择，形成完整的数据体系架构。DWS 与 ADS 同处服务象限，分界不在结构而在受众，是服务象限内部的受众切分而非结构转换。
两条正交轴刻画结构化数据的主流建模流派：
| 轴 | 一端 | 另一端 | 刻画什么 |
|---|---|---|---|
| 结构轴 | 规范化：拆表、消冗余、保写一致 | 反范式化：合表、换扫描性能与可理解性 | 为哪侧目标函数付出结构代价 |
| 时间轴 | 覆盖式：只保留当前态 | 追加式：全历史不可变、插入不改写 | 变化发生时牺牲什么 |
认知矩阵与流派归位：
| 覆盖式（当前态） | 追加式（全历史） | |
|---|---|---|
| 规范化 | OLTP 3NF 源系统。代价：分析查询 join 链长、口径分散 | Inmon EDW / Data Vault / Anchor 保留层。代价：表数量与 join 深度膨胀，需汇出才可分析 |
| 反范式 | 宽表/OBT、搜索索引、物化汇总。代价：更新扩散、口径漂移、依赖链长 | Kimball 星型 + SCD2。代价：冗余随版本数线性放大，维表膨胀 |
矩阵推论：
规范化×覆盖象限（OLTP 源系统）的标准形态：一致性强、冗余小；Inmon 将 3NF 与时间不可变结合形成 EDW，归入规范化×追加象限。 以消除冗余、保证更新一致性为设计原则；E-R 是其常用表示法，但 E-R 图同样用于概念层建模——前者是规范化原则，后者是表示方法，属不同层次。
反范式×追加象限的分析服务形态：事实表承载度量、维度表承载上下文，星型结构以受控冗余换取扫描性能与业务可理解性，维度历史保真由 SCD 机制承载。适合 OLAP，性能强、易理解。
规范化×追加象限的保留层形态：Hub（实体）/ Link（关系）/ Satellite（属性与历史）三类结构，显式融合 3NF 的可追溯性与维度建模的分析友好性。 适合源系统多变、审计与历史追溯要求高的场景；代价是表数量膨胀、需汇出到维度模型后才可直接分析，通常作为企业数仓的中间层而非直接面向分析（分层堆叠形态见矩阵推论 2）。
反范式×覆盖象限的物化形态：适合大数据查询分布式场景，避免关联，以冗余换查询性能。 代价是违反范式、属性变更需多处同步、依赖链长导致稳定性与维护性下降；在指标口径层面，宽表反而常用于统一口径。
由关系遍历目标函数主导。实体即节点，关系即边，适合关联密集型，如风控、推荐。
结构上靠近反范式端，但由检索匹配目标函数主导。反范式化、高冗余、为查询优化服务。
建模与邻域体系的关系由两个正交维度刻画：决策权（谁定义概念、谁裁决争议）与结构载体（各域的操作对象是什么）。治理拥有决策权，模型提供结构载体——权力中枢与结构底座分离，各邻域按此归位：
| 邻域 | 决策权归属 | 建模承担的结构角色 | 依赖方向 |
|---|---|---|---|
| 数据治理 | 概念定义权、标准审批、争议裁决 | 统一模型是标准落地的形态：建模是治理的结构执行层 | 治理授权 → 建模执行 → 成果回流登记 |
| 元数据管理 | 描述规范 | 模型是元数据的首要采集对象，业务/技术元数据派生自结构 | 结构先于描述，结构变更牵动登记 |
| 数据质量 | 质量标准与指标定义 | 约束、主键、唯一性是质量规则的挂靠点，检测在结构上运行 | 规则挂靠于结构，结构变更牵动规则集 |
| 数据架构 | 数据分布与流向决策 | 建模提供静态结构，架构组织动态流动；粒度与键决定可搬运性 | 流动方案受结构约束 |
结构缺陷不留在建模内部，而是以邻域症状暴露——模型作为公共结构载体的可观测形式；邻域体系失效时，应先检查其结构载体：
| 症状 | 表象领域 | 常见结构根因 |
|---|---|---|
| 同一指标两处口径分叉 | 数据治理 | 业务概念未收敛到统一模型，决策与载体分离 |
| 标准与生产"两张皮" | 数据治理 | 定义未经模型进入生产链路，标准停留在文档 |
| 质量告警频发 | 数据质量 | 约束、键缺失，规则无挂靠点 |
| 血缘断裂 | 元数据 | 无稳定代理键与字段级映射 |
| 跨系统集成对不齐 | 数据架构/集成 | 粒度与键设计不统一 |
归属判断信号：问题是"结构不存在或不统一"，还是"决策权或机制缺位"——前者回建模层，后者留在治理或邻域机制内。双向失效即职责边界：概念在治理文档与模型中各自定义（事实源冲突）说明授权与执行未分离；邻域规则悬空（质量规则无结构可挂）说明建模未提供载体。
治理对象由前文推导：模型是公共结构载体（"边界与生态"），粒度与口径被下游结构性锁定（"本质"），因此建模治理的核心对象不是模型本身，而是模型变更——其风险由两个量决定：扩散面（血缘给出的下游数量）与破坏性（结构或语义契约是否改变）。机制沿变更生命周期组织：
| 阶段 | 机制 | 控制的风险 | 失效形态 |
|---|---|---|---|
| 设计 | 建模规范：命名、主键、编码、粒度声明 | 语义起点分叉 | 新表绕过规范，口径从源头裂变 |
| 准入 | 分级评审：可加性变更走快速通道；结构与语义变更经评审，提议者与批准者分离 | 错误结构进入公共依赖 | 错误粒度/口径被下游固化，返工成本随下游数放大 |
| 发布 | 语义版本与兼容契约：加列不改语义为兼容变更，可独立发布；改粒度、改键、改口径为破坏性变更，需迁移窗口与双写/重跑 | 破坏性变更向下游传播 | 下游静默失败、口径漂移 |
| 退役 | 废弃流程：标记属主与退役日期、保留观察期、通知下游 | 腐化积累 | 无人敢删，公共载体退化为废弃资产堆 |
破坏性变更的判断不能停留在 schema 层：列名不变而语义改变——口径换算、指标分母、字段单位——结构校验通过而语义已分叉，是最隐蔽的破坏形态。兼容门禁因此必须校验语义契约（字段语义、单位、口径定义随版本冻结），而非仅校验结构差异。
一致性管理（跨系统概念对齐）的决策权归属数据治理、建模承担执行对齐，职责边界见"边界与生态"章。
各趋势驱动源不同——生成成本（AI）、需求侧（新目标函数）、物理成本（引擎经济性）——但收敛于同一元原则：演进只发生在可变的成本项上；不可变的矛盾（读写目标函数分化、公共载体属性）决定形态空间，可变成本决定形态在空间中的位置，人的角色向判断与授权环节收缩。由此得到三条共性：
AI 基于元数据、查询日志、业务文档可自动生成概念/逻辑模型。
随业务变化自动推荐字段、表结构优化。 外部尚无成熟实践，验证信号是主动元数据平台能否闭环完成“发现变更→推荐模型→人工确认”；在此之前，模型演进仍以人工评审为主。
图、向量、结构化同时存在，模型需兼容多模态数据结构。
分布式计算促使宽表、反范式模型在分析场景继续普及；但 OLTP 侧范式化仍是标准，Data Vault 还在显式融合 3NF 与维度建模。本质章的目标函数分化决定这是并存而非单向替代；物理前提的移动（见矩阵推论 4）则可能改变两端的相对位置。
选模型时先问这份数据主要拿来做什么，再决定两件事：拆表还是合表、只存当前状态还是保留历史（即坐标系的两条轴），最后才落到具体方法。下表每行都按这个顺序写，表里没有的场景也能照同样思路推出来：
| 场景 | 最看重什么 | 结构取向 | 推荐模型 |
|---|---|---|---|
| OLTP 业务系统 | 写入正确，改一处即全局生效 | 拆表去冗余，只存当前状态 | 范式建模 |
| 数仓明细/汇总层 | 汇总查询快、口径统一、能回看历史 | 合表加冗余，保留历史版本 | 维度建模 |
| 需要审计追溯、源系统经常变的数仓 | 历史完整，源系统变了不必推倒重来；查询慢些可以接受 | 拆表去冗余，保留全部历史 | Data Vault |
| 查询模式固定的大数据明细 | 查询不做 join；属性变更时多处同步也能接受 | 合表加冗余，只存当前状态 | 宽表 |
| 关系分析（风控/社交） | 沿关系逐层查找 | 两条轴不适用 | 图模型 |
| 搜索检索 | 关键词匹配与排序 | 两条轴不适用 | 搜索引擎建模 |
选型时最容易出错的三件事，按优先级：
不要只选一种方法。实际数仓都是分层组合：底层用范式或 Data Vault 保证数据完整、可追溯，上层用维度模型服务分析。常见错误是挑一种方法全局套用——因为 Data Vault "听起来专业"就全面采用，或一开始把所有数据都做成星型模型，上游一变就得返工。
团队能力和交付时间同样左右选择，且不在坐标系之内：Data Vault 对团队要求更高，自顶向下的方案上线更慢，这两点可能让结构上更好的方案不可行。因此常见路线是先用上线快的方案（维度模型、宽表）拿到成果，数据复杂度上来后再改为分层组合。
另一个常见错误是照搬源系统的表结构建模，会把源系统的设计包袱一并继承；应按业务过程（下单、支付、发货）建模。