技术文章 > 基于RDBMS的空间数据库的设计与实现

基于RDBMS的空间数据库的设计与实现

2018-10-22 11:56

文档管理软件,文档管理系统,知识管理系统,档案管理系统的技术资料:

陈俊华 宋关福 李绍俊
[摘要]基于关系型数据库(RDBMS)来进行空间数据的存储和管理,目前已经成为构建空间数据库的主流技术。本文介绍了空间数据存储方式的演变以及不同存储方式的优缺点,并且阐述了基于RDBMS来构建空间数据库的的一些关键技术。
[关键词]
关系数据库 空间数据引擎 面向对象 可排序四叉树编码
1.空间数据的特征
数据是信息系统的基础,一般认为数据是信息的载体,信息是数据的内涵。利用计算机来处理数据,提取信息是信息系统的基本功能。GIS处理的主要是和空间位置、空间关系有关的数据。一般来说,数据具有以下基本特征:
  u 选择性。数据从某一(些)侧面描述事物本身。
  u 可靠性。有很多原因影响数据的可靠性,比如数据在获取,存储,管理,传播过程中会出现差错,导致数据的失真。必须保证数据的可靠性。
  u 时间性。事物是动态的,发展的,数据只能反映事物在某个时间态下的状态。关于数据时间性的研究比较多,也有一些专著。
  u 完备性。数据的不完备往往导致分析结果的不完善,甚至会造成决策失误。
  u 详细性和综合性。
  空间数据除了具有一般数据的特征之外,还具有一些区别于其他数据的特性。构成空间数据的特征主要有:
1.1 空间性
这是空间数据最主要的特性。空间数据描述了空间物体的位置、形态,甚至需要描述物体的空间拓扑关系。例如描述一条河流,一般数据侧重于河流的流域面积,水流量,枯水期等。而空间数据则侧重于河流的位置、长度、发源地等和空间位置有关的信息。复杂一点的还要处理河流与流域内城市间的距离、方位等空间关系。空间性是空间数据区别于其他数据的标志特征。
1.2 抽象性
空间数据描述的是现实世界中的地物和地貌特征,非常的复杂,必须经过抽象处理。不同主题的空间数据库,人们所关心的内容也有差别。所以空间数据的抽象性还包括人为地取舍数据。抽象性还使数据产生多语义问题。在不同的抽象中,同一自然地物表示可能会有不同的语义。如河流既可以被抽象为水系要素,也可以被抽象为行政边界,如省界,县界等。
1.3 多尺度与多态性
不同的观察尺度具有不同的比例尺和不同的精度,同一地物在不同的情况下就会有形态差异。最典型的例子有:就形态而言,任何城市在地理空间中都占据一定范围的区域,因此可以认为其是面状地物,但在比例尺比较小的空间数据库中,城市是作为点状地物来处理的。
1.4.多时空性
GIS 数据具有很强的时空特性。一个GIS 系统中的数据源既有同一时间不同空间的数据系列;也有同一空间不同时间序列的数据。不仅如此,GIS 会根据系统需要而采用不同尺度对地理空间进行表达。GIS 数据是包括不同时空和不同尺度数据源的集成。
2.空间数据存储方式的演变
陈述彭先生曾经指出,地理信息系统脱胎于计算机制图。早期的空间数据存储比较凌乱,往往以存储地图的形式来存储数据。在存储空间数据的同时,还保存空间数据的拓扑关系。例如早期Arc/Info所采用的”节点—弧段—多边形”的数据模型。这种数据模型处理单个对象的能力很弱,修改一个的对象时候,会牵涉到其他的对象。由于需要维护拓扑关系,对空间数据的更新修改比较麻烦。
  需要指出的是,由于CAD软件在制图方面的优势,部分GIS的人员选用CAD软件作为制图系统。大量的GIS数据是存储在CAD文件中的,如Autodesk的DWG文件格式。但是CAD系统所管理的数据文件一般情况下都比较小,(如Microstation的DGN格式,数据量最大不超过32M,DWG文件很少超过100M的),无法满足GIS系统的大数据量要求。
  以空间数据表示的地物不仅具有空间信息,而且具有很多的非空间的附属信息。如城市的人口,国民生产总值等,这些构成了地理元素的属性信息。在早期的文件中,由于存储空间数据和属性数据所采用的格式不同,在GIS系统中一般都将其分开存储。这样,维护两者的一致性并进行一体化管理便成为必须解决问题。
  随着面向对象思想的出现和面向对象方法学的应用,人们开始用面向对象的思想来进行空间数据模型的设计。按照面向对象思想,每种地物都可以被抽象为某一类具有公共属性的对象,如点,线,面等,具体的地物则是该对象的一个实例,它还具有自己的属性。各种对象分层管理。这样就解决了空间数据与属性数据的一体化管理。
  早期的文件都是针对专门的软件的,各个GIS软件厂商都有自己的文件格式,无法共享数据。随着GIS的发展,出现了一些数据格式标准化组织,提出了统一空间数据编码的思想,以便在不同GIS系统之间的进行数据交换。但各种文件格式之间的数据转换依然费时费力,这就导致了GIS系统的建设成本居高不下。对于GIS厂商来说,由于需要文件格式的升级和向下兼容,导致开发负担大大加重。
  在其他的信息系统建设中,人们也碰到了同样的问题,这就要求数据的存储需要有统一的标准,以便于维护与升级并提供开放式的管理方法。于是,关系数据库系统应时而生。借助于标准的SQL语言与ODBC和后来的ADO等技术,使人们获得了比较满意的解决方案。
  由于空间数据的特殊性,它要处理的数据都具有空间特征和空间关系,难以在关系模型中表达。利用关系数据库来存储空间数据在理论与技术上的遭遇了暂时的困难。这个阶段,有些系统开始利用关系数据库来存储属性数据,而空间数据保持原有文件结构不变,通过在空间数据和属性数据之间建立关联的方法架起二者的桥梁。如在MicorStation中,可以通过设立MSLink属性与外部数据库连接。
  纵观计算机的发展,最初的数据是适应特定的系统的,每一个系统都拥有自己的数据格式。并有特定的数据结构来适应程序和算法,这时考虑的重点是系统的专有性;随着数据量的增多,数据共享需求的提出,数据的重要地位越来越突出,各个系统开始考虑数据的统一问题,并且提出了一些改良方案。最后初步形成了目前集各种技术之大成的空间数据库系统,标志空间数据库技术和空间数据库系统的初步成熟。而且,基于关系数据库或者对象关系数据库的空间数据管理正在逐步成为GIS发展的潮流。
3.面向对象与关系模型
关系理论的研究与应用都已经比较成熟,面向对象方法学更是在现代软件的设计和开发中发挥了至关重要的作用。如何将两者结合来设计数据库系统也是当前研究的热点。基于空间数据面向对象的特性,在利用RDBMS存储空间数据时,我们显然希望结合两者的优点,设计出符合要求的数据库系统。
  考察一下关系模型和面向对象两种理论的特点,我们将会发现,关系模型描述关系时,采用的是”实体——关系”模型(E-R模型),使用SQL语句进行检索,侧重点是对象之间属性的聚集。也就是说,实体对象模型描述的是实体的外在特征的关联,对于空间数据的属性查询,这是非常理想的解决方案。但是,我们知道,空间数据的之间的空间关系是他们的内在联系,是由空间地物的地理位置关系决定的,并且往往是多对多的、错综复杂的关系。在描述这种关系时,目前的关系模型就不是很理想了,要完成空间关系的查询还相当的困难。为此,许多的GIS研究都提出了与SQL相类似的”空间查询语言”(Spatial Query Language),但目前仍处于不成熟的阶段。
  再看面向对象理论,以抽象性、封装性、多态性来描述对象。对象具有方法和属性,对象之间的关系是通过消息机制来沟通的。用面向对象的方法来处理空间物体之间的关系是比较自然的。OpenGIS定义了一组空间关系算子,包括了各种对象的空间关系。在对象中实现了这些算子,基本上就可以描述对象之间的空间关系了。对象的空间位置判断已经有了一些比较成熟的算法和程序。在SuperMap2000中,就设计了一些非常高效的算法,实现了这些功能。
  面向对象与关系模型对于空间关系的描述能力,是截然不同的。我们不难看出,关系模型侧重于描述对象的外在联系,反映的是对象的聚集。面向对象可以处理对象之间的关系,但处理对象的属性的能力又不如关系模型。基于以上分析,当前的地理信息系统中,真正实现空间数据与属性数据一体化管理是有一些不足的。使用SQL语句难以做到空间关系和属性特征联合查询。这就涉及到了空间索引的SQL表达问题。
4.空间数据的检索
空间数据的组织,关键是数据的索引与检索。空间索引的性能优劣直接影响空间数据库和地理信息系统的整体性能,它是GIS的一项关键技术。(参见引文[2]:空间信息查询)
  对于空间索引,学者研究得较多,常见的有BSP树、K-D-B树、R树、R+树、CELL树、四叉树等。除此之外,简单的网格型的空间索引也有着广泛的应用。如ESRI的软件ArcSDE就使用了一种改进的网格索引。关于各种空间索引的优缺点,可以参考文献4。 网格索引是多对多的索引,即一个几何对象可能跨越/穿越多个网格,而一个网格往往包含多个几何对象。多对多的关系会导致冗余,因为一个对象的ID 号可能被多个网格重复地记录。不仅是存储上的冗余,在搜索算法上也要进行额外的排重处理。网格划分的越细,搜索的精度就会越高,当然冗余也越大,耗费的磁盘空间和搜索时间也越长。网格划分的精细程度取决于几何对象的大小和数量。当被索引的对象大小差别很悬殊的时,网格索引会遇到另外一个难题:网格划分小到什么程度合适?过于精细,会导致冗余太大,索引数据的存储量也可能成倍增加,甚至索引的存储量会超过数据本身,此时如果进行大范围查询,也会影响速度;过于粗略,小对象不能精确定位,过多的几何对象落在同一个网格上,降低了搜索的准确度。有些软件采用多重网格索引来避免这一问题,在一定程度上提高了搜索速度的同时,也导致了更多的数据冗余。
  在SuperMap2000中SDB格式的数据文件采用了四叉树编码作为空间索引,以数组的方式存储树的结构[3],在树的节点上存储各个空间对象的编码(ID值)。这在文件中很方便存取和检索。然而,这种多对一的关系不符合关系模型的范式。如何在关系数据库的结构(表)中实现四叉树编码呢?也就是说,能不能以表格的方式来管理四叉树索引呢?更进一步的要求是,我们希望利用SQL语句来检索四叉树。自然的,我们会想到,先用四叉树检索出所有ID,如某个查询窗口对应的空间数据有1000条,我们的SQL语句就可以这样:”Select * From tablename Where ID IN [….];”这样的SQL语句会遇到一个问题:检索出来的数据量非常巨大时,可能SQL语句会超过允许的长度。
  
            图1、仅仅划分两次形成的四叉树的编码
  因为普通的四叉树编码难以转化成SQL语句检索,SuperMap创造性的提出了可排序四叉树编码。我们利用可排序四叉树编码规律,将检索转换成SQL语句的条件,查询出相应的子集来。可排序四叉树的增加节点,删除节点等操作都非常简单,只要计算出编码值,与空间数据对应起来就可以了,所以可排序四叉树编码作为表的一列存储。
  假设某个节点位于四叉树的第n层,它的可排序四叉树编码Index.。它的四个子节点位于树的第n-1层,编码分别为:LL_Index,LR_Index,RL_Index,RR_Index.,则他们之间有如下关系:
  LL_Index = Index – 3 * 4(n-1);
  LR_Index = Index – 4(n-1);
  RL_Index = Index + 4(n-1);
  RR_Index = Index + 3 * 4(n-1);
  可排序四叉树编码的特性之一是通过编码值,很容易确定节点在树中的层数。在进行查询时,给定一个查询窗口(Rectangle),这个查询窗口唯一的对应一个四叉树节点。通过节点的编码,我们如何确定在这棵子树下的所有子节点呢?有二种方法:
  通过编码值位运算。但有些RDBMS不支持位运算的SQL语句,所以在空间数据引擎中难以实现通用性,只能应用于特定的RDBMS,如MS的SQL SERVER;
  通过计算,找出子节点的大小范围。大小比较的SQL条件查询是高效率的。
  找子节点的范围的程序伪代码如下:
   GetIndexRange(long Index,var long Min,var long Max)
   {
     long n = GetLayerNum(Index);
     Min = Max = Index;
     While(n>0)
      {
        Min = Min – 3 * 4(n-1);
        Max = Max + 3 * 4(n-1);
        n = n –1;
      }
    }
    
     图2、四叉树检索需要对查询窗口进行优化
  需要指出的是,可排序四叉树检索需要对查询窗口进行优化(图2)。虚线的查询窗口可以分割成四个小窗口分别查询,最后的结果就是四个子集的并集。窗口优化的程序也很容易实现,在此不再给出。
  在获得子树下所有节点编码的范围以后,利用SQL语句(Select * From tablenane Where(ID>Min and ID  可排序四叉树编码与网格型索引相比,具有如下优点:
  u 节省存储空间。网格索引需要存储对象的空间范围(上,下,左,右),四叉树存储的是一列四叉树编码。
  u 减少索引列数,提高效率。网格索引有四个字段建立索引。
  u 变浮点运算为整型运算,提高了效率。网格索引存储的是坐标,四叉树索引的编码小于32位,并且是整数。
  u 编码唯一。任何对象的编码值都是唯一的,网格索引难以确定网格的大小,需要非常有经验的数据库管理员才能对索引进行优化。
  u 客户端计算空间索引值,分担服务器的CPU计算任务。
5.网络传输:数据压缩与客户端缓存技术
GIS管理的是海量数据。目前处理大量数据的关系数据库已经比较成熟,形成了工业标准。依赖于关系数据库系统的巨大的数据处理能力存储空间数据基本上可以满足工程项目的需求。GIS系统性能的高低很大程度上还与网络的传输速度有关。网络的负载就是传输的数据量的大小。通过数据压缩可以大大的降低网络的传输量,从而提高系统的性能。
  对于数据的压缩,具有很多算法。但是,当前研究比较多的是声音、图像、动画等多媒体数据的压缩。例如,基于小波变换的压缩算法,可以使影像数据的压缩率达到50:1,甚至更高。对于矢量数据,在关系数据库中,比较好的存储方法是二进制数据块。对于二进制块数据,压缩算法也很多,比较常见的有LZW算法、Huffman算法、Zip算法等。如Huffman算法,对于二进制数据块的压缩率,一般在40%左右。也就是说,压缩后空间数据的存储容量能够减少一半多。所以采用数据压缩是降低存储空间和网络负载的有效途径。数据压缩以后,在网络上传输,还提高了数据的安全性和保密性。特别是通过Internet访问远程数据库时候,网络传输往往是系统的瓶颈所在,传输的数据量越少,系统的性能越高。SuperMap2000在开发的过程中,集成了多种压缩算法,如压缩影像数据的工具MrSID,ECW。矢量数据也采用了压缩。
  当然,经过压缩的数据需要解压缩。在客户端接受数据后,需要把它解压缩出来,这将花费一些CPU时间。一般来说,压缩率越高,算法越复杂,压缩和解压缩的时间也越长。在具体的工程系统建设上,需要区别系统的瓶颈,采取不同的压缩算法,甚至也可以不压缩。例如,在企业内部的Intranet上,网络速度可以达到100M,与本地数据访问的速度相差不大,数据的安全性要求也很容易得到满足,就可以不压缩存储。SuperMap提供压缩存储与否的选择,具体工程项目中可以灵活选择。
  空间数据的检索,可能返回一个很大的记录集,达到几十万甚至上百万条纪录。例如,查询全国水系,就有大大小小的河流。检索出来的记录集如何传送到客户端呢?如果客户端需要把整个记录集全部接受下来,将会极大的消耗系统资源。并且,数据的传输耗费时间长,客户端需要进行长时间的等待。如何避免这种情况呢?我们采用了异步传输和客户端缓存的技术,较好地解决了这个问题。
    
          图3、异步缓存的示意图
  如上图,服务器查询出记录集后,把记录集放系统缓存中,启动传输进程。同时,客户端接受数据,等缓存中有数据后,客户机程序开始处理数据,接受数据进程转到后台运行。所谓异步传输,是指传输数据和处理数据是异步进行的,数据先行传到客户端缓存。需要处理时,再从缓存中读取。客户端处理完毕后,释放系统资源,所以,客户端的系统消耗可以降低。数据的传输与处理异步同时进行,客户端无需等待。
  在SuperMap2000的空间数据引擎中,通过这两项技术的使用,降低网络传输负载,提供系统性能,起到了很好的效果。
6.优点和应用范围
利用关系数据库存储空间数据,具有很多优点,下表列出了两种方式的对比:
特 点 文件方式 基于RDBMS的空间数据库
海量数据管理 可以 擅长
空间与属性数据一体化 难于实现一体化,需要通过连接实现一致性维护 一体化
开放性 特殊格式 工业标准,开放式管理
可扩充能力 弱 强
多用户并发 难于实现 很强的并发控制能力
数据维护与更新 文件数量多,管理困难 只需一个数据库
权限控制 弱 强
  基于RDBMS的空间数据库技术,对于多用户、大数据量的GIS应用,有着较大优势。基于RDBMS的空间数据库技术在部门GIS和企业级GIS的建设中,可以降低系统的复杂程度,提高开发效率,提高系统的性能。基于RDBMS的空间数据库技术还为WebGIS的建设提供数据支持,使其远程访问数据的能力得到提高。实现WebGIS时,制图服务器和数据管理服务器可以保持相对的独立以优化系统结构。作为SuperMap2000的一部分,基于RDBMS的空间数据库技术(引擎)已在多个大型项目中得到了成功的应用。
[参考文献]
[1] 郭仁忠.《空间分析》.武汉测绘科技大学出版社.1997 .1
[2] 陈述彭,周成虎等.《地理信系统导论》.科学出版社. 2000. 1
[3] 宋关福.《组件式地理信息系统研究》.中国科学院地理研究所博士论文,北京,1998
[4] 宋关福.《组件式地理信息技术研究》.中国科学院