ORACLE8 UML 对象建模设计01.docx

1、ORACLE8 UML 对象建模设计01第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

2、 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年问题，就可认识到这种系统的局限性。关系系统以其巨大的理

3、论优势胜过传统的以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年的基础。关系理论中较少的概念已使关系数据库成为行业标准。关系数据库厂家已经能够主要从系统逻辑设计上孤立数据库物理实施的复杂

4、性，由此提供了一个简单的应用开发者接口。在过去的2 0年里，数据库已经作为一个行业发展成熟起来。许多人已经感觉到使建模环境更加丰富的必要性，这种环境更能适应向类属建模的发展。而且，我们认识到面向对象理论的一些概念能够被引入数据库行业，甚至可以带来更高的效率。关系数据库的词汇量相对有限。我们通过精心设计展开文件来实现结构的设计，并将一些不同类型的索引放在那些文件的不同字段中。就访问而言，表之间的连接只被逻辑指明，第一部分基础所以参照指针通过外码执行，表之间确实无显式连接。参照完整性约束仅仅是一些阻止特殊种类的无效数据放在数据模型中的代码段。当一个记录被插入、更新或删除时，可以将触发器加到表中，以

5、便明确地执行一些操作，并且可将程序单元存储到数据库中。最后，可用簇表来改善性能。这些策略仍旧会限制我们以一个相当有限的方式思考。在关系数据库中，每个表事实上是一个独立的结构。在逻辑实体关系（ E R）模型中，有作为其他实体子集的实体。例如，领薪金者雇员是所有雇员的子集。同样，有基于其他实体的实体。例如P O明细，它是基于购货单（ P u r c h a s eO r d e r）的。但是，在关系数据库范例中表达这种结构的能力是有限的。看似矛盾的是，面向对象数据库保持了早期数据库理论的一些概念。正如在C O D A S Y L时期，当把对象定位带入关系数据库世界时，人们发现遇到了“老朋友”，如链

6、接表和指针。重要的是不要忘记最初放弃链接表和指针的理由，要记住在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

7、（或其他一些集成C A S E工具）产生的，这样一个转换即使在一个大系统中也只需执行1 2天就能实现。在关系数据库之前的时代，支持报表需求是很困难的。如果一个特殊的报表并非为了系统的最初设计规范而计划，那就能够容易地花费几周时间去编写一个新的报表（假定编写这个报表是可能的）。对基础性数据结构的修改是很麻烦的，似乎微小的变化就得需要整个大系统重新设计。虽不能断言所有这些问题已随着实体关系图（ E R D）和关系数据库的出现而消失，但状况显然已得到改善。早期的关系数据库看起来很像展开文件的前身，规范化被认为是一件纯粹满足好奇心的事。直到最后，至少通过第三范式，才发现规范化并不是一个坏想法。由于8

8、0年代的严重不规范化，在处理关系结构时遇到了一些处理展开文件时遇到的同样问题。数据结构的修改仍然很难且很昂贵，就像应用程序的修改一样。截止到1 9 9 0年，大多数数据模型制作者已经认识到，当8 0年代的那些系统需要修改时，其严重的非规范化会引起许许多多的问题。规范化最终成为“流行时尚”。9 0年代中期，一些早期的面向对象的思考开始转向关系数据库。在O r a c l e世界里，这涉及到通过创建更抽象的结构构造模型，但仍然在关系数据环境中操作。在最近几年里，一些关系数据库已经包含了面向对象的思想。现在，在大部分系统中看到某种级别的类属建模是很普通的。例如，把组织单位表示为一个简单的递归结构是行

9、业标准，而不是用单独的表表示区域、部门和科室（或代表特殊组织的任一种结构）。更抽象的模型正变得很平常。在最近的一次会议中，设计数据库调查表的人问如何支持一个有几百列的表，且每一份调查表都有几百个问题。被调查者中的一些人回答说应通过将答案放在一个单独的表中和将调查表的结构作为数据存入数据库来为调查表建立模型。一个无争议的解决办法因此而产生，面向对象的思想进入了数据模型。最近,面向对象的发展更进了两步。首先，数据库本身已包括新的面向对象的特点。其次，2计计第一部分基础下载在U M L中有了比在E R D中更新、更丰富的模型语言。如前所述，这些新概念实际上包括一些关系思想之前的老概念，如链接表和指针

10、。这种新老集成提供了一个很好的机会，但必须谨慎地对待。现在能够构造操作更有效的关系结构，但如果不仔细，可能会失去一些由关系数据库范例而带来的结构灵活性。1.1.2 对象-关系数据库对象-关系数据库正向我们走来。近1 0年来，“面向对象”已成为计算机行业最时髦的语言。在计算机行业中随便捡起一本杂志就会看到一些有关面向对象的文章。面向对象通常被错用来作为可重用代码的同义词，前者的含义是指一组准确的、推理性的计算机科学结构，它能影响系统的每个方面，包括编程语言、工具和数据库。这种技术的主要影响表现在编程上，面向对象有助于转变编程的过程。但是，应该认识到，并非每个C + +程序都是面向对象的。系统中有

11、关面向对象的最重要的方面就是设计组的思想。程序编写时没有可重用组件和标准是很平常的。前一段时间，我们核查了一个用C + +编写的大系统的失败，其中，每个程序员都设定了自己的标准，整个系统只有少部分是利用面向对象的编程标准来编写的。在一定程度上，面向对象的革命已经对数据库界产生了一定的影响。由主要数据库模型制作者支持的类属模型的发展如此强烈就是这场革命的反映。同样，在应用开发中，拥有可重用对象组件的模板的广泛应用正在成为主要编程厂家的规范。从这一点上说，为了更好地支持面向对象，O r a c l e现在正在改进R D B M S、Oracle Designer和Oracle Developer。

12、1.1.3 “对象-关系”的真正含义如果你问六位专家“对象-关系”是什么意思，那你将会得到六个答案。现在仍然在试图结合关系范例和对象范例，结合两者将不是一件容易的事。真正的对象数据库是市场的很小一部分，对象-关系数据库还处在发展阶段。问题是要确定在这个新的范例中究竟想得到什么。关系已有了2 0年的历史，在这期间，关系技术已成熟发展到了一个复杂的环境。最终，人们有了足够的参照完整性、存储程序和触发器，一些人已算出如何避免变化的表。同样，面向对象编程几乎和关系数据库同时起步，也已有了20年的历史。我们不应该指望面向对象是灵丹妙药。面向对象编程还没有解决编程人员的所有问题。相反，对象结构要求用一种完

13、全不同的方法考虑编程。面向对象将另外一层复杂性增加到环境中。许多编程厂家在向面向对象的转换过程中遇到了很大困难，而其他一些厂家则报告说他们的编程效率有了极大的提高。面向对象数据库把对象的存在作为一种不易变的结构来考虑。宁愿用参照指针，也不愿通过参照完整性来连接对象。继承性是被完全支持的，访问对象严格限于通过使用相关的方法和操作来进行。对象-关系系统正试图结合两者的优点，即对象标识符和主码。对象将通过对象引用和参照完整性联系起来。这种系统中还同时具备触发器和方法。表可独立构造，也可从一些父结构（称为类）继承属性和方法。但是，很难将这些实施到一个关系模型中。目前， Oracle 8i有了对象标识符

14、和方法，但只有有限的继承性。第1章概述计计3下载从开发者的前景来看，最大的挑战是如何最好地利用这些新功能。关系数据库中的所有标准工具都已和对象数据库中的所有新结构加在了一起，那么我们应该在哪里和怎样利用这些新结构呢？性能、设计和维护的影响是什么呢？本书将试图回答所有这些问题。然而，技术总是在朝前发展，在你读这本书时，给出的建议大概已经过时了。因此，这里不仅要试图给出最好方法，而且要讨论一般情况下设计和制作模型的最好方法，以便使这些工具能够跟得上我们的想象力，使你们愿意使用这个新技术。1.1.4 创建对象-关系系统我们不应该通过目前Oracle 8i的执行情况来判断对象-关系范例的有效性， Or

15、acle 8i中的对象相对较新。可以假设对象支持的水平和质量将会在今后几年里有重大改进。这里将要讨论一个对象-关系数据库的完全实施可能会为我们提供什么。对象-关系范例具备哪些简单关系数据库中所不具备的优势呢？ 能够以更快的速度和更少的花费创建数据库。 能够更容易地、以更少的花费维护数据库。 系统将会更加灵活和健壮，因而事务中的变化或新发现的需求能够更容易地、以更少的花费被修改。这就是对象-关系方法的前景所在。从目前Oracle 8i中对象扩展的状态来看，还不能完全实现这些好处，但随着产品的成熟，我们确实期望这些前景会得到实现。对象-关系方法究竟是利用什么来提供这些好处的呢？对象-关系方法是传统

16、关系方法的一种改进。利用对象-关系方法，不仅应知道这个模型的组织结构的好处是什么，而且应试图将这些好处加以合适推广。一些人已经开始以面向对象的方式来思考问题，每当建立一个超类/子类模型时，面向对象的思想就得到了使用。在传统的人这个超类和顾客与雇员子类中，我们认识到人是人和顾客的一个概化。然而，在关系模型中并没有明确的方法实施子类，要么把所有的属性放到一个表中，要么将它们分成两个或更多个表。在关系数据库中并没有明确的方法表达“概化”的意思。关系和对象思想之间理论上一个主要的不同是：在关系数据库中，分开考虑数据和应用，而在对象思想中，合起来考虑数据和与它关联的操作和方法。在O r a c l e领

17、域中，经常分开考虑数据和应用。在Oracle Designer中，通过交互矩阵将功能连接到实体中。在Oracle Developer中，应用被连接到数据中，其方法与程序和数据结构相互作用的方法一样。逻辑上，数据和代码不应该分开考虑。数据对象和它们各自的操作与方法结合起来考虑的面向对象的方法是一种更自然、更符合逻辑的方法。利用这种更自然的制作模型的方法，开发与维护速度可以期望得到改进。系统与所使用工具的分离越大，开发过程就会越长。如果能够使R D B M S及其工具与面向对象的方法更加一致，那就能够更快地构造更好的系统。希望改善的第二个原因是数据模型更小了（表减少了）、更健壮了，而且更加易于开发

18、。本章最后的例子将会解释这一点。1.2 什么是U M L随着日益复杂的系统的出现，一个用来描述它们的清晰、简洁的方法正变得越来越重要。4计计第一部分基础下载针对这种需要，Grady Booch、Jim Rumbaugh和Ivar Jacobson开发出了统一建模语言（ U M L）。在建立一个信息管理和事务处理的模型及文档系统时，可以利用面向对象的分析和设计方法建立U M L。为了构造成功的系统，一个健全的模型是很重要的，它将总的系统计划和整个开发组联系在了一起。像其他任何语言一样， U M L有它自己的组成和原则且将用于整本书，用来阐明构造不同模型模式和实际系统的例子。设计U M L的基本目

19、标如下所示： 向用户提供了一种随时可用的可视化模型语言以便他们能够开发和交换有意义的模型。 为扩展核心概念提供了扩展和规范机制。 独立于特定的编程语言和开发过程。 为理解模型语言提供了正式基础。 鼓励面向对象工具市场的发展。 支持较高层次的开发概念，如合作、框架、模式和组件。 集成最好的实践经验。基于以上所有理由， U M L是设计对象-关系系统的可选择语言。U M L并不只是实体关系图的替代物。U M L包含了许多组成部分，它们结合在一起提供了一个完整的面向对象的开发环境。U M L中处理数据模型的部分是类图，本书将专门讨论U M L中的类图，同时简单地提及U M L中的任何其他部分。应该注

20、意，U M L包括整个系统设计环境，而不只是数据模型。关于U M L的完整讨论可在任何一本能够获得U M L的书中找到。U M L的组成部分包括： 类图（Class diagram）。这是数据模型图示语言，它与E R模型的作用范围差不多。 对象图（Object diagram)。这是一种只有一组对象的类图。可把它看作是一种显示例子数据而不是总的数据模型的一种数据模型，它对解释复杂的图是很有用的。 用例图（Use case diagram）。用例的思想类似于O r a c l e的C A S E方法中的“函数”。用例图显示了各种角色（例如顾客、雇员）和使用情况的集成。在O r a c l e方法

21、学中没有这种图的模拟。 时序图（ Sequence diagram）。时序图显示了按时间顺序安排的对象的交互过程。它类似于Oracle Designer中的过程流程图。 合作图（ Collaboration diagram）。为了执行某些功能，对象之间需要传递信息，合作图显示了这些对象及其相关信息。O r a c l e方法学中没有这种图的模拟。 状态图（ Statechart diagram）。状态图是标准的状态转换图。它们表明一个对象可处于什么状态，什么原因可使对象转换状态。O r a c l e方法学中没有这种图的模拟。 行为图（Activity diagram）。行为图是一种流程图，它

22、表示操作及其判定点。它类似于Oracle Designer中的数据流程图。 执行图（ Implementation diagram）。执行图表明了系统组件以及它们之间的交互作用。执行图能够表示系统中的软件或硬件组成部分。使用U M L对于熟悉E R模型的人来说，重要的是要认识到向U M L类图的转换并不令人惊奇。严格的模型制作者更加熟悉实体关系图（ E R D）的受限之处。U M L消除了部分而绝不是全部的限制，第1章概述计计5下载在E R D中我们不喜欢的一些内容在U M L中仍然存在。搞清楚关系和对象模型的术语是很重要的。需要记住的是， E R模型中的“实体”概念应被U M L中的“类”概

23、念所代替。类的正确定义要比实体定义的范围广。也可以使用对象描述处理信息。但是，在下面的讨论中，对象一词被用来表示上下文中的数据对象。一个类就是一些有意义的事物的集合，或是有意义的事物的一种分类。关键一点是一个实体或类经常代表现实生活中的某些东西，这是一个可以检验数据模型有效性的关键机制。该数据模型能准确表达类中的每个对象所对应的现实生活中的“东西”吗？如果不能被准确表达，那就没有一个有效的数据模型。对E R模型制作者来说，类和实体一般认为是等同的。但是，它们之间有一个重要的分别，即类和“方法”是有关系的，方法可认为是P L / S Q L、J a v a或与表相互作用的函数。例如，对一个雇员来

24、说，相关联的方法可能有雇佣、解雇、提升、分配至部门、分配至委员会等。穷尽地开发出一系列方法，以便使开发者只需要与这些方法相互作用而不必直接操作类中的数据是完全可能的。将开发者从类的物理结构中分离出来被认为是面向对象技术的基本优点。但是，这却需要仔细考虑怎样为自己的开发组建立结构。如果开发者构造方法和开发应用程序一样，那么封装将不会带来什么好处。1.3 Oracle的面向对象产品Oracle 8i并不是第一次使用具有面向对象思想的O r a c l e产品。在Form 4.5中通过使用属性类曾对面向对象做了第一次尝试。可对应用中的任何对象设置和执行属性的标准设置。利用库和对象组的P L / S

25、Q L是一组极为丰富的特性，可提供一些创建可重用程序组件的能力。一些人甚至将应用程序中的所有部件都封装到可重用结构中。现在的产品正开始向更好地支持面向对象思想的方向发展。在R D B M S中从8 . 0版起步，O r a c l e第一次提供了对象-关系数据库。8 i版已经对这次编写工作作了测试，期望在1 9 9 8年年底可得到使用。在对象扩展中，主码补充上了对象标识符（O I D），传统的参照完整性利用对象指针进行扩展，且增加了两个非第一范式结构：嵌套表和参考表。Oracle Developer 2.0首次于1 9 9 8年3月发表，提供了显式模板和对象库支持（多年来，许多人一直在为产生这

26、个模板功能而努力）。这个继承模型被改进以便引用的对象能够被修改。最后，挂接块到P L / S Q L过程的能力也增加了进去，这对于将块连接到Oracle 8i对象扩展中起到了先驱作用。Oracle Designer 2.1版（ 1 9 9 8年6月）通过新增加一个称为对象数据库设计器（ O b j e c tDatabase Designer，O D D）的新组件提出了第一个对象扩展。这个组件提供了利用U M L类图的子集产生Oracle 8i对象扩展D D L代码的能力。随着R D B M S中对象的扩展， Oracle Developer开始支持编写针对对象扩展的应用程序，同时Oracle

27、 Designer 开始支持D D L的产生。现在可以创建对象系统了吗？这倒不一定。到目前为止，关系和面向对象数据库的结合仍然很新。纵然是这次编写工作，我们仍然不能对Oracle 8i中的属性和方法完全继承， Oracle 8i仅提供了有限的可继承性。在Oracle Designer的O D D中，U M L的许多重要特征还未被实施。这并不意味着对象-关系数据库是一个坏想法，只是因为它们仍在发展中。在今后的几年内，对象-关系数据库将会作为新的系统标准完全代替传统的关系数据库。6计计第一部分基础下载很明显，对象-关系数据库是未来的发展趋势。但是，目前还不准备构造对象-关系系统的产品。首先， Or

28、acle 8i中的对象扩展需要经历另一个反复的过程，这至少需要一个完全的可继承性以便能够说明已经有了面向对象系统。在Oracle 8i中，可继承性目前有一个语言接口问题。这个问题是：各种语言对“继承性”含义的理解并不一致。C + +支持多重继承性，J a v a则不支持。O r a c l e语言接口（ C + +，J a v a）中的每一种都完全支持语言的继承性模型。（在Oracle 8i中, Java的继承性在服务器端是可以利用的。）在Oracle Designer方面，需要U M L类图在O D D中的完全执行，也需要U M L中的其他一些部分在产品中得到应用，此外还需要能产生与对象结构

29、共同运行的模块。Oracle Designer支持静态数据库U M L建模。据估计， U M L用户中的8 5 %将他们自己局限在静态建模中。O r a c l eD e s i g n e r支持适合产生Oracle 8i结构的U M L子集，这应该可以使大多数用户得到满足。但是，本书提倡使用全部U M L类图语法设计数据模型。当设计者增加更多的U M L支持时，可利用第三方工具和Oracle 8i中的对象-关系特征得到完整的U M L模型结果。1.4 Oracle 8i 中的新特征Oracle 8i包括一些新特征，其中一些专门属于对象-关系数据结构的可用性。本节将提供许多新的Oracle

30、8i对象特征的概况，这些特征的大部分扩展到本书更为详细的例子中。1.4.1 对象-关系数据结构我们将先开始讨论与对象层相关的Oracle 8i的新特征，因为这是改进最重要的一个领域。虽然Oracle 8i中的改进并不全与对象相关，但它们中的大多数都与对象-关系结构有关。1. 列与行类型类型是一种物理结构，用它来作为其他类型和/或表的模板或构造块。列类型是用来定义有一个或多个属性或成员的组织结构的类型，这些属性或成员共同描述了有一个或多个列对象的结构。代码1 - 1定义了一个列类型N A M E _ T,它描述了存储姓名信息的列结构，例如人的姓和名。代码1 - 1行类型是用来定义一个对象表的整个

31、结构的类型。代码1 - 2定义了一个类型P E R S O N _ T。P E R S O N _ T类型包括4个属性： P E R S O N _ I D（即产生的唯一标识序列U I D）、L N A M E _ T X（即姓）、F N A M E _ T X（即名）和B I RT H _ D AT E（即出生日期）。代码1 - 2 a第1章概述计计7下载注意，既然L N A M E _ T X和F N A M E _ T X列的数据类型说明不能显式地定义为VA R C H A R（5 0），D M L语句的典型关系语法就不会起作用。相反，数据类型引用了在代码1 - 1中定义的新列类型N A M E _ T。同样，任何D M L语句都必须指定列类型。列类型类似于Oracle Designer中的域，主要是由于它们将列结构归类。如果还需要修改系统中每个姓名字段的数据类型或长度，则只需修改N A M E _ T的列类型，因为它的结构被每一个姓名字段所共享。同样，行类型产生了对象表结构