图书销售管理系统外文文献翻译.docx

图书销售管理系统外文文献翻译.docx

《图书销售管理系统外文文献翻译.docx》由会员分享，可在线阅读，更多相关《图书销售管理系统外文文献翻译.docx（13页珍藏版）》请在冰豆网上搜索。

图书销售管理系统外文文献翻译图书销售管理系统外文文献翻译C#及数据库的开发及数据库的开发一、C#的介绍C#在某种程度上可以看作是.NET面向Windows环境的一种编程语言。

在去去的十几年里，Microsoft给Windows和WindowsAPI添加了许多功能，VB和C+也经历了许多变化。

虽然VB和C+最终已成为非常强大的语言，但这两种语言也存在问题，因为它们保留了原来的一些内容。

对于VisualBasic来说，它的主要优点是很容易理解，许多编程工作都很容易完成，基本上隐藏了WindowsAPI和COM组件结构的内涵。

其缺点是VisualBasic从来没有实现真正意义上的面向对象，所以大型应用程序很难分解和维护。

另外，因为VB的语法继承于BASIC的早期版本（BASIC主要是为了让初学者更容易理解，而不是为了编写大型商业应用程序），所以不能真正成为结构化或面向对象的编程语言。

另一方面，C+在ANSIC+语言定义中有其自己的根。

它与ANSI不完全兼容，因为Microsoft是在ANSI定义标准化之前编写C+编译器的，但已经相当接近了。

遗憾的是，这导致了两个问题。

其一，ANSIC+是在十几年前的技术条件下开发的，因此不支持现在的概念（例如Unicode字符串和生成XML文档），某些古老的语法结构是为以前的编译器设计的（例如成员函数的声明和定义是分开的）。

其二，Microsoft同时还试图把C+演变为一种用于在Windows上执行高性能任务的语言在语言中避免添加大量Microsoft专用的关键字和各种库。

其结果是在Windows中，该语言成为了一种非常杂乱的语言。

让一个C+开发人员说说字符串有多少个定义方式就可以说明这一点：

char*、LPTSTR、string、CString（MFC版本）、CString（WTL版本）、wchar_t*和OLECHAR*等。

现在进入.NET时代一种全新的环境，它对这两种语言都进行了新的扩展。

Microsoft给C+添加了许多Microsoft专用的关键字，并把VB演变为VB.NET，保留了一些基本的VB语法，但在设计上完全不同，从实际应用的角度来看，VB.NET是一种新语言。

在这里，Microsoft决定给开发人员另一个选择专门用于.NET、具有新起点的语言，即VisualC#.NET。

Microsoft在正式场合把C#描述为一种简单、现代、面向对象、类型非常安全、派生于C和C+的编程语言。

大多数独立的评论员对其说法是“派生于C、C+和Java”。

这种描述在技术上是非常准确的，但没有涉及到该语言的真正优点。

从语法上看，C#非常类似于C+和Java，许多关键字都是相同的，C#也使用类似于C+和Java的块结构，并用括号（）来标记代码块，用分号分隔各行语句。

对C#代码的第一印象是它非常类似于C+或Java代码。

但在这些表面上的类似性后面，C#学习起来要比C+容易得多，但比Java难一些。

其设计与现代开发工具的适应性要比其他语言更高，它同时具有VisualBasic的易用性、高性能以及C+的低级内存访问性。

C#包括以下一些特性：

完全支持类和面向对象编程，包括接口和继承、虚函数和运算符重载的处理。

定义完整、一致的基本类型集。

对自动生成XML文档说明的内置支持。

自动清理动态分配的内存。

可以用用户定义的特性来标记类或方法。

这可以用于文档说明，对编译有一定的影响（例如，把方法标记为只在调试时编译）。

对.NET基类库的完全访问权，并易于访问WindowsAPI。

可以使用指针和直接内存访问，但C#语言可以在没有它们的条件下访问内存。

以VB的风格支持属性和事件。

改变编译器选项，可以把程序编译为可执行文件或.NET组件库，该组件库可以用与ActiveX控件（COM组件）相同的方式由其他代码调用。

C#可以用于编写ASP.NET动态Web页面和XMLWeb服务。

应该指出，对于上述大多数特性，VB.NET和ManagedC+也具备。

但C#从一开始就使用.NET，对.NET特性的支持不仅是完整的，而且提供了比其他语言更合适的语法。

C#语言本身非常类似于Java，但其中有一些改进，因为Java并不是为应用于.NET环境而设计的。

在结束这个主题前，还要指出C#的两个局限性。

其一是该语言不适用于编写时间急迫或性能非常高的代码，例如一个要运行1000或1050次的循环，并在不需要这些循环时，立即清理它们所占用的资源。

在这方面，C+可能仍是所有低级语言中的佼佼者。

其二是C#缺乏性能极高的应用程序所需要的关键功能，包括保证在代码的特定地方运行的内联函数和析构函数。

但这类应用程序非常少。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

它分为两个阶段。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图7描述了数据库