写本文的最初意向是当前正在进行的项目中有实现ESRI版本化数据管理的功能模块，碰到一些棘手的问题，几经周折还是决定系统学习ArcGIS10的帮助文档。（文章摘抄的比较多）

地理数据库是用于保存数据集集合的“容器”。首先了解一下ArcGIS的三种地理数据库类型：

• 文件地理数据库-在文件系统中以文件夹的形式存储。每个数据集都以文件形式保存，该文件大小最多可扩展至1TB。建议使用文件地理数据库而不是个人地理数据库；
• 个人地理数据库-所有的数据集都存储于Ms Access数据文件内，该文件的大小最大为2GB。
• ArcSDE地理数据库-使用Oracle、MS SQL Server、IBM DB2、IBM Informix、PostgreSQL存储与关系数据库中。这些多用户地理数据库需要使用ArcSDE，在大小和用户数量方面没有限制；

地理数据库在可扩展性、跨平台以及性能方面ESRI都推荐使用文件地理数据库而非个人地理数据库。而ArcSDE地理数据库针对的是大型的多用户的企业解决方案，其可用来管理共享式多用户地理数据库和支持多种基于版本的关键性GIS工作流。

这里重点来理清ArcSDE对DBMS事务框架进行长事务管理和短事务管理：

ArcSDE 的主要角色之一就是支持每个 DBMS 中的地理数据库版本管理框架。

绝大多数情况下，GIS 中的单个编辑事务可能涉及对多个表中的多个行进行更改。例如，更新宗地可能需要更改面的表示，并更改相应的边界线和宗地拐角。此外，还必须更新这些要素中每个要素的属性记录。此编辑操作需要对多个表中的多条记录进行更改。在这些情况下，用户希望将此编辑集合视为单个事务。提交或回滚这些更改时，会将它们视为一个统一的操作来进行管理。

同时，用户希望能够在一个编辑会话中撤消和重做单个编辑操作。为了使这种情况变得更为复杂，可能需要在与中央共享数据库断开连接的系统中执行编辑操作。

而且，在这些专门化的 GIS 数据维护过程中，GIS 数据库必须持续保持对日常操作可用，而在这些日常操作中，每位用户都有可能获取共享 GIS 数据库的个人视图或状态。

通过使用一种称为版本管理的方法，ArcSDE 地理数据库支持在多用户环境下对这些数据管理情景及许多其他数据管理情景进行管理和更新。在版本管理这种机制下，所有的数据库更改都作为表中的行进行记录。例如，每次更新某一行中的某个值时，旧值即会失效，并会新增一个更新行。

这样，通过将更改信息以增量记录的方式存储在数据库中，ArcSDE 技术就能在简单 DBMS 事务框架中管理复杂的高级 GIS 事务。

ArcSDE 使用版本的元数据来隔离多个编辑会话、支持复杂事务、共享复本、同步多个数据库之间的内容、执行自动存档并支持历史查询。

再来看看ESRI提供的数据库维护策略：

非版本化数据维护

• 非版本化数据维护仅仅使用基础DBMS事务模型,与标准数据库事务等效。一次编辑会话（EditOperation）过程中从开启到保存算一个事务过程，并且保存之后访问该数据的其他用户和应用程序都将看到所做的更改。
• 此策略适用于简单要素，不需要版本控制和历史记录管理的功能。
• 此策略不能对之前所做的操作执行撤销重做等操作，并且在后一次的操作记录提交时不会进行冲突检测，而是直接覆盖前一次的操作记录。

版本化数据维护

• 地理数据库对标准 DBMS 事务进行了扩展，允许数据库同时存在多个并发状态（即版本）。每个版本可以表示正在进行的工作（如一个设计或一组工作指令）、可跨越多个数据库连接的工作，时间可以长达几周或几个月，视需要而定。版本可以使您在同一地理数据库中管理对数据的过去、现在和建议的更改。
• 要管理过去的更改，需要将对数据的更改保存到单独的存档表中。可以根据需要将这些更改保留一定的时间，以便允许用户查看数据库在先前某个时间点的状态。此功能称为归档。启用此功能时，对 DEFAULT 版本（通常用作数据库的发布版本）的更改会自动存档。
• 要管理当前更改，编辑者可以修改地理数据库的私有（private）版本，这样其他用户便无法查看未完成的工作。编辑数据的某一版本时，不应用任何锁。这样就使并发得到了最大限度的提高，因为其他用户能够读取和编辑您正在修改的数据，并且您不会阻止其他用户访问数据库。编辑者完成更改之后，便可以将更改整合到已发布版本之中。
• 要管理建议的更改，可以在数据库的某个版本中设计一个情景或执行假设分析。情景可以作为一个单独的更改单元进行管理，它可以跨越多个编辑会话并延续许多天、周或月。可以自由地添加建议的要素、执行地理分析、生成地图，所有操作都不会影响其他用户正在访问的数据库。更改完成并通过批准之后，可以将其整合到地理数据库的其他部分中。
• 版本化表需要数据库管理员进行定期维护。随着时间推移，对地理数据库的编辑次数增多，增量表会逐渐增大，因此会影响到显示和查询性能。要保持性能，数据库管理员可以定期压缩版本化数据库，此操作会从增量表中移除冗余的信息。在经历密集的数据库活动之后，如数据库移动结束时或加载新数据之后，需要对版本化数据库执行压缩操作。可以在其他用户连接到数据库并使用数据库的情况下进行压缩。

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

• 将所有版本的更改保存到增量表[支持历史归档][操作:注册版本时不勾选“将编辑内容移动到基表”][应用场景举例:管理版本的最好方法是将所有更改都保存到增量表中。这可以使您充分利用地理数据库的功能，包括存档、复制以及编辑几何网络和拓扑的能力]
• 将所有非 DEFAULT 版本编辑内容保存到增量表，将所有 DEFAULT 版本的编辑内容保存到基表[不支持历史归档][操作:注册版本时勾选“将编辑内容移动到基表”][应用场景举例:这种情况举例，一个部门使用 ArcGIS 维护数据库中的地理数据，而另一个部门使用自定义应用程序维护同一数据库中的客户记录。自定义应用程序需要在事务进行时应用 DBMS 约束和触发器并且可能不识别版本化表。与此同时，另一部门需要在自己的独立版本中编辑地理数据，在编辑完成并通过批准之后再共享部门编辑内容。]

下面具体看看如何使用版本化数据：

• DEFAULT版本：每个ArcSDE地理数据库都具有一个名为DEFAULT的默认版本，其始终存在且不能被删除，一般用来作为数据库的发布版本。在版本体系中，DEFALUT版本作为根版本，您可以将其他版本中的变更提交到DEFALUT版本，从而逐步维护和更新DEFAULT版本。
• 其他版本：可以通过从任意现有版本创建子版本或分支版本的方式创建其他版本。版本机制中，无论有多少个版本，各表和要素类在数据库仅存储一次，ArcGIS保留了各要素类和表的原始格式，但会在被称为增量表（A表和D表）的表中记录所有更改。用户可以同时编辑所有版本，多个用户还可以同时编辑同一版本。

通过以上基本知识的了解，深入探索一下版本和版本化编辑的工作原理：

对任意版本中的数据开始执行版本化编辑之前，必须将数据集注册为版本。

理解将数据集注册为版本和创建版本的区别：

• 创建版本时所创建的是地理数据库的某种“视图”，您可以通过该“视图”编辑版本化数据并随即查看所做的更改。连接到同一版本的其他用户将在刷新之后看到这些更改。但是，在您对这些更改进行协调并提交到祖先版本之前，连接到其他版本的用户将不会看到这些更改。举个例子，如下图所示版本工作流示意：在进行版本化编辑之后，将更改提交回DEFALUT版本之后，无论您连接的是哪个版本，这些更改都是可见的。

• 将数据集（要素类、要素数据集或表）注册为版本会使其为版本化编辑准备就绪。将数据集注册为版本时，会创建两个增量表：用于插入和更新的A(或叫“添加”)表以及用于删除的D(或叫“删除”)表。每次更新或删除数据集中的记录时，都会向这两个表或其中一个表添加行。因此，版本化数据集包含原始表（称为基表）以及增量表中的所有更改。进行可填充增量表的编辑时，地理数据库会追踪您所连接的版本。查询或显示版本中的数据集时，ArcGIS 对原始表和增量表中的相关行进行组合，呈现出数据的无缝视图。

无论在哪个版本中进行编辑，对要素类或表所做的全部编辑都会被记录到同一增量表。总的来说，基表、A 表和 D 表中的所有行表示要素类或表的所有版本。这表示任何一个版本都只能引用这三个表中的行的子集。那么，ArcGIS 如何记住增量表中属于各版本的行呢？

• 使用被称为“状态 ID”的整型标识符对 A 表和 D 表中的各行进行标记，以在向表中添加行时提供参考。每次编辑版本时均会创建新的状态，并向这两个增量表或其中一个增量表添加新行。状态可被看作是树结构的一部分，在树结构中，各分支记录了版本的发展情况。记录版本从基表到当前状态之间一连串变更的一系列状态称为谱系。显示或查询版本时，ArcGIS 会查询版本的谱系以获取“状态 ID”，然后从 A 表和 D 表中检索正确的记录。

以上概念性的描述不太形象，来看看Oracle数据库中是通过哪些表来追踪版本：

在内部，版本通过多个数据库表（数据集表、增量表和系统表）来管理，以追踪版本。

虚线表示各列之间的隐含关系。

添加和删除表的名称中的数字为 TABLE_REGISTRY 表中业务表的 REGISTRATION_ID。

• 创建版本

  在创建版本时，会在Versions表中创建一条新纪录，包括版本名称、版本描述、版本创建时间等信息，最需要注意的是Status和State_ID两个字段;

  Status：默认值为1，表明该版本正在进行版本事务状态；

  State_ID：获得最新的编辑状态ID;

  

• 版本编辑

  所有进行的编辑都会在STATES表（状态表）中记录相关的编辑状。在版本编辑时，该表会记录每一步的编辑状态，但是在保存编辑时，会记录一个最终的有效的编辑状态。举例说明：创建一个要素（记录了一次状态），填写属性（记录第二次的状态），但是当保存编辑的时候，只记录最终的一个编辑状态。

  

  STATE_LINEAGES表（世系表）与STATES表（状态表）是类似的，只存储最终的编辑状态。所谓世系表，是说如果一个DEFALUT版本创建一个子版本，相应的编辑状态值会对应继承DEFALUT版本的LINAEAGE_NAME值进行记录，如果在另外一个子版本进行编辑，会获得最新的编辑状态作为另一个子版本的LINEAGE_NAME值来记录该版本的编辑状态。

  

  在MVTABLES_MODIFIED表中记录了针对每一个注册ID（也就是要素类）的多版本编辑状态。

  

  所有在注册版本记录上新创建的数据都会存储在A表中，因为A表也有一个编辑状态，所以根据STATES表的编辑状态可以定位到A表的某条数据，所有的空间数据、属性数据的信息都可以获得。

  

  所有注册版本记录上的对数据的删除信息都保存在D表中，记录相关的删除状态、OBJECTID、新建的状态ID，根据后两个字段可以唯一定位到删除数据信息。

  

• 协调版本

  只介绍STATES和STATE_LINEAGES这两个表的变化，在协调版本时会将子版本的数据与相应父版本进行协调，上面我们介绍各个版本对应一个LINEAGE_NAME，所以这两个表会添加两条相应的记录。特别介绍一下STATES表，添加一条记录是一个新的协调状态ID（STATE_ID），然后记录开始时间和结束时间，对应的世系版本ID会是当前编辑版本的值，而且还会添加一条记录，就是对应协调目标版本的协调ID，协调版本的LINEAGE_NAME，以及创建时间，但是结束时间没有进行存储。

  

  这里也就对应了上面所说的在协调过程中只会更新编辑版本的数据，并不会更新协调版本的数据。

• 提交版本

  也只介绍STATES和STATE_LINEAGES这两个表的变化，上面所说的对应协调版本的结束时间没有存储，在进行提交版本后，就存储了协调版本的结束时间（对应STATES表的记录）。

  

  在提交过程中，Versions表还会进行相应的变化，因为针对于某一个子版本的事务已经结束，那么STATUS值和STATE_ID也会发生相应的变化。

  STATUS：变为某一个很大的值，表明该版本结束了相关事务；

  STATE_ID：获得结束该版本编辑的一个状态值，也可以理解为获得当前一个最新的编辑状态ID。

  

随着对地理数据库不时进行编辑，增量表的大小和状态的数量会有所增加。表越大、状态越多，每次显示或查询版本时 ArcGIS 所必须处理的数据就越多。要保持数据库的性能，ArcSDE 管理员必须定期运行“压缩”命令，以移除不使用的数据，之后再使用“分析”命令更新数据库统计数据。

• 压缩：地理数据库压缩操作可从对版本以及版本化编辑进行跟踪的系统表中移除不必要的状态和行，还可将增量表中的行移动到业务表（基表）中。压缩操作只能由 ArcSDE 管理员来执行，可对地理数据库中的所有状态进行操作，与版本所有者无关。

  压缩操作很有必要，因为随着对编辑地理数据库不断进行编辑，增量表的大小和状态的数量也会不断增加。表越大、状态越多，每次显示或查询版本时 ArcGIS 所必须处理的数据就越多。因此，对性能的最大影响不是版本的数量，而是增量表中对每个版本的更改量。因此，各个版本就可能具有不同的查询响应时间。

  要维护数据库性能，ArcSDE 管理员必须定期运行压缩操作来移除未使用的数据。

• 分析：此命令可用于更新地理数据库的数据集中的统计数据。对业务表、要素表、增量表、栅格表和历史存档表中的统计数据以及与这些表相关联的索引中的统计数据进行更新。

理解“将编辑内容移动到基表”类型的注册版本：

在将不参与网络、拓扑或历史归档的数据注册为版本时，您可以指定是否要将对 DEFAULT 版本进行的编辑移动到基表中。如果指定此选项，则仍将更改记录到增量表中。但是在进行保存时，会将更改从增量表中移动到基表，而增量表中不会保存更改。

在将数据注册为版本时，如果所做的修改仅需要数分钟即可完成并且使用第三方应用程序连接到版本化地理数据库，则指定此选项会很有帮助。

第三方应用程序通常仅可用于查询基表，而无法查看增量表。如果使用版本化，且未选择将编辑移动到基表，那么这些应用程序将无法查看尚未协调并提交到 DEFAULT 版本的在其他版本中进行的编辑。请注意，编辑 DEFAULT 之外的版本时，会在同一增量表中记录更改。保存时，更改会保留在增量表中。但是，将更改合并到 DEFAULT 版本时，更改会从增量表移动到基表。将更改合并到 DEFAULT 之外的版本时，更改将保留在增量表中，就像未指定将编辑移动到基表的选项一样。

Oracle中针对版本管理策略的添加和管理用户：

• 用户帐户是用来标识连接到地理数据库的人员或客户端应用程序的唯一名称和密码，决定了哪些用户可以访问数据以及数据归哪些用户所有。
• 在地理数据库中创建表时用于与地理数据库建立连接的用户名即是数据所有者的名称。
• 了解数据归谁所有至关重要，因为如果某用户在数据库中拥有数据，则不允许将该用户帐户从数据库中移除；而且，将由创建数据集的用户控制其他用户访问该数据集的权限级别。
• 在Oracle中的ArcSDE管理用户账户的推荐方案：建议只将 ArcSDE 管理员及其方案用于管理和存储 ArcSDE 系统表。对于要素类和栅格数据集等 ArcSDE 数据对象，应创建单独的用户方案来进行存储。不要将这些对象存储在 ArcSDE 管理员存储空间中，因为这样可能会因 ArcSDE 管理员空间被填满而导致 ArcSDE 服务崩溃。如果能够遵守操作规范，将系统表仅存储在 ArcSDE 管理员存储空间中，则可以简化 ArcSDE 的管理。

那么什么是用户权限？

权限用于决定授权用户对数据和地理数据库执行何种操作。应根据人员在组织中所执行的工作类型来分配权限。用户是否为地理数据库的管理员？用户是否需要编辑或创建数据？用户是否仅需查询数据？

对用户或用户组指定的权限会影响他们在地理数据库中所能执行的操作。有些用户只能连接到地理数据库。这些用户为只读用户。另有一些用户可连接到地理数据库并创建数据集。另有一些用户可连接到数据库并编辑数据集，但无法创建或删除数据集。还有一些用户可执行管理任务，如创建备份文件或执行压缩操作。

可在不同级别设置用户权限：数据库、地理数据库版本以及数据库中的数据集。

• 数据库权限[建用户账户时分配的权限]

  这些权限用于决定用户或用户组可在地理数据库中或对地理数据库执行的操作；例如，用户是可以创建新数据集还是可以管理地理数据库。

• 地理数据库版本权限[在创建版本时决定的其他用户对版本的访问权限]

  还可以通过设置权限来控制用户对地理数据库版本的访问。这是一种特殊的数据库权限类型，并不通过 DBMS 进行设置。而是在创建地理数据库版本时由该版本的创建者决定其他用户对此版本所具有的访问类型。如果将版本创建为“公共”版本，则所有用户均可对其进行访问及修改。如果将其创建为“私有”版本，则只有该版本的创建者可以对其进行访问。如果版本为“受保护”版本，则其他用户可以查看该版本，但只有创建者可以对其进行修改。

• 数据集权限[在ArcMap中针对某个指定用户对数据集进行的权限分配]

  数据集权限用于决定用户可对特定数据集执行的操作：用户是可以对数据集进行编辑，还是只能从中查询数据？特定数据集的使用权限由该数据的所有者（即为创建数据或将数据导入地理数据库的用户）进行控制。可授予用户只读（查询）权限，也可授予读/写（更新、插入和删除）权限。这些数据集权限用于决定用户是否为编辑者；如果用户不具备任何数据集的更新、插入或删除权限，则此用户不是编辑者。

下列规则适用于授予和撤消数据的权限：

• 只有数据集所有者才能更改该数据集的权限。
• 撤消权限需要数据集的排它锁；因此，如果有其他用户连接到该数据集，则您无法撤消用户对该数据集的权限。
• 无法向用户授予要素数据集内要素类的不同权限。
• 如果已将新要素类添加到要素数据集中或在要素数据集中构建了网络或拓扑，所有者必须再次授予要素数据集的权限，以便能够将这些权限应用到要素数据集的新表中。
• 只有数据集所有者才能删除数据集或更改其定义；因此，即使数据集所有者向另一用户授予了数据集的 INSERT、UPDATE 和 DELETE 权限，该用户也无法更改数据集的方案。
• 您每次只能改变用户对一个数据集的权限。
• 输入用户名时，可能要求您将域名或计算机名与该用户名一同提供，这取决于存储数据集的数据库管理系统类型以及用户连接到该地理数据库时所使用的身份验证类型。例如，如果创建的操作系统登录帐户包括域或计算机前缀，那么您需要输入域名或计算机名，后加反斜线和用户名：BARNYARD\user1

对版本机制原理和Oracle中ArcSDE管理用户策略有了个大概的了解以后，来看看ArcGIS有关地理数据库权限，这些是如何来控制对数据的访问：

在创建版本时，创建者可以指定版本的名称、可选版本描述和版本的权限，作为版本的所有者，您可以随时更改这些属性或删除版本。

您可以设置版本权限以防止版本被版本所有者以外的用户编辑或查看。可对版本设置下面其中一种权限：

• 私有 - 只有所有者或 ArcSDE 管理员可以查看版本和修改已版本化的数据。
• 受保护的 - 任何用户都可以查看版本，但是只有所有者或 ArcSDE 管理员可以对具有读/写权限的数据库进行编辑。
• 公共 - 任何用户都可查看版本。任何具有数据集读/写（UPDATE、INSERT 和 DELETE 或读/写）权限的用户都可以修改那些数据集。

设置版本权限时，要考虑版本的工作流策略以及在该框架下工作的各类用户的需要。应同时使用版本权限和数据集权限来控制对数据的访问。

设置权限时，应特别注意 DEFAULT 版本所采用的保护方式。DEFAULT 版本是地理数据库中所有其他版本的祖先版本，通常代表已发布的地理数据库版本。对于从 DEFAULT 版本中删除的任何要素或行，即使这些要素或行已记录在版本的增量文件中，也无法恢复，除非将数据集取消注册版本（假设事先未压缩数据库）。将数据集取消注册版本可以将数据集恢复为上次压缩数据库时的配置；不过，所有未压缩的编辑内容都将丢失。鉴于这一点，完全有必要保护 DEFAULT 版本以防止发生意外修改或损坏。

可通过三种方法来保护 DEFAULT 版本：

• 如果已选择了用户可直接编辑 DEFAULT 版本的策略，那么您可将新版本创建为 DEFAULT 的只读存档版本。任何从 DEFAULT 版本中意外删除的要素都可以根据需要从该版本中恢复。
• 如果选择了部分用户需要直接编辑 DEFAULT 版本的策略，那么您可以使用 DEFAULT 来创建新版本，供其中一些用户进行编辑。
• 如果选择了无人直接编辑 DEFAULT 的策略，那么 ArcSDE 管理用户应该将 DEFAULT 版本的权限设置为 PROTECTED 而不是 PRIVATE；PRIVATE 会防止除 ArcSDE 管理用户以外的所有用户连接到数据库。如果将权限设置为 PROTECTED，则任何用户都可以查看 DEFAULT 版本，但只有 ArcSDE 管理用户可以对 DEFAULT 版本直接进行编辑或协调并可从其他版本中将编辑内容提交到 DEFAULT 版本。

对于版本机制的实现原理，版本表的变化是非常复杂的。尤文G斯博客的博主强烈建议：由于机制实现相关表的关系比较复杂，禁止用户直接利用操作普通表的方法修改SDE库中版本表的相关数据，因为一旦把相关的状态联系删除错误，那么就意味着你可能要重新建库。

本人亲身体验过由于在SDE中直接操作历史归档相关表导致的SDE库混乱的痛苦，所以建议大家遵循ESRI公司的规则，没有对机制更深入的理解还是不要直接去操作相关表。