# 数据建模项目手册

## 1. 业务驱动与目标

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

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

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

## 2. 原则与关键概念

### 选择合适的模型

| 层级 | 主要问题 | 内容 | 技术依赖 | 典型批准者 |
|---|---|---|---|---|
| 概念 CDM | 范围内有哪些业务概念，如何关联 | 核心概念、关系、业务语言和边界 | 无 | 业务负责人/数据所有者 |
| 逻辑 LDM | 详细数据需求和规则是什么 | 实体/事实、原子属性、键、基数、可选性、时态、定义 | 与具体产品无关 | 业务数据所有者/架构师 |
| 物理 PDM | 如何在目标技术中实现 | 表/集合/节点、列/字段、数据类型、约束、索引/分区及技术命名 | 有 | DBA/平台/工程负责人 |

根据使用场景选择关系、维度、对象、事实型、时态或 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. 上下文与角色

| 角色 | 责任与决策权 |
|---|---|
| 业务负责人/数据所有者 | 批准范围、定义、粒度、业务规则、权威来源和残余风险 |
| 业务分析师/SME | 提供过程、场景、需求、例子/反例并验证可理解性 |
| 数据架构师 | 提供主题域、企业术语、共享模式和跨模型约束，审查一致性 |
| 数据建模师/分析师 | 主持发现，设计模型、定义和追溯，呈现选项，不擅自裁决业务语义 |
| 数据管家/元数据负责人 | 维护术语、定义、所有权、标准、参考域、仓库和问题闭环 |
| DBA/平台/数据工程 | 提供技术约束、物理设计、生成/逆向、迁移、性能和运行证据 |
| 集成/质量/安全专业人员 | 验证映射、实际数据、规则、分类、访问和控制影响 |
| 模型评审负责人/记录人 | 管理议程、材料、意见、共识、决定、签署和后续行动 |

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

## 5. 交付物与验收证据

### 建模任务书与层级选择

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

### 需求与模型追溯

| 需求 ID/用例 | 术语/规则 | CDM 概念 | LDM 实体.属性 | PDM 对象.字段 | 来源/转换 | 质量/测试 | Owner | 状态/版本 |
|---|---|---|---|---|---|---|---|---|

### 元素定义卡

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

### 评审清单

| 维度 | 核对问题 | 证据 | 结论/缺陷 | Owner/期限 |
|---|---|---|---|---|
| 需求覆盖 | 每个 P0/P1 需求在模型哪里，模型中多余内容为何存在 | 追溯矩阵、用例走查 | | |
| 完整元数据 | 图、定义、粒度、键、关系、域、来源、问题是否齐全 | 模型包 | | |
| 层级/方案 | 细节是否符合 CDM/LDM/PDM 与所选方案 | 模型声明、标准 | | |
| 结构正确 | 唯一性、基数、引用、可选性、时态和异常是否合理 | 场景/约束测试 | | |
| 抽象/复用 | 通用结构是否带来价值而非理解或实现负担 | 方案权衡 | | |
| 命名/定义 | 名称一致可懂，定义完整准确且无循环 | 术语/命名标准 | | |
| 可读性 | 布局和分图能让目标受众正确解释 | 受众验证 | | |
| 企业一致 | 共享术语、键、模式与架构一致或有批准例外 | 企业模型/ADR | | |
| 模型—数据一致 | 类型、域、唯一性、空值、枚举和关系匹配实际数据 | 剖析/样本/测试 | | |
| 实施/运行 | 性能、安全、恢复、变更和可维护性可证实 | 原型/基准/运行评审 | | |

### 变更记录

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

### 快速路径、样本与评分

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

| 样本层 | 选择规则 | 用途 | 版本/Owner | 预期结果与批准 |
|---|---|---|---|---|
| 正常 | 高频且已知正确的代表性记录 | 主路径与回归 | | |
| 边界 | 最大/最小、跨期、多对多、时区、生命周期边界 | 基数、时态、约束 | | |
| 异常 | 空值、重复、孤儿、冲突、迟到、错误格式 | 拒绝、隔离与修复 | | |
| 金样本 | 由业务 owner 人工裁决并冻结输入与期望 | 语义、匹配、迁移回归 | | |

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

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

## 6. 工具与技术

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

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

## 7. 指标、风险与实施

| 指标族 | 示例 | 最低定义要求 |
|---|---|---|
| 覆盖/完整 | 需求追溯率、必需元数据完整率、开放问题老化 | 分母、层级、阈值、owner |
| 结构/标准 | 结构缺陷、命名/定义符合率、企业模式一致率 | 评审规则和例外 |
| 模型—数据 | 类型/域/唯一/引用匹配率、未映射值 | 剖析数据集和时间点 |
| 交付/变更 | 评审一次通过率、重工、变更周期、漂移数 | 基线、目标、数据源 |
| 复用/价值 | 复用模型/模式、支持成本、需求/缺陷避免 | 归因方法和受益人 |

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

主要风险：把物理现状当业务需求；模型过度抽象或提前设计未来范围；业务只在最后评审；旧模型未经验证复用；图/定义/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`：将分类、访问、最小化、保留和保护要求落入模型与实现。