读DAMA数据管理知识体系指南11数据建模（下）

1. 规范化

1.1. 规范化(Normalization)是运用规则将复杂的业务转化为规范的数据结构的过程

1.2. 范式化的基本目标是保证每个属性只在一个位置出现，以消除冗余或冗余导致的不一致性

• 1.2.1. 整个过程需要深入理解每个属性，以及每个属性与主键的关系

1.3. 规范化规则根据主键和外键整理属性

• 1.3.1. 规范化规则可归类到不同规范层次，对每一个层次可应用更细的方式和规范性来搜索正确的主键和外键

• 1.3.2. 每个级别由一个独立的范式组成，并且每个相继级别不需要包含以前的级别

2. 范式的层次

2.1. 第一范式(1NF)

• 2.1.1. 确保每个实体都有一个有效的主键，每个属性都依赖于主键，而且消除冗余的分组，以确保每个属性的原子性（不能有多个值存在）​

• 2.1.2. 第一范式包括了与通常称为关联实体的附加实体的多对多关系解析

2.2. 第二范式(2NF)

• 2.2.1. 确保每个实体都有最小的主键，每个属性都依赖于完整的主键

2.3. 第三范式(3NF)

• 2.3.1. 确保每一个实体都没有隐藏的主键，每个属性都不依赖于键值之外的任何属性（仅依赖于完整的主键）​

• 2.3.2. 模型的规范化通常要求达到第三范式水平即可

2.4. Boyce/Codd范式(BCNF)

• 2.4.1. 解决了交叉的复合候选键的问题

• 2.4.2. 候选键是主键或备用键

• 2.4.3. 复合意味着不止一个（如一个实体主键有两个属性）​，交叉是指键与键之间隐藏着业务规则

2.5. 第四范式(4NF)

• 2.5.1. 将所有三元关系分解成二元关系，直到这些关系不能再分解成更小的部分

2.6. 第五范式(5NF)

• 2.6.1. 将实体内部的依赖关系分解成二元关系，所有联结依赖部分主键

2.7. 实践中BCNF、4NF、5 NF很少出现

3. 抽象化

3.1. 抽象化(Abstraction)就是将细节移除，这样可以在更广泛的情况下扩展适用性，同时保留概念或主题的重要和本质属性

3.2. 抽象包括泛化(Generalization)和特化(Specialization)

• 3.2.1. 泛化将实体的公共属性和关系分组为超类(Supertype)实体

• 3.2.2. 特化将实体中的区分属性分离为子类(Subtype)实体

  • 3.2.2.1. 这种特化通常基于实体实例中的属性值

3.3. 超类也可以使用角色或分类创建子类，将实体的实例按功能分离到组中

3.4. 子类关系意味着超类的所有属性都被子类继承

• 3.4.1. 在数据模型中，子类可以减少冗余

4. 规划数据建模交付成果

4.1. 图表(Diagram)

• 4.1.1. 一个数据模型包含若干个图表，图表是一种以精确的方式描述需求的形式

• 4.1.2. 需求可以描述不同详细程度的层级（如概念、逻辑或物理模型）​、采用的数据模型（关系、维度、对象、基于事实的、基于时间的或NoSQL）​，以及实例中采用的表示方法（如信息工程、统一建模语言、对象角色建模等）​

4.2. 定义(Definitions)

• 4.2.1. 实体、属性和关系的定义对于维护数据模型的精度至关重要

4.3. 争议和悬而未决的问题(Issues and Outstanding Questions)

• 4.3.1. 数据建模过程经常出现可能无法解决的一些争议和问题

• 4.3.2. 负责解决这些争议或回答这些问题的人员或团队通常位于数据建模团队之外

• 4.3.3. 通常数据建模工作交付的文档应包含当前的议题和未解决的问题

4.4. 血缘关系(Lineage)

• 4.4.1. 血缘关系是指数据从哪里来，经过什么样的加工，变成了什么样的结果的脉络关系

• 4.4.2. 血缘关系会以来源/目标映射的形式呈现，这样就可以了解到源系统的属性以及它们如何被迁移至目标系统

• 4.4.3. 血缘关系还可以在同一建模过程中，追踪数据模型层级

• 4.4.4. 有助于数据建模人员深入理解数据需求，准确定位属性来源

• 4.4.5. 确定属性在源系统中的情况，这是验证模型和映射关系准确性的有效工具

5. 建立数据模型

5.1. 要研究现有的数据模型和数据库

5.2. 参考已发布的建模标准和数据标准

5.3. 搜集和考虑随时提出的新的数据要求

5.4. 在此基础上建模人员设计数据模型初稿

5.5. 再与业务专家和业务分析师确认及讨论模型设计是否符合业务规则要求，同时提出修改建议

5.6. 由建模人员进行修改

5.7. 反复进行，直至没有任何问题为止

5.8. 需要通过持续改进实践来控制模型质量

5.9. 数据模型需要保持最新的状态

• 5.9.1. 需求或业务流程发生变化时，都需要对数据模型进行更新

• 5.9.2. 在结束开发迭代时，一个好的习惯是对最新的物理数据模型进行逆向工程，并确保它与相应的逻辑数据模型保持一致

• 5.9.3. 许多数据建模工具可以自动比较物理模型与逻辑模型差异

6. 正向工程

6.1. 指从需求开始构建新应用程序的过程

• 6.1.1. 需要通过建立概念模型来理解需求的范围和核心的术语

• 6.1.2. 建立逻辑模型来详细描述业务过程

• 6.1.3. 通过具体的建表语句来实现物理模型

6.2. 概念数据模型建模

• 6.2.1. 选择模型类型

  • 6.2.1.1. 从关系、维度、基于事实或者NoSQL的建模方法中选择一种来进行建模

• 6.2.2. 选择表示方法

  • 6.2.2.1. 一旦选定了建模的模式类型，接下来就该考虑采用何种建模表示方法

• 6.2.3. 完成初始概念模型

  • 6.2.3.1. 初始概念模型主要目的是获取用户的观点

  • 6.2.3.2. 不要试图将该组用户的观点与其他部门去匹配而使这个流程复杂化

• 6.2.4. 收集组织中最高级的概念（名称）

  • 6.2.4.1. 主要包括时间、地点、用户/会员、商品/服务和交易

• 6.2.5. 收集与这些概念相关的活动（动词）

  • 6.2.5.1. 关系可以是双向的，也可以涉及多个概念

• 6.2.6. 合并企业术语

  • 6.2.6.1. 一旦数据建模人员获取了某些用户的观点，接下来需要确保这些观点与企业的术语和定义相一致

• 6.2.7. 获取签署

  • 6.2.7.1. 初始模型完成后，确保对模型进行最佳实践及需求满足程度的评审

  • 6.2.7.2. 通常采用电子邮件方式发送给大家，如果看起来是准确的就足够了

6.3. 逻辑数据模型建模

• 6.3.1. 分析信息需求

  • 6.3.1.1. 为确认信息需求，需要在若干业务流程中确认业务信息需求

  • 6.3.1.2. 业务流程所要消费的信息可定义为输入，而其他业务流程的输出可定义为信息产品

  • 6.3.1.3. 不管流程还是数据都是以顺序或并发的方式进行设计

  • 6.3.1.4. 需求分析包括业务需求的引导、组织、记录、评审、完善、批准和变更控制

  • 6.3.1.5. 逻辑数据建模是表达业务数据需求的重要手段

    6.3.1.5.1. 图片胜于千言万语

  • 6.3.1.6. 书面的数据需求说明书使用需求管理工具来维护

  • 6.3.1.7. 任何此类文档的内容收集规范都应该与数据模型捕获的需求同步，以便于进行影响分析

• 6.3.2. 分析现有文档

  • 6.3.2.1. 分析现有与建模有关的档案（包括已设计的数据模型和数据库）对建模工作是一个很好的开始

  • 6.3.2.2. 即使现有的数据模型文件已过时，或与实际生产系统存在较大差异，有价值的部分也会对新模型的设计提供很大帮助

  • 6.3.2.3. 务必向相关专家确认其每个细节的准确性和时效性，以确保新模型设计的准确性

• 6.3.3. 添加关联实体

  • 6.3.3.1. 关联实体(Associative Entities)用于描述多对多关系

  • 6.3.3.2. 关联实体从关系中涉及的实体获取标识属性，并将它们放入一个新的实体中

  • 6.3.3.3. 在维度建模中，关联实体通常被称为事实表

• 6.3.4. 添加属性

  • 6.3.4.1. 将属性添加到概念实体中

  • 6.3.4.2. 逻辑数据模型中的属性具有原子性，它应该包含一个且只有一个数据（事实）​，不能被再次拆分

• 6.3.5. 指定域

  • 6.3.5.1. 域(Domains)的作用是保证模型属性中格式和数值集的一致性

• 6.3.6. 指定键

  • 6.3.6.1. 分配给实体的属性可以是键属性，也可以是非键属性

  • 6.3.6.2. 键属性有助于从所有实体实例中识别出唯一的实体实例，可以是单独一个属性成为键，也可以是与其他键元素组合的部分键

  • 6.3.6.3. 非键属性描述实体实例，但无法唯一标识该实例

  • 6.3.6.4. 需要识别主键和备用键

6.4. 物理数据建模

• 6.4.1. 逻辑数据模型需要进行修改和调整以形成物理数据模型，并使得最终的设计在存储应用程序中运行良好

• 6.4.2. 解决逻辑抽象

  • 6.4.2.1. 子类型吸收(Subtype Absorption)

    6.4.2.1.1. 子类型实体属性作为可空列，包含在表示超类型实体的表中

  • 6.4.2.2. 超类型分区(Supertype Partition)

    6.4.2.2.1. 超类型实体的属性包含在为每个子类型创建的单独表中

• 6.4.3. 添加属性细节

  • 6.4.3.1. 向物理模型添加详细信息

  • 6.4.3.2. 定义每个列或字段的物理域、物理数据类型和长度

  • 6.4.3.3. 为列或字段添加适当的约束（如允许为空和默认值）​，尤其是对于“NOT NULL”的约束

• 6.4.4. 添加参考数据对象

  • 6.4.4.1. 创建匹配的单独代码表

    6.4.4.1.1. 据模型的不同，这些代码表数量也不一样

  • 6.4.4.2. 创建主共享代码表

    6.4.4.2.1. 对于拥有大量代码表的模型，可以将所有的代码表合并到一张表中

    6.4.4.2.2. 意味着更改一个引用列表将对整个表产生影响

    6.4.4.2.3. 应该避免代码值的冲突

  • 6.4.4.3. 将规则或有效代码嵌入到相应对象的定义中

    6.4.4.3.1. 为对象嵌入的规则或列表代码创建约束，对于仅用作其他对象引用的代码列表

• 6.4.5. 指定代理键

  • 6.4.5.1. 给业务分配不可见的唯一键值，与它们匹配的数据没有任何意义或关系

  • 6.4.5.2. 这是一个可选步骤，主要取决于自然键是否够大或是复合值，以及其属性是否分配了可能随时间变化的值

• 6.4.6. 逆规范化

  • 6.4.6.1. 逆规范化或添加冗余可以极大地提高性能，远超过了重复存储和复制处理的成本

  • 6.4.6.2. 维度模型主要采用逆规范化的手段

• 6.4.7. 建立索引

  • 6.4.7.1. 索引是用于访问数据库数据的过程中优化查询（数据检索）性能的另一个选择

  • 6.4.7.2. 在许多情况下，索引可以提高查询性能

  • 6.4.7.3. 要尝试在大表上构建索引，使用最频繁引用的列（特别是键，包括主键、备用键和外键）来实现最常运行的查询

• 6.4.8. 分区

  • 6.4.8.1. 充分考虑整个数据模型（维度）的分区策略，尤其是当事实包含许多可选维度键（稀疏）时

  • 6.4.8.2. 在理想情况下，建议在日期键上进行分区

    6.4.8.2.1. 如果无法做到这一点，则需要根据分析结果和工作负载进行研究，以提出并改进后续分区模型

• 6.4.9. 创建视图

  • 6.4.9.1. 视图可用于控制对某些数据元素的访问，也可用于嵌入公共连接条件或过滤器，以实现常见对象或查询的标准化

  • 6.4.9.2. 视图本身应该是需求驱动的

    6.4.9.2.1. 需要对照逻辑数据模型和物理数据模型的开发流程来创建视图

7. 逆向工程

7.1. 逆向工程是记录现有数据库的过程

7.2. 物理数据建模通常是第一步，以了解现有系统的技术设计

7.3. 逻辑数据建模是第二步，以记录现有系统满足业务的解决方案

7.4. 概念数据建模是第三步，用于记录现有系统中的范围和关键术语