数据开发

一、简介

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

　　数据开发职能的关联图如图5.1所示。

　　项目组成员必须相互合作以有效地设计出数据解决方案。

　　　　• 业务数据管理专员和领域专家(Subject Matter Experts,SMEs)提供关于数据和信息的业务需求,包括业务规则和数据质量预期,并负责检验这些需求是否得到了满足。

　　　　• 数据架构师、分析师和数据库管理员主要负责数据库设计。在实现层次化的面向服务的架构(Service-Oriented Architecture,SOA)过程中,数据库管理员与软件开发人员协同定义数据存取服务。

　　　　• 软件架构师和开发人员(包括应用系统集成和数据整合专家）主要负责应用程序内部的数据捕获和数据使用设计,以及信息产品(屏幕展示和报表打印)的用户界面设计。

二、概念和活动

2.1 系统开发生命周期

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

　　在系统开发生命周期中,系统开发和维护项目会执行一些特定的活动。如图5.2所示，

　　其过程中的阶段仅代表了系统实施过程中常用的非常高阶的步骤。虽然这些阶段并没有标准的大纲,但通常,每个系统开发周期都会包含以下一些规范和实施活动:

　　　　• 项目计划,包括范围定义和业务案例论证。

　　　　• 需求分析。

　　　　• 解决方案设计。

　　　　• 详细设计。

　　　　• 组件构建。

　　　　• 测试,包括单元测试.整合测试、系统测试、性能测试和验收测试。

　　　　• 部署准备,包括文档开发和培训。

　　　　• 安装和部署,包括试运行和上线。

　　系统维护活动一般也遵从相同高级别的系统开发生命周期流程,只是频率更快,所执行的分析、设计、编码、测试和部署的工作量都较小。

　　很多组织都已采用各种系统开发生命周期方法,将不同的系统开发方法和技术整合成综合的系统开发方法。这些方法可以指导系统开发项目的规划和实行。而大多数的SDLC方法会在系统开发生命周期的每个阶段给出详细的任务和特定的技术建议以实施相关活动。而这些任务和技术会创建有关数据建模的一系列交付物并最终引导到系统实施。前一阶段任务的输出可作为引导下一阶段的任务的输入。

　　不同的SDLC 方法以不同的方式描述系统开发生命周期,且每个方法都有特定的术语，如瀑布法和螺旋、迭代法。在高级别的计划、分析和设计原则指导下,这些方法在多个项目阶段执行系统开发生命周期的步骤,并以增量的方式逐步交付完整的解决方案。

　　信息系统定义并交付信息(满足相关性和时间范围等关联环境要求的数据)以支持业务职能(从战略规划到运营绩效)。数据存储和信息产品是构成每个信息系统整体所必需的组件。有效的系统开发项目需保证数据、流程和技术三者并重。

2.2 数据建模方式

　　目前存在有几种不同的数据建模方法,每种方法会使用不同的图形样式。不同的图形样式在语法上稍有不同。尽管所有的数据模型都是使用框和线表示,但是不同的样式会使用不同的符号,在框中也会用不同的内容来进行详细说明。DAMA 数据管理知识体系指南仅对这些样式进行非常简要的介绍。

　　　　• IE---最常用的数据建模图形样式是“信息工程”(Information Engineering,IE)语法,之所以命名为E是因为受到詹姆斯·马丁(James Martin)关于信息工程的书籍和培训的影响。正的表示法通常使用三叉戟或者“鱼尾纹”,及其他符号来描绘基数。

　　　　• IDEF1X一最初是为美国空军开发的一种辅助的数据建模语法,用圈(或涂黑或为空)和线(或实线或虚线)代替“鱼尾纹”以表达相同的意思。IDEFO流程图通常使用IDEF1X表示法。

　　　　• ORM—对象角色建模语法(Object Role Modeling)可以非常详细地描述业务数据的关系和规则。ORM 图所表达的信息量太大,因此需要分解到更小的主题域视图，从而让用户更有效地理解在一张图上描述较少的业务实体。虽然ORM并没有被广泛运用,但是它的支持者仍然强烈鼓吹其好处。ORM在为复杂的业务关系建模时特别有用。

　　　　• UML-统一建模语言(Unified Modeling Language)是几种不同建模形式综合而成的图形风格的建模语言。由 Grady Booch, Ivar Jacobsen以及James Rumbaugh开发的UML把面向对象的分析和设计过程标准化。现在UML已经被广泛使用,并能有效地达到建模目的。许多标准化组织已经把UML广泛应用于系统开发生命周期中。

　　UML定义了几种不同类型的模型和图形,类图与其他数据模型样式相似。除了为面向对象的软件建模,基于 XML的 Web services语义模型也常常使用UML类图。事实上，概念、逻辑甚至物理数据模型都能使用UML类图表示。

　　一些实践者认为分别给对象和数据建模没有必要,或没有价值。概念对象类与概念数据模型是对等的。然而,逻辑和物理的数据模型常常与逻辑和物理的面向对象的程序设计有很大差别。逻辑数据模型能够规范化数据属性,但对象模型不能。对象的属性表示在程序内存中的数据;而物理数据模型的属性则表示数据库中存储的数据,通常是作为关系型数据库基表中的列。认识到这些差异,大多数数据专业人士倾向于使用不同图形样式,在不同的模型中为数据和数据库建模。

　　通过经常地使用,不同的建模图的惯例可以被很快地区分开来,并且可以清楚地沟通每个模型的目的。例如，一些实践者使用IE表示法进行逻辑数据建模,而使用IDEF1X进行物理数据建模,特别是多维数据模型建模。然而,这可能使业务数据管理专员在评审不同的模型时很容易混淆。其实业务数据管理专员不需要成为数据模型的设计人员,他们只需要能顺利地阅读和理解一种主要的图形风格所表达的模型就可以了。

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

　　数据建模是一种分析和设计方法,并用于:第一,定义和分析数据需求;第二y设计满足需求的数据结构。数据模型是反映数据需求和设计的数据说明书和相关模型图的集合。大多数情况下,概念数据建模和逻辑数据建模是需求分析活动,而物理数据建模是设计工作。

　　模型是我们周围环境中事物的抽象表现,可以使人们通过标准化的符号快速领会其内容。地图、组织机构图以及建筑蓝图都是日常生活中所使用的模型范例。可将数据模型想象为使用文本和符号表示数据元素及其相互关系的图形。事实上，一张模型图可能只是作为一个整体模型所提供的多张视图中的其中之一。更为正式的定义是,数据模型是表现数据需求和设计的规格说明书及相关图形的完整集合。

　　尽管对于技术和流程有明确的定义,但是让数据在很多不同的应用表单中可用是需要技巧的,比如以可视化的方式让数据容易被理解。数据建模是一个复杂的处理过程,它包括了人与技术之间的相互作用。数据模型不能损害数据的完整性和安全性的要求。良好的数据模型能够有效地理解,并准确地表达数据需求,以保证解决方案的质量。一些模型图可能因为过多强调细节,反而降低了其有效性。

　　以下两个公式指引建模方法:

　　　　• 目的十对象=交付物。

　　　　• 交付物＋资源＋时间=方法。

　　数据模型的目的是为了推动:

　　　　• 沟通理解一数据模型为不同层次和经验的人提供理解数据的桥梁。它不但能帮助我们了解一个业务领域、一个实际应用或者修改现有结构的影响;同时,数据模型也有助于培养新的业务和技术人员。

　　　　• 形式化一—数据模型记录了数据需求和数据相关业务规则的唯一且确切的定义。

　　　　• 范围—数据模型也可以帮助解释已采购的应用程序包的数据关联环境和范围。

　　即使是包含相同数据的数据模型也可能因为范围和焦点不同而有所区别:

　　　　• 范围——从功能(业务视图或应用视图)、领域(流程、部门,处室、企业或产业视图)，和时间(现状、短期未来、长期未来)等不同的角度来表达数据。

　　　　• 焦点——基本和关键概念的(概念视图),详细但独立于关联环境的(逻辑视图),为特定技术和用途而优化的(物理视图)。

　　使用数据模型可以对数据进行规范,以满足信息需求。业务流程中使用的数据流被打包在信息产品中,而这些信息产品中的数据必须满足业务需求。数据建模,在此意义上,是一种反映业务需求的分析活动。然而,数据建模也代表了每一步业务流程中的创新机会,这使得数据建模同时也成为了一种设计活动。总而言之,概念数据建模中存在更多的分析活动,而物理数据建模中存在更多的设计活动,而逻辑数据建模则两者兼而有之,且需平衡。

2.3.1 分析信息需求

　　信息即是上下文环境相关的数据,且有时效性。为确认信息需求,首先需要在一个或多个业务流程中确认业务信息需求。业务流程所要消费的信息可定义为输人,而其他业务流程的输出可定义为信息产品。这些信息产品的名称往往可以确定一个必需的业务词汇,而且数据建模以此为依据。不管流程还是数据都是以顺序或并发的方式进行设计,有效的分析和设计能够在流程和数据建模并重的前提下确保数据(名词)和流程(动词)的相对平衡。

　　典型地,项目由项目需求驱动,而项目的章程则定义了项目的目标、交付物以及范围边界。初始的项目计划需要估算完成项目目标所需的资源,活动,时间以及成本。每个项目的章程都应该包括数据相关的目标,并在项目范围内确定相关数据。借鉴企业数据模型所提供的词汇可以有效地定义项目的数据范围。

　　需求分析包括业务需求的引导、组织、记录、评审、完善、批准和变更控制。某些需求可以用于确定数据和信息的业务需求。可以同时使用文字和图形来表述需求说明。

　　逻辑数据模型是表达业务数据需求的重要手段。对于很多人而言,如老话所说:“图片胜过千言万语”(a picture is worth a thousand words)。但是一些人不喜欢图片形式而更喜欢数据建模工具所创建的图表和报表。很多组织都有规范的管理要求用于需求说明书的起草和完善,比如,“系统应该……”。书面的数据需求说明书可使用需求管理工具来维护。用数据模型中所定义的规范来同步这些文档时要非常仔细。

　　有些方法还包括定义企业数据模型的规划活动,并使用如业务系统规划(BusinessSystems Planning, BSP)或者信息系统规划等技术。当然这些方法也包括定义规划阶段相关企业范围内的数据交付架构。第4章在数据架构管理中介绍了这些活动。

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

　　概念数据模型是业务重点相关的主题域内可视的、高阶的视角。它仅包括给定的领域和职能中基础和关键的业务实体,同时也给出实体和实体之间的关系的描述。概念数据模型定义了关键业务词汇的语义(名词和动词)。概念数据模型主题域可以反映与业务流程和应用功能相关联的数据。一个概念数据模型不依赖于技术(数据库、文件等)和使用过程中的关联环境(无论实体是在一个计费系统还是数据仓库系统中)。

　　概念数据模型中应包含一个词汇表用于定义其中的每一个对象。定义包括有业务术语、关系术语、实体同义词和安全分类。图5.3是概念数据模型的示例。

　　为创建一个概念数据模型,要从主题域模型的某个主题域开始。先确定哪些对象被包含在该主题领域内,以及它们之间如何关联。例如,客户主题域可能包括以下实体:账户所有者、子账户、首选联系方式和联系信息。

　　账户所有者一般会关联一个或多个子账户。每个账户所有者在任何时候都有一套首选联系方式和联系信息。

　　要维护一个概念数据模型,应采用--定的流程对所有生产系统可能对概念模型产生的变更进行检查。如果项目涉及变更,可创建中间概念模型,并在此之上做变更。然后,复制这个模型的变更到生产环境版本的概念模型上,并将其作为发布流程的一部分,以确保模型与现状同步。

　　1)实体

　　业务实体是组织感兴趣的事物,比如一个对象或者一个事件。而数据实体是指业务认为重要并值得定义的数据集合。实体是一个名词。

　　　　• 谁—-人员、组织、角色、雇员、客户、供应商、学生、当事人、部门、监管实体、竞争对手、合作伙伴、附属机构、团队、家庭、家用物品。

　　　　• 事物———产品、服务、资源、原材料、成品、课程、班级。

　　　　• 时间——事件、财政周期。

　　　　• 哪里—一位置、地址、站点、网络节点。

　　　　• 为什么——政策、规则、要求、投诉、退货、查询。

　　　　• 如何——机制、工具、文档、发票、合同、协议、标准、说明。

　　实体是特定业务实体的实例化。比如客户实体可拥有名为Bob、Joe、Jane等的实例。而账户实体就可以有 Bob的支票账户、 Bob的储蓄账户,Joe的经纪人账户等实例。

　　实体会出现在概念或者逻辑数据模型中。概念业务实体描述关于数据收集相关目标，如客户、产品和账户。逻辑数据实体遵循范式和抽象的规则,因此客户的概念可分解成很多组成部分,如客户、客户类型以及客户偏好。物理数据模型则定义基表,而基表与可比较的逻辑模型中的实体直接或不直接地关联。

　　实体可以是独立的,也可以是非独立的。独立的实体(或者核心实体)不依赖于任何其他实体而存在。独立实体每一次出现都不会参照在数据模型中的任何其他实体。一个非独立实体则需要依赖于一个或者多个其他实体而存在。下面介绍了3种类型的非独立实体。

　　　　• 属性/特性实体一一仅依赖于一个父实体,例如员工的受益人仅依赖于员工本身。

　　　　• 关联/映射实体——依赖于两个或者两个以上的实体,例如注册依赖于特定的学生和课程。

　　　　• 类别/子类或超类实体——某实体是“一类”其他实体。子类和超类分别是继承和泛化的例子。一个超类实体是其所有子类的泛化,而每一个子类都继承了其父类的属性。例如，一个当事人(Party)超类会链接到员工和组织等子类。子类之间可重叠(非排他)或者不重叠(排他)。一个不重叠的子类实体实例必须属于某个子类,但不可能同时属于两个子类。

　　2）关系

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

　　　　• 数据规则对数据间的关联进行了限制。例如,新生每学期最多可注册18个学分。数据模型关注这样的数据业务规则。

　　　　• 操作规则在数据元素包含一定的数值时用于指导做什么事。操作规则很难在数据模型中定义。保证数据质量的业务规则是操作规则,而应用程序将操作规则实现为数据记录的编辑和校验规则。

　　数据模型中可表达的数据规则主要有两种:

　　　　• 基数规则-——用于定义与两个实体间关系相关的某个实体的实例数量。例如,“每个公司可以聘很多雇员”。

　　　　• 参照完整性规则——是为确保正确有效的数值所定义的规则。例如,“一个人可以不为公司工作,但是公司不能独立存在,至少需要聘用一人。”

　　在数据模型中需要将基数规则和参照完整性等业务规则表达为实体间的关系。结合上面提到的例子,可将公司和个人的关系表述如下:

　　　　• 每个人可以为0到多个公司工作。

　　　　• 每个公司必须聘用1个或多个人员。

　　关系标签是用于描述两个实体之间业务规则的动词短语,伴随着一些用于描述基数关系和参照完整性关系的用语。

　　两实体间的关系可能有以下3种类型:

　　　　• 一对一的关系,指父实体有且仅有一个子实体。

　　　　• 一对多的关系,指父实体可能有一个或多个子实体。一对多关系是最为常见的关系。在某些一对多的关系中,子实体必须有父实体,但某些其他关系中,与父实体之间的关系成为可选的。在某些一对多的关系中,父实体必须至少有一个子实体,而在其他的一对多的关系下,与子实体的关系也成为可选的。

　　　　• 多对多的关系,指一个实体的实例可与其他实体的0到多个实例联系起来。反之亦然。

　　递归关系将同一实体不同实例关联起来。递归关系可有一对一、一对多以及多对多几种关系。

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

　　逻辑数据模型是数据需求和控制数据质量的业务规则的详细描述,通常用于支持特定用法的上下文环境(应用需求)。逻辑数据模型也不依赖于任何技术以及具体实施中的技术限制。一个逻辑数据模型通常从概念数据模型的拓展开始,将数据属性添加到每个实体。组织应该有命名标准以指导逻辑数据对象的命名。逻辑数据模型通过应用两种技术以转换概念数据模型的结构:范式化和抽象化。逻辑数据模型的示例如图5.4所示。

　　范式化是运用规则将业务的复杂性转化为稳定的数据结构的过程。只有对每个数据元素有更深的理解才能发现每个数据元素与其他数据元素间的关系。范式化的基本目标是保证数据元素仅在一个位置出现。

　　范式规则根据主键和外键整理数据元素。范式规则可归类到不同层次,对每一个层次可应用更细的粒度和规范性来搜索正确的主键和外键。这样每一个层次都可以包含一个独立的范式,并且包含前面所有的层次。标准层次包括:

　　　　• 第一范式(1NF)——确保每个实体都有一个有效的主键,每个数据元素都依赖于主键,而且消除冗余的分组,以确保每个数据元素的原子性(不能有多个值存在)。

　　　　• 第二范式(2NF)——确保每一个实体都有最小的主键,每一个数据元素都依赖于完整的主键。

　　　　• 第三范式(3NF)——确保每一个实体都没有隐藏的主键,并且确保每个数据元素都不依赖于主键之外的数据元素(即,依赖且仅依赖于完整的主键)。

　　　　• Boyce/Codd范式(BCNF)——解决了交叉的复合候选键的问题。候选键是主键或者是备用键。“复合”表示有多个(例如，一个实体主键有两个数据元素)，“交叉”是指键与键之间隐藏着业务规则。

　　　　• 第四范式(4NF)———将所有三元关系分解成二元关系,直到这些关系不能再分解成更小的部分。

　　　　• 第五范式(5NF)——将实体内部的依赖关系分解成二元关系,所有联结依赖都部分使用主键。

　　　　• 第六范式(6NF)——在主键上增加了临时对象,以根据时间针对历史数据做报表和分析进行。

　　范式模型这个术语通常表示数据达到第三范式。BCNF 、4NF、5NF 以及6NF很少出现;它们往往都被认为是数据建模的高级主题。

　　抽象化是对实体数据、元素和关系的重新定义,通过消除细节以拓展数据结构使之能应用到更广的范围,通常会使用超类而不是子类。比如,使用通用的当事人角色超类以代表客户、雇员以及供应商等子类就是应用抽象的例子。

　　使用范式可以反映实体细节。抽象是在实体某些细节丢失或还未发现的情况下﹐或是实体通用版本比子类更重要和更有用的情况下使用。

　　1）属性

　　属性是实体的一种特性,对于业务是非常重要的事实的分类,其值有助于确认或者描述实体实例。例如,“Student Last Name”这一属性就描述了每个学生的姓氏,在物理数据模型中可将属性转换到文件的域或数据库基表的字段。属性一般使用业务名称;而域和字段则使用技术名称,且常常包括技术缩写。在逻辑数据模型中,业务实体就是组织的词汇表中必需的名词,而属性则代表形容词。

　　逻辑模型中的属性应具有原子性。它包括且仅包括一小片数据(事实),而且无法分解成更细微的数据片。例如，一个被称为电话号码的概念数据元素可分解成多个逻辑数据元素以对应不同类型的电话号码(家庭、办公室、传真,移动电话等)，国家代码(1代表美国和加拿大),地区代码、前缀、总机号、分机号。

　　属性的实例即是特定实体实例中属性的取值。属性被赋值就是实体实例的属性被实例化。例如,“60106”就是数据元素“Customer Employee Zip Code”的实例,它存在于客户实例Bob中。

　　对于在任何数据模型中的业务价值来说,实体和属性的定义都非常重要。高质量的定义可以阐明业务词汇的含义,并提供严谨的业务规则管理实体关系。高质量的定义还能帮助业务专家制定明智的商务决策,也能帮助IT人员制定明智的应用设计决策。高质量的数据定义有3大重要特征:清晰、准确和完整。

　　2)域

　　属性取值的完整集合即为域。一个属性不能在其对应的域之外取值。部分域对于具体的取值定义有数量限制,或者对取值的数量有最大值和最小值的限制。业务规则也可以限制域。

　　属性往往共享相同的域,例如,员工的雇用日期和采购订单的日期定是:

　　　　• 有效的日历格式(例如,不能是“2月31日”)。

　　　　• 日期属于工作日。

　　　　• 日期不属于节假日。

　　数据辞典包括域的集合及与每个域相关联的属性等,不一而足。

　　3）键

　　实体的属性既可以属于键也可以不属于键。关键的数据元素有助于从所有实体实例中识别唯一的一个实体实例,既可以只使用该关键数据元素,也可以部分使用该关键数据元素(即联合其他的关键数据元素)来识别。非关键的数据元素可用来描述实体实例,但无助于唯一地标识实体实例。

　　键(或候选键)代表一个或多个属性,其取值能够唯一地确认一个实体实例。复合键包括两个或多个属性。候选键中有且仅有一个主键,而其他所有的候选键会成为备用键。

　　为避免使用复合主键,或关键属性的取值将来会改变,则可以使用代理键(SurrogateKey),也称为逻辑键。代理键包括随机生成的一个唯一值,并仅将其分配给一个实体实例。代理(surrogate)是指替代( substitute),若一个实体中确实存在唯一的数据元素或者数据元素集合,那么就可以使用自然键。代理键也被称为匿名键或者非智能键。请注意:简单使用序列号也存在一定程度的智能。例如以序列号为主键将人员记录插入基表,则可以使用序列号对人进行区分,这其实等同于行号。真正的代理键是随机、非顺序的。

　　外键是能够将某一实体关联到其他实体的属性。简单来说,外键是当两个实体存在关联时,而同时出现在这两个实体中的属性,并且外键能部分或全部地识别其中一个或者两个实体。当两个实体间存在一对多的关系,子实体会继承父实体主键属性。外键的定义使我们能够在数据结构间导航。

　　当父实体外键属性成为子实体的复合主键一部分时,它们之间就存在明确的关联(Identifying Relationship)。而当父实体外键与子实体主键属性无关时,它们之间就不存在明确的关联。

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

　　物理数据模型可以根据技术约束,应用方法、性能需求和建模标准等来优化详细的数据需求和业务规则的实施工作。设计关系数据库需要考虑特定的数据库管理系统能力(IBM的DB2或者UDB、Oracle,Teradata、 Sybase, Microsoft SQL Server或Access)。组织应通过一定的命名标准来指导物理数据对象的命名。图5.5是物理数据模型的示例。

　　物理数据模型的设计需要决定以下事务:

　　　　• 每个表和列(关系数据库)，或文件和字段(非关系数据库),或模式和元素(XML数据库)的技术命名。

　　　　• 每个列或字段的逻辑域、物理数据类型、长度和非空属性。

　　　　• 每个列或字段的任何默认值,特别是针对非空限制。

　　　　• 主键和备用唯一键及索引,包括怎样分配键。

　　　　• 根据逻辑模型建立小的参考数值集合,例如①单独的代码表,②一个全局共享的主代码表,③简单地用规则或限制条件。

　　　　• 当子类实体属性作为可空的列合并到代表超类实体的基表中,或者将超类的属性压缩到可以代表所有子类的一个基表中,这时在物理数据库设计中可以使用较少的超类/子类逻辑模型实体。

　　在之后的表述中,术语“表”是指表、文件或XML模式;“列”是指列、字段或XML元素;而“行”是指行、记录或实例。

　　可用如下一些技术将逻辑数据模型转变为物理数据建模。

　　　　• 去范式化——有选择地和有理由地违反范式规则,在数据模型中重新引入数据冗余以减少数据获取时间,尽管有可能需要耗费额外的存储空间,额外的插入/更新时间,以及降低数据质量。

　　　　• 代理键———代理键在业务中不可见。

　　　　• 索引—创建额外的索引文件来优化特定类型的查询。

　　　　• 分区——垂直(按列分组)或水平(按行分组)分解表格或文件。

　　　　• 视图——虚拟表用于简化查询,数据访问控制和列的重命名,不会像去范式化导致数据冗余和损失参照完整性。

　　　　• 维度——创建事实表与相关的维度表,按照商务智能的需要使用星型模型和雪花模型(见第9章)。

2.4 详细的数据设计

　　详细的数据设计活动包括:

　　　　• 详细的物理数据库设计,包括视图、函数、触发器和存储过程。

　　　　• 其他可支持的数据架构,如 XML模式和对象类。

　　　　• 信息产品,如在屏幕展示和报表中的使用数据。

　　　　• 数据访问方案,包括数据访问对象、整合服务及报表和分析服务。

　　数据库管理员(DBA)在数据库设计中起领导作用,在设计信息产品设计(XML模式、消息、屏幕展示和报表)中以及相关数据服务(数据访问服务﹑数据整合服务以及商务智能服务)中起配合作用。数据分析师在设计信息产品和相关数据服务中起领导作用,而在数据库设计过程中则起配合作用。

2.4.1 设计物理数据库

　　物理数据库详细设计包括数据库实施的详细说明书。物理数据库的设计可能需要利用特定的数据库管理系统所特有的功能和能力,这些是不一定包括在数据模型本身中的。

　　对于关系型数据库,最主要的设计交付物是DDL(数据定义语言)说明书。DDL是结构化查询语言(SQL)的子集,用于创建基表、索引、视图和其他物理数据库的对象。对于XML数据库来说,最主要的交付物是命名空间。

　　一个完整的高质量数据库设计文档不仅仅是 DDL语句。5.2.4节第1部分下的第3)条描述了一份完整的物理设计文档。

　　无论 DBA是否在物理数据建模过程中协同工作, DBA负有详细数据库设计的主要职责,包括:

　　　　• 确保设计能达到数据完整性的要求。

　　　　• 确定以最合适的物理结构来存放和组织数据,如关系型或其他类型的数据库管理系统(DBMS)、文件、OLAP多维数据集、XML等。

　　　　• 确定数据库资源要求,如服务器尺寸和位置、磁盘空间需求,CPU和内存的需求以及网络需求。

　　　　• 为数据结构创建详细的设计说明书,如关系型数据库表、索引、视图,OLAP 多维数据集、XML模式等。

　　　　• 确保满足性能要求,包括对于查询、插人,更新和删除的批量操作和在线处理的响应时间要求。

　　　　• 对于数据备份、恢复、归档和清除过程的设计,确保能满足可用性要求。同时,确保数据库维护操作在可用时间窗口内能够完成。(参见第6章)

　　　　• 设计数据安全的实施方案,包括身份验证、加密需求、应用角色以及数据访问和权限更新。总体原则是决不能将数据对象授权给单个用户,而仅授权给角色。能够根据需要将用户移动到角色内或角色外,这能极大地简化维护操作并提高了数据安全性。（参见第7章)

　　　　• 在适当情况下确定使用分区和哈希模式。

　　　　• 要求SQL代码评审,从而确保SQL代码能符合编码标准,并高效运行。

　　1)物理数据库设计

　　在架构和技术的选择基础上选择如何进行数据库设计。可基于以下几点考量要素来选择架构(例如,关系型,层次型、网络型、面向对象型、星型模式、雪花模式,多维数据集模式等):

　　　　• 数据是否需要更新,更新频率如何。

　　　　• 数据的自然组织。

　　　　• 数据如何展现和使用。

　　实施技术(如,关系型,XML、OLAP或者面向对象等技术)的选择可能会取决于很多不同的因素,包括数据需要保存多长时间,它们是否需要与其他数据整合或者跨系统和应用边界进行传递,以及对于数据安全性、完整性、可恢复性、可访问性和可重用性的要求等。

　　也可能有组织和政策的因素,包括由于组织不同和开发者技能偏好,会导向特定的技术或供应商。其他影响物理数据库设计的因素包括:

　　　　• 采购和使用许可权需求,包括DBMS、数据库服务器、任何客户端侧的数据访问及报表工具。

　　　　• 审计和隐私要求(如 Sarbanes-Oxley、PCI、 HIPAA等)。

　　　　• 应用要求,如,数据库是否必须支持一个Web应用或Web服务,或特定的分析或报表工具。

　　　　• 数据库服务等级协议( SLAs)。

　　数据库设计者必须找出下列问题的答案,包括:

　　　　• 性能要求如何?允许查询结果返回的最长时间,或者允许一组关键数据更新所用的最长时间。

　　　　• 数据库的可用性要求如何?用于执行数据库操作的时间窗口如何?数据库备份和事务日志备份频率如何(即,我们所能忍受的数据不可恢复的最长的时间)?

　　　　• 数据库尺寸的预期多大?数据增长速率的预期多大?在什么时间点可以将旧的或不用的数据存档或删除?预计有多少并发用户?

　　　　• 数据库需要什么样的虚拟化技术来支持应用要求,以使应用与数据库模式之间不存在紧耦合关系?

　　　　• 将会有其他应用程序需要使用这些数据吗?如果有,需要哪些数据?又是如何使用的?

　　　　• 用户希望使用数据做实时查询和报表吗?如果是这样,如何使用?且使用何种工具?

　　　　• 有需要数据库实现的业务或应用流程吗?(如,用于跨数据库完整性检查或更新的触发器代码,封装成数据库过程和函数的应用类,为简化使用或保证安全而提供的数据库基表组合而成的视图等。)

　　　　• 是否存在与数据库或数据库开发流程相关的应用程序,以及开发人员需要注意的问题?

　　　　• 应用程度代码是否高效?代码变更会消除性能问题吗?

　　在设计和创建数据库时,DBA需要牢记以下设计原则(缩写为PRISM)。

　　　　• 性能和易用性(Performance and Ease of Use)确保让已被批准的用户在一个好用的且与业务相关的形式下快速并简便地访问数据,使应用程序和数据的业务价值得到最大化。

　　　　• 重用性(Reusability)-在适当情况下,数据库结构应当确保多个应用程序能够使用这些数据。数据库结构同时应该确保多个业务目的(如商务分析,质量改善、战略规划、客户关系管理和流程改进)能够使用这些数据。避免将-个数据库,数据结构或者数据对象耦合到单个应用。不要将一个应用程序紧耦合到一个数据库!数据应当反映真实的业务实体和属性,而不是单个应用程序的需求。

　　　　• 完整性(Integrity)——数据应该始终存在有效的业务含义和价值,不管上下文如何,都应始终反映有效的业务状态。数据库设计尽可能地保持与数据的紧密联系以保证数据完整性,同时迅速地发现并报告数据完整性约束被违反的情况。

　　　　• 安全(Security)——真实和准确的数据需要及时地并只能由授权用户使用。隐私保护需要考虑所有的利益相关者,包括客户、业务伙伴和政府监管机构的需求,而且他们的需求都要被满足。加强数据的安全性,就像数据完整性一样,尽可能与数据保持密切关系,立即发现并报告违反安全性条件的行为。

　　　　• 可维护性(Maintainability)———所有数据工作都有成本,但也产生价值;要确保创建、存储、维护、使用和部署数据的成本不能超出其价值。确保以可能的最快的速度响应业务流程改变和新业务需求。

　　下面是一些对于物理数据库设计最佳实践的建议:

 　　　（1）对于使用关系型数据库支持事务处理(OLTP)的应用,可使用符合范式的设计以提升数据的完整性、可重用性、良好的更新性能和数据可扩展性。

　　　　(2）同时,使用视图、函数和存储过程来创建非范式的,应用特定的,对象友好、概念(虚拟化)视图的数据。不要强制开发人员在物理数据库级别工作,也不要将数据库模式与应用程序紧耦合。

　　　　(3）对于整个数据库和数据库实体对象都使用标准的命名规则以及有意义和描述性的名字,以简化维护工作,特别是当必须使用缩写时。

　　　　(4）在数据库级别,而不是在应用程序级别对数据的安全性和完整性进行强制要求。这能使数据重用较为容易,同时也让开发人员不需要在每一个应用程序为了使用一小块数据时而编写和测试代码级的限制条件。

　　　　(5)尽可能在数据库服务器端对数据进行处理,以最大化性能,简化维护,提高安全性、可扩展性,减少网络流量,并降低开发成本。例如,在数据库端执行所有的数据库更新和并将复杂的SQL查询编写成数据库中的存储过程,而不是将其嵌入到应用代码中,并使用服务端(而不是客户端)游标。使用存储过程可以轻松地隔离和修复错误以及性能问题,增强性能,极大地减少网络流量。

　　　　(6）仅对应用程序组或角色授权数据库对象(基表、视图、存储过程、函数等),而不是对单个用户授权。这提高了安全性,并简化了维护。

　　　　(7)决不允许对数据库进行任何直接的、即席的更新;所有的更新都应在控制方式下，通过预先定义的流程进行。

　　2）性能调优

　　在物理数据库的实施中,需要考虑当应用程序提出访问和修改数据的请求时数据库的性能如何。有若干种技术可用于优化数据库性能。

　　在很多情况下,索引可以提高查询性能。数据库设计者必须为数据库表选择和定义合适的索引。对于在数据库中访问数据而言,索引是一个可替代的路径以优化查询(数据检索)功能。主要的关系型数据库管理系统(RDBMS)产品支持很多的索引类型。索引可以是唯一或者不唯一的,聚族或非聚族,分区或非分区,单列或多列,B树,位图或是哈希的。如果索引不合适,数据库管理系统(DBMS)会重新考虑读取基表中所有行(全表扫描)来获取数据。对于大表,这是非常消耗资源的。可尝试使用最常被引用的列,特别是键(主键,备用键和外键)在大表上创建索引以支持最常被运行的查询。

　　去范式化是将符合范式规则的逻辑数据模型经过慎重考虑后,转换成一些带冗余数据的基表。换句话说,它有意地将一个数据元素放在多个位置。这-过程会因为数据冗余而引入数据错误的风险。因此需要进行数据质量检查确保数据元素的副本被正确地存储。只有当去范式化明显能提高数据库查询性能,数据的拆分和组合能降低查询结果集的大小,数据的组合可以减少表查询联接和数据计算的执行和存储时才采用去范式化。去范式化技术包括但不限于:

　　　　• 合并层次(向上汇总)—一为减少联接查询,可在子表中的每一行重复父表的列,从而将父/子关系组合到一张基表中以形成直接访问路径。这是多维建模中的主要工具(参见第9章)。

　　　　• 分解层次(向下细化)——为减少查询返回的结果集,可按照不同类型将父表分解成多个子表。例如,为不同类型的客户,如支票、贷款、投资等,各创建一个基表。

　　　　• 垂直分割---一为减少查询返回的结果集,可根据列的不同为某表创建子集。例如，将客户表分割成两张表,分别基于相对静态的字段或相对易变的字段(以提高加载/索引性能),或基于查询中常见和非常见字段(提高全表扫描性能)。

　　　　• 水平分割——为减少查询返回的结果集,可使用某列的取值作为区分标志将某表分割成不同子集。例如,创建包括特定区域客户的区域性客户表。

　　　　• 组合和预联接表——如果存在大量对两表进行联接查询,为了降低联接查询次数，可考虑创建一个已包括两表联接查询结果的基表。

　　　　• 在一行中重复列——为减少行数,或使行与行之间便于比较,可创建一个重复列的表。例如,与其对于用12行来记录12个月的数据,还不如在表中设置12列,每月对应1列。

　　　　• 从存储数据中提取数据——在查询时减少计算成本,特别是计算需要从不同表获取数据,可以使用预计算列,并将计算结果存人基表,可以是一个新表,也可以是参与计算的某张表。

　　　　• 创建报表副本——为提高报表性能,可以创建一张基表以包含报表所需的所有元素,这些元素已经计算过并联接在一起,而且可周期性地进行更新。

　　　　• 创建副本(镜像)-——如果某些数据集被经常使用且常常存在竞争,为改善系统性能,可以为相互独立的用户组创建副本。为了改善加载和查询的性能也可以使用同样的方法。

　　3）物理数据库设计文档

　　物理数据库设计文件指引数据库的实施和维护。通过回顾设计文件可以在创建和更新数据库前发现和纠正设计中的错误。通过修改设计文件,可简化未来设计迭代更改的实施过程。一个物理数据库设计文档包括以下几个部分。

　　　　• 数据库设计中业务功能的介绍性描述,例如,数据库设计包括业务数据的哪些方面或哪些子集?

　　　　• 图形化的设计模式,通过ER图形式来设计关系型数据库,或者用UML,的形式实现面向对象的数据库设计。

　　　　• 数据库语言相关语句。在结构化查询语言(SQL)中,数据定义语言(DDL)用于定义所有的数据库对象(表空间、基表、索引、索引表空间、视图,序列等以及 XML命名空间)。

　　　　• 以文档记录技术元数据,包括数据类型、长度、域、源和每一列的用途,以及键的结构和每一张表相关的索引。

　　　　• 用例或样本数据,可以表现实际上所看到的数据的样子。

　　　　• 简要描述,根据需要,用于解释:

　　　　　　◆ 所选择的数据库架构和技术,以及选择的原因。

　　　　　　◆ 影响选择数据库管理系统的限制条件,包括成本限制、策略限制,性能限制、可靠性和可扩展性的限制、安全限制、应用限制、预期数据量等。

　　　　　　◆ 数据库设计流程,包括使用的T具和方法。

　　　　　　◆ 物理数据库设计和逻辑数据模型设计两者之间的不同,以及存在这些不同的原因。

　　　　　　◆ 所选数据库的更新机制及其实施。

　　　　　　◆ 数据库的安全需求及其实施。

　　　　　　◆ 数据库的服务水平协议(SLA)及其实施。

　　　　　　◆ 数据库的用户和应用需求及其实施。

2.4.2 信息产品设计

　　数据库设计是数据开发的焦点,数据专家同时也应该参与到相关的数据交付物设计中。数据分析师可以在屏幕展示和报表等方面帮助信息产品设计过程中的软件设计者和开发者进行设计,以满足业务数据需求。数据分析师应确保业务数据术语的一致性使用,并确保在表现形式上增加合适的上下文环境以方便数据生产者和信息消费者使用数据。

　　数据库管理员通常协助应用开发,让业务用户和管理者能在更加好用的表单中使用更加稳定可用的数据。许多令人激动的新技术都是为了这个目的,所以数据库管理员应该熟悉它们。

　　　　• 报表服务一—让用户既能够执行通用的报表,也可以使用自定义的特设的报表,并且让数据以不同形式交付给用户使用,比如,通过邮件或者RSS feed交付(发布)，通过浏览器或者门户访问,将数据抽取到Excel电子数据表格,等等。

　　　　• 分析服务——分析服务使业务用户可从多个业务维度进行“切片和分块”(slice anddice)，比如从多个地域/日期/时间方面分析产品或产品分类的销售趋势。同时也包括“预测分析”( predictive analytics),即分析数据以识别未来趋势和潜在的商业机会。

　　　　• 仪表盘-——是一种用于有效地显示很多分析指标的用户界面，比如图和表(chartsand graphs)。用户可以钻取(drill down)这些指标以查看指标所依赖的数据。

　　　　• 记分卡---是用于展示绩效得分或经过计算的评估结果的一种特殊类型的分析显示方式。记分卡通常包括实际值(量度结果),目标和预测(基线)得分(量度与基线的比较结果)以及指数(可视化展现得分有利或者不利)。

　　　　• 门户网站—一是在一个设计精良,易于访问的Web页面基础上,综合展现众多应用系统链接和多个信息源。门户网站聚集了大量有着不同信息需求的分散用户,并且基于共同的兴趣为用户创建了一个“社区”( community)。门户网站也让用户能够共享文件、搜索文档库、进行讨论和项目合作。

　　　　• XML交付—一在数据库和应用中有效利用XML,常常需要创建模式定义。这些定义可以用于校验XML文档、XML转换(用XSLT把 XML转化成HTML,或者其他格式)以及数据库对象。需要校验的数据库对象包括视图,存储过程以及检索XML文件的函数,将XML 数据转化为关系形式(反之亦然)，合并关系型数据和XML格式的数据。

　　　　• 业务流程自动化——将多个数据库整合的数据作为业务流程自动化软件的输入,用于协同不同的平台上的业务流程。

　　　　• 应用集成——同样的,数据整合(包括核心组件、数据转换和清洗)是企业应用集成(EAI)软件的关键组成部分,使得数据可以容易地跨不同平台在应用系统间传输。

　　数据库管理员所涉及的与信息产品开发相关的工作包括数据分析、创建支持这些产品的数据结构(例如XML模式,OLAP 多维数据集或者数据集市)和数据库对象,帮助进行数据整合和数据交付。

　　数据库管理员可以帮助软件开发者创建和维护数据库访问语句。在结构化查询语言(SQL)中,这些语句就是数据操作语言(DML),包括查询(SELECT),插人(INSERT)、更新(UPDATE)以及删除(DELETE)语句。数据库管理员经常会对这些语句进行评审,推荐其他可用方法和为性能调整进行一些修改。

　　在面向服务的架构(Service-Oriented Architecture,SOA)中,数据库管理员可能与软件设计者和开发者在设计数据访问层服务时合作。数据访问服务是为了使数据访问标准化，并将数据库变更与应用程序相隔离。

2.4.3 数据访问服务设计

　　通常我们希望,也有必要访问远程数据库中的数据,并将其与本地数据库中的数据相合并。现有几种机制可以实现,而DBA应当对于每个机制的长处与短处非常了解。访问和重用远程数据的最常见的方法如下。

　　　　• “链接服务器”(Linked Server)型连接——某些 DBMS允许你把远程数据库服务器定义为“链接服务器”,并通过一个ODBC或者OLE/DB连接来访问它们。这种方法有快速、简便以及价格低廉等优势。但是,也有一些注意事项需要牢记:

　　　　　　• 这种连接只有有限的功能;一般仅限于执行一个定义为字符串或存储过程的硬编码查询。

　　　　　　• 有可能产生安全问题。在定义这些连接的时候请不要将用户名和口令硬编码,且在目标服务器上只能开放所需数据子集的只读权限。

　　　　　　• 性能无法很好地扩展,只能获取相对较少的数据量。

　　　　　　• 数据请求工作在同步模式,要求调用程序一直等待,直到所有的数据返回。

　　　　　　• 这些连接依赖于供应商所提供的ODBC或OLE/DB驱动程序的质量(但实际上有时很糟糕)。

　　然而,这种方法有一个主要的优势:它很容易在数据库中实施,允许从数据库的视图、触发器、函数和存储过程访问远程数据。

　　　　• SOA Web Services——将远程数据访问封装成Web服务的形式,并在应用程序中调用。可以根据应用的需求,以同步或者异步的形式实现Web服务。这种方法大大提高了数据的可重用性,而且一般性能和可扩展性都很好。但是这种方法仍有一些缺陷:

　　　　　　• Web服务的编写、测试和部署更加困难,且成本较高。

　　　　　　• 组织可能会面临创造SOA的梦魔(SOA Nightmare)的风险,组织中会存在无数点至点的,应用特定的,不可重用的Web服务,而这些Web服务都需要得到维护以应对不断变化的数据库模式和位置。

　　　　　　数据库对象很难使用Web服务。它们通常必须被应用程序消费。一-些较新的数据库管理系统允许你将应用程序类封装成存储过程或者功能;但是,此方法不适用于视图。

　　　　• 消息代理——某些DBMS(如微软SQL Server 2005)允许在数据库中实现消息服务。在一个数据库中的一个存储过程或函数可以将消息发送到其他数据库中,从而执行查询,存储过程或函数,并异步地将结果返回给调用程序。这种方法比较容易实现,也可靠、具扩展性,而且性能也不错。但是,它只能在相同类型的 DBMS 的实例间工作。

　　　　• 数据访问类——使用ODBC或OLE/DB连接编写应用程序类来访问远程的,不同的服务器上的数据,并提供给应用程序。在.NET 环境中,这些数据可以存储在内部作为ADO.NET的数据包对象(一类内存数据库),为简化访问并获得更好的性能。类似的第三方和开源技术也存在于UNIX/Linux和Java应用中。

　　　　• ETL——如果从数据源访问数据不能在技术灵活性上得到满足,或基于性能考虑不能访问数据源的话,有不同的 DBMS和第三方ETL工具可以弥补这个差距。这些工具从源方提取数据,进行必要的转换(例如,重新格式化和清洗),或者加载到数据库中的一个只读表,或将结果集交给调用程序或者应用程序。ETL可以通过一个存储过程或函数来执行DBMS 的ETL包,并按照周期性的时间间隔来计划执行。主要缺点是面对大量的数据记录时,ETL工具的扩展性和性能不是很好,对于长期维护可能比较困难并且成本高昂。

　　　　• 复制——从一个数据库环境到另一个环境传输数据的另外一种选择是使用时复制。大多数DBMS支持一些复制技术(例如镜像和日志传输),尽管这些技术要求源和目标服务器是相同的 DBMS。对于跨不同平台或DBMS的复制,更多自行开发的复制解决方案也是可行的。例如,在一个平台上通过批处理程序可以将数据抽取到磁盘上的一个平面文件中。该文件可以被复制(使用FTP或类似机制)到目标服务器,然后通过另一个批处理进程加载到目标数据库中。目前的挑战是保证时机正确(例如,确保数据在被需要前达到目标服务器),并确保在复制过程中发生的任何故障得到及时发现和报告。请注意,如果复制的数据在目标服务器上被更新(尽可能避免这种情况),一个安全可靠的机制必须将这些更新复制回源服务器,理想情况下可以通过一些两阶段提交进程完成。

　　　　• 位置合并——作为最后的手段,可能需要将源数据库和目标数据库放在同一个数据库服务器(或DBMS的实例)上。显然,这不是一个理想的解决方案,因为它将两个数据库紧耦合了。它仅适用于两个数据库中的数据在业务含义和用法上相同,而且所需要的数据量(或访问频率)在其他的解决办法无法满足的情形。

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

2.4.4 设计数据整合服务

　　数据库事务是可恢复工作的原子单元。一个事务可以包含多个数据库指令。当事务的所有步骤完成时，“提交命令”被执行令所有的变化生效。在提交的时间点之前,这些更新都可以被回滚。一个事务是原子性的,这就意味着要么全部执行,要么什么也没有执行。事务会执行所有指令,或者撤销所有指令。应用程序开发人员可以根据决定何时提交更新来定义数据库事务。

　　数据库设计的一个重要方面是确定适当的更新机制。当多个用户可以并发更新基表，则需要实施一些并发控制机制,以确保两个用户无法在同一时间更新同一记录。这通常需要在每个表中添加一个属于日期类型的数据元素—“时间戳"(timestamp)或“日期时间”(datetime),从而确保该字段的值在记录修改之前被检查,而且当该记录被修改后随即更新。

　　通常使用锁来保证数据的完整性,在一个时间点仅允许一-个用户修改一条数据库记录。数据锁存在不同的级别,名为锁的粒度。数据库管理员为每个数据库对象,如列,行,页、表、文件或数据库确定合适的锁类型。

　　数据分析和数据整合专家为ETL(extract-transform-load,抽取-转换-加载)程序和其他技术定义源和目标之间的映射,以及数据转换设计来执行数据的移动、清理和整合。DBA可能协作完成此设计活动。

　　数据分析师、数据整合专家和数据库管理员也会为从旧的数据结构转换为新的数据结构而设计数据迁移和转换的程序和实用工具。

　　有多种方法可用,但任何方法的选择都必须满足以下条件:

　　　　(1)在受控制的方式下进行数据库更新。不允许直接、即席地更新数据库。

　　　　(2)将与特定业务流程相关的所有更新作为工作的一个单元进行管理,可提交或全部回滚事务,这也叫做事务的完整性。不允许发生数据库部分更新。

　　　　(3）不允许两个或多个用户同时更新同一记录,这也被称为并发控制。

　　　　(4）立即中止当前事务并回滚更新的错误,并立即将错误报告给调用程序或应用程序。(5）仅将更新特定的数据库表的权限授权给一组用户(包含一个或多个用户角色)。(6）一次事务中尽量将更新限制到很少的数据记录,以防止表的过度锁定,以及因为回滚大量更新导致的应用程序挂起(Hanging).

　　可以考虑以下可能的更新机制:

　　　　• 基本存储过程(Fundamental Stored Procedures,FSPs)——每个 FSP在一张数据库基表中通常根据一个或多个键值来确定对有限的数据记录实施一个操作(插人、更新、删除或查询)。如果要用FSP,可以从物理模型或从数据库架构自动生成它。这大大减少了实施数据库所需要的时间,可以更容易地修改模式以应对新的需求。

　　　　• 应用数据层—编写-一个应用程序组件调用数据库中的存储过程或FSP并跨多表执行更新。建议用性能更佳的存储过程,因为SQL代码是预先编译和预先优化的。它们也更加安全,因为只有指定的用户能执行它们,而表不能开放,因为要防范SQL.注入攻击。它们更易于维护,而且错误或性能问题可以很容易地被发现和纠正。·数据集更新——通过一个数据适配器(Data Adapter)对象在应用程序中更新数据集或数据基表中的记录,而这个数据适配器可以关联一组存储过程,来执行插人,更新、删除和查询操作。

　　　　• 可更新的视图—在一些关系型 DBMS中,视图可以与触发器关联并以可控制的方式处理关联基表的更新。正如 FSP,建议通过自动生成代码的方式,以减少或消除编码、测试和维护的时间。

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

　　数据分析师和设计人员是信息消费者(对数据有业务需求的人)与数据生产者(在可用表单中定义数据的人)之间的中介。数据专业人员必须兼顾信息消费者的业务数据需求,包括中高级管理人员,以及数据生产者的应用需求。系统需求文档以用例,应用类模型及服务水平协议(SLA)等形式记录应用数据需求。

 　　数据专业人员必须平衡短期和长期业务利益。信息消费者需要及时得到数据信息以满足短期的业务责任和把握住当前的商业机会。系统开发项目团队必须满足时间和预算的限制。但是,也必须确保组织数据对应的数据架构是安全的、可恢复的,可共享的和可重用的，并且这些数据都是正确、及时、相关和尽可能好用的,从而满足利益相关者的长期利益。因此,数据模型和数据库设计应该在企业短期需求和长期需求之间做出合理的平衡。

2.5.1 开发数据模型和设计标准

　　数据建模和数据库设计标准作为实现业务数据需求,符合数据架构,确保数据质量的指导原则。数据架构师、数据分析师和数据库管理人员必须共同开发这些标准。而设计标准可以对相关IT标准进行补充但是不能与之冲突。

　　为每种类型的建模对象和数据库对象发布数据模型和数据库命名标准。实体、基表,属性、键、视图和索引的命名标准非常重要。命名既要特别,又需要尽可能地描述准确。

　　逻辑名称应该是对业务用户有意义的,应尽可能多地使用完整的单词和避免所有缩写，除了最熟悉的缩写以外。物理名称必须符合 DBMS 所允许的最大长度,必要时可使用缩写。逻辑名称使用空格作为单词之间的分隔符,而物理名称通常使用下划线作为单词之间的分隔符。

　　命名标准应尽量减少在不同环境中的名称变化。名字不应该反映其特定环境,如测试、质量保证或者生产。分类词可用以区别属性和实体,列名和表名。分类词还可用于显示哪些属性和列,是定量的而不是定性的,这在分析这些列的内容时是很重要的。

　　数据建模和数据库设计的标准应包括:

　　　　• 标准数据建模和数据库设计成果清单及相关描述。

　　　　• 适用于所有数据模型对象的标准名称、可接受的缩写、非常规用词缩写规则的清单及相关描述。

　　　　• 所有的数据模型对象的标准命名格式清单,包括属性和列的分类词。

　　　　• 用于创建和维护这些成果的标准方法清单和描述。

　　　　• 数据建模和数据库设计的角色和职责清单及描述。

　　　　• 数据建模和数据库设计中捕获的所有元数据属性清单和描述,这包括业务元数据和技术元数据以及定义元数据质量的预期和需求指南。

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

　　　　• 准备和引导设计评审的指南。

2.5.2 数据模型和数据库质量设计的评审

　　项目组应当适时开展需求及设计评审。这些评审应当包括概念数据模型评审,逻辑数据模型评审以及物理数据库设计评审。

　　由代表着不同背景.技术、期望以及观点的一组主题域相关专家开展的设计评审活动，应当能够在与个人矛盾无关的前提下讨论不同的观点,并在小组内达成一致,前提是所有参与者目标一致,以推动最具有实践性、表现最佳以及最适用的设计。每次的设计评审都应设置一位组长来推动会议进行。组长负责制定及推动会议进程,来确保所需的文档都可用并分配到人,征求所有参与者的意见,维持秩序确保会议正常进行,总结概括组内的一致意见。设计评审应当有记录员来记录讨论中的要点。

　　1)概念和逻辑数据模型评审

　　概念及逻辑数据模型评审应当确保;

　　　　(1)业务数据需求能够完全被覆盖,而且在模型中清晰地表达,包括约束实体间关系的业务规则。

　　　　(2)业务(逻辑)名称、实体和属性(业务语义)的业务定义能够清晰、切实、一致及互补。在表达名称及相关说明时应当使用相同的术语。

　　　　(3)遵循数据模型标准及命名标准。

　　　　(4)验证概念及逻辑数据模型。

　　2)物理数据库设计评审

　　物理数据库设计评审应当能够确保:

　　　　(1)设计满足业务、技术、用途以及性能的需求。

　　　　(2)遵循数据库设计标准,包括命名及缩写规则等。

　　　　(3）参照标准定义可用性、恢复、归档以及清除过程。

　　　　(4）满足元数据质量预期及需求,以达到适时更新元数据存储库的目的。

　　　　(5）验证物理数据模型。

　　所有涉及到的利益相关者,包括DBA小组、数据分析师/架构师、业务数据所有者或者数据资产管理人员,应用开发人员、项目经理,应当评审并批准物理数据库设计文件。完整的设计文件应当作为数据库交付生产运营成果的一部分。

　　3)数据模型验证

　　以建模标准、业务需求和数据库需求来验证数据模型。以下为一些模型验证的问题范例:

　　　　• 模型能否与应用模型标准相匹配?模型是否采用标准化的数据辞典术语?模型是否使用标准域?模型是否在所有的适用列中采用分类词后缀?模型是否包括所有对象和关系的描述?模型是否在适用的情况下采用缩写规则?

　　　　• 模型是否满足业务需求?模型是否包括所有相关的数据项?能否通过数据库中执行所需的事务?能否正确无误地获得了事务内容?能否通过模型执行任何所需的查询?

　　　　• 模型是否与数据库需求相匹配?是否存在与数据库保留字相同名称的对象?是否所有的对象都有唯一的名称?模型是否为所有对象分配了所有者?

2.5.3 管理数据模型的版本及整合

　　数据模型及其他设计说明需要审慎的变更控制,就如需求说明及其他系统开发生命周期的交付物一样。数据模型的每一项变更都需要保留随时间推移的版本信息。如果变更涉及到逻辑模型,比如新增或修改业务数据需求,应该由数据分析人员或数据架构师评审和批准这些变更。

　　每次变更应当注明:

　　　　• 项目或情景需要变更的原因。

　　　　• 对象变更的内容及形式,包括添加、修改或删除了哪些表和列等。

　　　　• 批准变更的时间以及变更被应用到模型的时间。变更在系统中被实施的时间不需注明。

　　　　• 由谁完成变更。

　　　　• 变更在哪里(在哪个模型中)完成。

　　作为范式处理的一部分,变更可能需要在企业模型的多个部分同时完成。将任何模型作为范式处理的一部分,变更可能需要在企业模型的多个部分同时完成。将任何模型

　　一些数据模型工具包括提供数据模型历史版本及整合功能的存储库。如同应用程序代码类似,可以将数据模型保存在DDL输出或XML文件中,或在标准源代码管理(SCM)系统中校对数据模型。

2.6 数据项目实施

　　数据实施包含一系列支持系统建设、测试及部署的数据管理活动,包括:

　　　　• 数据库实施及在开发和测试环境中的变更管理。

　　　　• 创建测试数据,包括必要的安全程序,比如数据模糊处理。

　　　　• 开发数据迁移及转换程序,可用于通过系统开发生命周期管理开发的项目,以及公司业务合并、拆分的业务场景。

　　　　• 数据质量需求验证。

　　　　• 用户培训的建立及交付。

　　　　• 有效文档的开发。

　　设计完成后,DBA负责在开发及测试环境中实施所设计的数据结构。这些结构包括数据库基表或文件、视图、存储过程、函数、OLAP数据多维数据集,XSLT模式以及其他类似的对象。DBA负责数据库开发环境及其配置的变更控制。开发及测试环境的变更控制应当是类似的,甚至与生产环境所用控制程序相同。DBA应当使用相同的变更和配置管理工具,借鉴其他信息系统交付物的管理实践,来管理数据库设计说明书(DDL)文件的配置变化。

2.6.1 实施开发和测试数据库变更

　　由于数据库变更在应用开发的过程中是必需的,DBA既负责推进又负责监督这些变更。通常这些变更来自开发者。实施则根据开发者所承担的角色和职责不同而不同:

　　　　• 开发人员可能可以直接创建及更新数据库对象,例如视图、功能,存储过程,并通知DBA 及数据建模人员来评审和更新数据模型。

　　　　• 开发团队可能拥有他们自己的“开发DBA”,后者有权对模式进行修改,条件是这些变更应由 DBA 及数据建模人员评审。

　　　　• 开发人员可能与数据建模人员一起工作,由数据建模人员使用数据建模工具对模型进行修改,然后生成“变更的DDL”并由 DBA 来评审及实施。

　　　　• 开发人员可能与数据建模人员一起工作,后者可以在DBA评审及批准之后,使用数据建模工具的功能以交互的方式将变更推送到开发环境中。

　　如果正在采用迭代的开发方法(例如,敏捷开发),那其中的变更评审及批准工作、逻辑及物理模型的更新工作,可能需要被异步地完成。可以考虑通过口头批准的方式避免开发工作被中断,将模型的更新视为后续工作。然而,要注意确保数据库不会与逻辑模型失去同步,否则数据库可能因为与某个单个应用紧耦合而变成“烟道”。尽可能多地采用视图,存储过程、函数以及其他形式的数据虚拟化来实现特定应用的数据库需求。

　　DBA应当能够仔细地监控所有的数据库代码,以确保与应用代码采用相同的标准。所有的数据库代码应当能被很好地说明,且为可测试的(理想情况下,应包含内嵌诊断代码并可通过传递参数的方式触发),可理解的、与协议的标准相一致,并且容易维护。DBA应当能够尽早识别质量低下的SQL代码,以防止造成错误或性能问题,并且在存储过程或函数重复使用这些低质量SQL代码之前提醒开发人员的注意。如果能够在项目初期额外地多考虑一点,那么在后期会减少些痛苦。

2.6.2 创建和维护测试数据

　　DBA、软件开发人员以及测试人员可以相互合作,在开发环境数据库中生成测试数据。既可以生成测试数据,也可以抽取具有代表性的生产数据子集。他们还必须严格检查测试环境完全满足隐私和保密的需求,及时删除过时的、无用的以及不再需要的测试数据。

　　DBA 也可能需要协助开发人员生成SQL脚本和用于数据整合的包( packages)，比如生成DTS或者SSIS包,用来生成及维护测试数据。通常,这项工作主要是开发小组的职责,但开发小组可能需要也欢迎 DBA的专业知识。这也是 DBA 能够为开发工作增加价值的另外一种方式。

2.6.3 迁移和转换数据

　　许多项目中的关键部分就是将遗留数据迁移到新的数据库环境中去,包括必要的数据清洗和格式转换。这项工作非常重要,时间和成本的需求都不能被低估。这需要数据架构师和分析师对遗留数据模型和目标数据模型非常熟悉,DBA、业务人员和开发者也必须熟悉遗留的应用。取决于遗留数据存储在什么地方,数据迁移可能需要运用不同的技术,包括SQL、COBOL,UNIX脚本、DBMS整合包(比如 DTS或者SSIS之类)非关系型数据库管理系统,第三方ETL应用、数据整合Web服务、FTP,RPC、ODBC,OLE/DB等。一些数据迁移的工作可能需要成千上万个小时来完成。

2.6.4 构建并测试信息产品

　　包括DBA 在内的数据专家应该协调软件开发人员对系统所需要的信息产品进行开发和测试,其中包括:

　　　　• 整合来自多种源的数据实施机制,并通过使用合适的元数据来确保数据整合有意义。

　　　　• 报告和分析数据的机制,包括在线和基于 Web的报表、即时查询、BI记分卡、OLAP、门户网站等。

　　　　• 如果因网络时延或其他原因导致不能从单一数据源为所有用户提供服务,就要采取复制数据的实施机制。

　　软件开发人员负责编写程序代码并测试,包括数据库访问。软件开发人员也负责创建、测试和维护信息数据,比如界面和报表。其中测试工作包括单元测试、整合测试和性能测试等。

2.6.5 构建并测试数据访问服务

　　DBA要对数据访问服务的开发负责。DBA 协同软件开发人员开发、测试和执行数据访问服务,首先要关注开发和测试环境,然后是生产环境。

　　数据需求应该包括数据访问的业务规则,用于指导数据访问服务的实施,以及与软件开发人员的协同。业务数据管理专员和其他主题域的专家(Subject Matter Expert,SME)通过用户验收测试来验证数据访问需求及性能要求是否满足。

2.6.6 构建并测试数据整合服务

　　数据整合专家负责开发ETL程序和技术进行数据整合、数据迁移和数据结构转换。DBA协同软件开发人员开发、测试和执行数据迁移和转换程序,首先是在开发和测试环境，然后是生产环境。

　　数据需求应该包括数据质量相关的业务规则,引导应用编辑约束和数据库参照完整性约束的实施。业务数据管理专员和其他主题域的专家(SME)应通过用户验收测试来验证数据需求是否满足。

2.6.7 验证信息需求

　　在系统开发生命周期中数据专家的职责并不限于设计。他们应作为系统开发项目团队的一部分并通过持续的交流互动来完善设计。数据库管理人员在系统开发生命周期阶段尤为活跃。业务数据管理专员在分析和设计阶段之后继续参与开发,或者可以由独立的质量保证团队控制测试过程。主要工作就是验证解决方案是否满足需求,但同时也要注意规划部署、开发培训和文档说明。

　　在任何应用开发项目中,尤其是利用迭代(敏捷)法进行开发的项目,数据(和数据库)需求可能会突然改变,原因是要适应新的或变更的业务需求。如果数据的某些假设无效,现有需求的优先顺序需要调整。数据建模人员是开发人员与数据分析师/架构师之间的中间人，负责评审需求的增加或变更。数据建模人员需要在逻辑和物理数据模型中正确反映业务数据需求。DBA以最有效的方式将变更应用到数据库中。DBA 会同开发人员一起测试数据需求实施,并确保满足应用需求。

2.6.8 准备部署数据

　　当数据库管理员解决实施和测试中的技术问题时,数据分析师就可利用数据建模中所捕获的业务知识,在用户培训及说明文档中使用清晰和--致的语言对系统进行描述。即使数据模型本身并不作为教学示例,数据模型中的业务概念,术语,定义和规则都是应用用户培训的重要部分。数据管理专员通过定义数据模型来贡献其业务知识,他们也对系统的数据质量负责,同时作为数据流程和应用的所有者,他们负责系统及相关培训和文档的验收。这个过程应持续一致地使用他们的系统命名法。

　　数据管理专员和数据分析师也应该参与到部署的准备工作中,包括形成和评审培训材料以及系统文档,特别是确保已定义的业务数据术语的一致性应用,服务台的支持人员在系统用户如何正确访问、操作和解释数据方面也需要熟悉和接受培训。

　　DBA主要负责把新的和变更的数据库对象部署到生产环境(参见第6章)。对于生产环境,数据库管理人员应仔细控制新数据库安装和已有数据库的变更过程。一旦安装结束,业务数据管理专员和数据分析师也应该尽早监控系统,查看业务数据需求是否确实得以满足。

三、综述

　　在组织中实施数据开发的指导原则,每一个数据开发活动相关角色的总结表,以及在数据开发过程中可能出现的组织和文化问题,总结如下。

3.1 指导原则

　　在组织中实施数据开发职能需遵循如下9个指导原则:

　　　　(1)数据开发活动是构成整个软件开发生命周期的不可缺少的组成部分。

　　　　(2） 数据建模是有效地进行数据管理和系统设计关键技术。

　　　　(3）概念和逻辑数据模型表达业务和应用需求,而物理数据模型代表解决方案。数据建模和数据库设计定义了详细的解决方案组件规格说明。

　　　　(4)数据建模和数据库设计要平衡取舍和需求。

　　　　(5）数据专业人员协同其他项目组成员,共同完成信息产品、数据访问和整合接口的设计。

　　　　(6）数据建模和数据库设计应该遵从书面标准。

　　　　(7）为确保业务需求得以满足,设计标准得以遵从,设计评审工作应该检查所有的数据模型和设计。

　　　　(8） 数据模型代表有价值的知识资源(元数据)。应该通过模型库,配置库和变更管理等手段精心管理和控制数据模型以确保数据模型质量和可用性。

　　　　(9)数据管理员(DBA)和其他数据专业人员在数据库和相关应用系统的建设,测试及部署过程中都扮演非常重要的角色。

3.2 过程总结

　　数据开发职能流程的过程总结如表5.1所示。容中列举了数据开发的每一项交付物、负责角色、批准角色和贡献角色。此表也在附录A.9中体现。

3.3 组织和文化问题

　　Q1:数据交付过程中最大的问题是什么?

　　与数据交付相关的最大的组织和文化问题,是很多组织对数据交付需求理解太简单,没能充分认识并利用数据开发所能提供的好处。许多组织专注于应用开发,而忽视了数据本身的重要性。简单地说,探索发现数据分析和数据建模的重要性和有效性,可能会带来组织的变革。当考虑系统变更的时候,业务和IT部门都会考虑对数据的影响,有时他们会发现在其他应用中已经含有相同的数据和功能,或者他们其实并不真的需要那些已有的或者期望的数据和功能。

　　Q2:如何开展正规的数据开发?

　　为了开展开发模式的变革,有必要从数据的角度对系统进行文档记录。数据流、数据模型和数据质量分析等所有因素都必须记录到文档中。从某个系统开始,逐步过渡到从这个系统接收数据或者向这个系统发送数据的其他若干系统。基础架构的网络图有助于展示并帮助我们了解这些关系。下一步,就需要将系统数据流和数据模型的图纸分发给系统的利益相关方,既包括业务部门也包括IT部门。并与他们坐下来讨论这些图纸所展现的是否与他们看到的和理解的相同。确保所有的利益相关方相信文档如实反映了系统现状。然后,宣布这些文档的存在。为这些文档创建主版本,以及实施过程中的修订版本,以作为SDLC 的一部分。当一个系统上线投入运行,其中的一部分工作就是分发更新的数据流和数据模型。一旦这些内容确定,数据分析师和数据建模师会忙于为其他系统进行文档记录以及帮助软件工程师在项目中使用这些新的文档。因此,有可能需要额外的人员加人到团队中。

　　将以上过程拓展到分析所有的系统可能是一个迭代的过程,而且需要持续进行。这不仅可以通过避免系统冗余和数据存储冗余来节省成本,更可以通过高效率的开发来为组织降低成本。

　　最后一步是将参考这些文档作为系统需求分析和设计阶段的标准作业流程的一部分，从而改变组织文化。当数据开发成为这些文化的一部分,组织将致力于持续地维护并发展它以满足组织的需要。

文末说明：参考书籍来自《DAMA数据管理知识体系指南》