对象 数据库 VS 关系数据库 我们将对象数据库管理系统( ODBMS )定义为一个集成了数据库能力与 面向对象 编程语言能力的数据库管理系统( DBMS ), OD" name="description" />

对象数据库VS关系数据库

发表于:2007-05-25来源:作者:点击数: 标签:
MI LY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">对象 数据库 VS 关系数据库 我们将对象数据库管理系统( ODBMS )定义为一个集成了数据库能力与 面向对象 编程语言能力的数据库管理系统( DBMS ), OD

MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">对象数据库 VS 关系数据库

我们将对象数据库管理系统(ODBMS)定义为一个集成了数据库能力与面向对象编程语言能力的数据库管理系统(DBMS),ODBMS使数据库对象看起来像是已有的一个或多个程序设计语言中的程序设计语言以象。——Rick CattellOMG-93委员会主席。

ODBMS在多用户客户机/服务器环境中提供了持久性存储器。ODBMS可以处理对象的并行访问,提供锁定和事务保护,保护对象存储器免遭各种类型的威胁,照管像备份和恢复之类传统任务。ODBMS这所以与关系数据库不同,是因为ODBMS存储的是对象,而不是表格。对象的引用通过持久性标识(PID)进行,PID可以独一无二地识别各个对象,可以用来在对象之间建立标记和容器关系。ODBMS还加强了封装,支持继承。ODBMS结合了对象属性和传统的DBMS功能,如锁定、保护、事务处理、查询、版式本、并发和持久性。

ODBMS不是利用分离的语言(如SQL)定义、检索和处理数据,而是利用类定义和传统的面向对象的程序语言(通常是C++SmallTalkJava语言)构造来定义和访问数据。ODBMS只来过是存储器内语言数据结构的多用户、持久性扩展。换句话说,客户就是C++或是Java程序,服务器就是ODBMS­——没有像SQLRPC这样的可视中间对象。ODBMS将数据库能力直接集成进语言。

ODBMS的价值。很显然,最好是以自然的形式存储那些对象,而不是将数据修饰得光光滑滑或撕得七零八落之后放进关系表格中。

对于那些数据复杂难以在表格里简单排列的用户来说,ODBMS特别适合。ODBMS曾经长期是学者和OO研究人员极为感兴趣的领域。最早的商品化ODBMS出现在1986年,是Servio公司(现在的GemStone公司)和Ontos公司推出的。后来(九十年代)Object DesignODI)、VersantObjectivityO2 TechnologyPoetIbexUniSQLADB MATISSE等公司也加入了这个开拓行列。这些ODBMS厂商首先瞄准了那些复杂数据结构和长命期事务处理的应用程序——包括计算机辅助设计、CASE和智能办公室等。随着多媒体、群件、公布式对象和万维网技术的出现,ODBMS与那些深奥难懂的特性现在变成了客户机/服务器系统的主流要求。ODBMS技术填补关系数据库最弱的那些空隙——复杂数据、版式本和长生命期事务、持久性对象存储、继承和用户定义的数据类型等等。

以下是ODBMS厂商开拓的各个特性:

n        自由创建新的信息类型

n        快速存取

n        组合结构的灵活视图

n        与面向对象的程序语言紧密集成

n        利用多继承支持可定制的信息结构

n        支持版本事务、嵌套事务和长生命期事务

n        分布式对象储库

n        支持复合对象的生命期管理

对象狂已经掌握了整个行业。面向对象技术支持者正在宣告,对象关系数据库和ODBMS将成为医治关系技术的所谓弱点的良药。这纯属胡说……在数据库上直接地和不加区分地就应用面向对象技术,将再次引入关系数据库花了二十年才克服的那些问题。

在用户中间,很少有人会怀疑ODBMS最终将成为RDBMS的后继技术。在诗人William Blake的比喻中,年轻的革命上帝Orc已经开始衰老,变成冷冰冰的暴君Urizen——戒律和标准的守护人。

我们可以两者兼得。要点是将这两项技术结合起来,而不是相互扔泥块。对二十多处踏踏实实的关系数据库研究的开发熟视无睹,不加以利用,就不太应该了。

DatePascal都承认目前的SQL数据库实现有缺点;但他们两人都有觉得关系模型本身能够处理ODBMS将解决的那些问题,ODBMS有能力,可以利用嵌套关系、域(或用户定义的数据封装类型)以及一种比SQL更强大的面向集合语言在关系技术世界里近似。这些特性完成这项工作,无需追逐对象指针或操纵低级的专用语言记录结构。没有必要减轻关系理论的联合能力。开发者没有必要退回到用手工方法去最佳化或重新优化应用程序的性能——将时钟倒拔回去了。Date认为域和对象是同一回事,解决办法是由关系技术厂商扩展其系统,以包括“适当的域支持”。

StoneBraker注意到纯粹的ODBMS还缺乏复杂搜索、查询优化器和服务器可扩展性等领域的功能。而且,许多ODBMS在用户编程的同一个地址空间里运行其产品。这意味着在客户应用程序和ODBMS之间没有任何屏蔽。此外,与关系DBMS相比,ODBMS的市场突破还极小。最后,对象/关系和SQL数据类型扩展器正在RDBMS语言政治协商环境内满足某些对象要求。

支持ODBMS的人们觉得,除了仅仅扩展关系模型之外,还有更多的方法。事实上,他们已经拒绝了SQL3,理由是不足(正在达成休战协定)。ODBMS顽固分子认为他们正在为一个新创世界创造更好的管道系统,在这个世界里信息系统完全建产在对象基础之上。在一个由ORB、对象服务、面向对象的程序设计语言和Object Web组成的管道里,关系数据库成了阻碍。所需要的正是一个纯粹的ODBMS。为什么要坚持用BLOB、存储过程和用户定义类型来扩展一个像SQL这样的旧基础呢?他们宁愿自始至终坚持用对象技术,有时从SQL借来某些东西(比如查询)。他们还在创建一个多用户、坚实的基础、包括锁定、事物处理、恢复和各种工具。

当然我们这里谈论的是DavidGoliathSQL数据库是目前的山中之王,它们拥有巨额的开发经费,在从MIS商店到客户机/服务器低端市场里有着极好的市场接受度。是不是因为ODBMS能与更好地处理对象,这个山中之王就会被黜?这还有待进一步地观察。不过,正如Esther Dyson表达的,“利用表格存储对象,就象是将汽车开回家,然后拆成零碎件放进车库里,早晨可以再把汽车装配起来。但是人们不禁要问:这是不是泊车的最有效的方法呢”

原文转自:http://www.ltesting.net