面向对象的数据库系统

面向对象数据库乃是面向对象技术与数据库技术相结合的产物。在涉及面向对象数据库的论题之前有必要先考察一下“面向对象”的含义。

“面向对象”是近年来计算机领域中的一个出现频率颇高的词汇，在软件工程实践者看来，它常常与如下一些概念密切相关：数据抽象、封装性、继承性、多态性、可扩充性、类属程序设计、信息隐蔽、代码重用、模块化等等，甚至还可以列出更多的相关概念，但最终到底什么是“面向对象”还是不清楚。

往往一谈到“面向对象”，人们就自觉或不自觉地将它与面向对象的程序设汁语言关联起来，而面向对象的程序设计语言有许许多多，而且风格迥异，所以单从语言角度出发来理解“面向对象”是不行的。

不少计算机专家认为，“面向对象”是一种世界观和方法论。

首先，“面向对象”是一种认识客观世界的世界观，这种世界观将客观世界看成是由许多不同种类的对象构成的，每个对象都有自己的内部状态和运动规律，不同对象之间的相互联系和相互作用就构成了完整的客观世界。

其次，“面向对象”是从结构组织去模拟客观世界的一种方法，这种方法的基本着眼点是构成客观世界的那些成分——对象。

用面向对象的观点去认识世界，用面向对象的方法去模拟客观世界就构成了“面向对象”的完整含义。从系统实现的角度看，“面向对象”的实质也许可以看成是支持“数据抽象”，而且是“分层的数据抽象”。

所谓“数据抽象”，粗略地说，就是把数据对象的内部表示和它所允许的操作汇集并封装起来，使得对于数据对象的访问只能通过引用其接口中所规定的外部可见的操作来进行。

把“面向对象”概念融合到数据库中去就形成了所谓“面向对象数据库”。但是，把哪些概念融合进去以及怎么融合进去？到目前为止都是未解决的问题，看法很不一致，以致于难以面向对象数据库下一个准确的定义。

应用的需求。数据库技术自 60 年代后期问世以来，无论从理论上、技术上，还是应用上，都经历了一个飞速发展的过程。现在，大型信息系统一般都是以数据库系统作为其核心的。

从数据库系统采用的数据模型来看，70 年代广为流行的是网状模型和层次模型的数据库系统。自 80 年代以来，由于关系模型有严格的数学基础，概念简单清晰，非过程化程度高，数据独立性，因此关系型数据库系统的发展非常迅速，所以，计算机厂商新推出的数据库管理系统几乎都是支持关系模型的。

随着数据库技术的发展，数据库应用领域已从传统的商务数据处理扩展到许多新的应用领域，例如计算机辅助设计（CAD）、计算机辅助软件工程

（CASE）、图象处理、超文本应用等，关系数据库管理系统很难适应这些新应用领域中模拟复杂对象，模拟对象的复杂行为的需求。甚至在传统的商务数据处理应用中，也提出了新的处理需求，例如存储和检索保险索赔案件中的照片、手写的证词等，这些要求也是传统的关系数据库系统难以满足的。新的应用需求的主要特征是：

数据模型要能描述复杂对象，能表达更丰富的语义。
数据类型从单一的格式化数据扩展为多媒体（图象、图形、声音）等非格式化的多种类型。
支持长事务（以小时、天计）、版本管理和动态模式修改等。

数据库工作者为了给新的应用建立适合的系统，进行了艰苦的探索。所采用的办法一是对传统的 DBMS 针对不同应用进行不同的扩充。但结果表明，这种办法，系统效率常常不能令人满意，而且发现应用开发中关系查询语言和程序设计语言之间不协调、不匹配的问题，为此人们试图把逻辑程序设计和数据库相结合，把函数程序设计和数据库相结合。最近发现把面向对象的程序设计方法和数据库相结合是最有希望的方法。它提供了表示、管理程序的数据两者的统一框架。把面向对象的方法和数据库技术结合起来建造向对象的数据库系统（Object-Oriented Database Systems，简称 OODBS）。

OODBS 在逻辑上和物理上都从面向记录或元组上升为面向对象——面向具有复杂结构的一个逻辑整体。它允许以自然方法并且结合数据抽象机制在结构和行为上对复杂对象建立模型。从而大幅度地提高管理效率，降低用户使用复杂性，并为版本管理、动态模式修改等功能的实现创造了条件。数据库的许多新领域都和面向对象的领域有关系，这些领域包括：语义数据模型、嵌套关系、可扩展的数据库系统、数据库程序设计语言等等。

面向对象数据库系统的特性。面向对象数据库系统的研究始于 80 年代中后期，对 OODB 的研究，实际上是沿着不同的方向、采用不同的方法进行的。例如 OODB 数据模型的研究是沿着三条路线展开的：一条是以 RDB 和SQL 为基础，扩展关系模型（ERM）；一条是以面向对象的程序设计语言为基础，扩充 OO 模型（EOM）；一条是建立新的 OODB 数据模型（ODM ）。因此在80 年代中后期，关于 OO 概念、OODB 概念、OODB 数据模型和语言等一系列基本概念、术语的定义和理解呈现了百花齐放、百家争鸣的局面。

对于什么是面向对象的数据库系统，目前尚缺乏权威性的统一标准。然而，对于面向对象数据库系统应该具备的基本特性，国际数据库学术界已取得了大体一致的共同认识。

首先，OODB 必须支持面向对象的数据模型，具有面向对象的特性。这些特性主要包括：支持复杂对象，具有对简单对象运用各种对象构造符组成复杂对象有的能力；具有对象标识，对象独立于它的值而存在；具有封装性，数据库对象中既封装数据又封装程序，从而达到信息隐蔽，同时也是逻辑数据独立性的一种形式；支持类型和类的概念，类型概括具有相同特性的一组对象的共同特性；支持类或类型的层次结构，从而支持继承性这一有力的建模工具；允许过载，即将同一名字用于不同类型上的数据操作；通过与现有程序设计语言的合理连接来达到计算完备性；并具有可扩充性。

其次，OODB 必须是一个数据库管理系统，具有数据库管理系统的基本功能。主要包括：持久性，数据库中的数据是持久保存的；外存管理，包括索引管理、数据聚集、数据缓冲、存取路径选择、查询优化等；并发性，系统应该提供和目前的数据库管理系统同样级别的，对多个用户并发操作数据库的支持；故障恢复，系统应该提供和目前的数据库管理系统同样级别的，将数据库从故障后的错误状态恢复到某一正确状态的功能；以及即席查询功能，查询功能应该是非过程化的、高效的、独立于应用的。

面向对象的数据库系统除了必须具备上述面向对象特性和数据库管理系统基本功能外，最好还能具备新应用领域所需要的一些进一步的特性，例如模式演化、版本管理、长事务和嵌套事务、分布式计算等。

面向对象数据库系统的优越性。面向对象数据库系统将面向对象的能力赋予了数据库设计人员和数据库系统的应用开发人员，从而可以大大扩展数据库系统的应用领域，并且提高开发人员的工作效率和应用系统的质量。

复杂对象构造能力使得对于客观世界的模拟能力强、方式自然。

关系数据库系统强迫用户多个关系的元组来表示层次数据、嵌套数据或复合数据。例如，职工有职工号、姓名、性别、工资、部门等属性，而部门又有部门号、部门名、部门性质、部门经理等属性。关系数据库中属性的取值只能是基本数据类型，这样，职工元组中的部门属性取值只能是部门号。要查询某职工及其所在部门的信息就需要做“职工”和“部门”这两个关系的连接。这样的表示方式既不自然，又影响查询的速度。面向对象数据库中对象的属性的取值可以是另外一个对象，一个职工对象的部门属性的取值就可以是该部门对象，实际储存的是该对象的对象标识，这样的表示方式自然、易理解，而且在查询某职工及其所在部门的信息时可以通过该部门的对象标识直接找到那个部门，提高了查询的速度。

封装性向开发人员和最终用户屏蔽复杂性和实现细节，降低了数据库

应用系统开发和维护的难度。

对象封装将程序封装在一起作为存储和管理的单位，也是用户使用的单位，从外部只能看到它的接口，而看不到实现的细节，对象内部实现的修改不影响对对象的使用，因此使应用系统的开发和维护都变得更加容易。关系数据库系统现在支持存储的过程，即允许程序用某种过程性语言编写并存入数据库中以备以后装载和执行。但是，存储的过程并不和数据封装在一起，即它们不和任何关系或关系的元组相关联，构成一个整体，其信息隐蔽和易维护性显然不如 OODB 中封装起来的对象。

继承性使得数据库设计和应用编程成为可重用的。

在面向对象的数据库系统中，类的定义和类库的层次结构体现了系统分析和数据库设计的结果，即体现了客观世界中对象的内部结构及对象之间的联系。同时，类定义中封装的方法保存了数据库应用编程的结果。应用开发人员可以在已建立的类库的基础上派生出新的类，继承已存在的类的属性和方法。例如定义“销售人员”类作为已存的“职工”的职工号、姓名、性别等属性，重用了数据库设计的结果，还可以继承“职工”的计算工资额、显示奖惩记录等方法，重用了应用编程的结果，数据库设计和应用编程的重用对于建立大型复杂的数据库应用系统具有重要意义。

RDB 与 OODB。传统关系数据库中管理的是一张张的二维表，表中每一项是一个元组（记录），而面向对象数据库中管理的是对象的集合，也可以看成是一张张的二维表，但表中每一项是一个对象。

关系数据库中表达现实世界的实体及其联系都是用表，而面向对象数据库中表达现实世界的对象用表，而联系用直接引用机制，这种直接引用机制是通过对象标识符加上（复杂对象）索引机制来实现的，这导致了面向对象数据库与关系数据库相比有很大不同。

用关系数据库表示非传统应用（例如 CAD、CASE、OIS 等）领域中的复杂实体就很不方便而且效率太低，因为元组之间的联系必须通过 JOIN 运算运态地建立，要访问一个复杂对象需经历大量的 JOIN 运算，造成系统效率严重下降，所以再用关系数据库就不行了。而面向对象数据库采用了直接引用机制，所以在存取一个复杂对象时避免了大量的 JOIN 运算。此外，关系数据库的传统应用是短事务应用，即每个事务的执行时间都非常短，所以可以采用封锁机制来实现并发访问。

非传统应用有长期性和合作性的特点，例如；一个设计事务可能要延续很长时间，而且可能两个人在设计同一个子系统，其中只要有一个人的设计事务正确提交就算整个事务正常完成（提交）。在这种情况下，关系数据库中并发控制的封锁策略就不再适用了，因为一个事务若长期封锁一部分对象将导致别的事务长期等待，这是不允许的。

此外，事务的原子性（事务不能嵌套）也不再适用了，因为非传统应用在很多场合下都可以表现成嵌套事务的执行。从设计方法学的角度看，人们已经普遍认识到面向对象的方法学优于过去常用的所谓“自顶向下、逐步求精”的基于功能分解的方法学，如果用户使用面向对象的方怯进行系统的分析与设计，而我们还只能为他们提供关系数据库，则势必在设计与实现之间造成一个语义断层，导致方法应用的不连贯性和语义丢失问题。所以用面向对象的数据库来支持整个面向对象的方法学的应用是必然的要求。