版本情景

本主题将介绍版本化的应用,即如何将此技术应用于企业内部,同时还将介绍可用的版本配置。

各企业之间的工作流有很大差别。它们通常按照独立的阶段向前推进,并且每个阶段都需要分配一组不同的资源与业务规则。一般来说,整个流程中的每个阶段都表示一个独立的工作单元,如工作指令。要管理各个工作指令,可以创建单独的孤立版本并对其进行修改。当您对完成的工作感到满意后,可以将更改集成到已发布的数据库版本中。通过这种方式使用版本,您能够同时适应最基本和最复杂的工作流程。

您最可能采用的方案是同时编辑已发布的数据库(多个编辑人员修改 DEFAULT 版本),或者采用某些其他配置的组合。了解企业和业务需求并认清每种配置的优缺点,将有助于您选择一种最适合于贵企业的配置。

出于简化和地理数据库管理考虑,建议的最佳做法是保持扁平版本树或让多个编辑者同时编辑 DEFAULT 版本。

同时编辑已发布的数据库

多个用户可以同时编辑同一版本,因此对于多个编辑人员来说,支持多用户编辑的最简单方法是直接编辑 DEFAULT 版本。

同时编辑 DEFAULT

随着各个编辑人员开始编辑 DEFAULT 版本,在编辑会话中将自动创建临时未命名版本。只有当前编辑人员才可以访问此临时版本。当编辑人员保存其工作内容或结束编辑会话后,临时版本中记录的更改将被提交到 DEFAULT 版本。

如果在您开始编辑后其他用户也编辑了 DEFAULT 版本,则当您保存工作内容时,ArcGIS 会自动进行协调并提交更改。系统会通知您版本已被更改,必须重新保存以接受其他编辑人员所做的更改。启用“ArcMap 选项”对话框中的自动协调可以绕过此警告消息。无论是否绕过此消息,如果存在冲突,都必须使用冲突解决对话框解决冲突,之后才能成功保存编辑内容。

了解有关保存数据的设置的详细信息

了解如何解决数据冲突

优点:

缺点:

多个项目

如果要管理多个项目或工作指令,您需要更加结构化的工作流管理方法。对于涉及多个编辑会话并持续数日、数周或数月的独立工作单元,可以在不影响 DEFAULT 版本的情况下对其进行维护。例如,这些独立的工作单元可以是高速公路改造方案、安装新电话服务或者正在进行的煤气管道维护项目。

管理多个项目

当启动某个工作指令或项目时,会创建一个 DEFAULT 版本的子版本。一个或多个编辑人员可以在此版本中工作,直到该工作指令或项目完成。对某个版本完成所有修改后,编辑人员或 ArcSDE 管理员将与 DEFAULT 版本进行协调,以解决出现的任何冲突。随后该人员会将修改提交到 DEFAULT 版本,从而将修改集成到已发布的数据库中。此时可以删除子版本。

可以限制用户对 DEFAULT 版本的访问权限,以强制执行此工作流并确保 DEFAULT 版本不会被修改。ArcSDE 管理员可以将 DEFAULT 版本的权限设置为受保护;这样允许用户继续查看 DEFAULT 版本,但将他们的访问权限级别限制为只读。任何想要修改数据的编辑人员都必须创建新版本。

如果只读用户不需要在更改被提交到 DEFAULT 版本后立即看到更改,则可以从 DEFAULT 版本创建一个受保护的静态版本供这些用户使用。应该在压缩数据库并重新构建索引和统计数据后创建此版本。这样做可确保表示只读版本所需的所有行都存储在基表中,并且数据库以最优性能运行。在这种情况下,不会对只读用户的数据库版本(下图中的 FastTrak)进行任何更改,因此不必执行版本差异查询,并且数据库统计数据和索引不会过期或产生碎片。在执行完每次计划的数据库压缩后,将会重新创建此版本,允许只读用户访问自上次数据库压缩后所进行的更改。

使用一个支持快速查询和报告的版本管理多个项目

优点:

缺点:

含子项目的多个项目

与同时编辑或多个项目方法提供的工作流结构相比,复杂项目需要更加精细的工作流结构。这些项目可进一步分为多个功能或地理单元,根据这些单元将制定出更复杂的版本化等级。例如,一个旨在设计并构建新的购物中心的项目可能具有几个不同的建造阶段,它会细分为东区和西区或按建造活动细分,如建筑物、公共设施安装或景观美化。

含子项目的多个项目

对于涉及不同团队和多个独立工作单元的大型项目,多层版本树是组织工作流的有效方式。负责同一项目不同方面的团队可以创建自己的版本来保存更新内容的私有视图。项目完成后,各个版本会被协调并提交回 DEFAULT 版本,并成为已发布数据库的组成部分。

优点:

缺点:

分阶段的项目

许多项目要经过一组预定或规定的多个阶段,其中每个阶段都需要工程设计、管理或法律批准,才能进入下一阶段。例如,在公共设施领域,常规项目阶段包括运作、计划、接受、施工和完工。这种特别过程本质上具有周期性:最初会将工作指令指定给工程师,随着项目经过各个阶段会对其进行修改,最后将其与生产数据库完全集成。

在此方法中,会为此过程的每个阶段都创建一个版本:初期设计或计划版本、批准版本和施工阶段版本。随着项目逐步向前推进,每个阶段都会经过审核和批准,然后被下一版本取代,直至达到最后一个阶段并完成该阶段。可以根据需要保存较早版本作为历史参考或者删除。

分阶段的项目

项目完成后,可以立即对构造出的版本进行协调并直接提交到 DEFAULT 版本,而不必协调与提交谱系中的先前版本。

优点:

缺点:

归档

许多项目的关键要求是在数据库随时间改变时保存数据库的各种状态。地理数据库可能需要支持的一些典型查询包括:

保存历史记录的一般要求是保留 DEFAULT 版本的归档,因为它通常代表已发布的数据库版本。对 DEFAULT 进行编辑或者从其他版本协调更改并提交到 DEFAULT 都会使 DEFAULT 发生更改。可以将地理数据库设置为自动记录这些更改。地理数据库内置此功能;不需要任何其他数据建模或应用程序自定义即支持自动归档功能。

某些项目需要对除 DEFAULT 以外的版本进行归档。由于版本表示在其被创建时父版本的状态,您可以创建一个只记录父版本在特定时间点状态的版本。例如,可以根据设计版本创建新的历史版本。当设计版本被协调并提交到父版本时,将保留历史版本作为设计版本在特定时间点的记录。

为归档目的而创建版本

有关归档的详细信息,请参阅归档过程

分布式数据管理

某些项目需要两个或多个远程办公室处理相同的数据。每个办公室都需要对数据库进行本地访问,因此会各自创建一个数据库副本。在一个地点对数据进行更改时,更改也必须应用到其他地点的数据。要保持数据库各副本间的同步,站点可以定期相互传输更改。此功能称为地理数据库复制。

远程办公室可以同步其地理数据库副本

通过复制还可以在路途中获取地理数据库的子集并进行离线编辑,这是外业维护团队的一般要求。返回办公室后,可以重新连接到网络并将更改合并回生产数据库。

对于不得不通过慢速网络编辑数据的人员,复制也是很有用的。在这种情况下,通过复制可将数据的子集提取到本地计算机,这样不必通过网络通信即可对数据进行处理。完成编辑后,可以通过网络传输更改,将其合并回生产数据库。有关详细信息,请参阅使用分布式数据的情形

相关主题

9/15/2013