【无标题】

一、数据架构语境关系图

企业架构包括多种不同类型，如包括业务架构、数据架构、应用架构和技术架构等。其中数据架构的主要目标是有效地管理数据，以及有效地管理存储和使用数据的系统。

数据架构是数据管理的基础。由于大多数组织拥有的数据超出了个人可以理解的范围，因此有必要在不同抽象层级上描述组织的数据，以便更好地了解数据，帮助管理层做出决策。

最为详细的数据架构设计文件是正式的企业数据模型，包含数据名称、数据属性和元数据定义、概念和逻辑实体、关系以及业务规则。

本章节中，将从以下几个方面考虑数据架构：

1）数据架构成果，包括不同层级的模型、定义、数据流，这些通常被称为数据架构的构件。

2）数据架构活动，用于形成、部署和实现数据架构的目标。

3）数据架构行为，包括影响企业数据架构的不同角色之间的协作、思维方式和技能。

二、业务驱动因素

数据架构常见的业务驱动因素如下：

1）利用新兴技术所带来的业务优势，从战略上帮助组织快速改变产品、服务和数据。

2）将业务需求转换为数据和应用需求，以确保能够为业务流程处理提供有效数据。

3）管理复杂数据和信息，并传递至整个企业。

4）确保业务和IT技术保持一致。

5）为企业改革、转型和提高适应性提供支撑。

数据架构的主要成果包括：

1）数据存储和处理需求。

2）设计满足企业当前和长期数据需求的结构和规划。

三、企业数据架构

企业数据架构包括企业数据模型和数据流两部分，详情如下。

1、企业数据模型

企业数据模型：组织对企业内数据实体、数据属性和它们之间关系的理解。各层级模型（概念模型、逻辑模型、物理模型）是企业数据模型的组成部分。模型链接定义和管理了模型的横向（关联）和纵向（层级）关系。

常见的企业数据模型建设方法：自上而下、自下而上或者混合模式：

自上而下是从主题域开始，先设计主题，再逐步设计下层模型。而采用自下而上的方法时，主题域结构则是基于现有逻辑数据模型向上提炼抽象而成。通常推荐两种方法相结合，即自下而上地从分析现有模型开始，自上而下地设计主题模型，通过两种方法的结合来共同完成企业数据模型的设计工作。

企业数据模型概念图：

主题域模型概念图：

2、数据流

数据流：记录数据血缘的数据加工过程，可以通过二维矩阵、数据流图呈现。

2.1、二维矩阵数据流概念图

2.2、数据流概念图

四、度量指标

常用的企业数据架构衡量指标：架构接受度、实施趋势、业务价值。数据架构衡量工作通常作为项目总体业务客户满意度的一部分，每年开展一次。

（1）架构标准接受率。测量项目与已建立的数据架构的紧密程度，项目与企业架构参与流程的遵循度。

（2）实施趋势。对跟踪企业架构改善组织实施项目能力的程度，至少沿两个方向进行改善：

1）使用/重用/代替/废弃测量。决定使用新架构构件与重用、代替或废弃构件的比例。

2）项目执行效率测量。测量项目的交付时间和可重用构件及指导构件的交付改进成本。

（3）业务价值度量指标 。追踪向期待的业务效果和利益方向的发展过程：

1）业务敏捷性改进。解释生命周期改进或改变的好处，改进延误成本的测量方法。

2）业务质量。测量业务案例是否按期完成；基于新创建或集成的数据导致业务发生的改变，测量项目是否实际交付了这些变更。

3）业务操作质量。测量改进效率的方法。实例包括准确性改进、时间减少，由于数据错误而导致的纠错费。

4）业务环境改进。实例包括由于数据错误减少而改变的客户保留率和在递交报告中当局评论的减少率。

五、关键概念/工具/方法

1、企业架构之间的关系

企业架构包括多种不同类型，如包括业务架构、数据架构、应用架构和技术架构等。每个架构都不是孤立存在的，要么对其他架构产生影响，要么受制于其他架构。

2、企业架构框架——Zachman框架

在建筑、飞机、企业、价值链、项目或系统中，有许多利益相关方，且各方对架构都持有一个不同的观点。这些概念可以应用到一个企业的不同架构类型和层次需求中。

Zachman模型可以完整地描述一个企业以及相互之间的关系。它并不定义如何创建模型，只是显示哪些模型应该存在。

矩阵框架的两个维度为：问询沟通（如是什么、怎样做、在哪里、是谁、什么时间和为什么）在列中显示，重新定义转换（如识别、定义、描述、规范、配置和实例）在行中显示。框架分类按照单元格呈现（问询和转换之间的交叉）。框架的每个单元格代表一个独特的设计组件。在问询沟通时，可以询问关于任何一个实体的基本问题，将其转换成企业架构，每个列可以按照如下理解：

1）什么（What）。目录列，表示构建架构的实体。

2）怎样（How）。流程列，表示执行的活动。

3）在哪里（Where）。分布列，表示业务位置和技术位置。

4）谁（Who）。职责列，表示角色和组织。

5）什么时间（When）。时间列，表示间隔、事件、周期和时间表。

6）为什么（Why）。动机列，表示目标、策略和手段。

重新定义转换是将抽象的概念转变为具体的实例（实例化）的必经步骤。矩阵中的每一行代表不同的角色，具体的角色包括规划者、所有者、设计师、建造者、实施者和用户。每个角色对整个过程和不同问题的解决均持有不同的视角。这些不同的视角对应的内容在每行中进行显示。例如，每个视角与“什么”列（目录或数据）均有交叉，说明相互之间具有不同关联关系。具体说明如下：

1）高管视角（业务背景）。定义不同模型范围的业务元素目录。

2）业务管理视角（业务概念）。明确管理层在定义的业务模型中所涉及的不同业务概念之间的关系。

3）架构师视角（业务逻辑）。作为模型设计的架构师细化系统需求，设计系统逻辑模型。

4）工程师视角（业务实体）。作为具体模型建造者的工程师，在特定技术、人员、成本和时间限制内，优化和实施为具体应用设计的物理模型。

5）技术人员视角（组件程序集）。采用特定技术、脱离上下文语境的视角，来解释配置模型的技术人员如何使用、组装和实施配置组件。

6）用户视角（操作类）。参与人员所使用的实际功能实例。

六、数据建模和设计语境关系图

数据建模是发现、分析和确定数据需求的过程，用一种称为数据模型的精确形式表示和传递这些数据需求。

数据模型有助于组织能够理解其数据资产，数据建模的直接成果不是数据库，而是对组织数据的理解。

数据建模最常见的模式：关系模式、多维模式、面向对象模式、事实模式、时间序列模式、NoSQL模式

每种模式又可以分为三层模型（不是所有的都可以分为三类）：概念模型、逻辑模型、物理模型。

每种模型都包含一系列组件，如实体、关系、事实、键和属性。

七、业务驱动因素

驱动组织进行数据建模和设计的常见业务因素如下：

1）提供有关数据的通用词汇表。

2）获取、记录组织内数据和系统的详细信息。

3）在项目中作为主要的交流沟通工具。

4）提供了应用定制、整合，甚至替换的起点

良好的数据建模会降低支持成本，增加未来需求重复利用的可能性，从而降低构建新应用的成本。数据模型是元数据的一种重要形式。

八、活动

1、规划数据建模： 评估组织需求、确定建模标准、明确数据模型存储等任务

2、建立数据模型： 一个不断迭代的过程，不断进行优化，直到满足业务诉求。常见的建立数据模型的方法包括正向工程和逆向工程：

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

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

该部分在执行时，细节比较多，详细的操作指南，可在执行时再次翻阅DMBOK

3、审核数据模型： 持续改进、模型评估和正式发布。

4、维护数据模型： 数据模型需要保持最新状态。在维护数据模型时一个好的习惯是对最新的物理数据模型进行逆向工程，并确保它与相应的逻辑数据模型保持一致。许多数据建模工具可以自动比较物理模型与逻辑模型差异

九、度量指标

可以参考下表来制定适合自己企业的数据模型计分卡和评估指标。

十、数据建模核心概念

1、实体、关系、属性、域

1.1、实体

实体定义是有别于其他事物的一个事物，是一个组织收集信息的载体。一个实体可以被认为是一些基本问题的答案——谁、什么、何时、何地、为什么、怎么办或这些问题的综合。

实体在不同层级模型中的叫法不同：

概念模型：概念concept/术语term

逻辑模型：实体entity

物理模型：表table

实体类型——实体——实体实例之间的关系

1.2、关系

关系是实体之间的关联。关系捕获概念实体之间的高级别交互、逻辑实体之间的详细交互和物理实体之间的约束。

关系有一些内在的属性，如基数，元数等：

关系的基数：一对一、一对多、多对多关系

关系的元数：涉及到的实体的个数，一元关系、二元关系、三元关系等

1.3、属性

属性是定义、描述和度量实体某方面的性质。

属性中的标识符，也称为键。

按照结构分：单一键、组合键（多个属性集合）、复合键（组合键 + 其他）、代理键（也是单一键，表的唯一标识符，技术上的自增ID）

按照功能分：候选键（标识实体实例的最小属性集合，可能包含一个或多个属性）、主键（被选为实体唯一标识符的候选键）、超键（唯一标识实体实例的任何属性集）、备用键（没有被选为主键的候选键）——一般主键是代理键，备用键是业务键

1.4、域

域代表某一属性可被赋予的全部可能取值，也被称为值域。

2、常用数据建模方法

2.1、关系建模

关系建模是一种能够清晰表达含义的组织数据的系统方法，在减少数据存储冗余方面卓有成效，特别适合设计操作型的系统。最常见的就是信息工程法，用三叉线表示基数

2.2、维度建模。

维度建模的理念是，数据组织的方式是为了优化海量数据的查询和分析。

维度建模主要包括下面概念：

• 事实表：特定的数值型度量值。如金额、交易量。往往占据数据库的大部分空间。

• 维度表：表示业务的重要对象，主要包含文字描述。如用户信息，地区信息。

• 粒度：事实表中单行数据的含义或描述，如日期、地区、用户等

2.3、非关系型数据库

NoSQL：Not only SQL。不是关于如何查询数据库，而是关于如何存储数据的。通常有四类：文档数据库、键值数据库、列数据库、图数据库。

3、关系模型和维度模型不同层级的展现

3.1、概念模型CDM

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

3.2、逻辑模型LDM

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

3.3、物理模型PDM

描述了一种详细的技术解决方案，通常以逻辑模型为基础，与某一类系统硬件、软件和网络工具相匹配。物理模型与特定技术相关

4、规范化

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

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

2）第二范式（2NF）。确保每个实体都有最小的主键，每个属性都依赖于完整的主键。

3）第三范式（3NF）。确保每一个实体都没有隐藏的主键，每个属性都不依赖于键值之外的任何属性（仅依赖于完整的主键）。

实践中一般达到第三范式即可，4NF，5NF很少出现

DAMA对范式的解释有点官方，为了帮助理解，可以参考：

十一、关键概念/工具/方法

1、数据建模和设计质量管理

1.1、开发数据建模和设计标准

如前所述，数据建模和数据库设计标准提供了满足业务数据需求、符合企业和数据架构标准以及确保数据质量的指导原则。数据建模和数据库设计标准应包括以下内容：

1）标准数据建模和数据库设计可交付成果的列表和描述。

2）适用于所有数据模型对象的标准名称、可接受的缩写和非常用单词的缩写规则列表。

3）所有数据模型对象的标准命名格式列表，包括属性和分类词。

4）用于创建和维护这些可交付成果的标准方法的列表和说明。

5）数据建模和数据库设计角色和职责的列表和描述。

6）数据建模和数据库设计中捕获的所有元数据属性的列表和描述，包括业务元数据和技术元数据。例如，指导原则中可以设置数据模型为每个属性捕获数据血缘的期望。

7）元数据质量期望和要求（参见第13章）。

8）如何使用数据建模工具的指南。

9）准备和领导设计评审的指南。

10）数据模型版本控制指南。

11）禁止或需要避免的事项列表。

1.2、评审数据模型以及数据库设计质量

组建具有不同背景、技能、期望和意见的不同领域的专家小组对数据模型和数据库设计进行评审。在组建专家评审小组时，可能需要通过特定途径，邀请有关领域的专家参与。参与者必须能够讨论不同的观点，并最终达成小组共识，不存在任何个人冲突，因为所有参与者都有共同的目标，即推广最实用、表现最好、最可用的设计。

1.3、管理数据模型版本与集成

对数据模型和其他设计规范需要谨慎的变更控制，就像需求规范和其他SDLC可交付成果一样。注意对数据模型的每次更改，需要以时间线记录变更内容。如果更改影响到了逻辑数据模型，如新的或更改了的业务数据要求，则需要数据分析师或架构师审核并批准对模型的更改。每个变更都应该予以记录，包括：

1）为什么（Why）项目或情况需要变更。

2）变更对象（What）以及如何（How）更改，包括添加了哪些表，修改或删除了哪些列等。

3）变更批准的时间（When）以及将此变更应用于模型的时间（不一定在系统中实施更改）。

4）谁（Who）做出了变更。

5）进行变更的位置（Where）在哪些模型中。

2、行业数据模型

行业数据模型是为整个行业预建的数据模型，包括医疗保健、电信、保险、银行、制造业等行业。这些模型通常范围广泛且内容详细。一些行业的数据模型包含数千个实体和属性。可以通过供应商购买行业数据模型，也可以通过ARTS（零售）、SID（通信）或ACORD（保险）等行业组织获得。

任何购买的数据模型都需要进行定制以适应组织的特点，因为它是根据其他组织的需求进行设计的。所需的定制级别取决于该数据模型与组织需求的接近程度，以及最重要部分的详细程度。在某些情况下，它们可以作为工作参考，帮助建模人员制作更完整的模型。有时，它只能帮助数据建模人员节约一些公共元素的录入工作。

3、数据库设计中的最佳实践

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

1）性能和易用性（Performance and Ease of Use）。确保用户可快速、轻松地访问数据，从而最大限度地提高应用程序和数据的业务价值。

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

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

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

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