本节书摘来自异步社区《ArcGIS Engine 地理信息系统开发从入门到精通（第二版）》一书中的第6章，第6.2节,作者： 邱洪钢 , 张青莲 , 熊友谊 更多章节内容可以访问云栖社区“异步社区”公众号查看。
6.2 空间数据库及组织
ArcGIS Engine 地理信息系统开发从入门到精通（第二版）
空间数据库系统是描述、存储和处理空间数据及其属性数据的数据库系统。空间数据库是随着地理信息系统的开发和应用而发展起来的数据库新技术。目前，空间数据库系统尚不是独立存在的系统，它与应用紧密结合，大多数是作为地理信息系统的基础和核心的形式出现。由于空间数据的复杂性和特殊性，一般的商用数据库管理系统难以满足要求。因而，围绕空间数据管理方法，出现了几种不同的组织方式。当前空间数据库的组织方式主要有两种：混合型空间数据库和集成型空间数据库，它们的区别在于是否对空间数据和属性数据进行一体化组织。
6.2.1 混合型空间数据库
目前大多数的地理信息开发平台就是采用混合结构型结构，即非空间数据存储在关系数据库中，空间数据存放在系统文件中。在空间数据库技术领域，比较有名的是MapInfo 公司和ESRI公司，其中的许多产品都是采用混合型的空间数据库，如商用系统MapInfo系列，ESRI的ArcView、ArcInfo系列等。这些产品分别使用不同的模块存储空间数据和属性数据。其空间数据在垂直方向上是分层进行组织的，空间数据在水平方向上是按图幅组织的。不同的是：MapInfo公司设计的产品中每一个图层由5个文件组成，而ESRI公司设计的产品中每一个图层只由3个文件组成。
这种混合管理的模式（即用文件系统管理几何图形数据，用商用关系数据库管理系统管理属性数据），它们之间是通过目标标识或者内部连接码进行连接。在这种管理模式中，几何图形数据与属性数据除了它们的ObjectID作为连接关键字段以外，两者几乎是独立地组织、管理与检索。就几何图形而言，由于GIS系统采用高级语言编程，可以直接操纵数据文件，所以图形用户界面与图形文件处理是一体的，中间没有裂缝。但对属性数据来说，则因系统和历史发展而异。早期系统中的属性数据必须通过关系数据库管理系统，图形处理的用户界面和属性的用户界面是分开的，它们只是通过一个内部码连接，导致这种连接方式的主要原因是早期的数据库管理系统不提供编程的高级语言，如Fortran或C的接口，而只能采用数据库操纵语言。这样通常要同时启动两个系统（GIS图形系统和关系数据库管理系统），甚至两个系统来回切换，使用起来很不方便。
最近几年，随着数据库技术的发展，越来越多的数据库管理系统提供有高级编程语言C和 Fortran等接口，使得地理信息系统可以在C语言的环境下直接操纵属性数据，并通过C语言的对话框和列表框显示属性数据，或通过对话框输入SQL语句，并将该语句通过C语言与数据库的接口查询属性数据库，在GIS的用户界面下显示查询结果。对于这种工作模式，并不需要启动一个完整的数据库管理系统，用户甚至不知道何时调用了关系数据库管理系统，图形数据和属性数据的查询与维护完全在一个界面之下。在ODBC（开放性数据库连接协议）推出之前，每个数据库厂商提供一套自己的与高级语言的接口程序，这样GIS软件商就要针对每个数据库开发一套与GIS的接口程序，所以往往在数据库的使用上会受到限制。
在推出了ODBC之后，GIS软件商只要开发GIS与ODBC的接口软件，就可以将属性数据与任何一个支持ODBC协议的关系数据库管理系统连接。无论是通过C，还是通过 ODBC与关系数据库连接，GIS用户都是在一个界面下处理图形和属性数据，它比前面分开的界面要方便得多。但这种采用文件与关系数据库管理系统的混合管理模式，还不能说建立了真正意义上的空间数据库管理系统，因为文件管理系统的功能较弱，特别是在数据的安全性、一致性、完整性、并发控制以及数据损坏后的恢复等方面缺少基本的功能。多用户操作的并发控制比起商用数据库管理系统来要逊色得多，因而GIS软件商一直在寻找采用商用数据库管理系统来同时管理图形和属性数据。
文件系统结构简单，在数据存取过程中几乎没有额外开销，并且可以按照用户的需求任意定制数据存储格式或存储复杂数据结构。但其缺点也很明显，即数据冗余度大、难以共享数据、容易造成数据的不一致性、程序与数据缺乏独立性、系统不易扩充。
这些产品虽然在功能上达到了空间信息处理的要求，但由于没有从DBMS 的核心部分，即数据结构部分来考虑空间信息的特殊性，所以处理的效率受到了很大的限制。
6.2.2 集成型空间数据库
近来国外提出的一种集成型结构，是将所有的数据都存储于一个数据库中。由于其采用的数据库原型不同，所以集成性空间数据库的类型也大不相同。
（1）全关系型数据库模型。
全关系型空间数据库管理系统是指图形和属性数据都用现有的关系数据库管理系统管理。关系数据库管理系统的软件厂商不作任何扩展，由GIS软件商在此基础上进行开发，使之不仅能管理结构化的属性数据，而且能管理非结构化的图形数据。其设计思想是把构成空间对象的每个基本元素（点、线段）对作为一行记录存入表中，通过关系模型来维护其空间属性的内部结构以及空间对象之间的拓扑关系。
用关系数据库管理系统管理图形数据的模式有两种，一种是基于关系模型的方式，图形数据按照关系数据模型组织。这种组织方式由于涉及一系列关系连接运算，相当费时，因此在处理空间目标方面效率不高。另一种方式是将图形数据的变长部分处理成Binary二进制块 Block字段。目前大部分关系数据库管理系统都提供了二进制块的字段域，以便管理多媒体数据或可变长文本字符。GIS利用这种功能，通常把图形的坐标数据，当做一个二进制块，交由关系数据库管理系统存储和管理。这种存储方式虽然省去了前面所述的大量关系连接操作，但是二进制块的读写效率要比定长的属性字段慢得多，特别是涉及对象的嵌套时，速度则更慢。
关系型数据库（RDB）有强大的关系理论支持，无疑是数据库产品中最成熟的。由于它是基于几种简单的基本类型和简单的二维表，因此它能完成非常复杂的关系操作，并能得到几乎任何期望的信息组合。它的优点也是很明显的，第一，物理数据存储与逻辑数据库结构的独立性；第二，多样、简易的数据访问能力，从而提供了高效数据访问的可能性；第三，相当灵活的数据库设计；第四，数据存储和冗余的减少。
采用关系数据库来管理地理信息是 GIS与数据库结合的初步尝试，但其中存在两个难题：首先，难以在关系数据库中存储空间数据，为了存储和表示结构复杂多变的空间数据，需要设计复杂的 E－R模型，并在数据库中存放大量的表，这样会增大系统的复杂性，而且还无法利用数据库提供的索引机制；其次，难以保持地理信息的数据一致性，由于地理信息的空间数据和属性数据通常不能存放在一张表里，因此这样会割裂逻辑上为一个整体的地理信息，而且拓扑关系也难以维护。
由于存在上述难题，虽然关系数据库在与GIS的结合中做出了有益的尝试，但最终还是没能成为主流。为此，随着面向对象型数据库（OODB）的出现与发展，人们提出了面向对象型数据库与GIS相结合的方案。
（2）面向对象数据库。
面向对象模型最适于空间数据的表达和管理，它不仅支持变长记录，而且支持对象的嵌套、信息的继承与聚集。面向对象的空间数据库管理系统允许用户定义对象和对象的数据结构以及它的操作。这样，我们就可以将空间对象根据 GIS的需要，定义出合适的数据结构和一组操作。这种空间数据结构可以是不带拓扑关系的面条数据结构，也可以是拓扑数据结构，当采用拓扑数据结构时，往往会涉及对象的嵌套、对象的连接和对象与信息的聚集。
虽然面向对象数据库屏蔽了原有的关系理论，具有完全面向对象的特征，具有很强的理论优势，但其商业化产品则侧重于程序设计语言对复杂数据的访问，同时还存在查询表达能力不强、查询效率比较低的问题。而且由于其中的许多技术细节还不够成熟，因此目前OODB还难以用于与地理信息系统应用相关的领域。
（3）对象—关系模型数据库。
对象—关系模型数据库（ORDB）是面向对象思想与数据库管理系统相结合的一个折中产物，它与OODB的区别在于，它没有抛弃关系理论，而是在关系模型的基础上，进一步支持了面向对象思想。这样不但继承了关系模型的优良特性，并兼容了原有的使用关系数据库的软件系统；而且提供了支持面向对象的类型与接口，也满足了面向对象软件系统的要求。不论在科学研究中，还是在实际应用中，它都占有重要的地位，是当前数据管理技术的中流砥柱。ORDB在与 GIS结合的过程中，具有如下明显的优势：① 支持基本类型扩充；② 支持复杂对象；③ 支持继承；④ 支持规则。这样，通过对对象存储访问的支持，不仅解决了关系型数据库所面临的难题，同时通过兼容关系数据库系统，保证了对现有运行系统升级的可能性。而最为重要的是，ORDB已经拥有比较成熟的商业化产品，这为它与 GIS的结合打下了良好的基础。
对象—关系模型把关系理论与面向对象思想有机结合，不但继承了关系系统优良的特性，还提供使用面向对象方法建模的能力，满足了用户对数据库表达能力的要求。
① 空间扩展模型。
此方案是基于对象—关系模型数据库而建立的。它通过建立一个空间对象表达模型，把空间数据和属性数据存储统一在DBMS之下，从而把GIS的数据管理部分的功能统一到DBMS之中，由DBMS完成数据层功能。其模型的重点在数据库上，希望通过增强数据库的空间功能而从根本上解决问题。这种扩展的空间对象管理模块，主要解决了空间数据变长记录的管理。由于由数据库软件商进行扩展，因此效率要比前面所述的二进制块的管理高得多。空间扩展模型体现出了两个优势：一是由数据库厂商支持的数据分析操作可以得到数据库系统内部优化机制的支持，因而效率较高。二是该模型在DBMS层为访问空间对象提供了统一的接口，也方便了系统从RDB到ORDB的移植。
但是，它还存在着技术不成熟的问题，如它仍然没有解决对象的嵌套问题，空间数据结构也不能由用户任意定义，不能提供对象—关系系统应具有的所有功能。同时空间扩展模型是数据库厂商提供的解决方案，它希望通过增强数据库的空间功能来从根本上解决问题。由于该方案是由数据库厂商开发的，因此能够比较充分地利用底层数据库，从而达到比较好的性能。但是，数据库的空间扩展毕竟是数据库系统的附属产品，它不但继承了底层数据库的优势，也受到底层数据库的制约。例如，只有几个大的数据库厂商提供对空间扩展模型的支持，而这些数据库产品又只能应用于比较大的应用系统中，这样空间扩展模型也就难以投入到中小应用中去。因此这种模型的使用仍然受到了一定程度的限制。
② 基于中间件的数据库模型。
此方案也是基于对象—关系模型数据库而建立的，其本质就是在数据库和最终用户之间增加中间件，通过中间件层实现从空间对象模型到数据库存储的映射，从而避免了对DBMS内核的直接修改，以消除数据库和最终用户间接口的差异，这样一方面能充分利用数据库提供的功能，另一方面也能满足用户最终的需求。这种模型的典型例子是ESRI的ArcSDE。
中间件的主要任务就是分析并执行空间对象访问命令，为GIS 应用提供一个一致且稳定的接口。基于中间件的数据库模型一般包括用户、中间件、数据存储层等3个层次。其中，用户使用地理信息，数据存储层负责存储地理信息，而中间件则负责用户与数据库之间的数据访问管理。对上层（GIS应用及SDSS应用）的接口，提供完整的空间对象管理功能，统一管理空间属性和用户属性。对下层（数据库）的接口，则将空间属性与用户属性分开管理，空间属性的管理功能由中间件和DBMS共同实现，用户属性的管理功能则由DBMS直接实现。由于支持面向对象方法，因此中间件为空间对象提供了统一的访问接口，同时中间件可以实现DBMS不能完成但效率不高的部分。
基于中间件的数据库模型则是GIS厂商提供的解决方案，它希望通过提供灵活方便的接口来适应多变的应用需求，即通过设计中间件来封装数据管理部分，以提供对多种类型数据源的支持。这虽然降低了GIS应用开发的复杂度，但是，增加中间件也势必在空间数据存取中增加了额外开销，从而影响系统的整体效率，另外，构造并维护中间件的人力物力投入也不容忽视。与空间扩展模型相比，中间件模型是一种以性能换功能的方法，但它在当前的应用中却又是相当有效的。其特点也是很明显的，主要表现在以下几个方面。
- GIS 应用接口稳定，使得基于它的GIS 应用也具有较强的稳定性。
- 易于裁剪，采用构件方式实现可以进行多层次的裁剪，以取得良好的性能/功能比。
- 数据库接口统一，不依赖于特定的数据库产品。
- 易于扩展，可以针对效率问题在中间件层提供一定的优化，如智能CACHE 技术、空间索引过滤和查询优化，可以针对领域应用扩展功能，比如为了满足空间数据库在SDSS 中的特殊要求，还可以在中间件层添加辅助空间数据挖掘的调用模块和支持空间知识库系统的调用模块等。
从本质上看，基于中间件的数据库模型和空间扩展模型的目的都是一样的，即都要为 GIS应用提供方便高效的服务，都要提供一个空间对象的统一访问接口。而它们的区别在于，基于中间件的数据库模型是对应用需求的直接响应，也是空间扩展模型的基础，而空间扩展模型则是基于中间件的数据库模型的总结与改进。相比之下，由于基于中间件的数据库模型具有灵活的结构，所以它不但在研究方面很有潜力，而且可以方便地实验各种数据管理技术。
