数据建模项目手册

1. 业务驱动与目标

数据模型是业务与技术之间的数据需求契约。它应：

• 建立共同词汇，明确范围、结构、关系和业务规则；
• 记录组织对数据的当前或期望理解，保留可复用的企业知识；
• 支撑应用开发、集成、主数据、治理、分析和变更影响分析；
• 降低异常、返工、支持成本和重复建设，同时提高复用与长期可维护性。

成功不等于画完 ER 图，而是模型准确覆盖获批需求、与实际数据相符、能被目标受众理解、能生成或验证实现，并在变化后仍保持追溯和版本一致。

2. 原则与关键概念

选择合适的模型

根据使用场景选择关系、维度、对象、事实型、时态或 NoSQL 等方案，不因工具默认模板而选择。一个项目不一定需要同等深度的三级模型，但省略某一级必须说明受众、风险和替代证据。概念与逻辑建模属于需求规划/分析，物理建模属于技术设计。

精确性原则

• 每个模型声明范围、受众、层级、方案、符号、状态和版本。
• 每个实体/事实写粒度声明；每个属性写业务定义、域、可选性和来源。
• 区分自然键、企业键、代理键与显示编号；记录唯一范围和时态。
• 同时表达名词（数据）与动词（过程/事件），用真实场景检验基数和生命周期。
• 逻辑名称面向业务、尽量使用完整词；物理名称遵循平台约束和统一缩写，不嵌入环境名。
• 抽象、规范化或反规范化必须有明确收益、代价和验证；物理优化不改变未获批准的业务含义。
• 模型图、定义、问题清单和血缘缺一不可；自动血缘不能代替业务语义。

3. Plan / Control / Develop / Operate

Plan

1. 明确业务结果、用例、范围/非范围、受众、时间和交付阶段。
2. 盘点企业模型、数据架构、分类/术语、标准、现有模型/数据库、数据集和需求；用 SME 与数据剖析验证旧资产。
3. 选择建模层级、方案、符号、工具、仓库和协作/版本方法。
4. 制定图、定义、问题、血缘、评审和批准的完成标准。

Control

1. 发布模型/数据库交付物、命名、定义、元数据、工具、版本与设计评审标准。
2. 分开举行需求评审、逻辑设计评审和物理设计评审；每项意见有级别、owner、期限和证据。
3. 对共享术语、键、参考域、企业模式和架构一致性执行门禁；争议由具名数据所有者裁决。
4. 对模型、字典、DDL、映射、规则与代码实施一致的变更控制和版本标识。

Develop

1. 从业务过程、信息产品、问题和场景提取概念（名词）、活动（动词）、规则及关系。
2. 建 CDM：先捕获用户视角，再与企业术语/模式协调，确认范围与签署。
3. 建 LDM：分析需求与已有资产；补充实体/事实、关联实体、属性、键、域、基数、可选性、时态和规则；保持技术中立。
4. 建 PDM：解析逻辑抽象，设计表/对象、列/字段、数据类型、约束、引用完整性、索引/分区、反规范化和安全要求；用代表性数据验证性能与正确性。
5. 建立需求→术语/规则→CDM→LDM→PDM→源/目标映射→质量规则→测试的双向追溯。
6. 对既有数据库可逆向工程，但必须重建可读语境、定义和业务验证，不能把物理现状误称为逻辑需求。

Operate

1. 发布同版本的模型图、机器可读模型、定义、映射、DDL、问题/决定和评审证据。
2. 在每个迭代末从实现逆向比较 PDM 与 LDM/CDM，识别未经批准的漂移。
3. 变更记录 why/what/how/when/who/where，执行影响分析、兼容性、迁移、回退和消费者通知。
4. 监控模型复用、需求覆盖、缺陷、漂移、变更周期和生产数据一致性；持续改进标准与模式。

4. 上下文与角色

模型评审应包含不同背景和使用视角；无共识且建模师无法解决时，由模型所反映系统/业务的具名 owner 作最终决定。

5. 交付物与验收证据

建模任务书与层级选择

- 业务结果、用例和消费者：
- 范围/非范围与关键场景：
- 待回答的业务/技术决定：
- 需求、现有模型/数据、架构和标准来源：
- 模型层级/方案/符号/受众及选择理由：
- 平台约束和禁止假设：
- 图、定义、问题、血缘和版本交付物：
- 评审者、裁决者、阶段门和验收证据：

需求与模型追溯

元素定义卡

- 名称/同义词/类型/模型层级：
- 定义、包含/排除项、例子/反例：
- 粒度、键、唯一范围和生命周期：
- 属性/域/单位/可选性/默认与空值语义：
- 关系、基数、业务规则和有效期：
- 权威来源、源字段、转换与血缘：
- 分类、质量要求和数据 owner：
- 开放问题、决定、状态和版本：

评审清单

变更记录

- 变更 ID、触发需求、提出人：
- why；what/how；when；who；where（受影响模型/版本）：
- 对定义、粒度、键、接口、质量、安全、消费者和历史的影响：
- 候选方案与决定人：
- 兼容性、迁移/回填、并行版本、弃用与回退：
- 测试、批准、发布日期和实际验证：

快速路径、样本与评分

四周最小路径：第 1 周批准任务书、用例、术语冲突和 CDM；第 2 周签署 LDM、定义卡与追溯；第 3 周只对端到端薄切片形成 PDM、映射和样本装载；第 4 周完成场景/数据/性能/权限回归、同版本发布和移交。无法裁决的语义不得以技术默认固化，只能由赞助人批准并列口径、隔离或降范围。

模型质量每个维度使用统一量表：0=无证据/错误、1=重大缺失、2=部分满足且有整改、3=满足标准、4=有独立验证并可复用。发布前为各维度设权重和阈值；需求覆盖、结构正确、模型—数据一致出现 0 分，或任何阻断缺陷未关闭时，一票否决。记录评分人、证据、评论、整改、复评日期，不以总分掩盖关键失败。

阶段门：任务书/层级获批 → CDM 范围/术语签署 → LDM 需求/结构签署 → PDM 可实施性验证 → 图/定义/映射/实现版本一致 → 发布和运行漂移核对。阻断项未关闭不得把模型标为批准。

6. 工具与技术

• 建模工具与仓库： 维护符号、定义、命名、正向/逆向工程、版本、比较和共享；绘图只是其中一部分。
• 数据剖析： 验证实际类型、域、唯一性、空值、模式、关系和异常，暴露模型与数据不匹配。
• 血缘/映射： 记录概念—逻辑—物理和源—目标，支持现实校验及影响分析。
• 模式/行业模型： 可作起点，须按本组织需求裁剪并由 SME 验证，不能以“行业标准”免除批准。
• 场景走查： 用创建、更新、合并/拆分、迟到、更正、取消、删除、历史时点和边界值验证模型。
• 原型与生成/逆向： 用 DDL、样本和代表性负载验证可实施性，并比较实际结构是否漂移。

物理数据库设计兼顾 PRISM：Performance/ease of use、Reusability、Integrity、Security、Maintainability。性能反规范化应在常规结构/索引/分区不足后再采用，并记录重复、一致性控制和回退。

7. 指标、风险与实施

质量评分须同时评价需求覆盖、完整性、层级/方案匹配、结构、适度抽象、命名、可读性、定义、企业一致和模型—实际数据一致；分项给出证据、分数和整改动作，不能只报总分。

主要风险：把物理现状当业务需求；模型过度抽象或提前设计未来范围；业务只在最后评审；旧模型未经验证复用；图/定义/DDL/代码版本分裂；逻辑变化未经批准混入物理优化；只检查总量不检查记录级一致；工具仓库无人维护。以分层选择、迭代 SME 验证、剖析、追溯、阶段门、版本比较和发布后逆向核对控制。

8. 依赖与协同

• designing-data-architecture：提供主题域、企业术语、权威来源、生命周期和平台方向；模型反馈细粒度影响。
• establishing-data-governance：裁决共享定义、所有权、标准与例外；不由建模师替代业务决策。
• managing-metadata：发布术语、定义、模型、版本、血缘、所有权和影响关系。
• managing-reference-and-master-data：当企业键、身份解析、层级或受控代码需要运营能力时主导。
• 当范围从一次性模型扩展为持续匹配、人工裁决队列、合并/拆分发布、黄金记录维护或向源系统回写时，升级为 managing-reference-and-master-data 主导；本技能只维护结构与规则契约。
• integrating-data：实现接口契约、源—目标转换、编排、对账和错误处理。
• operating-data-storage：验证数据库物理运行、容量、可用性、备份恢复和维护。
• delivering-data-warehousing-and-bi：主导指标、事实/维度交付、历史装载和消费采用；本技能负责模型质量。
• improving-data-quality：把模型规则转成剖析、控制、监测和问题修复。
• securing-data：将分类、访问、最小化、保留和保护要求落入模型与实现。