ORACLE8 UML 对象建模设计01.docx
《ORACLE8 UML 对象建模设计01.docx》由会员分享，可在线阅读，更多相关《ORACLE8 UML 对象建模设计01.docx（40页珍藏版）》请在冰豆网上搜索。
ORACLE8UML对象建模设计01
第1章概述
本章我们将简单讨论对象-关系模型，并概述数据库行业从60和70年代的展开文件结构到
数据库理论最近趋势的发展。
我们也将针对统一建模语言（UML）、Oracle环境的概观以及
Oracle8i中可利用的新特征作简单介绍。
1.1对象-关系数据库的发展
当从事于信息系统技术的人们开始利用数据库工作时，数据库由一系列文件构成。
我们
主要用CODASYL语言的COBOL扩展来访问这些结构。
在处理文件时，CODASYL给了我们
利用FIRST_RECORD、NEXT_RECORD和LAST_RECORD这类命令的能力，这是我们第一
次利用数据库游标。
在处理数据文件方面，CODASYL使我们能够比通过阅读text文件更有效
地工作。
我们对这些结构使用索引、ISAM和VSAM文件，这类结构建立在链接表基础上且与
索引结构分离。
第一次我们有了一个数据库管理系统（DBMS），在数据和程序之间具有了一定程度上的
独立性。
不幸的是，其中仍旧存在一些问题：
程序仍然很大，甚至系统中微小的变化可能也
需要数百（如果不是数千）小时的人工。
你只需看看现在扰人的2000年问题，就可认识到这
种系统的局限性。
关系系统以其巨大的理论优势胜过传统的以CODASYL为基础的系统。
开发者能够把文件
看作是简单的逻辑展开文件，所有的索引和SQL查询语句分析都可由关系DBMS（RDBMS）来
进行。
不幸的是，仍然存在许多问题。
查询运行得如此缓慢以致于开发者不得不取代缺省的
SQL语法分析算法。
80年代，要想获得好的性能是如此困难，以致于一些数据库设计者感觉
到很有必要回到非规范化数据模型。
1.1.1关系数据库
关系模型是一种非常精巧、清楚的模型，它已经为数据库行业提供了近20年的基础。
关
系理论中较少的概念已使关系数据库成为行业标准。
关系数据库厂家已经能够主要从系统逻
辑设计上孤立数据库物理实施的复杂性，由此提供了一个简单的应用开发者接口。
在过去的20年里，数据库已经作为一个行业发展成熟起来。
许多人已经感觉到使建模环
境更加丰富的必要性，这种环境更能适应向类属建模的发展。
而且，我们认识到面向对象理
论的一些概念能够被引入数据库行业，甚至可以带来更高的效率。
关系数据库的词汇量相对有限。
我们通过精心设计展开文件来实现结构的设计，并将一
些不同类型的索引放在那些文件的不同字段中。
就访问而言，表之间的连接只被逻辑指明，
第一部分基础
所以参照指针通过外码执行，表之间确实无显式连接。
参照完整性约束仅仅是一些阻止特殊
种类的无效数据放在数据模型中的代码段。
当一个记录被插入、更新或删除时，可以将触发
器加到表中，以便明确地执行一些操作，并且可将程序单元存储到数据库中。
最后，可用簇
表来改善性能。
这些策略仍旧会限制我们以一个相当有限的方式思考。
在关系数据库中，每
个表事实上是一个独立的结构。
在逻辑实体关系（ER）模型中，有作为其他实体子集的实体。
例如，领薪金者雇员是所
有雇员的子集。
同样，有基于其他实体的实体。
例如PO明细，它是基于购货单（Purchase
Order）的。
但是，在关系数据库范例中表达这种结构的能力是有限的。
看似矛盾的是，面向对象数据库保持了早期数据库理论的一些概念。
正如在CODASYL时
期，当把对象定位带入关系数据库世界时，人们发现遇到了“老朋友”，如链接表和指针。
重要的是不要忘记最初放弃链接表和指针的理由，要记住在80年代早期关系数据库出现之
前数据库是怎样的。
目前仍有一些高性能的数据库（至少要到2000年问题将它们消灭为止），
它们的运行主要使用COBOL编写的CODASYL、ISAM和VSAM文件。
CODASYL数据库的修
改通常需要花费几个月的精力。
我们早期遇到过一个COBOL项目，其中有一个将一个字段的
长度从10个字符改为12个字符的简单需求。
这个转换花费了几百个小时的编程。
现在，在关系
数据库环境中，这样一个转换最多仅需几天时间。
如果应用程序是用OracleDesigner（或其他
一些集成CASE工具）产生的，这样一个转换即使在一个大系统中也只需执行1~2天就能实现。
在关系数据库之前的时代，支持报表需求是很困难的。
如果一个特殊的报表并非为了系
统的最初设计规范而计划，那就能够容易地花费几周时间去编写一个新的报表（假定编写这
个报表是可能的）。
对基础性数据结构的修改是很麻烦的，似乎微小的变化就得需要整个大系
统重新设计。
虽不能断言所有这些问题已随着实体关系图（ERD）和关系数据库的出现而消
失，但状况显然已得到改善。
早期的关系数据库看起来很像展开文件的前身，规范化被认为是一件纯粹满足好奇心的
事。
直到最后，至少通过第三范式，才发现规范化并不是一个坏想法。
由于80年代的严重不
规范化，在处理关系结构时遇到了一些处理展开文件时遇到的同样问题。
数据结构的修改仍
然很难且很昂贵，就像应用程序的修改一样。
截止到1990年，大多数数据模型制作者已经认
识到，当80年代的那些系统需要修改时，其严重的非规范化会引起许许多多的问题。
规范化
最终成为“流行时尚”。
90年代中期，一些早期的面向对象的思考开始转向关系数据库。
在Oracle世界里，这涉及
到通过创建更抽象的结构构造模型，但仍然在关系数据环境中操作。
在最近几年里，一些关
系数据库已经包含了面向对象的思想。
现在，在大部分系统中看到某种级别的类属建模是很普通的。
例如，把组织单位表示为
一个简单的递归结构是行业标准，而不是用单独的表表示区域、部门和科室（或代表特殊组
织的任一种结构）。
更抽象的模型正变得很平常。
在最近的一次会议中，设计数据库调查表的人问如何支持
一个有几百列的表，且每一份调查表都有几百个问题。
被调查者中的一些人回答说应通过将
答案放在一个单独的表中和将调查表的结构作为数据存入数据库来为调查表建立模型。
一个
无争议的解决办法因此而产生，面向对象的思想进入了数据模型。
最近,面向对象的发展更进了两步。
首先，数据库本身已包括新的面向对象的特点。
其次，
2计计第一部分基础
下载
在UML中有了比在ERD中更新、更丰富的模型语言。
如前所述，这些新概念实际上包括一些
关系思想之前的老概念，如链接表和指针。
这种新老集成提供了一个很好的机会，但必须谨
慎地对待。
现在能够构造操作更有效的关系结构，但如果不仔细，可能会失去一些由关系数
据库范例而带来的结构灵活性。
1.1.2对象-关系数据库
对象-关系数据库正向我们走来。
近10年来，“面向对象”已成为计算机行业最时髦的语
言。
在计算机行业中随便捡起一本杂志就会看到一些有关面向对象的文章。
面向对象通常被
错用来作为可重用代码的同义词，前者的含义是指一组准确的、推理性的计算机科学结构，
它能影响系统的每个方面，包括编程语言、工具和数据库。
这种技术的主要影响表现在编程上，面向对象有助于转变编程的过程。
但是，应该认识
到，并非每个C++程序都是面向对象的。
系统中有关面向对象的最重要的方面就是设计组的
思想。
程序编写时没有可重用组件和标准是很平常的。
前一段时间，我们核查了一个用C++
编写的大系统的失败，其中，每个程序员都设定了自己的标准，整个系统只有少部分是利用
面向对象的编程标准来编写的。
在一定程度上，面向对象的革命已经对数据库界产生了一定的影响。
由主要数据库模型
制作者支持的类属模型的发展如此强烈就是这场革命的反映。
同样，在应用开发中，拥有可
重用对象组件的模板的广泛应用正在成为主要编程厂家的规范。
从这一点上说，为了更好地
支持面向对象，Oracle现在正在改进RDBMS、OracleDesigner和OracleDeveloper。
1.1.3“对象-关系”的真正含义
如果你问六位专家“对象-关系”是什么意思，那你将会得到六个答案。
现在仍然在试图
结合关系范例和对象范例，结合两者将不是一件容易的事。
真正的对象数据库是市场的很小一部分，对象-关系数据库还处在发展阶段。
问题是要确定
在这个新的范例中究竟想得到什么。
关系已有了20年的历史，在这期间，关系技术已成熟发展
到了一个复杂的环境。
最终，人们有了足够的参照完整性、存储程序和触发器，一些人已算出
如何避免变化的表。
同样，面向对象编程几乎和关系数据库同时起步，也已有了20年的历史。
我们不应该指望面向对象是灵丹妙药。
面向对象编程还没有解决编程人员的所有问题。
相反，对象结构要求用一种完全不同的方法考虑编程。
面向对象将另外一层复杂性增加到环
境中。
许多编程厂家在向面向对象的转换过程中遇到了很大困难，而其他一些厂家则报告说
他们的编程效率有了极大的提高。
面向对象数据库把对象的存在作为一种不易变的结构来考虑。
宁愿用参照指针，也不愿
通过参照完整性来连接对象。
继承性是被完全支持的，访问对象严格限于通过使用相关的方
法和操作来进行。
对象-关系系统正试图结合两者的优点，即对象标识符和主码。
对象将通过对象引用和参
照完整性联系起来。
这种系统中还同时具备触发器和方法。
表可独立构造，也可从一些父结
构（称为类）继承属性和方法。
但是，很难将这些实施到一个关系模型中。
目前，Oracle8i有了对象标识符和方法，但只
有有限的继承性。
第1章概述计计3
下载
从开发者的前景来看，最大的挑战是如何最好地利用这些新功能。
关系数据库中的所有
标准工具都已和对象数据库中的所有新结构加在了一起，那么我们应该在哪里和怎样利用这
些新结构呢？
性能、设计和维护的影响是什么呢？
本书将试图回答所有这些问题。
然而，技术总是在朝前发展，在你读这本书时，给出的建
议大概已经过时了。
因此，这里不仅要试图给出最好方法，而且要讨论一般情况下设计和制
作模型的最好方法，以便使这些工具能够跟得上我们的想象力，使你们愿意使用这个新技术。
1.1.4创建对象-关系系统
我们不应该通过目前Oracle8i的执行情况来判断对象-关系范例的有效性，Oracle8i中的
对象相对较新。
可以假设对象支持的水平和质量将会在今后几年里有重大改进。
这里将要讨
论一个对象-关系数据库的完全实施可能会为我们提供什么。
对象-关系范例具备哪些简单关系数据库中所不具备的优势呢？
■能够以更快的速度和更少的花费创建数据库。
■能够更容易地、以更少的花费维护数据库。
■系统将会更加灵活和健壮，因而事务中的变化或新发现的需求能够更容易地、以更少
的花费被修改。
这就是对象-关系方法的前景所在。
从目前Oracle8i中对象扩展的状态来看，还不能完全
实现这些好处，但随着产品的成熟，我们确实期望这些前景会得到实现。
对象-关系方法究竟是利用什么来提供这些好处的呢？
对象-关系方法是传统关系方法的
一种改进。
利用对象-关系方法，不仅应知道这个模型的组织结构的好处是什么，而且应试图
将这些好处加以合适推广。
一些人已经开始以面向对象的方式来思考问题，每当建立一个超类/子类模型时，面向对象
的思想就得到了使用。
在传统的人这个超类和顾客与雇员子类中，我们认识到人是人和顾客的
一个概化。
然而，在关系模型中并没有明确的方法实施子类，要么把所有的属性放到一个表中，
要么将它们分成两个或更多个表。
在关系数据库中并没有明确的方法表达“概化”的意思。
关系和对象思想之间理论上一个主要的不同是：
在关系数据库中，分开考虑数据和应用，
而在对象思想中，合起来考虑数据和与它关联的操作和方法。
在Oracle领域中，经常分开考虑数据和应用。
在OracleDesigner中，通过交互矩阵将功能
连接到实体中。
在OracleDeveloper中，应用被连接到数据中，其方法与程序和数据结构相互
作用的方法一样。
逻辑上，数据和代码不应该分开考虑。
数据对象和它们各自的操作与方法
结合起来考虑的面向对象的方法是一种更自然、更符合逻辑的方法。
利用这种更自然的制作模型的方法，开发与维护速度可以期望得到改进。
系统与所使用
工具的分离越大，开发过程就会越长。
如果能够使RDBMS及其工具与面向对象的方法更加一
致，那就能够更快地构造更好的系统。
希望改善的第二个原因是数据模型更小了（表减少了）、更健壮了，而且更加易于开发。
本章最后的例子将会解释这一点。
1.2什么是UML
随着日益复杂的系统的出现，一个用来描述它们的清晰、简洁的方法正变得越来越重要。
4计计第一部分基础
下载
针对这种需要，GradyBooch、JimRumbaugh和IvarJacobson开发出了统一建模语言（UML）。
在建立一个信息管理和事务处理的模型及文档系统时，可以利用面向对象的分析和设计方法
建立UML。
为了构造成功的系统，一个健全的模型是很重要的，它将总的系统计划和整个开
发组联系在了一起。
像其他任何语言一样，UML有它自己的组成和原则且将用于整本书，用
来阐明构造不同模型模式和实际系统的例子。
设计UML的基本目标如下所示：
■向用户提供了一种随时可用的可视化模型语言以便他们能够开发和交换有意义的模型。
■为扩展核心概念提供了扩展和规范机制。
■独立于特定的编程语言和开发过程。
■为理解模型语言提供了正式基础。
■鼓励面向对象工具市场的发展。
■支持较高层次的开发概念，如合作、框架、模式和组件。
■集成最好的实践经验。
基于以上所有理由，UML是设计对象-关系系统的可选择语言。
UML并不只是实体关系图的替代物。
UML包含了许多组成部分，它们结合在一起提供了
一个完整的面向对象的开发环境。
UML中处理数据模型的部分是类图，本书将专门讨论UML
中的类图，同时简单地提及UML中的任何其他部分。
应该注意，UML包括整个系统设计环境，
而不只是数据模型。
关于UML的完整讨论可在任何一本能够获得UML的书中找到。
UML的组成部分包括：
■类图（Classdiagram）。
这是数据模型图示语言，它与ER模型的作用范围差不多。
■对象图（Objectdiagram）。
这是一种只有一组对象的类图。
可把它看作是一种显示例子
数据而不是总的数据模型的一种数据模型，它对解释复杂的图是很有用的。
■用例图（Usecasediagram）。
用例的思想类似于Oracle的CASE方法中的“函数”。
用例
图显示了各种角色（例如顾客、雇员）和使用情况的集成。
在Oracle方法学中没有这种
图的模拟。
■时序图（Sequencediagram）。
时序图显示了按时间顺序安排的对象的交互过程。
它类
似于OracleDesigner中的过程流程图。
■合作图（Collaborationdiagram）。
为了执行某些功能，对象之间需要传递信息，合作
图显示了这些对象及其相关信息。
Oracle方法学中没有这种图的模拟。
■状态图（Statechartdiagram）。
状态图是标准的状态转换图。
它们表明一个对象可处于
什么状态，什么原因可使对象转换状态。
Oracle方法学中没有这种图的模拟。
■行为图（Activitydiagram）。
行为图是一种流程图，它表示操作及其判定点。
它类似于
OracleDesigner中的数据流程图。
■执行图（Implementationdiagram）。
执行图表明了系统组件以及它们之间的交互作用。
执行图能够表示系统中的软件或硬件组成部分。
使用UML
对于熟悉ER模型的人来说，重要的是要认识到向UML类图的转换并不令人惊奇。
严格的
模型制作者更加熟悉实体关系图（ERD）的受限之处。
UML消除了部分而绝不是全部的限制，
第1章概述计计5
下载
在ERD中我们不喜欢的一些内容在UML中仍然存在。
搞清楚关系和对象模型的术语是很重要的。
需要记住的是，ER模型中的“实体”概念应
被UML中的“类”概念所代替。
类的正确定义要比实体定义的范围广。
也可以使用对象描述
处理信息。
但是，在下面的讨论中，对象一词被用来表示上下文中的数据对象。
一个类就是一些有意义的事物的集合，或是有意义的事物的一种分类。
关键一点是一个
实体或类经常代表现实生活中的某些东西，这是一个可以检验数据模型有效性的关键机制。
该数据模型能准确表达类中的每个对象所对应的现实生活中的“东西”吗？
如果不能被准确
表达，那就没有一个有效的数据模型。
对ER模型制作者来说，类和实体一般认为是等同的。
但是，它们之间有一个重要的分别，
即类和“方法”是有关系的，方法可认为是PL/SQL、Java或与表相互作用的函数。
例如，对
一个雇员来说，相关联的方法可能有雇佣、解雇、提升、分配至部门、分配至委员会等。
穷
尽地开发出一系列方法，以便使开发者只需要与这些方法相互作用而不必直接操作类中的数
据是完全可能的。
将开发者从类的物理结构中分离出来被认为是面向对象技术的基本优点。
但是，这却需要仔细考虑怎样为自己的开发组建立结构。
如果开发者构造方法和开发应用程
序一样，那么封装将不会带来什么好处。
1.3Oracle的面向对象产品
Oracle8i并不是第一次使用具有面向对象思想的Oracle产品。
在Form4.5中通过使用属性
类曾对面向对象做了第一次尝试。
可对应用中的任何对象设置和执行属性的标准设置。
利用
库和对象组的PL/SQL是一组极为丰富的特性，可提供一些创建可重用程序组件的能力。
一些
人甚至将应用程序中的所有部件都封装到可重用结构中。
现在的产品正开始向更好地支持面
向对象思想的方向发展。
在RDBMS中—从8.0版起步，Oracle第一次提供了对象-关系数据库。
8i版已经对这次
编写工作作了测试，期望在1998年年底可得到使用。
在对象扩展中，主码补充上了对象标识
符（OID），传统的参照完整性利用对象指针进行扩展，且增加了两个非第一范式结构：
嵌套
表和参考表。
OracleDeveloper2.0首次于1998年3月发表，提供了显式模板和对象库支持（多
年来，许多人一直在为产生这个模板功能而努力）。
这个继承模型被改进以便引用的对象能够
被修改。
最后，挂接块到PL/SQL过程的能力也增加了进去，这对于将块连接到Oracle8i对象
扩展中起到了先驱作用。
OracleDesigner2.1版（1998年6月）通过新增加一个称为对象数据库设计器（Object
DatabaseDesigner，ODD）的新组件提出了第一个对象扩展。
这个组件提供了利用UML类图
的子集产生Oracle8i对象扩展DDL代码的能力。
随着RDBMS中对象的扩展，OracleDeveloper开始支持编写针对对象扩展的应用程序，
同时OracleDesigner开始支持DDL的产生。
现在可以创建对象系统了吗？
这倒不一定。
到目
前为止，关系和面向对象数据库的结合仍然很新。
纵然是这次编写工作，我们仍然不能对
Oracle8i中的属性和方法完全继承，Oracle8i仅提供了有限的可继承性。
在OracleDesigner的
ODD中，UML的许多重要特征还未被实施。
这并不意味着对象-关系数据库是一个坏想法，只是因为它们仍在发展中。
在今后的几年
内，对象-关系数据库将会作为新的系统标准完全代替传统的关系数据库。
6计计第一部分基础
下载
很明显，对象-关系数据库是未来的发展趋势。
但是，目前还不准备构造对象-关系系统
的产品。
首先，Oracle8i中的对象扩展需要经历另一个反复的过程，这至少需要一个完全的
可继承性以便能够说明已经有了面向对象系统。
在Oracle8i中，可继承性目前有一个语言接
口问题。
这个问题是：
各种语言对“继承性”含义的理解并不一致。
C++支持多重继承性，
Java则不支持。
Oracle语言接口（C++，Java）中的每一种都完全支持语言的继承性模型。
（在
Oracle8i中,Java的继承性在服务器端是可以利用的。
）
在OracleDesigner方面，需要UML类图在ODD中的完全执行，也需要UML中的其他一些
部分在产品中得到应用，此外还需要能产生与对象结构共同运行的模块。
OracleDesigner支持
静态数据库UML建模。
据估计，UML用户中的85%将他们自己局限在静态建模中。
Oracle
Designer支持适合产生Oracle8i结构的UML子集，这应该可以使大多数用户得到满足。
但是，
本书提倡使用全部UML类图语法设计数据模型。
当设计者增加更多的UML支持时，可利用第
三方工具和Oracle8i中的对象-关系特征得到完整的UML模型结果。
1.4Oracle8i中的新特征
Oracle8i包括一些新特征，其中一些专门属于对象-关系数据结构的可用性。
本节将提供
许多新的Oracle8i对象特征的概况，这些特征的大部分扩展到本书更为详细的例子中。
1.4.1对象-关系数据结构
我们将先开始讨论与对象层相关的Oracle8i的新特征，因为这是改进最重要的一个领域。
虽然Oracle8i中的改进并不全与对象相关，但它们中的大多数都与对象-关系结构有关。
1.列与行类型
类型是一种物理结构，用它来作为其他类型和/或表的模板或构造块。
列类型是用来定义有
一个或多个属性或成员的组织结构的类型，这些属性或成员共同描述了有一个或多个列对象的
结构。
代码1-1定义了一个列类型NAME_T,它描述了存储姓名信息的列结构，例如人的姓和名。
代码1-1
行类型是用来定义一个对象表的整个结构的类型。
代码1-2定义了一个类型PERSON_T。
PERSON_T类型包括4个属性：
PERSON_ID（即产生的唯一标识序列UID）、LNAME_TX
（即姓）、FNAME_TX（即名）和BIRTH_DATE（即出生日期）。
代码1-2a
第1章概述计计7
下载
注意，既然LNAME_TX和FNAME_TX列的数据类型说明不能显式地定义为VARCHAR
（50），DML语句的典型关系语法就不会起作用。
相反，数据类型引用了在代码1-1中定义的新
列类型NAME_T。
同样，任何DML语句都必须指定列类型。
列类型类似于OracleDesigner中的域，主要是由于它们将列结构归类。
如果还需要修改系
统中每个姓名字段的数据类型或长度，则只需修改NAME_T的列类型，因为它的结构被每一
个姓名字段所共享。
同样，行类型产生了对象表结构
升级会员 