土地信息系统数据库分布式设计与实现

1　关于土地信息

　　用关系数据库与空间数据库协同管理土地数据，是近年来土地信息系统的分布式处理的常用方法之一，其分布式实现主要依赖于关系数据库（如Oracle）所提供的分布式功能。

　　本文将详细阐述土地信息系统中基于Oracle的关系数据库分布式设计及空间数据分布式处理的实现。

　　2　Oracle系统的分布式设计技术

　　2.1　分布式Oracle系统构架

　　分布式Oracle系统是由分布式数据库管理系统（Oracle Rdbms）、支持多种操作系统和通信协议的分布式处理环境软件SQL*NET、以及与非Oracle Rdbms联接的软件SQL*CONNECT组成的一个软件群［2］。其中，Oracle Rdbms的分布式功能主要包括分布式查询、单点事务、多个事务中多点更新及结点自治等；SQL*NET提供不同Oracle数据库间的连接功能；SQL*CONNECT是实现Oracle与其它DBMS转换的一个接口产品。

　　2.2　SQL*NET

　　SQL*NET是Oracle分布式处理的基础，其体系结构如图1所示。通过SQL*NET，一个应用程序可以并行存取本地或远程的多个数据库。当存取远程数据库时，在客户端，SQL*NET将来自用户程序接口（UPI）层的子程序调用（SQL语句）组装成信息报文，经过异种机环境所需要的数据转换后，通过网络将报文发送给远程计算机；在服务器端，SQL*NET接受报文，作必要的数据转换，并将子程序调用参数传送到适当的Oracle核心入口点，在相反方向上服务器端驱动SQL*NET传送的是数据和返回码信息［1］。

　
图1　SQL*NET体系结构

　　2.3　各类数据库对象

　　Oracle中与分布式处理有关的数据库对象主要有：数据库链路、视图、快照、同义词等。其中，数据库链路用于连接本地结点和远程结点之间的数据库；数据快照是Oracle系统提供的一种对数据表的异步复制，它有以下两种作用：数据快照是远程数据表在本地的复制，通过它可以实现对远程数据的快速查询；在系统或网络出现故障时，可以通过数据快照恢复数据。

　　同义词用来简化一些繁琐的表名或视图名等。对于远程操作，用户也可以为远程数据库的表名或视图名等建立相应的同义词，以后访问这些远程数据库的表或视图就可以直接写同义词名，也就是说用户在访问数据时无须指明数据所在结点的名字，这就达到了透明访问。例如，在某一结点访问另一结点的数据表时需要命令：

　　SELECT*FROM SUPDBA.EMPLOYEE@SUP—HQ；

　　如果建立如下同义词：

　　CREATE PUBLIC SYNONYM EMPLOYEE FOR SUPDBA.EMPLOYEE@SUP—HQ；

　　再访问该远程表时就只需要命令：

　　SELECT * FROM EMPLOYEE；

　　2.4　分布式操作

　　在数据库链路定义以后，远程操作就变得非常简单和方便。用户访问远程数据库的表或视图时，只要在表名或视图名后面附上数据库链路名即可通过SELECT或INSERT、UPDATE、DELETE等语句对数据进行操作。其形式为：

　　SELECT 列表达式［,列表达式,...］

　　FROM 表名@数据库链路名［,表名@数据库链路名,...］

　　［WHERE 逻辑表达式］；

　　在访问数据时，如果要访问的数据来自同一个数据表，根据需要直接访问该表或基于该表的视图或快照；如果所要访问的数据来自不同的数据表，可通过连接（JOIN）操作或相应的视图来实现，视图中各数据项的来源有以下几种情况：

　　来自同一数据库中的一个表或多个表；

　　来自同一结点不同数据库中的两个表或多个表；

　　来自不同结点上数据库中的两个表或多个表。

　　如果事先建立了有关视图，用户就可以直接访问这些视图以实现一些对数据的复杂访问。

　　3　数据库分布式设计的基本步骤

　　3.1　确定数据的物理位置

　　在分布式数据库环境中，对每一数据表都要首先确定其最佳的存放位置，从而使整体数据的分布更加合理。在这一过程中，需要考虑的因素主要有以下几点：每一结点需传递的事务量；每一结点使用的数据量；网络的性能与可靠性；各结点速度、磁盘容量；若结点间连接不通后的访问规则；表间联系对数据完整性的影响等。

　　3.2　确定数据库及其对象

　　对每一存放数据的独立结点都要建立至少一个数据库，对于不同的应用，在同一地点也可以建立多个数据库。在每一数据库中还要根据实际需求建立有关的数据库对象，如Oracle中有关数据库对象有Table、View、Snapshot、Synonym、DatabaseLink等。

　　3.3　确定数据存取机制

　　分布式数据库的一大重要特点是数据访问的透明性。在应用系统中，不同的功能会需要访问不同数据库中的数据。为了达到数据访问的透明性，在分布式数据库设计时就需要确定如何存取其它数据库中的数据，如何实现不同数据库中数据表的链接等规则。

　　4　土地信息系统数据库的设计

　　深圳市土地管理信息系统（以下简称SZLIS）是一个面向深圳市规划国土局土地管理业务的集成化分布式信息系统。由于该局行政上采用市局——分局——管理所三级运作模式，土地管理业务分布在三级管理部门，因此SZLIS系统中的分布式处理至关重要。由于Oracle难以管理空间数据，地理信息系统软件ARC/INFO不支持分布式处理，故考虑二者结合来管理，即系统中非空间数据用Oracle管理，空间数据用ARC/INFO管理。

　　4.1　SZLIS体系结构

　　SZLIS运行在由七个局域子网构成的广域网上。七个局域网分别分布于深圳市规划国土局市局和六个分局，管理所采用电话拨号上网连接到分局数据库中。系统在市局和六个分局的服务器中分别建立七个数据库。

　　SZLIS的主要功能包括：管理业务文件的流转及办理过程；用地申请的处理和批复；用计算机进行出让地块的划界和对用地空间与文字属性的管理；进行红线图、方案图以及其它图件的制作与输出；制定地价方案，编制土地使用权出让合同书；对与土地有关的各类、各层次信息的查询功能等。在SZLIS中，市局、分局和管理所都有以上功能，且市局可以查询及审批各分局的业务数据，三级部门之间要互相流转文件。

　　4.2　数据说明

　　根据系统的功能需求，SZLIS中的数据及其使用情况分为以下几类：

　　类型一：人员、部门、岗位、任职、单位等做参考用的数据，全局统一一份数据，更新量少，市局、分局都能更新；

　　类型二：文件内容、办理过程等与文件流转相关的数据，市局和分局都会收文，且市局、分局、管理所三级之间要转文；

　　类型三：业务属性数据，如红线、宗地属性、界址点、地价方案、土地出让合同属性等，主要业务在分局办理，部分大型业务在市局办理，部分小型业务在管理所办理；

　　类型四：图形数据，包括红线、宗地等地块的图形数据。

　　SZLIS中的图形数据用ARC/INFO管理，ARC/INFO提供接口与Oracle管理的属性数据相连接。为了实现图形数据与属性数据的有效连接，以及利用图形数据查询或更新属性数据，除通过建立ARC/INFO 与Oracle系统之间的连接外，还需利用RELATE关系建立各COVERAGE的INFO属性表（AAT和PAT）与Oracle数据库中的属性表（table）之间的关联关系，即在ARC/INFO的AAT或PAT表与Oracle表中分别建立公共的标识项，通过这些公共的标识项把AAT或PAT表中的记录与相应Oracle中的对应记录挂接起来。

　　4.3　分布式设计

　　根据系统对分布式的需求，SZLIS中数据库分布式设计方案如下：

　　对于类型一数据，市局数据库中建立数据表，分局数据库中建立对市局表的快照和视图，对这些数据的大部分修改在市局进行，分局通过视图修改这些数据，通过快照查询这些数据；对于类型二数据，市局和分局的数据库中分别建立数据表，数据存放在数据的产生地，如果市局向分局转文，则有关此文的文件内容、办理过程等数据都拷到分局的数据库中，反之亦然；对于类型三数据，数据存放在分局的数据库中，在市局的数据库中分别建立对六个分局数据库的DATABASE LINK，市局通过视图创建或修改这些数据，通过快照查询这些数据；分局和管理所系统登录到对应分局的数据库，直接对业务数据进行操作。以宗地属性数据为例，在分局建立表PARCEL，分局操作此表，在市局建立视图和快照如下：

　　CREATE VIEW V$PARCEL—LH AS SELECT * FROM SUPDBA.PARCEL@SUP—LH;

　　CREATE SNAPSHOT S$PARCEL—LH

　　PCTFREE 5 PCTUSED 60

　　TABLESPACE users

　　STORAGE INITIAL 50K NEXT 50K

　　USING INDEX STORAGE (INITIAL 25K NEXT 25K)

　　REFRESH START WITH ROUND(SYSDATE + 1) + 18/24

　　NEXT SYSDATE + 1

　　AS SELECT * FROM SUPDBA.PARCEL@SUP—LH;

　　/* 快照从第二天18点开始刷新，每天刷新一次 */

　　上述三类数据存贮于SZLIS的Oracle数据库中，具体的表、视图、快照间的关系如图2所示。

图2　SZLIS中各数据库对象间关系

　　对于类型四数据，市局、分局、管理所各存放一份ARC/INFO数据，市局系统通过与Oracle数据库中对分局远程表做的视图相连来修改属性数据，通过快照来查询属性数据；分局和管理所系统则直接通过与Oracle数据库中的表相连来操作属性数据；每天系统的更新程序要根据Oracle数据库的属性数据对市局、分局、管理所的图形数据进行增量更新，以保证三地的数据一致。

　　SZLIS中基于Oracle的分布式数据库组织结构如图3所示。


　　　　　　　　　　　

图3　SZLIS分布式数据库组织结构

　　4.4　空间数据同步处理

　　ARC/INFO本身并不支持分布式存储和管理，为了实现市局、分局及管理所的空间数据同步，系统采用如下方法处理：

　　. 在分局的Oracle数据库中建立图形修改记录表，数据项包括数据类型、数据序号、创建地点、更新日期、更新类型、更新用户、读取标志等，市局建立它们的视图，并通过视图读取图形修改记录表。

　　. 市局或各分局系统运行时对图形的每个变动，如创建、更新、删除等操作，往图形修改记录表中加入记录。

　　. 在进行空间数据交换时，调用图形修改记录表，提取信息，进行图形数据更新。

　　. 处于第三级的管理所，数据的处理类似市局，属性数据访问的是分局的表，图形数据在其本地建数据库，与分局的表相关联。

　　5　展望

　　关系数据库经过多年的发展，其分布式处理技术已经越来越成熟。对于土地信息系统这种既有非空间数据又有空间数据的大型系统来说，其非空间数据可借助于相对成熟的分布式关系数据库来实现分布式处理，而目前空间数据的分布式处理需要寄生于关系数据库的分布式技术。要真正解决空间数据的分布式处理问题，还有待于深入的研究。

　　荣　芳　工程师。主要研究方向：地理信息系统，数据库设计等。