首页 百科知识 面向对象数据库系统的对象理论

面向对象数据库系统的对象理论

时间:2022-10-09 百科知识 版权反馈
【摘要】:面向对象技术最初是从面向对象的程序设计技术演变而来的。关系数据库方法是在一个最低级的层次上,用一系列的表列和行处理数据。在面向对象的数据库中处理客户时,是处理一个称为“客户”的对象。为表示现实世界的实体,对象由属性和操作信息组成。封装具有仅能通过对象提供或认可的动作访问该对象和其数据的性质。这与关系数据库的基本原理数据独立性相悖。在面向对象的模型中,数据行为存放在数据库内,而非数据库外。

7.2 面向对象数据库系统的对象理论

面向对象技术最初是从面向对象的程序设计技术演变而来的。面向对象的设计方法将客户世界分解成一个一个的对象,可以把一个一个的对象理解为功能齐备的集成块,将这些集成块组合起来就可以构成完整的程序。由于封装成对象,对象之间通过消息调用传递信息,易于修改,对象的移植及复用性好。通过定义这些对象本身的属性、方法、消息调用机制来设计程序。结构化程序设计是面向过程的,按照解决问题的思路一步一步编制模块化的程序,不能很好地符合人的认识习惯,程序之间的改动将互相关联,开发好的代码很少能被其他系统吸收和利用。

关系数据库方法是在一个最低级的层次上,用一系列的表列和行处理数据。面向对象的方法是在更高的层次上处理数据的。它处理包裹着数据的对象。在面向对象的数据库中处理客户时,是处理一个称为“客户”的对象。当处理一个订单时,引用一个称为订单的对象。

因为对象数据库理解对象客户和所有它的关系,它能容易地处理对象客户和所有与它一起工作的对象。

在关系模型中,订单实际是许多不同的表的组合,并带有装有用来支持和维护一个订单所需的属性的交表。在对象模型中,数据库对相互间的关系具有智能性,而在关系模型中则没有。当对关系模型做出更改时,通常翻译成一系列的新表,如果模型还要继续使用的话,此系列是必须建立的。这些关系必须由一个数据库设计者来重新设计。我们进一步来看看当置一个客户于关系数据库的一个订单中的情形。有大量支持这个活动所需的表。可能有客户表、清单表、价目表、清单价目表、行项目表、客户历史表等。为处理这些表,程序设计员必须利用表间所需的连接来设计代码。

可以看出,处理一个订单这一简单的动作需要大量的表。表中行和表列含有组装序所需的信息。对订单处理的一个更改可能会对支持它的基表有重要的影响。需要数据库设计者来设计新的关系和表示这些关系所涉及的表。在面向对象的模型中,就不会这样。事实上,假定模型改变,此改变将自然地产生和进行。

7.2.1 对象

对象(Object)是现实世界实体的软件表示。为表示现实世界的实体,对象由属性和操作信息组成。在面向对象的数据库中,数据字典不仅仅存放(并使你能理解)一个对象与另一个对象的关系,而且它也知道对象的行为。

提示对象是现实世界实体的软件表示。

7.2.2 类

当多个对象相互间在行为和属性方面类似时,可把它们归入一类(C1ass)。类、父类、子类、超子类的概念使得能在抽象层次上组织对象。把类想象成一个对象的模板有助于管理非常复杂的对象。用类组织对象的功能使对象能利用行为的类似以及其他共有特性。类为对象的模板。

7.2.3 封装

面向对象模型的基础之一是支持封装(Encapsulation)。所谓封装指数据被绑定于特定的对象,使对它的访问仅能通过该对象所提供或接受的动作来进行。这能避免对数据的非法访问。

封装意味着数据库中每个对象具有清晰的定义良好的接口

根据开发者的观点,对象是数据和动作的封装,可以将其视为一个程序块。它是一个具有独立功能的代码数据集,是一个非常强有力的功能。

马上就会有一个问题,即“封装是否会违背数据独立的关系规则?”我们认为不会。面向对象的程序设计的支柱之一就是封装。封装具有仅能通过对象提供或认可的动作访问该对象和其数据的性质。这与关系数据库的基本原理数据独立性相悖。根据Codd和Chris Date对关系模型的定义,可以用特别独立方式访问任何数据。

粗略一看,可能会认为在封装时使数据独立于应用程序很重要。这样很容易得出结论,那就是封装与数据独立的差异将使关系模型与面向对象的模型不相容。但事实并非这样。

在面向对象的模型中,数据行为存放在数据库内,而非数据库外。因为数据行为在数据库内,所以它不会危及应用程序与数据的独立性。应用独立于数据是数据独立规则的基础,也是SQL和其他特定工具的基础。

7.2.4 数据库触发器

利用数据库触发器(Database Trigger),关系数据库会具有一种封装的形式。然而为支持封装,意味着要对每一种可能的访问数据的方法创建一个触发器。由经验可知告诉我们这是不可能的。

事实上,如果用数据库触发器来实现封装,整个数据库的性能都会降低。

经验表明,使用过多的数据库触发器将降低整个数据库的性能。

每当访问一个表时,需要激活相应的触发器。仅此一项就使数据库要做的工作是平常访问数据要做工作的两倍。另一个问题是很多时候数据库触发器写得不好,它会破坏数据库的性能。因此,实际上数据库触发器的应用非常有限。

在关系数据库中若使用得当的话,数据库触发器是一个非常有力的工具。但是它们不能扩展成为提供封装功能的工具。

7.2.5 可扩充性

可扩充性(Extensibility)是面向对象的数据库增加新对象及其行为而不会影响其他对象和应用的一种能力。因为数据可与对象封装在一起,这种可扩充的能力为对象模型提供了处理非标准数据的能力。这是一个非常强有力的功能。

7.2.6 多态性和继承

在面向对象技术中,其他的重要概念包括继承和多态性。继承是一个对象包括来自另一个对象类型的属性或方法的能力。方向是从一般到特殊,正像关系型模型中的子类型。一个例子是,你可能有一个雇员对象类型和一个经理对象类型(雇员类型的子类型)。所有雇员有名字、地址社会保险号等,还有雇佣日期、薪水、雇佣比例等。所有前面这些代表一般的或普通的属性,能从雇员对象类型继承到经理对象类型。这意味着有两件事与效率有关:

(1)所有雇员(包括经理)的共同属性和方法只需要存储一次。

(2)经理对象类型仅需要存储它自己特有的属性和方法,如signature_authority(属性)或:rate_an_employee(方法)。因此继承可以基于属性(结构)或方法(行为)。

刚刚被描述的情况(经理对象模型从雇员对象中继承属性和方法)称之为单继承。有另一种类型的继承称之为多继承。单继承是一个子类最多有一个父类的形式;多继承允许一个更一般的模型:网络(或格子)模型,也就是子类型能够有多个父类,像在真实世界中的情况一样。与雇员到经理的单继承对比,考虑也包含官员的多继承方案:雇员→经理←官员。箭头特指继承方向,从一般(父)到特殊(子)。

多态性像继承一样可以是结构的或行为的。考虑一个没有经理对象类型的雇员对象类型。雇员只简单地是一个雇员,而不是经理。你如何从一个雇员类型获得经理类型呢?事实上,这是一个旧的程序结构,在不同的编程语言中有不同的术语,但在这里为了全面将它描述为变量记录。一个变量记录依赖于被输入的记录类型能够包含一些共同(继承)的数据,也能包含一些附加的域。这种情况对非规范化表是模棱两可的,可能同时包含经理和雇员。方法是怎么样的?与属性类似,方法是否可见依赖于被具体说明的对象(雇员或经理)。

刚才描述了常见的结构多态性是什么。那么行为多态性是什么?在面向对象中,当一种方法被调用时,称为向它发送了一条消息(进行执行)。当你向方法发送一条消息时,它可能有不同的执行,取决于它当前属于的对象类型或被影响的实例。例如,如果你调用一个hire方法,它构造(创建)一个新的职员或经理。尽管你调用的是同一个hire方法,这里实际上有构造一个实例(实例化一个对象)的两种不同实现:通过为雇员填入共同雇员属性,或通过为经理填入共同雇员属性和特定的经理属性。面向对象系统能够通过简单IF/THEN逻辑在单个程序内或通过定向化实现这个变化的程序,定向是IF/THEN逻辑加一个对所有可能程序之外的一个必要程序的调用。多态性也称之为重载。稍后捆绑(运行时捆绑)使多态性在现代言和系统中成为可能。在面向对象中,每一个对象类型总是至少有一种方法——它自身的构造方法。

另外一个重要的概念是对象ID(OID),它表示一个在对象创建以后唯一代表该对象的统一标志符。这意味着它在所有的,甚至在Oracle之外的面向对象系统和语言中是唯一的。简言之,面向对象的数据库是对建立在传统关系数据库技术之上的对象的扩充。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈