面向信息集成应用的查询规划系统的研究与实现

面向信息集成应用的查询规划系统的研究与实现

林忠平

（身份证号码：44058219850812XXXX广东奎创科技发展有限公司515100）

摘要：激烈的市场竞争迫使企业必须快速响应外部市场变化的要求，但是分散的、独立运行的事务处理系统无法调动企业的全部信息资源以满足新的应用需要，因此企业信息集成成为解决问题的关键。本文主要就面相信息集成应用的查询规划系统的研究与实现进行了探析，仅供大家参考。

关键词：信息集成应用；查询；规划系统；研究；实现

引言

随着企业的信息化建设以及数据库系统的广泛应用，众多的应用系统，如CRM,ERP,信息门户网站以及各种业务系统等在加速企业发展步伐的同时，信息孤岛也随之形成。

1.关于信息集成的概述

所谓信息集成，其根本任务是提供用户对多种异构数据源透明、一致和实时的访问。其中透明性是指屏蔽底层数据源的差异，让用户感觉数据来自一个统一的数据源;一致性是指消除数据源之间存在的结构异构和语义异构;实时性则指访问到的数据是最新的。目前，信息集成的一种比较有效的解决途径是在应用层面进行集成，但信息集成的复杂性使得应用层逻辑日益庞大而难以管理，所以虽然可以一定程度上解决问题，但仍然无法避免其局限性。信息集成的另外一种做法是在数据层面上进行集成，将各个分布、自治和异构的数据源有效地整合在一起，完成无缝地共享和交换信息的需要，为企业的内外部信息提供更好的访问，进而促进更快、更好的经营决策制定。

为了实现上述目标，信息集成系统需要为用户提供一个来自异构数据源数据的统一视图，称为全局模式，并且在此基础上支持一个统一的查询语言，并对基于这种语言的全局查询进行处理，屏蔽数据源的位置信息。查询处理无疑是信息集成应用中最重要的问题之一，它是用户和信息集成系统之间进行交互的重要手段。

查询规划的目标是将用户提交的全局查询转换为可被数据源执行的子查询，并生成一个全局查询计划，这是是查询处理的核心任务。评价一个查询规划策略的好坏，在于系统能否充分利用数据源的查询处理能力来优化查询计划，减少子查询结果的传输，提高查询处理的并发性，减少响应时间。

2.查询规划系统的概要设计

集成平台的用户权限分两种:普通用户和系统管理员。

系统管理员负责全局模式的管理，可以进行增加、删除、查找、修改全局模式的定义、分类、目录等操作。全局模式分物化的和虚拟的两种，定义在数据源入口模式的基础上，都用表结构存储，但是只有物化的全局模式存储来自相关数据源的数据，这可以提高针对常用数据查找的速度。系统管理员以提交一条DDL(DataDefinitionLanguage)语句的方式新增一个全局模式定义，查询规划系统首先要对此DDL语句进行合法性检查，验证通过后才可以写入元数据库中，当然在这之前要根据模式信息的使用需要对编译后的DDL语句进行一定的查询重写和转换的工作。

普通用户没有管理全局模式的权限，只能在全局模式的基础上提出查询。查询规划系统接收到用户提交的DQL(DataQueryLanguage)语句后，首先也要对查询语句进行合法性检查，通过检查的DQL语句需要交给相关的数据源进行执行，这个数据源可能来自本地的物化视图，也可能是来自某个或某些包装器，所以需要进一步对DQL语句进行分解，将分解后的子查询交由指定的数据源执行，这个过程还伴随着全局模式到局部数据源出口模式的查询重写过程，最终生成一个查询计划。

根据对查询规划系统功能的分析，查询规划系统主要分为两部分:查询分析器和查询重写器，如图1所示。

其中，查询分析器负责对用户提交的SQL语句进行词法、语法、语义的分析工作，通过合法性检查的SQL语句被转化为系统内部可以理解的数据结构，为了便于查询重写器进一步处理，使用关系代数[16]作为查询规划系统的内部语言。

查询重写器则负责全局模式和入口模式之间的查询转换工作，并将基于全局模式的查询分解为基于数据源出口模式的一系列子查询，为用户提交的DDL语句或者DQL语句生成相应的执行计划。

2.查询重写器的实现

2.1预处理器

预处理器是查询重写中的一个必不可少的组件，它的功能是通过对SQL查询语句中where子句的条件表达式进行等价改写，最大程度的分解条件表达式，为查询分解阶段做准备。

查询预处理分为三个处理阶段:首先对条件表达式中的谓词进行等价转换，然后对含有比较运算符以及IN谓词的嵌套查询进行合并，最后将条件表达式转化为析取范式。

2.2查询重写器

2.2.1DDL重写器

DDL重写器的功能是在管理员建立全局模式与入口模式映射的过程中，为了便于之后对用户基于全局模式提出的查询进行处理，在定义全局模式的时候就进行一系列分解和转换的过程，并把这个中间结果以执行计划的形式保存在元数据库中。这样，每次用户提交一个全局查询，只要调出元数据库中相关全局视图的执行计划，再根据具体需要“加工”一下，即可生成包括一些列子查询的全局执行计划，大大缩短了中介器查询处理所花的时间。

由于全局模式包括两种:物化视图和虚拟视图。其中，物化视图保存了实际的数据相当于一个本地的数据源，针对物化视图的查询不需要再进行分解，所以查询响应快，查询处理简单，但是需要进行数据更新维护。为了便于数据源向相应的物化视图报送数据增量，需要在给定数据源上定义一个数据视图，命名为分发目标。而物化视图的定义语句就重写为基于分发目标的定义语句，并在元数据库中建立相应的表存储数据。所以，物化视图的查询重写主要考虑视图维护的需求。而对于虚拟视图，并不需要保存实在的数据，只需要保存模式定义信息，所以无需为虚拟视图建立分发目标，但是要对语义分析后的关系代数表达式树进行优化，并将结果以执行计划对象的形式保存在元数据中，之后基于此虚拟视图提出的DQL语句很容易按照数据源的粒度分解成一系列针对数据源的子查询，并生成查询计划。

其中分发目标的定义语句重写还取决于数据源的增量计算能力，目前系统支持三类数据源:

1.具有全部增量计算能力的数据源，可以执行各种SQL查询操作，对于这种数据源，其分发目标建立在针对此数据源进行分解的子查询之上。

2.具有部分增量计算能力的数据源，可以执行指定的SQL查询操作(例如:选择、投影操作)，对于这种数据源，其分发目标建立在将指定操作下压后的入口关系上。

3.不具有增量计算能力的数据源，不支持任何SQL查询操作，对于这种数据源，其分发目标建立在数据源的入口关系上。

2.3查询分解器

查询分解器的目的是根据查询重写的需要将用户基于入口模式的查询分解为基于各个数据源的子查询，这个过程需要考虑哪些操作可以分解下压到各个数据源的相关入口关系上，哪些操作只能保存在顶层的全局查询中，所以查询分解不是一个简单的模式间属性替换的工作。其中涉及到的问题有:当查询语句中的属性由其他属性组合而成时如何分解如何判断哪些操作可以下压到数据源执行等问题。

由于数据源根据查询能力的不同分为三种类型:具有执行全部查询操作的能力;具有执行指定查询操作的能力以及不具有执行任何查询操作的能力。为了使查询分解后的子查询中不包括数据源不支持的操作，在向元数据库注册数据源的时候，就要先对其查询执行能力进行描述。

3.总结语

通过上文，我们进行了一定的分析，我们了解到在查询重写过程中使用启发式策略来进行优化，对查询分解后的执行计划没有进一步优化，接下来可以引入基于代价的查询优化方法，根据数据源中基表的大小，索引信息主外键约束等信息对执行计划进行优化。

参考文献

[1]MudraSalem，李瑞轩，卢正鼎等.Panorama多数据库原型系统.华中科技大学学报，2001,29(12):76-78.

[2]李珊，历浩，张炯等.基于本体的异构数据集成的研究[f].计算机工程与应用，200728(61):1460-146.