一种基于本体的城市交通异构数据集成系统及方法

摘要

本发明涉及一种基于本体的城市交通异构数据集成系统及方法，能够解决城市交通领域数据中的多种语法、语义、系统异构问题，提高数据处理工作效率。该系统由个模块组成：查询分解模块、本体与数据库映射模块、子查询生成模块、结果合并模块和包装器模块。所述方法利用本体，通过建立数据库表、字段与本体概念、属性之间的映射，实现对城市交通领域的常规以及特殊数据的管理，在进行数据集成的同时解决其中的异构问题。本发明充分考虑了城市交通领域数据相较其他领域数据的特有特征，解决了普适方法所不能解决的城市交通领域数据异构问题，从而为数据处理人员提供统一的数据查询接口，提高数据处理效率。

权利要求

1.一种基于本体的城市交通异构数据集成系统，其特征在于：包括本体与数据库映射模块、查询分解模块、子查询生成模块、包装器模块及查询结果合并模块，其中，查询分解模块、子查询生成模块、查询结果合并模块组成了数据集成系统的中介器；

本体与数据库映射模块：负责全局查询中涉及的城市交通本体概念和属性至数据库表和字段的映射解析；所述本体与数据库映射模块中包括两个文件，即描述城市交通领域知识全局本体、数据源与全局本体间的映射规则文件；所述城市交通领域知识全局本体描述了交通领域内的概念与概念之间的关系，同时概念中也包含了一些描述概念特征的属性，所述属性为用户编写全局查询语句时所参照的规范词语表；所述映射规则文件记录了各城市交通数据源的数据库表和字段与全局本体概念和属性之间的对应关系；输入查询中涉及的本体概念和属性，通过查询存储在所述映射规则文件中的数据源与全局本体间映射规则，向查询分解模块返回与本次查询相关的数据源、数据库表和字段名称；

查询分解模块：使用的全局查询语言基于SQL语言改编而来，为了处理城市交通异构数据中的轨迹数据、多种特殊情况添加针对轨迹数据的表映射函数以及格式转换函数；用户使用所述语言编写全局查询语句，查询分解模块通过对用户输入的全局查询语句进行解析，确定本次查询需要访问的数据源、数据库表和字段，解析过程通过建立查询树进行，查询树分别记录了全局查询语句中的概念、属性及本次查询所涉及的数据库表和字段；查询树建立的步骤为：首先对全局查询语句中的select、from、where三个子句进行解析，提取三个子句中涉及的本体概念和属性、表映射函数以及属性格式转换函数，然后从根节点开始逐层向下建立查询树，通过不断的调用本体与数据库映射模块解析查询语句中涉及的本体概念和属性所对应的数据库表和字段，完成查询树的建立；本模块可通过系统的外部接口调用，此时需要传入全局查询语句作为参数；用户也可以在查询界面的文本框内输入查询语句进行查询；

子查询生成模块：根据查询分解模块生成的查询树，生成针对各交通数据源的子查询，为各数据源对应的包装器模块提供一次查询所需的全部信息；遍历查询树，提取本次查询涉及到的所有数据源，同时读取系统中包含的数据源配置文件中相应的信息，为所有涉及到的数据源生成一个包括子查询语句、数据源种类、数据库连接配置信息多种信息在内的子查询，并将该子查询发往包装器模块执行；

包装器模块：每个数据源都有相应的包装器模块，从子查询生成模块接收到子查询后，通过子查询的转换、子查询执行和格式转换三个步骤得到子查询所指定的数据，并将该数据返回至查询结果合并模块进行连接，根据所对应的数据源种类的不同，不同数据源所对应的包装器模块分为SQL类包装器模块和非SQL类包装器模块两种，SQL类包装器模块首先需要将子查询转化成数据源能够直接执行的代码，然后读取子查询中的数据源连接配置信息，与数据源建立连接并执行查询，从而解决数据源系统异构问题，当数据源返回查询结果时，首先由各包装器模块根据子查询中的格式转换函数将来自数据源的结果进行格式转换，从而解决格式异构的问题，非SQL类包装器模块和SQL类包装器模块的工作过程基本相同，但在子查询转换步骤，非SQL类包装器模块只需解析子查询，不必生成数据源能够直接执行的代码；

查询结果合并模块：收集各包装器模块发来的查询结果，并根据子查询之间的关系类别进行结果合并；该模块根据全局查询种类的不同，选择不同的策略进行结果合并，查询种类分为单概念查询、多概念查询，单概念查询又分为全部绑定和部分绑定两种情况：单概念全部绑定即全局查询语句的from子句中仅包含一个概念，且在根据映射规则使用数据库表和字段进行全局查询语句的概念和属性名称替换时，每一个属性都能找到其映射的数据库字段；部分绑定即在根据映射规则使用数据库表和字段进行全局查询语句的概念和属性名称替换时，至少有一个属性无法找到其映射的数据库字段，因此需要从描述同一批实体的其他数据源中获得这些字段；多概念查询即from子句中包含了多个概念的查询；在全局查询为单概念查询的情况下，对于全部绑定的子查询，简单的对多个结果集进行并操作得到一个新的结果集；对于部分绑定，需要对多个结果集进行连接操作，并去除其中的多余相交字段，从而获得最终结果集；在全局查询为多概念查询的情况下，需要首先对属于同概念的子查询进行全部或部分绑定的结果合并，再对不同概念的已合并结果进行再次合并，得到最终结果集；当调用本系统的外部接口进行查询时，最终结果集将会以list对象的方式返回给用户，用户也可以通过图形化的查询界面进行查询，此时查询结果将会以可视化表格的形式呈现给用户。

2.一种基于本体的城市交通异构数据集成方法，其特征在于：实现步骤如下：

(1)查询分解：将全局查询语句的select、from、where三个子句成分进行分解，建立描述本次查询结构的查询树，同时将三个子句中涉及的全局本体概念和属性通过查询映射规则文件中的本体-数据库映射解析为数据库的表和字段；

(2)子查询生成：根据查询分解模块生成的查询树，生成针对各交通数据源的子查询，为各数据源对应的包装器模块提供一次查询所需的全部信息；遍历查询树，提取本次查询涉及到的所有数据源，同时读取系统中包含的数据源配置文件中相应的信息，为所有涉及到的数据源生成一个包括子查询语句、数据源种类、数据库连接配置信息多种信息在内的子查询，并将该子查询发往包装器模块执行；

(3)包装器子查询执行：通过子查询的转换、子查询执行和格式转换三个步骤得到各子查询所指定的数据，并将该数据返回至中介器的查询结果合并模块进行连接；

对于SQL类包装器模块，首先需要将子查询转化成数据源能够直接执行的SQL语句，然后与数据源建立连接并执行查询，在进行子查询转化时已将部分格式转换函数嵌入SQL代码中，由数据库来完成较为简单的数据格式转换，当数据源返回查询结果时，首先由各包装器模块根据子查询中的格式转换函数完成剩余的格式转换工作，从而解决格式异构的问题；

对于非SQL类包装器模块，其与SQL类包装器模块的工作过程基本相同，但在子查询转换步骤，非SQL类包装器模块只需解析子查询，不必生成数据源能够直接执行的代码；除此之外，格式转换函数的执行将全部在格式转换步骤完成；

(4)查询结果合并：根据查询分解的不同结果，完成对单概念全部绑定、单概念部分绑定、多概念查询三种情况下的结果合并任务，对于单概念全部绑定的结果合并，可以通过对所有查询结果集进行集合的并操作完成，对于单概念部分绑定的结果合并，需要对多个数据源信息交叉合并，即需要对多个数据集求笛卡尔积以获得最终的合并结果集；对于多概念查询，当查询仅涉及到多概念数据集之间的交叉操作时，只需对上述多个数据集求笛卡尔积；当多概念查询中夹杂了部分绑定时，应该首先对属于同概念的子查询进行部分绑定的结果合并，再对不同概念的已合并结果进行合并；

(5)返回查询结果：采取和全局查询语句输入相应的形式，将查询结果返回至用户。

说明书

一种基于本体的城市交通异构数据集成系统及方法

技术领域

[0001] 本发明涉及一种基于本体的城市交通异构数据集成系统及方法，属于数据库/数据集成领域。

背景技术

[0002] 为解决数据源之间的异构问题，迄今为止国内外研究者已进行了大量数据集成的研究工作。目前具有应用价值且处于主流地位的数据集成系统架构主要分为两类：ETL架构和中间件架构。

[0003] ETL架构的数据处理过程主要分为三步：Extract(抽取)、Transform(转换)、Loading(加载)。在抽取步骤中，系统将数据从各数据源中读取出来。在转换步骤中，为了使数据能够在语法上和目标数据仓库表中的模式一致，根据事先定义的转换规则，数据将会被进行统一的转换。在加载步骤中，在上一步结果会被导入到目标数据源中。为了去除噪声和不一致，在抽取数据后通常会对数据进行清洗。由于ETL架构事先将异构数据统一进行转换并存储到数据仓库中，用户将会基于转换后的数据进行查询。因此对于一些更新较快的数据，数据仓库可能无法为用户提供最新的数据版本。因此ETL架构并不适用于更新较快的数据。但是对于很少变动的数据，ETL架构采用的事先转换的策略能够减少系统响应查询的时间，相比中间件架构效率更高。

[0004] 中间件架构通过建立一个全局视图，将用户的查询分解、转化成针对不同数据源的查询，然后将数据源返回数据合并与转化，并将结果返回。用户通过应用程序向数据集成系统发起查询，中间件首先根据全局模式将查询结果分解成针对多个数据源的子查询，包装器模块收到子查询后转换成数据源能够直接执行的代码。数据源将数据返回时，包装器模块根据映射中的要求进行数据格式转换，中介器再将来自不同数据源的查询结果进行合并，并最终返回至用户。中间件架构中个重要的模块为：映射模块、查询分解模块以及结果返回模块。各数据源和全局视图间的映射关系通过映射模块进行存储；查询分解能够分解全局查询，并生成多个子查询；结果返回过程将数据源反馈的结果转换成统一的形式并返回。中间件架构在收到用户查询时才进行相应数据的转换，因此可以保证数据的实时性。但是由于每一次查询都需要对数据进行一次转换，因此系统响应时间相对较长。

[0005] 中间件架构中的模式有多种实现。由于本体能够对不清晰以及隐藏的知识进行说明，它采用本体作为模式能够很好的解决语义异构的问题。迄今为止已有众多研究者在设计数据源集成系统时引入本体，通过引入规范的领域知识加强数据源管理中语义信息的识别和建立，在提高语义互操作性方面有很好的效果。

[0006] 目前在交通领域已有大量基于上述架构的数据集成系统，但这些系统使用的方法适用于各个领域的常规数据集成管理，在设计时并没有考虑到城市交通数据相较其他领域数据的一些特有特征(如轨迹数据的时空特性等)，无法完成城市交通数据的管理、查询等任务。

发明内容

[0007] 本发明技术解决问题：克服现有技术的不足，提供一种基于本体的城市交通异构数据集成系统及方法。该系统及方法针对城市交通领域数据的特异性，在基于本体的中间件数据集成架构的基础上进行了改进与扩充，形成了一种基于本体的城市交通异构数据集成系统。该系统可对城市交通领域的一些非常规数据(例如轨迹数据)进行集成管理以及查询，减少城市交通的数据处理底层工作，从而提高数据挖掘工作的效率。

[0008] 本发明技术解决方案：一种基于本体的城市交通异构数据集成系统，包括：本体与数据库映射模块、子查询分解模块、查询生成模块、查询结果合并模块以及包装器模块。其中，查询分解模块、子查询生成模块、查询结果合并模块组成了数据集成系统的中介器。

[0009] 本体与数据库映射模块：负责全局查询中涉及的城市交通本体概念和属性至数据库表和字段的映射解析；该模块中包括两个文件，即描述城市交通领域知识全局本体、数据源与全局本体间的映射规则文件；其中城市交通领域知识全局本体描述了交通领域内的概念与概念之间的关系，同时概念中也包含了一些描述其特征的属性，是用户编写全局查询语句时所参照的规范词语表；映射规则文件中记录了系统中各城市交通数据源的数据库表和字段与全局本体概念和属性之间的对应关系；输入查询中涉及的本体概念和属性，通过查询存储在映射规则文件中的数据源与全局本体间映射规则，向查询分解模块返回与本次查询相关的数据源、数据库表和字段名称；

[0010] 查询分解模块：系统使用的全局查询语言基于SQL语言改编而来，为了处理城市交通异构数据中的轨迹数据、多种特殊情况添加了针对轨迹数据的表映射函数以及格式转换函数；用户使用上述语言编写全局查询语句，查询分解模块通过对用户输入的全局查询语句进行解析，确定本次查询需要访问的数据源、数据库表和字段，解析过程通过建立查询树进行，查询树分别记录了全局查询语句中的概念、属性及本次查询所涉及的数据库表和字段；查询树建立的步骤为：首先对全局查询语句中的select、from、where三个子句进行解析，提取三个子句中涉及的本体概念和属性、表映射函数以及属性格式转换函数，然后从根节点开始逐层向下建立查询树，通过不断的调用本体与数据库映射模块解析查询语句中涉及的本体概念和属性所对应的数据库表和字段，完成查询树的建立；本模块可通过系统的外部接口调用，此时需要传入全局查询语句作为参数；用户也可以在查询界面的文本框内输入查询语句进行查询；

[0011] 子查询生成模块：根据查询分解模块生成的查询树，生成针对各交通数据源的子查询，为各数据源对应的包装器模块提供一次查询所需的全部信息；遍历查询树，提取本次查询涉及到的所有数据源，同时读取系统中包含的数据源配置文件(该文件保存了系统现有数据源的连接方式、数据内容简介等内容)中相应的信息，为所有涉及到的数据源生成一个包括子查询语句、数据源种类、数据库连接配置信息多种信息在内的子查询，并将该子查询发往包装器模块执行；

[0012] 包装器模块：系统中每个数据源都有相应的包装器模块，从子查询生成模块接收到子查询后，通过子查询的转换、子查询执行和格式转换三个步骤得到子查询所指定的数据，并将该数据返回至查询结果合并模块进行连接，根据所对应的数据源种类(MySQL、HBase、HDFS、Hive等SQL或NoSQL数据源)的不同，不同数据源所对应的包装器模块分为SQL类包装器模块和非SQL类包装器模块两种，SQL类包装器模块首先需要将子查询转化成数据源能够直接执行的代码，然后读取子查询中的数据源连接配置信息，与数据源建立连接并执行查询，从而解决数据源系统异构问题，当数据源返回查询结果时，首先由各包装器模块根据子查询中的格式转换函数将来自数据源的结果进行格式转换，从而解决格式异构的问题，非SQL类包装器模块和SQL类包装器模块的工作过程基本相同，但在子查询转换步骤，非SQL类包装器模块只需解析子查询，不必生成数据源能够直接执行的代码；

[0013] 查询结果合并模块：收集各包装器模块发来的查询结果，并根据子查询之间的关系类别进行结果合并；该模块根据全局查询种类的不同，选择不同的策略进行结果合并，查询种类分为单概念查询、多概念查询，单概念查询又分为全部绑定和部分绑定两种情况：单概念全部绑定即全局查询语句的from子句中仅包含一个概念，且在根据映射规则使用数据库表和字段进行全局查询语句的概念和属性名称替换时，每一个属性都能找到其映射的数据库字段；部分绑定即在根据映射规则使用数据库表和字段进行全局查询语句的概念和属性名称替换时，至少有一个属性无法找到其映射的数据库字段，因此需要从描述同一批实体的其他数据源中获得这些字段；多概念查询即from子句中包含了多个概念的查询；在全局查询为单概念查询的情况下，对于全部绑定的子查询，简单的对多个结果集进行并操作得到一个新的结果集；对于部分绑定，需要对多个结果集进行连接操作，并去除其中的多余相交字段，从而获得最终结果集；在全局查询为多概念查询的情况下，需要首先对属于同概念的子查询进行全部或部分绑定的结果合并，再对不同概念的已合并结果进行再次合并，得到最终结果集；当调用本系统的外部接口进行查询时，最终结果集将会以list对象的方式返回给用户，用户也可以通过图形化的查询界面进行查询，此时查询结果将会以可视化表格的形式呈现给用户。

[0014] 一种基于本体的城市交通异构数据集成方法，实现步骤为：

[0015] (1)查询分解：将全局查询语句的select、from、where三个子句成分进行分解，建立描述本次查询结构的查询树，同时将三个子句中涉及的全局本体概念和属性通过查询映射规则文件中的本体-数据库映射解析为数据库的表和字段；

[0016] (2)子查询生成：根据查询分解模块生成的查询树，生成针对各交通数据源的子查询，为各数据源对应的包装器模块提供一次查询所需的全部信息；遍历查询树，提取本次查询涉及到的所有数据源，同时读取系统中包含的数据源配置文件中相应的信息，为所有涉及到的数据源生成一个包括子查询语句、数据源种类、数据库连接配置信息多种信息在内的子查询，并将该子查询发往包装器模块执行；

[0017] (3)包装器子查询执行：通过子查询的转换、子查询执行和格式转换三个步骤得到各子查询所指定的数据，并将该数据返回至中介器的查询结果合并模块进行连接；

[0018] 对于SQL类包装器模块，首先需要将子查询转化成数据源能够直接执行的SQL语句，然后与数据源建立连接并执行查询，在进行子查询转化时已将部分格式转换函数嵌入SQL代码中，由数据库来完成较为简单的数据格式转换，当数据源返回查询结果时，首先由各包装器模块根据子查询中的格式转换函数完成剩余的格式转换工作，从而解决格式异构的问题；

[0019] 对于非SQL类包装器模块，其与SQL类包装器模块的工作过程基本相同，但在子查询转换步骤，非SQL类包装器模块只需解析子查询，不必生成数据源能够直接执行的代码；除此之外，格式转换函数的执行将全部在格式转换步骤完成；

[0020] (4)查询结果合并：根据查询分解的不同结果，完成对单概念全部绑定、单概念部分绑定、多概念查询三种情况下的结果合并任务，对于单概念全部绑定的结果合并，可以通过对所有查询结果集进行集合的并操作完成，对于单概念部分绑定的结果合并，需要对多个数据源信息交叉合并，即需要对多个数据集求笛卡尔积以获得最终的合并结果集；对于多概念查询，当查询仅涉及到多概念数据集之间的交叉操作时，只需对上述多个数据集求笛卡尔积；当多概念查询中夹杂了部分绑定时，应该首先对属于同概念的子查询进行部分绑定的结果合并，再对不同概念的已合并结果进行合并；

[0021] (5)返回查询结果：采取和全局查询语句输入相应的形式，将查询结果返回至用户。

[0022] 本发明与现有技术相比的优点在于：

[0023] (1)本发明是针对城市交通领域的数据集成系统，能够处理现有系统无法处理的城市交通领域的特殊数据；

[0024] (2)本发明的数据查询使用了一种类似于SQL的查询语言，该语言根据城市交通领域的特有数据特征进行了一些修改，大致语法和SQL类似，系统的使用人员可以不需要过多的学习成本就能够直接使用系统；

[0025] (3)本发明通过在数据库与本体映射文件中写入数据格式转换函数来规定每次查询时数据源的结果以何种格式返回至用户，帮助用户解决了数据分析中各数据源格式不一致的问题。

附图说明

[0026] 图1是本发明组成模块框图；

[0027] 图2是数据库与本体映射文件的片段；

[0028] 图3是数据库配置信息文件的片段；

[0029] 图4是系统所使用的城市交通本体示意图；

[0030] 图5是系统所使用的城市交通本体中所包含的所有概念和属性的列表；

[0031] 图6是查询树结构示意图，其中OntClass为本体类，DBTable表示其父节点(一个OntClass)在数据库中所映射的表；OntProperty为一次查询中其祖父节点(一个OntClass)所对应的属性，DBAtrribute为其父节点(一个OntProperty)在数据库中所映射的字段；

[0032] 图7是查询树节点的数据结构组成；

[0033] 图8是子查询的数据结构组成。

具体实施方式

[0034] 为了使本发明的目的、技术方案和发明优势更加清楚明白，以下对本发明的实施方式做具体介绍。

[0035] 如图1所示，本发明包括本体与数据库映射模块、查询分解模块、子查询生成模块、查询结果合并模块以及包装器模块；其中，本体与数据库映射模块、子查询分解模块、查询生成模块、查询结果合并模块属于系统中介器。各模块的详细设计与实现过程如下：

[0036] 1.本体与数据库映射模块

[0037] 本体与数据库映射模块由查询分解模块调用，通过查询映射规则文件和数据库配置信息文件，将全局查询中的本体概念映射到数据库上。该模块的输入参数为本体的概念和属性或表映射函数参数。其中，表映射函数是本系统使用的查询语言为了解决城市交通异构数据的复杂查询情况所内嵌的一种映射函数，它能够通过函数参数，找到某个概念所映射的多个表中的一个。这类概念和表的映射通常很难建立，例如“轨迹”概念，每一个这样的概念都有一个特定的表映射函数。本模块使用了映射规则文件和、数据库配置信息文件和全局本体。映射规则文件示例如图2所示，上半部分为映射规则文件，其中左侧为数据源中的表和字段(即sr6为数据源名称，Trajectory为表名，time、lon、lat、companyID、taxiID等为字段)，右侧为本体中的属性；下半部分为数据库中的数据存储情况，其中左侧为数据库，轨迹(Trajectory)表中存储了time(时间)、lon(经度)、lat(纬度)、companyID(公司ID)、taxiID(出租车ID)等多个字段，右侧为上述字段所映射的本体内容。数据库配置信息文件的嵌套内容如图3所示，其中每一个sr标签对表示了一个数据源，一个数据源包含数据源名称(name)、数据源类型(type)、数据源url(url)、连接用户名(username)和连接密码(password)等信息。全局本体描述了城市交通领域的业务逻辑，它是基于数据库建立的，而并非仅仅从该领域的业务中提取而成。该城市交通本体的出租车业务部分如图4所示，其中主要包含轨迹点(TrajectoryDot)、出租车(Taxi)、位置点(Point)等多个重要概念及其属性，概念和属性的详细列表如图5所示，其中第一列为概念，第二列为该概念所对应的属性。

[0038] 当模块输入参数为本体的概念和属性时，模块处理过程如下：

[0039] 步骤1：读取全局本体，确定参数是否有效，即确定本体中是否存在输入的本体概念及属性；

[0040] 步骤2：读取映射规则文件，查找是否含有本体部分与“概念.属性”内容匹配的相关映射规则；

[0041] 步骤3：如果有相关的映射规则，返回映射规则的数据库部分，返回内容形式为“数据源.字段”；如果没有相关映射，则提示不存在相关数据源。

[0042] 当模块输入参数为表映射函数时，模块处理过程如下：

[0043] 步骤1：校验每个表映射函数参数，检查其是否合法；

[0044] 步骤2：读取表映射函数所对应的概念特定的数据源配置文件，在其中寻找是否有符合条件的数据源；

[0045] 步骤3：如果有相关的数据源，则返回数据源的所有相关信息，如数据源名称、表名称等；如果没有相关的数据源，则提示相关数据源不存在。

[0046] 2.查询分解模块

[0047] 查询分解模块通过解析全局查询语句、构建查询树，解析全局查询中所涉及的所有数据源及其内容。具体步骤为：

[0048] 步骤1：分析全局查询语句的各语法成分，将其select、from和where子句分解并将其中的元素分别存放到三个队列中；

[0049] 步骤2：构造查询树：遍历三个子句队列的内容，通过不断调用本体与数据库映射模块，将本体中的概念和属性映射到一个或多个数据库表和字段上。

[0050] 查询树的结构如图6所示，其中包含五种节点，分别是Root(根节点)、OntClass(本体类)、DBTable(数据库表)、OntProperty(本体属性)和DBAttribute(数据库字段)。查询树分五层，分别记录了与全局查询中的概念、属性以及一次查询所涉及的数据源和数据源字段。查询树的结构如下：树的根节点内容为空；第二层为本体的类，即from子句中的各组成成分；第三层为根据映射规则解析得到的数据库表，由于一个概念可能对应了不同数据源的多个表，因此一个本体概念节点可能会有多个数据库表子节点；第四层为本体的属性，即select子句中的各成分，本体属性节点是某一数据源表的子节点即表明该表能够返回相应的字段值；第五层为一个本体属性根据映射规则解析所得到的数据库表的字段，和本体的类的情况相同，由于一个本体属性可能会映射到不同数据源中的字段，所以它可能有多个子节点。查询树的数据结构如图7所示，其中，name字符串是节点的名字，即该节点所代表的对象的名称。bindname变量存储了节点的绑定名称，该名称直接指向了一个数据库表；bindname字段主要为了存储表映射函数所得出的数据库表名，对于存储对象不是表映射函数的节点，该属性的值和name属性相同。type字符串存储了该节点的类型，第二层节点的type类型视节点存储的对象是映射函数还是本体概念值可能为Function或Concept，第三层节点的type值为Table，第四层节点type值为Property，第五层节点type值为Attribute。
source变量指出了该节点存储的对象来自于哪一个子句，其值可能包括select、from和where三种。children列表存储了该节点的所有子节点。super变量存储了节点的父节点。
joinRelationList列表仅在进行包含多个概念的查询中有效，它记录了两个概念所对应的数据库表的连接键。info字符串记录了一些节点的额外信息，在第三层节点中存储其父节点概念的键值；在第五层存储对象来自where子句的节点(type值为where)中，info变量存储了where元素的值，否则值为空。

[0051] 上述变量描述仅适用于第二至五层节点，第一层节点(即根节点)仅起到了存储第二层节点的位置、提供树的访问入口的作用，并不存储其他实际信息。因此除了type变量的值为Root外，其他成员的值均为null。

[0052] 查询树的构造步骤如下：

[0053] 步骤1：建立根节点，除了type成员值为root，其他成员的值均为空。

[0054] 步骤2：逐个读取from队列中的元素，如果为本体概念，则直接生成节点加入根节点的子节点列表中，节点的name成员和bindname成员均赋值为本体概念名称；如果为表映射函数，则将函数名称作为节点name和bindname成员的值，生成节点后加入根节点的子节点队列中。该层(第二层)节点的source类型为“from”，表示与from子句有关。除此之外还需从映射规则文件中读取本体概念以及表映射函数中的概念的键，并存放在节点的info变量中。

[0055] 步骤3：对于第二层的每一个节点(本体类或表映射函数)，根据name属性的值查找映射文件中所映射的数据源或直接执行映射函数，为查找到的相关数据库表生成节点并加入上述第二层节点的子节点列表中，形成第三层节点。对于父节点为本体类的第三层节点，直接将所映射的数据库表名称作为name属性和bindname属性的值；对于父节点为映射函数的节点，映射规则中所对应的数据库表名称为映射函数所映射的一类表的名称，它的格式为“数据源+概念名”，例如sr1_Trajectory，将该名称赋给name变量。对于bindname变量的值，需要将映射内容中的概念名称替换为实际的数据库表，其值的格式为datasource_tablename，例如sr1_20120101。该层(第三层)节点的source类型为“from”。

[0056] 步骤4：对于每一个第三层的节点a(存储了数据源、数据库表名称)，根据a的name变量值逐个读取select队列的元素b并在映射文件中查找是否有有关的映射规则(即名称形如[a.name].b的数据属性，其中a.name既包含了数据源名称也包含了表名称)，若有则生成一个第四层节点并将其加入a的子节点队列中，name和bindname变量值均为select队列元素b的名称。select队列中的元素形式可能为“Concept.Property”，即指定了属性的来源，此时需要判断该元素的Concept值是否和第三层节点a的name一致，若一致则按上述方法生成节点，若不一致则继续进行下一个select队列元素的解析。在这一步骤中生成的该层(第四层)节点的source类型为“select”，表示与select子句有关。

[0057] 步骤5：对于每一个第三层的元素a，根据a的name属性逐个读取where队列的元素b并判断是否为多概念查询的连接键指定语句(连接键指定语句的形式如Concept1.Property1＝Concept2.Property2)，该类语句的特征为等号右侧包含“.”字符且以英文字母开头。如果是连接键指定语句，则需要根据该连接关系生成连接关系三元组并放入第三层元素的joinRelationList列表中，并进行下一个where队列元素b的解析。否则，根据b表达式左侧的本体属性查找是否有有关的映射规则。若有则生成一个第四层节点并将其加入子节点队列中，name和bindname属性均为where队列元素b的名称，并将整个表达式赋给info属性。where队列中的元素形式也可能为“Concept.Property”，此时需要判断该where元素的Concept是否和a的name变量一致，若一致则按上述方法生成节点，若不一致则继续进行下一个where队列元素的解析。在这一步骤中生成的该层(第四层)节点的source类型为“where”，表示与where子句有关。

[0058] 步骤6：对于每一个第四层的节点，根据其name变量的值查找有关的映射规则(和上一步中的一样)并生成一个第五层节点节点加入子节点队列中，其中name和bindname变量的值即为映射内容(例如sr1_taxiInfo.taxiID)。对于祖父节点(位于第二层的相关节点)为表映射函数的节点，name变量值为映射内容中的数据源表属性，但在bindname中的需将映射内容中的数据表名称换成映射后得到的表名称(例如sr3_20120101.taxiID)。source属性的值继承自父节点，若source值为where，则该节点需要从父节点处继承info变量的值，即约束查询结果的表达式，对于表映射函数的子节点，还需要将父节点info值中的概念替换成实际表名称。

[0059] 3.子查询生成模块

[0060] 子查询由全局查询分解而来，它包含了包装器模块进行一次查询所需要的全部信息。子查询的数据结构如图8所示。通过对查询分解模块生成的查询树进行遍历，子查询生成模块能够生成一次全局查询分解出的所有子查询。根据查询分解的规则，每一个第三层节点(代表一个数据库表)将会对应一个子查询，因此一个子查询中仅包含一个概念，但可能包含多个属性。字符串数组select、where以及from字符串分别存储子查询语句中三个相应子句所包含的元素。subQueryString是子查询语句，sourceNum存储了数据源的编号。sourceType指出了数据源的种类，其值包括MySQL、SQLServer和Oracle等等。
connectionString、userName和password分别存储了数据库连接时使用的连接字符串、用户名和密码。字符串数组key存储了子查询所对应的概念的键，一个概念的键可能由多个属性组成，可从本体相应概念的key标注属性中得到。

[0061] 步骤具体如下：

[0062] 步骤1：获取查询树第三层元素，对于每一个第三层元素，初始化一个SubQuery结构。

[0063] 步骤2：生成from子句。对于每一个第三层元素，将bindname属性的值赋给from属性。

[0064] 步骤3：生成select和where子句。对于每一个第三层元素，查找它子节点的子节点(即为该元素间接子类的第五层元素)。对这些位于第五层的相关节点逐个进行判断，若source属性为select，则将bindname属性值加入select队列中；若source属性为where，则将info属性值加入where队列中。

[0065] 步骤4：根据select、where、from子句中的元素内容组合查询字符串。

[0066] 步骤5：从from子句中截取SourceName，据此从数据源配置信息文件中找到数据源类型(sourceType)、连接字符串(connectionString)、数据库连接的用户名(userName)和密码(password)信息。

[0067] 生成的所有子查询将会被发往相应的包装器模块，由包装器模块根据其中的信息从数据库中获取所需要的数据。

[0068] 4.查询结果合并模块

[0069] 查询结果合并模块负责将各数据源包装器模块返回的查询结果进行合并，最终形成一个完整的查询结果数据集。根据查询的种类不同，可将查询结果合并分为三种：单概念全部绑定查询的结果合并、单概念部分绑定查询的结果合并和多概念查询的结果合并。

[0070] 单概念全部绑定即全局查询语句的from子句中仅包含一个概念，且在根据映射规则使用数据库表和字段进行全局查询语句的概念和属性名称替换时，每一个属性都能找到其映射的数据库字段。单概念全部绑定查询的结果合并可以通过对所有查询结果集进行集合的并操作完成。

[0071] 单概念部分绑定即全局查询语句的from子句中仅包含一个概念，且在根据映射规则使用数据库表和字段进行全局查询语句的概念和属性名称替换时，至少有一个属性无法找到其映射的数据库字段，因此需要从描述同一批实体的其他数据源中获得这些字段。单概念部分绑定查询的结果合并涉及到多个数据源信息的交叉合并，即需要对多个数据集求笛卡尔积以获得最终的合并结果集，这个过程类似于SQL的join操作。

[0072] 多概念查询即from子句中包含了多个概念的查询。这类查询可能仅涉及到多个概念数据集之间的交叉操作，同时也可能包含了部分绑定的查询情况。当查询仅涉及到多概念数据集之间的交叉操作时，只需对上述多个数据集求笛卡尔积；当多概念查询中夹杂了部分绑定时，应该首先对属于同概念的子查询进行部分绑定的结果合并，再对不同概念的已合并结果进行合并。

[0073] 查询合并模块的处理过程如下：

[0074] 步骤1：收集来自包装器模块的数据集，如果仅有一个数据集，则不需要进行合并，直接跳至步骤3；如果有多个数据集，则进入步骤2；

[0075] 步骤2：根据查询分解模块生成的本次查询的查询树判断多个数据集之间的查询关系，执行全部绑定查询、部分绑定查询或多概念查询的结果合并过程；

[0076] 步骤3：将查询结果通过接口或界面的方式返回至用户。

[0077] 5.包装器模块

[0078] 包装器模块负责将中介器发来的子查询进行进一步的处理，从数据库中获取相应的数据并进行格式的转化。包装器模块分为SQL类包装器模块和非SQL类包装器模块两类。其中SQL类包装器模块是为能够使用SQL语言查询的数据源所设计的包装器模块；非SQL类包装器模块是HBase、HDFS等不能用SQL进行查询的NoSQL数据源的专用包装器模块。包装器模块的处理过程部分主要分三步：子查询转换、子查询执行和格式转换。

[0079] SQL类包装器模块的处理过程如下：

[0080] 步骤1：子查询转换。首先去除子查询中各成分含有的冗余数据源信息，然后解析并存储全局查询中的格式转换函数，最后根据上述信息组合出数据源能够直接执行的SQL语句。对于全局查询语言中规定的多种格式转换函数，一部分可转换成SQL的内嵌函数，由数据库直接进行格式转换；部分数据库无法处理的格式转换则由包装器模块自身完成。

[0081] 步骤2：子查询执行。根据子查询中数据源的配置信息连接数据源，执行SQL查询语句。

[0082] 步骤3：格式转换。接收步骤2中数据源发来的查询结果，对于步骤1中SQL语句无法处理的格式转换，需在该步调用包装器模块内置的格式转换函数完成转换过程。

[0083] 步骤4：将上述结果返回至中介器的结果合并模块。

[0084] 非SQL类包装器模块的处理过程如下：

[0085] 步骤1：子查询转换。和SQL类包装器模块的处理过程类似，需要进行子查询冗余数据源信息的去除以及格式转换函数的解析，但不需要生成SQL语句，只需保存解析的结果。

[0086] 步骤2：子查询执行。根据解析结果执行查询，获得相关数据，这一步的具体过程和数据源类型相关，HBase、HDFS数据源的子查询执行过程不同，但查询结果都会保存在内存中。

[0087] 步骤3：格式转换。调用非SQL类包装器模块中的内置函数，将查询结果根据步骤1的解析结果进行转换。

[0088] 步骤4：将上述结果返回至中介器的结果合并模块。

[0089] 提供以上实施例仅仅是为了描述本发明的目的，而并非要限制本发明的范围。本发明的范围由所附权利要求限定。不脱离本发明的精神和原理而做出的各种等同替换和修改，均应涵盖在本发明的范围之内。