空间查询优化

关键词： 空间数据 查询 数据量 优化

空间查询优化（精选八篇）

空间查询优化 篇1

关键词：空间数据,缓存,查询,优化

1 引言

目前, 随着地理信息系统应用的广泛和深入, 其研究也越来越受关注。数据量庞大、数据结构复杂是GIS的主要特点之一。目前大多的GIS系统都能够以多种方式录入这些地理数据, 以有效的数据形式进行数据库管理、更新、维护、快速查询检索, 并以多种方式输出决策所需的地理空间信息。但是, 目前流行的空间数据库管理系统, 也存在明显的不足:缺乏空间关系查寻能力, 因此, 如何有效地管理空间地理数据、满足用户的快速查询检索需求成为GIS研究的热点问题之一。

由于空间数据具有结构复杂、数据量庞大等特点, 这就使得对空间数据的查询比单纯的属性数据查询要复杂的多。因此如何提高空间数据查询的效率, 成为影响了空间数据库性能的瓶颈, 而目前各种基于关系数据库的查询优化技术却不能完全适用于空间数据, 所以基于空间数据的查询优化技术就成为了空间数据库应用中的难点和突破点。

2 缓冲存储数据

目前, 大多GIS设计都基于稳定可靠、管理方便大型数据库软件, 将应用数据建立在一个统一的数据库服务器上。然而, 在具体应用中, 用户的查询分析结果如何存储却是一个值得讨论的事情。由于空间数据的数据量庞大, 有效读写和传输数据也成为优化查询, 提高效率的途径之一。因此, 为了避免在用户操作过程中频繁地数据交流, 可以将一部分临时数据缓冲存储的客户端, 这样, 用户进行查询分析时就不需要从大型服务器上读取数据, 节省了大量的网络传输时间。

对于缓存的数据对象来讲, 又有下面几种方案:

2.1 源数据缓存:

这种方案是首先对查询涉及的数据进行分析, 分析完之后将与查询相关的所有数据全部转移到用户客户端, 一次性完成数据转移工作, 之后用户所有的操作都在客户端进行, 然后再通过相关查询语言进行查询分析处理, 最好将处理结果送入服务器。这种方法的使用, 将大大减少查询时频繁访问数据库的时间, 提高数据往返传输的效率。

2.2 查询结果缓存:

与第一种方法不同, 在这种方案中, 可以不对数据源进行分析处理, 因为涉及到查询分析数据源位于数据库服务器上不转移, 用户操作所需数据都通过网络传输从服务器上读取, 只是将通过查询得到查询的结果缓存到客户端, 然后用户可以在需要的情况下再将这些查询结果转移到服务器上去。

2.3 源和结果全部缓存:

这种方案是综合前两种方法, 将首先查询所涉及到的源数据全部转移到客户端, 用户操作完毕后, 查询结果也暂时存储客户端, 需要服务器存储的情况下再将其转移到服务器上去。

3 比较分析

综合分析这三种缓存方案, 在第一种方案中, 如果查询涉及的源数据量比较庞大, 那么缓冲源数据将会占用大量的时间, 因此, 这种策略只能在一定数据量范围内提高查询效率。在第二种方案中, 用户在不需要的情况下就不需要转移结果数据, 即使需要转移, 结果数据的数据量肯定也不会大于源数据的数据量, 因此, 转移数据的时间肯定会减少。第三种方案由于查询涉及到的源数据和结果数据库都在客户端, 因此查询分析的效率将比较高, 但是仍需要以传输大量的数据为代价。

由于GIS中的数据量往往比较庞大, 缓冲源数据的时间代价就会比较高, 因此大多数情况下可以采用第二种存储方案, 即缓存结果数据到客户端的方法。在这种方案下, 客户端需要申请一片固定长度的缓冲区空间, 将查询结果数据集中的一批数据从数据库中取出后存放在缓冲区中, 这样就可以直接从缓冲区中得到要素的信息, 加快了数据提取的时间。

以GIS中简单要素类的矩形范围查询为例, 根据结果集的数目, 设定从服务器上批量取的要素数目batNum, 申请可以存放bat Num条数据的内存空间, 每次取bat Num条数据存入, 游标指向第一条。而cur Fetch Pos用来记录当前游标在每一次取数据后的位置, curSetPos表示当前游标在集合中的位置, 在不停地结果集遍历的过程中, 当cur Fetch Pos>batNum时, 则继续取下一个的bat Num条记录, 放入缓冲区中, 直到取到最后一条数据结束。

4 结束语

为了快速、高效的数据查询和应用分析, 对空间数据的优化研究将是一个不断比较分析和调整的过程, 本文提及的策略能够从一定程度上优化查询效率, 但还有待于继续深入研究。

参考文献

[1]万波, 潘晓芳, 杨林等.空间查询语言GSQL的研究与实现[J].计算机工程与应用, 2006 (7) :140-142.

基于特征的空间数据相似性查询研究 篇2

针对目前空间数据相似性查询的广泛应用需求和实际应用情况,提出基于特征的.空间数据相似性查询(Feature Based Spatial Data Similarity Query,FBSDQ)的概念,并给出了形式化定义,分析指出了FBSDQ的特点.提出了统一的FBSDQ处理框架及其实现的关键技术,以典型的度量空间高维索引结构VP树为例,讨论了基于距离的度量空间高维索引技术,为空间数据相似性查询的研究提供了技术支持.

作 者：夏宇 朱欣焰 周春辉 XIA Yu ZHU Xin-yan ZHOU Chun-hui 作者单位：夏宇,XIA Yu(武汉大学,遥感信息工程学院,武汉,430079)

朱欣焰,周春辉,ZHU Xin-yan,ZHOU Chun-hui(武汉大学,测绘遥感信息工程国家重点实验室,武汉,430079)

空间数据库查询优化技术研究 篇3

空间数据库是地理信息系统在计算机物理存储介质上存储的与应用相关的地理空间数据的总和, 从空间数据库查询优化技术的内容来看, 其优点在于能够对数据信息进行及时查询, 并能够优化空间数据存储方式, 为数据存储和地理信息的保存和调用提供有力支持。因此, 正确理解空间数据库查询优化技术, 对推动空间数据库查询技术发展和满足地理信息处理需要具有重要意义。

1 空间数据库技术的主要内容及特征

目前空间数据库技术的研究适于上世纪七十年代的地图制图和遥感图象处理领域, 目的就是利用卫星遥感资源迅速绘制各种经济专题地图。空间数据库的特征主要表现在三个方面:一、数据存储的容量较大, 并且可以对空间位置进行定位和描述。二、可以设计并利用多种空间数据模型, 同时造成复杂的空间数据模型。三是应用十分广泛。空间数据库技术能够在多个领域得到全面有效的应用, 对提高数据处理和存储效果具有重要作用。

2 目前空间数据库普通查询技术

在目前数据库查询技术的发展中, 空间数据库查询技术是一种最新的技术形式, 不但在整体查询效果上对数据库管理有着明显的支持, 同时对空间数据库查询的发展也起到了重要的促进。其要点在于空间数据库查询技术可以根据数据的存储要求, 对数据进行准确定位, 并根据数据的位置进行查找, 极大的提高了数据查询效率, 并提高了数据查询的准确性, 满足了数据库管理的现实需要。

3 空间数据查询方式及处理过程

空间数据查询操作中, 常用的查询方式有精确匹配查询、窗口查询、点查询、域查询、拓扑查询、空间连接查询、相邻查询和最近邻查询等。空间数据库查询处理过程查询处理器首先访问空间索引。空间数据库索引存储是空间对象的近似描述, 对这些近似描述操作, 将不可能满足查询条件的筛检掉, 在余下的对象为候选集, 在进行过滤步骤, 在求精步骤所要进行的几何计算, 运用空间近似方法, 尽可能多地排除不满足查询条件对象, 使侯选集逐渐缩小范围, 对一些近似精度高的数据进行处理, 提高几何图形监测速度, 使监测得到满足空间数据查询条件更多解。

4 空间数据查询的优化技术研究

4.1 空间数据索引优化技术

主要是从数据存取的角度对整个空间数据索引技术进行全面优化, 其重点是根据空间数据管理的实际需要, 增加专门的空间数据索引, 并结合空间数据管理的实际需要, 制定具体的空间数据索引目录, 保证空间数据在引用过程中能够充分满足实际需要, 进而达到提高空间数据导入质量的目的。传统数据索引机制也不适合现在空间数据查询。目前, 以R-树及及其变形树是公认的、常用的有效空间索引之一。R-树是基于空间关系的查询, 采用过滤-精炼两步策略。很大程度优化了空间数据库技术。

4.2 空间数据查询算法的优化

对于空间数据查询技术而言, 具体算法的优化不但关系到整个空间数据查询的实施, 同时也对空间数据查询的整体效果有着直接的影响。基于这一现实需要, 对空间数据查询算法进行优化是十分必要的。其中应根据空间数据查询的描述, 在空间查询处理过程的第一步是过滤, 在过滤步骤中判断空间对象的近似描述, 目前, 通过空间对象的形状来改进多边形监测法可以提高查询效率。在一些空间数据库里, 已经实现技术互补, 以此优化空间数据库查询技术。所以, 对空间数据查询算法的优化, 是空间数据算法的优势所在, 只有认识到这一点, 才能保证空间数据查询技术得到全面有效的利用。

4.3 优化代价估算模型

这一技术主要是根据估算模型的实际需要, 对代价估算的模型进行全面优化。为了保证优化效果满足实际需要, 在具体优化过程中, 首先要对代价估算模型进行正确了解, 并根据代价估算模型的实际算法进行空间对象整定, 保证代价估算模型能够通过空间索引进行访问, 提高代价估算模型的应用效果。基于当前空间数据查询技术的发展, 代价估算模型是该技术的核心内容, 对该技术的发展有着重要影响, 只有做好代价估算模型的优化, 才能保证空间数据查询技术在发展过程中得到有力的支持。因此, 做好代价估算模型的优化, 对空间数据查询技术而言具有重要的促进作用和现实的促进, 是提高空间数据查询技术应用效果的重要措施。

5 结论

通过本文的分析可知, 空间数据库查询优化技术在发展过中, 不但吸取了传统数据库查询技术的优点, 同时也对数据库查询功能进行了不断的优化, 使数据库查询技术能够随着空间定位技术的发展而快速进步, 为数据库查询技术的发展提供有力支持, 使空间数据库查询优化技术, 在实践中得到全面有效的应用。空间数据库查询优化技术作为一种新的数据库应用技术, 对地理信息的管理有着突出的优点和良好的支持。基于当前空间数据库查询优化技术的发展, 该技术在地里信息的管理中得到了有效应用, 并对地理信息的管理起到了积极的促进作用。因此, 正确理解空间数据库查询优化技术, 做好该技术的研究, 对空间数据库查询优化技术的研究具有重要意义。

参考文献

[1]李俊洁.空间数据库空间连接和查询优化研究[J].哈尔滨理工大学, 2008 (03) .

[2]方裕.空间查询优化[J].中国图像图形学报, 2001 (06) .

空间数据的访问方法与查询技术研究 篇4

GIS数据中包含了大量的地理信息数据, 如果不为这些数据创建索引, 要从海量的GIS数据中检索到目标数据, 这一过程可能会经历相当长的时间。如果为这些GIS数据创建合理的索引文件, 在索引文件中检索目标数据, 检索速度会明显得到提高。因此在空间数据产品中实现高效的索引算法是非常必要的。与此同时, 随着人们对地理数据表示和处理的需求越来越普遍, 地理信息系统正迅速扩展到各种应用领域。传统的GIS系统本身的功能和结构也发生了巨大变化, 开始向Web扩展。

1 空间数据库查询的主要特点

空间数据库查询是空间数据库的一项重要操作, 空间查询技术是针对空间数据库的特点发展起来的。由于空间数据量的庞大, 以及空间对象、空间查询的高度复杂性, 使得空间数据库的查询效率成为衡量空间数据库性能的重要指标之一。

数据库是为一定目的服务的, 并以特定的数据格式存储的相关联的数据集合。它是数据管理的高级阶段, 是从文件管理系统发展而来的。空间数据库是某一区域内关于一定地理要素特征的数据集合, 与一般关系数据库相比, 其主要特点有:

1) 数据量特别大, 要用数据来描述各种地理要素, 尤其是要素的空间位置, 其数据量往往很大。

2) 不仅有地理要素的属性数据与关系数据库中数据性质相似, 还有大量描述地理要素空间分布位置的空间数据, 并且这两种数据之间具有不可分割的联系。

3) 数据应用广泛, 如地理研究、环境保护、土地利用、生态环境、道路建设、资源开发、市政管理等。

空间查询是空间数据库的一项重要操作。由于空间数据库的特殊性, 空间数据库的查询除兼有普通数据库的查询能力外, 同时还应具备空间数据的查询能力。空间查询大体上可分为点查询、区域查询、最近邻查询及空间连接查询四类。

与一般关系数据库相比, 空间数据库在查询处理方面的主要特点至少有:1) 目前仅仅在空间操作的类别上达成了一致, 对每种具体空间查询的设计与处理规则各不相同。2) 空间数据库要处理非常大量的复杂对象, 这些对象具有空间范围, 而且不能自然地排序成数组, 需要建立适合于空间数据的访问方法以提高查询的效率。3) 检测空间谓词的算法计算量极大, 所以不能再假定I/O代价在CPU的处理代价中占主导地位, 这就使得空间查询处理与优化过程设计比传统数据库更为复杂。

2 空间数据索引

空间数据访问方法由空间索引和定义在空间索引上的查询操作组成, 是空间查询技术的基础, 空间查询的性能好坏很大程度上取决于空间数据访问方法的效率。

2.1 网格索引

网格索引的基本思想是将研究区域纵横分成若干个均等的小块, 每个小块都作为一个桶, 将落在该小块内的地物对象放入该小块对应的桶中。从精度考虑, 小块还可细分, 直至不可再分为止。当用户进行空间查询时, 首先计算出用户查询对象所在网格, 然后再在该网格中快速查询所选空间实体。其优点主要有:桶数固定、结构简单, 每个表项都用于表示地物的空间位置及分布;查询方式多样, 可以任意以一点或一条线或一个任意形状的区域进行检索;检索结果合理查询精确, 这是因为网格索引支持地物的特征信息存储;支持多精度等级, 查询并不要求太精确, 如查询某点附近的地物, 网格索引的多级分块策略正好适应这种情况, 对于一些非精确查询, 特征信息匹配计算无需进行或只进入第二级就行了, 而不必再往下去。这样就节省了更多的时间。然而网格文件本质上会造成目录非常松散, 因而浪费主存缓冲区和二级存储。

2.2 R树及其变种

R树是GUTTMAN于1984年提出的最早支持扩展对象存取方法之一, 也是目前应用最为广泛的一种空间索引结构。许多商用空间数据库系统, 如Map Info Spatial Ware和Oracle Spatial等均提供对R树的支持, 开放源码系统Postgre SQL也实现了R树。近二十多年来, 许多学者致力于R树的研究, 在R树的基础上衍生出了许多变种。比较典型的有R+树、R*树、压缩R树等。

R树是一个高度平衡树, 它是B树在k维上的自然扩展, 用空间对象的MBR来近似表达空间对象, 根据地物的MBR建立R树, 可以直接对空间中占据一定范围的空间对象进行索引。R树的每一个结点都对应着磁盘页D和区域I, 如果结点不是叶结点, 则该结点的所有子结点的区域都在区域I的范围之内, 而且存储在磁盘页D中。如果结点是叶结点, 那么磁盘页D中存储的将是区域I范围内的一系列子区域, 子区域紧紧围绕空间对象, 一般为空间对象的外接矩形。

R树中每个结点所能拥有的子结点数目是有上下限的。下限保证索引对磁盘空间的有效利用, 子结点的数目小于下限的结点将被删除, 该结点的子结点将被分配到其他的结点中;设立上限是因为每一个结点只对应一个磁盘页, 如果某个结点要求的空间大于一个磁盘页, 那么该结点就要被划分为两个新的结点, 原来结点的所有子结点将被分配到这两个新的结点中。令M为一个结点中记录数目的最大值, m≤M/2为一参数, 说明一个节点记录的最小值, m可作为调节树结构的一个可变参数, R树满足如下几项特点:根节点若非叶子节点, 则至少有两个子节点;每个非根叶节点和非叶节点包含的实体个数均介于m和M之间;所有叶子节点在同一层次。

R树兄弟结点对应的空间区域可以重叠, 可以较容易地进行插入和删除操作。但正因为区域之间有重叠, 空间索引可能要对多条路径进行搜索后才能得到最后的结果。当查找与给定的查询窗口相交的所有空间对象时, 空间搜索算法是从根结点开始, 向下搜索相应的子树。算法递归遍历所有约束矩形与查询窗口相交的子树, 当到达叶结点时, 边界矩形中的元素被取出并测试其是否与查询矩形相交, 所有与查询窗口相交的叶结点即为要查找的空间对象。R树的查询效率会因重叠区域的增大而大大减弱, 在最坏情况下, 其时间复杂度甚至会由对数搜索退化成线性搜索。正是这个原因促使了R+树的产生。在R+树中, 兄弟结点对应的空间区域没有重叠, 而没有重叠的区域划分可以使空间索引搜索的速度大大提高, 克服了R树中多路查询的问题, 但同时它也存在着一些缺陷, 如对某个最小约束矩形的划分, 可能会引起相关子树上其他结点也需要重新划分, 向下分裂操作可能使得已经划分好了的结点被重新划分, 空间对象在R+树的叶结点中被重复标记, 完成删除运算后, 必须对R+树进行重建等, 同时由于在插入和删除空间对象时要保证兄弟结点对应的空间区域不重叠, 而使插入和删除操作的效率降低。R*树是最有效的R树变种, 它能对覆盖区域、重叠面积和边界周长进行启发式地优化, 并通过重新插入节点重建R*树以提高其性能, 但重新插入这个过程相当繁琐, 其实现过程太过漫长。

压缩R树的空间数据集是预先己知的, 通过预先对数据进行合理有效的组织, 可以保证其具有很高的空间利用率和良好的查询效率, 但由于其不能进行动态插入和删除, 因而其应用受到了很大限制。

3 空间数据查询技术

3.1 点查询与区域查询

点查询 (Point Query, PQ) :给定一个查询点P, 找出所有包含它的空间对象O。使得PQ (p) ={O|PεO.G≠?}, 其中O.G为对象O的几何信息。

范围或区域查询 (Range or Regional query, RQ) :给定一个查询多边形P, 找出所有与之相交的空间对象O。当查询多边形为矩形时, 成为窗口查询:

对这些查询的处理与包含该查询关系的文件的组织方式有关, 根据参与查询的空间数据集是否具有空间索引, 其相应的处理策略各不相同。

1) 数据集未排序且没有空间索引在这种情况下, 唯一的方法就是采用穷举法扫描整个文件, 并判定每一条记录是否满足查询谓词, 利用过滤、精炼两步处理来实现。如果空间对象用它的MBR来近似表示, 则区域查询的过滤步骤就对应着检验矩形与查询矩形的交集。这个处理与没有过滤就处理整个对象相比, 其代价是非常低的。扫描的代价为O (n) , 其中n是进行区域查询的关系中包含的页面数。

2) 数据集具有空间索引在数据集具有空间索引的情况下, 查询可通过扫描索引文件过滤掉大部分不满足查询条件的空间对象, 从而避免扫描整个数据文件, 减少系统负载。通常使用的空间索引为R树族。使用索引树, 点查询通常可在O (logn) 时间内完成处理, 区域查询的代价则依赖于许多因素, 包括数据矩形的分布、查询窗口的大小、树的高度及用于构造索引树结点的压缩算法等等。采用R树的缺点是不同分支的MBR可以交叠, 这就可能导致沿着索引树的不同分支进行搜索。R树的一个变体树避免了内部结点的交叠, R+树的主要问题是空间对象的外接矩形可能在多个内部结点上存在重复, 这会导致搜索时间增加和结点的频繁溢出。

3.2 最近邻查询

最近邻查询在许多应用中都很常见。如电子商务网站接收到书籍订单后该把订单发送到最近的配送中心。典型的算法有两遍算法和一遍算法:

1) 两遍算法第一遍检索包含查询对象QO的数据页D, 以确定D中任意对象到QO的最小距离d;第二遍通过一个范围查询检索与QO的距离在d内的对象以确定最近邻居。这个方法使用了用于范围查询和点查询的算法。

2) 一遍处理算法该算法的最近邻查询需要用到与区域查询和点查询完全不同的算法。最早由ROSSOPOULOS提出, 使用了一对距离度量, 即搜索修剪条件和搜索算法。

3.3 空间连接查询

空间连接查询是空间数据库系统一种重要的多路查询, 即从两个数据集合中检索出所有满足某一空间谓词, 如交、包含等的空间对象。如给定两个对象集A、B, 其空间连接是从A中的对象到B中的对象应用谓词S的结果。谓词S包括覆盖、距离、方向、邻接和包含等。

当两种空间关系连接在一起时, 我们称之为空间连接。空间关系是指空间对象之间具有空间特性的关系, 主要包括拓扑、顺序、度量三大类关系。因此空间连接查询又可分为拓扑连接查询、顺序 (方位) 连接查询和度量 (距离) 连接查询。与其它空间查询一样, 空间连接查询的实现过程通常分两步进行过滤和精炼。过滤即是借助空间索引与MBR, 查找出满足给定条件的空间对象候选集, 建立空间连接索引。精炼则是用相应的空间对象代替进行具体的连接处理, 检索出满足实际需求的空间对象, 即从第二存储区检索候选集中每个对象的精确形状信息, 来测试其是否满足查询条件。

参考文献

[1]刘刚, 邓飞其, 杨长海.AJAX在WebGIS异步数据交互中的研究[J].计算机技术与发展, 2009 (1) .

嵌入式空间数据库综合查询算法 篇5

嵌入式空间数据库通常就是指嵌入式系统运行的过程中, 可以对空间地理信息和与其相关的一些属性信息所构成的空间数据进行全面的存储, 同时在实际的工作中还能够提供更加全面有效的空间检索引擎以及操作数据库管理系统。因为嵌入式资源具有非常明显的有限性, 嵌入式空间数据库通常作为GIS的后端, 这样就可以为GIS提供数据库所需要的各项功能。查询是嵌入式GIS采用嵌入式空间数据库所采取的最具复杂性的一个操作, 从某个角度上来说, 它的性能会对嵌入式GIS的运行效率产生非常重大的影响。

2 综合查询算法分类

嵌入式空间数据库综合算法主要是对空间数据的空间进行查询和对属性数据的属性内容进行全面的查询, 如果根据其对属性数据以及空间数据处理的流程和顺序来划分, 其大体上可以分成两类, 一个是串行查询, 一个是并行查询。

如果按照算法系统的实现方式对其进行划分, 其主要可以分成三种方式:

第一个是先空间查询。系统在运行的过程中首先完成空间运算工作, 之后按照空间运算返回的具体结果以及属性约束的实际条件再开展属性查询工作。第二个是先属性查询。系统在运行的过程中先是要按照属性约束的具体条件来对属性进行全方位的查询, 之后再按照属性查询返回所显示的结果结合空间约束的条件开展空间查询工作。第三个是空间和属性同时查询, 系统在运行的过程中首先药理按照属性和空间约束的条件对属性和空间进行同时查询, 之后再计算出二者结果中的交集, 这样就可以得到最终的查询结果。

3 先空间串行查询算法

用户在使用这种方法的过程中通常是借助应用程序的用户界面对选择一个指定的查询区域, 之后按照规定输入属性的约束条件, 之后应用程序会借助和嵌入式空间数据的接口连接, 对空间查询模块当中的操作函数以及空间索引模块当中的R* 空间索引开展空间查询工作。之后属性查询函数会在这些对象上面, 按照输入的属性月撒胡条件其用数据库内部的B+ 树索引, 从而完成属性查询工作, 最后一步就是把查询的结果用表格或者是可视的方式传递给客户。

这种方法在应用的过程中比较顺应大多数用户的思维模式, 在系统操作过程中也十分的便利, 但是在实际的工作中空间查询工作需要接触到很多复杂性比较强的空间对象, 此外这种方法还需要完成大量的计算, 所以一方面它是CPU密集型的系统, 同时也是I/O密集型的系统, 在属性查询操作的时候必须要操作非常多的单一性数据, 只是I/O密集型的系统, 尤其是对于存储资源和计算自愿不是非常多的系统而言, 这种方式会对操作的效率产生非常不利的影响。

4 先属性串行查询算法

用户在使用这种方法的时候首先要在应用程序的用户界面上选择一个显示区, 按照要求输入属性的约束条件, 之后应用程序的内部就会借助和嵌入式空间数据库的接口, 采用嵌入式空间数据库使得数据库内部空间查询模块当中的空间过滤操作函数进行处理, 从而就能对空间查询的约束条件进行有效的过滤, 之后使用底层嵌入式的关系数据库中的B+ 树索引, 对经过过滤的数据开展属性查询工作。之后函数会根据属性返回的结果集和过滤掉的空间查询约束条件, 采用固定的索引形式架站空间查询, 如果空间对象集能够充分的满足设定的条件就可以将查询的结果集按照表格或者是其他可视化的形式呈现在用户眼前。

这种方法和线空间串行查询的方法比较而言多设置了一个空间过滤器, 所以系统的处理效率会受到一定的影响, 但是它能够对计算的过程进行有效的简化处理, 此外, 加入了空间过滤器之后就可以提高查询的效率, 但是其也会使得I/O的运行负担大大增加。

5 并行查询算法

5.1 POSIX多线程。POSIX多线程主要特征表现如下:

5.1.1 操作系统自身的开销并不是很大, 线程和进程相比是一种相对比较经济的操作模式。同一进程当中不同的线程使用的地址空间完全相同, 所以对很多数据而言, 线程的开销要比线程低很多, 因此具有良好的经济性。5.1.2 程序复杂性小。不用编写IPC代码, 减少了很多工作量。5.1.3 灵活性强, 速度快。线程的开销并不是很大, 切换的速度非常快, 所以在系统运行的过程中我们不必担心CPU内存不足带来的影响。非常适合使用在嵌入式研究当中。5.1.4 可移植性。顾名思义, POSIX即可移植操作系统接口, 用它编写的代码可运行于solaris, freebsd, Linux等其他多种平台。

5.2 并行查询算法实现。用户首先从应用程序界面选择显示范围, 输入属性约束条件, 然后应用程序内部采用POSIX多线程机制, 通过与嵌入式空间数据库的接口, 同时调用嵌入式空间数据库内部空间查询模块的空间查询函数和空间索引模块的R* 树空间索引和底层嵌入式数据库SQLite的B+ 树索引进行空间和属性的双向查询, 接着对它们返回的结果集求交集, 最后将求交所得的最终查询结果集以表格或可视化的形式返回到用户界面。

该方法采用了POSIX多线程编程机制, 使得空间查询和属性查询操作可以同时进行。较前2 种算法而言, 理论上具有更高查询效率和更好的移植性。但是由于空间查询和属性查询的同时进行, 需要处理的记录数也较前2 种查询算法多。当记录数超过一定数量而空间查询函数的CPU代价较低时, 可能会影响系统的查询效率。

6 性能测试与比较

6.1 测试数据。测试数据取自17 套中国沿海海图数据, 海图以图幅- 图层形式组织。海图数据格式与shapefile格式基本相同, 且其空间数据和属性数据均存放在嵌入式空间数据库中。

6.2 测试环境。硬件运行环境:以ARM920T为嵌入式处理器为核心的三星SMDK开发板。软件运行环境:Monta Vista Linux专业版 (Professional Edition) 嵌入式Linux实时操作系统, 基于QTE图形界面开发包开发的嵌入式态势标绘软件系统QGIS-minus。软件开发环境:RedHat Linux9.0, SQLite3.3.4, Star SDB1.0.2。

6.3 测试与比较。在一般情况下, 并行查询算法的性能优于串行查询算法。但是由于并行查询算法是对空间查询和属性查询的同步进行, 需要处理的记录数也较前2 种查询算法多。当记录数超过一定数量而空间查询函数的CPU代价较低时, 其系统的查询效率也会明显降低。

结束语

当前, 我国的科学技术发展水平有了非常显著的提升, 嵌入式GIS对空间数据管理的数据数量呈显著的增加趋势, 这样的情况下, 嵌入式空间数据库综合查询算法的准确性和科学性也必须要有所改进和完善, 只有这样, 才能更好的保证数据查询的效果。所以, 我们在实际的工作中一定要对这一问题加以重视, 根据具体的情况选择不同的算法。

摘要：嵌入式数据库通常是嵌入式GIS系统的后端, 可以为GIS提供空间数据以及属性数据储存、检索和查询等多项功能, 在嵌入式GIS运行的过程中, 查询的性能对嵌入其运行的质量和效率有着最为显著的影响, 本文主要分析了嵌入式空间数据库综合查询算法, 以供参考和借鉴。

关键词：嵌入式空间数据库,综合查询方法,嵌入式GIS

参考文献

[1]万波, 潘晓芳, 杨林, 李莉.空间查询语言GSQL的研究与实现[J].计算机工程与应用, 2006 (7) .

空间查询优化 篇6

一、空间查询的概念及查询方式

空间查询属于空间数据库的范畴, 一般定义为从空间数据库中找出所有满足属性约束条件和空间约束条件的地理对象。在地理信息系统中, 空间查询指对空间对象进行查询和度量。空间查询不改变空间数据库的数据, 不产生新的空间实体和数据, 只通过属性查询和图形查询来回答用户的问题。

空间查询有两种查询方式:属性查询和图形查询, 同时也可以实现双向查询, 即“属性查图形”和“图形查属性”。

属性查询是根据一定的属性条件来查询满足条件的空间实体的位置, 是基于实体的属性信息进行查询, 与一般的数据库查询相同, 只不过最后查询的结果需要与图形关联。属性查图形, 主要是用SQL语句来进行简单和复杂的条件查询。如在北京市总体规划图上查找北京西站地区历年所规划项目, 将符合条件的规划项目属性与图形关联, 然后在规划图上显示给用户。

图形查询是另一种常用的空间数据查询, 是根据图形的空间位置来查询有关属性信息或者实体之间的空间关系。用户只需利用光标, 用点选、线选、框选等方式选中感兴趣的地域, 就可以得到查询对象的属性以及其他所需要的信息。图形查属性, 可以通过点、矩形、圆和多边形等图形来查询所选空间对象的属性等其他内容。查询的结果可以通过多种方式显示给用户, 如高亮度显示, 属性列表和统计图表等方式。

二、城市规划档案的特性

随着信息化技术的发展和成熟, 城市规划设计技术手段得到了改善和进步, 从最初的人工绘制图纸到信息化初级阶段运用的Auto CAD技术到目前大量基于GIS技术的智能化手段。城市规划设计方法的改变带来了城市规划档案的更新和改变, 城市规划档案从内容、形式及其利用等都发生了很大的变化。

1.城市规划中CAD系统、GIS技术的广泛应用对城市规划档案的影响。计算机辅助设计 (CAD) 系统是应用于机械工程、电子、建筑和化工诸多领域进行制图设计的图形处理软件。目前, 在城市规划设计工作领域中已普遍采用CAD技术进行规划设计工作。CAD技术的应用, 改写了过去完全依靠人工野外测量、数据采集, 图形绘制的历史, 提高了信息采集、整理和再加工的自动化和智能化程度, 大大提高了规划设计的效率。

地理信息系统 (GIS) 技术是以地理空间定位为基础, 结合各种文字、数字等属性进行集成处理与统计分析的通用技术, 是城市规划和管理的重要手段。GIS是城乡规划日常工作的工具, 它既是数据库, 又是工具箱, 具有数据更新快捷、空间范围实时直观等特性。GIS在城市规划中的广泛应用, 既实现了城市规划的直观和理性, 又提高了规划的公众参与性, 是城市规划信息时效性的保证。

城市规划编制和设计过程中新技术的使用, 实现了数据的数字化, 数据的获取也变得更加容易, 为规划设计工作提供了方便、快捷的方法。城市规划档案随着新技术的应用也发生了变化。首先, 规划档案的内容发生了变化。CAD技术代替了人工绘制的纸质规划图纸, 大量的CAD格式图纸和现状照片得到了保存, 档案的内容得到了丰富。其次, 档案的利用也有了新的要求。随着新技术的进步, 档案的利用方式不再局限于纸质档案的查询, 而对档案的数字化查阅、远程查阅等提出了要求。第三, 规划档案的空间特性显现出来。城市规划主要解决城市资源和城市基础设施在城市空间中的合理分布, 因而着重对于城市空间的描述和表达。GIS技术的应用使城市规划档案的空间特性显现出来。第四, 新技术的应用, 对档案信息的挖掘提出了要求。在规划编制设计过程中, 规划师对规划档案的利用要求不仅是案卷目录信息, 而希望提供相关数据的统计及利用。

2.城市规划档案数据的特点。城市规划是以地理空间信息作为其设计与管理的基础, 城市规划档案多以CAD格式、图片或文字表格形式存取和组织, 它作为一种专业技术档案具有以下特点。

(1) 内容丰富。城市规划档案包括总体规划、分区规划、控制性详细规划和修建性详细规划、各专项规划及基础设施规划等。其内容十分丰富, 包括城市基础地形图、市政综合管线图、各项规划编制成果 (包括总体规划、分区规划、控制性详细规划、专项规划、修建性详细规划等) 、各类报批方案 (包括总平面规划方案、建筑设计方案、市政设计方案、施工图等) 。

(2) 图形数据多。城市规划档案中涉及大量的空间图形数据, 有各种比例尺的基础地形图、用地红线图、选址红线图、影像图、现状图、土地规划图等等。另外, 还有各种空间定位控制数据、各种航空与遥感影像数据、地名数据等。

(3) 有空间特性。城市规划需要全面、综合地安排城市空间, 合理利用土地, 是一个与空间位置密切相关的信息获取、管理与服务的技术体系, 与空间地域、空间组织、空间范围等密切相关。城市规划档案作为城市规划编制的保存记录, 也保留了城市规划的空间特征, 档案信息以空间方式表达和利用。

三、空间查询模式的利用

为提高城市规划档案的查询利用效率, 针对城市规划档案数据的特点, 引入空间查询模式。

首先, 空间查询系统的构建是实现查询的前提, 它是基于遥感影像地图和GIS数据为基础而开发的工具。对档案管理人员而言, 系统的构建更多地依赖于信息开发人员。

其次, 档案数据的处理是实现查询的基础。空间查询作为一种空间位置查询方式, 相关空间信息是数据基础, 即任一卷城市规划档案都要有一个项目空间信息的描述, 系统将据此描述进行检索和查询。对于dwg格式的档案, 空间信息登记的方式相对比较简单。依据位置示意图, 在CAD系统中新建图层及项目界, 执行pl命令, 通过多段线的方式绘出对应档案的项目界限, 然后进行档案号、档案案卷名称等相关信息的登记, 入库, 完成该档案的空间信息登记。对于无dwg格式的档案, 可以参照位置示意图, 在谷歌地球上找到对应区域, 绘制项目边界得到KMZ文件, 经过格式转换和坐标转换后登记档案号、档案案卷名称等相关信息, 通过Arc Catalog入库完成空间信息的登记。

第三, 制度的完善是实现空间查询的保障。空间查询的实现, 还要完善相关的《电子档案的归档要求》、《档案的借阅利用制度》等制度。在电子档案的归档要求中, 为完成对档案项目边界的划定, 需要强调档案的数据与元数据规范, 强调数据的归档格式和要求, 明确元数据文件中关于项目边界图层的具体要求等。在档案的借阅制度中, 要完善空间查询的相关要求等内容。

空间查询模式可以根据查询要求在空间地图上迅速定位, 在规划档案以街区、地块等空间方式命名时更快速地检索到, 可以查询同一位置不同命名方式的所有档案, 可以有效地提高档案的查全率和查准率。在城市规划档案的查询利用中, 空间查询与关键词检索相互补充、各取所长, 更好地提高规划档案的利用率, 促进规划编制研究数据、信息资源间的有效利用和共享。

空间查询优化 篇7

1 场景坐标精确拾取方法

在三维环境下实现可量测性, 目前一般采用三种途径, 其一是基于数据文件或数据库实现空间查询功能;其二是基于投影变换关系的求交计算, 计算出三维地形图上相应的地面点空间位置:其三是基于OpenGL拾取与反馈技术的查询方法。

基于数据文件的三维环境下的空间查询。其基本过程是:在绘制三维图的同时, 按照一定的数据结构在三维地形上逐点存储所对应的地面点的空间信息 (X, Y, Z) , 构成相应的数据库文件或数据文件。在坐标查询时, 以三维图形中的位置 (X, Y) 为索引, 从相应的数据库文件或数据文件中查询, 显示出该点的地面空间信息。这种方法需要存储的数据量大, 且查询过程繁琐速度比较慢, 实际应用有一定的局限性;基于投影变换的空间坐标计算, 其实质就是透视投影成像的逆过程。即从任一点屏幕像点出发, 逆向投影光线交出地面点的空

表1编录属性数据库 (以结构面数据表为例)

间位置的过程。实现这一过程的数学基础就是摄影测量学中的单片定位算法, 其数据支持是区域的DEM, 这种方法解算精度依赖于DEM的精度, 且因为地形的起伏会产生解算不收敛的问题;基于OpenGL拾取与反馈技术的查询方法, 实现的原理是在内存中建立一个堆栈, 这个堆栈按递增序列 (如1, 2, ......n) 记录了X方向所有网格数, 当鼠标在三维场景中物体上点击时OpenGL从这个堆栈中依次判断是哪一个网格, 并返回给应用程序网格数n的值, 再由n值计算鼠标点格网左下角坐标。这种方法充分利用了OpenGL的拾取与反馈技术, 实现过程简易, 但是此方法得到只是格网左下角坐标, 得到的点位精度与格网的绘制密度有直接的关系, 若要保证拾取的精度, 则地形格网要很密, 这会影响程序的运行效率。因此探讨快速且精确的拾取算法是十分有必要的。

由于第三种方法实现过程简单, 且适合于主要由规则开挖面构成的边坡工程坐标拾取。所以本文选择在第三种方法的基础上进行改进, 以实现场景坐标的精确查询。具体的实现借鉴金字塔策略, 先粗定位, 然后逐步细定位。过程如下:首先在绘制边坡场景时, 对场景中的每一个边坡赋予一个唯一的ID值, 且向名称堆栈中推入该边坡的工D号;在鼠标点击场景进行空间分析时, OpenGL返回一个选中的坡面的ID号, 定位边坡, 此时用比较大的间距仅绘制当前边坡对象的网格, 并将此边坡的所有网格数推入堆栈, 再判断当前拾取的点在当前坡面分块中的哪一块, 对这一分块再进行格网加密。可以根据设定的阀值来判断拾取的值是否满足精度的要求, 如不满足则对当前块再加密, 直至返回的值满足要求。流程图如图1所示。

例如可以在第一层中将当前坡分为8×4, 然后在第二层将第一层中选中的网格再细分为8×4, 以此下去, 直到拾取到格网的左下角坐标精度满足设定的要求。

金字塔每一层的网格数可以自行设定。参见图2。

可以给出利用金字塔策略与不利用金字塔策略效率的比较:假定一个原本需要划分成1024×512坡面格网才能达到拾取精度的模型, 在使用金字塔策略时, 假定金字塔分为6层, 每层为8×4的格网, 只需要划分为8×4×6坡面格网, 两者的效率之差是非常明显的。且在场景越大的情况下, 金字塔策略的优势越明显。对于不在同一个平面上的曲面坡及不规则坡, 该方法的思想同样适用。当场景绘制时为构成坡面DEM的每一个格网分配一个ID, 在鼠标拾取时, 通过ID号定位到该格网时, 对此时的格网再进行细分, 细分方法与平面坡相同。

用金字塔策略实现场景坐标的快速精确定位, 是三维环境下的地质分析的基础。

2 编录信息查询浏览方法

对于边坡的编录信息, 同样采用OpenGL的拾取反馈技术, 结合ADO数据库访问技术对其进行查询。边坡编录属性类信息主要包括:地层数据、结构面数据、节理裂隙数据、风化分带数据、水文地质点数据、监测点数据及影像控制点测量成果数据。由于编录信息的坐标是存储在其相应的DXF文件中, 而其属性是存储在边坡编录属性数据库中。边坡三维场景中属性信息绘制时数据来源于其相应的DXF文件中, 因此要建立场景绘制的结构线与其属性的相互关系。

本文建立两者关系的方法是在边坡属性数据表中添加ID字段, 以结构面数据表为例, 如表1所示。

当从DXF文件中读取数据绘制编录信息时, 利用OpenGL拾取与反馈机制给每一条编录信息分配一个唯一的标识符 (ID) , 此时的标识符与属性数据库中的MAPINFOID相对应。在选择模式下, 通过鼠标在窗口的边坡三维模型上点击结构特征上的任意一点, 获取当前实体的ID值;然后, 通过ADO连接数据源, 根据此ID构造并执行相应SRL查一询语句, 从边坡属性数据库中相应的数据表里得到此编录信息的属性。查询的流程如图3所示。

查询的编录信息通常包括结构特征的图形线名、样式名、一级标识码等属性信息, 也可包括结构线的空间位置和结构面的产状信息等, 图3为选中一条结构线弹出的信息框示例。

3 边坡模型三维空间量算基本算法

地质编录空间量算的数据主要是关于模型的空间坐标、距离、开挖面坡度和坡向、开挖范围和各种面积等。显然, 有了任一点的空间坐标, 即可进一步计算出指定特征线的空间位置、任意两点的距离、方向以及开挖面的产状、范围和面积等等。

(1) 距离量测。

空间点的坐标可以本文介绍的精确拾取的方法, 拾取到其精确的空间三维坐标。任意两点的坐标均可精确拾取到, 两点间的距离由下式计算得到。

(2) 建成坡面的产状计算。

由于大部分边坡设计为平面, 故在利用边坡的角点数据获得平面坡法向量情况下, 计算坡度和坡向的方法可以大大简化。

首先以下式计算走向和倾角的绝对值

其中a, b为坡的走向和倾角, u, v, w为坡的法向量在大地坐标系X, Y, Z方向的分量。然后在根据法向量的值判断其方向, 判断方式如表2所示。

表示方法满足工程规范, 以某桩段边坡为例:走向N3.4690E;倾向倾角SEL47.5950。

(3) 开挖面形态监测。

基于影像的数字地质编录中, 平面或曲面边坡开挖面方程通常由开挖面控制点拟合得到, 或直接来源于设计参数。实际应用表明, 现有施工条件下的开挖面确定中误差小于10cm, 这个精度使得据此建立的三维模型能够满足对地质编录成果空间量算的需求。但是, 以几何面建立的三维模型显然无法精确表示开挖面实际形态, 况且10cm的精度对工程形态监测而言仍是不够的。

为了在三维虚拟环境下对开挖面实际形态监测, 系统采取如下方法。首先在三维场景下, 利用拾取与反馈功能精确计算出用户对开挖面查询点的空间位置, 并确定查询范围;然后系统根据查询位置, 在编录数据库中自动调出覆盖查询范围的原始立体像对, 由摄影测量算法实现对开挖表面三维形态数据的高精度、全自动采集建立查询区域高精度三维表面模型 (DSM) 最后依据DSM进行开挖面的工程形态、方量、超欠挖等监测和分析。监测流程如图4所示。

4 三维环境下编录矢量信息的合并、增加和删除

将矢量信息映射到三维场景后, 将能更加准确的观察其空间形态及同一结构线在空间上的分布和延伸。由于在二维环境下的编录是针对单桩段的, 因此对于跨桩段的结构线存在重复编录的情况。而在三维场景下, 可以通过交互的方式, 合并同一条结构线信息。其实现方法如下:首先在场景中选取认为在空间上是同一条的结构线, 由于每条结构线绘制时都分配了一个唯一的ID, 通过此ID号获取其空间数据然后利用这些数据绘制空间上的一条结构线, 最后完成三维场景下的结构线合并。

同样, 可以根据拾取ID号的方法, 删除掉选取的编录信息。

在三维环境下增加结构线的实现方法, 是利用鼠标拾取坡面上的三维数据点, 并将其连接成线的方法, 在绘制完成的同时, 计算其产状, 确定该条结构线所属的图层, 并将其存入到相应的数据库中。

参考文献

[1]郑贵洲, 申永利.地质特征三维分析及三维地质模拟现状研究[J].地球科学进展, 2004 (2) .

[2]唐利民, 赵建三.道路地形动态三维可视化及相关属性查询研究[J].长沙交通学院学报, 2005 (3) .

[3]侯恩科, 吴立新.三维地学模拟几个方面的研究现状与发展趋势[J].煤田地质与勘探, 2000 (6) .

[4]奚大平, 江文萍.数字地图的三维可视化研究及其若干应用[J].地球科学.中国地质大学学报, 2002 (3) .

浅谈SQLserver查询优化 篇8

索引是常见的数据库对象, 它的设置好坏、使用是否得当, 极大地影响数据库应用程序和数据库的性能。在良好的数据库设计基础上, 能有效地使用索引是SQL SERVER取得高性能的基础。如果对于一个未建立索引的表执行查询操作, SQL SERVER必须进行表扫描, 从磁盘上读表的每一个数据页, 从而挑选出所有符合条件的数据行。特别是当一个表有很多行时, 就会浪费大量时间, 效率太低。然而在建立索引之后, SQL SERVER将根据索引的指示, 直接定位到需要查询的数据行, 从而加快SQL SERVER的数据检索操作。这样利用索引可以避免表扫描, 并减少因查询而造成的I/O开销。

1.1 簇索引

簇索引是对磁盘上实际数据重新组织, 以按指定的一个或多个列的值排序。一个簇索引是一个B-树, 其底层包含了表中所有的数据页, 并且数据的物理存储顺序与索引顺序完全相同, 亦即簇索引的数据是按照一定的物理排序方式来保存的。由于簇索引的索引页面指针指向数据页面, 所以使用簇索引检索数据要比非簇索引快, 而且它适用于检索连续键值。

由于数据存储于数据页中, 所以只能为每个表建立一个簇索引。而且创建簇索引要求数据库有足够的空间来容纳大约1.2倍于表中实际数据的数据。在簇索引下, 数据在物理上按顺序排在数据页上, 重复值也排在一起, 所以查询时一旦找到符合条件的第一条记录, 具有相同键值或后续键值的行一定在物理上与它连在一起, 而不必进一步搜索, 从而缩小了查询范围, 提高了查询速度。每个表只能建一个簇索引, 以下情况比较适合创建簇索引: (1) 用于范围查询的列; (2) 用于Order By或Group By查询的列; (3) 用于连接操作的列; (4) 返回大量结果集的查询; (5) 不经常修改的列 (对经常变动的列, 列值修改后, 数据行必须移动到新的位置) 。

1.2 非簇索引

对于非簇索引, 叶级页包括了到数据页和行的行定位器, 而不像簇索引中那样是真正的数据。它不对表中的物理数据页进行排序。因此, 创建一个非簇索引不要求必须有大的剩余空间。一个表最多可建立249个非簇索引, 但要注意, 表中索引数目太多, 会影响到其它操作的性能, 例如Update, Delete和Insert等。因此, 不要试图使用过多的索引, 一般而言, 对于一个表拥有一个簇索引和2-6个非簇索引就已经足够了 (数据仓库例外) 。每个非簇索引提供访问数据的不同排序顺序。以下为一些创建非簇索引比较合适的场合: (1) 用于集合功能的列; (2) 外部键; (3) 返回数据量小的结果集的查询; (4) 经常要通过在表连接中指定列的方式访问的信息, 或者查询中排序和组合需要的列。

1.3 复合索引

复合索引是通过两个或两个以上的列创建的键 (最大列数为16列) , 索引值的最大长度为900字节。不要试图创建列数过多的复合索引, 过多的列会影响性能并使索引键变大, 这样在读取索引键时要扫描更多的数据页。在复合索引中应首先定义最可能具有唯一性的列。那么SQL SERVER何时能充分利用索引的优势, 何时不能使用索引?

当对一个大型表进行操作时, 如果满足下列条件, 优化器就能充分利用复合索引: (1) 复合索引中的第一个字段或所有字段是在Where子句中引用的字段, 并且包含有用的搜索参数。 (2) 复合索引中的字段, 在Where子句中不参与任何形式的计算。

1.4 覆盖索引

当要查询的所有信息都包括在单独的非簇索引 (也即一个复合索引) 的索引项中时, 即为覆盖索引。SQL不用读取数据页来满足查询, 因为索引的叶级页中包含了所需的全部信息。当表的行数远远大于索引键的数目时, 可明显加快查询速度。但覆盖索引索引项较多, 占用空间较大。所以用覆盖索引要注意权衡利弊。

2 视图

2.1 标准视图

视图是一种数据库对象, 它是由用户从一个或多个表中建立的一个虚拟表。视图是SQL查询语句而不是用数据构造的。它可以用来控制用户对数据的访问, 限制用户从表中所检索的内容, 并能简化数据的显示。而且在大多数情况下用户所查询的信息, 可能存储在多个表中, 而对多表操作比较繁琐, 那么可通过视图将所需的信息设计到一个视图中, 以此来简化数据查询和处理操作。另外, 视图中的数据都来自于基表, 是在视图被引用时动态生成的, 使用视图可以集中、简化和定制用户的数据库显示, 用户可以通过视图来访问数据, 而不必直接去访问视图的基表。

在SQL SERVER中可能通过视图检索数据, 对视图可以使用连接、Group By子句、子查询等, 以及它们的任意组合来检索视图数据。

2.2 索引视图

索引视图在数据库中存储视图结果集。索引视图之后, 视图的虚拟成为真实:视图包含数据。索引视图可缩短对多个表和进行多个复杂连接的视图的查询时间, 来直接访问所需数据, 成为跨多个表格的超索引。此外, 查询优化器开始在查询中使用视图优化器, 而不是直接从From子句中命名视图, 这样可以从索引视图中检索数据而无需重新编码, 由此为查询带来高效率。但基础表更新数据时, SQL SERVER需要更新索引视图中的数据, 这个更新可能影响性能。只有当视图的结果检索速度的效率超过了修改所需的开销时, 才应在视图上创建索引。

2.3 分区视图

分区视图可以提高分布式数据的查询效率。在各个区域的服务器中都存有本区域仓库信息的Warehouse表, 这样在本地服务器上进行查询时可以大大地提高检索的效率。使用这种方法, 在进行很多查询时避免了和其它服务器通信。

但是, 有些查询不仅要访问本地仓库信息, 还要访问一个或多个远程仓库信息。分区视图提供了简单的解决方案, 因为它是含有分区数据的表的联合。每个仓库都可根据仓库的ID来辨别属于哪个服务器。例如, SERVER1服务器的仓库的ID在10001与19999之间, SERVER2服务器的仓库的ID在20001与29999之间。下列的语句说明如何在SERVER1服务器上为仓库数据创建一个分区视图:

因为本地的查询很少需要访问远端的数据, 因此这种优化器大大地提高了查询的效率。例如下列语句实现了SERVER1服务器上的一个查询:

分区视图使服务器组中的多个服务器之间可以实现并行处理, 这样, 数据可以分布在多个服务器之间, 查询时根据需要动态合并。它提供了访问不同地址保存的数据的强大功能, 但是管理和使用视图很复杂, 视图生成和使用的规则很多, 因此, 只有遵守所有规则, 才可利用其强大特性。

3 异步查询

异步查询是远程数据库对象 (RDO) 的一个特征 (RDO用于开发SQL SERVER数据库应用程序) , 它允许应用程序在等待完成长时间运行的查询时, 能够执行其它任务。这样就使得用户在执行其它操作之前, 不必等待查询的完成, 实现并行操作。

结束语

实现优化查询的方法还有很多。要根据具体情况来确定采用哪种查询方式, 注意权衡利弊, 以使数据查询性能达到最优。

摘要：简要分析了SQL server的查询优化方法。