模型首先是沟通工具
数据建模是发现、分析和确定数据需求的过程，并用一种精确的形式把需求表达出来。它的直接成果往往不是数据库，而是对组织数据的共同理解。模型提供通用词汇、记录系统细节、充当项目沟通工具，也是应用定制、整合与替换的起点。
- 三项价值：格式化（简洁定义结构与规则）、范围定义（划清上下文边界）、知识保留（把理解写成可复用的记录）
- 模型是元数据的重要形式；建模中发现的定义、关系和血缘，是治理与数仓的基础
- 建模不是一次画完，而是与业务专家反复确认、修改的迭代过程
- 好的模型降低支持成本，提高未来需求复用与新建应用的效率
三层抽象与六种建模方法
同一个业务，可以用不同模式表达，也可以在不同详细程度上表达。常见六种模式是关系、维度、面向对象、基于事实、基于时间和 NoSQL；每种模式又分概念、逻辑、物理三层。选哪种，取决于用途、目标数据库和团队习惯。
| 方法 | 核心组织方式 | 典型用途 |
|---|---|---|
| 关系建模 | 实体、关系、规范化，消除冗余 | 操作型系统（OLTP）、企业逻辑模型 |
| 维度建模 | 事实表 + 维度，逆规范化 | 数据仓库、BI 分析 |
| 面向对象建模 | 类、对象、继承、封装 | 面向对象应用与复杂领域模型 |
| 基于事实建模 | 对象—角色—事实，先事实后实体 | 语义精确的领域建模、契约式设计 |
| 基于时间建模 | 中心、卫星、链接，保留历史 | 数据仓库中的时间维度与历史追踪 |
| NoSQL 建模 | 文档、列族、图、键值 | 大规模、半结构化、高并发场景 |
概念模型与逻辑模型可以跨数据库技术复用；物理模型则高度依赖具体 DBMS。
| 层级 | 回答什么 | 典型内容 |
|---|---|---|
| 概念模型 | 业务中有哪些重要事物及关系？ | 主题域、核心概念、高层关系，面向业务沟通 |
| 逻辑模型 | 业务规则如何精确表达？ | 实体、属性、主外键、基数、域、规范化 |
| 物理模型 | 在特定数据库中如何实现？ | 表、列、类型、索引、分区、约束、存储参数 |
四个基本构件：实体、关系、属性、域
实体是组织收集信息的载体；关系描述实体之间的业务规则；属性定义、描述或度量实体；域规定属性允许的取值范围。模型的精确性，主要来自这四者的严格定义，而不是图形的美观。
- 实体定义要清晰、准确、完整；避免缩写和「有时」「正常」这类歧义表述
- 基数用 0、1、多组合表达「是否必须」和「参与数量」，是业务规则的直接体现
- 关系元数分为一元（递归）、二元、三元；层级与网络结构都用一元关系表达
- 属性在逻辑层必须原子化：一个属性只承载一个事实，不能再次拆分
- 域可以用数据类型、格式、列表、范围或规则约束来定义
| 类型 | 含义 | 注意点 |
|---|---|---|
| 候选键 | 能唯一标识实例的最小属性集 | 一个实体可有多个候选键 |
| 主键 | 被选为唯一标识的候选键 | 通常选代理键，业务键作备用键 |
| 备用键 | 未被选为主键的候选键 | 常用于业务查询与外部对照 |
| 代理键 | 系统生成的、无业务含义的整数 | 对用户不可见，便于集成与稳定引用 |
| 组合键 / 复合键 | 多个属性共同唯一标识；复合键再包含其他键 | 注意顺序与最小性 |
独立实体的主键只含自身属性；非独立实体的主键至少包含一个来自父实体的属性，对应标识关系。
正向工程：从需求走到物理表
正向工程从需求开始构建新应用：概念模型理解范围与术语，逻辑模型细化业务规则，物理模型适配具体数据库。每一步都需要业务确认，而不是建模师闭门造车。
- 概念模型不要过早迁就其他部门的术语；先如实 capturing 用户观点，再合并企业术语
- 逻辑模型交付物包括图表、定义、争议与未决问题、血缘（来源/目标映射）
- 物理模型要明确哪些逻辑抽象被吸收、哪些被分区，以及逆规范化的理由
- 模型评审要覆盖启动模型、变更内容、被否方案以及是否符合标准
- 规划：评估组织需求、确定建模标准、约定模型存储与协作方式
- 概念建模：选模式与表示法，收集核心名词与动词，合并企业术语，取得业务签署
- 逻辑建模：分析信息需求与现有文档，添加关联实体、属性、域与键，规范化
- 物理建模：处理超类型/子类型、类型与约束、参考数据、代理键、索引、分区与视图
- 评审：业务与技术共同检查正确性、完整性、一致性和可实施性
- 维护：版本控制、变更记录、影响分析，并持续与架构和标准对齐
逆向工程、治理与度量
逆向工程用于理解现有数据库：先物理、再逻辑、最后概念。它常是遗留系统改造、数据集成和主数据项目的第一步。模型治理则通过标准、评审、版本控制和度量，保证模型长期可用，而不是一次性交付后腐烂。
- 每次模型变更记录四件事：为什么改、改了什么、何时批准、谁改的
- 模型质量可用记分卡评估：正确性、完整性、一致性、可读性、可实施性
- 度量可关注：评审一次通过率、模型复用率、因模型缺陷导致的返工、交付周期
- 模型是活资产：需求变化、架构演进、系统退役都应触发更新
| 类别 | 内容 |
|---|---|
| 交付物 | 标准模型清单、图表、定义、问题清单、血缘 |
| 命名 | 对象命名格式、可接受缩写、禁用词 |
| 方法 | 建模步骤、工具使用、评审流程 |
| 元数据 | 需捕获的业务与技术元数据、质量要求 |
| 变更 | 版本控制、变更记录、影响分析 |
评审小组应包含业务、架构、开发、DBA 等不同背景成员；未通过时建模师需逐项解决或升级给系统所有者。