ORACLE8UML对象建模设计01.docx

第1章概述本章我们将简单讨论对象-关系模型，并概述数据库行业从6 0和7 0年代的展开文件结构到数据库理论最近趋势的发展。我们也将针对统一建模语言（ U M L）、O r a c l e环境的概观以及Oracle 8i中可利用的新特征作简单介绍。1.1 对象-关系数据库的发展当从事于信息系统技术的人们开始利用数据库工作时，数据库由一系列文件构成。我们主要用C O D A S Y L语言的C O B O L扩展来访问这些结构。在处理文件时， C O D A S Y L给了我们利用F I R S T _ R E C O R D、N E X T _ R E C O R D和L A S T _ R E C O R D这类命令的能力，这是我们第一次利用数据库游标。在处理数据文件方面， C O D A S Y L使我们能够比通过阅读t e x t文件更有效地工作。我们对这些结构使用索引、I S A M和V S A M文件，这类结构建立在链接表基础上且与索引结构分离。第一次我们有了一个数据库管理系统（ D B M S），在数据和程序之间具有了一定程度上的独立性。不幸的是，其中仍旧存在一些问题：程序仍然很大，甚至系统中微小的变化可能也需要数百（如果不是数千）小时的人工。你只需看看现在扰人的2 0 0 0年问题，就可认识到这种系统的局限性。关系系统以其巨大的理论优势胜过传统的以C O D A S Y L为基础的系统。开发者能够把文件看作是简单的逻辑展开文件，所有的索引和S Q L查询语句分析都可由关系D B M S（R D B M S )来进行。不幸的是，仍然存在许多问题。查询运行得如此缓慢以致于开发者不得不取代缺省的S Q L语法分析算法。8 0年代，要想获得好的性能是如此困难，以致于一些数据库设计者感觉到很有必要回到非规范化数据模型。1.1.1 关系数据库关系模型是一种非常精巧、清楚的模型，它已经为数据库行业提供了近2 0年的基础。关系理论中较少的概念已使关系数据库成为行业标准。关系数据库厂家已经能够主要从系统逻辑设计上孤立数据库物理实施的复杂性，由此提供了一个简单的应用开发者接口。在过去的2 0年里，数据库已经作为一个行业发展成熟起来。许多人已经感觉到使建模环境更加丰富的必要性，这种环境更能适应向类属建模的发展。而且，我们认识到面向对象理论的一些概念能够被引入数据库行业，甚至可以带来更高的效率。关系数据库的词汇量相对有限。我们通过精心设计展开文件来实现结构的设计，并将一些不同类型的索引放在那些文件的不同字段中。就访问而言，表之间的连接只被逻辑指明，第一部分基础所以参照指针通过外码执行，表之间确实无显式连接。参照完整性约束仅仅是一些阻止特殊种类的无效数据放在数据模型中的代码段。当一个记录被插入、更新或删除时，可以将触发器加到表中，以便明确地执行一些操作，并且可将程序单元存储到数据库中。最后，可用簇表来改善性能。这些策略仍旧会限制我们以一个相当有限的方式思考。在关系数据库中，每个表事实上是一个独立的结构。在逻辑实体关系（ E R）模型中，有作为其他实体子集的实体。例如，领薪金者雇员是所有雇员的子集。同样，有基于其他实体的实体。例如P O明细，它是基于购货单（ P u r c h a s eO r d e r）的。但是，在关系数据库范例中表达这种结构的能力是有限的。看似矛盾的是，面向对象数据库保持了早期数据库理论的一些概念。正如在C O D A S Y L时期，当把对象定位带入关系数据库世界时，人们发现遇到了“老朋友”，如链接表和指针。重要的是不要忘记最初放弃链接表和指针的理由，要记住在8 0年代早期关系数据库出现之前数据库是怎样的。目前仍有一些高性能的数据库（至少要到2 0 0 0年问题将它们消灭为止），它们的运行主要使用C O B O L编写的C O D A S Y L、I S A M和V S A M文件。C O D A S Y L数据库的修改通常需要花费几个月的精力。我们早期遇到过一个C O B O L项目，其中有一个将一个字段的长度从1 0个字符改为1 2个字符的简单需求。这个转换花费了几百个小时的编程。现在，在关系数据库环境中，这样一个转换最多仅需几天时间。如果应用程序是用Oracle Designer（或其他一些集成C A S E工具）产生的，这样一个转换即使在一个大系统中也只需执行1 ~ 2天就能实现。在关系数据库之前的时代，支持报表需求是很困难的。如果一个特殊的报表并非为了系统的最初设计规范而计划，那就能够容易地花费几周时间去编写一个新的报表（假定编写这个报表是可能的）。对基础性数据结构的修改是很麻烦的，似乎微小的变化就得需要整个大系统重新设计。虽不能断言所有这些问题已随着实体关系图（ E R D）和关系数据库的出现而消失，但状