第5章 数据开发

数据开发（Data Development)是数据管理框架中的第三个数据管理职能它是第二个与数据治理功能交互并受其影响的数据管理职能。

5.1 简介

数据开发是指分析、设计、实施、部署及维护数据解决方案，以使企业的数据资源价值最大化。数据开发是系统开发生命周期（System Development Lifecycle，SDLC)中项目活动的子集，其专注于数据需求的定义、数据解决方案组件的设计和实施。数据解决方案中最基本的组件是数据库和其他数据结构。其他数据解决方案的组件包括信息产品(屏幕展示和报表)以及数据访问接口等。

数据开发职能的关联图:

5.2 概念与活动

5.2.1 系统开发声明周期

数据开发活动发生于系统开发和维护工作的关联环境中，而这整个过程通常称为系统开发生命周期（System Development Life Cycle,SDLC）。这些活动大多是以项目的方式进行管理。项目是为完成一定的目标而进行的有组织的活动。小规模的维护活动可能在一天内就可以完成，而特别大规模的多阶段项目则有可能需要持续数年才能完成。

系统开发生命周期（SDLC）：

5.2.2 系统建模方式

目前存在有几种不同的数据建模方法，每种方法会使用不同的图形样式。不同的图形样式在语法上稍有不同。

IE—最常用的数据建模图形样式是“信息工程”(Information Engineering,IE)语法，之所以命名为IE是因为受到詹姆斯·马丁（James Martin)关于信息工程的书籍和培训的影响。IE的表示法通常使用三叉戟或者“鱼尾纹”，及其他符号来描绘基数。
IDEF1X——最初是为美国空军开发的一种辅助的数据建模语法，用圈（或涂黑或为空)和线（或实线或虚线）代替“鱼尾纹”以表达相同的意思。IDEFO流程图通常使用IDEF1X表示法。
ORM—对象角色建模语法（ObjectRole Modeling)可以非常详细地描述业务数据
的关系和规则。ORM图所表达的信息量太大，因此需要分解到更小的主题域视图，从而让用户更有效地理解在一张图上描述较少的业务实体。虽然ORM并没有被广泛运用，但是它的支持者仍然强烈鼓吹其好处。ORM在为复杂的业务关系建模时特别有用。
UML——统一建模语言（Unified Modeling Language）是几种不同建模形式综合而成的图形风格的建模语言。由Grady Booch、Ivar Jacobsen 以及James Rumbaugh开发的UML把面向对象的分析和设计过程标准化。现在UML已经被广泛使用，并能有效地达到建模目的。许多标准化组织已经把UML广泛应用于系统开发生命周期中。

5.2.3 数据建模、分析和解决方案设计

数据建模是一种分析和设计方法，用于定义和分析数据需求，设计满足需求的数据结构。是一种反映业务需求的分析活动，也为业务流程提供了创新机会，具备设计活动。所以，概念数据建模是需求分析活动，物理数据建模是设计工作，而逻辑数据建模是两者兼有，需要平衡。

• 分析信息需求

信息需求是从一个或多个流程中确认，业务流程消费的输入的信息，输出信息产品。信息产品是确定一个必须的业务名词，也是数据建模的依据。不管是流程还是数据都是以顺序或者并行的方式进行，有效的分析和设计能够在流程和数据建模中确保数据和流程的平衡。
需求分析包括业务需求的引导、组织、记录、评审、完善、批准和变更控制。可以通过文字或者图形来表述需求说明。

• 开发和维护概念数据模型

概念数据模型是业务重点相关的主题域的高层级视角，并不依赖于技术和环境。包括给定领域和职能中基础和关键业务实体，以及实体间的关系描述。
概念数据模型定义了关键业务的词汇表，通过词汇表定义其中的每一个对象。包括业务术语、关系术语、实体同义词、安全分类等。概念数据模型的主题域可以反映业务流程和功能相关联的数据。

概念数据模型的开发，一般从某一个主题域开始，确定包含哪些实体，它们之间如何关联，以及实体的信息。业务实体一般会有主表（账户所有者）、子表（子账户）等。
维护概念数据模型，需要采用一定的流程对概念模型产生的变更进行检查，并做好版本记录。
（1）实体

业务实体是组织关心的事物，数据实体是业务认为重要且值得定义的集合。数据实体是业务实体的实例化。

①概念业务实体描述关于数据收集相关目标。
②逻辑数据实体遵循范式和抽象的规则，可以将业务实体分解为很多相关联的组成部分。
③物理数据模型则定义基础表结构，基础表结构可以比较逻辑模型中的数据实体进行直接关联或者间接关联。

实体可以独立存在，也可以参照其他实体，3种类型的非独立实体：

①属性/特性实体：仅依赖于一个父实体（1：1或者1：n关系，中的后者）
②关联/映射实体：依赖于两个或者以上的实体（n：1中的后者）
③类别/子类或超类实体：相当于某一个实体是n个实体的实例，展现形式就像子类继承、超类泛化。这个实体和n个实体之间并非依赖关系，而是使用n个实体中某一个实例的关系。（比如“当事人”这个实体，会需要员工、组织等实体的信息。当事人为超类，员工、组织为子类）

2）关系

业务规则定义了什么能做和什么不能做的限制条件。可分为两类：

①数据规则对数据间的关系进行了限制。
②操作规则在数据元素包含一定的数值时用于指导做什么事。操作规则通常无法在数据模型中进行定义，而是通过数据记录的编辑和校验规则处理。

数据模型表达的数据规则有两类：

①基数规则：定义与两个实体间关系相关的某个实体的实例数量。比如一个公司可以聘用多少人
②参照完整性规则：确保正确有效的数值。比如一个人可以独立存在，一个公司要想存在至少要聘用一个人

在数据模型中需要将这两个规则表达为实体间的关系，如上述两个例子：

每个人可以为0到多个公司工作
每个公司必须聘用1个或多个员工

关系标签用于描述两个实体间的业务规则，可能有3种类型：（3种类型的非独立实体）

①一对一关系，指父实体有且仅有一个子实体
②一对多关系，指父实体可能有一个或多个子实体。
③多对多关系，一个实体的实例可与其他实体的0到多个实例关联起来，反之亦然。

递归关系将同一实体不同实例关联起来，也会有上述三种情况。

• 开发和维护逻辑数据模型

逻辑数据模型是数据需求和控制数据质量的业务规则描述。从概念数据模型上拓展，将数据属性添加到数据实体。组织应提供逻辑数据模型的命名标准。逻辑数据模型其实是对业务需求的逻辑抽象，是概念数据模型和物理数据之间的逻辑映射。逻辑数据模型通过范式化和抽象化来转换概念数据模型的结构。

1）范式是运用规则将业务的复杂性转变为稳定的数据结构，梳理和理解数据元素之间的关系，确保一个数据元素仅在一个位置出现。范式规则可以归类到不同层次，每个层次都建立独立的规则，并包含之前所有的层次。包括：

第一范式1NF；
第二范式2NF；
第三范式3NF；
Boyce/Codd范式BCNF；
第四范式4NF；
第五范式5NF；
第六范式6NF；

2）抽象是对实体数据、元素和关系的重新定义，通过消除细节来拓展数据结构来适应业务的复杂性和范围。通常会使用超类而不是子类。（比如用当事人角色超类代表客户、雇员、供应商等子类）

属性：实体的一种特性，对于业务事实的分类，描述实体实例。业务实体是组织词汇表中的名词，属性代表形容词。属性在逻辑模型中应具有原子性，确保无法分解为更细的数据片。高质量的实体和属性定义可以阐明业务词汇含义，提供严谨的业务规则管理实体关系，帮助制定明智的商务决策和应用设计。高质量的数据定义有3大特征：清晰、准确和完整；
域：属性取值的完整集合。一个属性不能在其对应的域范围外，部分域对于取值定义有数量等限制，或最大最小值限制，业务规则也可以限制域。有些属性可以共享相同的域（比如时间）。数据辞典包括域的集合和每个域相关联的属性。
键：（或候选键）代表一个或多个树形，其取值可以唯一的确认一个数据实体的实例。

①复合键包括两个或多个属性。候选键中有且仅有一个主键，其他所有的候选键都会成为备用键。
②为避免复合主键，或关键属性的取值将来会改变，可以使用代理键。代理键是随机生成的唯一值，非顺序的。
③外键时能够将某一实体关联到其他实体的属性。

• 开发和维护物理数据模型

物理数据模型可以根据技术约束、应用方法、性能需求和建模标准等来优化详细的数据需求和业务规则的实施工作。设计数据存储的具体结构。

物理数据模型的设计工作：

①每个表和列（关系型数据库）、文件和字段（非关系型数据库），模式和元素（XML数据库）的技术命名；
②每个列或字段的逻辑域、物理数据类型、长度和非空属性；
③每个列或字段的任何默认值，特别是非空限制；
④主键、备用唯一键及索引，包括怎样分配键；
⑤根据逻辑模型建立小的参考值集合，如独立的代码表、全局共享码表、简单的规则和限制条件；
⑥当子类实体属性做为可空的列合并到超类实体中，或者压缩超类属性导可以代表所有子类时，物理数据库设计可以使用较小的超类/子类的逻辑模型实体；

书中注：在之后的表述中，“表”指表、文件、XML模式；“列”指列、字段、XML元素；“行”指行、记录、实例；

逻辑数据模型转换为物理数据模型的建模技术：

去范式化：有选择、有合理理由的进行反范式化处理，通过冗余数据降低数据获取时间；
代理键：在业务使用中不能见到代理键，只用来协助数据处理使用；
索引：通过索引来优化特定场景的查询；
分区：垂直或水平分解表；
视图：虚拟化表用于简化查询、控制数据访问、列重命名；
维度：创建事实表和相关的维度表，按照商务智能的需要使用星型模型和雪花模型

5.2.4 详细的数据设计

详细的数据设计主要是针对物理数据库的设计工作，包括物理数据库设计时需要用的各类视图、函数、触发器和存储过程等，同时，也包含数据架构、信息产品（展示使用）、数据访问方案等内容。

• 设计物理数据库

物理数据库的设计是数据库实施的详细说明，比如关系型数据库的设计交付物是DDL说明书，XML数据库的交付物是命名空间。物理数据库设计除了设计者之外，数据管理员(DBA)也负有详细数据库设计的职责。

物理数据库设计的内容：

架构和技术选择：架构类型包括关系型、层次型、网络型、面向对象型、星型模式、雪花模式、多维数据集模式等；
实施技术：存储预期、应用要求（与数据库耦合度）、安全性、可用性、实时性要求、性能要求、组织和政治因素、开发者技术偏好等；
其他：授权、审计和隐私、数据库服务协议、开发流程等；

数据库设计原则（PRISM）：

①性能和易用性；
②重用性；
③完整性；
④安全；
⑤可维护性；

最佳实践：

①对于使用关系型数据库需要支持事务处理的，可以使用符合范式设计以提升数据完整性、可重用性、更新性能和数据可扩展性；
②使用视图、函数和存储过程来创建非范式的、特定应用、虚拟视图的数据，不强制物理数据库级别工作，也不要将数据库模式和应用程序紧耦合；
③整个数据库和数据库实体对象都使用标准的命名规则、有意义和描述性的名字，以简化维护工作，特别是使用缩写的时候；
④在数据库级别对数据的安全性和完整性进行强制要求；
⑤在数据库服务器端进行数据处理（存储过程），可以轻松隔离和修复错误以及性能问题，减少网络流量；（笔者注：使用数据库层级的开发和处理，需要平衡维护和复杂度，不建议在存储过程中进行复杂的数据处理，可以考虑进行大数据量的处理，而不是逻辑处理）
⑥仅对应用程序组和角色授权数据库对象，而不是单个用户，提升安全性，简化维护；
⑦决不允许对数据库进行任何直接的、及时的更新，所有更新都应该在控制下，通过预定的流程进行；

完整的物理数据库设计文档包括：

①数据库设计中业务功能的介绍性描述；
②图形化设计，如ER图、UML等；
③数据库语言相关语句；
④以文档记录相关元素，如类型、长度、域等；
⑤用例或样本数据，可以表现实际上所看到的数据样子；
⑥根据需要，对相关内容进行简要描述。如：数据库架构和技术的选择原因、限制条件、数据库设计流程、物理数据库设计和逻辑数据模型设计间不同的原因、数据库的更新机制、数据库的安全需求、服务水平协议、用户和应用需求等；

性能调优：

建立索引；
去范式化；

• 信息产品设计

信息产品设计是为用户提供数据展示，满足业务数据需求。数据的展现包括：报表服务、分析服务、仪表盘（驾驶舱）、记分卡、门户网站、XML交付、业务流程自动化、应用集成。

数据分析师确保业务数据术语的一致性使用，并增加适当的上下文环境确保数据生产者和消费者使用数据。为用户提供更加友好的表单，使用更加稳定可用的数据。

数据库管理员主要是协助进行数据整合和数据交付。确保数据访问标准化（数据库变更与应用程序隔离）、对开发者创建和维护的数据库访问语句进行评审和性能调整。

• 数据访问服务设计

数据访问服务设计主要是为了满足访问远程数据库中的数据，以便和本地数据库中的数据结合使用。通常有以下常见的方式：

①链接服务器（Linked Server）型连接；
②SOA Web Services；
③消息代理；
④数据访问类；
⑤ETL工具；
⑥复制；
⑦位置合并；

数据访问服务的目标是在企业范围内以方便低廉的数据重用方式使用数据，尽可能避免成本高昂的数据复制模式，尽可能防止冗余和不一致性。

• 设计数据整合服务

数据整合服务主要确定适合的更新机制，执行数据库事务。实施多用户并发操作时的控制机制，确保数据的完整性。

数据分析和数据整合专家为数据间映射设计数据转换机制，DBA协助完成此设计活动。他们也会为新旧数据结构转换进行设计，并选择适用的工具。

数据整合的原则：

①在受控的方式下进行数据更新；
②将与特定业务流程相关的更新以事务的方式进行管理，不允许部分提交更新；
③进行并发控制；
④将错误信息可以报告给调用的程序；
⑤为更新特定数据库的权限授权给角色；
⑥一次事务尽可能限制到小范围内，防止长时间（过度）锁表，以及大量回滚事务；

5.2.5 数据模型和设计质量管理

数据模型和数据库设计应该兼顾组织短期和长期需求间的平衡，处理好数据消费者和生产者的需求。

制定数据建模和设计的标准：（标准作为实现业务数据需求，符合数据架构，确保数据质量的指导原则）

①数据建模和设计的标准成果清单及描述；
②数据模型对象的命名规则及相关描述，包括缩写规范、非常规词汇规范等；
③数据模型对象的标准命名格式，包括属性、列等；
④用于创建和维护这些成果的标准方法；
⑤数据建模和设计的角色和职责；
⑥所有的元数据属性及描述；
⑦如何使用建模工具、准备和引导设计评审的指南说明；

质量设计评审：包括概念数据模型评审、逻辑数据模型评审和物理数据模型评审；
1）概念和逻辑数据模型评审

①业务数据需求是否完全覆盖，且清晰表达，包括约束实体间关系的业务规则；
②业务名称、实体、属性的定义清晰、切实、一致、互补，使用含义相同的术语；
③遵循数据模型标准及命名标准；
④验证模型；

2）物理数据模型评审

①设计满足业务、技术、用途及性能的需求；
②遵循数据建模和设计标准；
③满足元数据质量预期和需求；
④验证模型；

3）数据模型验证：以建模标准、业务需求和数据库需求来验证数据模型。
管理数据模型的版本及整合：

①数据模型及设计说明，需要与其他交付物一样进行版本变更控制。重要的内容需要相关人员进行评审和批准。
②变更时需要注明：背景及变更原因；变更内容；批准时间、被实施的时间；实施变更的人员；
③部分变更内容要注意与企业模型的合并，避免出现不一致；

5.2.6 数据项目实施

数据实施是支持系统建设、测试及部署的数据管理活动。包括：

①实施开发和测试数据库变更：不同角色可以进行数据库变更的实施工作，但DBA应当监控所有变更，并确保与标准一致，尽早是别质量低下的变更；
②创建和维护测试数据：维护环境数据的有效性和质量，定期删除测试和过时数据，并审查是否满足隐私和保密的需要；
③迁移和转换数据；
④构建并测试信息产品、数据访问服务、数据整合服务；
⑤验证信息需求；
⑥准备部署数据：确保对系统使用清晰、一致的语言描述，并将这些数据模型中的业务概念、术语、定义和规则做为用户培训和文档的一部分。相关人员均需参与到部署的准备工作，DBA负责把新的数据对象部署到生产环境，并在安装结束后，相关角色尽早监控系统，确认是否满足业务数据需求；