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