Design and Realization of MAPGIS7.0 Management Based on DBMS
-
摘要: 提出了一种“版本化”的地理数据库管理模式和基于DBMS (database management system) 的版本管理模型, 讨论了其设计过程和层次结构, 给出了关键算法及MAPGIS7.0中版本管理的实现技术, 解决了传统GIS软件不能并发处理长事务的难题。该版本管理工具已经在国家“863”项目---地质调查空间数据管理系统良好地运行, 能够满足多用户长期并发编辑地图的要求.Abstract: This paper presents a "versioned" managing mode to manage the geological database, and a model of version management based on DBMS. The design process and architecture are discussed, as well as the main arithmetic and technologies of version realization in MAPGIS 7.0. It solves the concurrency control problem of long-duration transaction which cannot be solved by traditional GIS software. Test shows that in actual application, users can do cooperative editing for a long term with MAPGIS7.0. Now it has been successfully applied to the national geological survey spatial database management system.
-
Key words:
- MAPGIS /
- long transaction /
- version
-
0. 引言
GIS的许多应用都涉及长期的编辑制图工作, 如地质编图过程, 一次编辑可能历时数天, 甚至数月, 而且是许多地质工作者并发的编辑地理要素.这种长时间的要素编辑操作要求具有事务ACID特性, 即原子型、一致性、独立性、持久性.要素编辑的特点往往表现为下列需求: (1) 从开始编辑到结束编辑, 所有的编辑操作要么都取消、要么都提交, 无论取消或提交, 都不破坏地理要素的一致性和完整性; (2) 所有的编辑结果只有编辑人员可见, 在提交编辑之前, 所有编辑结果都能够保存, 但对其他人不可见; (3) 多人同时编辑, 相互之间不受影响; DBMS提供的事务, 一般都采用加锁机制.在事务处理过程中.DBMS (database management system) 将锁定相应表的相应行记录, 直到事务结束.这就要求用户的事务时间尽可能的短, 并且可能产生死锁情况.因此DBMS的事务不能满足GIS编辑过程中的这种长时间并发访问的要求(Michael, 2003).
因而设计一个版本管理工具, 能够以版本的方式对地理数据库进行管理, 能够处理GIS长事务, 并满足GIS中长时间协同编辑的应用需求, 具有非常重要的现实意义.本文介绍了MAPGIS7.0版本管理的设计思想、物理设计、功能模块以及关键实现算法.
1. 版本管理原理
基于MAPGIS7.0平台的长事务实现机制有基于状态和版本这2个概念, 通过版本控制, 让多个用户可以直接编辑某个地理数据库而不用明确地锁定要素或者复制数据.
状态是地理数据库变化过程中某一瞬间的标识.任何改变地理数据库的操作都产生新状态.地理数据库中的这些状态可以组织成一棵树, 在这棵树的线性结构中描述了各个状态的父子关系; 版本是一个命名的状态.地理数据库中的每一个版本都明确指向一个具体的状态.不同版本在数据逻辑上相互区分.这样, 我们在进行要素编辑时, 可以为同时进行分工合作的人员定义各自的版本, 每个人都在自己的版本空间下工作, 不受其他人编辑的干扰, 完成编辑后, 再进行版本的合并.
版本管理模式没有使用DBMS对一般事务采用加锁处理并发的方式, 多用户的并发是建立在各自的状态分支上的.用户在自己的状态分支上所作的任何操作完全由该用户自己控制, 不受其他任何用户的影响.这种模式实现了事务的乐观并发性.这意味着当开始一个长事务时, 没有任何锁加到要素上.在这种模式下允许引入编辑冲突, 当提交事务时, 检测冲突并协调解决冲突.
乐观并发性是适于GIS应用的, 因为相对于地理数据库大小来说, 要素编辑的数量是小的.在实际的地图编制过程中, 编辑冲突并不经常发生, 并且比起长事务期间锁住要素来说, 协调冲突的代价比较微小(廖国琼, 2000).
2. 基于DBMS的结构设计
版本管理的主要逻辑思想通过记录数据库的状态来维护地理数据库的版本, 在DBMS中可以通过一组特定模式的关系表格在整个空间数据库和要素类2个层次上来实现.
在数据库层次上, 基于MAPGIS7.0 SDE设计版本管理数据字典如下: MPDB_STATES, MPDB_STATE_LINEAGES, MPDB_VERSIONS, MPDB_MVXCLS_MODIFIED.其中MPDB_STATES表用来存储地理数据库变化过程中产生的状态, 每个状态有它对应的状态分支, MPDB_VERSIONS表存储地理数据库中版本的信息, 其中每个版本对应一个地理数据库的状态, MPDB_STATE_LINEAGES表存储地理数据库中每个状态分支中存在的状态列表, 用来提高系统查询的效率; 同时还提供MPDB_MVXCLS_MODIFIED表存储状态改变类的信息, 每个类在哪个状态下被修改, 在该数据字典中都有记录, 该字典在版本协调过程中进行冲突检测时使用.这4张表对于整个地理数据库来说是全局共享的(任娟, 2005).
在要素类层次上, 基于MAPGIS7.0 SDE设计的AMF、MF、DMF 3个表, 来支持对要素类进行版本管理.其中AMF表存储添加的要素信息, AMF表中的state_ID字段表示该添加动作对应的地理数据库的状态; DMF表存储删除的要素信息, 其中deleted_state_ID字段表示该删除动作对应的地理数据库的状态.MF表存储原始状态对应的数据.特定版本下的数据检索可以通过对MF表+AMF表-DMF表组合查询来实现.
在空间数据库层上的4个数据字典表和要素类层次上支持版本管理的类的AMF表/DMF表联合起来即可完成对要素类的版本管理操作.图 1给出了用于实现地理数据库版本管理的数据库模式的关系结构, 该图虽然是地理数据库版本管理的实现模式, 同样也是建立在关系数据库基础上的面向对象地理数据库模型版本管理实现的一般方法.
3. 功能设计
在实际地理数据生产中, 版本管理模块不仅要具有地图编辑的所有功能, 还需要提供有效的机制来对不同用户、不同时间的各自编辑结果进行浏览、比较和取舍; 综合实际地理数据实际生产和面向实体的地理数据管理的需要; MAPGIS7.0版本管理应具有版本创建、删除、归并、冲突解决等功能和机制(吴信才, 2003) (图 2).
(1) 创建版本.地理数据库创建的时候将创建一个“缺省”版本, 它是以后创建任何版本的父版本或者祖先版本.用户可以根据需要选取地理数据库已经存在的任何版本作父版本来创建版本, 并且确定版本的访问权限.版本权限包括私有的、保护的和公有的.
(2) 注册和注销版本.系统为每个支持版本管理的类提供了将该类支持和取消版本管理能力的方法: 注册版本、注销版本.注册版本后, 该类才具有长事务处理的能力, 才能够进行版本的编辑, 协调和提交等操作; 而注销版本则使该类就失去了版本管理的能力, 不能进行版本管理的相关操作.
(3) 打开版本.用户打开要素类的时候可以指定打开哪个版本.要素类等在该版本下打开后, 用户对类的编辑(如Append, Update, Delete等) 将只在该版本下可见.
(4) 版本编辑.版本化的类在开始编辑后, 才能进行要素、几何或空间点、线及属性表格等进行添加、删除、更新等操作; 不开始编辑将不能进行正常的编辑操作或操作结果不能保存.
(5) 保存编辑.保存编辑将使对要素类的编辑结果得以保存, 不保存的结果将视为放弃开始编辑后的所有操作.
(6) 冲突检测.保存编辑结果时, 系统将在下列2种情况下检测冲突: ①系统将检测是否有多个用户打开并编辑同一个版本, 并对同一个要素进行了编辑, 若有将判定是否有冲突.②系统将检测是否有多个用户分别打开不同的版本, 并对同一个要素或对象进行了编辑; 这些编辑结果各自保存时并不存在冲突, 但合并版本时, 则将判定是否存在冲突.冲突根据对同一要素或者实体进行的编辑类型的不同分为: 更新-更新冲突, 更新-删除冲突和删除-更新冲突.
(7) 版本协调.在版本下编辑的结果只能向父版本协调.协调的结果就是将没有冲突的动作合并, 将存在冲突的操作选出来, 交给用户仲裁.系统无法确定那种编辑更符合用户的最终要求时, 就将2个版本下的不同编辑判定为冲突.仲裁冲突的用户根据需要主观地决定采用那个版本下的编辑, 或者2个都不采取, 而选择退回编辑之前的状态, 以便采用另外用户认为更合理的处理方式编辑该要素或者实体.冲突集中时可以单个解决, 也可以同时解决.
(8) 版本提交.用户在解决完冲突后, 将结果提交到当前版本或父版本.提交后产生冲突的2个版本的编辑结果将变为一致; 不提交则冲突的解决结果将不能保存.
4. 实现模型
4.1 要素编辑实现模型
要素的编辑过程可以分解为添加要素、更新要素、删除要素3个基本的动作.添加一个要素, AMFXX表中添加一条记录, 记录新添加要素的信息(表 1); 更新一个要素的动作可以分解为删除原来的要素, 添加一个新的要素, DMFXX表中添加一条记录(表 2), 记录删除该要素的信息, 然后在AMFXX表中添加一条记录(表 3), 记录新添加要素的信息, 在此过程中, 新的要素ID保持不变; 删除一个要素, DMFXX表中添加一条记录(表 4), 记录删除该要素的信息.
表 1 添加要素: 向AMFXX表中添加一条记录Table Supplementary Table Add a feature: insert to AMFXX表 2 更新要素: 向DMFXX表中添加一条记录Table Supplementary Table Update a feature: insert to DMFXX表 3 更新要素: 向AMFXX表中添加一条记录Table Supplementary Table Update a feature: insert to AMFXX表 4 删除要素: 向DMFXX表中添加一条记录Table Supplementary Table Delete a feature: insert to DMFXX4.2 要素范围检索实现算法
矩形范围检索要素的实现算法如下:
(1) 从线索树MPDB_STATE_LINEAGES表中找到指定状态的线索分支上的祖先状态集合CS;
(2) 在MF表中查询出所有满足给定矩形范围条件的要素集合CF;
(3) 在DMF表中查询所有CS集合包含的状态中删除了0状态的要素集合CD1;
(4) 在AMF表中查询出满足给定矩形范围条件的要素集合CA;
(5) 在DMF表中查询出所有CS集合包含的状态中删除了CS状态中添加要素的集合CD2;
(6) 最后要素检索结果可以表示为(CF-CD1) ∪ (CA-CD2).
例如在要素类283中查找与矩形范围(xmin=100, ymin=200;xmax=300, ymax=400) 相交, 且状态为199, 线索分支为197的要素集合, 其SQL实现模型如下:
SELECT bf.FID, 0 STATE_ID, bf.TYPE, bf.INFID, bf.DATALEN, bf.DATA
FROM YANG.MF283 bf WHERE (bf.FID, bf.FID)
NOT IN (SELECT DELETE_FID, DELETE_FID FROM YANG.DMF283 WHERE DELETED_STATE_ID IN
(SELECT l.STATE_ID FROM YANG.MPDB_STATE_LINEAGES l
WHERE l.LINEAGE_ID = 197 AND l.STATE_ID < = 199))
AND bf.XMIN < =300 AND bf.XMAX > =100 AND bf.YMIN < =400 AND bf.YMAX > =200
UNION ALL
SELECT af.FID, af.STATE_ID, af.TYPE, af.INFID, af.DATALEN, af.DATA
FROM YANG.AMF283 af WHERE (af.FID, af.STATE_ID)
NOT IN (SELECT DELETE_FID, STATE_ID FROM YANG.DMF283 WHERE DELETED_STATE_ID IN
(SELECT l.STATE_ID FROM YANG.MPDB_STATE_LINEAGES l
WHERE l.LINEAGE_ID = 197 AND l.STATE_ID < = 199))
AND af.STATE_ID IN (SELECT l.STATE_ID FROM YANG.MPDB_STATE_LINEAGES l
WHERE l.LINEAGE_ID = 197 AND l.STATE_ID < = 199)
AND af.XMIN < =300 AND af.XMAX > =100 AND af.YMIN < =400 AND af.YMAX > =200.
4.3 要素冲突检测算法
冲突的产生都是在父子版本所处的不同的状态分支对同一个要素进行了更新或者删除操作产生的.更新-更新冲突的检测算法如下:
(1) 查询出2个状态分支的最大公共状态Sc;
(2) 查询出父版本在Sc状态到状态St上所有更新的要素的集合CUt;
(3) 查询出子版本在Sc状态到状态Ss上所有更新的要素的集合CUs;
(4) 更新-更新冲突的结果可以表示为CUt ∩CUs.
更新-删除冲突的检测算法如下:
(1) 查询出2个状态分支的最大公共状态Sc;
(2) 查询出父版本在Sc状态到状态St上所有更新的要素的集合CUt;
(3) 查询出子版本在Sc状态到状态Ss上所有被删除的要素的集合CDs;
(4) 更新-更新冲突的结果可以表示为CUt ∩CDs.
4.4 要素状态压缩算法
定期压缩地理数据库中的冗余状态可以有效的提高地理数据库检索要素的性能, 具体的算法如下:
(1) 遍历状态树, 决定哪些状态是冗余状态, 可以被压缩; 没有版本指向该状态节点时只有一个子状态节点的状态可以被压缩;
(2) 对能够压缩的状态, 需要消除该状态在版本管理相关的数据字典(MPDB_STATES表、MPDB_STATE_LINEAGES表、MPDB_MVXCLS_MODIFIED表) 和相关AMF表、DMF表中的影响.
5. 结论
目前基于大型GIS的版本管理模型已经应用到国家基于大型GIS地质调查空间数据库管理系统中.经过试验检测, 版本化后的性能已经接近没有注册版本的性能, 说明本文设计的版本管理模型及实现思路确实可行, 并能够很好地满足实际应用的需求.
-
表 1 添加要素: 向AMFXX表中添加一条记录
Table 1. Add a feature: insert to AMFXX
表 2 更新要素: 向DMFXX表中添加一条记录
Table 2. Update a feature: insert to DMFXX
表 3 更新要素: 向AMFXX表中添加一条记录
Table 3. Update a feature: insert to AMFXX
表 4 删除要素: 向DMFXX表中添加一条记录
Table 4. Delete a feature: insert to DMFXX
-
Liao, G. Q., 2000. An optimistic concurrency control method for supporting engineering design transaction. Computer Engineering, 26 (7): 24-25 (in Chinese with English abstract). Michael, Z., 1999. Modeling our world. Environmental Systems Research Institute, Inc., California. Ren, J., 2005. Principles of geodataba seversion control. Land and Resources Information, 6 (3): 41-45 (in Chinese with Englishabstract). Wu, X. C., 2003. MAPGIS7.0 whitepaper. Wuhan Zondy Cyber-Tech Co., Ltd., Wuhan (in Chinese). 廖国琼, 2000. 一种支持工程设计事务的乐观并发控制方法. 计算机工程, 26 (7): 24-25. 任娟, 2005. Geodatabase版本控制原理剖析. 国土资源信息化, 6 (3): 41-45. 吴信才, 2003. MAPGIS7.0技术白皮书. 武汉: 中地数码科技有限公司. -