综述
面向对象数据库系统（Object Oriented Data Base System，简称OODBS）是数据库技术与面向对象程序设计方法相结合的产物。
对于OO数据模型和面向对象数据库系统的研究主要体现在：研究以关系数据库和SQL为基础的扩展关系模型；以面向对象的程序设计语言为基础，研究持久的程序设计语言，支持OO模型；建立新的面向对象数据库系统，支持OO数据模型。
面向对象程序设计方法是一种支持模块化设计和软件重用的实际可行的编程方法。它把程序设计的主要活动集中在建立对象和对象之间的联系（或通信）上，从而完成所需要的计算。一个面向对象的程序就是相互联系（或通信）的对象集合。面向对象程序设计的基本思想是封装和可扩展性。
面向对象数据库系统支持面向对象数据模型（以下简称OO模型）。即面向对象数据库系统是一个持久的、可共享的对象库的存储和管理者；而一个对象库是由一个OO模型所定义的对象的集合体。
一个OO模型是用面向对象观点来描述现实世界实体（对象）的逻辑组织、对象间限制、联系等的模型。一系列面向对象核心概念构成了OO模型的基础。概括起来，OO模型的核心概念有如下一些:
（1）对象（Object）与对象标识OID（Object IDentifier）
现实世界的任一实体都被统一地模型化为一个对象，每个对象有一个唯一的标识，称为对象标识（OID）。
（2）封装（Encapsulation）
每一个对象是其状态与行为的封装，其中状态是该对象一系列属性（Attribute）值的集合，而行为是在对象状态上操作的集合，操作也称为方法（Method）。
（3）类（C1ass）
共享同样属性和方法集的所有对象构成了一个对象类（简称类），一个对象是某一类的一个实例（instance）。
（4）类层次（结构）
在一个面向对象数据库模式中，可以定义一个类（如C1）的子类（如C2），类Cl称为类C2的超类（或父类）。子类（如C2）还可以再定义子类（如C3）。这样，面向对象数据库模式的一组类形成一个有限的层次结构，称为类层次。
（5）消息（Message）
由于对象是封装的，对象与外部的通信一般只能通过显式的消息传递，即消息从外部传送给对象，存取和调用对象中的属性和方法，在内部执行所要求的操作，操作的结果仍以消息的形式返回。
OODB语言用于描述面向对象数据库模式，说明并操纵类定义与对象实例。OODB语言主要包括对象定义语言（ODL）和对象操纵语言（OML），对象操纵语言中一个重要子集是对象查询语言（OQL）。OODB语言一般应具备下述功能：
（1）类的定义与操纵
面向对象数据库语言可以操纵类，包括定义、生成、存取、修改与撤销类。其中类的定义包括定义类的属性、操作特征、继承性与约束等。
（2）操作/方法的定义
面向对象数据库语言可用于对象操作/方法的定义与实现。在操作实现中，语言的命令可用于操作对象的局部数据结构。对象模型中的封装性允许操作/方法由不同程序设计语言来实现，并且隐藏不同程序设计语言实现的事实。
（3）对象的操纵
面向对象数据库语言可以用于操纵（即生成、存取。修改与删除）实例对象。
目前，还没有像SQL那样的关于面向对象数据库语言的标准，因此不同的OODBMS其具体的数据库语言各不相同。
对象-关系数据库系统就是将关系数据库系统与面向对象数据库系统两方面的特征相结合。 对象-关系数据库系统除了具有原来关系数据库的各种特点外，还应该提供以下特点：
（1）扩充数据类型，例如可以定义数组、向量、矩阵、集合等数据类型以及这些数据类型上的操作。
（2）支持复杂对象，即由多种基本数据类型或用户自定义的数据类型构成的对象。
（3）支持继承的概念
（4）提供通用的规则系统，大大增强对象-关系数据库的功能，使之具有主动数据库和知识库的特性。
对象数据库 VS 关系数据库
我们将对象数据库管理系统（ODBMS）定义为一个集成了数据库能力与面向对象编程语言能力的数据库管理系统（DBMS），ODBMS使数据库对象看起来像是已有的一个或多个程序设计语言中的程序设计语言以象。——Rick Cattell，OMG-93委员会主席。
ODBMS在多用户客户机/服务器环境中提供了持久性存储器。ODBMS可以处理对象的并行访问，提供锁定和事务保护，保护对象存储器免遭各种类型的威胁，照管像备份和恢复之类传统任务。ODBMS这所以与关系数据库不同，是因为ODBMS存储的是对象，而不是表格。对象的引用通过持久性标识（PID）进行，PID可以独一无二地识别各个对象，可以用来在对象之间建立标记和容器关系。ODBMS还加强了封装，支持继承。ODBMS结合了对象属性和传统的DBMS功能，如锁定、保护、事务处理、查询、版式本、并发和持久性。
ODBMS不是利用分离的语言（如SQL）定义、检索和处理数据，而是利用类定义和传统的面向对象的程序语言（通常是C++、SmallTalk和Java语言）构造来定义和访问数据。ODBMS只来过是存储器内语言数据结构的多用户、持久性扩展。换句话说，客户就是C++或是Java程序，服务器就是ODBMS-——没有像SQL和RPC这样的可视中间对象。ODBMS将数据库能力直接集成进语言。
ODBMS的价值。很显然，最好是以自然的形式存储那些对象，而不是将数据修饰得光光滑滑或撕得七零八落之后放进关系表格中。
对于那些数据复杂难以在表格里简单排列的用户来说，ODBMS特别适合。ODBMS曾经长期是学者和OO研究人员极为感兴趣的领域。最早的商品化ODBMS出现在1986年，是Servio公司（现在的GemStone公司）和Ontos公司推出的。后来（九十年代）Object Design（ODI）、Versant、Objectivity、O2 Technology、Poet、Ibex、UniSQL和ADB MATISSE等公司也加入了这个开拓行列。这些ODBMS厂商首先瞄准了那些复杂数据结构和长命期事务处理的应用程序——包括计算机辅助设计、CASE和智能办公室等。随着多媒体、群件、公布式对象和万维网技术的出现，ODBMS与那些深奥难懂的特性现在变成了客户机/服务器系统的主流要求。ODBMS技术填补关系数据库最弱的那些空隙——复杂数据、版式本和长生命期事务、持久性对象存储、继承和用户定义的数据类型等等。
以下是ODBMS厂商开拓的各个特性：
●自由创建新的信息类型
●快速存取
●组合结构的灵活视图
●与面向对象的程序语言紧密集成
●利用多继承支持可定制的信息结构
●支持版本事务、嵌套事务和长生命期事务
●分布式对象储库
●支持复合对象的生命期管理
对象狂已经掌握了整个行业。面向对象技术支持者正在宣告，对象关系数据库和ODBMS将成为医治关系技术的所谓弱点的良药。这纯属胡说……在数据库上直接地和不加区分地就应用面向对象技术，将再次引入关系数据库花了二十年才克服的那些问题。
在用户中间，很少有人会怀疑ODBMS最终将成为RDBMS的后继技术。在诗人William Blake的比喻中，年轻的革命上帝Orc已经开始衰老，变成冷冰冰的暴君Urizen——戒律和标准的守护人。
我们可以两者兼得。要点是将这两项技术结合起来，而不是相互扔泥块。对二十多处踏踏实实的关系数据库研究的开发熟视无睹，不加以利用，就不太应该了。
Date和Pascal都承认目前的SQL数据库实现有缺点；但他们两人都有觉得关系模型本身能够处理ODBMS将解决的那些问题，ODBMS有能力，可以利用嵌套关系、域（或用户定义的数据封装类型）以及一种比SQL更强大的面向集合语言在关系技术世界里近似。这些特性完成这项工作，无需追逐对象指针或操纵低级的专用语言记录结构。没有必要减轻关系理论的联合能力。开发者没有必要退回到用手工方法去最佳化或重新优化应用程序的性能——将时钟倒拔回去了。Date认为域和对象是同一回事，解决办法是由关系技术厂商扩展其系统，以包括“适当的域支持”。
StoneBraker注意到纯粹的ODBMS还缺乏复杂搜索、查询优化器和服务器可扩展性等领域的功能。而且，许多ODBMS在用户编程的同一个地址空间里运行其产品。这意味着在客户应用程序和ODBMS之间没有任何屏蔽。此外，与关系DBMS相比，ODBMS的市场突破还极小。最后，对象/关系和SQL数据类型扩展器正在RDBMS语言政治协商环境内满足某些对象要求。
支持ODBMS的人们觉得，除了仅仅扩展关系模型之外，还有更多的方法。事实上，他们已经拒绝了SQL3，理由是不足（正在达成休战协定）。ODBMS顽固分子认为他们正在为一个新创世界创造更好的管道系统，在这个世界里信息系统完全建产在对象基础之上。在一个由ORB、对象服务、面向对象的程序设计语言和Object Web组成的管道里，关系数据库成了阻碍。所需要的正是一个纯粹的ODBMS。为什么要坚持用BLOB、存储过程和用户定义类型来扩展一个像SQL这样的旧基础呢？他们宁愿自始至终坚持用对象技术，有时从SQL借来某些东西（比如查询）。他们还在创建一个多用户、坚实的基础、包括锁定、事物处理、恢复和各种工具。
当然我们这里谈论的是David和Goliath。SQL数据库是目前的山中之王，它们拥有巨额的开发经费，在从MIS商店到客户机/服务器低端市场里有着极好的市场接受度。是不是因为ODBMS能与更好地处理对象，这个山中之王就会被黜？这还有待进一步地观察。不过，正如Esther Dyson表达的，“利用表格存储对象，就象是将汽车开回家，然后拆成零碎件放进车库里，早晨可以再把汽车装配起来。但是人们不禁要问：这是不是泊车的最有效的方法呢”
网友评论