地理数据库事务管理
事务是指对数据库进行更改的一系列任务。与其他数据库应用程序一样,地理信息系统 (GIS) 数据库必须支持实施数据完整性和应用程序行为的更新事务。在许多情况下,用户可使用数据库管理系统 (DBMS) 的事务框架来管理地理数据库的编辑和更新。
然而,GIS 用户通常还有某些特定的事务要求。例如:
- 通常,多个记录要在单个事务中一起进行更新。
- 大量的事务必须跨越很长的一个时间段(有时可达数天或数月,而不只是几秒或几分钟)。
此外,用户还需要能够撤消和恢复更改。编辑会话可以持续数小时甚至数天。通常,编辑操作必须在与中央共享数据库断开连接的系统中执行。
由于 GIS 工作流进程可能持续数天或数月,所以 GIS 数据库必须持续保持对日常操作可用,在这些日常操作中,每位用户都有可能获取共享 GIS 数据库的个人视图或状态。在多用户数据库中,GIS 事务必须在 DBMS 的短事务框架中进行管理。ArcSDE 技术可使用简单 DBMS 事务框架管理高级复杂的 GIS 事务,在这些事务操作中起到了关键的作用。
GIS 用户会遇到许多长事务工作流极其关键的情况。在大多数情况下,通过使用多用户 DBMS 和 ArcSDE 并利用版本化方法来管理对 GIS 数据库的更新,可以应对这些情况,下面会对此进行详细介绍。
以下是需要使用基于版本的事务模型的 GIS 数据编译工作流的示例:
- 多个编辑会话 - 单个 GIS 数据库更新可能需要进行持续数天或数周的涉及多个编辑会话的大量更改。
- 多用户编辑 - 多个编辑人员经常需要同时更新相同的空间整合要素。每位用户都需要使用各自的数据库状态,从而查看各个更新,而忽略其他编辑人员所做的更新。最后,每位用户需要提交更新并与其他编辑人员进行协调,以识别并解决所有冲突。
- 检出/检入事务 - 在很多情况下都需要将数据库中与某特定区域或地区对应的那部分数据检出到个人计算机中,然后在可能持续数天或数周的离线会话中更新此信息,甚至带到现场进行移动编辑和更新。这些更新必须提交到主数据库中。
- 历史 - 有时,在 GIS 数据库中保留每个要素的历史版本(即使在此特定版本更新后)、在存档中保留已不再使用且发生更改的要素的副本或跟踪各个要素的历史是十分有用的,例如,国家地图数据库中的宗地谱系或要素更新属性。
- 传输只变更更新 - 企业数据库和空间数据基础设施(其中的信息在各个组织之间共享)的维护需要共同协作,这种协作需要采用定义完善的可扩展标记语言 (XML) 架构并通过 Internet 来共享更新,从而在数据库之间共享只变更更新。
- 分布式地理数据库复本 - 区域数据库可以是总公司 GIS 数据库中与某特定地理区域对应的那部分数据的副本。这两个数据库必须通过交换更新的方式定期进行同步。
- DBMS 之间的松散耦合复制 - 通常,GIS 数据必须在一系列数据库副本(复本)之间保持同步,每个站点将在其本地数据库上执行各自的更新。通常,这些数据库只是定期通过 Web 进行连接。更新必须定期从每个数据库复本传输到其他数据库,同时自身的内容也会得到更新。在很多情况下,DBMS 是不同的 - 例如,在 Microsoft SQL Server、Oracle 和 IBM DB2 之间复制数据集。
地理数据库事务模型:版本化
用于管理上述工作流以及许多其他重要 GIS 工作流的地理数据库机制是,在地理数据库中保持多个状态,而且最为重要的是还要同时确保地理信息、规则和行为的完整性。这种管理、处理以及查看多个状态的能力要通过版本化来实现。版本化,顾名思义,就是当通过不同状态对各个要素和对象进行修改、添加和撤消时,系统可以显式记录它们的版本。每个版本显式记录一个要素或对象的一个状态,并连同重要的事务信息一起作为表中的一行。允许任何数目的用户同时操作和管理多个版本。
版本能够将所有事务记录为随着时间的推移而对数据库所做的一系列更改。这意味着,各个用户可以操作地理数据库的多个视图和状态。从而实现开放式、高性能的多用户访问这一目标。例如,当数千位用户同时访问包含数亿条记录的数据集时,系统必须足够快并能够对这些数据集的使用提供有效的支持。
基于版本的地理数据库事务模型相对而言十分简单,即把更新记录在变更表中。
版本会显式地将地理数据库的对象状态记录在两个增量表中:
- 添加表
- 删除表
可使用简单查询来查看和处理任何所需的地理数据库状态,例如,查看某一特定时刻数据库的状态或查看包含编辑内容的特定用户的当前版本。
ArcSDE 在版本化地理数据库应用程序中起着关键作用,它利用短事务框架来管理每个 DBMS 中的长事务,并能够跨越不同的 DBMS 运行。
在此版本表示例中,45 号宗地被更新为 47 号宗地。通过利用版本化,原始宗地将被保存在删除表中,而新宗地将被保存在添加表中。其他元表记录了有关事务的版本信息,例如,每次更新的时间和顺序、版本名称以及每次更新的状态 ID。每个版本还具有各自的安全及访问权限。
这样,当随着时间的推移不同的编辑人员同时更新各自的数据库版本时,大多数用户都能够对默认版本进行操作。
可以对每个版本进行大量的更新,在用户要对数据进行附加编辑时他们可以连接到并操作更新版本。如果用户已准备好要与企业的其余人员共享这些更新,则可执行协调和提交操作将更新版本中的编辑内容提交到主(默认)版本。此时,将使用冲突解决过程来识别并协调在此过程中可能出现的所有冲突。
要了解版本化的详细信息,请参阅了解版本化。