外文文献及翻译信息系统开发和数据库开发Word格式文档下载.docx

外文文献及翻译信息系统开发和数据库开发Word格式文档下载.docx

《外文文献及翻译信息系统开发和数据库开发Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《外文文献及翻译信息系统开发和数据库开发Word格式文档下载.docx（17页珍藏版）》请在冰点文库上搜索。

信息工程是一种面向数据的创建和维护信息系统的方法。

因为信息工程是面向数据的，所以当你开始理解数据库是怎样被标识和定义时，信息工程的一种简洁的解释是非常有帮助的。

信息工程遵循自顶向下规划的方法，其中，特定的信息系统从对信息需求的广泛理解中推导出来（例如，我们需要关于顾客、产品、供应商、销售员和加工中心的数据），而不是合并许多详尽的信息请求（如一个订单输入屏幕或按照地域报告的销售汇总）。

自顶向下规划可使开发人员更全面地规划信息系统，提供一种考虑系统组件集成的方法，增进对信息系统与业务目标的关系的理解，加深对信息系统在整个组织中的影响的理解。

信息工程包括四个步骤:

规划、分析、设计和实现。

信息工程的规划阶段产生信息系统体系结构，包括企业数据模型。

1.3信息系统规划

信息系统规划的目标是使信息技术与组织的业务策略紧密结合，这种结合对于从信息系统和技术的投资中获取最大利益是非常重要的。

正如表1所描述的那样，信息工程方法的规划阶段包括3个步骤，我们在后续的3个小节中讨论它们。

1.确定关键性的规划因素

关键性的规划因素是指组织目标、关键的成功因素和问题领域。

确定这些因素的目的是建立规划的环境并且将信息系统规划与战略业务规划联系起来。

表2显示了松谷家具公司的一些可能的关键规划因素，这些因素有助于信息系统的管理者为新的信息系统和数据库社顶优先级以处理需求。

例如，考虑到不精确的销售预测这个问题领域，信息系统的管理者可能在组织数据库中存放额外的历史销售数据、新的市场研究数据和新产品的测试数据。

2.确定组织的规划对象

组织规划对象定义了业务范围，业务范围会限制后来的系统分析和信息系统可能发生改变的地方。

五个关键的规划对象如下所示:

●组织单元组织中的各种部门。

●组织地点业务操作的发生地。

●业务功能支持组织使命的业务处理的相关组。

业务功能不同于组织单元，事实上一个功能可以分配给多个组织单元（例如，产品开发功能可能是销售部和生产部共同的责任）。

●实体类型关于组织所管理的人，地点和事物的数据的主要类别。

●信息系统处理数据集的应用软件和支持程序。

3.建立企业模型

一个全面的企业模型包括每个企业功能的功能分解模型、企业数据模型和各种规划矩阵。

功能分解是把组织的功能进行更详细的分解过程，功能分解是在系统分析中为了简化问题、分散注意力和确定组件而使用的经典处理方法。

在松谷家具公司中订单履行功能的功能分解的例子如图2所示。

对于处理业务功能和支持功能的全部集合而言，多个数据库是必须的，因此一个特定的数据库可能仅仅对支持功能（如图2所示）的一个子集提供支持。

为了减少数据冗余和使数据更有意义，拥有完整的、高层次的企业视图是非常有帮助的。

企业数据模型使用特定的符号来描述。

除了实体类型这种图形描述外，一个完整的企业数据模型还应包括每个实体类型的描述和描述业务操作的提要，即业务规则。

业务规则决定数据的有效性。

一个企业数据模型不仅包括实体类型，还包括数据实体间的联系，以及各种规划对象间的其他联系。

显示规划对象间联系的一种常见形式是矩阵。

由于规划矩阵不需要数据库被明确的建模就可以明确描述业务需求，因此规划矩阵是一种重要的功能。

规划矩阵经常从业务规则中导出，它有助于社顶开发活动优先级、将开发活动排序和根据自顶向下视图通过一种企业范围的方法安排这些开发活动。

有许多种规划矩阵可供使用，它们的共同之处是:

●地点-功能显示业务功能在哪个业务地点执行。

●单元-功能显示业务功能由哪个业务单元执行或负责。

●信息系统-数据实体解释每个信息系统如何与每个数据实体相互作用（例如，是否每个系统都对每个实体中的数据进行创建、检索、更新和删除）。

●支持功能-数据实体确定每个功能中数据的获取、使用、更新和删除。

●信息系统-目标显示信息系统支持的每个业务目标

图3举例说明了一个可能的功能-数据实体矩阵。

这样的矩阵可以用于多种目的，包括以下三个目的:

1）确定空白实体显示哪些数据实体没有被任何功能使用或哪个功能没有使用任何实体。

2）发现丢失的实体每个功能涉及的员工通过检查矩阵能够确认任何可能丢失的实体。

3）区分开发活动的优先级如果一个给顶的功能对于系统开发有高优先级（可能因为它与重要的组织目标相关），那么这个领域所使用的实体在数据库开发中拥有高优先级。

Hoffer、George和Valacich（2002）的著作中有关于怎样使用规划矩阵完成信息工程和系统规划的更完整的描述。

2数据库开发过程

基于信息工程的信息系统规划是数据库开发项目的一个来源。

这些开发新数据库的项目通常是为了满足组织的战略需求，例如改善客户支持、提高产品和库存管理或进行更精确的销售预测。

然而许多数据库开发项目更多的是以自底向上的方式出现的，例如信息系统的用户需要特定的信息来完成他们的工作，从而请求开始一个项目，又如其他信息系统的专家发现组织需要改进数据管理而开始新的项目。

即使在自底向上的情况下，建立企业数据模型也是必须的，以便理解现有的数据库是否可以提供所需的数据，否则，新的数据库、数据实体和属性都应该加到当前的组织数据资源中去。

无论是战略需求还是操作信息的需求，每个数据库开发项目通常集中在一个数据库上。

一些数据库项目仅仅集中在定义、设计和实现一个数据库，以作为后续信息系统开发的基础。

然而在大多数情况下，数据库及其相关信息处理功能是作为一个完整的信息系统开发项目的一部分而被开发的。

2.1系统开发生命周期

指导管理信息系统开发项目的传统过程是系统开发生命周期（SDLC）。

系统开发生命周期是指一个组织中由数据库设计人员和程序员组成的信息系统专家小组详细说明、开发、维护和替换信息系统的全部步骤。

这个过程比作瀑布是因为每一步都流到相邻的下一步，即信息系统的规格说明是一块一块地开发出来的，每一块的输出是下一块的输入。

然而如图所示，这些步骤并不是纯线性的，每个步骤在时间上有所重叠（因此可以并行地管理步骤），而且当需要重新考虑先前的决策时，还可以回滚到前面某些步骤。

（因而水可以在瀑布中倒流！

）

图4对系统开发生命周期每一阶段的目的和可交付的产品进行了简明注解。

系统开发生命周期的每一阶段都包括与数据库开发相关的活动，所以，数据库管理的问题遍布整个系统开发过程。

我们在图5中重复了系统开发生命周期的七个阶段，并概述了每个阶段常见的数据库开发活动。

请注意，系统开发生命周期的阶段和数据库开发步骤之间不存在一一对应的关系，概念数据建模发生在两个系统开发生命周期阶段之间。

企业建模

数据库开发过程从企业建模（系统开发生命周期中项目论证和选择阶段的一部分）开始设定组织数据库的范围和一般内容。

企业建模发生在信息系统规划和其他活动期间，这些活动确定信息系统的哪个部分需要改变和加强并概述出全部组织数据的范围。

在这一步中，检查当前数据库和信息系统，分析作为开发项目主体的业务领域的本质，用非常一般的术语描述每个信息系统在开发时所需要的数据。

每个项目只有当它达到组织的预期目标时才可以进行下一步。

概念数据建模对一个已经开始的信息系统项目而言，概念数据建模阶段分析信息系统的全部数据需求。

它分为两个阶段。

首先，它在项目开始和规划阶段建立一张类似于图1的图。

同时建立其他文档来概述不考虑现存数据库的情况下特定开发项目中所需的数据范围。

此时仅仅包括高层类别的数据（实体）和主要联系。

然后在系统开发生命周期的分析阶段产生确定信息系统必须管理的全部组织数据的详细数据模型，定义所有数据属性，列出全部数据类别，表示数据实体间所有的业务联系，确定描述数据完整性的全部规则。

在分析阶段，还要检查概念数据模型（在后面也称作概念模式）与用来解释目标信息系统其他方面的模型类别的一致性，例如处理步骤、处理数据的规则以及时间的时序。

然而，即使是这样详细的概念数据模型也只是初步的，因为后续的信息系统生命周期中的活动在设计事务、报表、显示和查询时可能会发现遗漏的元素或错误。

因此，经常说到的概念数据建模是以一种自顶向下的方式完成的，它由业务领域的一般理解所驱动，而不是由特定的信息处理活动所驱动。

3.逻辑数据库设计

逻辑数据库设计从两个角度进行数据库开发。

首先，将概念数据模型变换成基于关系数据库理论的标准表示方法——关系。

然后像设计信息系统的每个计算机程序（包括程序的输入和输出格式）那样，对数据库支持的事务、报表、显示和查询进行详细的检查。

在这个所谓的自底向上的分析中，精确地验证数据库中需要维护的数据和在每个事务、报表等等中需要的那些数据的性质。

对于每个单独的报表、事务等等的分析都要考虑一个特定的、有限制的但是完全的数据库视图。

当报表、事务等被分析时有可能根据需要而改变概念数据模型。

尤其在大型的项目中，不同的分析人员和系统开发者的团队可以独立地工作在不同的程序或程序集中，他们所有工作的细节直到逻辑设计阶段才可能会显示出来。

在这种情况下，逻辑数据库设计阶段必须将原始的概念数据模型和这些独立的用户视图合并或集成到一个全面的设计中。

在进行逻辑信息系统设计时也可以确定额外的信息处理需求，此时这些新的需求必须集成到前面确定的逻辑数据库设计中。

逻辑数据库设计的最后一步是根据为生成结构良好的数据规格说明而确定的规则，将组合的、协商后的数据规格说明转换成基本的或原子的元素。

对当今的大部分数据库而言，这些规则来自关系数据库理论和称作规范化的过程。

这一步的结果是产生管理这些数据的、不引用任何数据库管理系统的完整的数据库描述图。

在完成逻辑数据库设计后，开始确定详细的计算机程序的逻辑和维护、报告数据库内容所需的查询。

4.物理数据库设计和定义

物理数据库设计和定义阶段决定计算机存储器（通常是磁盘）中数据库的组织，定义数据库管理系统的物理结构，概述处理事务的程序，产生期望的管理信息和决策支持的报表。

本阶段的目标是设计能够有效、安全地管理所有数据处理的数据库，因此物理数据库设计需紧密结合物理信息系统其他方面的设计，包括程序、计算机硬件、操作系统和数据通信网络。

5.数据库实现

数据库实现阶段编写、测试和安装处理数据库的程序。

设计人员可以使用标准的编程语言（如COBOL、C或VisualBasic）、专用的数据库处理语言（如SQL），或专用的非过程化语言来编程，以产生固定格式的报表、显示结果，可能还包括图表。

在实现阶段，还要完成所有的数据库文档，培训用户，为信息系统（和数据库）的用户安装程序。

最后一步是利用现存的信息源（遗留应用中的文件和数据库以及现在需要的新数据）加载数据。

加载数据的第一步经常是将数据从现存的文件和数据库中转到一种中间的格式（如二进制或文本文件），然后再将这些中间数据加载到新的数据库中。

最后，运行数据库以及相关的应用以供实际的用户维护和检索数据。

在运转期间，定期备份数据库，并当数据库损坏或受到影响时恢复数据库。

6.数据库维护

数据库在数据库维护期间逐渐发展。

在这一步，为了满足变化的业务条件，为了改正数据库设计的错误，或数据库应用的处理速度而增加、删除或改变数据库的结构特征。

当一个程序或计算机发生故障而使数据库受到影响或损坏时也可能应该重建数据库。

这一步通常是数据库开发过程中最长的一步，因为它持续数据库及相关应用的整个生命周期，每次数据库的发展都可看作一个简略的数据库开发过程，其中会出现概念数据建模、逻辑和物理数据库设计以及数据库实现以处理提出的变化。

2.2信息系统开发的其他方法

系统开发生命周期法或其稍作变化的变体经常用于指导信息系统和数据库的开发。

信息系统生命周期是一种方法学，它是高度结构化的方法，它包括许多检查和权衡以确保每一步产生精确的结果，而且新的或替代的信息系统与它必须通信的或数据定义需要一致的现存系统保持一致。

系统开发生命周期法经常由于产生一个工作系统需要很长的时间而受到批评，因为工作系统仅仅在整个过程结束时才产生。

现在组织越来越多的使用快速应用开发法，它是一个包含分析、设计和实现步骤的快速重复的迭代过程，直到汇聚到用户所需的系统为止。

快速应用开发法在所需的数据库已经存在、增强系统主要是为了检索数据的应用中适用，而不适用于那些生成和修改数据库的应用。

使用最广泛的快速应用开发法之一是原型法。

原型法是一个系统开发的迭代过程，通过分析员和用户的紧密配合，持续地修改系统而最终将所有需求转换成一个工作系统。

图6显示原型法的过程。

在此图中我们包含了注释，概略地描述了每个原型法阶段的数据库开发活动。

一般来说，当信息系统的问题被确定时，仅仅粗略地尝试概念数据建模。

在开发最初的原型时，设计用户想要的显示和报表，同时理解任何新的数据库需求并定义一个用语原型的数据库。

这通常是一个新的数据库，它复制现存系统的一部分，还可能增加了一些新的内容。

当需要新的内容时，这些内容通常来自外部数据源，如市场研究数据、一般的经济指标或行业标准。

当产生原型新的版本时重复数据库的实现和维护活动。

通常仅进行最低限度的安全性和完整性控制，因为此时的重点是尽可能快地产生可以使用的原型版本。

而且文档管理也延迟到项目的最后，在交付使用时才进行用户培训。

最后，一旦构建了一个可接受的原型，开发者和用户将决定最后的原型和数据库是否能交付使用。

如果系统（包括数据库）效率很低，那么系统和数据库将被重新编程和重新组织以达到期望的性能。

随着可视化编程工具（如VisualBasic、Java、VisualC++和第四代语言）越来越流行，利用可视化编程工具可以很方便地修改用户与系统间的界面，原型法正成为可供选择的系统开发方法。

使用原型法改变用户报表和显示的内容和布局是相当容易的。

在这个过程中，新的数据库需求被确定，因此被发展中的应用使用的现存的数据库应该进行修改。

甚至有可能为一个需要新的数据库的系统使用原型法，在这种情况下，当系统需求在迭代的开发过程中不断变化时需要获取样本数据以建造或重建数据库原型。

3数据库开发的三层模式体系结构

在本文前面关于数据库开发过程的解释中提到了一个系统开发项目上建立的几个不同的、但是相关的数据库视图或模型:

●概念模式（在分析阶段建立）。

●外部模式或用户视图（在分析阶段和逻辑设计阶段建立）。

●物理模式或内部模式（在物理设计阶段建立）。

图7描述了数据库这三个视图之间的关系，重要的是要记住，它们是同一个组织数据库的视图或模型。

也就是说，每一个组织数据库都有一个物理模式、一个概念模式以及一个或多个用户视图。

因此，三层模式体系结构用观察同一数据集的不同方式定义数据库。

概念模式关于全部数据库结构的、与技术无关的规格说明。

概念模式定义了整个数据库而不涉及数据怎样存储在计算机的二级存储器中。

通常，概念模式用实体-联系（E-R）图或对象建模符号这样的图形格式来描述，我们把这种类型的概念模式称为数据模型。

另外，概念模式的规格说明作为元数据存储在信息库或数据字典中。

物理模式包括概念模式的数据怎样存储在计算机二级存储器中的规格说明。

对数据库分析员和设计人员来说，重要的是物理数据库（物理模式）的定义，它提供了关于分配和管理存储和访问的数据所在的物理二级存储器空间的数据库技术的全部规格说明。

数据库开发和数据库技术是以数据库这三个模式间的区分为基础的。

数据库开发项目的一个角色可能仅需处理与这三个视图中的一个相关的工作。

例如，一个初学者可能设计用于一个或多个程序的外部模式，而一个有经验的开发者将设计物理模式或概念模式。

数据库设计问题在不同的层次上有很大的不同。

4三层数据库定位体系结构

显然，所有数据库中的好的事情都和“三”有关！

当设计一个数据库时，你要选择把数据存放在何处。

这个选择在物理数据库设计阶段作出。

数据库分为个人数据库、工作组数据库、部门数据库、企业数据库和因特网数据库。

个人数据库经常由最终用户自己设计和开发，仅仅由数据库专家给予培训和咨询帮助，它仅包含最终用户个人感兴趣的数据。

有时候，个人数据库是从工作组数据库或企业数据库中提取出来的，这种情况下数据库专家经常编写一些提取例程来创建本地数据库。

工作组数据库和部门数据库经常被最终用户、业务部门中的系统专家和中心数据库专家一起开发。

这些人员的协同工作是必须的，因为在设计共享的数据库时必须权衡大量的问题:

处理速度、易于使用、数据定义的差别和其他类似的问题。

由于企业数据库和因特网数据库影响广、规模大，所以，通常由在集中的数据库开发小组中受过专业培训的数据库专家来开发。

1.客户层

一个台式计算机或笔记本也称作表示层，它专门管理用户系统界面和本地化数据，在这一层上可以执行Web脚本任务。

2.服务器/Web服务器层

处理HTTP协议、脚本任务，执行计算和提供数据访问，所以该层称作处理服务层。

3.企业服务器（小型机或大型机）层

执行复杂的计算和管理来自组织间多个数据源的数据的合并，也称作数据服务层。

在一个组织中，数据库和信息系统分层的体系结构与用于分布式计算的客户/服务器体系结构的概念相关。

客户/服务器体系结构基于一个局域网环境，其中服务器上（称作数据库服务器或数据库引擎）的数据库软件执行来自客户工作站的数据库命令，每个客户的应用程序专注于它们的用户接口功能。

实际上，整个概念数据库（以及访问这些数据库的应用处理例程）作为一个分布式数据库或单独但是相关的物理数据库而分布在本地的PC工作站、中间的服务器（工作组或部门）和一个中心服务器（部门或企业）上。

简单地说，使用客户/服务器体系结构的原因是:

●它可以在多个处理器上同时处理同一个应用，因此改善了应用的响应时间和数据处理速度。

●它可以利用每个计算机平台最好的数据处理特性（如PC的高级用户界面与小型机和大型机的计算速度）。

●可以混合使用各种客户端的技术（装配Intel或Motorola处理器的个人计算机、网络计算机、信息站等）和共享公共数据。

另外，你可以在任何层改变技术而仅对其他层系统模块的影响很小。

●能够使处理靠近需处理的数据源，从而改进响应时间并减少网络通信量。

●它允许和鼓励接受开放系统标准。

对于数据库开发而言，使用一个多层的客户/服务器体系结构开发数据库最有意义之处在于易于将数据库开发和维护数据库的模块与向最终用户表示数据库内容的信息系统模块分隔开。

表示例程能够使用像PowerBuilder、Java和VisualBasic这样的语言来提供易于使用的图形化的用户界面。

通过中间件，表示例程能够通过层间相互作用来访问例程，该例程访问所需数据并分析这些数据以形成所需信息。

作为一个数据库开发人员和程序员，你可以在这三层中的任何一层工作，开发必需的软件。

InformationSystemDevelopmentandDatabaseDevelopment

Inmanyorganizations,databasedevelopmentfromthebeginningofenterprisedatamodeling,datamodelingenterprisesdeterminethescopeofthedatabaseandthegeneralcontent.Thisstepusuallyoccursinanorganization'

sinformationsystemplanningprocess,itaimstohelporganizationscreateanoveralldatadescriptionorexplanation,andnotthedesignofaspecificdatabase.Aspecificdatabaseforoneormoreinformationsystemsprovidedataandthecorporatedatamodel（whichmayinvolveanumberofdatabases）describedbytheorganizationmaintainingthescopeofthedata.Datamodelingintheenterprise,youreviewofthecurrentsystem,theneedtosupportanalysisofthenatureofthebusinessareas,theneedforfurtherdescriptionoftheabstractdata,andplanningoneormoredatabasedevelopmentproject.Figure1showsPineValleyfurniturecompany'

senterprisedatamodelofapart.

1.1InformationSystemArchitecture

Asshowninfigure1,seniordatamodelisonlygeneralinformationsystemarchitecture（ISA）orapartofanorganization'

sinformationsystemblueprint.Intheinformationsystemplanning,youcanbuildanenterprisedatamodelasawholeinformationsystemarchitecturepart.AccordingtoZachman（1987）,SowaandZachman（1992）viewsofaninformationsystemarchitectureconsistsofthefollowingsixkeycomponents:

Data（Figure1shows,butthereareothermethodsthat）.

Manipulationofdatapro