1 文章结构脑图

第5章 数据建模和设计 10%.png

2 基本概念

2.1 数据建模和数据模型

数据建模最常用在系统开发与系统维护的工作环境中，也称为系统开发生命周期(SDLC)。直接结果在于<font color="red">对组织数据的理解。</font><font color="green">P92</font>

<font color="red">模型是现实中事物的一种表征或者想要创造事物的一种模式。 一个模型可以包含一个或多个图表</font>。模型图可以使人们通过标准化的符号快速领会其内容。地图、组织架构图和建筑蓝图都是日常模型的例子。<font color="green">P92</font>

<font color="red">数据模型描述了组织已经理解或者未来需要的数据。数据模型包含一组带有文本标签的符号</font>，这些符号试图以可视化方式展现数据需求并将其传递给数据建模人员，以获得一组特别的数据。<font color="green">P92</font>

数据模型是用来将数据需求从业务传递到IT,以及在IT内部从分析师、建模师和架构师到数据库设计人员和开发人员的<font color="red">主要媒介</font>。<font color="green">P92</font>

2.2 建模的数据类型

建模的数据类型： 1 类别信息，对事物分类或分配事物类型的数据，如颜色、型号。2 资源信息， 实施操作流程所需的基本数据，如产品、客户。资源实体有时被称为参考数据。3 业务事件信息， 在操作过程中创建的数据，如客户订单。事件实体有时被称为交易性业务数据。4 详细交易信息，通过销售系统、传感器生成，用于分析趋势。大数据。<font color ="red">此 4 类为静态数据，部分动态数据也可建模，如系统的方案,包括用于消息传递和基于事件的系统的协议和方案等。 </font>

2.3 数据模型组件

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

实体 Entity： 在数据建模之外，有别于其他事物的一个事物。在数据建模里，实体是一个组织收集信息的载体。一个实体被认为一些基本问题的答案：谁、什 么、何时、何地地、为什么、怎么办、度量。
一般用矩形代表，矩形中间是实体名称。
实体实例： <font color ="red">实体实例是特定实体的具体化或取值</font>。实体别名因模型类型不同而不同。关系模型用“实体”，维度模型用“维度”和“事实表”，面向对象类型使用“类”或“对象”;基本时间模型 用“中心”、“卫星”、“链接”，关系型使用“文件”、“节点”。实体别名在概念模型中称 “概念”、“术语”。逻辑模型中称为“实体”。物理模型中称为“表”。
实体的定义属于核心元数据。高质量的数据定义具有清晰、准确、完整三个特征。<font color="green">P93-95</font>

关系(Relationship)： 是<font color="red">实体之间的关联</font>。关系捕获概念实体之间的<font color="red">高级别交互</font>、逻辑实体之间的<font color="red">详细交互</font>、物理实体之间的<font color="red">约束</font>。<font color="green">P95</font>
关系别名：关系在维度模型中使用“<font color="red">导航路径</font>”，在 NoSQL 中使用“<font color="red">边界</font>”、“<font color="red">链接</font>”。在概念和逻辑级别上用“<font color="red">关系</font>”，在物理上使用“<font color="red">约束</font>“、”<font color="red">引用</font>“。<font color="green">P95</font>
关系在数据建模图上表现为<font color="red">线条</font>。<font color="green">P95</font>
关系的基数： 表明一个实体与其他实体参与建立关系的数量。有“0、1、多”。
关系的元数： 关系中涉及实体的数目。有一元关系、二元关系、三元关系。一元关系：递归关系、 自我引用关系。一对多：层级关系。多对多： 网络关系或图表。二元关系： 涉及两个实 体的关系。三元关系： 涉及三个实体的关系。<font color="green">P96</font> 见下图5-3
外键 Foreign Key： 在物理模型建模中表示关系。<font color="green">P96-97</font>

属性 Attribute： 定义、描述或度量实体某个方面的性质。属性可能包含域。<font color="red">实体中属性的物理展现为表、视图、文档、图形或文件中的列、字段、标 记或节点等</font> 。
属性在图中是在实体矩形内用列表描述。<font color="green">P97</font>
标识符 Identifiers：，也称为键，是唯一标识实体实例的一个或多个属性的集合。<font color="red">可按键结构分为单一键、 组合键、复合键、代理键，按功能分为候选键、主键、备用键</font>。<font color="green">P97</font>
键的结构类型： <font color="red">单一键：</font>唯一标识实体实例的一个属性，例如，通用产品代码(UPC)和车辆识别号(VINS)。<font color="red">代理键：</font>也是单一键，表的唯一标识符， 通常是一个计数符，由系统自动生成，一个整数，含义与数值无关，技术性，不应对用户可见。 <font color="red">组合键：</font>一组由两个或多个属性组成的集合，一起达到唯一标识一个实体实例，例如，美国电话号码(区号+交换机+本地号码)和信用卡号码(申请者ID +账户号+校验数)。 <font color="red">复合键：</font> 包含一 个组织键和至少一个其他单一键、组合键或非键属性。例如，多维事实表上的键,它可能包含几个复合键、单一键和可选的加载时间戳 <font color="green">P97</font>
键的功能类型： <font color="red">超键：</font>唯一标识实体实例的任何属性集。<font color="red">候选键：</font>标识实体实例的最小属性集合， 可能包含一个或多个属性。最小意味着候选键的任意子集都无法唯一标识实体实例。一个实体可以有多个候选键。候选键可以是业务键(自然键)。<font color="red">业务键：</font>业务专业人员用于检索 单个实体实例的一个或多个属性。业务键和代理键是互斥关系。<font color="red">主键：</font>被选择为实体唯一标识符的候选键。 <font color="red">备用键：</font>是一个候选键，虽唯一，但没有被选为主键，可用于查找特定实体实例。<font color="green">P97-98</font>
独立实体： 其主键仅包含只属于该实体的属性，用矩形符号表示。非独立实体： 指其主键于少包 含一个其它实体的属性，至少含有一个标识关系用圆角矩形表示。<font color="green">P98</font>
标识关系是指父实体(关系图中一端实体)的主键作为外键被继承到子实体主键的一部分。在非标识关系中,父实体的主键仅被继承为子实体的非主外键属性。<font color="green">P98</font>

域 Domain： 某一属性可被赋予的全部可能取值。提供一种将属性特征标准化的方法。
<font color="red">域中所有的值都为有效的值。不在域中的值被称为无效的值。属性中不应当含有其指定的域以外的值。</font>
可以附加的规则对域进行限制，限制规则称为约束。域可以使用多种不同的方式定义，如** 1.数据类型(Data Type) 2.数据格式(Data Format) 3.列表(List) 4.范围(Range) 5.基于规则(Rule-Based)**。 <font color="green">P98-99</font>

2.4 数据建模的方法

常见的 6 种数据建模方法是关系建模、维度建模、面向对象建模、基于事实建模、基于时间建模 和非关系型建模。每种建模方法都采用一些特定的表示法进行表达。
<font color="red">在关系建模方法中，三层模型仅适用于关系型数据库，而概念模型和逻辑型模型可适用于其他数据库</font>。基于事实的建模方法与此类似。对于维度建模方法，三层模型仅适用于关系型数据库和多维数据库。面向对象的建模方法仅适用于关系型数据库和对象数据库。基于时间的建模方法属于物理数据建模技术，<font color="red">主要用于关系型数据库环境中的数据仓库</font>。NoSQL 方法严重依赖于底层数据库结构(文档、列、图或 键值)，因此也属于物理数据建模技术。<font color="green">P99-100</font> 见下表5-6

关系模型设计的目的： 是<font color="red">精确的表达业务数据，消除冗余</font>。关系模型特别适合设计操作型的系统。在关系建模中有几类不同的表示法可以 用来表达实体间的关系，包括<font color="red">信息工程法 IE、信息建模的集成定义 IDEF1X、巴克表示法(Barker) 和陈氏表示法(Chen)</font>。常见是信息工程法，采用三叉线(鸭掌模型)来表示基数。<font color="green">P101</font>

维度建模 为了<font color="red">优化海量数据的查询和分析</font>。维度数据模型专注于特定业务流程的业务问题。使用轴表示法( Axis Notation) 来建模。此模型中实体之间的连线表示用于说明业务问题的导航路径。<font color="green">P101</font>
事实表： 事实表中的行对应于特定的数值型度量值，如金额。事实表占据了数据中大部分空间， 且有大量的行。<font color="green">P101</font>
维度表： 表示业务的重要对象，主要留住文字描述。<font color="red">维度是事实表的入口点或链接</font>。充当查询或 报表约束的主要来源。高度反范式的，占总数的 10%左右。<font color="red">各个维度在每一行都有一个唯一的标识符，主要是代理键和自然键</font>。维度也有些属性。渐变类的维度根据变化的速率和类型来管理变化，主要变化有<font color="red">覆盖、新行、新列</font>。<font color="green">P101-102</font>
雪花模型 Snowflaking： 将星型模型中的平面、单表、维度结构规范为相应的组件层次结构或网 络结构。<font color="green">P102</font>
粒度： 事实表中单行数据的含义或描述，是每行都有的最详细信息。关键步骤之一。<font color="green">P102</font>
一致性维度： 基于整个组织。一致性事实:使用跨多个数据集市的标准化术语。<font color="green">P102</font>

UML： 统一建模语言。<font color="green">P103</font>

基于事实的建模： 基于事实的模型不使用属性,通过表示对象(实体和值) 之间的精确关系来减少直观或专家判断的需求。对象角色建模ORM 、ORM2。完全面向通信的建模FCO-IM。<font color="green">P104</font>
对象角色建模： 它以典型的需求信息或查询的实例开始,这些实例在用户熟悉的外部环境中呈现,然后在概念层次上用受控自然语言所表达的简单事实来描述这些实例。见下图5-8

基于时间的数据模型： 当数据值必须按照时间顺序与特定时间值相关联时,需要用到基于时间的建模。
数据拱顶： 是一组支持一个或多个业务功能领域，面向细节、基于时间且唯一链接的规范化表。 数据拱顶模型是一种混合方式，<font color="red">综合了第三范式(3NF)和星型模式的优点</font>。数据拱顶模型专门 为满足企业数据仓库的需求而设计的。<font color="red">有 3 种类型的实体:中心表、链接表、卫星表。设计的重点是业务的功能领域，中心表代表业务主键，链接表定义了中心表之间的事务集成，卫星表定义了中心表主键的语境信息</font>。<font color="green">P104-105</font> 见下图5-9
锚建模： 适合信息结构和内容随时间发生变化的情况。提供用于概念建模的图形语言，能扩展处 理临时数据。它有锚、属性、连接、节点四个基本建模概念。锚模拟的是实体和事件。属性模拟 了锚的特征。连接表示了锚之间的关系。节点模拟共享的属性。<font color="green">P105</font>

非关系型数据库 NoSQL： 1)文档数据库。2)键值数据库。只有两列中存储。3)列数据库。最接近关系型数据库。可使用更复杂的数据类型，如未格式化的文本和图像。它将列存储在自己的结构 中。4)图数据库。<font color="green">P105-106</font>

2.5 数据模型级别

数据模型级别： <font color="red">1 概念模型</font>。企业的“真实世界”视图，代表企业当前的最佳模式或经营方式。 <font color="red">2 外模式。3 内模式</font>。数据的机器视图。<font color="green">P106</font>

概念数据模型 CDM： 用一系列相关主题域的集合来描述概要数据需求。概念数据模型仅包括给定的领域和职能中基础和关键的业务实体，同时也给出实体和实体之间关系的描述。<font color="green">P106-107</font> 见下图5-11

逻辑数据模型 LDM： 对数据需求的详细描述，通常用于支持特定用法的语境中(如应用需求)。 不受任何技术或特定实施条件的给。在<font color="red">关系逻辑数据模型</font>中，通过<font color="red">添加属性来扩展</font>。属性通过规范化技术被分配给实体。每个属性和它所在实体的主键之间都有非常强的关系。在很多情况下， <font color="red">维度型逻辑数据模型</font>是维度型概念数据模型的<font color="red">完全属性透视图</font>。关系型逻辑数据模型捕获业务流程的规则，而维度型逻辑数据模型捕获业务问题以确定业务流程的运行状况和性能。<font color="green">P107</font> 见下图5-12 图5-13

物理数据模型 PDM： 描述一种详细的技术解决方案，通常以逻辑模型为基础，与某一类硬件、 软件和网络工具相匹配，与特定的技术有关。1)规范模型。物理模型的一个变种，用于描述系统 之间的数据移动。该模型描述了在系统之间作为数据报或消息传递的数据结构。通用以实现重用 和简化接口需求。2)视图。虚拟表，提供了一种从多张包含或引用实际属性的表中查看数据的 方法。3)分区。拆分表的过程。执行分区是为了方便存档和提高检索 性能。分区可以是垂直(按 列分组)或水平(按行分组)4)逆规范化。<font color="green">P109-110</font> 见下图5-14
逆规范化： 将符合范式规则的逻辑数据模型经过慎重考虑后，转换成一些带冗余数据的物理表。 逆规范化处理由于存在数据冗余而引入了产生数据错误的风险。一般逆规范化只会提高数据库 查询性能或提升用户安全操作。原因： 1提前组合来自多个其他表的数据，以避免代价高昂的运 行时连接。2创建更小的、预先过滤的数据副本，以减少昂贵的运行时计算和/或大型表的扫描。 3预先计算和存储昂贵的数据计算结果，以避免运行时系统资源竞争。<font color="green">P110</font>
在维度建模中，常称为折叠、合并。如果每个维度都被折叠为一个结构，生成的数据模型称为星型模型，如果维度没有被折叠，则生成的模型为雪花模型。<font color="green">P110</font>

2.6 规范化

规范化(Normalization)： 是运用规则将复杂的业务转化为规范的数据结构的过程。目标是保证 每个属性只在一个位置出现，以消除冗余或冗余导致的不一致性。规范化规则根据主键和外键整 理属性。规范化规则可归类到不同规范层次，对每一个层次可应用更细的方式和规范性来搜索正 确的主键和外键。每个级别由一个独立的范式组成，并且每个相继级别不需要包含以前的级别。 通常要求达到第三范式即可。平时 BCNF、4NF、5NF 少见。<font color="green">P110-111</font>
第一范式 1NF： 每个实体<font color="red">都有一个有效的主键</font>，每个属性都依赖于主键。
第二范式 2NF： 每个实体<font color="red">都有最小的主键</font>，每个属性都依赖于完整的主键。
第三范式 3NF： 每一实体<font color="red">都没有隐藏的主键</font>，属性都不依赖于键值外的任何属性(仅依赖于 完整的主键)。<font color="red">模型的规范化通常要求达到第三范式</font>。
Boyce/Codd 范式(BCNF)： 解决交叉的复合候选键问题。候选键是主键或备用键。
第四范式 4NF： 将所有三元关系分解为二元关系，直到这些关系不可再分。
第五范式 5NF： 将实体内部的依赖关系分解为二元关系，所有联结依赖部分主键。

2.7 抽象化

抽象化： 将细节移除，在更大情况下扩展适用性，同时保留概念或主题的本质属性。<font color="red">1 泛化(Generalization)</font>:将实体公共属性和关系分组为超类实体。<font color="red">2 特化(Specialization)</font>:将实体中的分区属性分类为子类实体，通常基于 实体实例中的属性值。超类也可以使用角色或分类创建子类，将实体的实例按功能分离到组中。 子类关系意味着超类的所有属性都被子类继承，可以减少冗余。<font color="green">P111</font>

3 语境关系图

3.1 定义

数据建模的定义： 发现、分析和确定数据需求的过程，用一种称为数据模型的精确形式表示和传 递这些数据需求。过程是循环迭代的，可能包括概念、逻辑和物理模型。<font color="green">P90</font>

常见 6 种数据模型： <font color="red">关系模式。多维模式。面向对象模式。事实模式。时间序列模式。NoSQL 模式。</font>
根据描述详细程度不同，可分为： <font color="red">概念模型。逻辑模型。物理模型。</font><font color="green">P90</font>

3.2 目标

数据建模和设计的目标： 确认并记录对数据需求的理解，确保应用程序更符合当前和未 来的业务需求，为更多数据应用或数据管理 ，例如主数据管理和数据治理项目。<font color="green">P91</font>

<font color="red">数据模型是元数据的一种重要形式。</font><font color="green">P91</font>

不同视角理解数据有助于： <font color="red">1 格式化</font>。简洁定义，规范结构，防止异常。<font color="red">2 范围定义</font>。帮助解释数据上下文的边界。<font color="red">3 知识保留记录</font>。为未来提供原始记录，助于更好的理解组织等，助于理解变更带来的影响。可被重复利用，帮助了解环境中的数据结构。建模师帮助他人理解信息蓝图。<font color="green">P91-92</font>

3.3 业务驱动因素

业务驱动因素： 1)提供有关数据的<font color="red">通用词汇表</font>。2)获取、记录组织内<font color="red">数据和系统的详细信息</font>。 3)在项目中作为主要的<font color="red">交流沟通工具</font>。4)提供了应用定制、整合，甚至替换的<font color="red">起点</font>。<font color="green">P90</font>

3.4 输入

输入： 现有的数据模型和数据库。数据标准。数据集。初始数据需求。原始数据需求。数据架构。 企业分类法。交付成果:概念、逻辑、物理数据模型。<font color="green">P91</font>

3.5 活动

数据建模和设计活动： 1 规划数据建模。2 建立数据模型(创建概念、逻辑、物理模型)。3 审核数据模型。4 维护数据模型。<font color="green">P91</font>

3.5.1 规划数据模型

规划数据建模。应先有合理计划，包括评估组织需求、确定建模标准、明确数据模型存储管理等任务。
交付物 <font color="red">1.图表</font>。一个数据模型包含若干个图表。<font color="red">2.定义</font>。实体、属性和关系 的定义对于维护数据模型的精度至关重要。<font color="red">3.争议和悬而未决的问题。4.血缘关系：</font>对于物理模 型来说，了解数据血缘关系是非常重要的。通常以来源、目标映射形式呈现。
血缘关系重要的原因： <font color="red">一是有助于建模人员深入理解数据需求，准确定位属性来源;二是确定属性在源系统中的情况， 这是验证模型和映射关系准确性的有效工具。</font><font color="green">P112</font>

3.5.2 建立数据模型

建立数据模型： 正向工程。逆向工程。数据建模是一个不断迭代的过程。<font color="green">P113</font>

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

概念数据模型建模： <font color="red">1 选择模型类型。2 选择表示方法</font>。如信息工程 法(IE)或对象角色建模(ORM)。<font color="red">3 完成初始概念模型</font>。主要目的是获取用户的观点。<font color="red">4 收集 组织中最高级的概念(名称)。5 收集与这些概念有关的活动(动词)</font>。关系可以是双向，也可 以涉及多个概念。<font color="red">6 合并企业术语。7 获取签署</font>。确保对模型进行最佳实践及需求满足度的评审。<font color="green">P113</font>

逻辑数据模型建模： <font color="red">1 分析信息需求</font>。需求分析包括业务需求的引 导/组织/记录/评审/完善/批准和变更控制。逻辑数据建模是表达业务数据需求的重要手段。 <font color="red">2 分析现有文档</font>。即使文档过时也有帮助。应考虑已有的数据模型。 <font color="red">3 添加关联实体</font>。用于描述多对 多的关系。关联实体可以有 2 个以上的父实体。在维度建模中，关联实体通常称为事实表。 <font color="red">4 添加属性</font>。逻辑模型中属性有原子性，它应有一个且只有一个数据(事实)，不能再拆分。 <font color="red">5 指定域</font>。作用是保证模型属性中格式和数值集的一致性。 <font color="red">6 指定键</font>。分配给实体的属性可以是键属性， 也可以是非键属性。还需要识别主键和备用键。<font color="green">P114-115</font>

物理数据模型建模： <font color="red">1.解决逻辑抽象</font>【子类型吸收:子类型实体属性 作为可空列，包含在表示超类型实体的表中。超类型分区:超类型实体属性包含在为每个子类型 创建的单独表中。】<font color="red">2.添加属性细节</font>。向物理模型添加详细信息，如表和列/文档和字段等的技术 名称。定义每个列或字段 的物理域、物理数据类型和长度。添加约束。<font color="red">3.添加参考数据对象</font>。A. 创建匹配的单独代码表。B.创建主共享代码表。C.将规则或有效代码嵌入到相应对象的定义中。 <font color="red">4.指定代理键</font>。给业务分配不可见的唯一键值，与它们匹配的数据没有任意意义或关系。可选。 如果将代理键指定为表的主键，要确保原始主键上有备用键。<font color="red">5.逆规范化</font>。有时逆规范化或添加冗余可以极大地提高性能，远超过了重复存储和复制处理的成本。维度模型主要采用逆规范化的 手段。<font color="red">6.建立索引</font>。提高查询性能。使用最频繁引用的列来实现。<font color="red">7.分区</font>。理想情况下，建议在 日期键上分区，如不行则需要根据分析结果 和工作负载来提出改进。<font color="red">8.创建视图</font>。可用于控制 对某些数据元素的访问，也可用于嵌入公共连接条件或过滤器，实现觉对象或查询的标准化。视 图本身应是需求驱动。<font color="green">P115-116</font>

逆向工程： 记录现有数据库的过程。物理数据建模通常是第一步，以了解现有系统的技术设计; 逻辑数据建模是第二步，以记录现有系统满足业务的解决方案;概念数据建模是第三步，用于记 录现有系统中的范围和关键术语。大多数数据建模工具支持各种数据库的逆向工程。<font color="green">P116</font>

审核数据模型： 用价值实现时间。支持成本。数据模型质量验证器(数据模型记分卡) 等技术用于评估模型的正确性、完整性、一致性。<font color="green">P117</font>

维护数据模型： 需要保持最新状态。一个好的习惯是对最新的物理数据模型进行逆向 工程，并确保它与逻辑模型一致。<font color="green">P117</font>

3.6 交付成果

3.7 技术驱动因素

3.8 方法

<font color="red">命令约定的最佳实践： </font>对每种类型建模对象和数据库对象发布数据模型和数据库命名 标准。命名标准对于实体、表、属性、键、视图和索引尤为重要。名称应该是<font color="red">唯一的并且尽可能具有描述性</font>。逻辑名称对业务用户应具有意义，应尽可能使用<font color="red">完整的单词</font>，避免使用不熟悉的缩写。物理名称符合 DBMS <font color="red">允许的长度，必要时使用缩写</font>。逻辑名称通常不允许使用<font color="red">任何的分隔符。物理名称可使用下划线作为单词分隔符</font>。命名标准应该尽量<font color="red">减少跨环境的名称变化</font>。名称不 应受其特定环境影响，如测试、QA 或生产环境。分类词(Class Word)，即数量、名称和代码 等属性名称中的最后一个术语，可用于从表名中区分实体和列名的属性。<font color="green">P119</font>

<font color="red">数据库设计中的最佳实践-PRISM 设计原则： </font> 1 性能和易用性。2 可重用性。多应用重复使用，并可用于多目的。3 完整性。数据应始终具有有效的业务含义和价值，始终反映业务的有效状态。4 安全性。始终向授予用户提供真实准确的数据，且仅限授权用户使用。5 可维护性。维护成本不超过其对组织的价值;尽可能快速响应业务流程和新业务需要变化。<font color="green">P119-120</font>

3.9 工具

数据建模工具： 自动实现数据建模功能的软件。<font color="green">P117</font>

数据血缘工具： <font color="red">是允许捕获和维护数据模型上每个属性的源结构变化的工具。可以实现变更影响分析。<font color="green">P117</font>

数据分析工具： 可以帮助探索数据内容，根据当前的元数据进行验证、识别数据质量和现有数据工件(如逻辑和物理模型、DDL 和模型描述)的缺陷。<font color="green">P118</font>

元数据资料库： 软件工具。用于存储有关数据模型的描述性信息，包括图表和附带的 文本(如定义)以及通过其他工具和流程(软件开发工具、BPM 工具、系统目录等)导入的元数 据。元数据资料库本身应该启用元数据集成和交换。共享元数据比存储元数据更为重要。<font color="green">P118</font>

数据模型模式： 数据模型模式是可重复使用的模型结构，有组件、套件和整合数据模 型模式。基本模式(Elementary Pattern) 是数据建模的“螺母和螺栓”，包括解决多对多关系和 构建自引用层次结构的方法。套件模式(Assembly Pattern) 是指跨越业务人员和数据建模人员 范畴的一套构建块。业务人员可以理解它们——资产、文档、人员和组织等。已公布主题模型套 件，可为建模设计人员提供可靠的、强健的、可扩展的和可实现的模型设计。整合模式 (Integration Pattern) 提供了以常见方式整合套件模式的框架。<font color="green">P118</font>

行业数据模型： 为整个行业预建的数据模型。<font color="green">P118-119</font>

3.10 度量指标

度量指标： 数据模型校验指标。<font color="green">P91</font>

度量指标： 使用数据模型计分卡，提供了对模型质量的总体评估方法，并明确指出了针对模型的改进方案。 见下图5-15 <font color="green">P112-113</font>
各种类别的描述如下：1.模型多大程度上反映了业务需求?2.模型的完整性如何?(需求完整性。 元数据完整性)3.模型与模式的匹配度是多少?4.模型的结构如何?5.模型的通用性如何?6.模 型遵循命名标准的情况如何?7.模型的可读性如何?8.模型的定义如何?(清晰/完整/准确)9.模 型与企业数据架构的一致性如何?10.与元数据的匹配程度如何? <font color="green">P112-113</font>

4 实施指南

数据建模和设计质量管理： 数据模型和数据库设计应是组织短期需求和长期需求之间的合理平 衡。主要有:1 开发数据建模和设计标准。2 评审数据模型及数据库设计质量。3 管理数据模 型版本与集成。<font color="green">P120</font>

开发数据建模和设计标准 <font color="green">P120</font>
1)标准数据建模和数据库设计可交付成果的列表和描述。
2)适用于所有数据模型对象的标准名称、可接受的缩写和非常用单词的缩写规则列表。
3)所有数据模型对象的标准命名格式列表,包括属性和分类词。
4)用于创建和维护这些可交付成果的标准方法的列表和说明。
5)数据建模和数据库设计角色和职责的列表和描述。
6)数据建模和数据库设计中捕获的所有元数据属性的列表和描述,包括业务元数据和技术元数据。例如,指导原则中可以设置数据模型为每个属性捕获数据血缘的期望。
7)元数据质量期望和要求。
8)如何使用数据建模工具的指南。
9)准备和领导设计评审的指南。
10)数据模型版本控制指南。
11)禁止或需要避免的事项列表。

管理数据模型版本与集成： 需要以时间线记录变更内容，每个变更都应记录，包括:Why。What。How。When。Who。Where。<font color="green">P121</font>

5 关键架构图

1. 图5-1语境关系图

   
   
   图5-1语境关系图

2. 表5-2 常用的实体类别

   
   
   表5-2 常用的实体类别

3. 图5-3 一元关系

   
   
   图5-3 一元关系

4. 图5-4 二元关系

   
   
   图5-4 二元关系

5. 图5-5 三元关系

   
   
   图5-5 三元关系

6. 表5-6 建模方法和表示法

   
   
   表5-6 建模方法和表示法

7. 表5-7 数据库交叉应用模式（Scheme to Database Cross Reference）

   
   
   表5-7 数据库交叉应用模式

8. 图5-8 基于事实的建模

   
   
   图5-8 基于事实的建模

9. 图5-9 数据拱顶模型

   
   
   图5-9 数据拱顶模型

10. 图5-10 锚建模

    
    
    图5-10 锚建模

11. 图5-11 概念数据模型

    
    
    图5-11 概念数据模型

12. 图5-12 关系型逻辑数据模型

    
    
    图5-12 关系型逻辑数据模型

13. 图5-13 维度型逻辑数据模型

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

14. 图5-14 关系型物理数据模型

    
    
    图5-14 关系型物理数据模型

15. 表5-15 数据模型计分卡

    
    
    表5-15 数据模型计分卡