《DAMA数据管理知识体系指南》05—第5章 数据建模和设计 知识点记录

第5章 数据建模和设计

5.1 引言

1.数据建模概要：
1）本章将描述数据模型的用途、数据建模中的基本概念和常用词汇以及数据建模的目标和原则。本章将使用一组与教育相关的数据作为案例来说明用各种数据建模的方法，并介绍它们之间的差异。
2）数据建模是发现、分析和确定数据需求的过程，用一种称为数据模型的精确形式表示和传递这些数据需求。
3）数据建模是数据管理的一个重要组成部分。
4）建模过程中要求组织发现并记录数据组合的方式。
5）在建模过程本身，设计了数据组合的方式（Simsion，2013）。
6）数据模型有助于组织能够理解其数据资产。数据可以采用多种不同的模式来表示。
7）其中最为常见的6种模式分别是：关系模式、多维模式、面向对象模式、事实模式、时间序列模式和NoSQL模式。
8）按照描述详细程度的不同，每种模式又可以分为3层模型：概念模型、逻辑模型和物理模型。
9）每种模型都包含一系列组件，如实体、关系、事实、键和属性。
10）一旦建立了模型，就需要对其进行质量审查；一旦得到批准，后续还需要对其进行维护。
11）数据模型包含数据使用者所必需的元数据。
12）在数据建模过程中发现的大部分元数据对于其他数据管理功能是必不可少的，如数据治理的定义、数据仓库与数据血缘分析等。

2.数据建模和设计的语境关系图如下图所示。

5.1.1 业务驱动因素

3.数据模型的作用：
数据模型对于有效的数据管理至关重要，如：
1）提供有关数据的通用词汇表。
2）获取、记录组织内数据和系统的详细信息。
3）在项目中作为主要的交流沟通工具。
4）提供了应用定制、整合，甚至替换的起点。

5.1.2 目标和原则

4.数据建模的目标是确认和记录不同视角对数据需求的理解，从而使应用程序与当前和未来的业务需求更加紧密地结合在一起，并为成功地完成广泛的数据应用和管理活动奠定基础，如主数据管理和数据治理计划。
良好的数据建模会降低支持成本，增加未来需求重复利用的可能性，从而降低构建新应用的成本。
数据模型是元数据的一种重要形式。
确认和记录不同视角的理解有助于：
1）格式化。数据模型是对数据结构和数据关系的简洁定义。能够评估当前或者理想情况下业务规则对数据的影响情况。格式化的定义赋予数据规范的结构，减少在访问和保存数据时发生异常的概率。通过展现数据中的结构和关系，数据模型使数据更容易被使用。
2）范围定义。数据模型可以帮助解释数据上下文的边界，以及购买的应用程序包、项目、方案或实施的现有系统。
3）知识保留记录。数据模型通过以书面的形式获取知识来保存系统或项目的企业信息。它能给未来项目提供原始记录。数据模型有助于更好地理解一个组织、一个业务方向、一个已存在的应用，也有助于理解修改现有数据结构所带来的影响。数据模型可被重复利用，可以帮助业务专业人员、项目经理、分析师、建模师和开发人员了解环境中的数据结构。正如地图绘制者学习并记录地理环境来帮助他人寻找方向，同理，建模师帮助他人理解信息蓝图（Hoberman，2009）。

5.1.3 基本概念

5.本节将介绍几类可建模的不同数据类型、数据模型的组成部分、适合于开发的数据模型类型以及在不同情况下选择不同类型的原因。这组定义非常广泛，部分原因是因为数据建模本身就是关于定义的过程。理解支持实践的词汇是很重要的。

1.数据建模和数据模型

5.数据建模和数据模型
1）数据建模最常用在系统开发与系统维护的工作环境中，也称为系统开发生命周期（SDLC）。
2）数据建模可以用于更广泛的领域（如业务和数据架构、主数据管理和数据治理计划），其直接的结果不是在数据库，而是对组织数据的理解。
3）模型是现实中事物的一种表征或者想要创造事物的一种模式。一个模型可以包含一个或多个图表。模型图可以使人们通过标准化的符号快速领会其内容。地图、组织架构图和建筑蓝图都是日常模型的例子。
4）数据模型描述了组织已经理解或者未来需要的数据。
5）数据模型包含一组带有文本标签的符号，这些符号试图以可视化方式展现数据需求并将其传递给数据建模人员，以获得一组特别的数据。这些数据大小不一，小到仅可以用于一个项目，大到可以用于整个组织。
6）模型是一种文档形式，用于记录数据需求和建模过程产生的数据定义。数据模型是用来将数据需求从业务传递到IT，以及在IT内部从分析师、建模师和架构师到数据库设计人员和开发人员的主要媒介。

2.建模的数据类型

6.在任何既定组织中适合于建模的数据类型反映了组织或项目需要数据模型的优先级。可以对下列4种主要类型的数据进行建模（Edvinsson，2013）：
1）类别信息（Category Information）。用于对事物进行分类和分配事物类型的数据。例如，按市场类别或业务部门分类的客户；按颜色、型号、大小等分类的产品；按开放或关闭分类的订单。
2）资源信息（Resource Information）。实施操作流程所需资源的基本数据。例如，产品、客户、供应商、设施、组织和账户等。在IT专业人员定义中，资源实体有时被称为参考数据。
3）业务事件信息（Business Event Information）。在操作过程中创建的数据。例如，客户订单、供应商发票、现金提取和业务会议等。在IT专业人员定义中，事件实体有时被称为交易性业务数据。
4）详细交易信息（Detail Transaction Information）。详细的交易信息通常通过销售系统（商店或在线应用）生成。它还可以通过社交媒体系统、其他互联网交互（单〈双〉击流等）和机器上的传感器产生。这些传感器可以是船只和车辆的部件、工业组件或个人设备（全球定位系统、射频识别、无线等）。这种类型的详细信息可以被聚合，用于派生其他数据，并用以分析趋势，类似于业务时间信息的使用方式。这种类型的数据（大容量或快速变化）通常被称为大数据。
这四类都属于“静态数据”。部分“动态数据”也可以建模。例如，系统的方案，包括用于消息传递和基于事件的系统的协议和方案等。

3.数据模型组件

正如将在本章后面讨论的一样，不同类型的数据模型采用不同的约定符号来表示数据。然而，大多数数据模型都包含基本相同的组件：实体、关系、属性和域。

（1）实体

7.对实体的认识
在数据建模之外的概念中，实体（Entity）的定义是有别于其他事物的一个事物。在数据建模概念里，实体是一个组织收集信息的载体。实体有时被称为组织的一组名词。一个实体可以被认为是一些基本问题的答案——谁、什么、何时、何地、为什么、怎么办或这些问题的综合（参见第4章）。
8.下表定义并给出了常用实体类别的例子（Hoberman，2009）。

1）实体的别名。

9.通用术语“实体”可以使用其他名称表示。最常见的是使用“实体类型”代表一类事物。例如，Jane是Employee类型。因此，Jane是实体，Employee是实体类型。然而，目前普遍的用法是用术语“实体”表示Employee，用“实体实例”（Entity Instance）表示Jane（表5-2）。

10. 实体实例是特定实体的具体化或取值。实体学生可能有多个学生实例，比如名字是鲍勃·琼斯、乔·杰克逊、简·史密斯等实例。实体课程可以有《数据建模基础》《高级地质学》和《17世纪英国文学》等实例。
11. 实体别名会根据模型类型（Scheme）而变化（参见后面的“数据建模的方法”）。
在关系模型中经常用到“实体”这个术语，在维度模型中经常使用“维度”和“事实表”等术语，在面向对象模型中经常使用“类”或“对象”等术语，在基于时间模型中经常使用“中心”“卫星”“链接”等术语，在非关系型数据库模型中经常使用“文件”或“节点”等术语。
12.实体别名（Entity Aliases）也会根据模型抽象程度不同而有所不同。概念模型中的实体一般被称为概念（Concept）或术语（Term），逻辑模型中的实体被称为实体（Entity）（其他称呼取决于不同模型类型）。而在物理模型中，实体的称呼根据数据库技术的不同也不一样，最常见的称呼是表（Table）。(三级层次模型的细节将在后面的“数据模型级别”中讨论。)

2）实体的图形表示。

12.实体的图形表示
在数据模型中，通常采用矩形（或带有圆边的矩形）代表实体，矩形的中间是实体的名称，如图5-2所示。图中有三个实体：学生（Student）、课程（Course）和讲师（Instructor）。

3）实体的定义。

13.实体的定义对于任何数据模型所描述的业务价值都有巨大贡献。它们属于核心元数据。高质量的定义澄清了业务词汇表的含义，并有助于精确管理实体之间关系所描述的业务规则。它们帮助业务和IT专业人员针对业务和应用程序设计做出明确的决策。
14.高质量的数据定义具备以下3个基本特征：
①清晰（Clarity）。定义应该易于阅读和理解，采用简单清晰的语言表述，没有晦涩的首字母缩写词或难于解释的歧义术语表达，如“有时”或“正常”。
②准确（Accuracy）。定义是对实体的精准和正确的描述，应由相关业务领域的专家进行审查，以确保其准确性。
③完整（Completeness）。定义要尽量全面，所包括的内容都要体现。例如，在定义代码时，要包括代码值的示例。在定义标识符时，标识符的唯一性范围应包括在定义中说明。

（2）关系

15.关系（Relationship）是实体之间的关联（Chen，1976）。关系捕获概念实体之间的高级别交互、逻辑实体之间的详细交互以及物理实体之间的约束。

1）关系的别名。

16.关系的别名：
通用术语“关系”也可以用其他名称来表示。关系的别名（Relationship Aliases）根据模型不同而变化。在关系模型中经常使用术语“关系”，在维度模型中经常使用术语“导航路径”，在NoSQL非关系型数据库模型中经常使用诸如“边界”或“链接”等术语。关系别名也可以根据模型抽象程度而有所不同。在概念和逻辑级别上的关系就被称为“关系”，但是在物理级别上的关系可能会采用其他名称表示，如“约束”或“引用”等，这主要取决于具体的数据库技术。

2）关系的图形表示。

17.关系在数据建模图上通常显示为线条。图5-3是一个用信息工程法表示关系的示例。

在这个示例中，学生（Student）和课程（Course）之间的关系描述了学生可以参加课程的规则。讲师（Instructor）和课程（Course）之间的关系描述了讲师可以教授课程的规则。线上的符号（称为基数）以精确的语法说明了规则。关系通过关系数据库中的外键来表示，在非关系型数据库中通过边界或链接来表示。

3）关系的基数。

18.关系的基数：
在两个实体之间的关系中，基数（Cardinality）说明了一个实体（实体实例）和其他实体参与建立关系的数量。基数由出现在关系线两端的符号表示。数据规则是通过基数指定来强制执行的。对于关系，如果没有基数，那么人们最多只能说两个实体以某种方式相连。
对于基数而言，只能选择0、1或多（“多”的意思是超过“1”个）。关系的每一方都可以有0、1或多的任意组合。指定0或1表示关系中是否需要实体实例。1个或多个表示给定关系中参与的实例数量。
下面以下学生（Student）和课程（Course）的例子来解释这些基数符号的含义（见图5-4）。

业务规则是：
1）每一名学生可以选择一门或多门课程。
2）每一门课程可以被一名或多名学生选择。
3）关系的元数。
19.关系中涉及实体的数目被称为关系的元数（Arity），最常见的有一元关系、二元关系以及三元关系。
①一元关系。一元关系（Unary Relationship）也被称为递归关系（Recursive Relationship）或自我引用关系（Self-referencin Relationship）。它只包含一个实体。一对多的递归关系描述了一种层级关系，而多对多的关系描述的是一种网络或图表。在层级关系中，一个实体最多拥有一个父实体（或称上级实体）。在关系模型中，子实体处于关系中的“多”的一边，而父实体处于关系中的“一”的一边。在关系网络中，一个实体可以拥有多个父实体。
例如，一门课程（Course）需要有先导课程。如果想要参加生物学研讨会，学生必须首先听完生物学讲座，生物学讲座是生物学研讨会的先决条件。在以下关系型数据模型中，使用信息工程表示法可以将这种递归关系建模为层级关系或网络关系（图5-5、图5-6）。

第一个示例（图5-5）为层级关系，第二个示例（图5-6）为网络关系。在第一个示例中，参加生物学研讨会需要首先参加生物学讲座。一旦生物学讲座被设定为生物学研讨会的先导课程，则生物学讲座不可再作为其他课程的先决条件。第二个示例则允许生物学讲座作为其他课程的先导课程。

②二元关系。涉及两个实体的关系被称为二元关系（Binary Relationship）。在二元关系的传统数据模型中，最常见的二元关系包含两个实体。图5-7是一个UML课程的图解，学生（Student）和课程（Course）构成二元关系的两个实体。

③三元关系。涉及三个实体的关系被称为三元关系（Ternary Relationship）。图5-8展示了一个基于事实（对象角色表示法）建模的例子。此例中，学生（Student）可以在特定的学期（Semester）中选择一门特定的课程（Course）。

在图5-9示例中，注册（Registration）包含两个外部键：来自学生（Student）的学号（Student Number）和来自课程（Course）的课程号（Course Code）。课程号来自于课程实体，学号来自于学生实体。外键体现在关系中的“多”的一边的实体，即子实体中。示例中的学生（Student）和课程（Course）是父实体，而注册（Registration）是子实体。

（3）属性

20.属性（Attribute）是一种定义、描述或度量实体某方面的性质。属性可能包含域，这将在后面展开讨论。实体中属性的物理展现为表、视图、文档、图形或文件中的列、字段、标记或节点等。

1）属性的图形表示。

在数据模型中，属性通常在实体矩形内的列表中描述，如图5-10所示，其中实体学生（Student）的属性包括学号（Student Number）、姓（Student First Name）、名（Student Last Name）、出生年月（Student Birth Date）。

2）标识符。

21.标识符（Identifiers）也称为键，是唯一标识实体实例的一个或多个属性的集合。本节根据键的结构（单一键、组合键、复合键、代理键）和功能（候选键、主键、备用键）进行分类。

22.①键的结构类型。
单一键（Simple Key）是唯一标识实体实例的一个属性。通用产品代码（UPC）和车辆识别号（VINS）都是单一键的例子。代理键也是一种单一键。代理键是表的唯一标识符，通常是一个计数符，由系统自动生成。代理键是一个整数，其含义与其数值无关（换句话说，代表月份的代理键数值为1不能推断其代表1月份）。代理键具有技术功能，不应对数据库的最终用户可见。它们保存在后台，以帮助保持唯一性，允许在结构间进行更高效的导航，并促进跨应用程序的集成。
组合键（Compound Key）是一组由两个或多个属性组成的集合，这些属性一起唯一地标识一个实体实例。例如，美国电话号码（区号+交换机+本地号码）和信用卡号码（申请者ID +账户号+校验数）。
复合键（Composite Key）包含一个组合键和至少一个其他单一键、组合键或非键属性。例如，多维事实表上的键，它可能包含几个复合键、单一键和可选的加载时间戳。

23.②键的功能类型。
超键（Super Key）是唯一标识实体实例的任何属性集。候选键（Candidate Key）是标识实体实例的最小属性集合，可能包含一个或多个属性（如一个单一键或复合键）。最小意味着候选键的任意子集都无法唯一标识实体实例。一个实体可以有多个候选键。电子邮件地址、手机号码和客户账号数据报是客户实体候选键的例子。候选键可以是业务键（有时称为自然键Natural Key）。业务键（Business Key）是业务专业人员用于检索单个实体实例的一个或多个属性。业务键和代理键是互斥关系。
主键（Primary Key）是被选择为实体唯一标识符的候选键。即使一个实体可能包含多个候选键，但只有一个候选键能够作为一个实体的主键。
备用键（Alternate Key）是一个候选键，虽然也是唯一的，但没有被选作为主键。备用键可用于查找特定实体实例。通常，主键是代理键，而备用键是业务键。

24.③标识关系与非标识关系。
独立实体是指其主键仅包含只属于该实体的属性。非独立实体是指其主键至少包含一个来自其他实体的属性。在关系模式中，大多数数据建模图用矩形符号表示独立实体，非独立实体则用圆角矩形表示。
在图5-11所示的学生例子中，学生（Student）和课程（Course）是独立实体，注册（Registration）则为非独立实体

非独立实体至少含有一个标识关系。标识关系是指父实体（关系图中一端实体）的主键作为外键被继承到子实体主键的一部分。正如学生（Student）和注册（Registration）之间、课程（Course）和注册（Registration）之间的关系。在非标识关系中，父实体的主键仅被继承为子实体的非主外键属性。

（4）域

25.在数据建模中，域（Domain）代表某一属性可被赋予的全部可能取值。域可以用不同的方式来表达（参见本章节末的要点）。域提供了一种将属性特征标准化的方法。例如，日期域，包含了所有可能的日期，可以适用于任何逻辑数据模型或是物理数据模型中日期属性，如：
1）聘用员工的日期。
2）收到订单的日期。
3）提交声明的日期。
4）课程开始的日期。
域中所有的值都为有效的值。不在域中的值被称为无效的值。属性中不应当含有其指定的域以外的值。例如，员工性别编码，限定只能为女性或男性的性别编码域中。聘用员工的日期域，可被简单地定义为所有有效日期。在此规则下，聘用员工日期的域不应包含每年的2月30日。
可以用附加的规则对域进行限制，这些限制规则被称为约束。规则可以涉及格式、逻辑或两者皆有。例如，通过将聘用员工日期域限制为早于今天的日期，可以从有效值域中排除2050年3月10日，即便它是一个有效日期。员工聘用日期也可以被约束在一个特定的工作日（在星期一、星期二、星期三、星期四或星期五）。

26.域可以用多种不同的方式定义。
1）数据类型（Data Type）。域中的某一属性中的数据有特定的标准类型要求。例如，整数、字符（30字节）和日期都属于数据类型域。
2）数据格式（Data Format）。使用包括模板和掩码等格式的域，如邮政编码和电话号码以及字符的限制（仅用字母数字代码，字母数字代码和某些特殊符号等），用这些格式来定义有效值。
3）列表（List）。含有有限个值的域。很多人都非常熟悉下拉列表就属于此类。例如，订单状态域的值可以限制在订单开立、发货、订单结束、退货等状态。
4）范围（Range）。允许相同数据类型的所有值在一个或多个最小值和/或最大值之间的域。有些范围可以是开放式的。例如，订单送货日期（Order Delivery Date）必须在订单下达日期（Order Date）之后的三个月之内。
5）基于规则（Rule-Based）。域内的值必须符合一定的规则才能够成为有效值。规则包括将关系或组合中的值与计算值或其他属性值进行对比。例如，物品价格必须高于物品成本。

4.数据建模的方法

27.常见的6种数据建模方法是关系建模、维度建模、面向对象建模、基于事实建模、基于时间建模和非关系型建模。每种建模方法都采用一些特定的表示法进行表达（表5-2）。

28.本节将简要介绍每一种方法及其采用的表示方法。见表5-3，某些方法仅适用于特定的技术，使用哪种方法，部分取决于打算要建立的数据库。
表5-3 数据库交叉应用模式（Scheme to Database Cross Reference）

29.在关系建模方法中，三层模型仅适用于关系型数据库，而概念模型和逻辑型模型可适用于其他数据库。基于事实的建模方法与此类似。对于维度建模方法，三层模型仅适用于关系型数据库和多维数据库。面向对象的建模方法仅适用于关系型数据库和对象数据库。
30.基于时间的建模方法属于物理数据建模技术，主要用于关系型数据库环境中的数据仓库。NoSQL方法严重依赖于底层数据库结构（文档、列、图或键值），因此也属于物理数据建模技术。表5-3展示了建模过程中的几个要点。甚至在如基于文档数据库这样的非传统数据库中，也可以在文档物理模型之后构建关系概念模型和逻辑模型。

（1）关系建模

31.关系模型
关系理论首先由Edward Codd博士在1970年提出。他提出了一种能够清晰表达含义的系统方法来组织数据，这种方法在减少数据存储冗余方面卓有成效。Edward Codd博士发现二维关系是最有效管理数据的方式。术语“关系”来源于该方法所基于的数学方法——集合理论（参见第6章）。
关系模型设计的目的是精确地表达业务数据，消除冗余。
关系模型特别适合设计操作型的系统，因为这类系统需要快速输入信息并精确地存储信息（Hay，2011）。
在关系建模中有几类不同的表示法可以用来表达实体间的关系，包括信息工程法IE、信息建模的集成定义IDEF1X、巴克表示法（Barker）和陈氏表示法（Chen）。
最常见的是信息工程法，该方法采用三叉线（俗称“鸭掌模型”）来表示基数（图5-12）。

（2）维度建模

32.**维度建模（Dimensional）**的概念起源于20世纪60年代，由Gerneral Mills和达特茅斯学院（Dartmouth College）在一次联合研究项目中提出。在维度模型中，数据组织的方式是为了优化海量数据的查询和分析。与此对应的是，操作型系统支持事务的处理，为优化单个事务快速处理而生。
维度数据模型专注于特定业务流程的业务问题，图5-12中展示的是用维度模型分析招生情况。可以根据学生所在的区域（Zone）、学校名称（School）、学期（Semester）以及学生是否接受财政资助（Financial Aid）来查看招生信息。导航可以从一个区域（Zone）上升到地区（Region）和国家（Country），从学期（Semester）上升到学年（Year），从学校名称（Name）上升到学校等级（Level）。
在这个模型中，用到了图形方法“轴表示法（Axis Notation）”来建模，对于那些不习惯阅读传统数据建模语法的人来说，“轴表示法”是一种非常有效的沟通工具。
关系和维度数据模型都基于同样的业务过程（如录取情况的例子所示）。不同点在于关系代表的含义不同。在关系模型中，关系连线表示业务规则。而在维度模型中，实体之间的连线表示用于说明业务问题的导航路径。

图5-12 维度模型的轴表示法

1）事实表。

33.在维度模型中，事实表（Fact Tables）的行对应于特定的数值型度量值。例如，金额、交易量或个数等。有些度量值是算法的结果，在这种情况下，元数据对于正确理解和使用至关重要。事实表占据了数据库的大部分空间先（90%是一个合理的经验法则），并且往往具有大量的行。

2）维度表。

34.维度表（Dimension Tables）表示业务的重要对象，并且主要包含文字描述。维度是事实表的入口点或链接，充当“查询”或“报表”约束的主要来源。维度通常是高度反范式的，通常占总数据的10%左右。
各个维度必须在每一行都有一个独一无二的标识符。维表中最主要的两种标识键是代理键和自然键。
35.维度也有一些属性，它们以不同的速率发生变化。渐变类的维度根据变化的速率和类型来管理变化。3种主要的变化类型有时被称为ORC，具体如下：
①第一类，覆盖（Overwrite）。新值覆盖旧值。
②第二类，新行（New Row）。新值写在新行中，旧行被标记为非当前值。
③第三类，新列（New Column）。一个值的多个实例列在同一行的不同列中，而一个新值意味着将系列中的值向下一点写入，以便在前面为新值留出空间。最后一个值被丢弃。

3）雪花模型。

36.雪花模型（Snowflaking）的含义是将星型模式中的平面、单表、维度结构规范为相应的组件层次结构或网络结构。

4）粒度。

37.粒度（Grain）这一概念是指事实表中的单行数据的含义或者描述，这是每行都有的最详细信息。定义一个事实表中的粒度是维度建模的关键步骤之一。例如，如果一个维度模型用于度量学生注册过程，粒度可能为学生、日期和班级。

5）一致性维度。

39.一致性维度（Conformed Dimensions）是基于整个组织考虑构建的，而不是基于某个特定的项目。由于具有一致的术语和值，这些维度在不同的维度模型中可以共享。例如，如果日期是一个一致性维度，那么为按学期计算学生申请人数而建立的维度模型，将包含与为计算毕业生而建立的维度模型具有相同的值和定义。

6）一致性事实。

40.一致性事实（Conformed Facts）使用跨多个数据集市的标准化术语。不同的业务用户可能以不同的方式使用同一术语。客户增加与毛利润增加或调整增加是否一致？开发者需要敏锐地意识到很多事物称谓一样，但在各组织中概念并不相同；或者相反，事物的称谓不一样却在各个组织中实际表达的是同一概念。

（3）UML

41.统一建模语言（UML）是一种图形风格的建模语言。UML根据数据库的不同有着不同种类的表示法（类模型）。UML规定了类（实体类型）和它们之间关系类型（Blaha，2013）。
42.图5-13体现了UML类模型的特点：
1）与ER图相似，但ER中没有操作（Operation）或方法部分。
2）在ER图中，与操作最为接近概念的是存储过程。
3）属性类型（如日期、分钟）是用程序编程语言的数据类型表示的，而不是物理数据库数据类型来表示。
4）默认值可以在符号中有选择的显示。
5）访问数据是通过类的公开接口。封装或数据隐藏是基于“局部影响”的。类和实例的维护都是通过暴露出来的操作方法进行。

图5-13 UML类模型
43.每个类包含有相关的操作或方法（也称为“类行为”）。由于类行为需要排序和计时，其只是松散地连接到业务逻辑中。在ER术语中，数据库表具有存储过程/触发器。类操作可以是：
1）公开的（Public）。完全可见。
2）内部可见的（Internally）。对子实体可见。
3）私密的（Private）。隐藏的。
相比之下，ER物理模型只提供公共访问途径；所有数据都同样暴露在进程、查询或操作当中。

（4）基于事实的建模

44.基于事实的建模（Fact-Based Modeling，FBM）方法起源于20世纪70年代末，是一种概念建模语言。这类语言通常基于Fact-Based Modeling对象的特征，以及每个对象在每个事实中所扮演的角色来描述世界。一个广泛而强大的约束系统依赖于流畅的自动语言和对具体实例的自动检查。基于事实的模型不使用属性，通过表示对象（实体和值）之间的精确关系来减少直观或专家判断的需求。使用最广的基于事实建模方法是对象角色建模（ORM），由Terry Halpin在1989年提出。

1）对象角色建模。

45.对象角色建模（Object Role Modeling，ORM或ORM2）是一种模型驱动的工程方法。**它以典型的需求信息或查询的实例开始，这些实例在用户熟悉的外部环境中呈现，然后在概念层次上用受控自然语言所表达的简单事实来描述这些实例。**受控自然语言是受限制的无歧义的自然语言版本，因此所表达的语义很容易被人理解。它也是形式化语言，因此可以自动将结构映射到较低级操作上（Halpin，2015）。
ORM模型如图5-14所示。

图5-14 ORM模型

2）完全面向通信的建模。

46.完全面向通信的建模（Fully Communication Oriented Modeling，FCO-IM）在注释和方法上与ORM相似。图5-15中的数字2是对某些事实的描述：1234号学生的名字是比尔。

（5）基于时间的数据模型（Time-Based）

47.当数据值必须按照时间顺序与特定时间值相关联时，需要用到基于时间的建模（Time-Based）。

1）数据拱顶。

48.数据拱顶（Data Vault）是一组支持一个或多个业务功能领域，面向细节、基于时间且唯一链接的规范化表。数据拱顶模型是一种混合方式，综合了第三范式（3NF，将会在后面章节中讨论）和星型模式的优点。数据拱顶模型专门为满足企业数据仓库的需求而设计的。数据拱顶模型有3种类型的实体：中心表、链接表和卫星表。数据拱顶模型设计的重点是业务的功能领域，中心表代表业务主键，链接表定义了中心表之间的事务集成，卫星表定义了中心表主键的语境信息（Linstedt，2012）。
49.如图5-16所示，学生（Student）和课程（Course）是中心表，它们代表主题中的主要概念。参加课程（Attendance）是一个链接表，其将两个中心表联系在一起。学生联络方式（Student Contact）、学生属性（Student Characteristics）和课程描述（Course Description）是几个卫星表，提供了一些关于中心概念的描述信息，可以支持不同类型的历史。

图5-16 数据拱顶模型（Data Vault）

2）锚建模。

50.锚模型（Anchor Model）适合信息的结构和内容都随时间发生变化的情况。它提供用于概念建模的图形语言，能够扩展处理临时数据。锚建模（Anchor Modeling）有4个基本的建模概念：锚、属性、连接、节点。锚模拟的是实体和事件，属性模拟了锚的特征，连接表示了锚之间的关系，节点用来模拟共享的属性。
51.如图5-17所示的锚模型，学生（Student）、课程（Course）和参加课程（Attendance）都是锚点，灰色的菱形代表连接，圆圈代表属性。

图5-17 锚模型

（6）非关系型数据库

52. 非关系型数据库（NoSQL）是基于非关系技术构建的数据库的统称。有些人认为NoSQL并不是一个很好的名称，因为它不是关于如何查询数据库（这是SQL的来源），而是关于如何存储数据的（这是关系结构的来源）。
通常有4类NoSQL数据库：文档数据库、键值数据库、列数据库和图数据库。

1）文档数据库。

文档数据库（Document Databases）通常将业务主题存储在一个称为文档的（Document）结构中，而不是将其分解为多个关系结构。例如，不是将学生（Student）、课程（Course）和注册信息（Registration）存储在3种不同的关系结构中，而是将这3种结构的属性存储在一个称为注册信息（Registration）的文档中。

2）键值数据库。

键值数据库（Key-value Databases）只在两列中存储数据（键和值），其特性是可以在值列同时存储简单（如日期、数字、代码）和复杂（未格式化的文本、视频、音乐、文档、照片）的信息。

3）列数据库。

在4种类型的NoSQL数据库中，列数据库（Column-oriented Databases）最接近关系型数据库。两者都有类似的方法，即将数据视为行和值。但不同的是，关系型数据库使用预定义的结构和简单的数据类型。例如，数量和日期。而列数据库，如Cassandra，可以使用更复杂的数据类型，包括未格式化的文本和图像。此外，列数据库将每个列存储在自己的结构中。

4）图数据库。

图数据库（Graph Databases）是为那些使用一组节点就可以很好地表示它们之间的关系的数据而设计的，这些节点之间的连接数不确定。图数据库最适用的例子是社交关系（节点是人）、交通网络（节点可以是公共汽车或火车站）或路径图（节点可以是街道十字路口或高速公路出口）。图数据库最大的功能是在图中寻找最短路径或者最近的邻居，这些功能在传统的关系型数据库中实现是极其复杂的。常见的图数据库包括Neo4 J、Allegro和Virtuoso等。

5.数据模型级别

53. 1975年，美国国家标准协会的标准规划与需求委员会（SPARC）发布了数据库管理的三重模式，它们分别是：
1）概念模式（Conceptual）。概念模式体现了正在数据库中建模企业的“真实世界”视图，代表了企业当前的“最佳模式”或“经营方式”。
2）外模式（External）。它是数据库管理系统的各个用户操作与特定需求相关企业模型的子集。这些子集称为“外模式”。
3）内模式（Internal）。数据的“机器视图”由内模式描述。该模式描述了企业信息的存储表示形式（Hay，2011）。
这3个层次通常分别在概念层次、逻辑层次和物理层次上进行细节展现。在项目中，概念数据建模和逻辑数据建模是需求规划和分析活动的一部分，而物理数据建模属于设计活动。本节概述了概念、逻辑和物理数据建模。此外，每一级都将分别采用关系模型和维度模型示例进行说明。

（1）概念数据模型

54. 概念数据模型（Conceptual Data Model，CDM）是用一系列相关主题域的集合来描述概要数据需求。概念数据模型仅包括给定的领域和职能中基础和关键的业务实体，同时也给出实体和实体之间关系的描述。例如，要对学生和学校之间的关系进行建模，采用信息工程（IE）语法描绘的关系型概念数据模型，如图5-18所示。
每所学校（School）有若干个学生（Student），每个学生只来自一所学校。此外，每个学生可提交若干个申请（Application），每一个申请只能由一个学生提交。关系线获取了关系数据模型中的业务规则。例如，学生Bob可以申请郡高中或皇后学院，但不能同时去就读这两所大学。此外，一份申请只能由一个学生提交，而不是两个或零个。
如图5-19所示，使用轴表示法的维度型概念数据模型说明了学校相关的概念。

图5-18 关系型概念数据模型

图5-19 维度型概念数据模型

（2）逻辑数据模型

55.逻辑数据模型（Logical Data Model，LDM）是对数据需求的详细描述，通常用于支持特定用法的语境中（如应用需求）。逻辑数据模型不受任何技术或特定实施条件的约束。逻辑数据模型通常是从概念数据模型扩展而来。
在关系逻辑数据模型中，通过添加属性来扩展概念数据模型。属性通过应用规范化技术被分配给实体，如图5-20所示。每个属性和它所在实体的主键之间都有非常强的关系。例如，学校名称（School Name）与学校代码（School Code）有很强的关系，学校代码的每个值最多返回一个学校名称。

**56.**在很多情况下，维度型逻辑数据模型是维度型概念数据模型的完全属性透视图，如图5-21所示。关系型逻辑数据模型捕获业务流程的规则，而维度型逻辑数据模型捕获业务问题以确定业务流程的运行状况和性能。
图5-21中的录取人数（Admissions Count）是回答与录取（Admissions）相关的业务问题的度量。围绕招生录取（Admissions）实体提供的语境来查看诸如按学期（Semester）和学年（Year）等不同粒度级别的招生人数（Admissions Count）。

图5-21 维度型逻辑数据模型

（3）物理数据模型

57. 物理数据模型（Physical Data Model，PDM）描述了一种详细的技术解决方案，通常以逻辑数据模型为基础，与某一类系统硬件、软件和网络工具相匹配。物理数据模型与特定技术相关。例如，关系型数据库管理系统应被设计成具有特定功能的数据库管理系统（如IBM DB2，UDB，Oracle，Teradata，Sybase，Microsoft SQL Server，or Microsoft Access）。
    图5-22展示了一个关系型物理数据模型。在这个数据模型中，为了适应特定的技术要求，学校已经被逆范式化到了学生实体（Student）中。当访问一个学生信息时，他的学校信息也同时被访问到了，因此，两者一起存储的结构比两个独立存储的性能更好。
    
    图5-22 关系型物理数据模型
    由于物理数据模型受实现技术约束，因此常常通过对结构进行组合（逆范式化）来提高检索性能，类似上面例子中的学生和学校。
    图5-23说明了一个维度模型的物理数据模型（通常是星型模式，意味着每个维度都有一个结构）。
    
    58.与关系模型的物理数据模型类似，该结构已从逻辑对应结构修改为使用特定技术，以确保业务问题能够以简单和快速的方式得到解决。
    1）规范模型。规范模型（Canonical Model）是物理模型的一个变种，用于描述系统之间的数据移动。该模型描述了在系统之间作为数据报或消息传递的数据结构。当通过Web服务、企业服务总线（ESB）或企业应用程序集成（EAI）发送数据时，规范模型描述了发送服务和接收服务应该使用的数据结构。这些结构的设计应尽可能通用，以实现重用和简化接口需求。
    2）视图。视图（Views）是虚拟表，它提供了一种从多张包含或引用实际属性的表中查看数据的方法。当请求视图中的一个属性时，标准视图会运行SQL来检索数据。实例化（通常称为“物化”）视图在预定的时间运行。视图用于简化查询、控制数据访问和重命名列，而不会由于逆规范化而导致引用完整性的冗余和丢失。
    3）分区。分区（Partitioning）是指拆分表的过程。执行分区是为了方便存档和提高检索性能。分区可以是垂直的（按列分组），也可以是水平的（按行分组）。
    ①垂直分割。为减少查询返回的结果集，可根据列的不同为某表创建子集。例如，将客户表分割成两张表，分别基于相对静态的字段或相对易变的字段（以提高加载/索引性能），或基于查询中常见和非常见字段（提高全表扫描性能）。
    ②水平分割。为减少查询返回的结果集，使用某列的值作为区分创建子集表。例如，创建只包含特定区域中客户的区域客户表。
    4）逆规范化。逆规范化（Denormalization）是将符合范式规则的逻辑数据模型经过慎重考虑后，转换成一些带冗余数据的物理表。换言之，逆规范化有意将一个属性放在多个位置。将数据逆规范化有很多原因，最重要的是提高性能，如：
    ①提前组合来自多个其他表的数据，以避免代价高昂的运行时连接。
    ②创建更小的、预先过滤的数据副本，以减少昂贵的运行时计算和/或大型表的扫描。
    ③预先计算和存储昂贵的数据计算结果，以避免运行时系统资源竞争。
    逆规范化还可以用于根据访问需要将数据划分为多个视图或副本表来加强用户安全性。
    逆规范化处理由于存在数据冗余而引入了产生数据错误的风险。因此，只有在使用视图或分区进行物理设计还是无法满足效率要求时，才会选择逆规范化处理。为确保正确地存储属性副本，执行数据质量检查是一个好办法。一般来说，逆规范化只会提高数据库查询性能或提升用户安全操作。
    虽然在本节中使用了“逆规范化”这个术语，但这个过程并不仅仅适用于关系数据模型。例如，可以在文档数据库中执行逆规范化，但这个过程采用了不同的术语表达，如嵌入（Embedding）。
    在维度数据建模中，逆规范化被称为折叠（Collapsing）或合并（Combining）。如果每个维度都被折叠成一个结构，生成的数据模型被称为星型模式（Star Schema）（见图5-23）。如果维度没有折叠，则生成的数据模型被称为雪花（Snowflake）（见图5-21）。

6.规范化

59.规范化（Normalization）是运用规则将复杂的业务转化为规范的数据结构的过程。范式化的基本目标是保证每个属性只在一个位置出现，以消除冗余或冗余导致的不一致性。整个过程需要深入理解每个属性，以及每个属性与主键的关系。
规范化规则根据主键和外键整理属性。规范化规则可归类到不同规范层次，对每一个层次可应用更细的方式和规范性来搜索正确的主键和外键。每个级别由一个独立的范式组成，并且每个相继级别不需要包含以前的级别。
60. 范式的层次包括：
1）第一范式（1NF）。确保每个实体都有一个有效的主键，每个属性都依赖于主键，而且消除冗余的分组，以确保每个属性的原子性（不能有多个值存在）。第一范式包括了与通常称为关联实体的附加实体的多对多关系解析。
2）第二范式（2NF）。确保每个实体都有最小的主键，每个属性都依赖于完整的主键。
3）第三范式（3NF）。确保每一个实体都没有隐藏的主键，每个属性都不依赖于键值之外的任何属性（仅依赖于完整的主键）。
4）Boyce / Codd范式（BCNF）。解决了交叉的复合候选键的问题。候选键是主键或备用键。复合意味着不止一个（如一个实体主键有两个属性），交叉是指键与键之间隐藏着业务规则。
5）第四范式（4NF）。将所有三元关系分解成二元关系，直到这些关系不能再分解成更小的部分。
6）第五范式（5NF）。将实体内部的依赖关系分解成二元关系，所有联结依赖部分主键。
模型的规范化通常要求达到第三范式水平即可。实践中BCNF、4 NF、5 NF很少出现。

7.抽象化

61. 抽象化（Abstraction）就是将细节移除，这样可以在更广泛的情况下扩展适用性，同时保留概念或主题的重要和本质属性。抽象化的一个例子是参与者/角色结构，可以用来描述人员和组织如何扮演特定的角色（如员工和客户）。并不是所有的建模人员或开发人员都熟悉或有能力处理抽象化问题。建模人员需要权衡开发和维护抽象结构的成本，以及在未来需要修改非抽象结构时所需的返工工作量（Giles，2011）。
抽象包括泛化（Generalization）和特化（Specialization）。泛化将实体的公共属性和关系分组为超类（Supertype）实体，而特化将实体中的区分属性分离为子类（Subtype）实体。这种特化通常基于实体实例中的属性值。
超类也可以使用角色或分类创建子类，将实体的实例按功能分离到组中。一个例子是参与者（Party），其中含有个人（Individual）和组织（Organization）两个子类。
子类关系意味着超类的所有属性都被子类继承。在图5-24所示的关系示例中，大学（University）和高中（High School）是学校（School）的子类。
在数据模型中，子类可以减少冗余。这也使得看起来截然不同但拥有相似之处的实体之间更容易沟通。

5.2 活动

本节将简要介绍数据建模概念、逻辑和物理数据模型的设计步骤，以及维护和审查数据模型的步骤和方法，并讨论正向工程和逆向工程。

5.2.1 规划数据建模

在数据模型设计工作开始之前，首先要制订一个合理的工作计划。
62.数据建模工作计划主要包括评估组织需求、确定建模标准、明确数据模型存储管理等任务。
63.数据建模工作交付成果包括以下4个方面内容：
1）图表（Diagram）。一个数据模型包含若干个图表，图表是一种以精确的方式描述需求的形式。需求可以描述不同详细程度的层级（如概念、逻辑或物理模型）、采用的数据模型（关系、维度、对象、基于事实的、基于时间的或NoSQL），以及实例中采用的表示方法（如信息工程、统一建模语言、对象角色建模等）。
2）定义（Definitions）。实体、属性和关系的定义对于维护数据模型的精度至关重要。
3）争议和悬而未决的问题（Issues and Outstanding Questions）。数据建模过程经常出现可能无法解决的一些争议和问题。此外，负责解决这些争议或回答这些问题的人员或团队通常位于数据建模团队之外。因此，通常数据建模工作交付的文档应包含当前的议题和未解决的问题。例如，对于一个学生模型而言，比较突出的问题可能是：如果一个学生离开学校后又返回，那么这种情况是为他分配新的学号，还是保留原来的学号？
4）血缘关系（Lineage）。对于物理模型（有时是逻辑数据模型）来说，了解数据血缘关系是非常重要的。血缘关系是指数据从哪里来，经过什么样的加工，变成了什么样的结果的脉络关系。一般而言，血缘关系会以来源/目标映射的形式呈现，这样就可以了解到源系统的属性以及它们如何被迁移至目标系统。血缘关系还可以在同一建模过程中，追踪数据模型层级。例如，从概念模型到逻辑模型。
64.血缘关系之所以在数据建模过程中很重要，有以下两个原因：一是有助于数据建模人员深入理解数据需求，准确定位属性来源；二是确定属性在源系统中的情况，这是验证模型和映射关系准确性的有效工具。

5.2.2 建立数据模型

65.为了更好地开展建模工作，建模人员前期通常需要搜集大量材料，开展大量的分析工作并了解之前的建模情况。在研究完这些内容后，才能够真正开始建模工作。数据建模是一个不断迭代的过程，具体迭代方式如图5-25所示。在建模过程中，首先要研究现有的数据模型和数据库，参考已发布的建模标准和数据标准，搜集和考虑随时提出的新的数据要求，在此基础上建模人员设计数据模型初稿；然后再与业务专家和业务分析师确认及讨论模型设计是否符合业务规则要求，同时提出修改建议；最后由建模人员进行修改。如此反复进行，直至没有任何问题为止（Hoberman，2014）。

1.正向工程

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

（1）概念数据模型建模

67.创建概念数据模型涉及以下步骤：
1）选择模型类型。从关系、维度、基于事实或者NoSQL的建模方法中选择一种来进行建模。参见前面关于模式类型的讨论以及选择每个方案的时间。
2）选择表示方法。一旦选定了建模的模式类型，接下来就该考虑采用何种建模表示方法。例如，信息工程法（IE）或对象角色建模（ORM）。选择语言通常取决于组织内的标准情况和人员的习惯等。
3）完成初始概念模型。初始概念模型主要目的是获取用户的观点。不要试图将该组用户的观点与其他部门去匹配而使这个流程复杂化。
4）收集组织中最高级的概念（名称）。这些概念主要包括时间、地点、用户/会员、商品/服务和交易。
5）收集与这些概念相关的活动（动词）。关系可以是双向的，也可以涉及多个概念。例如，顾客有多个地址（家庭、工作等）、同一空间地址有多个客户，交易涉及的客户、销售的产品、发生的时间点及位置等。
6）合并企业术语。一旦数据建模人员获取了某些用户的观点，接下来需要确保这些观点与企业的术语和定义相一致。例如，如果概念数据模型有一个名为“客户”的实体，并且企业术语中也存在相同概念的名词如“顾客”，这时就需要合并企业术语。
7）获取签署。初始模型完成后，确保对模型进行最佳实践及需求满足程度的评审。通常采用电子邮件方式发送给大家，如果看起来是准确的就足够了。

（2）逻辑数据模型建模

逻辑数据模型补充了概念模型的需求细节。
68.逻辑数据模型建模
1）分析信息需求。
为确认信息需求，需要在若干业务流程中确认业务信息需求。
业务流程所要消费的信息可定义为输入，而其他业务流程的输出可定义为信息产品。
这些信息产品的名称往往可以确定一个必需的业务词汇，而且数据建模以此为依据。
不管流程还是数据都是以顺序或并发的方式进行设计。
有效的分析和设计能够在流程和数据建模并重的前提下确保数据（名词）和流程（动词）的相对平衡。

需求分析包括业务需求的引导、组织、记录、评审、完善、批准和变更控制。
某些需求可以用于确定数据和信息的业务需求，可同时使用文字和图形来表述需求说明。
逻辑数据建模是表达业务数据需求的重要手段。对于很多人来说，喜欢图形表达方式，正如老话所说：“图片胜于千言万语”。但是，也有一些人不喜欢图形表达，而更喜欢数据建模工具所创建的表格和报表。
很多组织都有规范的管理要求，以用于指导需求说明书的起草和完善，如“系统应该……”。书面的数据需求说明书使用需求管理工具来维护。任何此类文档的内容收集规范都应该与数据模型捕获的需求同步，以便于进行影响分析。这样，就可以回答“我的数据模型的哪些部分代表或实现了哪个需求”或者“为什么这个实体在这里”。
2）分析现有文档。
通常，分析现有与建模有关的档案（包括已设计的数据模型和数据库）对建模工作是一个很好的开始。即使现有的数据模型文件已过时，或与实际生产系统存在较大差异，有价值的部分也会对新模型的设计提供很大帮助。但需要注意的是，在参考已有模型文件中的内容进行新模型设计时，务必向相关专家确认其每个细节的准确性和时效性，以确保新模型设计的准确性。企业经常使用的套装软件，如企业资源规划（ERP）系统，它们拥有自己的数据模型。在设计逻辑数据模型时，应考虑这些已有的数据模型，并在合适的情况下使用或将其映射到新的企业数据模型中。此外，还有一些有用的数据建模模式（Patterns），如一种标准的角色概念建模方法。许多行业捕获了该行业的通用模型（如零售业或制造业）可以使用，基于这些通用模型进行定制开发，以适用于特定的项目。
3）添加关联实体。
关联实体（Associative Entities）用于描述多对多关系。关联实体从关系中涉及的实体获取标识属性，并将它们放入一个新的实体中。该实体只描述实体之间的关系，并允许添加属性来描述这种关系，如有效日期和到期日期。关联实体可以有两个以上的父实体。关联实体可能成为图形数据库中的节点。在维度建模中，关联实体通常被称为事实表。
4）添加属性。
将属性添加到概念实体中。逻辑数据模型中的属性具有原子性，它应该包含一个且只有一个数据（事实），不能被再次拆分。例如，一个名为“电话号码”的概念分为几个逻辑属性，分别是电话类型代码（家庭、办公室、传真、手机等）、国家代码（美国和加拿大为1）、区号、前缀、基本电话号码和分机等。
5）指定域。
域（Domains）的作用是保证模型属性中格式和数值集的一致性。例如，学生学费金额（Student Tuition Amount）和教师薪水金额（Instructor Salary Amount）都可以为其分配金额域（Amount Domain），这是一个标准的货币域。
6）指定键。
分配给实体的属性可以是键属性，也可以是非键属性。键属性有助于从所有实体实例中识别出唯一的实体实例，可以是单独一个属性成为键，也可以是与其他键元素组合的部分键。非键属性描述实体实例，但无法唯一标识该实例。另外，还需要识别主键和备用键。

（3）物理数据建模

69.物理数据建模
逻辑数据模型需要进行修改和调整以形成物理数据模型，并使得最终的设计在存储应用程序中运行良好。例如，适应微软Access所需的更改将和适应Teradata所需的更改完全不同。接下来的介绍中，术语“表”（Table）用于表示引用表、文件和模式等含义；术语“列”（Column）用于表示引用列、字段和元素等含义；术语“行”（Row）用于表示引用行、记录或实例等含义。
1）解决逻辑抽象。
逻辑抽象实体（超类型和子类型）通过使用以下任意一种方法，在物理数据库设计中成为独立对象。
①子类型吸收（Subtype Absorption）。子类型实体属性作为可空列，包含在表示超类型实体的表中。
②超类型分区（Supertype Partition）。超类型实体的属性包含在为每个子类型创建的单独表中。
2）添加属性细节。
向物理模型添加详细信息，如每个表和列（关系数据库）、文档和字段（非关系数据库）、模式和元素（XML数据库）的技术名称。
定义每个列或字段的物理域、物理数据类型和长度。为列或字段添加适当的约束（如允许为空和默认值），尤其是对于“NOT NULL”的约束。
3）添加参考数据对象。
逻辑数据模型中参考数据的集合可以通过以下3种常见方式在物理模型中实现：
①创建匹配的单独代码表。根据模型的不同，这些代码表数量也不一样。
②创建主共享代码表。对于拥有大量代码表的模型，可以将所有的代码表合并到一张表中。但是，这意味着更改一个引用列表将对整个表产生影响。同时，应该避免代码值的冲突。
③将规则或有效代码嵌入到相应对象的定义中。为对象嵌入的规则或列表代码创建约束，对于仅用作其他对象引用的代码列表，这可能是一个很好的解决方案。
4）指定代理键。
给业务分配不可见的唯一键值，与它们匹配的数据没有任何意义或关系。这是一个可选步骤，主要取决于自然键是否够大或是复合值，以及其属性是否分配了可能随时间变化的值。
如果将代理键指定为表的主键，请确保原始主键上有备用键。例如，如果在逻辑数据模型上，学生表（Student）的主键是学生姓名（Student First Name）、学生姓氏（Student Last Name）和学生出生日期（Student Birth Date）组成的复合主键，则在物理数据模型上，学生的主键可以是代理键学生编号（Student ID）。在这种情况下，应该在学生名字、学生姓氏和学生出生日期的原始主键上定义备用键。
5）逆规范化。
在某些情况下，逆规范化或添加冗余可以极大地提高性能，远超过了重复存储和复制处理的成本。
维度模型主要采用逆规范化的手段。
6）建立索引。
索引是用于访问数据库数据的过程中优化查询（数据检索）性能的另一个选择。**在许多情况下，索引可以提高查询性能。**数据库管理员或数据库开发人员必须为数据库表选择和定义适当的索引。主要的RDBMS产品支持多种类型的索引。索引可以是唯一的或非唯一的、集群的或非集群的、分区的或非分区的、单列或多列、b树、位图或散列等多种类型。如果没有适当的索引，DBMS将读取表中的每一行（表扫描）以检索所有数据。对于大表来说，这将会耗费很多成本。要尝试在大表上构建索引，使用最频繁引用的列（特别是键，包括主键、备用键和外键）来实现最常运行的查询。
7）分区。
必须充分考虑整个数据模型（维度）的分区策略，尤其是当事实包含许多可选维度键（稀疏）时。在理想情况下，建议在日期键上进行分区；如果无法做到这一点，则需要根据分析结果和工作负载进行研究，以提出并改进后续分区模型。
8）创建视图。
视图可用于控制对某些数据元素的访问，也可用于嵌入公共连接条件或过滤器，以实现常见对象或查询的标准化。视图本身应该是需求驱动的。在许多情况下，需要对照逻辑数据模型和物理数据模型的开发流程来创建视图。

2.逆向工程

70.逆向工程是记录现有数据库的过程。物理数据建模通常是第一步，以了解现有系统的技术设计；逻辑数据建模是第二步，以记录现有系统满足业务的解决方案；概念数据建模是第三步，用于记录现有系统中的范围和关键术语。大多数数据建模工具支持各种数据库的逆向工程。但是，将模型元素进行可读性的布局展示仍需要建模人员来完成。可以选择几种常见的布局（如正交、维度和层次结构）来启动流程，但语境的组织（即按主题区域或功能对实体分组）在很大程度上仍是一个手动流程。

5.2.3 审核数据模型

和IT的其他领域一样，需要通过持续改进实践来控制模型质量。诸如价值实现时间、支持成本和数据模型质量验证器（如数据模型记分卡）（Hoberman，2009）等技术都可用于评估模型的正确性、完整性和一致性。一旦完成概念数据建模、逻辑数据建模和物理数据建模，这些模型就成为任何需要理解模型的角色（从业务分析师到开发人员）非常有用的工具。

5.2.4 维护数据模型

71.数据模型需要保持最新的状态。需求或业务流程发生变化时，都需要对数据模型进行更新。通常来说，在一个特定项目中，模型级别需要更改时，也意味着相应的更高级别的模型需要更改。例如，如果物理数据模型需要添加新的一列，则经常需要将该列作为属性添加到相应的逻辑数据模型中。在结束开发迭代时，一个好的习惯是对最新的物理数据模型进行逆向工程，并确保它与相应的逻辑数据模型保持一致。许多数据建模工具可以自动比较物理模型与逻辑模型差异。

5.3 工具

有多种类型的工具可以帮助数据建模人员完成他们的工作，包括数据建模、模型血缘、数据剖析工具和元数据资料库等。

5.3.1 数据建模工具

72.数据建模工具是自动实现数据建模功能的软件。入门级数据建模工具提供基本的绘图功能，以便用户可以轻松创建实体和关系，如数据建模托盘。这些入门级工具还支持“橡皮筋”功能，在移动实体时自动重绘关系线。更复杂的数据建模工具支持从概念模型到逻辑模型，从逻辑模型到物理模型，从物理模型到数据库结构转换的正向工程，允许生成数据库数据定义语言（DDL）。大多数还支持从数据库到概念模型的逆向工程。这些更复杂的工具通常支持诸如命名标准验证、拼写检查、存储元数据的位置（如定义和血缘）以及共享（如发布到Web）等功能。

5.3.2 数据血缘工具

73.数据血缘工具是允许捕获和维护数据模型上每个属性的源结构变化的工具。通过这些工具可实现变更影响分析，也就是说，可以使用它们来查看一个系统的变化或系统的一部分中的变化是否对另一个系统产生影响。例如，属性总销售额可能来自多个应用程序，需要计算才能填充——血缘工具将存储此信息。Microsoft Excel®是一种常用的血缘工具。虽然易于使用且相对便宜，但是Excel无法实现真正的影响分析，必须手动管理元数据。在数据建模工具、元数据资料库或数据集成工具中也经常获取数据的血缘（参见第11章和第12章）。

5.3.3 数据分析工具

74.数据分析工具可以帮助探索数据内容，根据当前的元数据进行验证、识别数据质量和现有数据工件（如逻辑和物理模型、DDL和模型描述）的缺陷。例如，如果业务部门预期员工一次只能有一个职位，而系统显示员工在同一时间段内有多个职位，则该记录将被记录为数据异常（参见第8章和第13章）。

5.3.4 元数据资料库

75.元数据资料库是一款软件工具，用于存储有关数据模型的描述性信息，包括图表和附带的文本（如定义）以及通过其他工具和流程（软件开发工具、BPM工具、系统目录等）导入的元数据。元数据资料库本身应该启用元数据集成和交换。共享元数据比存储元数据更为重要。元数据资料库必须具有便于用户访问的方式，供人们查询存储库的内容。数据建模工具通常自带一个功能有限的资料库（参见第13章）。

5.3.5 数据模型模式

76.数据模型模式是可重复使用的模型结构，可以在很多场景下被广泛应用。有组件、套件和整合数据模型模式。基本模式（Elementary Pattern）是数据建模的“螺母和螺栓”。它们包括解决多对多关系和构建自引用层次结构的方法。套件模式（Assembly Pattern）是指跨越业务人员和数据建模人员范畴的一套构建块。业务人员可以理解它们——资产、文档、人员和组织等。重要的是，这些已公布的数据模型模式主题模型套件，可以为建模设计人员提供可靠的、强健的、可扩展的和可实现的模型设计。整合模式（Integration Pattern）提供了以常见方式整合套件模式的框架（Giles，2011）。

5.3.6 行业数据模型

77.行业数据模型是为整个行业预建的数据模型，包括医疗保健、电信、保险、银行、制造业等行业。这些模型通常范围广泛且内容详细。一些行业的数据模型包含数千个实体和属性。可以通过供应商购买行业数据模型，也可以通过ARTS（零售）、SID（通信）或ACORD（保险）等行业组织获得。
任何购买的数据模型都需要进行定制以适应组织的特点，因为它是根据其他组织的需求进行设计的。所需的定制级别取决于该数据模型与组织需求的接近程度，以及最重要部分的详细程度。在某些情况下，它们可以作为工作参考，帮助建模人员制作更完整的模型。有时，它只能帮助数据建模人员节约一些公共元素的录入工作。

5.4 方法

5.4.1 命名约定的最佳实践

78.ISO11179元数据注册是一种表示组织中元数据的国际标准，包含与数据标准相关的几个部分，包括命名属性和编写定义。
数据建模和数据库设计标准是有效满足业务数据需求的指导原则，它们符合企业架构和数据架构的要求（参见第4章），以确保数据质量标准（参见第14章）。数据架构师、数据分析师和数据库管理员必须共同开发这些标准，它们之间是相互补充的关系，与IT标准没有冲突。
对每种类型建模对象和数据库对象发布数据模型和数据库命名标准。命名标准对于实体、表、属性、键、视图和索引尤为重要。名称应该是唯一的并且尽可能具有描述性。
逻辑名称对业务用户应具有意义，应尽可能使用完整的单词，并避免使用除最熟悉的缩写之外的单词。物理名称必须符合DBMS允许的最大长度，因此必要时将使用缩写。逻辑名称通常情况下不允许使用任何的分隔符对单词进行分隔，但物理名称通常使用下划线作为单词分隔符。
命名标准应该尽量减少跨环境的名称变化。名称不应受其特定环境影响，如测试、QA或生产环境。分类词（Class Word），即数量、名称和代码等属性名称中的最后一个术语，可用于从表名中区分实体和列名的属性。他们还可以显示哪些属性和列是定量的而不是定性的，这在分析这些列的内容时是非常重要的衡量标准，也是数据质量检核的重要依据。

5.4.2 数据库设计中的最佳实践

79在设计和构建数据库时，DBA应牢记以下PRISM设计原则：
1）性能和易用性（Performance and Ease of Use）。确保用户可快速、轻松地访问数据，从而最大限度地提高应用程序和数据的业务价值。
2）可重用性（Reusability）。应确保数据库结构在适当的情况下，能够被多个应用重复使用，并且可用于多种目的（如业务分析、质量改进、战略规划、客户关系管理和流程改进）。避免将数据库、数据结构或数据对象耦合到单个应用程序中。
3）完整性（Integrity）。无论语境如何，数据应始终具有有效的业务含义和价值，并且应始终反映业务的有效状态。实施尽可能接近数据的数据完整性约束，并立即检测并报告数据完整性约束的违规行为。
4）安全性（Security）。应始终及时向授权用户提供真实准确的数据，且仅限授权用户使用。必须满足所有利益相关方（包括客户、业务合作伙伴和政府监管机构）的隐私要求。强化数据安全性，就像数据完整性检查一样，执行数据的安全性约束检查，尽可能确保数据的安全性。如果检查发现存在违反数据安全性约束的情况，则立刻报告违规行为。
5）可维护性（Maintainability）。确保创建、存储、维护、使用和处置数据的成本不超过其对组织的价值，以能够产生价值的成本方式执行所有数据工作；确保尽可能快速地响应业务流程和新业务需求的变化。

5.5 数据建模和设计治理

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

80.数据分析人员和设计人员作为信息消费者（具有数据业务需求的人）和数据生产者之间的中介，他们必须平衡信息消费者的数据使用要求和数据生产者的应用要求。
数据专业人员还必须平衡短期商业利益和长期商业利益的关系。信息消费者需要及时获取数据以满足短期业务任务，并及时利用当前的商业机会。系统开发项目团队必须满足时间和预算限制。但是，他们还必须确保组织的数据驻留在安全、可恢复、可共享和可重用的数据结构中，并且这些数据尽可能正确、及时、相关和可用，从而满足所有利益相关方的长期利益。因此，数据模型和数据库设计应该是企业短期需求和长期需求之间的合理平衡。

1.开发数据建模和设计标准

如前所述，数据建模和数据库设计标准提供了满足业务数据需求、符合企业和数据架构标准以及确保数据质量的指导原则。
81.数据建模和数据库设计标准应包括以下内容：
1）标准数据建模和数据库设计可交付成果的列表和描述。
2）适用于所有数据模型对象的标准名称、可接受的缩写和非常用单词的缩写规则列表。
3）所有数据模型对象的标准命名格式列表，包括属性和分类词。
4）用于创建和维护这些可交付成果的标准方法的列表和说明。
5）数据建模和数据库设计角色和职责的列表和描述。
6）数据建模和数据库设计中捕获的所有元数据属性的列表和描述，包括业务元数据和技术元数据。例如，指导原则中可以设置数据模型为每个属性捕获数据血缘的期望。
7）元数据质量期望和要求（参见第13章）。
8）如何使用数据建模工具的指南。
9）准备和领导设计评审的指南。
10）数据模型版本控制指南。
11）禁止或需要避免的事项列表。

2.评审数据模型以及数据库设计质量

82.项目团队应对概念数据模型、逻辑数据模型和物理数据库设计进行需求评审和设计评审。审查会议的议程应包括审查启动模型（如有）的项目、对模型所做的更改、考虑和拒绝的任何其他选项以及新模型在多大程度上符合现有的建模或架构标准。
组建具有不同背景、技能、期望和意见的不同领域的专家小组对数据模型和数据库设计进行评审。在组建专家评审小组时，可能需要通过特定途径，邀请有关领域的专家参与。参与者必须能够讨论不同的观点，并最终达成小组共识，不存在任何个人冲突，因为所有参与者都有共同的目标，即推广最实用、表现最好、最可用的设计。推动会议进程的负责人主持设计审查。该负责人设计并遵循议程，确保所有必需的文档在评审会议开始前都可用且已经分发，征求所有参与者的意见，维护秩序并保持会议的顺利进行，总结评审小组的共识。在许多情况下，举办设计评审会时需要指派专门的记录员来记录讨论的要点。
如果审查没有通过，建模人员必须通过修改以解决评审小组提出的所有问题。如果存在建模人员无法自行解决的问题，应该将问题反馈给系统所有者并寻求最终解决办法。

3.管理数据模型版本与集成

83.对数据模型和其他设计规范需要谨慎的变更控制，就像需求规范和其他SDLC可交付成果一样。注意对数据模型的每次更改，需要以时间线记录变更内容。如果更改影响到了逻辑数据模型，如新的或更改了的业务数据要求，则需要数据分析师或架构师审核并批准对模型的更改。
每个变更都应该予以记录，包括：
1）为什么（Why）项目或情况需要变更。
2）变更对象（What）以及如何（How）更改，包括添加了哪些表，修改或删除了哪些列等。
3）变更批准的时间（When）以及将此变更应用于模型的时间（不一定在系统中实施更改）。
4）谁（Who）做出了变更。
5）进行变更的位置（Where）在哪些模型中。
一些数据建模工具包括了提供数据模型版本控制和集成功能的资料库。否则，在DDL导出或XML文件中保留数据模型，将它们参考应用程序代码一样签入和签出标准源代码管理系统进行管理。

5.5.2 度量指标

84.有几种方法可以测量数据模型的质量，但这些方法都需要与某个标准进行比较。下面通过一个示例介绍数据模型计分卡方法，用于衡量数据模型质量，其中提供了10个数据模型质量指标，介绍了组成计分卡的10个不同类别的指标及分值，以及10个类别指标的总体分数（Hoberman，2015）。数据模型记分卡见表5-4。
表5-4 数据模型计分卡

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