文档文库
手机版
投诉建议
热门搜索： 心得体会 演讲稿 思想汇报
首页 > 面向对象数据库在本体存储中的应用研究

面向对象数据库在本体存储中的应用研究

发布时间：   来源：文档文库   
小 中 大
字号：
手机查看
武汉理工大学硕士学位论文
面向对象数据库在本体存储中的应用研究
姓名：李常友申请学位级别：硕士专业：通信与信息系统指导教师：龙毅宏
20100501

武汉理工大学硕士学位论文
摘要
随着语义网络中本体资源的增加，本体的规模越来越大，结构越来越复杂。此时，本体查询和管理的效率成为人们普遍关注的问题。而本体存储方式直接影响着本体的查询效率，因此，如何合理地存储大规模的本体，从而提高本体的查询和搜索效率是一件很有意义且具有挑战性的任务。
近些年来，国内关于本体存储方面的研究都在不断发展，然而许多研究都只局限于基于关系数据库上的，只是在现有的存储方式上加以改良，在本体查询效率上并没有显著的提高。
为进一步提高本体的查询效率，本文在基于面向对象数据库的本体存储方式上进行了探索，并使用优秀的开源对象数据库ｄｂ４０和本体开发工具包Ｊｅｎａ设计并实现了该存储方式。面向对象数据库中数据直接以对象方式存储，可避免将本体拆分为三元组，很好地解决了阻抗失配的问题。更重要的是在面向对象数据库中查询本体数据不需要再用像ＳＱＬ这样的中间语言和像ＪＤＢＣ这样的中间接口，因此用对象数据库来存储本体不仅更直观，而且查询效率与关系数据库相比也大大提高了。全文的主要研究成果如下：
（１）对基于面向对象数据库存储本体的可行性进行了理论分析。首先对本体模型和对象数据库模型相似性进行了分析，讨论了如何用对象数据库对数据的操纵和管理能力来存取本体，从而论证了基于对象数据库存储本体，可大大提高本体查询效率。
（２）选取对象数据库曲４０和ｊｅｌｌａ作为工具，设计并实现了一种专门的存储方式。本文选用Ｊｅｎａ工具包来创建和填充本体模型，并通过对其内部接口的修改将本体数据持久存储到对象数据库中。系统结构分三层设计，把本体持久化到对象数据库的过程进行了封装，对外提供直接操纵本体对象的接口，使在对象数据库中对本体的操作与在内存中对本体数据的操作几乎一样。
（３）对系统的性能及本体存储和查询效率进行了详细的测试分析。本文对此存储方案进行性能分析，对不同情况下本体的存储和查询效率进行了详细测试，并与传统的关系数据库存储方式在效率上进行对比分析。关键词：本体存储，对象数据库，ｄｂ４０

武汉理工大学硕七学位论文
Ａｂｓｔｒａｃｔ
Ｗｉｔｈ
ｔｈｅｉｎｃｒｅａｓｉｎｇｏｆｏｎｔｏｌｏｇｙ
ｒｅｓｏｕｒｃｅｓ
ｉｎＳｅｍａｎｔｉｃ
Ｗｅｂ，ｔｈｅｂｏｄｙｓｉｚｅｏｆ
ｏｎｔｏｌｏｇｙｂｅｃｏｍｅｓｉｎｃｒｅａｓｉｎｇｌｙｌａｒｇｅａｎｄｔｈｅｓｔｒｕｃｔｕｒｅｂｅｃｏｍｅｓｍｏｒｅ
ｃｏｍｐｌｅｘ．Ａｔ
ｔｈｉｓｐｏｉｎｔ，ｔｈｅｑｕｅｒｙａｎｄｍａｎａｇｅｍｅｎｔｅｆｆｉｃｉｅｎｃｙｏｆｏｎｔｏｌｏｇｙｂｅｃｏｍｅｓ
ａ
ｗｉｄｅｓｐｒｅａｄ
ｃｏｎｃｅｒｎ．Ａｎｄｔｈｅｓｔｏｒａｇｅｏｆｏｎｔｏｌｏｇｙｄｉｒｅｃｔｌｙａｆｆｅｃｔｓｔｈｅ
ｅｆｆｉｃｉｅｎｃｙｏｆｏｎｔｏｌｏｇｙｑｕｅｒｙ．
Ｔｈｅｒｅｆｏｒｅ，ｈｏｗｔｏｒｅａｓｏｎａｂｌｙｓｔｏｒｅｌａｒｇｅｂｕｌｋｏｎｔｏｌｏｇｙａｎｄｉｍｐｒｏｖｅｔｈｅｅｆｆｉｃｉｅｎｃｙ
ｏｆ
ｏｎｔｏｌｏｇｙｑｕｅｒｙ
ａｎｄ
ｓｅａｒｃｈｉｓ
ａｎｉｎｔｅｒｅｓｔｉｎｇａｎｄ
ｃｈａｌｌｅｎｇｉｎｇｔａｓｋ．
Ｒｅｃｅｎｔｙｅａｒｓ，ｄｏｍｅｓｔｉｃｒｅｓｅａｒｃｈ
ｏｎ
ｔｈｅｏｎｔｏｌｏｇｙｓｔｏｒａｇｅｈａｓｂｅｅｎ
ｃｏｎｔｉｎｕａｌｌｙ
ｄｅｖｅｌｏｐｉｎｇ．Ｈｏｗｅｖｅｒ＇ｍａｎｙ
ｓｔｕｄｉｅｓａｒｅｌｉｍｉｔｅｄｂａｓｅｄ
ｏｎ
ｒｅｌａｔｉｏｎａｌｄａｔａｂａｓｅ，ｏｎｌｙｉｍｐｒｏｖｅｔｈｅｗａｙｏｆｅｘｉＳｔｉｎｇｓｔｏｒａｇｅ．Ｔｈｅｅｆｆｉｃｉｅｎｃｙ
ｏｆｏｎｔｏｌｏｇｙ
ｑｕｅｒｙｉｓｎ’ｔ
ｓｉｇｎｉｆｉｃａｎｔｌｙｉｍｐｒｏｖｅｄ．
Ｔｏｆｕｒｔｈｅｒ
ｉｍｐｒｏｖｅ
ｔｈｅ
ｅｆｆｉｃｉｅｎｃｙｏｆ
ｏｎｔｏｌｏｇｙｑｕｅｒｙ，ｔｈｉｓｄｉｓｓｅｒｔａｔｉｏｎｅｘｐｌｏｒｅｓ
ｔｈｅｏｎｔｏｌｏｇｙｓｔｏｒａｇｅ
ｂａｓｅｄ
ｏｎ
ｏｂｊｅｃｔ－ｏｒｉｅｎｔｅｄ
ｄａｔａｂａｓｅ，ａｎｄｗｅ
ｄｅｓｉｇｎａｎｄ
ｉｍｐｌｅｍｅｎｔｔｈｅｓｔｏｒａｇｅｍｏｄｅｕｓｉｎｇｅｘｃｅｌｌｅｎｔｏｐｅｎｓｏｕｒｃｅ
ｏｂｊｅｃｔｄａｔａｂａｓｅｄｂ４０ａｎｄ
ｏｎｔｏｌｏｇｙｄｅｖｅｌｏｐｍｅｎｔｋｉｔＪｅｎａ．Ｉｎ
Ｏｂｊｅｃｔ－ｏｒｉｅｎｔｅｄｄａｔａｂａｓｅ，ｔｈｅｄａｔａｓｔｏｒｅｄｄｉｒｅｃｔｌｙ
ｉｎｔｈｅｆｏｒｍｏｆ
ｏｂｊｅｃｔ，ｓｏ
ｇａｌｌ
ａｖｏｉｄｓｐｌｉｔｉｎｇｏｎｔｏｌｏｇｙｉｎｔｏｔｒｉｐｌｅｓ
ａｎｄ
ｓｏｌｖｅｔｈｅｉｍｐｅｄａｎｃｅ
ｍｉｓｍａｔｃｈ
ｐｒｏｂｌｅｍ．Ｍｏｒｅ
ｉｍｐｏｒｔａｎｔｌｙ，ｔｈｅ
ｏｎｔｏｌｏｇｙ
ｑｕｅｒｙ
ｉｎ
ｏｂｊｅｃｔ－ｏｒｉｅｎｔｅｄ
ｄａｔａｂａｓｅｄｏ
ｎｏｔｎｅｅｄＵＳｅ
ｔｈｅｉｎｔｅｒｍｅｄｉａｔｅｌａｎｇｕａｇｅｓｕｃｈａｓＳＱＬａｎｄ
ｉｎｔｅｒｍｅｄｉａｔｅｉｎｔｅｒｆａｃｅｓｓｕｃｈ
ａｓ
ＪＤＢＣ．Ｓｏｕｓｉｎｇ
ｏｂｊｅｃｔ
ｄａｔａｂａｓｅ
ｔｏｓｔｏｒｅｏｎｔｏｌｏｇｙｉｓ
ｎｏｔ
ｏｎｌｙｍｏｒｅｉｎｔｕｉｔｉｖｅ，ｂｕｔａｌｓｏｍｏｒｅｅｆｆｉｃｉｅｎｃｙ
Ｏｎ
ｑｕｅｒｙｃｏｍｐａｒｅｄｗｉｔｈｔｈｅ
ｒｅｌａｔｉｏｎａｌ
ｄａｔａｂａｓｅ．Ｔｈｅ
ｍａｉｎｒｅｓｅａｒｃｈｒｅｓｕｌｔｓｏｆｔｈｉｓｄｉｓｓｅｒｔａｔｉｏｎａｌｅａｓ
ｆｏｌｌｏｗｓ：
（１）Ｄｉｓｃｕｓｓｔｈｅｆｅａｓｉｂｉｌｉｔｙｏｆｏｎｔｏｌｏｇｙｓｔｏｒａｇｅ
ｂａｓｅｄｏｎｏｂｊｅｃｔ・ｏｒｉｅｎｔｅｄｄａｔａｂａｓｅ
ｔｈｅｏｒｙ．Ｆｉｒｓｔｗｅａｎａｌｙｚｅｔｈｅｓｉｍｉｌａｒｉｔｙｂｅｔｗｅｅｎ
ｏｂｊｅｃｔｄａｔａｂａｓｅ
ｍｏｄｅｌａｎｄ
ｍｏｄｅｌ，ａｎｄｄｉｓｃｕｓｓｅ
ｈｏｗｔｏ
ｕｓｅ
ｔｈｅｄａｔａ
ｍａｎｉｐｕｌａｔｉｏｎａｎｄ
ｍａｎａｇｅｍｅｎｔ
ｏｆｏｂｊｅｃｔ
ｄａｔａｂａｓｅｔｏ
ａｃｃｅｓｓｔｈｅｏｎｔｏｌｏｇｙ．Ｔｈｉｓ
ｗｏｒｋｄｅｍｏｎｓｔｒａｔｅｓｔｈｅ
ｄａｔａｂａｓｅ啪ｇｒｅａｔｌｙｉｍｐｒｏｖｅｔｈｅｅｆｆｉｄｅｎｃｙｏｆｏｎｔｏｌｏｇｙｑｕｅｒｙ．
（２）Ｄｅｓｉｇｎ
ａｎｄ
ｉｍｐｌｅｍｅｎｔ
ａ
ｓｐｅｃｉａｌｉｚｅｄｓｔｏｒａｇｅｕｓｉｎｇ
ｏｂｊｅｃｔｄａｔａｂａｓｅ
ｄｂ４０
ａｎｄ
ｕｓｅ
Ｊｅｎａｔｏｏｌｋｉｔｔｏｃｒｅａｔｅ
ａｎｄｐｏｐｕｌａｔｅ
ｏｎｔｏｌｏｇｙｍｏｄｅｌ，ａｎｄｍｏｄｉｆｙｉｔｓ
Ⅱ
ｉｎｏｎｔｏｌｏｇｙ
ｃａｐａｂｉｌｉｔｉｅｓｏｂｊｅｃｔ—ｂａｓｅｄ
Ｊｅｎａ．Ｗｅ

武汉理工大学硕十学位论文
ｉｎｔｅｒｎａｌｉｎｔｅｒｆａｃｅｓｔｏｐｅｒｓｉｓｔｅｎｔｏｎｔｏｌｏｇｙｄａｔａｔｏｔｈｅａｒｃｈｉｔｅｃｔｕｒｅｉｓｄｅｓｉｇｎｅｄｔｈｒｅｅ—ｌａｙｅｒ，ａｎｄｔｈｅ
ｏｂｊｅｃｔｄａｔａｂａｓｅ．Ｔｈｅｓｙｓｔｅｍ
ｐｅｒｓｉｓｔｅｎｃｅｏｆｏｎｔｏｌｏｇｙｄａｔａｔｏ
ａｃｃｅｓｓ
ｏｂｊｅｃｔ
ｔｏ
ｄａｔａｂａｓｅｉｓｅｎｃａｐｓｕｌａｔｅｄ．Ｗｅｏｎｌｙｐｒｏｖｉｄｅｉｎｔｅｒｆａｃｅｓｏｆ
ｏｎｔｏｌｏｇｙ
ｏｂｊｅｃｔ
ａｐｐｌｉｃａｔｉｏｎｓ．Ｓｏｔｈｅ
ｎｅａｒｌｙｔｈｅｓａｍｅ．
ｏｎｔｏｌｏｇｙｄａｔａｏｐｅｒａｔｉｏｎｉｎｏｂｊｅｃｔ
ｄａｔａｂａｓｅａｎｄｉｎｍｅｍｏｒｙｉｓ
（３）Ｔｅｓｔ
ｓｔｏｒａｇｅ
ａｎｄ
ａｎａｌｙｚｅｔｈｅｓｙｓｔｅｍ
ｐｅｒｆｏｒｍａｎｃｅａｎｄｔｈｅｅｆｆｉｄｅｎｃｙ
ｔｈｅ
ｏｆｏｎｔｏｌｏｇｙ
ａｎｄｑｕｅｒｙ．Ｔｈｉｓ
ｄｉｓｓｅｒｔａｔｉｏｎ
ａｎａｌｙｚｅｓ
ｐｅｒｆｏｒｍａｎｃｅｏｆｔｈｉｓｓｔｏｒａｇｅ
ｕｎｄｅｒｄｉｆｆｅｒｅｎｔ
ｓｃｈｅｍｅ，
ａｎｄ
ｔｅｓｔｓｔｈｅｅｆｆｉｄｅｎｃｙｏｆｏｎｔｏｌｏｇｙｓｔｏｒａｇｅ
ａｎｄｑｕｅｒｙ
ｃｉｒｃｕｍｓｔａｎｃｅｓ
ｃｏｍｐａｒｅｓｔｈｅｅｆｆｉｃｉｅｎｃｙｗｉｔｈｒｅｌａｔｉｏｎａｌｄａｔａｂａｓｅ．
Ｋｅｙｗｏｒｄｓ：Ｏｎｔｏｌｏｇｙｓｔｏｒａｇｅ，Ｏｂｊｅｃｔ－ｏｒｉｅｎｔｅｄｄａｔａｂａｓｅ，ｄｂ４０
１１１

独创性声明
本人声明，所呈交的论文是本人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得武汉理工大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说
明并表示了谢意。
期：
兰呈！！：量：衫
学位论文使用授权书
本人完全了解武汉理工大学有关保留、使用学位论文的规定，即：学校有权保留并向国家有关部门或机构送交论文的复印件和电子版，
允许论文被查阅和借阅。本人授权武汉理工大学可以将本学位论文的
全部内容编入有关数据库进行检索，可以采用影印、缩印或其他复制手段保存或汇编本学位论文。同时授权经武汉理工大学认可的国家有关机构或论文数据库使用或收录本学位论文，并向社会公众提供信息
服务。
（保密的论文在解密后应遵守此规定）
僦引鹤）．她¨州签蓉膨眦Ｄｌｏ矗２‘

武汉理．［大学硕士学位论文
第１章绪论
１．１课题研究背景及其意义
语义网的发展对信息处理的发展做出了很大贡献，任何服务器都可以在网络上以本体的形式发布语义信息，本体信息不只是在网络上用来显示，还可以被计算机系统读懂并做自动化处理，并且可以在不同应用系统之间重复利用【¨。因此越来越多的应用系统使用了语义Ｗｅｂ技术。语义网技术的快速发展为自动化或半自动化系统之间的交互提供了新的解决方案。
本体在语义网中的地位非常重要，是解决语义层次上Ｗｅｂ信息共享和交换的基础。语义网中的本体与哲学中所说的本体是不同的，语义网中的本体，简单来说，是一个概念化的模型，是特定领域概念及其之间关系的描述。语义网是本体的一个重要应用领域，本体的构建是实现语义网的关键环节。但随着语义网络中本体资源的增加和本体结构的复杂化，本体查询和管理的效率成为人们普遍关注的问题。在大量数据时，本体的存储方式直接影响着本体的查询存储效率。因此，研究如何合理地存储大规模的本体，从而提高本体数据的访问效率是一件很有意义且具有挑战性的任务，也是目前研究的热点。
目前已经出现了很多本体存储和查询的工具或系统，采用的方式主要有内存，文件，关系数据库等。内存存储和文件方式只适合处理少量本体数据，且也受到物理内存的限制。现在主流方式是基于关系数据库存储，但由于本体模型和关系数据库模型差异巨大，本体需先拆分为三元组形式，存储存在“阻抗不匹配＂的问题，因此在大量数据中查询时效率仍不尽人意。
本文提出了基于面向对象数据库来存储本体，就是要解决关系数据库存储本体数据存在的问题。面向对象数据库吸收了面向对象程序设计语言的思想，如支持类、方法、继承等概念，面向对象数据库中数据直接以对象方式存储【２】，可避免将本体拆分为三元组。’本文通过对比本体模型和对象数据库模型的相似点，从理论上分析了面向对象数据库在本体存储上的优势，并基于Ｊｅｎａ工具包设计并实现了一种专门的存储方式。该方式利用对象数据库本身对数据的操纵能力来存储本体，不需要再将本体拆分为三元组，提高了本体的查询效率，具

武汉理工大学硕士学位论文
有重要的实际应用价值。
１．２相关领域国内外研究现状
近些年来，国内关于本体存储方面的研究都在不断发展【３１，目前按照存储介质，对本体的存储方法主要有三种：内存存储方式、纯文本存储方式，关系数据库方式【４ｌ。
１．２．１内存存储方式
基于内存的存储方式的特点是将本体数据全部导入内存，在内存结构上对
本体进行数据填充和数据查询【５１。此方法具有很高效率，但受计算机物理内存
的限制，只能处理少量的本体数据，一旦本体数据量超出了内存大小，就会导致内存溢出。且此方式不能够持久化存储本体，系统关闭则内存中的数据就会丢失。
１．２．２纯文本存储方式
纯文本存储方式是将本体库以文件的形式存储在本地文件系统中，可以采用多种文件形式，如ＸＭＬ、ＲＤＦ（Ｓ）、ＯＷＬ等［６１。系统启动时候将本体数据从文件中读入内存，然后在内存中操作本体库，之后再将本体数据写入文件进行保存［７１。这种方式系统可能需要频繁的读写文件，这种方法不仅效率低，而且很难适应数据量较大的情况。基于文件系统的存储方式一般只适用于持久化规模比较小的本体数据【引。
１．２．３关系数据库方式
关系数据库为主是将本体按照一定的策略组织在关系数据库中，利用现有的数据库系统对数据的操纵和管理能力来存取本体【引。现有的基于关系数据库的本体存储模式大致可分为３种存储模式：水平模式，垂直模式，和混合模式［１０ｌ。几种存储方式各有优缺点。但关系数据库模型和本体数据模型差异较大，关系型数据库中数据的基本数据结构是二维形式的表，而本体模型的表现形式是带有向箭头的图，所以存储本体到数据库之前要先分解本体，将本体拆分为一系列的三元组来描述【１１Ｊ。查询本体时，首先使用ＳＱＬ数据库查询语言和ＪＤＢＣ
２

武汉理。１：大学硕士学位论文
之类的中间驱动程序遍历找到与之相关的三元组，之后再将三元组组装成本体对象。就像在车库中存车时，你把它的门、椅子、轮子等等分别卸下来存放，使用时再重新组装起来一样，这是非常耗时的，而是也是没有任何意义的。这个问题通常被称为“阻抗不匹配’’。不论在关系数据库中以何种方式存放本体，都不可能解决不匹配障碍问题【１２１。
１．３本文的研究工作及组织结构
本文在分析了面向对象数据库和本体的特点，论证了用面向对象数据库存储本体的可行性和高效性，并基于Ｊｅｎａ和开源对象数据库ｄｂ４０设计并实现一种专门的存储方式，可有效地提高本体的查询效率。本文在多种情况下对系统的本体访问效率进行了测试，并与传统的关系数据库存储方式进行了对比，实验验证了面向对象数据库在本体存储方面的优越性。
全文共分５章，内容安排如下：
第一章介绍本文的研究背景及其意义，介绍了目前国内外本体存储方式的研究现状，并总结了课题研究中所做的主要工作，这章是对整个课题研究的整体介绍。
第二章为本体存储方式研究。首先对面向对象数据库的发展做了简要介绍，详细分析了本体模型的特点。并通过对比了本体模型和对象数据库模型的相似点。对基于面向对象数据库存储本体的可行性和高效性进行了分析研究。
第三章为本体存储系统的详细设计。本文选用优秀的开源面向对象数据库ｄｂ４０来存储本体，使用ｊｅｌｌａ工具包对本体数据进行填充和操作，并将本体持久存储到对象数据库的过程进行了封装，实现了基于面向对象数据库ｄｂ４０的本体存储方案。
第四章为系统性能的详细测试。在各种不同的情况下，对本体数据存储效率和查询效率进行了测试，并将结果与传统的关系数据库存储方式进行了对比，实验证明了面向对象数据库存储本体的优越性。
第五章为对本文的工作进行总结，提出可能的改进和对未来工作的展望。
３

武汉理工人学硕士学位论文
第２章基于ＯＯＤＢ的本体存储的研究与设计
２．１
ＯＯＤＢ存储技术研究
２．１．１面向对象数据库特点
面向对象程序语言操纵的是对象，所以ＯＯＤＢ的一个优势是面向对象语言程序员在做程序时，可直接以对象的形式存储数据【１３】，可在ＯＯＤＢ内部对对象进行复制或修改而产生新的对象１１训。对象数据模型有以下特点：
（１）对象数据模型将客观世界按语义组织成由各个相互关联的对象单元组成的复杂系统，是对客观事物的抽象描述【１５Ｊ。对象可以定义为对象的属性和对象的行为描述【１６１。形式上，对象包括对象标识、属性、方法、关系，对象的属性是对对象状态的描述，其成分可以是复杂数据，如集合、元组、对象等ｌｒ７１。在对象数据模型中，对象标识用来标识一个对象，一个特定的对象的属性值、方法和关系可以改变，但是标识符不能变化ｌｌ剐。
（２）在对象数据库系统中，语义上相似的对象被组织成类，类是对象的集合，对象只是类的一个实例１１９１。类为对象提供一个统一的抽象描述，并可以通过类创建类的实例，实现对象的访问和操作刚。
（３）在对象数据模型中，对象之间的关系分为直接关系和间接关系。直接关系分为两种：聚合关系和组合关系【２１１。聚合关系是指ｋｉｎｄ．ｏｆ的关系，表示某个对象是另一个对象概念意义上的一种；组合关系是指ｐａｒｔ．ｏｆ的关系，表示对象的部分与整体关系。对象间的间接关系是指对象间的具有特定意义的关系，在具体环境中有具体的意义，需要用一个类来描述这种间接关系【勿。
（４）对象数据模型具有“封装＂、“继承’’、“多态’’等基本概念，类是语义上相似对象的封装，通过类描述，可以看到对象所有的属性和行为【２３１。对象组织成继承层次结构，允许低层次类型对象访问高层次类型对象的属性和方法，这样可以减少类型定义上的混乱，使数据语义描述更加合理１２４】。
（５）方法的实现可以事先用标准宿主语言编写并存储在服务器端。方法实现类似于关系数据库中的存储过程，但存储过程并不和特定对象相关联；而方法实现则是类的一部分Ｉ矧。
（６）实际应用中，面向对象数据库可以实现一些带有复杂数据描述的应用
４

武汉理工大学硕士学位论文
系统，如时态和空间事务、多媒体数据管理等【２６ｌ。
２．１．２与关系数据库的异同
基于上述对象数据库的特点分析，我们将其与关系数据库做对比，说明为何对象数据库在数据存储上具有优势。
关系型数据库把数据存储在简单的两维表中，这是一种表达大量数据的有效方法，而且程序员也易于理解，关系型数据库使用ＳＱＬ建立了一种标准的数据访问语言，然而，关系理论的基础之一是数据和使用数据的程序能够而且应该是相互独立的１２７１。这与面向对象的思想是不一致的。
面向对象数据库使用对象而不是二维表来存储数据。对象的方法不能脱离对象本身。我们以汽车对象为例来进行说明，当你使用汽车时，你使用的是一辆完整的汽车，作为一个东西，一个对象来使用。与汽车相关的动作有很多，如驾驶，换档，按喇叭，开车灯等等。如果我们将汽车抽象为一个对象，那么这些相关动作就是对象的方法，这些动作不能脱离汽车这个对象而存在，即对象的方法不能脱离对象本身。当你把你的车停在车库，你把它作为一个东西来存储。如果使用“关系型车库＂，就需要把汽车拆散开来，分别在车库中的某些地方存放方向盘，车门，车窗，车灯，车轮。使用的时候在将这些“组装起来＂，这是相当耗时的。若使用“对象型车库’’汽车就不用拆分。
从图２．１我们可以更明确的看出关系数据库与对象数据库在数据存储时的不同。通过对图中所示的不同存储模式的对比，我们来进一步说明为何对象数据库具有优势。
图２－１ＲＤＢ与ＯＯＤＢ数据存储比较
５

武汉理１：大学硕士学位论文
首先，目前我们应用系统开发使用的大都是面向对象程序语言，而关系数据库本身并不直接支持面向对象语言中的数据类型。但是通过使用对象数据库，我们可以保持应用系统程序的一致性，因为ＯＯＤＢ与面向对象语言使用同一种
表达模型。
其次，使用面向对象语言开发应用系统时，若采用传统的关系数据库存储此信息，则存储复杂数据需要设计数据库模型，并建立相应的二维表，这是一个非常耗时的工作。若采用对象数据库存储，由以上介绍我们已经知道，对象数据库中数据表现形式与面向对象程序语言中的对象一致，不需要在对存储对象进行任何拆分或转换，也不需要在专门设计数据库，直接将程序中的对象存入对象数据库即可。
再次，由于对象与二维表关系模型的差异，我们再查询的时候还需要借助ＳＱＬ语言和ＪＤＢＣ之类的中间驱动接口，查询过程繁琐且效率低下。使用对象数据库就不会存在这个问题，我们在查询的时候也不需要借助中间接口或中间语言，直接使用我们所用的系统开发语言就可以将数据从对象数据库再取出来。
２．２本体模型特点分析
Ｓｔｕｄｅｒ给出本体定义是“本体是共享概念模型的明确的形式化规范说明’’【捌。本体具有概念模型、明确、形式化和共享四层含义【２９１。如图２－３就是一个简单的本体模型，
图２．３本体样例
６

武汉理工大学硕士学位论文
我们根据图来详细分析下本体的定义【３０１，并研究本体与对象数据库之间的相似点：
（１）我们所讲的本体是计算机本体，而不是哲学上的本体。
（２）本体所呈现的数据结构是一个图，图中的每一个节点代表一个概念。概念是我们所认知的一个基本单元。
（３）概念可由一个词或短语来表示，通常用名词或名词性短语表示。比如：人、车、网络、武汉理工大学。
（４）本体的节点通过不同的关系连接起来，其中最重要的一个关系是ＩＳ．Ａ关系。
（５）节点和ＩＳ．Ａ关系共同组成了一个有根的有向不循环图（Ｒｏｏｔｅｄ
ＤＡＧ）。
有根的意思是存在一个称为根节点的“最高节点＂。其他所有节点都通过一个或几个ＩＳ．Ａ关系连接到跟节点。
（６）这里所指的ＩＳ．Ａ关系是“向上的＂，即如果ＩＳ．Ａ关系从概念Ｘ只想概念Ｙ，那么现实世界中所有可以被叫做ｘ的东西也都可以被称为Ｙ。换句话说，每个ｘ都是Ｙ。例如汽车是交通工具，狗是一种动物。
这与面向对象数据库是非常相似的，在面向对象数据库中有类和子类的关系，且对象图与本体图也非常相似。
（７）非循环的意思是如果从一个节点出发，沿着ＩＳ．Ａ关系走下去，不管穿过多少ＩＳ－Ａ关系，永远不会回到出发点。
（８）大部分节点还有连接着其他信息，如属性、关系、公理等。
（９）属性是与概念相关的包含额外信息的简单字符串或者数字变量。例如：动物可以有一个“腿＂的属性，它的值可以为０、２、４。汽车可以有“颜色＂的属性，值可为红色、黑色。
这与面向对象数据库中的数据成员非常相似。
（１０）关系是从一个概念到另一个概念的有向链接。它表示两个概念之间如何相互关联。关系的可能会产生循环。关系的名字通常标注在链接的旁边。例如：概念“人＂与概念“车一之间存在关系，关系的名字叫做“拥有＂。
这与面向对象数据库中“动词性＂属性非常类似。（１１）通常ｌＳ－Ａ链接也可叫做ＩＳ．Ａ关系。
（１２）其他关系通常称为“语义关系＂，以与ＩＳ．Ａ关系区别。
（１３）连接两个概念的关系成为“二元关系＂，大部分本体不允许存在高次
７

武汉理工大学硕士学位论文
元关系，且二元关系是单向的。
（１４）ＩＳ．Ａ关系可使图中低层节点继承高层节点的属性和语义关系。例如：如果动物有“腿”的属性，那么狗自然也有“腿＂的属性，不需要再特别声明
狗具有“腿＂属性。
这也与面向对象数据库中的继承关系十分类似。
（１５）如果高层节点的属性有值，那么底层节点可以继承这个值，也可以重新赋给此属性新值。例如：在本体中定义了动物“腿’’属性的值为４，但是动物的孩子节点鸟重新给“腿’’属性赋值为２，那么鸟的腿属性值就为２．
（１６）本体具有“拦截机制”阻止继承。
（１７）在本体图中，高层节点代表一般概念，低层节点表示特定概念。例如：“动物”比“狗＂的概念更一般化，“狗＂比“吉娃娃＂更一般化
（１８）公理表示概念的普遍真理并与概念紧密相关。例如：如果甲是乙的丈夫，那么乙一定是甲的妻子。
（１９）信息的本体表现形式与人类知识的表现形式非常相似。
（２０）信息的本体表现形式可用于某些情况下的推理，这与人类自己的逻辑推理很类似，包括继承推理、传递推理和分类。但对象数据库不具备推理功能，因此使用对象数据库存储本体仍需要专门的推理机。
（２１）分类是指如果我们知道一个概念的属性，我们可以推出它还属于这个本体中的哪些其他概念。例如：如果我们知道一个动物有四条腿，黑色条纹，吃肉，跑的很快，生活在非洲，那它肯定是一只老虎。
（２２）一个概念可以从几个其他概念中继承信息，这叫做多继承。多继承可能会引起一些问题，如明显的冲突等。例如，美国的尼克松总统既是共和党又是基督教徒，基督教徒被认为是“和平的一，而共和党被认为是好战的。如果尼克松同时继承这两个概念，那么他是爱好和平还是喜欢战争？
（２３）传递性推理相当于ＩＳ．Ａ关系链。例如：如果我们知道“吉娃娃＂是一种狗，并且知道狗是一种动物，那么我们可以推出“吉娃娃’’是一种动物。
（２４）表示本体的有根有向不循环图也被称为分类系统，也称无序层次图。（２５）有时候本体可能允许无根图，即图有多个根。这个时候我们～般人为引入一个假定的根，从而确定其为一个有根图。一般我们称这个引入的根为“Ｔｈｉｎｇ＂。在数据库中，我们成为“实体”。
（２６）本体不能用树图来表示，因为树并不支持继承。
８

武汉理１：大学硕士学位论文
（２７）本体保存的是“语义＂知识，并不是一些没有意义的特殊符号，而是有具体含义的词。哪些依赖于数字来表现的知识如神经网络，并不属于本体。
２．３存储方案分析
从以上分别对本体模型和对象数据库模型的研究，我们发现二者有很多的相似点和共同的，用对象数据库存储本体不仅更直观，而且从理论上分析效率比关系数据库要高很多，下面我们分别对方案的可行性和高效性进行详细的分析。
２．３．１
ＯＯＤＢ存储本体的可行性
使用对象数据库在存储本体时，也会出现新的问题。由于本体模型中概念之间关系的复杂性，对象数据库在存储概念之间复杂关系时有些吃力。因为本体中所存在的关系十分灵活，而对象数据库本身并不能直接存储这些关系。此外，本体可以用概念之间关系和公理进行推理，推理需要对象的分类和传递，而对象数据库仅支持继承，且本体不支持对象的实例这个说法，本体中的概念就是模型类。在对象数据库中，存储的都是对象的实例。
解决这些问题是证明使用对象数据库来存储本体具有可行性的关键，基于以上问题，可以设计增加辅助处理模块，增加表示概念之间关系的对象如Ｔｙｐｅ等，对本体数据稍做处理，就可以持久化到对象数据库中。我们以图２．３所示本体为例，在对象数据库中存储方式设计如图２．４所示：
图２．４本体存储方式
９

武汉理ｆ：大学硕士学位论文
通过增加本体管理的模块和辅助存储模块，概念之间的复杂关系通过一个属性对象来表示，本体数据可完整的、直观的存入对象数据库。目前也有很多开源工具包可以直接借用，如Ｊｅｎａ等。因此，用对象数据库存储本体数据是完全可行的。
２．３．２
ＯＯＤＢ存储本体的高效性
面向对象数据库为应用系统存储对象提供了非常简单和有效的方式，它也为对象的查询提供了多种方式，如样本查询，查询表达式，遍历查询等查询方法【３１】。对应用系统来说就行直接获取程序中的对象一样，这种存储方式解决了使用关系数据库时所存在的“阻抗不匹配＂问题，不需要再做繁琐的对象关系映射的管理工作。
图３．５可直观的看出关系数据库与对象数据库存储数据的区别：
关系数据库
对象数据库
０Ｏｏ
图３．５关系数据库与对象数据库存储对比
在关系数据库中，二维表要同时表示对象实体和关系，所以需要规定主键和外键这些概念。本体数据复杂的图形结构与关系数据库扁平的二维表结构差异巨大，存储数据时，需要被拆分为元组之间的关系，在大规模本体查询时，不仅效率低，而且存储不直观。
目前已有很多本体处理工具包可以将本体用面向对象程序语言中的对象来表示，如Ｊｅｎａ工具包等．ｏ所以如果结合这些工具，同时使用对象数据库管理本体，可以从根本上解决模式不匹配的问题，不需要对本体数据“拆分再组装＂，可大幅度提高本体的查询效率。因此从理论上讲，用对象数据库管理本体数据比传统的关系数据库方式不仅更直观，且无论在存储性能和查询效率上，都会
１０

武汉理Ｔ大学硕士学位论文
有很大的提高。
２．４本章小结
本章通过本体特点的分析，提出使用对象数据库存储本体的方式，并详细讨论使用对象数据库存储本体的可行性和高效性。传统的关系数据库存储存在着缺点和不足，直接影响到本体的查询效率。面向对象数据库模型与本体模型有众多相似点，通过在二者之间增加一个过渡的语义管理层，对本体高效查询提供了强有力的支持。

武汉理１：大学硕士学位论文
第３章基于ＯＯＤＢ的本体存储系统的实现
３．１软件工具及数据库的选择
程序设计语言：Ｊａｖａ所用语言版本：ＪＤＫｌ．６．０Ｊａｖａ开发平台：ＭｙＥｃｌｉｐｓｅ本体工具包：Ｊｅｎａ
２．０
０５
对象数据库：ｄｂ４０７．４操作系统：ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ
３．１．１
Ｖｉｓｔａ
Ｊｅｎａ存储本体的问题及其特点
本设计选取Ｊｅｎａ２．０工具包设计实现连接本体与对象数据库的语义数据处理层。Ｊｅｎａ是一组由Ｊａｖａ编写的ＡＰＩ，是惠普实验室研发的Ｊａｖａ开发工具包，可以描述填充本体模型，用于语义网系统的开发ｐ２１。Ｊｅｎａ已经实现本体到各种关系数据库的存储，如ｍｙｓｑｌ，ｏｒａｃｌｅ等，且目前许多语义系统都是用了Ｊｅｎａ工具包。因此，本系统选用Ｊｅｎａ实现到对象数据库的存储，具有通用性。系统对外提供标准的Ｊｅｎａ接口，目前本体应用系统不用修改或只需做少许修改就可以移植到对象数据库上。
此外，选用Ｊｅｎａ来实现本体到对象数据库的存储，还因为Ｊｅｎａ具有以下特
点：
（１）Ｊｅｎａ可以用多种形式读取ＲＤＦ等本体模型，ＪｅｎａＡＰｌ允许处理基ＲＤＦ的本体数据，即它支持ＯＷＬ，ＤＡＭＬ＋ＯＩＬ和ＲＤＦＳ，可直接读取文件存储的本体到内存，对本体模型执行读写、查询等多种操作１３３ｌ。也可在内存中直接创建本体模型，再对其进行填充、修改。Ｊｅｎａ提供方法可将本体对象与三元组之间随意转换。
（２）可使用多种数据库存储本体数据。Ｊｅｎａ可将本体数据持久化到关系数据库中。Ｊｅｎａ可在关系数据库中为本体自动建立相应的表格（一般是５个表）进行存储。Ｊｅｎａ虽然对这部分功能进行了封装，但实际存储方式仍然是将本体

武汉理工大学硕ｔ学位论文
数据转化为三元组，这里是我们系统重点研究并修改的地方。
（３）Ｊｃｎａ提供成熟的查询模型。ＳＰＡＲＱＬ是一种本体查询语言，是由Ｗ３ＣＲＤＦ数据访问工作组设计的访问ＲＤＦ数据模型的协议［３４１。Ｊｅｎａ２提供的ＡＲＱ查询引擎实现了ＳⅣ氓ＱＬ查询语言，从而支持对模型的查询。但查询引擎与关系数据库相关联，这使得在本体数据量比较大时，本体的查询效率将会受到严重影响【３５１。本系统设计工作之～就是修改Ｊｅｎａ代码，将其与关系数据库的查询关联转移到对象数据库中来。
（４）支持基于规则的推理。Ｊｅｎａ２支持基于规则的简单推理，并且允许引入其他推理引擎或推理机，创建模型时将推理机与模型关联以实现推理【蚓。本系统设计对外提供标准的本体推理接口，因此常用推理机不需要做任何修改就可以嵌入本系统。
３．１．２
ｄｂ４０对象数据库概述
ｄｂ４０是一个优秀的纯面向对象数据库引擎，Ｊａｖａ与．ＮＥＴ开发者只需一行代码就可以直接存储和获取应用对象，不需要再独立预定义和维持一个数据模
型阳。此外，ｄｂ４０还有一个优势就是无需数据库管理员的管理，占用资源很小。
自从ｄｂ４０对象数据库发布以来，迅速吸引了大量用户将原基于关系数据库的应用系统转移到ｄｂ４０上来Ｉ硎。
ｄｂ４０数据库引擎具有使引人注目的新功能，实现了关系数据库所未有的性能和灵活性ｆ３９１。主要特性如下：
（１）开源模式。与其他面向对象数据库不同，ｄｂ４０是开源软件，依靠开源社区的力量驱动开发ｄｂ４０产品Ｉ蛔。
（２）原生数据库。ｄｂ４０是１００％原生的面向对象数据库，可直接使用
Ｊａｖａ、．ＮＥＴ编程语言来操作１４１１。程序员不需要进行对象关系映射来存储对象数
据，可极大的节省了程序员在数据存储的开发时间。
（３）无需管理。使ｄｂ４０无需数据库管理员，实现了零管理，减少开发成
本【４２１。
（４）支持多种开发平台。ｄｂｄｏ支持各种Ｊａｖａ版本开发，而且还支持．ＮＥＴ
开发平刽矧。由于Ｊｅｎａ是Ｊａｖａ语言开发的本体工具包，因此本系统选用Ｊａｖａ
平台，可方便的实现Ｊｅｎａ到对象数据库的连接。
（５）高性能。ｄｂ４０比传统的Ｈｉｂｅｍａｔｅ／ＭｙＳＱＬ关系数据库方案在某些测试线路上速度高出４４倍之多，且仅仅需要在应用系统中添加一个ｊａｒ文件，安装非常简单ｌ删。
１３

武汉理工大学硕七学位论文
表３．１为官方公布的ｄｂ４０基准测试数据。
表３－１ｄｂ４０官方基准测试数据
存储方案
ｄｂ４０／４．５．２００
读区
１．０２０．８１０．４１０．８。０．４３６９６．０４．４
写入
１．０３２．２５．４１４．６１．７１２．９１４．８
查询
１．Ｏ６．７５３６．０１．７６７７．６１２９９．７３．０
删除
１．Ｏ１７．３３．９６．５０．７７．１２．４
Ｈｉｂｅｒｎａｔｅ／ＭｙＳＱＬＨｉｂｅｍａｔｅ／ＨＳＱＬＤＢＪＤＢＣ／ＭｙＳＱＬＪＤＢＣ／ＨＳＱＬＤＢ
ＪＤＢＣ／Ｄｅｒｂｙ
ＪＤＯＮＯＡ／ＭｙＳＱＬ３．１．３
ｄｂ４０与Ｊｅｎａ的衔接
Ｊｅｎａ虽然可以将本体用面向对象程序语言中的对象表示出来，但是Ｊｅｎａ只提供了基于关系数据库的存储方式。我们在Ｊｅｎａ与对象数据库之间建立一个数据处理层，通过中间层将本体再持久化到ｄｂ４０对象数据库中。存储方式如图
３－１所示。
Ｉｌ
Ｉ
Ｊｅｎａ本体数据
ｊＥ
数据处理层
ｊ亡
对象攀据库
图３－１基于ｄｂ４０本体存储设计
Ｊｅｎａ表示的本体数据不直接存入对象数据库，而是先由数据处理层对本体
１４

武汉理［大学硕士学位论文
数据进行处理。在这一层将本体数据表示成适合在ＯＯＤＢ中存储的“图＂对象，表示本体的对象都直接或间接实现Ｊｅｎａ提供的标准接口，这样基于Ｊｅｎａ设计的应用系统不需要做大的修改。数据处理层表示本体数据的对象之间关系仿照Ｊｅｎａ在关系数据库中存储设计，但对象本身继承自Ｊｅｎａ定义的内存中保存本体的对象类，这样设计既可以使本体对象方便存储到对象数据库，而且在对外接口调用上又与关系数据库类似，从而更方便系统的移植。
３．２系统的设计与实现
３．２．１系统总体框架设计
本文提出基于对象数据库ｄｂ４０存储本体的系统模型，如图３．２所示。该模型分为三个层次，从下往上依次数据访问层、本体数据处理层和对外接口层。
底层的数据访问层之负责对ｄｂ４０对象数据库的管理，包括基本数据的写入、读出和查询等，并对这些基本操作进行了封装，对上层只提供操作方法调用，这里的基本存储对象实现了Ｊｅ肋表示本体数据的Ｇｒａｐｈ接口。中间层对本体数据进行存取预处理，这一层是仿照Ｊｅｎａ在关系数据库中存储本体的模式设计，主要包括本体数据封装成Ｍｏｄｅｌ模块、创建本体Ｍｏｄｅｌ的ＭｏｄｅｌＭａｋｅｒ模块、创建本体基本表示单元Ｇｒａｐｈ的ＧｒａｐｈＭａｌ【ｅｒ模块和事务处理模块等。顶层的设计也仿照Ｊｅ舳的工厂设计模式，增加专门创建基于对象数据库的ＭｏｄｅｌＭａｋｅｒ等操作。此层本体存储的最外层，中间层的数据表示类都由这层的工厂类负责创建，对外提供标准接口方法调用。
这种采用分层设计的最大优点是上一层只对下一层次的调用管理，降低本体查询与ｄｂ４０数据访问的耦合性，程序设计人员不必关心本体数据如何存储到对象数据库中，只需调用最外层工厂类提供的创建方法创建本体Ｍｏｄｅｌ，存储时也直接调用相应的事务提交方法即可。

武汉理．［大学硕士学位论文
ＦＥ二薹重重一｛
ｌ
：据Ｌ————————————————————————————————————————————————————————＿Ｊ：
≯［二二巫堕二二］ｌ
ｌ一一一一．：—：＝＝－＝—＝＝＝＿＝—＝＝＝－＝＝＿＝＝＝＿＝＝＿＝＝＝工：＝＝－＝ｊ＝＝＝工＝＿＝＝－＝■＝＝＝＝Ｊ
图３－２基于ｄｂ４０的本体存储模型
数据读取层读取的基本数据是Ｇｒａｐｈ图，是Ｊｅｎａ用来表示本体概念的基本元素，系统专门设计了基于ｄｂ４０的本体ＤＢ４０Ｇｒａｐｈ，实现了Ｊｅｎａ的Ｇｒａｐｈ接口，在数据处理层基于Ｇｒａｐｈ封装成本体Ｍｏｄｅｌ。此层就是对Ｇｒａｐｈ的基本访问操作，在对象数据库中存取的基本本体类也是Ｇｒａｐｈ。
数据处理层仿照Ｊｅｎａ到关系数据库的存储，由于Ｊｅｎａ内存模型与ｄｂ４０持久化模型结构上的一致性，系统设计的存储类都是基于或者直接继承自Ｊｅｎａ中对本体在内存操作的类，但是Ｊｅｎａ在内存中处理本体数据不存在事务的管理问题。因此，此层还设计了事务管理操作，并进行了基本封装，可调用相关方法进行事务回滚或事务提交到对象数据库。
对外接口主要是一个ＭｏｄｅｌＦａｃｔｏｒｙ的工厂类，直接创建基于ｄｂ４０的本体Ｍｏｄｅｌ，此Ｍｏｄｅｌ是继承自Ｊｅｎａ的内存本体Ｍｏｄｅｌ，方便存储到对象数据库。而系统设计的调用方式与Ｊｅｎａ创建基于关系数据库Ｍｏｄｅｌ相似，方便了已有应用系统移植。
另外，系统基于ｄｂ４０采用层次体系结构来设计存储本体，还具有如下几个优点：
（１）各层对自己要实现的功能进行封装，下层模块仅提供接口方法供上层模块调用，这样简化了本体存储的本体数据处理和持久化到ｄｂ４０的复杂性，而
ｌ
Ｉ！
１６

武汉理Ｉ：大学硕士学位论文
且单个层次的局部处理模块求解规模减小，从而降低了整个系统实现的复杂性。同一层次内各子系统模块之间是协作关系，通过协同合作共同完成本层模块所负责的功能，同时设计尽量降低各子模块对其他子模块的依赖性，内部进行局部封装、分工，减小了系统内部子模块的工作量。应用程序设计人员只需了解外层接口方法，不需要关心存储的具体实现。
（２）仿照Ｊｅｎａ基于关系数据库存储方法设计，使基于对象数据库存储方法符合原来的调用习惯。系统将对象数据库ｄｂ４０的基本读取操作封装在底层，中间层对本体的查询存储操作仿照Ｊｅｎａ在关系数据库设计，使Ｊｅｎａ程序开发人员不需要了解ｄｂ４０如何存储，因此可以很快上手，不会影响新语义系统的开发，并提高了整个本体系统的本体处理性能。从方法调用上来看，本系统与基于关系数据库系统的调用方式基本相同。
（３）便于目前已有的本体应用系统的移植。目前许多语义系统都是Ｊｅｎａ或基于Ｊｅｎａ所做的，因此系统各模块设计均实现了Ｊｅｎａ对本体调用的接口，这样可以在不需要对原系统进行修改或只需稍做修改，就可将原来就有关系数据库的系统移植到对象数据库ｄｂ４０上来。
３．２．２各模块功能具体实现
系统设计有三个层次，每个层次都有几个功能模块组成，各个模块之间的关系如图３．３所示。
图３．３系统各模块之间关系图
下面分层对各个模块主要功能及模块之间关系介绍如下：
１７

武汉理工大学硕士学位论文
（１）顶层的对外接口也是仿照Ｊｅｎａ设计的，使用的是工厂设计模式。它提供一个创建本体的ＭｏｄｅｌＭａｋｅｒ的工厂，可创建基于ｄｂ４０的本体ＭｏｄｅｌＤＢ４０Ｍａｋｅｒ，ＭｏｄｅｌＤＢ４０Ｍａｋｅｒ实现了Ｊｅｎａ提供的ＭｏｄｅＭａｋｅｒ接口，并且设计为ＭｏｄｅｌＦａｃｔｏｒｙ的内部类实现。这样我们甚至可以直接在Ｊｅｎａ源代码中添加这段代码，再从新编译成ｊａｒ包即可，使得系统设计通用性更强。各模块之间的关系如图３．４所示。
图３．４顶层模块之间关系图
ＭｏｄｅｌＦａｅｔｏｒｙ主要包含两个创建ＭｏｄｅｌＤＢ４０Ｍａｋｅｒ的方法，和一个创建基于对象数据库ｄｂ４０连接的方法。前两个方法实现了方法的重构，第一个方法只需提供一个实现ＩＤＩＭＯＣｏｎｎｅｃｔｉｏｎ接口的对象做参数，就可建立本体模型制造器。ＤＩＭＯＣｏｎｎｅｃｔｉｏｎ就是实现ＩＤＢ４０Ｃｏｎｎｅｃｔｉｏｎ接口的类。第二个构造方法有两个参数，比第一个方法多一个ＲｅｉｆｉｃａｔｉｏｎＳｔｙｌｅ参数，这是Ｊｅｎａ工具包中的一个类，可设置它的各种参数项。若缺省，则是用默认的ＲｅｉｆｉｃａｔｉｏｎＳｔｙｌｅ对象创建。
ＭｏｄｅｌＤＢ４０Ｍａｋｅｒ只是一个创建本体模型的包装类，其对本体的操作都是通过ＧｒａｐｈＤＢ４０Ｍａｋｅｒ实现的，操作的本体的基本数据形式仍是Ｇｒａｐｈ，这样设计主要是与Ｊｅｎａ接口相兼容，操作方式依据关系数据库设计。ＭｏｄｅｌＤＢ４０Ｍａｋｅｒ的设计实现是使其直接继承Ｊｅｎａ的ＭｏｄｅｌＭａｋｅｒｌｍｐｌ类，构造参数为ＧｒａｐｈＤＢ４０Ｍａｋｅｒ对象，它所实现的基本操作都是调用
ＧｒａｐｈＤＢ４０Ｍａｋｅｒ的方法。
１８

武汉理工大学硕士学位论文
ＭｏｄｅｌＤＢ４０是表示本体数据的Ｍｏｄｅｌ，是基于对象数据库ｄｂ４０的。这个类继承自Ｊｅｎａ基于内存的表示本体的ＭｏｄｅｌＣｏｍ。构造器接受ＧｒａｐｈＤＢ４０对象参数，这个类并不包含具体的对本体的操作，其操作都是通过调用ＧｒａｐｈＤＢ４０方法完成的。ＧｒａｐｈＤＢ４０是数据处理层的模块。
（２）数据处理层各模块设计大都实现了Ｊｅｎａ在内存中表示本体的接口，这样可由Ｊｅｎａ创建和填充本体的内存模型，在通过调用底层的接口并将它们持久存储到数据库中。系统仿照Ｊｅｎａ在关系数据库持久化本体设计，这样做的好处是Ｊｅｎａ程序员开发本体系统可快速上手，且原有的本体应用系统只需做极小修改就可以，各模块之间关系如图３．５所示。
图３．５数据处理层模块之间关系图
本层设计的核心类是ＧｒａｐｈＤＢ４０Ｍａｋｅｒ，ＧｒａｐｈＤＢ４０Ｍａｋｅｒ继承自Ｊｅｎａ的ＢａｓｅＧｒａｐｈＭａｋｅｒ对象，是ＭｏｄｅｌＤＢ４０的构造参数，它实现了Ｊｅｎａ表示本体基本元素的图结构Ｇｒａｐｈ。ＧｒａｐｈＤＢ４０Ｍａｋｅｒ负责直接创建最基本的本体数据ＧｒａｐｈＤＢ４０对象。
ＧｒａｐｈＤＢ４０继承自Ｊｅｎａ工具包中的ＧｒａｐｈＭｅｍＦａｓｔｅ类，而ＧｒａｐｈＭｅｍＦａｓｔｅ是Ｊｅｎａ在内存中表示本体的基本单元。由于对象数据库中数据结构与面向对象程序语言中的对象类型一致，内存中的对象可直接存入ｄｂ４０数据库，所以我们在数据库中的存储单元实现ＧｒａｐｈＭｅｍＦａｓｔｅ类的话，Ｊｅｎａ从数据库中查询、删除、修改本体数据就会跟在系统内存中一样。数据用则取，不用则存，不用在像关系数据库那样，用的话取出相关三元组组成对象供调用，不用的话拆分为
１９

武汉理工大学硕士学位论文
三元组再存，因此存取效率比关系数据库要高很多。这个类的对象是数据库的基本存储单元。
本层设计在处理本体数据时还实现事务操作功能，核心类是ＤＢ４０ＧｒａｐｈＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅｒ，这个类对存储本体的事务操作进行了封装，它实现了Ｊｅｎａ的ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅｒ接口，提供事务的开始、提交、回滚等操作，还可以通过ｔｒａｎｓａｃｔｉｏｎｓＳｕｐｐｏｒｔｅｄ方法对是否支持事务进行测试。这个类是通过调用ｄｂ４０数据库本身的事务处理能力来实现事务操作的。
（３）系统的底层包含曲４０数据库和对数据库进行基本操作管理的各个功能模块，对上一层提供打开关闭数据库连接、访问数据等接口方法，类似我们使用关系数据库时的Ｈｉｂｅｒｉｎａｔｅ所建立ＤＡＯ层。在ｄｂ４０对象数据库中，存储的基本对象是Ｇｒａｐｈ图，是Ｊｅｎａ提供的表示本体元素的接口。
而实现对ＤＢ４０Ｇｒａｐｈ进行基本操作的核心类是ＤＢ４０Ｃｏｎｎｅｃｔｉｏｎ，它负责对ｄｂ４０进行操作的模块可建立或关闭到对象数据库的连接，并负责ｄｂ４０中存储，读取、删除数据，并提供多种查询数据的方法供上层Ｊｅｎａ接口调用，操作的基本本体数据单元是Ｇｒａｐｈ。
这个接口中的方法都是仿照Ｊｅｎａ的ＩＤＢＣｏｎｎｅｃｔｉｏｎ接口写的，所以基于关系数据库能进行的操作这里基于ｄｂ４０也全部都实现了。
ＤＢ４０Ｃｏｎｎｎｅｃｔｉｏｎ提供大量的方法供调用使用，实际上，我们在ｄｂ４０数据库最底层存储的只有一个ＨａｓｈＭａｐ对象，ＨａｓｈＭａｐ键为定义的ＤＢ４０Ｇｒａｐｈ图的名字，值为ＤＢ４０Ｇｒａｐｈ对象本身。这样的优势是数据库中之存在此一个ＨａｓｈＭａｐ泛型类，无需查找，可直接取出，效率极高。且在ＨａｓｈＭａｐ中通过键查找值时间复杂度为ｌ，也是极为快速的，类似在建立索引的关系数据库中查
找。
３．３基于ｄｂ４０的本体的访问
系统的程序仿照Ｊｅｎａ连接关系数据库的方式设计，对底层对对象数据库的访问进行了封装，在进行本体数据存储或查询时候，建立与对象数据库的连接与建立与关系数据库的方法形式相似，程序容易看懂。下面我们分别看一下基于对象数据库如何存储和查询本体，并与Ｊｅｎａ基于关系数据库存储的源程序做
对比，解释异同。

武汉理工大学硕士学位论文
３．３．１本体数据的存储
（１）首先创建一个要创建一个基于对象数据库ｄｂ４０的链接，并传入一个地址参数，程序如下：
ＩＤＢ４０ＣｏｎｎｅｃｔｉｏｎＣ＝ｎｅｗ
ＤＢ４０Ｃｏｎｎｅｃｔｉｏｎ（ｄａｔａｂａｓｅＦｉｌｅ）；
ｄａｔａｂａｓｅＦｉｌｅ变量表示数据库的存放地址，ｄｂ４０数据库在硬盘中的数据形式只是一个文件，只需将ｄｂ４０数据的存放地址作为参数传给的ＤＢ４０Ｃｏｎｎｅｃｔｉｏｎ构造器即可创建链接。
（２）使用上面创建的数据库连接对象创建一个模型制造器，模型制造器用来创建本体模型。
ＭｏｄｅｌＭａｋｅｒｄｂ４０Ｍａｋｅｒ＝ＭｏｄｅｌＦａｃｔｏｒｙ．ｅｒｅａｔｅＭｏｄｅｌＤＢ４０Ｍａｋｅｒ（ｅ）；
ＭｏｄｅｌＦａｃｔｏｒｙ是一个工厂类，可以创建基于不同数据库的模型制造器，这里所创建的ＭｏｄｅｌＭａｋｅｒ实际上是ＭｏｄｅｌＤＢ４０Ｍａｋｅｒ，是基于ｄｂ４０对象数据库设计的实现了Ｊｅｎａ中ＭｏｄｅｌＭａｋｅｒ接口的类，可用于创建基于ｄｂ４０的本体模型。
（３）使用ＭｏｄｅｌＭａｋｅｒ创建本体模型对象，参数为本体模型的名字，此处命名为“ＭｙＯｎｔｏｌｏｇｙ＂，缺省默认为ｄｅｆａｕｌｔ，本体模型对象可直接调用Ｊｅｎａ工具包中的方法进行数据填充。
Ｍｏｄｅｌ
ｄｂ４０Ｍｏｄｅｌ＝ｄｂ４０Ｍａｋｅｒ．ｃｒｅａｔｅＭｏｄｅｌ（”ＭｙＯｎｔｏｌｏｇｙ”）；
这里创建的本体模型实际上就是ＭｏｄｅｌＤＢ４０对象的实例，ＭｏｄｅｌＤＢ４０是基于对象数据库ｄｂ４０设计的表示本体模型的类，与Ｊｅｎａ中基于关系数据库中的Ｍｏｄｅｌ一样，它实现了Ｊｅｎａ本体模型的标准的Ｍｏｄｅｌ接口，可利用Ｍｏｄｅｌ接口中多中方法对其进行操作，具有通用性。
（４）对本体模型进行填充，修改。对本体模型的填充的方法都是继承自标准的Ｊｅｎａ接口，可以调用其方法添加数据，也可以直接读取ｏｗｌ文件数据填充本体对象。
（５）将本体数据存入对象数据库，只需一句程序语言。
ｃｏｎｎｅｃｔｉｏｎ．ｃｏｍｍｉｔ０；
．
实际上这里进行的是事务的提交，最后调用的是ｄｂ４０数据库本身的事务提交方法。本体在ｄｂ４０中存储过程中，之前对本体的修改、填充都是在内存中操作，只有进行事务提交后，本体才真正的存入数据库，
（６）关闭对象数据库链接，释放资源。
ｃｏｎｎｅｃｔｉｏｎ．ｃｌｏｓｅ０；
２１

武汉理工大学硕十学位论文
如果未做步骤（５）中事务提交的工作，这里对象数据库中连接关闭时，也会自动将本体存入ｄｂ４０中，即关闭数据库也是对事务的提交。当然若要再次修改本体数据，需重新建立连接。
通过以上几个程序步骤调用，就可阻将一个本体数据转存到ｄＭｏ对象数据库中，我们可以看到程序大量使用的是标准的Ｊｅｎａ接口，创建本体Ｍｏｄｅｌ和存储本体Ｍｏｄｅｌ与原Ｊｅｎａ调用方式一样，只需刨建一个基于ｄｂ４０的ＤＢ４０Ｃｏｎｎｅｃｔｉｏｎ数据库连接，且存储最终存储过程只是直接调用哪个Ｍｏｄｅｌ的ｔｏｍｍｉｔ方法进行事务提交即可。存储之后，在ＭｙＥｃｌｉｐｓｅ中装一个ｄｂ４０专用的插件，我们就可以利用ｄｂ４０Ｂｒｏｗｓｅｒ直接查看存入对象数据库的本体对象，如图３．６所示。
孽出ｃｄ“ＷＭ’㈣口
ｃ∞ｔｂ＾ｗ¨‘…ｏＴ’悱“ｐ弛ＭＭｍ
ｃ∞Ｊ■Ｊ∞Ｌ¨一№＇ｈ口日岫ｈ
・ｃ帅＾¨口＊∞一㈣ｏＴ■ｋ岬一ｃ＿ｕ¨Ｈｈ…∞Ｔｍｋｍ∞蝴一ｈ日＿‘ｎｏ～■＿■■ｍ‘
－∞ｍｑ州蚺ｎ州诎出口＾二—一ｏ‘ｗｕ州扣一～自＂Ｍ．．ｍｑｍ日¨ｒｒｍＭ
－∞“州扣☆¨ｗＭｈ“∞岬■。““ｂ～…｛－一一㈣“～
，ｊｏ籼ｌ’Ｈ滴
．ｔｄｌ
‘”“”！“ｍ∞ｍｍ７ｗｍ㈣‘｛ｏ№ｉ１∞“ｂ口∞ｍ州目椰啪
ｔ
ｊ一～Ⅲ舸“Ｈ
㈣ｍｍ
Ｉ｜
｛“ｔ
ｍ＿
“＿‘ｈＪ＿¨日ｈ∞●ｐ∞日¨＊ｍ∞ｍ砒口哺
。’（
∞“ｍｍ¨ｄ№
。自
∞∞ｎｂ■ｈｏｍｏ■ｔ０Ｂｎ．
！？！！—一
ｏ！山ｗ即脚ｃｈ’即肿岬即肿Ｉ
。～！一¨Ｄ‘ｍⅦｍ
”ｊｊｏ＝＝
ａ岫
ｏ…．．＋
二“¨¨。ｍ日∞ｄ¨帆“Ⅲ咖
图３－６ｄｂ４０对象数据库中的本体
从图中可以看到，所有存在ｄｌ＇‘ｌｏ数据库中的与本体相关的类都会被列在左边ｔ同时我们还可以查询这些所列的类在对象数据库中的存储实例，从图右边上部分可以查看某个类实例的个数等信息，图的下部甚至可以详细直观的查看和修改每个本体对象的各个属性的具体值。例如，我们利用ｄｂ４０Ｂｒｏｗｓｅｒ查看

武汉理工大学硕士学位论文
了ＧｒａｐｈＤＢ４０类在对象数据库中的存储情况。在图的右边上部分，我可以看到ｄｂ４０中已经存储量一个ＧｒａｐｈＤＢ４０对象，右下部分可以查看ＧｒａｐｈＤＢ４０实例
各个属性的具体信息。
３．３．２本体数据的查询
本体的查询有多种方式，可以通过本体的ＵＲＩ来直接查找某个数据，也可以使用本体查询语言ＳＰＡＲＱＬ在本体模型中查找某些符合条件的本体条目。本系统基于Ｊｅｎａ设计，Ｊｅｎａ对本体查询的所有方式都适应。下面是基于对象数据库ｄｂ４０来用进行本体的简单查询。
（１）首先还是创建一个连接ｄｂ４０的ＤＢ４０Ｃｏｎｎｃｃｔｉｏｎ，使用这个数据库连接对象创建一个模型制造器ＭｏｄｅｌＭａｋｅｒ，ＭｏｄｅｌＭａｋｅｒ用来创建本体模型。
ＩＤＢ４０Ｃｏｎｎｃｃｔｉｏｎｃ＝ｎｅｗＤＢ４０Ｃｏｎｎｃｃｔｉｏｎ（ｄａｔａｂａｓｅＦｉｌｅ）；
ＭｏｄｅｌＭａｋｅｒｍａｋｅｒ＝ＭｏｄｅｌＦａｃｔｏｒｙ．ｃｒｅａｔｅＭｏｄｅｌＤＢ４０Ｍａｋｅｒ（ｃ）；
通过以上程序调用，Ｊｅｎａ与ｄｂ４０之间的连接就建立起来，之后的对本
体Ｍｏｄｅｌ的操作都与数据库相关的。
（２）建立连接后，直接根据本体Ｍｏｄｅｌ的名字在对象数据库ｄｂ４０中取出Ｍｏｄｅｌ对象。
Ｍｏｄｅｌｍｏｄｅｌ＝ｍａｋｅｒ．ｇｅｔＭｏｄｅｌ（”ＭｙＯｎｔｏｌｏｇｙ”）；
Ｊｅｎａ中本体的存储、查询等操作都是通过Ｍｏｄｅｌ接口执行的，将Ｍｏｄｅｌ
从数据库中读取出来时间应该尽量短。本系统以ＨａｓｈＭａｐ的名值对的方式存储Ｍｏｄｅｌ，所以Ｍｏｄｅｌ的读取是直接定位，不需要搜索。
（３）本体的查找方式多样，本设计全部采用Ｊｅｎａ接口。在Ｊｅｎａ中，需要先将普通的本体Ｍｏｄｅｌ转化为ＯｎｔＭｏｄｅｌ，下面是如何通过本体的ＵＲＩ查询本体对象的以及本体概念的某个属性值。
／／普通Ｍｏｄｅｌ通过相应方法转为ＯｎｔＭｏｄｅｌ
ＯｎｔＭｏｄｅｌＳｐｅｃｓｐｅｃ＝ｎｅｗ
ＯｎｔＭｏｄｅｌＳｐｅｃ（ＯｎｔＭｏｄｅｌＳｐｅｃ．ＯＷＬ＿ＭＥＭ）；
ｓｐｅｃ．ｓｅｔｌｍｐｏｒｔＭｏｄｅｌＭａｋｅｒ（ｍａｋｅｒ）；
ＯｎｔＭｏｄｅｌｌｍｐｌ
ｏｎｔＭｏｄｅｌ＝（ＯｎｔＭｏｄｅｌｌｍｐｌ）ＭｏｄｅｌＦａｃｔｏｒｙ．
ｅｒｅａｔｅＯｎｔｏｌｏｇｙＭｏｄｅｌ（ｓｐｅｃ，ｍｏｄｅｌ）；
∥查询本体的对象属性’
ＯｂｊｅｃｔＰｒｏｐｅｒｔｙｅａｔ＝ｏｎｔＭｏｄｅｌ．ｇｅｔＯｂｊｅｃｔＰｒｏｐｅｒｔｙ（ＮＳ＋”ｅａｔ”）；
Ｅｘｔｅｎｄｅｄｌｔｅｒａｔｏｒ＜Ｉｎｄｉｖｉｄｕａｌ＞ｉｎｔｅｒａｔｏｒ＝ｏｎｔＭｏｄｅｌ．１ｉｓｔｌｎｄｉｖｉｄｕａｌｓ０；Ｓｙｓｔｅｍ．ｏｕｔ．ｐｒｉｎｔｌｎ（”ｉｎｔｒａｔｏｒ个数：¨＋ｉｎｔｅｒａｔｏｒ．ｔｏＬｉｓｔ０．ｓｉｚｅ０）；ｗｈｉｌｅ（ｉｎｔｅｒａｔｏｒ．ｈａｓＮｅｘｔ０）｛

武汉理工大学硕士学位论文
Ｓｙｓｔｅｍ．ｏｕｔ．ｐｒｉｎｔｌｎ（”ｉｎｔｒａｔｏｒ为：”＋ｉｎｔｅｒａｔｏｒ．ｎｅｘｔ０．ｇｅｔＵＲｌ０）；
＇
ＩｎｄｉｖｉｄｕａｌａｎｉｍａｌＩｎｄｉｖｉｄｕａｌ６６６＝ｏｎｔＭｏｄｄ
．ｇｅｔｌｎｄｉｖｉｄｕａｌ（”ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｅｎ＃ｃｏｍｌｎｄｉｖｉｄｕａｌ６６６”）；
搜索出要找的本体以后，可对其进行修改等各种操作，调用事务提交方法或者正常关闭数据库以后，修改的数据会持久化到ｄｂ４０中。
（４）由于已有的语义应用系统对本体的搜索仍然是基于三元组的，且使用
的是ＳＰＡＲＱＬ查询语言。ＳＰＡＲＱＬ是Ｗ３ＣＲＤＦＤａｔａＡｃｃｅｓｓＴ作组设计并推荐
的本体查询语言，是“面向数据＂的查询语言，只对Ｍｏｄｅｌ中包含的信息进行查询。Ｊｅｎａ提供了支持此语言的接口，本系统是使用Ｊｅｎａ设计的，因此同样可以使用这种查询方式。
３．３．３与Ｊｅｎａ的异同
为了增加已有语义应用系统的可移植性，本系统设计尽量仿照Ｊｅｎａ在关系数据库中存储、查询本体的形式。由于使用对象数据库不需要中间驱动程序，因此某些代码的开发比Ｊｅｎａ要简洁很多，下面对二者的本体数据处理方式作出对比，以便开发使用。
（１）打开数据库连接。Ｊｅｎａ建立与关系数据库的连接比较复杂，创建ＩＤＢＣｏｎｎｅｃｔｉｏｎ对象需要一系列的参数。下面以连接开源关系数据库ＭｙＳＱＬ为例来作出比较。
ＳｔｒｉｎｇＳｔｒｉｎｇ
ｓｔｒＤｒｉｖｅｒ＝”ｃｏｍ．ｍｙｓｑｌ．ｊｄｂｃ．Ｄｒｉｖｅｒ”；ｓｔｒＵＲＬ＝＂ｊｄｂｃ：ｍｙｓｑｌ：／／ｌｏｃａｌｈｏｓｔ／ｔｅｓｔ”；
ｕｓｅｒ
ＳｔｒｉｎｇｓｔｒＵｓｅｒ＝”ｒｏｏｔ”；／／ｄａｔａｂａｓｅＳｔｒｉｎｇ
ｉｄ
ｐａｓｓｗｏｒｄ
ｓｔｒＰａｓｓＷｏｒｄ＝”ｒｏｏｔ’’；／／ｄａｔａｂａｓｅ
ＳｔｒｉｎｇｓｔｒＤＢ＝”ＭｙＳＱＬ”；／／ｄａｔａｂａｓｅｔｙｐｅＩＤＢＣｏｎｎｅｃｔｉｏｎｃｏｒｍ＝ｎｅｗＤＢＣｏｎｎｅｃｔｉｏｎ
（ｓｔｒＵＲＬ，ｓｔｒＵｓｅｒ，ｓｔｒＰａｓｓＷｏｒｄ，ｓｔｒＤＢ）
从代码中可以看至ＵＣ，Ｊ建ＩＤＢＣｏｎｎｅｃｔｉｏｎ需要驱动ｕｒｌ，数据库ｕｄ等很多参数。ｄｂ４０对象数据库ｄｂ４０不需要ＪＤＢＣ之类的驱动程序，只需一个数据库存放地址参数，一行代码就可以建立ＩＤＢ４０Ｃｏｎｎｅｃｔｉｏｎ对象。
ＤＢ４０Ｃｏｎｎｅｃｔｉｏｎ（ｄａｔａｂａｓｅＰａｔｈ）；
（２）创建ＭｏｄｅｌＭａｋｅｒ和Ｍｏｄｅｌ。与Ｊｅｎａ创建方法几乎相同，采用工厂设计模式，对外屏蔽了接口具体实现类。
ＭｙＳＱＬ：
ＩＤＢ４０Ｃｏｎｎｃｃｔｉｏｎｔｏｎｉｌ－ｅ＿ｎｅｗ

武汉理工大学硕士学位论文
ＭｏｄｅｌＭａｋｅｒＭｏｄｅｌ
Ｄｂ４０：
ｍｙｓｑｌＭａｋｅｒ＝ＭｏｄｅｌＦａｃｔｏｒｙ．ｃｒｅａｔｅＭｏｄｅｌＲＤＢＭａｋｅｒ（ｃｏｎｎ）；
ｍｙｓｑｌＭｏｄｅｌ＝ｍａｋｅｒ．ｃｒｅａｔｅＭｏｄｅｌ（”ＭｙＯｎｔｏｌｏｇｙ”）；
ｄｂ４０Ｍａｋｅｒ＝ＭｏｄｅｌＦａｃｔｏｒｙ．ｃｒｅａｔｅＭｏｄｅｌＤＢ４０Ｍａｋｅｒ（ｃｏｎｎ）
ＭｏｄｅｌＭａｋｅｒＭｏｄｅｌ
ｄｂ４０Ｍｏｄｅｌ＝ｍａｋｅｒ．ｃｒｅａｔｅＭｏｄｅｌ（”ＭｙＯｎｔｏｌｏｇｙ”）；
（３）创建本体模型Ｍｏｄｅｌ以后，就可以通过Ｍｏｄｅｌ接口可以对数据库中的本体数据进行、修改、填充等操作。由于两种方式都实现的是一个Ｍｏｄｅｌ接口，因此代码调用相同，在此不再赘述。
（４）事务的提交。关系数据库事务提交都是通过Ｍｏｄｅｌ接口的ｃｏｍｍｉｔ方法完成的，本系统事务提交是通过与对象数据库的链接ｃｏｎｎｅｃｔｉｏｎ的ｃｏｍｍｉｔ方法完成的。这里需要说明的是，基于ｄｂ４０的事务提交都是调用ｄｂ４０数据库本身的事务处理能力来做的，不需要写专门的事务处理代码，对ｄｂ４０基本事务
操做进行封装就可以了。
表３．２详细列出本系统访问对象数据库与Ｊｅｎａ访问关系数据库在使用方式
上的异同。
表３．２本系统与Ｊｅｎａ在操作上的异同
操作＼数据库建立与数据库连接创建本体Ｍｏｄｅｌ本体存储和查询事务的提交
ｄｂ４０对象数据库
不需要驱动，提供一个路径参数即可，比较简单
相同相同
关系数据库
需要驱动和与数据库相符的ｕｄ，较复杂
相同相同
使用与数据库连接的ｃｏｍｍｉｔ方法，需要改进
使用本体Ｍｏｄｅｌ的ｃｏｍｍｉｔ
的方法
从以上介绍可以看出，系统的设计尽最大可能仿照Ｊｅｎａ原有的基于关系数据库的设计，基本类也大都实现了相应的Ｊｅｎａ接口。且由于对象数据库本身的优势，建立连接的代码比Ｊｅｎａ简化了很多，可以有效降低已有的本体应用系统移植到对象数据库的代价。
３．４本章小结
本章详细设计并实现了基于Ｊｅｎａ和ｄｂ４０数据库的本体存储方案。基于对

武汉理工大学硕士学位论文
象数据库的存储设计是一项复杂的创造性活动，尽管ｄｂ４０数据库本身行性能
已经比关系数据库优化很多，但是如何良好的完成Ｊｅｎａ接口与ｄｂ４０之间的衔接、如何设计ｄｂ４０中本体的存储形式也与本体的查询效率有重要关系。本章给出本体存储的三层系统模型，并详细说明了各层系统模块功能及相互调用关系。介绍了在ｄｂ４０中如何进行本体存储和查询，并与Ｊｅｎａ在关系数据库中的相应操作做了对比。

武汉理工大学硕七学位论文
第４章系统性能的测试验证
４．１软件测试环境
４．１．１软件测试工具的选择
ＣＰＵ：２．２０ＧＨｚ
内存：２．００ＧＢ
操作系统：ＭｉｃｒｏｓｏｆｔＶｉｓｔａ
测试编程语言：Ｊａｖａ测试开发平台：ＭｙＥｃｌｉｐｓｅ
８．０
关系数据库：ｍｙｓｑｌ—ｅｓｓｅｎｔｉａｌ－５．１．４１
４．１．２测试流程概述
本章主要从存储和查询两方面入手，对系统的性能进行测试。在现有的存储模式中，主要以关系数据库为主。Ｊｅｎａ支持多种关系数据库，其中开源的ＭｙＳＱＬ是一个优秀的、可在各种流行操作系统平台上运行的关系型数据库系统，在本体开发中应用的也比较多。所以，本章选取ＭｙＳＱｌ中本体的存储模式和本系统在存储和查询效率上做出对比。
在进行本体存储测试时，我们分别测试了１０、１００这两个数量级上分别存入ＭｙＳＱＬ和ｄｂ４０中所需要的时间。本章设计了专门的存储效率测试程序，可以记录数据持久化到ｄｂ４０中所需要的时间，同时，也往ＭｙＳＯＬ中存入同样规模同种类型的数据，记录两种数据库各自所用的时间，并绘制图表进行对比分析，从而在性能上做出比较。
在进行本体查询测试时，本章的设计程序使用多个不同的查询，如通过Ｍｏｄｅｌ接口中的方法查询和通过ＳＰＡＲＱＬ语言查询，在测试ＳＰＡＲＱＬ查询时，使用了ＬＵＢＭ（１，０）数据测试框架。在本体数据规模不同的情况下，重复上述测试，记录查询响应时间。同时用同样的数据，同样的查询测试关系数据库中的响应时间，并对二者进行对比分析。

武汉理工大学硕士学位论文
本章在每种情况下测量５次，去掉最低和最高值，取三次测试的平均响应时间作比较，时间单位为毫秒（ｍｓ）。
４．２本体存储效率测试
本体的存储效率即本体写入数据库的速度，本章详细测试往ｄｂ４０数据库中存储一定量本体数据所需要的时间。首先在本体Ｍｏｄｅｌ中填充一定数量的属性等数据，之后存入对象数据库。同样，利用Ｊｅｎａ在ＭｙＳＱＬ数据库中存入同样数量的本体数据，测得时间。对两种存储方式所用时间做比较，以测试验证本文所设计的系统效率。存储代码设计如下。
测试程序首先将普通本体Ｍｏｄｅｌ利用Ｊｅｎａ接口转化为ＯｎｔＭｏｄｅｌ，往ＯｎｔＭｏｄｅｌ中填充一组ＯｎｔＣｌａｓｓ、Ｉｎｄｉｖｉｄｕａｌ、Ｐｒｏｐｅｒｔｙ元素，之后存入ｄｂ４０对象数据库中。利用循环可存入多组数据，同时测得所用时间。同样，将同样的本体数据也存入关系数据库ＭｙＳＱＬ中，程序与上面类似，可参考Ｊｅｎａ指南。本节通过上面所设计的代码分别测试了十、百组数量级规模的本体数据存两个数据库中所需要的时间，每个数据测量５次，去掉最低值和最高值，测试取三次存储的平均时间。时间单位为毫秒（ｍｓ）。存储十组到九十组本体数据所测的数
据如表４－１所示。
表４．１本体存入数据库测试结果一
数据库慨模
ｄｂ４０
１０
２０３０４０５０６０
７０
８０９０
１７２２１０２５７２６８３０３３１９３４２
４０７
３２８８
４５５
ｍｙｓｑｌ
３９４８２７１１９６１５５０１９１６２４０４２８１１３６２６
从表中可以看出，本系统采用ｄｂ４０的存储效率比Ｊｅｎａ到关系数据库ｍｙｓｑｌ要提高很多，在存储十组本体数据时，比关系数据库时间少用一半。随着本体数据规模增大，本系统在数据存储上的优势越来越明显，在存储九十组数据时，效率已经高出近一个数量级。我们将表中数据画成坐标图，可以看的更明显一
些，如图４．１所示。

武汉理Ｉ＝大学硕士学位论文
４０００
。‘’
１＋
３５００３０００
．，
，
／
／。
２５００
∞言
．／
，
一，
，
，
釜２０００
盔
１５００
，
，●
／’
．，，，
ｊｊ
／，
，
一．／
ｑ
１０００
Ｊ
ｊ
，
．
５００
，
．
●
●
≠
●
。
’｜
●
’
’
’
ｊ
０
‰’
１０
．ｔ。？一ｔ
３０
？，
？；…。？。。。ｔ。、荔
７０
８０
９０
２０４０５０６０
数据量（单位：组）
图４—１存储效率测试结果一
为了全面验证本系统的效率，我们再对本体存储规模稍大的情况进行验证。
选取存储百组数量级的情况，用上述同样的方法分别在ｄｂ４０中和ＭｙＳＱＬ中测试。存储一百组到一千组本体数据分别到两个数据库，所测的时间如表４．２所
示，时间单位为毫秒（ｍｓ）。
表４．２本体存入数据库测试结果二
数据库＼规模
Ｄｂ４０
１００
．
２∞
６０９
３００４００５００６００７００８００９００１０００
４６３８４３９９４１１９２１２７６１５６７１７０７１９７７２１４９
ｍｙｓｑｌ
３６６６６７３３９７７８１２８２３１６１９１１９３８５２２５７９２５７５８２８９２０３１９８７
同样从表中可以看出，本系统存储本体到ｄｂ４０比传统Ｊｅｎａ到的关系数据库所用时间大大减少，且在存储数量级大时，本系统优势更加明显，效率已经领先关系数据库一个数量级之多。表中数据画成坐标图如图４．２所示。

武汉理［大学硕士学位论文
３５０００
３００００
２５０００
公２００００
吕
厘
茁１５０００
１００００
５０００
Ｏ
１００２００３００４００５００６００７００８００９００
数据量（单位：组）
图４＿２存储效率测试结果二
通过图４－１和图４．２，可以直观的看出本文提出的基于对象数据库处理本体比经典的关系数据库在数据存储上效率要高很多。无论是在存储小规模数据还是大规模数据，本系统在本体存储上的效率都有了很大改进。在实际语义系统中，可提高数据持久化效率，减少系统反应时间，给用户更好的交换体验。当然，仅仅提高了存储效率是不够的，更重要的是使用对象数据库存储本体时，本体的查询效率是否提高。我们来进行更详细的测试。
４．３小规模数据下本体查询效率
本体的查询效率是人们最关心的问题，是提高语义网系统性能的关键。本节对本系统在本体查询效率上进行测试，并与关系数据库ＭｙＳＱＬ最比较。由于对象数据库本身的优势，在从ｄｂ４０中取出本体Ｍｏｄｅｌ对象时，会同时读取与之关系最紧密的一些对象到内存中。所以在ｄｈ４０中进行本体搜索，有一定的几率会是直接在内存中进行数据访问，不需要与数据库进行交互，这样极大的提高本体查询效率。本体的查询有多种方式，本节对各种查询方式在不同数据规模下进行了全面的测试。

武汉理工大学硕士学位论文
４．３．１通过接口方法查询
首先利用Ｍｏｄｅｌ或者ＯｎｔＣｌａｓｓ接口的方法进行查询，主要是用Ｌｉｓｔ方法查询所有个体（Ｉｎｄｉｖｉｄｕａｌ）。部分测试查询效率的代码设计如下。
测试程序首先从对象数据库中取出普通的本体Ｍｏｄｅｌ，利用Ｍｏｄｅｌ中的方法对本体进行查询。本节主要测试了三种查询：
（１）
通过ＯｎｔＭｏｄｅｌ获得所有个体
主要利用ＯｎｔＭｏｄｅｌ．１ｉｓｔＩｎｄｉｖｉｄｕａｌｓ０方法进行测试，分别测试了两百、四百、六百、八百、一千组数据时的查询效率，时间单位是ｍｓ。结果如表４．３所示。
表４．３本体查询结果一
数据库＼数据规模
ｄｂ４０
两百
３６６
四百
５４７
六百
９２３
八百
１１３４
一千
１４４６
ＭｙＳＱＬ
４１１４７７５６１１４０８１５３４５１８９３１
此方法查询到的个体数量比较多，从表中可以看出，本系统的查询优势非常明显。我们绘制成柱形图进行对比，如图４．３所示。
加掩墙Ｍ￡ｊｍ
咖咖咖咖咖咖咖咖咖咖
。
＾譬ｖ匣富
翻
８
６４
２
２∞４００６００８００
数据量（单位；组）
图４—３本体查询效率对比图一
３１

武汉理工大学硕士学位论文
从图４．３中可以明显看出，在不同数据规模下，利用ＯｎｔＭｏｄｅｌ．１ｉｓｔＩｎｄｉｖｉｄｕａｌｓＯ方法查询所有实例，ｄｂ４０拥有巨大的优势，速度快出一个数量级之多。
（２）
查找某个具体类的所有实例
主要利用ＯｎｔＣｌａｓｓ．１ｉｓｔＩｎｓｔａｎｃｅｓＯ方法进行测试，也测试了两百到一千组数据规模下的查询效率，时间单位是ｍｓ。结果如表４．４所示。
表４—４本体查询结果二
数据库＼数据规模
ｄｂ４０
两百
６６
四百
１１９
六百
１８６
八百
２７５
一千
２９８
ＭｙＳＱＬ
２１９４１６５８４７５６’９０１
从数据上看，本系统比传统关系数据库效率仍高出几倍，与关系数据库查
询效率对比如图“所示。
Ｏ∞９∞８∞７∞６∞５∞
一譬一庭窜
４∞３∞２∞ｌ∞Ｏ
一口■一一ｄ正一一ｂ羔一如盟一ｔ工一
∞
数据量
．
盟
∞
组
图“本体查询效率对比图二
（３）
查找所有属性
主要利用ＯｎｔＭｏｄｅｌ．１ｉｓｔＡｌｌＯｎｔＰｒｏｐｅｒｔｉｅｓ０方法，同样测试了五种数据规模下

武汉理工大学硕士学位论文
的查询时间，测试结果如表４．５所示。
表４－５本体查询结果三
数据库＼数据规模
ｄｂ４０
两百
６７
四百
１２２
六百
１８９
八百
２９５
一千
３０４
ＭｙＳＱＬ
３９３，。７５７
１０５１１３５２１６１１
同样绘制成柱状图，与ｍｙｓｑｌ做对比，如图４．５所示。
ｔ８∞
１６００
ｊ一一ｗ咿＿丫。。霉
移ｊ１鹗，——．｛
。Ｙ∥峨”？Ⅲ。ｊｊｊｊ坤“守
一‘，
一妒””ｊ、∞。ｊ≯啊噬ｗ烨…
１４∞
，
１２∞
黧
ｌ
譬１０００
庭
窨８００
６００
．●掰
ｊ
目鬣
蒸
Ｉ厂■
。．１自％。Ｊ
８００
一口■一—ｄ■一
｜耋ｉｌ
一，ｌ一
ｌ
４∞２∞
Ｏ
缀。露荔］
翻
豳
！ｒ］
一ｌ溉…
Ｆ＿
４００
Ｉ，一ｋ
６００
ｌ
ｌ｛
。。。，￡ｋ
ｌ
圈｝习
２００ｌｏｏＯ
数据量（单位：组）
图４．５本体查询效率对比图三
４．３．２通过ＳＰＡＲＱＬ查询
ＳＰＡＲＱＬ（ＳｉｍｐｌｅＰｒｏｔｏｃｏｌ
ａｎｄＲＤＦＱｕｅｒｙ
Ｌａｎｇｕａｇｅ），是为ＲＤＦ开发的一种
查询语言和数据获取协议，它是为Ｗ３Ｃ所开发的ＲＤＦ数据模型所定义，但是
可以用于任何可以用ＲＤＦ来表示的信息资源１４ｓｌ。
这里的查询测试我们使用了著名的ＬＵＢＭ性能测试框架。ＬＵＢＭ是一个关于大学的领域本体，我们使用ＬＵＢＭ（Ｉ，０）作为测试数据，包含１５个数据文件，
约１０万个三元组【矧。我们测试了数据规模为３、６、９、１２个数据文件下的５

武汉理｜１：大学硕士学位论文
中不同查询方式。这５种查询方式如下：
（１）查询本科和研究生在同一所大学读的在读研究生和他所在学校。查询
语句为：
ＳＥＬＥＣＴ？Ｘ？Ｙ
ｗｈｅｒｅ｛？Ｘ＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｃｎ＃ｒｎｅｍｂｅｒＯｆ＞？ｚ．
？Ｚ＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｃｎ＃ｓｕｂＯｒｇａｎｉｚａｔｉｏｎＯｆ＞？Ｙ．
？Ｘ＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｃｎ＃ｕｎｄｅｒｇｒａｄｕａｔｅＤｅｇｒｅｅＦｒｏｍ＞？Ｙ．’
解释：查找所有满足条件的ｘ和Ｙ，其中Ｘ是Ｚ的成员，Ｚ是Ｙ的子组织，且Ｘ从Ｙ取得本科学位。
（２）查询所有由某个教授所出版的书。这有两个查询条件，我们将两个条件颠倒，查询两次分别进行对比。查询语句如下：
ＰＲＥＦＩＸ
ｕｂ：＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｃ渤
ＰＲＥＦＩＸｒｄｆ：＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／１９９９／０２／２２・ｒｄｆ－ｓｙｎｔａｘ－ｎｓ舟＞
ＳＥｕ￡Ｃｒ？Ｘｗｈｅｒｅ｛
？Ｘｒｄｆ：ｔｙｐｅｕｂ：Ｐｕｂｌｉｃａｔｉｏｎ．？Ｘｕｂ：ｐｕｂｌｉｃａｔｉｏｎＡｕｔｈｏｒ
＜ｈｔｔｐ：／／ｗｗｗ．Ｄｅｐａｒｔｍｅｎｔ０．Ｕｎｉｖｅｒｓｉｔｙ０．ｅｄｕ／ＡｓｓｉｓｔａｎｔＰｒｏｆｅｓｓｏｒ０＞．｝
解释：查询所有满足条件的Ｘ，Ｘ的类型是出版物，且Ｘ的作者是由ＵＲＬ唯一确定的某个特定教授。
（３）查询所有的学生，即所有的研究生和本科生。查询语句如下：
ＰＲＥＦＩＸ
ｒｄｆ：＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｅ；／１９９９／０２／２２一ｒｄｆ－ｓｙｎｔａｘ・ｎｓ挣＞
ＳＥＬＥＣＴ？ｘｗｈｅｒｅ｛
｛？ｘｒｄｆ：ｔｙｐｅ＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｃｎ＃ＵｎｄｅｒｇｒａｄｕａｔｅＳｔｕｄｅｎｔ＞｝ＵＮＩＯＮ｛？ｘｒｄｆ：ｔｙｐｅ＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｃｎ＃ＧｒａｄｕａｔｅＳｔｕｄｅｎｔ＞｝）
解释：查询所有满足条件的Ｘ，Ｘ的类型是本科生或者研究生，ＵＮｌＯＮ表
示的是并操作。
（４）查询属于某个大学的所有学生和他们的Ｅｍａｉｌ。查询语句如下：
ＰＲＥＦＩＸｕｂ：＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ａｌｌｊ９｝＞
ＳＥＬＥＣＴ
？Ｙ？Ｘ
？Ｘ
？Ｚ
ｗｈｅｒｅ｛？Ｘ
ｕｂ：ｍｅｍｂｅｒＯｆ
？Ｙ．
ｕｂ：ｓｕｂｏｒｇａｎｉｚａｔｉｏｎＯｆ＜ｈｔｔｐ：／／ｗｗｗ．Ｕｎｉｖｅｒｓｉｔｙ０．ｅｄｕ＞．
ｕｂ：ｅｍａｉｌＡｄｄｒｅｓｓ？Ｚ）
解释：查询满足条件的Ｘ，Ｚ，其中Ｚ是Ｙ的成员，Ｙ是由ＵＲＬ唯一确定
的某大学子组织，Ｘ的ｅｍａｉｌ地址是Ｚ。

武汉理ｒ大学硕士学位论文
（５）查询选修了他们导师课程的所有学生。查询语句如下：
ＰＲＥＦＩＸ
ｕｂ：＜ｈｔｔｐ：／／ｗｗｗ．ｗｈｕｔ．ｅｄｕ．ｃ彬
ｗｈｅｒｅ｛？Ｘ
ｕｂ：ａｄｖｉｓｏｒ？Ｙ
ＳＥＬＥＣＴ？Ｘ？Ｙ？Ｚ
？Ｘｕｂ：ｔａｋｅｓＣｏｕｒｓｅ？ｚ．”＋”？Ｙ
ｕｂ：ｔｅａｃｈｅｒＯｆ？Ｚ．）
解释：查询满足条件的Ｘ，Ｙ，Ｚ，其中Ｘ是Ｙ的导师，Ｘ学习了课程ｚ，且Ｙ是教Ｚ课程的老师。
这五种查询在ｄｂ４０中查询结果如表４＿６所示，在ｍｙｓｑｌ中的查询结果如图４．７所示。同时测试了不同数据规模下的查询效率。
表４－６ｄｂ４０中ＳＰＡＲＱＬ查询效率
查询方式＼规模
查询１查询２查询３
５８８
７４５１５２２１０６６３１１９８
８９６
８９６
６２１３３
１５０８１０２７２９２３１６７２
１１７８
１３２２４１５５２５０９９３２５７
２２４５
１５５１
１７８２５５６７３３８０１２４４６２
２８２１
查询４
查询５
表４＿７ｍｙｓｑｌ中ＳＰＡＲＱＬ查询效率
查询方式＼规模
查询１查询２查询３
２３５
３２１４４
１４５９４３７２９３８１８８３
２４９
６３８５６
１９５１５７８４９６６２８８７
２４４
９５１４７
２．４８３６８５７３５７４１９４
２．４６
１２６７５０
３２２１８１５１００１９５６６８
查询４
查询５
查询２中我们将查询条件作了颠倒，测试查询条件顺序变化对查询效率的
影响，也可以算是两种查询。从表中可以看出，ｄｂ４０在使用ＳＰ：被ＱＬ查询时效
率有的比ｍｙｓｑｌ高，有的比ｍｙｓｑｌ低。为了对比更加明显，我们将数据绘制成柱状图进行对比。

武汉理工人学硕士学位论文
数据规模为三个数据文件查询对比如图４－６所示。
３５００
铲
’
ｊ’ｊ
一“ｊ
ｔ？？“。ｊ¨ｊ。
。ｊ
’。
……“？臻
鼋
３０００
ｊ
２５００
圉Ｉ
：
，
］ｉ
ｊ
，《
玄２０００
一
二
暮
譬１５００
１０００
嬲
．——・１
玩
蕾，
Ｉ
搦
ｌ
一№蒌｜一铀盟一，工一
ｌ一一口■一一ｄ量一
５∞
Ｏ
ｌ。乙＿
Ｉｌ
≥魏＆
豳
貔，
３
墨。
。麓
４
４，
自彘
２（２）
查询类型（５种）
５
攀
ｉ
■
ｉ
图４．６五种查询方式的效率对比（３个数据文件）
数据规模为六个数据文件查询对比如图４—７所示。
６０００
５０∞
４０∞
∞■
釜３０００
譬
２０００
一口■～一ｄ正一一知虬一．工一
一ｍ啦
ｌＯ∞
０
２（２）３
查询类型（５种）
图４－７五种查询方式的效率对比（６个数据文件）

武汉理工大学硕士学位论文
数据规模为九个数据文件查询对比如图４．８所示。
８０００
，’
二一
呻．一。“ｊ
：二｛
・＋ｊ
。。叶１。
张’’一
々
一’”碣
７０００
６０００
飘
露豳
—蜀
Ｉ’一｛
ｌ
７ｌ鼍
５０００
啦■
ｊ
Ｉ—■■
釜４０００
茁
３０００
曩
～口■～
面蛆一如盟
２０００
ｌＯ∞
０
二
么旃
．ｊ屯。豳｝也。缀潮
纽２（２）
３
：
●ｏ
锄
闫
，
查询类型（５种）
图４．８五种查询方式的效率对比（９个数据文件）
数据规模为十二个数据文件查询对比如图４．９所示。
１２０００
移１
７
７驴？
…””ｊ。｜’ｉ。。。ｊ７。。
ｊｊ
ｊｊ。”｜’１。１７’。，…。Ｌｊ
ｊ？
Ｔ’’ｔ飞：『。’０ｉ强豫
：，
？
７：ｌ
缓
芬
１００００
８０００
黧
搦
霭
驾
■
釜６０００
譬
４０００
震
２０００
Ｏ
兢Ｊ
豳
ｌ。皿。。圈。几。。麓
－
２（２）
查询类型（５种）
３
蕊
级Ｉ
一口■一
｜耄譬｛一幻５｝｛
－。
罔
图４－９五种查询方式的效率对比（ｔ２个数据文件）

武汉理工大学硕士学位论文
从表中可以看出，使用ＳＰＡＲＱＬ查询时，本系统并不是在所有条件下都具有优势，有些查询效率两者相差不多，有的甚至不如关系数据库（如查询３）。通过分析我们发现，在查询语句比较简单，查询条件较少时，本系统并不具备优势。但是在进行复杂查询时，本系统可节省相当多的查询等待时间。而实际应用中复杂查询用的是比较多的。此外，从第二个查询可以看出，查询条件顺序的变化对关系数据库中的查询效率影响很大，能相差出一个数量级，查询效率不稳定。所以总体上来说，使用ＳＰＡＲＱＬ查询时，本系统还是具有相当大的优势的。
４．４大规模数据下本体查询效率
上述测试我们使用的是ＬＵＢＭ（Ｉ，０）作为测试数据，主要测试随着本体规模的增大，本体查询效率在对象数据库和关系数据库中所需时间的趋势对比。但是在超大规模的数据量情况下，对象数据库是否仍具有优势呢？
本节我们选用了ＬＵＢＭ（２０，０）和ＬＵＢＭ（３０，ｏ）作为测试数据，并选用上述的五种ＳＰＡＲＱＬ查询进行测试。
４．４．１
ＬＵＢＭ（２０，ｏ）下本体查询效率
ＬＵＢＭ（２０，０）包含５５６５７２个类实例，２２２４７５０个属性实例，我们在这种数据规模下测试了上述五种查询在ｄｂ４０和ｍｙｓｑｌ中的所用时间，测试结果如表４—８所示。
表４－８ＬＬＩＢＭ（２０，ｏ）Ｔ本体查询效率测试
数据库＼查询方式
Ｄｂ４０
查询１
１６８３０２１６９９８６１６８９１０
查询２
４２８０７４３２５９４３１３４４０７４０６４０５
９１８８５９１８５４９２４４８１７６５３０１７２２７２１７２７４５
查询３
４８３１ｌ４９０７５４８４５１４９７８０４９６０９４８３１９
查询４
５２９３４５３３７６５３８４２１３０５０８１３２７５４１３０９２９
查询５
１２８４２６１２９０４５１２５９２０２６５０９４２６５９０６２６９８２３
ｍｙｓｑｌ
２６８０１２２７２００３２７６１２２

武汉理［大学硕士学位论文
我们取表中测试数据的中间值，绘制成柱状图进行对比，如图４－１０所示。
３０００００
２５００００
２０００００
■
釜１５００００
富
１０００００
一ｂ
一口■一—ｄ皿一Ｚ一协篮一１Ｊ一
５００００
０
２（２）
查询类型（５种）
３
４
图４－１０ＬＵＢＭ（２０，０）查询效率对比
４．４．２
ＬＵＢＭ（３０，Ｏ）下本体查询效率
ＬＬＩＢＭ（３０，０）包含８２３１７０个类实例，３２８４６４２个属性实例，约４００万个三元组，我们同样测试了上述五种查询在ｄｂ４０和ｍｙｓｑｌ中的所用时间，测试结果如表４－９所示。
表４．９ＬＵＢＭ（３０，ｏ）Ｔ本体查询效率测试
数据库＼查询方式
Ｄｂ４０
查询１
２８０３８０２８６６１４２７０１７９
查询２
１４３３０８１５１１２２１３６８６５４５４
‘
查询３
８７９３５９０８９２８９８４６８２６８６７７６０２８４１５５
查询４
１３３０７６１４３８６２１３２７１４１８１０１２１８５５０５１８５０７４
查询５
２０８０９９２０３４３９２３３４０９３９２８９５３９３７１６３８５７５１
２２４０４４２２９４５０
２１糊
２４６３３７２５３４３８２５０５４６
ｍｙｓｑｌ
３５０６３８３４８３８９３４９０８９
４７７４３０
同样，我们将表中数据绘制成柱状图进行更为直观的对比，如图４－１１所示。

武汉理，大学硕士学位论文
４５００００
’ｉｊ
。”ｊ’。
ｊ
。。１
ｏ
：
“
＂Ｉ？
鼍
。９
８
Ｖ一∞”ｉ喁
●
４０００００
３５００００
｝。一
３０００００
ｊ
２５００００
厦
譬２０００００
１５００００
黧
如
圉
一｝一
Ｉ．
—ｄ一ｂ
～口■一ｔ一Ｚ一４§一一Ｏ盟—１‘一
搦
Ｉ
１０００００
５００００
ｌｇ貌。
０
豳
ｔ、
燃
２（２）
：加。＿
３
４
ｒ
‘
搋嗣
５
１．一
荔
查询类型（５种）
图４－１１｜．ＵＢＭ（３０，０）查询效率对比
从图中可以看出，柱状图形状与ＬＵＢＭ（２０，０）测试图相似。通过将这两个柱状图与小规模数据下查询效率图对比，我们可以发现，大部分查询效率ｄｂ４０仍比ｍｙｓｑｌ高很多。且原来小规模查询中不如ｍｙｓｑｌ快的查询，在大规模数据下效率几乎与关系数据库一样（如查询３），所以大规模数据下，对象数据库仍具有很大优势。
４．５实验结论
从以上对测试所得的不同数据规模、不同查询方式的实验数据和柱状图表的分析，我们可以得出以下结论：
在本体的存储方面，本系统在存储不同数据规模下都具有巨大优势，这是因为对象数据库存储本体时不需要将本体拆分为三元组，可以节约相当的写入时间，因此存储效率较关系数据库有很大优势。
．
在本体查询时，使用Ｍｏｄｅｌ接口方法查询时本系统较关系数据库有更好的查询性能，同样是因为取对象数据是，对象数据库中是直接取，而关系数据库需要将数据“组装＂成对象，比较耗时。在使用ＳＰＡＲＱＬ查询时，查询条件简单时，对象数据库优势不明显，甚至低。而复杂查询效率比关系数据库高。这
４０

武汉理．Ｉ：大学硕七学位论文
是因为，在关系数据库中，对某些常用查询建立了索引，查询时直接定位，所以此时比对象数据库耗时少。但应用时所用大部分是复杂查询，所以从整体上统计分析，使用ＳＰＡＲＱＬ查询对象数据库还是比关系数据库效率高的。
所以，对象数据库在本体存储和本体查询上都比传统的关系数据库有较大优势，适合大规模本体的存储。
４．６本章小结
本章主要对对象数据库的本体存储和查询的效率进行了测试，并与关系数据库ｍｙｓｑｌ进行了对比分析。本体存储测试了不同数量级数据规模下的存储效率。本体查询测试了通过Ｍｏｄｅｌ接口方法查询和通过ＳＰＡＲＱＬ查询的效率，且每种查询都选取了多种查询方式全面测试。测试ＳＰＡＲＱＬ查询选用了ＬＵＭＢ（１，０）进行测试。通过对实验结果的分析，证明了本文所提出的基于对象数据库存储本体比关系数据库效率更高，且适合存储大规模本体。
４１

武汉理ｒ大学硕七学位论文
第５章总结与展望
５．１全文的工作总结
本体存储方式是目前语义网领域的研究热点，而本体的存储方式直接影响本体的查询效率。采用何种方式存储本体，以提高对本体的查询效率，是一项具有重要意义和应用价值的研究。目前，本体存储方式主要以关系数据库为主。但由于关系数据库模型与本体对象模型之间的差异巨大，存在“阻抗不匹配＂的问题。本体存储时，需要将本体对象拆分为多个三元组，因此不仅存储效率低，查询效率也受到很大影响。
为解决上述问题，本文提出使用对象数据库来存储本体的方式。由于对象数据库模型和本体的模型存在很多的相似点，因此使用对象数据库存储本体，不仅更直观，且效率更高。本文在本体存储研究中，主要完成以下几个方面的工作：
（１）详细分析了本体模型和对象数据库的特点，并通过一个具体的本体实例描述了本体模型和对象数据库模型的相似点。对基于面向对象数据库存储本体的可行性和高效性进行了研究，从理论上分析了为什么对象数据库在本体存储上具有优势。
（２）基于对象数据库ｄｂ４０，使用Ｊｅｎａ工具包设计并实现了一种专门的本体存储方式。本文选用优秀的开源面向对象数据库ｄｂ４０来实现本体的存储，对本体的各种操作如Ｍｏｄｅｌ创建、数据填充、数据修改都使用标准的Ｊｅｎａ接口。系统设计实现分层模型，将本体持久存储到对象数据库的过程进行了封装，对外通过标准接口，使在对象数据库中操作本体与在内存中操作本体方式上一样，实现了基于面向对象数据库的本体存储方案。
（３）对基于对象数据库的本体存储性能进行了详细测试。本文测试了不同数据规模存入对象数据库的效率，并与关系数据库ｍｙｓｑｌ进行了对比，证明本系统在本体存储上比关系数据库效率高。
（４）对基于对象数据库的本查询效率进行了详细测试。本文选取了多种查询方式对本系统查询效率进行测试，同时在同样条件下测得基于ｍｙｓｑｌ的本
４２

武汉理工大学硕十学位论文
体查询数据，并对二者对比分析，证明本系统在查询上的优越性。
５．２下一步工作展望
本文为提高本体的查询和存储效率进行了研究，提出了使用对象数据库存储本体的新方法，设计并实现了一种存储方式，取得了一定的研究成果。就本系统而言，在未来研究和系统改进方面的工作主要有：
（１）系统设计的三层模式存储还具有一定的耦合性，层次不是很清晰，需要对设计结构进一步优化。
（２）本文实现了本体在对象数据库的存储，但在存储和修改并发性方面还需要做相应工作。各接口方法设计主要考虑效率的问题，还需要考虑同一接口内部方法的线程安全问题。
（３）使用ＳＰＡＲＱＬ查询时，在简单条件查询下，本系统仍存在性能改善空间。在某些ＳＰＡＲＱＬ查询上本系统比关系数据库并不具备优势，这是由于关系数据库中将常用简单查询建立索引或单独建立一个表格存储。因此在对象数据库中也可以考虑创建一些辅助存储类，建立此类与常用查询对象的关联，提高查询效率。
（４）本系统设计使用了Ｊｅｎａ工具包，虽然在方法设计上尽量仿照Ｊｅｎａ接口中的方法，以适应Ｊｅｎａ编程习惯，但由于引入了新的存储类，在某些对本体对象的操作上与原来有些出入，未做到１００％相同。因此，在这方面还需要做进一步的研究。

武汉理，１：人学硕七学位论文
致谢
毕业论文的完成，也意味着自己的研究生生活即将结束。回首这三年，学习生活中的点点滴滴汇入心田，在此我向所有帮助过我的老师、同学和亲人致以衷心的感谢！
首先真诚的感谢我的导师龙毅宏教授，在研究生学习期间，生活上对我们关心照顾，学习工作上悉心指导，治学上又对我们严格要求。他严谨的治学态度、勤奋的工作精神都深深地影响着我，他以实际行动为我们树立了良好的榜样。在平时的科研项目活动中，龙老师深厚的学术功底和敏捷的思维能力常常给我启发，使我在科研能力上有了很大的提高。在毕业论文的撰写过程中，龙老师也给予了我很多的帮助和支持，帮我开拓思路和改进研究方法。再次向我尊敬的导师表示最崇高的敬意和最衷心的感谢！
同时，非常感谢同一实验室的几位师兄弟，感谢他们对我的帮助和关心，与他们的交流使我受益匪浅，极大的丰富了我的知识面，开拓我的思路。正是在实验室这种互助、团结的气氛下，大家才能共同进步。在武汉理工大学的求学期间能遇到他们，是我此生的荣幸。
我还要衷心地感谢我的父母，感谢父母的养育之恩，他们在我这么多年的求学生涯中付出了太多心血。
最后，向各位论文评审老师表示衷心地感谢，谢谢你们提出宝贵意见

武汉理ｊＬ大学硕士学位论文
参考文献
【１】１
ＳｅｍａｎｔｉｃＷｅｂ
Ｓｅｒｖｅｒｓ：Ａｎｅｗａｐｐｒｏａｃｈ
ｔｏ
ｑｕｅｒｙ
０１１
ｂｉｇ
ｄａｔａｓｅｔｓｏｆ
ｍｅｍｄａｔａ【Ｊ】．
ｏｎ
Ｓｏｔｏ－Ｃａｒｒｉ６ｎ，Ｊｅｓｆｉｓ；Ｊｕａｎ，ＯｓｃａｒＳａｎＪｕａｎ；Ｊｏｙａｎｅｓ，Ｌｕｉｓ．ＷＳＥＡＳＣｏｍｐｕｔｅｒｓ，Ｖｏｌｕｍｅ
Ｔｒａｎｓａｃｔｉｏｎｓ
５（２０００，Ｐ．２６５８—２６６２
【２】陈运启，基于本体的语义检索模型研究［Ｄ］，重庆大学硕士学位论文，２００９．１０【３】吴琴霞，赵红丹，基于本体语言ＯＷＬ逻辑语义与推理的研究［Ｊ］，软件导刊２００８．１２：
４９—５６
【４１邓志鸿，唐世渭，张铭，杨冬青，陈捷，Ｏｎｔｏｌｏｇｙ研究综述【Ｊ１，北京大学学报（自然科
学版），２００２＿５：１２％１３１
【５】王乐，张建军，ＯＷＬ本体存储的分析与应用【Ｊ】，科学技术与工程，２００８．７：２４３．２４６【６】６
Ｋｅｖｉｎ
Ｗｉｌｋｉｎｓｏｎ，ＣｒａｉｇＳａｙｅｒｓ，Ｈａｍｍｉ
ＫｕｎｏａｎｄＤａｖｅ
Ｄａｔａ
Ｒｅｙｎｏｌｄｓ，ＥｆｆｉｃｉｅｎｔＲＤＦＳｔｏｒａｇｅ
ａｎｄＲｅｔｒｉｅｖａｌｉｎＪｅｎａ２
ｐ】，ＥｎｔｅｒｐｒｉｓｅＳｙｓｔｅｍｓａｎｄ
ＭａｎａｇｅｍｅｎｔＬａｂｏｒａｔｏｒｙ．Ａ．（１９９４）
Ｐ．３９０－４０１
【７】王功明，关永，赵春江，面向对象数据库的关键技术研究【Ｊ１，微计算机信息，２００６：７９－８３【８】鲍文，面向语义网的本体存储管理研究【Ｄ】，大连海事大学硕士学位论文，２００８．３【９】ＪｅｅｎＢｒｏｅｋｓｔｒａ，Ａｒｊｏｈｎ
Ａｒｃｈｉｔｅｃｔｕｒｅ
ｆｏｒ
Ｋａｍｐｍａｎ，ａｎｄＦｒａｎｋ
ＶａｎＨａｒｍｅｌｅｎ．Ｓｅｓａｍｅ：ＡＧｅｎｅｒｉｃ
ＲＤＦ
Ｓｔｏｒｉｎｇ
ａｎｄ
Ｑｕｅｒｙｉｎｇ
ａｎｄＲＤＦＳｃｈｅｍａ．
ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｒｄｆ．ｏｒｇ／ｄｏｃ／ｐａｐｅｒｓ／Ｓｅｓａｍｅ・ＩＳＷＣ２００２．ｐｄｆ
【１０】任柏青．基于关系数据库的领域本体构建方法的研究与实践【Ｄ】，北京邮电大学硕士学
位论文，２００９．１１
【１１】曹特磊，基于本体的网络信息检索【Ｄ】，北京邮电大学硕士学位论文，２００８．３【１２】李曼，王琰，赵益宇，杜小勇，王珊．基于关系数据库的大规模本体的存储模式研究
【Ｊ】，华中科技大学学报（自然科学版），２００５．１２：１１１—１１３【１３】Ｋｏｂｌｅｒ，Ａ．，Ｎｏｒｒｉｅ，Ｍ．Ｃ：ＯＭＳ
Ｊａｖａ：ＬｅｓｓｏｎｓＬｅａｒｎｅｄｆｒｏｍＢｕｉｌｄｉｎｇ
ｏｆ
ａ
Ｍｕｌｔｉ－ＴｉｅｒＯｂｊｅｃｔ
ＭａｎａｇｅｍｅｎｔＦｒａｍｅｗｏｒｋ．Ｉｎ：ＰｒｏｃｅｅｄｉｎｇｓＷｏｒｋｓｈｏｐ
Ｏｎ
ＪａｖａａｎｄＤａｔａｂａｓｅｓ：Ｐｅｒｓｉｓｔｅｎｃｅ
Ｏｐｔｉｏｎｓ，Ｎｏｖｅｍｂｅｒ２，１９９９，Ｄｅｎｖｅｒ，ＣＯ，ＵＳＡ．（１９９９）
【１４】汤庸，叶小平等．高级数据库技术［ＭＩ．北京：高等教育出版社，２００５：２７６－２７９ｆ１５】季维岩，面向对象数据库及其实现方法研究ｆＪ】，科学技术与工程，２００４．１：１１９．１３１１１６】叶小平，
汤庸，
汤娜等，数据库系统基础教程【Ｍ】，清华大学出版社，２００７：３４３．３５１
【１７】史晓峰，林和平，面向对象数据库及其对象查询处理的研究【Ｊ】，长春工程学院学报（自
然科学版），２００５：１５１．１６０

本文来源：https://www.2haoxitong.net/k/doc/cb44c42de2bd960590c677ac.html

《面向对象数据库在本体存储中的应用研究.doc》
将本文的Word文档下载到电脑，方便收藏和打印
推荐度：
点击下载文档

文档为doc格式
相
关
案
例

相关推荐

推荐内容

收银员工作总结范文8篇(1) 2014年云南省西双版纳公务员考试模拟练习 一年级看图写话：小羊过河(精选三篇) 关于现代汽车维修技术的现状及发展探讨 安徽省宿州市十三校12-13学年高一上学期期中考试英语试题 领导干部公选考试的命题规律和应试技巧 岩石力学试题A 2010年营销师秘书证考试培训教材 桂林夕阳红养老中心2014年中秋节活动策划( “八大习惯”养成教育工作总结
网站内容来自网络，如有侵权请联系我们，立即删除！ Copyright © 范文写作网京ICP备16605803号