数据维护策略

针对地理数据的事务在持续时间和复杂性方面可能千差万别。地理数据库支持两种数据维护策略 - 版本化维护和非版本化维护，这使得用户和应用程序分别针对简单或复杂数据执行短期和长期事务的需要得到了平衡。

可以分别针对不同的要素类或表应用不同的策略，因此可在同一地理数据库中同时使用这两种策略。

这两种策略中编辑数据的方法相似，都是在编辑会话中进行编辑并且都使用一些相同的工具。不同的是基础数据源的维护方式。在可编辑的数据以及可执行的工作流程类型方面也存在一些差异。本主题将介绍这些差异。

非版本化数据维护

此策略不涉及处理多个版本 - 它仅仅使用基础 DBMS 事务模型。非版本化编辑相当于标准数据库事务。

编辑数据的方式为：在编辑器选项 对话框中启用非版本化编辑；启动一个编辑会话，然后执行所需操作，如添加、删除或移动要素以及更新属性。编辑会话中的第一次编辑会启动事务。保存时，所执行的各个编辑操作会作为单个事务提交到数据库。保存之后，下一次编辑时会启动一个新事务。在编辑会话中，每次保存的操作数量多少可根据需要而定，但建议您经常保存，以避免因锁定了正在编辑的数据而阻止其他用户访问或编辑数据。保存之后，访问该数据的其他所有用户和应用程序都将看到所做的更改。

如果不想将编辑内容提交到数据库，请停止编辑且不保存。事务中的所有编辑内容（自上次保存之后的所有编辑，在从未保存的情况下则为编辑会话启动后的所有编辑）都将被消除并且不会提交到数据库。

编辑时，任何使用 DBMS 在数据上定义的唯一索引、约束和触发器均适用。所有相同的锁定行为均适用，如同您直接使用 DBMS 对数据执行事务一样。因此，如果多个用户或应用程序都访问或修改相同的数据，则其中一个用户或应用程序可能会阻止另一方对数据执行操作。在多用户编辑环境中使用非版本化编辑时，您应了解隔离级别和锁定操作在 DBMS 中如何工作，并在必要时先在 DBMS 中设置正确的隔离级别再开始使用 ArcGIS。

此策略适用于简单要素，对于简单要素来说，您不需要管理历史记录或管理版本化数据的多种表示。由于此策略不需要版本，因此在需要 GIS 和非 GIS 应用程序共享对公用数据库的访问权限时，此策略也非常有用。

可能的应用

• 通过允许第三方应用程序（不是使用 Esri 软件创建的应用程序）读取或修改 ArcGIS 应用程序所访问的同一数据，轻松地将地理数据集成到现有应用程序。
• 使用简单的工作流程和编辑操作管理项目。如果事务始终非常简单并且持续时间很短，则可以直接修改数据，无需合并更改以及定期管理版本所需的附加表。

局限性

• 只能编辑简单数据（点、线、多边形、注记和关系）。不能编辑参与构建拓扑、网络数据集、几何网络或地形的要素类。
• 由于是直接对数据源进行编辑，在误操作时，无法撤消或恢复单次编辑。撤消编辑的唯一方法是停止编辑会话而不进行保存，这样会放弃上次保存之后所做的全部编辑。
• 每个事务都必须在一个编辑会话中开始和完成。编辑会话只能持续有限的一段时间；例如，您通常需要在几个小时后结束会话，这样才能在一天结束时从系统注销。
• 使用非版本化编辑时，不会检测冲突。如果一名用户更新要素并保存，随后另一用户更新同一要素并且也进行保存，则最后所做的更新会覆盖第一次更新。

  有关详细信息，请参阅快速浏览：处理非版本化数据。

版本化数据维护

地理数据库对标准 DBMS 事务进行了扩展，允许数据库同时存在多个并发状态（即版本）。每个版本可以表示正在进行的工作（如一个设计或一组工作指令）、可跨越多个数据库连接的工作，时间可以长达几周或几个月，视需要而定。版本可以使您在同一地理数据库中管理对数据的过去、现在和计划的更改。

要管理过去的更改，需要将对数据的更改保存到单独的存档表中。可以根据需要将这些更改保留一定的时间，以便允许用户查看数据库在先前某个时间点的状态。此功能称为归档，它内置于 ArcGIS 中，不需要进行开发。启用此功能时，对 DEFAULT 版本（通常用作数据库的发布版本）的更改会自动存档。

要管理当前更改，编辑者可以修改地理数据库的私有版本，这样其他用户便无法查看未完成的工作。编辑数据的某一版本时，不应用任何锁。这样就使并发得到了最大限度的提高，因为其他用户能够读取和编辑您正在修改的数据，并且您不会阻止其他用户访问数据库。编辑者完成更改之后，便可以将更改整合到已发布版本之中。

要管理计划的更改，可以在数据库的某个版本中设计一个情景或执行假设分析。情景可以作为一个单独的更改单元进行管理，它可以跨越多个编辑会话并延续许多天、周或月。可以自由地添加建议的要素、执行地理分析、生成地图，所有操作都不会影响其他用户正在访问的数据库。更改完成并通过批准之后，可以将其整合到地理数据库的其他部分中。

地理数据库可以具有的版本数量没有限制。版本可以具有各种不同的配置并且支持各种工作流程。但是，出于简化和地理数据库管理考虑，推荐的最佳做法是保持扁平版本树或使多个编辑者同时编辑 DEFAULT 版本。

为了支持版本化功能，ArcGIS 不复制数据，而是将每个要素类和表保留为其原始格式，但会在表中记录更改，这个表称为增量表。增量表由一个记录插入和更新操作的添加表和一个记录删除操作的删除表组成。每次在版本中更新或删除记录时，都会向这两个表或其中一个表添加行。在版本中查询或显示要素类或表时，ArcGIS 对增量表和原始表中的相关行进行组合，呈现出数据的无缝视图。

编辑版本化要素类

版本化表需要数据库管理员进行定期维护。随着时间推移，对地理数据库的编辑次数增多，增量表会逐渐增大，因此会影响到显示和查询性能。要保持性能，数据库管理员可以定期压缩版本化数据库，此操作会从增量表中移除冗余的信息。在经历密集的数据库活动之后，如数据库移动结束时或加载新数据之后，需要对版本化数据库执行压缩操作。可以在其他用户连接到数据库并使用数据库的情况下进行压缩。

ArcGIS 可以用下列两种方法之一管理支持版本的基础增量表：

• 将所有版本的更改保存到增量表
• 将所有非 DEFAULT 版本编辑内容保存到增量表，将所有 DEFAULT 版本的编辑内容保存到基表

第一种方法仅支持 ArcGIS 应用程序。第二种方法在需要使用 ArcGIS 和第三方应用程序维护数据的时候十分有用。

仅使用 ArcGIS 应用程序维护数据

在仅使用 ArcGIS 应用程序维护数据的环境中，管理版本的最好方法是将所有更改都保存到增量表中。这可以使您充分利用地理数据库的功能，包括存档、复制以及编辑几何网络和拓扑的能力。

要针对要素类或表启用此行为，应将数据注册为版本而不将编辑内容移动到基表。将更改保存到用这种方法注册的数据集时，这些更改会保存在增量表中。采用这种方法时，用户无法直接访问原始表，而是始终访问数据的一个版本。

下例说明了一种数据完全通过使用版本进行管理的配置。编辑者需要使用 ArcGIS 或其他 Esri 应用程序对数据进行更改。如果发布版本或其他任何版本调整为版本化视图，非 GIS 应用程序便可以对其进行访问。

由于不具备支持版本所需的增量表和其他表，因此不使用 Esri 软件库而直接访问 DBMS 中数据的应用程序自身无法读取版本。ArcGIS 提供允许这些应用程序使用 SQL 读取给定版本的版本化视图。版本化视图既可以访问表，又可以访问要素类。使用版本化视图访问要素类的几何属性时，需要使用 SQL 几何类型，ArcGIS 完全支持这些几何类型。

这种方法具有以下优点：

• 在进行编辑时可撤消或恢复更改。
• 由于不具有锁，可对冲突进行编辑。ArcGIS 允许用户轻松地检测、协调和解决冲突。
• 存档自动更改，并可查询数据库在特定时间点的状态。
• 能够在几何网络、网络数据集或拓扑中编辑要素。
• 可以使两个或多个地理上分散的办公机构同时处理地理数据库的同步副本。这些办公机构需要定期彼此发送更改，使每个机构都具有该地理数据库的最新视图。ArcGIS 将此功能称为地理数据库复制。
• 无网络连接的移动用户能够在野外使用便携式计算机或手持设备编辑地理数据库的一部分。用户返回办公室后，再将其更改整合到地理数据库中。ArcGIS 也将此功能称为地理数据库复制。

潜在应用包括：

• 需要存储和查询存档数据的项目。
• 需要假设分析的项目：在单独的版本中创建新设计。如果设计通过批准，可以将其与数据库的其他部分合并。如果未通过批准，可以将其丢弃。
• 具有特定质量保证要求的项目：在与其他数据库用户独立的版本中收集对数据的更改，如批量导入。在与数据库的发布版本合并之前，测试并批准更改。
• 将工作分为功能单元和地理单元的项目：例如，一个设计并新建购物中心的项目可能具有几个不同的建造阶段，它会细分为东区和西区或按建造活动细分，如建筑、公共设施安装或景观美化。每个单元的工作在一个单独的版本中进行；每个版本完成时，会提交到数据库的发布版本中。
• 通过指定或规定的阶段组形成的项目，其中每个阶段都需要工程设计、管理或经依法批准，才能视为完成：这些项目的工作流程可以使用单独的版本来管理每个阶段，如初始设计或建议版本、批准版本以及建造阶段的版本。随着项目逐步向前推进，每个阶段都会经过审核和批准，然后被下一版本取代，直至达到并完成最后一个阶段。
• 具有法规审计要求的项目：持续进行存档以支持对更改的查询。
• 项目的多个办公机构在地理位置上相距较远，但需要同时处理同一地理数据库：各个办公机构需要能够定期同步其数据副本。
• 需要维护队员在野外使用便携式计算机更新数据的项目。
• 需要软件开发者在自己的数据库私有版本上测试 SQL 语句和应用程序逻辑的项目。

版本具有许多优点，但也有一些局限性：

• 第三方应用程序必须与版本化视图相适用才能读取数据。
• 处理版本化数据时，在使用处于活动状态的 DBMS 行为（如唯一约束和触发器）方面存在限制。这是因为插入和更新操作会在增量表中创建新行而非在基表中执行插入和更新。

使用 ArcGIS 和其他应用程序维护数据

在复杂的计算环境中，可能会有许多不同的部门应用程序访问同一数据库，因此需要能够同时支持 ArcGIS 和第三方应用程序。针对这种情况举例，一个部门使用 ArcGIS 维护数据库中的地理数据，而另一个部门使用自定义应用程序维护同一数据库中的客户记录。自定义应用程序需要在事务进行时应用 DBMS 约束和触发器并且可能不识别版本化表。与此同时，另一部门需要在自己的独立版本中编辑地理数据，在编辑完成并通过批准之后再共享部门编辑内容。

由于考虑到这些要求，ArcGIS 允许您在要素类或表上执行版本化编辑，同时保留与其他应用程序共享编辑内容的能力。要在要素类或表上启用此功能，应将数据注册为版本，同时可以选择是否将编辑内容移动到基表。可以在“注册”对话框中找到此选项。

编辑用这种方法注册的数据时，版本的工作方式与在上一种方法中介绍的方式相同：更改会保存在增量表中。一种例外情况是 DEFAULT 版本。将编辑内容保存到 DEFAULT 版本时，无论是通过直接进行编辑还是通过合并另一版本中的更改，编辑内容都会保存在基表中。取消选中“将编辑内容移动到基表”选项时，这些编辑内容将不再保留在增量表中。

这可以让所有应用程序在同一数据库上进行工作。

• 不是使用 Esri 软件编写的应用程序可以继续使用标准事务访问和修改数据，即便当前正在 DEFAULT 或另一版本中对数据进行编辑。
• ArcGIS 或使用 ArcObjects 编写的应用程序将更改保存到 DEFAULT 版本或将更改合并到 DEFAULT 版本时，任何使用 DBMS 在数据上定义的唯一索引、约束和触发器均适用。
• 当一个应用程序修改数据时，这些更改对访问该数据的其他应用程序立即可用。由于对 DEFAULT 版本的更改不保存在增量表中，因此不需要将第三方应用程序调整为适合于版本化视图来使其可以读取这些表。

可能的应用

• 需要使用 ArcGIS 和其他应用程序编辑数据的项目 - 建立一个工作流程，其中其他应用程序使用标准 DBMS 事务访问和修改数据库中的非空间数据，同时其他用户在同一数据的特定版本上操作，执行持续时间相对较长且与其他数据库用户独立的事务，直至提交到 DEFAULT 版本为止。
• 其他潜在应用与仅使用 ArcGIS 应用程序维护数据时相同
  • 需要假设分析的项目
  • 具有特定质量保证要求的项目
  • 将工作分为功能单元和地理单元的项目
  • 通过指定或规定的阶段组形成的项目
  • 要维护队员在野外使用便携式计算机更新数据的项目
  • 需要软件开发者测试 SQL 语句和应用程序逻辑的项目

局限性

使用“将编辑内容移动到基表”选项将数据集注册为版本后，会在处理版本的方式上受到限制。

• 只能编辑简单数据（点、线、多边形、注记和关系）。不能编辑拓扑、网络数据集、几何网络或地形中的要素类。
• 不能存档对数据集的更改。
• 不能复制数据集。
• 编辑 DEFAULT 版本或将版本提交到 DEFAULT 时，不能解决冲突，因此可能会覆盖其他用户的编辑内容。

有关版本及其提供的功能的详细信息，请参阅了解版本化和版本情景。