ArcGIS 10——地理数据库管理GIS数据

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

 

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

• 文件地理数据库-在文件系统中以文件夹的形式存储。每一个数据集都以文件形式保存，该文件大小最多可扩展至1TB。建议使用文件地理数据库而不是我的地理数据库；
• 我的地理数据库-全部的数据集都存储于Ms Access数据文件内，该文件的大小最大为2GB。
• ArcSDE地理数据库-使用Oracle、MS SQL Server、IBM DB二、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公司的规则，没有对机制更深刻的理解仍是不要直接去操做相关表。