第5章数据建模和设计

思维导图

5.1 引言

最常见的6种模式：
关系模式、多维模式、面向对象模式、事实模式、时间序列模式和NoSQL模式
每种模式分为三层模型：概念模型、逻辑模型和物理模型
每种模型都包含一系列组件：如实体、关系、事实、键和属性。

5.1.1 业务驱动因素

数据模型对于有效的数据管理至关重要，如：

提供有关数据的通用词汇表。
获取、记录组织内数据和系统的详细信息。
在项目中作为主要的交流沟通工具。
提供了应用定制、整合，甚至替换的起点

5.1.2 目标和原则

确认和记录不同视角对数据需求的理解，从而使应用程序与当前和未来的业务需求更加紧密地结合在一起，并为成功地完成广泛的数据应用和管理活动奠定基础，如主数据管理和数据治理计划。良好的数据建模会降低支持成本，增加未来需求重复利用的可能性，从而降低构建新应用的成本。数据模型是元数据的一种重要形式。

确认和记录不同视觉的理解有助于：格式化、范围定义、知识保留记录

5.1.3 基本概念

1、数据建模和数据模型

数据建模可以用于更广泛的领域（如业务和数据架构、主数据管理和数据治理计划），其直接的结果不是在数据库，而是对组织数据的理解。

数据模型描述了组织已经理解或者未来需要的数据。数据模型包含一组带有文本标签的符号，这些符号试图以可视化方式展现数据需求并将其传递给数据建模人员，以获得一组特别的数据。
数据模型是用来将数据需求从业务传递到IT，以及在IT内部从分析师、建模师和架构师到数据库设计人员和开发人员的主要媒介。

2、建模的数据类型

可以对下列4种主要类型的数据进行建模；这四类都属于“静态数据”。部分“动态数据”也可以建模。例如，系统的方案，包括用于消息传递和基于事件的系统的协议和方案等。

1）类别信息（Category Information）。

用于对事物进行分类和分配事物类型的数据。例如，按市场类别或业务部门分类的客户；按颜色、型号、大小等分类的产品；按开放或关闭分类的订单。

2）资源信息（Resource Information）。

实施操作流程所需资源的基本数据。例如，产品、客户、供应商、设施、组织和账户等。在IT专业人员定义中，资源实体有时被称为参考数据。

3）业务事件信息（Business Event Information）。

在操作过程中创建的数据。例如，客户订单、供应商发票、现金提取和业务会议等。在 IT专业人员定义中，事件实体有时被称为交易性业务数据。

4）详细交易信息（Detail Transaction Information）。

详细的交易信息通常通过销售系统（商店或在线应用）生成。它还可以通过社交媒体系统、其他互联网交互（单〈双〉击流等）和机器上的传感器产生。这些传感器可以是船只和车辆的部件、工业组件或个人设备（全球定位系统、射频识别、无线等）。这种类型的详细信息可以被聚合，用于派生其他数据，并用以分析趋势，类似于业务时间信息的使用方式。这种类型的数据（大容量或快速变化）通常被称为大数据。

3、数据模型组件

大多数数据模型都包含基本相同的组件：实体、关系、属性和域。

实体

分类	定义	示例
谁（Who）	相关的人或组织。也就是谁对业务很重要？“谁”通常是泛指的一个参与方活角色。例如，客户或供应商。人员或组织可以有多个角色，也可以包含多个参与方中	员工、病人、玩家、嫌疑人客户、供应商、学生、乘客、竞争者、作者
什么（What）	为相关企业提供的产品或服务。它通常指的是组织的产出或提供的服务。也就是说，什么对企业来说最重要的？类别、类型等属性在这里非常重要。	产品、服务、原料、成品、课程、歌曲、照片、书
何时（When）	和企业相关的日历或时间间隔，即业务什么时候经营	日期、月、季度、年、学期、财政周期、分钟、出发时间
何地（Where）	企业相关地点。地点是可以指实际的地方或电子场所，即业务在哪进行	邮寄地址、分发点、网址、IP地址
为什么（Why）	企业相关的事件或交易。这些事件使得业务得以维持，即企业为什么要运行	下订单、退货、投诉、取款、存款、表扬、查询、贸易、索赔
怎么办（How）	和企业相关的事件记录。这些记录提供事件发生的证据，如记录订单事件的购买订单，即如何知道事件发生了	发货单、合同、协议、账户、购买单、超速票、装箱单、贸易确认书
度量（Measurement）	关于时间、地点和对象的计数、总和等	销售数量、项目数、付款金融、余额

实体的别名：

实体别名会根据模型类型(Scheme)而变化(参见后面的“数据建模的方法”)。在关系模型中经常用到“实体”这个术语，在维度模型中经常使用“维度”和“事实表”等术语，在面向对象模型中经常使用“类”或“对象”等术语，在基于时间模型中经常使用“中心”“卫星”“链接”等术语，在非关系型数据库模型中经常使用“文件”或“节点”等术语。

实体的图形表示

在数据模型中，通常采用矩形（或带有圆边的矩形）代表实体，矩形的中间是实体的名称，

实体的定义

清晰、准确、完整

关系

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

关系的图形表示

关系通过关系数据库中的外键来表示，在非关系型数据库中通过边界或链接来表示。

关系的基数

一元关系

递归、自我引用关系。
它只包含一个实体。一对多的递归关系描述了一种层级关系，而多对多的关系描述的是一种网络或图表。在层级关系中，一个实体最多拥有一个父实体(或称上级实体)。在关系模型中，子实体处于关系中的“多”的一边，而父实体处于关系中的“一”的一边。在关系网络中，一个实体可以拥有多个父实体。
二元关系

涉及两个实体的关系被称为二元关系
三元关系

涉及三个实体

外键

通常用在物理数据建模中表示关系，在逻辑数据建模中，有时也用这种方法表示关系。

属性

属性(Attribute)是一种定义、描述或度量实体某方面的性质。属性可能包含域。实体中属性的物理展现为表、视图、文档、图形或文件中的列、字段、标记或节点等。

属性的图形表示

标识符

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

键的结构类型
- 单一键
  
  代理键也是一种单一键。代理键是表的唯一标识符，通常是一个计数符，由系统自动生成。代理键是一个整数，其含义与其数值无关(换句话说，代表月份的代理键数值为1不能推断其代表1月份)。代理键具有技术功能，不应对数据库的最终用户可见。它们保存在后台，以帮助保持唯一性，允许在结构间进行更高效的导航，并促进跨应用程序的集成。
  
  唯一标识实体实例的一个属性
- 组合键
  
  一组由两个或多个属性组成的集合，这些属性一起唯一地标识一个实体实例
- 复合键
  
  一组由两个或多个属性组成的集合，这些属性一起唯一地标识一个实体实例
键的功能类型
- 超键/候选键
  
  候选键 (Candidate Key)是标识实体实例的最小属性集合，可能包含一个或多个属性(如一个单一键或复合键)。最小意味着候选键的任意子集都无法唯一标识实体实例。一个实体可以有多个候选键。电子邮件地址、手机号码和客户账号数据报是客户实体候选键的例子。候选键可以是业务键(有时称为自然键Natural Key)。业务键(Business Key)是业务专业人员用于检索单个实体实例的一个或多个属性。业务键和代理键是互斥关系。
  
  唯一标识实体实例的任何属性集（实体里所有唯一值的字段：主键ID，工号，身份证。。。）
- 主键
  
  被选择为实体唯一标识符的候选键。即使一个实体可能包含多个候选键，但只有一个候选键能够作为一个实体的主键。
- 备用键
  
  是一个候选键，虽然也是唯一的，但没有被选作为主键。备用键可用于查找特定实体实例。通常，主键是代理键，而备用键是业务键。（员工表里的工号，从业务上也是唯一的，但是表里还有自己设置主键ID）
标识关系和非标识关系

独立实体是指其主键仅包含只属于该实体的属性。非独立实体（组合键）是指其主键至少包含一个来自其他实体的属性。在关系模式中，大多数数据建模图用矩形符号表示独立实体，非独立实体则用圆角矩形表示。

域

在数据建模中，域(Domain)代表某一属性可被赋予的全部可能取值。域可以用不同的方式来表达(参见本章节末的要点)。域提供了一种将属性特征标准化的方法。

域中所有的值都为有效的值。
不在域中的值被称为无效的值
属性中不应当含有其指定的域以外的值
可以用附加的规则对域进行限制，这些限制规则被称为约束；规则可以涉及格式、逻辑或两者皆有

域可以用多种不同的方式定义：

数据类型、数据格式、列表、范围、基于规则

4、数据建模的方法

在关系建模方法中，三层模型仅适用于关系型数据库，而概念模型和逻辑型模型可适用于其他数据库。 基于事实的建模方法与此类似。对于维度建模方法，三层模型仅适用于关系型数据库和多维数据库。面向对象的建模方法仅适用于关系型数据库和对象数据库。

建模方法	表示法
关系	信息工程（IE）、信息建模集成定义（IDEFIX）、巴克符号（Barker Notation）、陈氏符号（Chen）
维度	维度
面向对象	统一语言建模（UML）
基于事实	对像角色建模（ORM2）、完全面向交流的信息建模（FCO-IM）
基于时间	数据拱顶建模（Data Vault）、锚建模（Anchor Modeling）
非关系型（NoSQL）	文档、列、图、键值

数据库交叉应用模式（Scheme to Database Cross Reference）
建模方法	关系型数据库	多维数据库	对象数据库	文档数据库	列式数据库	图数据库	键值数据库
关系	CDM LDM PDM	CDM LDM	CDM LDM	CDM LDM	CDM LDM	CDM LDM	CDM LDM
维度	CDM LDM PDM	CDM LDM PDM
面向对象	CDM LDM PDM		CDM LDM PDM
基于事实	CDM LDM PDM	CDM LDM	CDM LDM	CDM LDM	CDM LDM	CDM LDM	CDM LDM
基于时间	PDM
非关系型			PDM	PDM	PDM	PDM	PDM

概念数据模型（CDM）、逻辑数据模型（LDM）、物理数据模型（PDM）

关系建模

关系模型设计的目的是精确地表达业务数据，消除冗余。关系模型特别适合设计操作型的系统，因为这类系统需要快速输入信息并精确地存储信息(Hay，2011)

信息工程（IE）
信息建模集成定义（IDEFIX）
巴克符号（Barker Notation）
陈氏符号（Chen）

维度建模

维度数据模型专注于特定业务流程的业务问题
关系和维度数据模型都基于同样的业务过程(如录取情况的例子所示)。不同点在于关系代表的含义不同。在关系模型中，关系连线表示业务规则。而在维度模型中，实体之间的连线表示用于说明业务问题的导航路径。

事实表：

在维度模型中，事实表（Fact Tables）的行对应于特定的数值型度量值。例如，金额、交易量或个数等。

维度表：

维度表（Dimension Tables）表示业务的重要对象，并且主要包含文字描述。维度是事实表的入口点或链接，充当“查询”或“报表”约束的主要来源。维度通常是高度反范式的，通常占总数据的10%左右。

维度也有一些属性，它们以不同的速率发生变化。渐变类的维度根据变化的速率和类型来管理变化。3种主要的变化类型有时被称为 ORC，具体如下：

        ①第一类，覆盖（Overwrite）。新值覆盖旧值。

        ②第二类，新行（New Row）。新值写在新行中，旧行被标记为非当前值。

        ③第三类，新列（New Column）。一个值的多个实例列在同一行的不同列中，而一个新值意味着将系列中的值向下一点写入，以便在前面为新值留出空间。最后一个值被丢弃。

雪花模型：

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

粒度：

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

一致性维度：

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

一致性事实：

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

面向对象（UML）

统一建模语言(UML)是一种图形风格的建模语言。UML根据数据库的不同有着不同种类的表示法(类模型)。

基于事实的建模

对象角色建模

对象角色建模(Object Role Modeling，ORM或ORM2)是一种模型驱动的工程方法。它以典型的需求信息或查询的实例开始，这些实例在用户熟悉的外部环境中呈现，然后在概念层次上用受控自然语言所表达的简单事实来描述这些实例。受控自然语言是受限制的无歧义的自然语言版本，因此所表达的语义很容易被人理解。
完全面向通信的建模

基于时间的数据模型

数据拱顶（Data Vaule)

数据拱顶(Data Vault)是一组支持一个或多个业务功能领域，面向细节、基于时间且唯一链接的规范化表。
数据拱顶模型是一种混合方式，综合了第三范式(3NF，将会在后面章节中讨论)和星型模式的优点。数据拱顶模型专门为满足企业数据仓库的需求而设计的。数据拱顶模型有3种类型的实体:中心表、链接表和卫星表。数据拱顶模型设计的重点是业务的功能领域，中心表代表业务主键，链接表定义了中心表之间的事务集成，卫星表定义了中心表主键的语境信息(Linstedt， 2012)。
锚模型（Anchor Model）

锚模型(Anchor Model)适合信息的结构和内容都随时间发生变化的情况。它提供用于概念建模的图形语言，能够扩展处理临时数据。锚建模(Anchor Modeling)有4个基本的建模概念:锚、属性、连接、节点。锚模拟的是实体和事件，属性模拟了锚的特征，连接表示了锚之间的关系，节点用来模拟共享的属性。

非关系型数据库

文档数据库

文档数据库(Document Databases)通常将业务主题存储在一个称为文档的(Document)结构中，而不是将其分解为多个关系结构。
键值数据库

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

在4种类型的NoSQL数据库中，列数据库(Column- oriented Databases)最接近关系型数据库。
不同的是，关系型数据库使用预定义的结构和简单的数据类型。例如，数量和日期。而列数据库，如Cassandra，可以使用更复杂的数据类型，包括未格式化的文本和图像。
图数据库

图数据库最大的功能是在图中寻找最短路径或者最近的邻居，这些功能在传统的关系型数据库中实现是极其复杂的。

5、数据模型级别

概念数据模型（CDM）

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

逻辑数据模型（LDM）

是对数据需求的详细描述，通常用于支持特定用法的语境中(如应用需求)。逻辑数据模型不受任何技术或特定实施条件的约束。逻辑数据模型通常是从概念数据模型扩展而来。
模在关系逻辑数据型中，通过添加属性来扩展概念数据模型。

物理数据模型（PDM）

物理数据模型(Physical Data Model，PDM)描述了一种详细的技术解决方案，通常以逻辑数据模型为基础，与某一类系统硬件、软件和网络工具相匹配。物理数据模型与特定技术关。
由于物理数据模型受实现技术约束，因此常常通过对结构进行组合 (逆范式化)来提高检索性能，

规范模型

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

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

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

逆规范化(Denormalization)是将符合范式规则的逻辑数据模型经过慎重考虑后，转换成一些带冗余数据的物理表。换言之，逆规范化有意将一个属性放在多个位置。将数据逆规范化有很多原因，最重要的是提高性能
逆规范化还可以用于根据访问需要将数据划分为多个视图或副本表来加强用户安全性。
在维度数据建模中，逆规范化被称为折叠(Collapsing)或合并 (Combining)。如果每个维度都被折叠成一个结构，生成的数据模型被称为星型模式(Star Schema)(见图5-23)。如果维度没有折叠，则生成的数据模型被称为雪花(Snowflake)(见图5-21)。

6、规范化

第一范式(1NF)

确保每个实体都有一个有效的主键，每个属性都依赖于主键，而且消除冗余的分组，以确保每个属性的原子性 (不能有多个值存在)。第一范式包括了与通常称为关联实体的附加实体的多对多关系解析。

第二范式(2NF)

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

第三范式(3NF)

确保每一个实体都没有隐藏的主键，每个属性都不依赖于键值之外的任何属性(仅依赖于完整的主键)。

Boyce / Codd范式(BCNF)

确保每一个实体都没有隐藏的主键，每个属性都不依赖于键值之外的任何属性(仅依赖于完整的主键)。

第四范式(4NF)

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

第五范式(5NF)

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

7、抽象化

抽象化(Abstraction)就是将细节移除，这样可以在更广泛的情况下扩展适用性，同时保留概念或主题的重要和本质属性。
抽象包括泛化(Generalization)和特化(Specialization)。泛化将实体的公共属性和关系分组为超类(Supertype)实体，而特化将实体中的区分属性分离为子类(Subtype)实体。这种特化通常基于实体实例中的属性值。

5.2 活动

5.2.1 规划数据建模

数据建模工作交付成果包括以下4个方面内容：图表、定义、争议和悬而未决的问题、血缘关系

5.2.2 建立数据模型

正向工程

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

概念数据模型建模

选择模型类型。

从关系、维度、基于事实或者NoSQL的建模方法中选择一种来进行建模。参见前面关于模式类型的讨论以及选择每个方案的时间。
选择表示方法。

一旦选定了建模的模式类型，接下来就该考虑采用何种建模表示方法。例如，信息工程法（IE）或对象角色建模（ORM）。选择语言通常取决于组织内的标准情况和人员的习惯等。
完成初始概念模型。

初始概念模型主要目的是获取用户的观点。不要试图将该组用户的观点与其他部门去匹配而使这个流程复杂化。
收集组织中最高级的概念（名称）。

这些概念主要包括时间、地点、用户/会员、商品/服务和交易。
收集与这些概念相关的活动（动词）。

关系可以是双向的，也可以涉及多个概念。例如，顾客有多个地址（家庭、工作等）、同一空间地址有多个客户，交易涉及的客户、销售的产品、发生的时间点及位置等。
合并企业术语。

一旦数据建模人员获取了某些用户的观点，接下来需要确保这些观点与企业的术语和定义相一致。例如，如果概念数据模型有一个名为“客户”的实体，并且企业术语中也存在相同概念的名词如“顾客”，这时就需要合并企业术语。
获取签署。

初始模型完成后，确保对模型进行最佳实践及需求满足程度的评审。通常采用电子邮件方式发送给大家，如果看起来是准确的就足够了。

逻辑数据模型建模

分析信息需求
分析现有文档
添加关联实体
添加属性
指定域
指定键

物理数据建模

解决逻辑抽象

逻辑抽象实体（超类型和子类型）通过使用以下任意一种方法，在物理数据库设计中成为独立对象。

①子类型吸收（Subtype Absorption）。子类型实体属性作为可空列，包含在表示超类型实体的表中。

②超类型分区（Supertype Partition）。超类型实体的属性包含在为每个子类型创建的单独表中。
添加属性细节
添加参考数据对象
指定代理键
逆规范化
建立索引
分区
创建视图

逆向工程

逆向工程是记录现有数据库的过程。物理数据建模通常是第一步，以了解现有系统的技术设计;逻辑数据建模是第二步，以记录现有系统满足业务的解决方案;概念数据建模是第三步，用于记录现有系统中的范围和关键术语。

5.2.3 审核数据模型

和IT的其他领域一样，需要通过持续改进实践来控制模型质量。

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允许的最大长度，因此必要时将使用缩写。逻辑名称通常情况下不允许使用任何的分隔符对单词进行分隔，但物理名称通常使用下划线作为单词分隔符。

        命名标准应该尽量减少跨环境的名称变化。名称不应受其特定环境影响，如测试、QA或生产环境。分类词(Class Word)，即数量、名称和代码等属性名称中的最后一个术语，可用于从表名中区分实体和列名的属性。他们还可以显示哪些属性和列是定量的而不是定性的，这在分析这些列的内容时是非常重要的衡量标准，也是数据质量检核的重要依据。

ISO11179元数据注册是一种表示组织中元数据的国际标准，包含与数据标准相关的几个部分，包括命名属性和编写定义。

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

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

性能和易用性（Performance and Ease of Use）。

确保用户可快速、轻松地访问数据，从而最大限度地提高应用程序和数据的业务价值。
可重用性（Reusability）。

应确保数据库结构在适当的情况下，能够被多个应用重复使用，并且可用于多种目的（如业务分析、质量改进、战略规划、客户关系管理和流程改进）。避免将数据库、数据结构或数据对象耦合到单个应用程序中。
完整性（Integrity）。

无论语境如何，数据应始终具有有效的业务含义和价值，并且应始终反映业务的有效状态。实施尽可能接近数据的数据完整性约束，并立即检测并报告数据完整性约束的违规行为。
安全性（Security）。

应始终及时向授权用户提供真实准确的数据，且仅限授权用户使用。必须满足所有利益相关方（包括客户、业务合作伙伴和政府监管机构）的隐私要求。强化数据安全性，就像数据完整性检查一样，执行数据的安全性约束检查，尽可能确保数据的安全性。如果检查发现存在违反数据安全性约束的情况，则立刻报告违规行为。
可维护性（Maintainability）。

确保创建、存储、维护、使用和处置数据的成本不超过其对组织的价值，以能够产生价值的成本方式执行所有数据工作；确保尽可能快速地响应业务流程和新业务需求的变化。

5.5 数据建模和设计治理

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

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

标准数据建模和数据库设计可交付成果的列表和描述。
适用于所有数据模型对象的标准名称、可接受的缩写和非常用单词的缩写规则列表。
所有数据模型对象的标准命名格式列表，包括属性和分类词。
用于创建和维护这些可交付成果的标准方法的列表和说明。
数据建模和数据库设计角色和职责的列表和描述。
数据建模和数据库设计中捕获的所有元数据属性的列表和描述，包括业务元数据和技术元数据。例如，指导原则中可以设置数据模型为每个属性捕获数据血缘的期望。
元数据质量期望和要求（参见第13章）。
如何使用数据建模工具的指南。
准备和领导设计评审的指南。
数据模型版本控制指南。
禁止或需要避免的事项列表。