在20世纪60年代后期引入的面向对象技术引起了一场革命。到20世纪80年代后，面向对象的技术已经成为了行业的主流，其原因多种多样：面向对象不仅简化了界面的开发，而且也提供了一种更加灵活、简单数据处理方法，这种方法从根本上改变了应用程序的构建方法。不再像关系型数据库一样用死板的二维表格来表示数据，对象技术使用类对数据进行描述。一个对象是一个类的实例，就像一颗特定的橡树是橡树类的实例一样。
　　对象技术使用继承方案，使得类是按等级设计的。“橡树”类能够从更加普遍的类“树”继承数据结构和数据行为。
　　对象技术能够更好地描述我们所见的世界，面向对象的语言已经被证实在大多数编程领域更加通用。他们使得编程语言更加接近自然语言和多数软件开发领域的主流思想。面向对象是一个新的典范，它的影响将持久而深远。
　　面向对象的特性很快被添加到各种成熟的语言中，并因此成就了一些语言，如C++。新的面向对象的开发环境出现了，包括Visual Basic，Visual C++，PowerBuilder，Delphi，以及Caché。尽管面向对象的技术在高级开发环境下受到了广泛支持，它还是需要花一定的时间形成正规的课程。而且还需要花更长的时间来构建一个真正的基于对象的世界——我们目前还没有到达这样一个阶段。
　　万维网上对象技术的发展
　　随着万维网（World Wide Web）转变为交换各种信息的手段，面向对象的编程语言Java成为Web开发者的最爱。基于C++，Java能够用来创建可以在浏览器执行的小程序（Java applets）。
　　Sun为了促进Java的发展免费提供Java环境。在短短几年内，成百上万的Java环境被复制下载，Java渗透到世界的每一个角落。同时Java引发了更多的面向对象语言，如JavaScript，C＃以及Jscript。Internet的发展也培育了一些新的面向对象语言像Perl和PHP。现在的开发者使用面向对象的技术已经是理所当然的了。
　　对象的崛起
　　对象技术影响了软件开发的各个方面。对象建模已经占领了应用建模的市场，标准UML建模方法独占鳌头。
　　20世纪90年代，面向对象中间件产品的出现为面向对象的应用提供了安全交流服务。当1998年JMS（Java Messaging Serivce）的出现，使得中间件市场向前跨越了一大步。JMS定义了一整套消息传递的应用编程接口（APIs），使得经认证的J2EE应用必须引入JMS服务器。这进一步强化了标准化进程，大大降低了中间件的费用，提供了编写企业范围基于对象的应用程序平台。
　　XML和Web服务
　　1998年，HTML，专门用于网页设计的标识语言，经过进一步发展并标准化，创造出了XML（扩展的标识语言）。XML提供了一整套语法，能够用于创建与存储在数据库中定义相似的自定义数据格式，可以。有了XML，程序能够把定义附加在数据上，能够交换数据和数据含义。XML能够使得有特定标准的数据模型（如发票或者购买订单）的定义能够在公司内部或者公司之间进行数据交换。XML引发了Web服务的兴起——在不需要客户定制的情况下，程序能够与其他程序立即交互。现在出现了两种Web服务环境——J2EE和。NET。像SQL一样，XML为程序员提供了获取数据的标准，但XML同时还提供了一种在对象层定义数据的标准语言。XML和对象技术一样迅速成长。结果，数据对象的新标准和基于XML的新的开发产品出现了。
　　对象数据库——缺失的一环
　　与软件开发各个环节中对象技术的快速应用形成鲜明对比，对象数据库直到现在才开始逐渐被人们所接受。对象数据的迟缓行动原因有很多。
　　早期的对象语言没有考虑数据存储。程序在内存数据上工作，数据作为文件存储，当程序下次运行时数据也作为文件被读取。这种方法使得应用程序之间不可能共享数据，数据的恢复、管理、扩展几乎不可能。
　　目前在市场上已经有大量的面向对象数据库产品：Versant，Objectivity，ObjectStore，GemStone等等。他们为面向对象的开发环境提供了相应的数据存储。这些产品满足了最初的热情，甚至这些产品被期望能够打造一个新的数据库市场——甚至可能成为市场的领袖。
　　但不幸的是，这些对象数据库出现时，关系型数据库供应商已经积聚了巨大的动力，并占领了大量市场份额。在标准的SQL接口下，访问关系型数据库的面向对象程序很容易写。相反，多数早期的对象数据完全不提供SQL接口，不适合任何查询应用程序。结果，对象数据库在商业上没有建立坚实的基础。他们在应用领域只创建了一个小市场来管理和存储复杂对象如CAD/CAM，电信业、多媒体、人工智能，模拟金融设备、病人诊治跟踪系统以及科学应用。
　　数据库市场从未特别关注过对象数据库，直到对象定义语言XML出现，这种情况才有所改变，促进了对象数据库的再次呈现，因为他们管理XML定义的数据是最合适的。使用XML，必然会提高存储复杂数据的需求，将进一步引发对象数据库的复苏。
　　03年9月份InfoWorld公布了一项开发员调查，其中有一个惊奇的结果，89.2％的被调查者说他们使用关系型数据库，52％的被调查者说他们使用面向对象或者XML数据库。当问及有关存储数据的类型时，40.2％的人说他们存储持久的对象，58.9％的人说他们存储XML数据，89％的人说他们存储关系型数据。Baroudi Bloor相信对象数据库比我们想象的用的更加广泛，随着需求的激增，将进一步扩大市场份额。
　　InfoWorld的调查还显示了面向对象的语言是新应用开发的主流选择。我们相信这些统计数字反映了当今开发员面临的困境。他们需要与他们一直使用的面向对象语言有更好协调性的数据库，但他们有需要关系型数据库所提供的查询能力。
　　关系型数据库——另一半是如何存在的
　　只要有程序，就会有数据。IT行业最早具有商业价值之一的就是数据管理。自动的数据管理意味着业务能够扩展、具有竞争力，没有它就不可能。所以毫无疑问机智的商业技术员很早把目光聚集在数据管理市场。在对象数据库产生之前的20年，E.F Codd博士提出的关系型理论找到了出路，开发出商业的关系型数据库产品。在80年中期，在IT领域有一个宗教式的信仰，认为数据的所有理论问题都已经解决，实践的问题也会随之解决。然而，很明显，事实并不是这样。
　　关系型数据库把数据存储在简单的两维表中，这是一种表达大量数据的有效方法，而且程序员也易于理解。关系型数据库使用SQL建立了一种标准的数据访问语言。关系型数据库有一个逻辑和物理形式清楚的结构，这种结构使得应用程序对数据结构是透明的，而且在很多商业应用程序中工作的很好。
　　然而，关系理论的基础之一是数据和使用数据的程序能够而且应该是相互独立的。这与对象技术的整个理念是不一致的。对象技术鼓励设计者使用对象而不是表来思考数据。对象和使用对象的方法是不可能彼此分开的。
　　如果把汽车作为一个复杂的对象来考虑。当你使用汽车时，你使用一辆完整的汽车，作为一个东西——一个对象来使用。与汽车相联系的有很多动作（也就是面向对象术语中的方法）。你驾驶汽车，进行换档，发信号，开车灯，等等。如果汽车是一个对象，这些动作就是对象的方法，他们对汽车而言是基础性的。这些动作独立于汽车的想法是荒唐的。当你把你的车停在车库，你把它作为一个东西来存储。而不是分别在车库中的某些地方存放方向盘，转换器，信号器，车灯。数据和它相对应的处理过程也不能而且也不应该被隔离开来。在对象数据库中他们是不分开的。
　　事实上，这两种观点各有优缺点。有些处理过程确实是独立于数据的。尤其是访问大量数据的查询操作。简单的查询就是根据一些标准来选取数据，而不关心数据是什么，也不用关心数据是如何被组织的，只要它能快速的被取出就可以了。查询是独立于数据的，但对象方法则不是。
　　关系型数据库的局限性
　　关系型数据库有比我们想的更多的局限性。存储和表示一些相当普通的数据结构也是非常困难的。试想一条公交线路——简单，有序的一组站点。关系型数据库以无序的方式存放表，只有创建一个特殊的索引，才能提取有序的数据。对象数据库就没有这个问题，它有有序的数组，不需要索引——这种索引是因为关系数据结构的局限性而要求创建的人工索引。
　　另一个简单的例子是产品用料单——在制造系统中记录一个产品和它的组件。组件自身也许还有组件，组件的组件还有组件，以此类推。一个关系型数据表不能表达这种部件与部件的部件之间的关系。而这些关系却是重要的数据。查询一个产品数据库，它的所有组件应该是一目了然的。关系型数据库结构使得开发员花费很多的工作来回答这种简单的查询，非常的复杂、困难。与这个例子类似的例子：地图和它的路、河、路标；网站和它的页面、链接以及图像。实际上，搜集的信息越复杂，等级层次和交叉层次就越多，在简单二维表的关系型数据库就越不可能表达清楚。对象数据库没有这样的限制，事实上，他们就是为了解决这个问题而设计的。
　　虽然关系型数据库发展成熟，在这十年中发展也非常迅猛，但我们还听到一些项目因为所使用的关系数据的性能不是很好而导致失败。通常，是因为关系型数据库物理上存储数据的方法导致的。对开发员而言，为了集合他们所需的数据，他们常常不得不进行这个表与另一个表联接，再与另外的表联接，然后再与另一个表联接。为了提取数据，数据库运行优化程序来判断提取数据的最好方法，然后再提取数据。这样的处理常常要花费很长的时间，结果就大大影响了性能。尽管关系型数据库优化器已经改善了运行时间，但他们还需要比对象数据库更多的处理时间。
　　关系型数据库和“阻抗不匹配”障碍
　　关系型数据的一个问题是他们所使用的基本数据结构是一种二维形式的表。在关系理论中，数据应该被组织成规范的表——也就是数据应该按唯一的方式组织，使得程序员能够消除冗余，确保数据变化的一致性。这种设计技术的引入确保了关系表中的数据是一组独立的、通过键相关的数据。这种技术来自集合论的数学理论，但问题是集合论不能表达数据之间所有的关系和结构。
　　以规范的方式存储数据常常要求程序员在存入数据库之前分解对象，并且重新组织数据，但要使用它是，在使用SQL查询（多重连接）。就像在车库中存储车时，你把它的门、椅子、轮子等等分别卸下来存放。这是非常耗时的，而是也是没有任何意义的。
　　但面向对象的语言占主导地位时，问题就越发明显了。这个问题通常被称为对象－关系不匹配障碍。这个问题是由于面向对象语言和关系型数据库使用语言的方法不同导致的，结果这个问题只能有程序员自己来解决。事实上，大多数关系型数据库在使用的时候并不是完全规范的，但即使是这样，不匹配问题还是发生，对编程人员的工作造成了很大的困难。我们可以估计使用关系型数据库的面向对象开发员25％到40％的时间用于编写代码来解决对象与关系表的匹配问题。
　　也许这个根本性困难产生了对对象数据的强烈需求，但多数对象数据库也有一个很大的问题：他们对SQL的支持很少。而许多软件工具需要SQL接口，尤其是商业智能应用。甚至有SQL接口的对象数据库也不能创建用于管理商业智能应用所产生的这类查询机制。
　　对象－关系数据库
　　关系型数据库的供应商并没有忽视对象的出现。显然，规范复杂数据是没有意义的。举个极端的例子，如果你要规范一个位图形式的图像——是一系列的象素表示的——你最终要得出一个表，这个表的行是象素，并且主键的属性反映他们的顺序。很明显最好是把这个数据作为一个对象来存储。
　　他们提出了“对象－关系”数据库的创意，这个创意中保留了关系型数据库的结构，但允许关系表中的列含有一个复杂的对象。这些对象能够捆绑处理复杂数据的处理过程（一种存储过程）。并且SQL能够允许调用与关系型等同的“对象方法”。
　　这种方法是对数据关系理论的一种嘲弄，事实上，它完全忽略了这个理论，但又允许复杂数据（地图，矢量图，图表，甚至整个表格）被定义为一个项目存放在关系结构中。因此，这些功能被实现并商品化。Informix称它的嵌入过程为DateBlades，Oracle称之为Cartridges。
　　对象－关系数据库成为存储数据时对象数据库的一种替代方案，但根本的问题它并没有解决。对象－关系数据库还是受不匹配障碍的困扰。
　　对象数据库与关系型数据库
　　实践中，对象数据库相对于关系数据库有显着的优势。
　　◆他们能更快的运行事务处理程序
　　◆他们能够更有效的处理对象
　　◆他们能够提供更好的开发效率
　　◆他们能够管理更容易
　　在一些例子中，因为是性能方面的原因，用对象数据库能够替代关系型数据库。在不能存储复杂对象的大规模的业务处理程序中确实是这样的——也许有些人会认为这个必然是关系型数据库的领地。
　　对象数据库最大的性能优势是他们不必像关系型数据库一样在数据使用之前先连接数据。他们就以使用数据的方式存储数据，这就大大提高了性能。对象数据库能够使用缓存技术，这样就使得在请求数据时数据就已经存放在内存中了。对象数据库在抽取数据时几乎不需要进行优化。
　　但开发一个新的系统，处理复杂数据如文档、复杂图表、网页、多媒体等的需求不断增长时，这些需求对象数据库可以很好的满足。
　　当今面向对象的前景
　　在软件开发的各个方面使用对象技术的人群都在不停地增长。甚至在最后一个领域——数据库——尽管对象数据库还没有取代关系型数据库，这种增长也是十分显着的。InfoWorld报告说52%的开发员在使用对象数据库或者XML数据库（通常也是一种对象数据库）。还有一些选择混合形式的数据库，这种数据库能比较容易地使用对象结构。随着新应用程序开发过程中Web接口成为一个必不可少地部分，Web服务成为应用系统交互地一种可行的机制，构建一个面向对象的世界似乎是当今的现实。
　　03年9月的InfoWorld调查也显示了使用面向对象语言的程序员几乎无处不在。事实上，尽管有些人宣称使用C语言，但是面向对象的语言还是成为当今90％的程序员的选择。调查也显示了程序员比较喜欢基于Web的应用，易用的对象编程和脚本语言。随着越来越多的有着正规培训的软件工程师进入市场，面向对象技术将成为新应用开发的唯一选择。
　　结论
　　也许关系型数据库将继续领导数据库市场，而对象数据库在市场上只占有一席之地。也许对象数据库将进一步提升市场份额，因为他们能够处理当今使用的复杂的数据。然而，我们认为还有其他的可能：数据库技术可能发展出一种真正的混合型产品，这种产品能提供关系接口和对象接口双重优势。我们知道这是有可能的。事实上，至少有一种产品，来自InterSystems的Caché，就是这样一个产品。（Caché数据库，描述他自己时，既不是说是关系型的，也不是说是对象的，而是后关系型数据库）。数据库供应商——不管他们的产品是属于关系型还是对象型——都会朝着这个方向前进的。
　　这种混合产品的方法包括给数据库提供一个映射层，程序员通过映射层访问数据库。映射层应该基于开发的标准以解决不匹配障碍问题。数据库的调用能够用SQL完成，也可以直接请求对象类或者类的集合。映射层能够把这些调用转换为对数据库的物理数据请求以抽取数据。这种方法将消除不匹配的障碍。
　　改变任何一种数据类型都是非常大的挑战。对象数据库需要快速索引能力，以从庞大的数据集中抽取数据。在这方面做得比较好的关系型数据库使用位图索引技术，但数据一旦更新，这些索引就需要重新建立。因为这个原因，很少有对象数据有这个功能。对关系数据库而言，他们需要提供更加灵活的物理数据结构。在发展过程中，关系型数据库倾向于在物理层使用表。他们需要放弃这种不灵活的限制，允许存储多种数据结构。数据库使用者将获得最大的收益。试想把对象数据库的优势和关系型数据库的优势整合在一起：
　　◆好的处理性能
　　◆复杂数据管理
　　◆管理简便
　　◆快速开发
　　◆灵活的查询功能
　　◆标准的数据访问接口
　　◆更好地适用于商业智能应用
　　这种混合产品使使用一个数据库引擎成为可能，并且所有应用只有一个数据定义集。Baroudi Bloor相信企业界需要混合式的数据库产品。供应商们必须放弃他们对关系数据库宗教式的倾向，转向更具优势的混合式的数据库，否则的话他们将陷于COBOL以及打孔卡片的深渊而不能自拨。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。