大家可以看到,在这里,操作包括两个读过程,一个计算过程和一个写过程,而没有查询过程,这与前面提到的正文编辑是非常相似的。所不同的就是这一应用中的数据是相当复杂的。 本例代表了大多数复杂数据,简单查询的应用的特性。对于这类应用,符合SQL标准的关系数据库显然是不适用的,而使用传统的文件系统又将带来很大的麻烦,需要人工地读入雇员和楼层的信息,将数据从磁盘格式转换为内存格式;邻接信息在磁盘上可能是一个雇员的唯一标识,在装入信息时需要转换成虚指针,而这些虚指针是依赖于装入位置的,在以后的执行中不能重用;在将计算结果写出时,还要进行同样复杂的转换。在这种操作上浪费程序员的时间和精力是不值得的,最好能够有一种语言支持复杂对象的持久存储。 本类应用与前两类应用最主要的不同在于增加了复杂数据,而与第二类应用相比,它又几乎没有查询要求,从面向对象语言上发展起来的面向对象数据库系统(OODB)是这类应用的最佳选择。使用了持久变量,对象的装入和转换过程就可以完全交给语言支持系统去解决,应用程序代码也就可以大大简化了。由于复杂数据的持久存储,必然会引起速度的下降,性能的降低,这类语言的设计者为了保持运行速度,常常不得不放弃安全性方面的考虑。 目前,市场上已经推出了Gemstone、Objectivity、 Objectstore等若干个OODBS产品,满足这一类应用的要求。然而,这些产品在坚固性,可伸缩性,客户/服务器结构,应用开发工具等许多方面不如RDBMS产品。目前的应用领域也比较局限。
4.复杂数据,复杂查询———对象—关系数据库系统
随着计算机工业的发展和数据库技术的普及,数据库技术被越来越多的领域所关注和采用,一些以前认为不必或不适合于用数据库技术实现的领域纷纷探讨采用数据库技术的问题。于是,存储简单数据,在其上进行复杂查询的关系数据库系统,以及存储复杂数据,而不易进行查询的面向对象数据库系统,都不再能够满足应用的进一步的需要。
下面就是一个典型的例子。 加州水资源管理局(DWR)需要对全州的各种水道进行管理。该局的资料库中保存了50万张幻灯片,每天需要对它们进行多次存取查询操作,一般是按照内容进行查询的。例如:查找日落时的旧金山湾的幻灯片;查找低水位时的圣巴巴拉水库的幻灯片;查找美洲河岸边一种濒危水禽的幻灯片,等等。按照内容对幻灯片进行查找是很困难的。解决方案之一是按照预先定义的概念集建立索引,但是这样做价格昂贵,而且,客户所关心的概念随时间不断发生变化,新的关心焦点可能根本就不在建立索引所依据的概念集中,也就无从查找了。另一个解决方案是按照关键词对幻灯片的标题进行查找,但是实践证明此方法并不有效,因为许多感兴趣的概念并不出现在标题中。
于是,DWR计划将全部的幻灯片扫描成数据形式,建立数据库系统加以管理。在这里,就需要数据库系统能够支持对幻灯片的分类,支持对图像数据的存储和理解,支持客户的即席查询等功能。 首先就是对查询语言提出了更高的要求,至少需要允许用户自定义数据类型,并自定义这些数据类型上的函数和操作。第一个具有这样的能力的SQL标准是正在制定中的SQL3标准。
由于输入和输出都有可能是用户自定义的数据结构的数据(例如地图,坐标,图像等),因此在客户工具方面,原有的支持关系数据库系统的工具在新的应用面前也显得有些无能为力了。这样的应用,强烈要求可视化系统与数据库管理系统集成在一起,为用户提供"pan andzoom"的界面。 对于上例中的查询,例如找日落时旧金山湾的幻灯片,在性能方面也有所要求。在这样的环境中,要提高系统的运行效率,需要各种优化策略。
最新相关文章
发表评论