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

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

1、 C#及数据库的开发 一、 C#的介绍 C#在某种程度上可以看作是 .NET 面向 Windows 环境的一种编程语言。在去 去的十几年里， Microsoft 给 Windows 和 Windows API 添加了许多功能， VB 和 C+也经历了许多变化。虽然 VB 和 C+最终已成为非常强大的语言，但这两种语言也存在问题，因为它们保留了原来的一些内容。 对于 Visual Basic 来说，它的主要优点是很容易理解，许多编程工作都很容易完成，基本上隐藏了 Windows API 和 COM 组件结构的内涵。其缺点是 Visual Basic 从来没有 实现真正意义上的面向对象，所以大型应

2、用程序很难分解和维护。另外，因为 VB 的语法继承于 BASIC 的早期版本 (BASIC 主要是为了让初学者更容易理解，而不是为了编写大型商业应用程序 )，所以不能真正成为结构化或面向对象的编程语言。 另一方面， C+在 ANSI C+语言定义中有其自己的根。它与 ANSI 不完全兼容，因为 Microsoft 是在 ANSI 定义标准化之前编写 C+编译器的，但已经相当接近了。遗憾的是，这导致了两个问题。其一， ANSI C+是在十几年前的技术条件下开发的，因此不支持现在的概念 (例如 Unicode 字符串和生成 XML 文档 )，某些古老的语法结构是为以前的编译器设计的 (例如成员函数

3、的声明和定义是分开的 )。其二， Microsoft 同时还试图把 C+演变为一种用于在 Windows 上执行高性能任务的语言 在语言中避免添加大量 Microsoft 专用的关键字和各种库。其结果是在 Windows 中，该语言成为了一种非常杂乱的语言。让一个 C+开发人员说说字符串有多少个定义方式就可以说明这一点： char*、 LPTSTR、 string、 CString (MFC 版本 )、 CString (WTL 版本 )、 wchar_t*和 OLECHAR*等。 现在进入 .NET 时代 一种全新的环境，它对这两种语言都进行了新的扩展。 Microsoft 给 C+添加了许

4、多 Microsoft 专用的关键字，并把 VB 演变为VB.NET，保留了一些基本的 VB 语法，但在设计上完全不同，从实际应用的角度来看， VB.NET 是一种新语言。 在这里， Microsoft 决定给开发人员另一个选择 专门用于 .NET、具有新起点的语言， 即 Visual C# .NET。 Microsoft 在正式场合把 C#描述为一种简单、现代、面向对象、类型非常安全、派生于 C 和 C+的编程语言。大多数独立的评论员对其说法是“派生于 C、 C+ 和 Java”。这种描述在技术上是非常准确的，但没有涉及到该语言的真正优点。从语法上看， C#非常类似于 C+和 Java，许多

5、关键字都是相同的， C#也使用类似于 C+和 Java 的块结构，并用括号 ( )来标记代码块，用分号分隔各行语句。对 C#代码的第一印象是它非常类似于 C+或 Java 代码。但在这些表面上的类似性后面， C#学习起来要比 C+容易得多，但比 Java 难一些。其设计与现代开发工具的适应性要比其他语言更高，它同时具有 Visual Basic 的易用性、高性能以及 C+的低级内存访问性。 C#包括以下一些特性： 完全支持类和面向对象编程，包括接口和继承、虚函数和运算符重载的处理。 定义完整、一致的基本类型集。 对自动生成 XML 文档说明的内置支持。 自动清理动态分配的内存。 可以用用户定义

6、的特性来标记类或方法。这可以用于文档说明，对编译有一定的影响 (例如，把方法标记为只在调试时编译 )。 对 .NET 基类库的完全访问权，并易于访问 Windows API。 可以使用指针和直接内存访问，但 C#语言可以在没有它们的条件下访问内存。 以 VB 的风格支持属性和事 件。 改变编译器选项，可以把程序编译为可执行文件或 .NET 组件库，该组件库可以用与 ActiveX 控件 (COM 组件 )相同的方式由其他代码调用。 C#可以用于编写 ASP.NET 动态 Web 页面和 XML Web 服务。 应该指出，对于上述大多数特性， VB.NET 和 Managed C+也具备。但 C

7、#从一开始就使用 .NET，对 .NET 特性的支持不仅是完整的，而且提供了比其他语言更合适的语法。 C#语言本身非常类似于 Java，但其中有一些改进，因为 Java 并不是为应用于 .NET 环境而设计的。 在结束这个主题前，还要指出 C#的两个局限性。其一是该语言不适用于编写时间急迫或性能非常高的代码，例如一个要运行 1000 或 1050 次的循环，并在不需要这些循环时，立即清理它们所占用的资源。在这方面， C+可能仍是所有低级语言中的佼佼者。其二是 C#缺乏性能极高的应用程序所需 要的关键功能，包括保证在代码的特定地方运行的内联函数和析构函数。但这类应用程序非常少。 二、 数据库开发

8、过程 基于信息工程的信息系统规划是数据库开发项目的一个来源。这些开发新数据库的项目通常是为了满足组织的战略需求，例如改善客户支持、提高产品和库存管理或进行更精确的销售预测。然 而许多数据库开发项目更多的是以自底向上的方式出现的，例如信息系统的用户需要特定的信息来完成他们的工作，从而请求开始一个项目，又如其他信息系统的专家发现组织需要改进数据管理而开始新的项目。即使在自底向上的情况下，建立企业数据模型也是必须的，以便理解现有的数据库是否可以提供所需的数据，否则，新的数据库、数据实体和属性都应该加到当前的组织数据资源中去。 无论是战略需求还是操作信息的需求，每个数据库开发项目通常集中在一个数据库上

9、。一些数据库项目仅仅集中在定义、设计和实现一个数据库，以作为后续信息系统开发的基础。然而 在大多数情况下，数据库及其相关信息处理功能是作为一个完整的信息系统开发项目的一部分而被开发的。 1、 系统开发生命周期 指导管理信息系统开发项目的传统过程是系统开发生命周期 (SDLC)。系统开发生命周期是指一个组织中由数据库设计人员和程序员组成的信息系统专家小组详细说明、开发、维护和替换信息系统的全部步骤。这个过程比作瀑布是因为每一步都流到相邻的下一步，即信息系统的规格说明是一块一块地开发出来的，每一块的输出是下一块的输入。然而如图所示，这些步骤并不是纯线性的，每个步骤在时间上有所重叠（因此可以并行地管

10、理步 骤），而且当需要重新考虑先前的决策时，还可以回滚到前面某些步骤。（因而水可以在瀑布中倒流！） 图 4 对系统开发生命周期每一阶段的目的和可交付的产品进行了简明注解。 系统开发生命周期的每一阶段都包括与数据库开发相关的活动，所以，数据库管理的问题遍布整个系统开发过程。我们在图 5 中重复了系统开发生命周期的七个阶段，并概述了每个阶段常见的数据库开发活动。请注意，系统开发生命周期的阶段和数据库开发步骤之间不存在一一对应的关系，概念数据建模发生在两个系统开发生命周期阶段之间。 企业建模 数据库开发过程从企业建模（系统开发 生命周期中项目论证和选择阶段的一部分）开始设定组织数据库的范围和一般内容

11、。企业建模发生在信息系统规划和其他活动期间，这些活动确定信息系统的哪个部分需要改变和加强并概述出全部组织数据的范围。在这一步中，检查当前数据库和信息系统，分析作为开发项目主体的业务领域的本质，用非常一般的术语描述每个信息系统在开发时所需要的数据。每个项目只有当它达到组织的预期目标时才可以进行下一步。 概念数据建模对一个已经开始的信息系统项目而言，概念数据建模阶段分析信息系统的全部数据需求。它分为两个阶段。首先，它在项目开始和规划阶段建立 一张类似于图 1 的图。同时建立其他文档来概述不考虑现存数据库的情况下特定开发项目中所需的数据范围。此时仅仅包括高层类别的数据（实体）和主要联系。然后在系统开

12、发生命周期的分析阶段产生确定信息系统必须管理的全部组织数据的详细数据模型，定义所有数据属性，列出全部数据类别，表示数据实体间所有的业务联系，确定描述数据完整性的全部规则。在分析阶段，还要检查概念数据模型（在后面也称作概念模式）与用来解释目标信息系统其他方面的模型类别的一致性，例如处理步骤、处理数据的规则以及时间的时序。然而，即使是这样详细的概念数据模型也只 是初步的，因为后续的信息系统生命周期中的活动在设计事务、报表、显示和查询时可能会发现遗漏的元素或错误。因此，经常说到的概念数据建模是以一种自顶向下的方式完成的，它由业务领域的一般理解所驱动，而不是由特定的信息处理活动所驱动。 2、 逻辑数据

13、库设计 逻辑数据库设计从两个角度进行数据库开发。首先，将概念数据模型变换成基于关系数据库理论的标准表示方法 关系。然后像设计信息系统的每个计算机程序（包括程序的输入和输出格式）那样，对数据库支持的事务、报表、显示和查询进行详细的检查。在这个所谓的自底向上的分析中，精确地验 证数据库中需要维护的数据和在每个事务、报表等等中需要的那些数据的性质。 对于每个单独的报表、事务等等的分析都要考虑一个特定的、有限制的但是完全的数据库视图。当报表、事务等被分析时有可能根据需要而改变概念数据模型。尤其在大型的项目中，不同的分析人员和系统开发者的团队可以独立地工作在不同的程序或程序集中，他们所有工作的细节直到逻

14、辑设计阶段才可能会显示出来。在这种情况下，逻辑数据库设计阶段必须将原始的概念数据模型和这些独立的用户视图合并或集成到一个全面的设计中。在进行逻辑信息系统设计时也可以确定额外的信息处理需求 ，此时这些新的需求必须集成到前面确定的逻辑数据库设计中。 逻辑数据库设计的最后一步是根据为生成结构良好的数据规格说明而确定的规则，将组合的、协商后的数据规格说明转换成基本的或原子的元素。对当今的大部分数据库而言，这些规则来自关系数据库理论和称作规范化的过程。这一步的结果是产生管理这些数据的、不引用任何数据库管理系统的完整的数据库描述图。在完成逻辑数据库设计后，开始确定详细的计算机程序的逻辑和维护、报告数据库内容所需的查询。 3、 物理数据库设计和定义