DAMA数据管理知识体系指南 - 第五章 数据建模和设计

5.1 引言

数据建模定义

数据建模师发现，分析和确定数据需求的过程，然 后采用数据模型精确形式表示和传递这些数据需求。这个过程是循环迭代的，可能包括概念，逻辑和物理模型。

5.1.1 业务驱动原因

5.1.2 目标和原则

数据建模的目标

确认和记录不同视角对数据需求的理解，从而使应用程序与当前和未来的业务需求更加紧密的结合在一起

5.1.3 基本概念

1 模型

是现实中事物的一种表征或者想要创造事物的一种模式

2 数据建模的4种主要类型

• 类别信息 ：用于对事物进行分类和分配事物类型的数据
• 资源信息 ：实施操作流程说需要资源的基本数据
• 业务事件信息 ：在操作过程中创建的数据
• 详细交易信息 ：通常通过销售系统生成。

3 模型组件

1. 实体：一个组织收集信息的载体

   1. 常用的实体类别

      1. 谁
      2. 什么
      3. 何时
      4. 何地
      5. 为什么
      6. 怎么办
      7. 度量

   2. 实体的别名

      1. 关系模型：实体
      2. 维度模型：维度，事实表
      3. 面向对像模型：类，对象
      4. 基于时间模型：中心，卫星，链接
      5. 非关系型数据库模型：文件，节点

   3. 实体的图形表达：

      1. 独立实体：矩形
      2. 非独立实体：圆角矩形

   4. 实体的定义：属于核心元数据。

      1. 高质量数据定义的三个基本特征：清晰，准确，完整。

2. 关系：关系是实体间的关联。

   1. 关系的别名

      1. 关系型模型：关系
      2. 维度模型：导航路径
      3. NoSQL非关系型数据库模型：边界，链接

   2. 关系的图形表示：线条

   3. 关系的基数：在两个实体之间的关系中，基数（Cardinality）说明了一个实体（实体实例）和其他实体参与建立关系的数量。

   4. 关系的元数：关系中涉及的实体的数目被称为关系的元数。常见的有一元关系，二元关系，三元关系。

3. 属性：一种定义，描述或度量实体某方面的性质。

   1. 属性的物理展示：表，视图，文档，图形或文件中的列，字段，标记或节点等。

   2. 属性可能包含域

   3. 属性的图形表示：通常在实体矩形内的列表中展示。

   4. 标识符：也称为键，是唯一标识实体实例的一个或多个属性的集合。

      1. 键的结构类型：单一键，组合键，复合键，代理键
      2. 键的功能类型：超建，候选键，主键，备用键。

   5. 标识关系：父实体的主键作为外检被继承到子实体主键的一部分。

   6. 非标识关系：父实体的主键仅被继承为子实体的非主外键属性。

4. 域：代表某一属性可被赋予的全部可能取值。

   1. 约束：通过附加规则对域进行限制，这些限制规则被称为约束。
   2. 域的定义方式：数据类型，数据格式，列表，范围，基于规则。

4 数据建模的方法

1. 关系建模

   1. 目的：精确地表达业务数据，消除冗余。
   2. 表达实体间关系的方法：信息工程法IE、信息建模的集成定义IDEF1X、巴克表示法（Barker）和陈氏表示法（Chen）。

2. 维度建模

   1. 目的：优化海量数据的查询和分析。
   2. 关系代表的含义：在关系模型中，关系连线表示业务规则。而在维度模型中，实体之间的连线表示用于说明业务问题的导航路径。
   3. 事实表：事实表（Fact Tables）的行对应于特定的数值型度量值。
   4. 维度表：维度表（Dimension Tables）表示业务的重要对象，并且主要包含文字描述。维度通常是高度反范式的，通常占总数据的10%左右。
   5. 维度标的3种变化类型：覆盖，新行，新列。
   6. 雪花模型：将星型模式中的平面、单表、维度结构规范为相应的组件层次结构或网络结构。
   7. 粒度：指事实表中的单行数据的含义或者描述，这是每行都有的最详细信息。定义一个事实表中的粒度是维度建模的关键步骤之一。
   8. 一致性维度：是基于整个组织考虑构建的，而不是基于某个特定的项目。由于具有一致的术语和值，这些维度在不同的维度模型中可以共享。
   9. 一致性事实：使用跨多个数据集市的标准化术语。不同的业务用户可能以不同的方式使用同一术语。

3. UML

4. 基于事实建模

   1. 对象角色建模
   2. 完全面向通讯建模

5. 基于时间的数据模型

   1. 数据拱顶：是一组支持一个或多个业务功能领域，面向细节、基于时间且唯一链接的规范化表。

   2. 数据拱顶模型的3种类型的实体：

      1. 中心表：代表业务主键
      2. 连接表：定义了中心表之间的事物集成。
      3. 卫星表：定义了中心表主键的语境信息。

   3. 锚建模:适合信息的结构和内容都随时间发生变化的情况

   4. 锚建模的四个基本概念：

      1. 锚：模拟的是实体和事件
      2. 属性：模拟了锚的特征
      3. 连接：表示了锚之间的关系
      4. 节点：用来模拟共享的属性

   5. 非关系型数据库：基于非关系技术构建的数据库的统称。4类NoSQL数据库：文档数据库、键值数据库、列数据库和图数据库。

5 数据模型级别

1. 概念数据模型

   概念数据模型（Conceptual Data Model，CDM）是用一系列相关主题域的集合来描述概要数据需求。概念数据模型仅包括给定的领域和职能中基础和关键的业务实体，同时也给出实体和实体之间关系的描述。

2. 逻辑数据模型

   逻辑数据模型（Logical Data Model，LDM）是对数据需求的详细描述，通常用于支持特定用法的语境中（如应用需求）。逻辑数据模型不受任何技术或特定实施条件的约束。逻辑数据模型通常是从概念数据模型扩展而来。

3. 物理数据模型

   物理数据模型（Physical Data Model，PDM）描述了一种详细的技术解决方案，通常以逻辑数据模型为基础，与某一类系统硬件、软件和网络工具相匹配

   规范模型

   规范模型（Canonical Model）是物理模型的一个变种，用于描述系统之间的数据移动。该模型描述了在系统之间作为数据报或消息传递的数据结构。

   视图

   视图（Views）是虚拟表，它提供了一种从多张包含或引用实际属性的表中查看数据的方法

   分区

   分区（Partitioning）是指拆分表的过程。执行分区是为了方便存档和提高检索性能。分区可以是垂直的（按列分组），也可以是水平的（按行分组）。

   逆规范化

   逆规范化（Denormalization）是将符合范式规则的逻辑数据模型经过慎重考虑后，转换成一些带冗余数据的物理表。换言之，逆规范化有意将一个属性放在多个位置。

6 规范化（重点关注第一，二，三范式）

规范化（Normalization）是运用规则将复杂的业务转化为规范的数据结构的过程。范式化的基本目标是保证每个属性只在一个位置出现，以消除冗余或冗余导致的不一致性。

1. 第一范式（1NF）。确保每个实体都有一个有效的主键，每个属性都依赖于主键，而且消除冗余的分组，以确保每个属性的原子性（不能有多个值存在）。
2. 第二范式（2NF）。确保每个实体都有最小的主键，每个属性都依赖于完整的主键。
3. 第三范式（3NF）。确保每一个实体都没有隐藏的主键，每个属性都不依赖于键值之外的任何属性（仅依赖于完整的主键）。
4. Boyce / Codd范式（BCNF）。解决了交叉的复合候选键的问题。候选键是主键或备用键。复合意味着不止一个（如一个实体主键有两个属性），交叉是指键与键之间隐藏着业务规则。
5. 第四范式（4NF）。将所有三元关系分解成二元关系，直到这些关系不能再分解成更小的部分。
6. 第五范式（5NF）。将实体内部的依赖关系分解成二元关系，所有联结依赖部分主键。

7 抽象化

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

1. 泛化 : 泛化将实体的公共属性和关系分组为超类（Supertype）实体
2. 特化：将实体中的区分属性分离为子类（Subtype）实体

5.2活动

本节介绍：

• 数据建模概念，逻辑和物理数据模型的设计步骤
• 维护审查数据模型的步骤和方法
• 正向工程和逆向工程

5.2.1 规划数据建模

定制合理的工作计划：

1. 评估组织需求
2. 确定建模标准
3. 明确数据模型存储管理等任务

数据建模交付成果：

1. 图表

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

3. 争议和悬而未决的事情。

   数据建模过程经常出现可能无法解决的一些争议和问题。此外，负责解决这些争议或回答这些问题的人员或团队通常位于数据建模团队之外。因此，通常数据建模工作交付的文档应包含当前的议题和未解决的问题。

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

5.2.2 建立数据模型

1.正向工程

正向工程是指从需求开始构建新应用程序的过程。首先需要通过建立概念模型来理解需求的范围和核心的术语；然后建立逻辑模型来详细描述业务过程；最后是通过具体的建表语句来实现物理模型

1. 概念数据模型建模步骤：

   1. 选择模型类型。比如关系模型，维度模型等
   2. 选择表示方法。比如信息工程法（IE） 或 对象角色建模（ORM）
   3. 完成初始概念模型。
   4. 收集组织中最高级的概念（名称）。这些概念主要包括时间、地点、用户/会员、商品/服务和交易。
   5. 收集与这些概念相关的活动（动词）。
   6. 合并企业术语。
   7. 获得签署。通过邮件发给大家评审

2. 逻辑数据模型建模

   逻辑数据模型补充了概念模型的需求细节。

   1. 分析信息需求

   2. 分析现有文档

   3. 添加关联实体

      • 关联实体用来描述多对多的关系。
      • 关联实体可以有两个以上的父实体。
      • 在维度建模中关联实体通常被称为事实表

   4. 添加属性：将属性添加到概念实体中。

   5. 指定域

3. 物理数据模型：

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

   1. 解决逻辑抽象

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

      • 子类型吸收（Subtype Absorption）： 子类型实体属性作为可空列，包含在表示超类型实体的表中。
      • 超类型分区（Supertype Partition）： 超类型实体的属性包含在为每个子类型创建的单独表中。

   2. 添加属性细节

   3. 添加参考数据对象，3种实现方式：

      1. 创建匹配的单独代码表
      2. 创建主共享代码表
      3. 将规则或有效代码嵌入到相应的对象定义中。

   4. 指定代理键：给业务分配不可见的唯一键值，与它们匹配的数据没有任何意义或关系。

   5. 逆规范化：通过添加冗余提高性能

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

   7. 分区

   8. 创建视图：控制某些数据元素的访问，实现查询的标准化。

2. 逆向工程

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

• 第一步：物理数据建模，了解现有系统的技术设计。
• 第二步：逻辑数据建模，记录现有系统满足业务的解决方案。
• 第三步： 概念数据建模，记录现有系统中的范围和关键术语。

5.2.3 审核数据模型

5.2.4 维护数据模型

5.3 工具

5.3.1 数据建模工具

5.3.2 数据血缘工具

5.3.3 数据分析工具

5.3.4 元数据资料库

5.3.5 数据模型模式

数据模型模式是可重复使用的模型结构，可以在很多场景下被广泛应用。

• 基本模式
• 套件模式
• 整合模式

5.3.6 行业数据模型

5.4 方法

5.4.1 命名约定的最佳实践

• 名称应该是唯一的并且具有描述性
• 逻辑名称对业务用户应该具有意义
• 物理名称必须符合DBMS允许的最大长度
• 逻辑名称不允许使用分隔符进行分割，但是物理名称通常使用下划线作为单词分隔符
• 名称不能受特定环境影响，如测试 ，开发或生产

5.4.2 数据库设计的最佳实践

在设计和构建数据库时，DBA应牢记PRISM设计原则：

1. 性能和易用性
2. 可重用性
3. 完整性
4. 安全性
5. 可维护性

5.5 数据建模和设计治理

5.5.1 数据建模和设计质量管理

1. 开发数据建模和设计标准
2. 评审数据模型以及数据库设计质量
3. 管理数据模型版本与集成

5.5.2 度量指标

数据模型计分卡

类别	总分数	模型分数	%	注释
模型多大程度上反映了业务需求	15
模型的完整性如何	15
模型与模式的匹配度是多少	10
模型的结构如何	15
模型的通用性如何	10
模型遵循命名标准情况如何	5
模型的可读性如何	5
模型的定义如何	10
模型与企业数据架构一致性如何	5
与元数据的匹配程度如何	10
总分	100

各个类别的简要描述如下：

1. 模型多大程度上反映了业务需求 ： 要确保数据模型代表需求。如果需要获取订单信息，则在评审该项指标时应检查模型中是否包含订单信息。如果需求中要求按学期和专业查看学生人数，则应检查模型中是否支持按照学期和专业查询学生人数的功能。
2. 模型的完整性如何：这里的完整性具有两个方面的要求：需求的完整性和元数据的完整性。需求的完整性意味着已经提出的每个需求都应在模型中得到满足。这意味着数据模型只包含被要求的内容而没有额外的内容。在模型设计时也需要考虑在不久的将来因业务的变化而能够很容易地向模型中追加内容，这部分设计在审查过程中也会被注意和考虑。如果建模人员在模型中设计了从未被要求的内容，那么该项目可能变得难以交付。此外，还需要考虑包含未来需求增加所引发的可能成本。元数据的完整性是指模型周围的所有描述性信息也要完整。例如，如果正在评审一个物理数据模型，希望数据格式和允许为空的定义和描述出现在数据模型上
3. 模型与模式的匹配度是多少？ ： 确保正在审查模型的具象级别（概念模型、逻辑模型或物理模型）和模式（关系、维度、NoSQL）与该类型模型的定义相匹配
4. 模型的结构如何：验证用于构建模型的设计实践，以确保最终可以从数据模型构建数据库。这包括避免一些设计问题，如在同一实体中有两个具有相同名称的属性或者在主键中有一个空属性。
5. 模型的通用性如何： 评审模型的扩展性或者抽象程度。例如，从客户位置转到更通用的位置，可以使设计更容易地处理其他类型的位置，如仓库和配送中心。
6. 模型遵循命名标准的情况如何： 确保数据模型采用正确且一致的命名标准。主要关注命名标准的结构、术语和风格。命名标准被正确地应用于实体、关系和属性上。例如，一个属性构造块选用“客户”或“产品”等属性主题。术语意味着为属性或实体被赋予专有名称。术语还包括正确的拼写和缩写要求。风格意味着外观，如大写或驼峰拼写等内容。
7. 模型的可读性如何： 确保数据模型易于阅读。这个问题并不是十大类别中最重要的，但是如果模型难以阅读，则可能无法准确地评估记分卡上其他更重要的类别。将父实体放置在其子实体上方，相关实体显示在一起，并最小化关系线长度都可以提高模型的可读性。
8. 模型的定义如何： 确保定义清晰、完整和准确。
9. 模型与企业数据架构的一致性如何： 确认数据模型中的结构能否在更加广泛和一致的环境中应用，以便在组织中可以使用一套统一的术语和模型结构。主要评审出现在数据模型中的术语和结构与组织中的相关数据模型中出现的结构是否保持一致。在理想情况下，与企业数据模型（EDM）（如果存在的话）结合使用为佳。
10. 与元数据的匹配程度如何： 确认存储在模型结构中的数据和实际数据是一致的。例如，客户姓氏（Customer Last Name）这一列中是否真的存储的是客户的姓氏数据？数据类别旨在减少这些意外，并有助于确保模型上的结构与这些结构将保存的数据相匹配。