Geodatabase and ArcSDE 系列讲座一

ArcGIS 9.2产品推出以后，Geodatabase部分发生了比较大的变化。本次讲座介绍的均是9.2的Geodatabase和ArcSDE的功能。

在产品组成方面：9.1版本中，Geodatabase包括两种：Personal Geodatabase和ArcSDE Geodatabase，其中前者是将空间数据存储在Access中，后者是将数据存储在Oracle，Informix，DB2，SQL Server中 。而9.2版本中，新推出了File Geodatabase，并且在ArcSDE Geodatabase部分，变成了三种类型：ArcSDE Personal Geodatabase，ArcSDE Workgroup Geodatabase，ArcSDE Enterprise Geodatabase。其中前两种是9.2新推出来的产品，是将空间数据存储在SQL Server Express中（详细介绍可见正文），而第三种就是9.1版本的ArcSDE Geodatabase，是将空间数据存储在Oracle，Informix，DB2，SQL Server。

在功能方面：本讲座涉及的功能均为9.2的功能，其中9.1具备的功能包括：Versioning Editing（版本化编辑），Working With a Geodatase Using SQL（支持的数据库仅为Informix和DB2 ），离线编辑（与9.2的空间数据复制中的Check In/Check Out相同）。值得注意的是，9.1版本对存储在ArcSDE中的空间数据只提供版本编辑功能，到了9.2才增加了Non Version（非版本化编辑）功能，以及Registered as visioned with the option to move edits to base（不完全版本化编辑）功能。

第一部分：Geodatabase的基础知识(之一)

Geodatabase能将空间数据存储在文件、MDB文件或者大型DBMS中。以上三种存储方式的区别在于可存储数据量的不同以及可支持的并发用户数量不同，能够实现从小数据量、单用户的文件数据库到大数据量、多用户并发编辑的企业级DBMS的不同层次的应用。

Geodatabase事实上是很多Geographic Dataset的集合，最基本的Dataset的类型包括Feature Classes、Raster Dataset、Attribute Tables。在以上基本要素的基础上，还能定义Geodatabase的Schema、数据的完整性、规则和行为，包括Spatial Reference、Spatial Resolution、Topology、Network、Domain等等。在创建Geodatabase时，首先生成不同的Dataset类型，然后添加或者扩展Geodatabase基本要素的能力，例如添加拓扑、网络、子类以实现GIS行为建模、维护数据完整性以及建立空间关系。

不同的数据库中，存储矢量和栅格数据几何特征的字段是不一样的，如果DBMS能够支持Spatial type Extensions，则能够很容易采用这种方式存储空间几何特征。目前有三种DBMS能够支持Geodatabase的Spatial Type：

（1）Oracle using the ESRI spatial type or optionally the Oracle Spatial type；

（2）IBM DB2 using the Spatial Extender Geometry Object；

（3）Informix using the Spatial DataBlade Geometry Object。

Geodatabase将地理要素以表格的形式存储，每行记录代表一个要素。在Geodatabase的数据表支持的数据类型包括：

Numbers：包括Short Integers、Long Integers、Single-Precision floating points、Double-Precision Floating Point Numbers；

Text；

Date；

BLOB’S；Binary Large Objects用来存储和管理二进制信息，例如Symbols和CAD几何特征；

Globe Identifiers：Globe Unique Identifiers。GlobeID和GUID用来唯一标识一行记录。

第二部分：Geodatabase的基础知识(之二)

对于矢量要素的存储来说，创建新的Feature Dataset或者新的Feature Class时，需要对数据的环境进行设置，即Spatial Reference，以下为主要的几种空间参考的参数：

（1）XY Tolerance

指实现Cluster或者进行拓扑验证、缓冲区分析、多边形叠加等操作时，点与点的坐标之间的最小距离。缺省的XY Tolerance是0.001 meter（投影坐标系）；如果是State Plane Feet，则缺省值是0.003281feet；如果是地理坐标系，则缺省值是0.000000008982995degrees。一旦点与点的X坐标或者Y坐标的距离小于XY Tolerance，则两点应该合并为一个点。缺省状态下XY Tolerance=XY Resolution * 10。在实际应用中，XY Tolerance太大或者太小均有问题，应该根据实际情况设定合适的Tolerance。在设定Topology时，可以设定不同要素类的Rank，以确保当两个要素的点小于XY Tolerance时，应该是哪个点向哪个点移动。

（2）XY Resolution

表示存储要素坐标时的数值精度，即可以保留的小数点的位数。缺省状态下的Resolution是0.0001meter(投影坐标系) ；如果是State Plane Feet，则缺省值是0.0003281feet；如果是地理坐标系，则缺省值是0.0000000008982995degrees。对于3D数据以及Linear Referencing数据，可以分别对Z值和M值设置Z Tolerance、Z Resolution，以及M Tolerance、M Resolution可以将Geodatabase的Feature Classes扩展为高级数据类型：Feature Dataset、Subtypes、Attribute Domains、Relationship Classes、Topology、Network Dataset、Geometric Network、Terrain、Address Locator、Linear Referencing、Cadastral Fabric、Cartographic Representation、Versioning。对于Raster数据的存储来说，Raster数据是采用规则网格表示连续的地理事物和现象。其存储时需要注意以下部分的设置：

Coordinate System；

Reference Coordinate or XY Location；

Cell Size；

Count of Rows和Columns。

Raster和Image数据类型也是存储和管理在关系表格中，Raster数据通常比较大，存储的时候需要一个Side Table来存储，将Raster切为小片，或者大小通常为128*128或者256*256的Blocks，存储在Raster表中，通过Side表的每一行记录去记录栅格中的每一个Block。

第三部分：管理File和Personal Geodatabase

虽然对File Geodatabase和Personal Geodatabase的管理任务很少，但是还是有些管理任务是很重要的，“附件一”为两种数据库需要的管理工作。

Compressing与Compacting所表示的含义与操作是不同的。

对于File Geodatabase来说，Compressing与Smart Data Compression（SDC）采用相同的技术，并且提供更多的优越之处。为了减小存储空间，可以将File Geodatabase的矢量要素和Table压缩成Read-Only格式。Compress以后的数据在ArcMap和ArcCatalog中显示时与未压缩的数据一样，只是不能编辑。

File Geodatabase的Compress不是在物理上将数据压缩得更小，而是将数据组织得更加紧凑，例如重复的完全相同的多点会用一行记录加上点的个数来表示。ArcGIS对不同的字段采取不同的压缩方法，压缩比例由要素的类型以及属性数据的冗余程度来决定。右键单击File Geodatabase，选择Compress File Geodatabase实现该功能。Compress和Uncompress也可以通过Geoprocessing的工具来实现。除了可以通过 Compress File Geodatabase功能来实现文件的压缩以外，如果原始数据的Resolution很精细，而在实际应用中不需要很高的分辨率，则可以将原始数据导入到一个新的粗分辨率的数据库。不能够单独Compress和Uncompress一个Feature Dataset中的Feature Class，如果希望对该Feature Class压缩，则需要将该Feature Dataset中的所有的Feature Class都压缩。对于Rsater Dataset和Raster Catalog的压缩只能由File Geodatabase Geoprocessing工具来实现。

一旦Feature Class和Table被压缩，则不能够对数据进行编辑，并且不能够修改Coordinate System Information、Subtypes、Attribute Domains、Default Value、Filed and their Properties、Representations。唯一能够修改的就是Feature Class和Table的Alias以及Attribute Indexes。

一个Feature Dataset中可以添加Uncompressed Feature Class，如果一个Feature Dataset中同时包含Compressed和Uncompressed的数据，则Uncompressed的数据也不能够被编辑或修改。“附件二”为File Geodatabase对Compress功能的支持程度。

用户能够压缩Relationship、Topology、Geometric Networks、Network Datasets 、Terrains中的要素类，但局限是：不能够针对已经Compressed的Feature Class创建Topology或者Geometric Network，如果压缩Relationship Class的一边的数据，则另一边的数据也不能编辑。如果Topology的Feature Class已经Compressed，则Topology的属性也不能修改。“附件三”为高级要素对Compress功能的支持程度。

Compacting是将文件记录整理、重新归类，以减少存储空间。如果经常添加或者删除数据，就必须定期对File 或者Personal Geodatabase实现Compact，这能够减少文件大小，提高访问速度。

File Geodatabase是将数据存在硬盘的文件夹中，每个Dataset是一个文件，该文件可以达到TB级，而Personal Geodatabase是将数据存储在MDB文件中。当第一次将数据加载到File Geodatabase或者Personal Geodatabase中时，文件中的记录是顺序排列的，但是如果以后删除或者添加要素，则文件中的记录就没有顺序了，会存在很多没有利用的空间，这将加大文件存储的空间，使得数据访问起来速度很慢。

在ArcCatalog中右键单击数据源，选择Compact Database，则可以实现数据库的Compact。如果某个Database正在ArcMap中编辑，则不能够被Compact。

第四部分：Versioning（版本）

Versioning使得多个用户能够同时编辑一个Geodatabase，而不用去复制数据库或者锁定数据库。一个Geodatabase能够有很多Version，事实上不管一个 Geodatabase有多少个Version，数据库中只保存一套Tables和Feature Classes。Version是对Geodatabase的快照，而不是复制。对所有版本的编辑都是保存在Delta表中的。通过创建Version，多个用户可以同时对一个Geodatabase进行编辑，而且多个用户也可以同时编辑一个Version。

在ArcCatalog和ArcMap中，可以像未版本化的数据一样实现数据的查询、浏览和编辑。当用户连接一个多用户的Geodatabase时，通常需要选定连接哪个Version。

所有的ArcSDE Geodatabase均具备Default 版本，所有版本的最原始的源就是Default版本。能够通过提交更新的方式来维护和更新Default版本，也可以对其直接编辑。

用户在创建版本时，可以为版本设定访问权限。对某个版本的编辑只会应用到该版本，而某个版本中Schema的变化则会影响到所有其它的版本。一旦停止编辑，可以将编辑结果提交到任意父版本。首先要Reconcile，即比较提交版本中的数据与父版本是否有冲突，如果有冲突则提供冲突解决办法。然后就是 Post，则将编辑结果提交到父版本。

每一个Table和Feature Class包含两个Delta表：A表和D表。每次更新或者删除版本中的一个记录时，则可能对一个或者两个Delta表进行修改。一个Version包含所有的Original 表以及所有的Delta表的变化，当显示和查询一个版本时，ArcGIS是从Original表和Delta表中查找相应的信息。

对于Feature Class和Table的所有编辑，不管是位于哪个Vision中，都是保存在相同的Delta表中。因此Base中的所有行，以及A和D表的所有记录表示了Feature class和Table的所有版本的信息，任何一个版本都是这三个表的子类。

ArcGIS记录Delta表中的记录属于哪个Version的办法是：A表和D表的每一行都用State ID进行标识。当编辑一个版本时，产生一个新的State，同时产生新的一行添加到A表或者D表。一个系列的States记录了版本从Base表到当前状态，该系列称为Lineage。当你显示或者查询一个Version时，ArcGIS从版本的Lineage中得到State ID，然后从A表和D表中找到相应的信息。

当编辑Geodatabase时，Delta表的大小和State的数量都在增加，表格与State越多，每次处理时的速度就越慢，因此应该定期利用 ArcCatalog中的Compress工具进行数据库压缩，利用Analyze工具实现数据库的Statistics的重建。

在进行数据库处理的时候，有三种选项：Registered As Visioned without the option to move edits to base ,registered as visioned with the option to move edits to base, not registered as versioned.

（1） Registered As Visioned without the option to move edits to base

能够实现的操作包括Undo和Redo操作、长事务编辑、为设计和工程使用命名版本、使用Geodatabase归档、使用数据库复制。不能做的事：创建拓扑、从拓扑中添加或删除要素、添加和删除拓扑规则、创建几何网络、从几何网络中添加或删除要素类。

（2） registered as visioned with the option to move edits to base

不能够做的事：编辑参与拓扑和几何网络的要素类、数据库归档、数据库复制

（3）not registered as versioned

是最原始的状态，能够实现复杂数据类型，包括拓扑和几何网络的编辑与更新。因为Default版本是数据库中最关键的，需要经常更新，因此需要对Default版本定期备份。

如果用户注册版本时采用的是Register with the option to save edits to the base table，编辑简单要素时，编辑的结果还是保存在Delta表中，一旦保存，则这些变化就要从Delta表转移到Base Table中，而在Delta表中不再保存编辑的结果。用户如果编辑的不是Default版本，则变化也是记录到Delta表中，Save以后，变化也依旧保留在Delta表中，然而当Reconcile和Post到Default版本以后，变化就转移到Base 表中了。如果是将版本中的变化Reconcile和Post到非Default版本，则在Delta表中依旧会保留变化信息。Register with the option to save edits to the base table的缺陷就是一旦编辑错误，不能够回退，只能够放弃整个编辑过程。这种方法主要是使得第三方应用能够在版本化的环境下执行类似Non- Version 编辑，而ArcGIS用户是不能够通过这种设置来实现Non-Version编辑的。

第三方应用（非ArcGIS软件或者非AO开发的软件）通常是只能对Base Table进行查询，不能够看到Delta表中的变化。如果将数据注册为版本化，而不选择move the edits to the base table，当用户还没有将编辑结果Reconcile和Post到Default版本时，第三方用户是无法看到其他版本的编辑情况。Unregistered as Versioned将使得用户保留上一次Compress后的数据，而未Compress的数据则将丢失。

对于海量的、多用户的数据库，可以使用自动Reconcile和Post的功能。有两种方式可以实现：Batch Reconcile和Version Reconcile Services

在版本化编辑中，可以多个用户同时编辑一个版本中的数据，也可以多个用户同时编辑同一数据库的不同版本。这两种情况会导致以下两种冲突的发生：

（1）多个用户同时编辑一个版本中的数据：当多个用户同时编辑一个Version时，对每个用户都创建一个Edit Session，每个用户都不能看到其他用户的编辑状态，只有用户Save Edits以后，才能够看到其他用户的编辑状态。如果多个用户同时对一个要素做了不同的操作，则会发生Conflicts，在保存编辑结果时，会出现冲突信息，则根据在Editing Options的Versioning面板上设置的Preferences来处理冲突，看应该保存哪个用户的编辑结果；

（2）如果是子版本和父版本的编辑发生冲突，则在Reconcile的时候会出现冲突信息，用户可以手动去解决冲突；如果用户正在查看的版本又被提交了新的内容，则用户只有Refresh以后，才能看到更新以后的内容。