浏阳做网站的公司价格,wordpress 京东主题,h5开发网站,设计广告图片用什么软件写本文的最初意向是当前正在进行的项目中有实现ESRI版本化数据管理的功能模块#xff0c;碰到一些棘手的问题#xff0c;几经周折还是决定系统学习ArcGIS10的帮助文档。#xff08;文章摘抄的比较多#xff09; 地理数据库是用于保存数据集集合的“容器”。首先了解一下Arc…写本文的最初意向是当前正在进行的项目中有实现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表添加一条记录是一个新的协调状态IDSTATE_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 而不是 PRIVATEPRIVATE 会防止除 ArcSDE 管理用户以外的所有用户连接到数据库。如果将权限设置为 PROTECTED则任何用户都可以查看 DEFAULT 版本但只有 ArcSDE 管理用户可以对 DEFAULT 版本直接进行编辑或协调并可从其他版本中将编辑内容提交到 DEFAULT 版本。 对于版本机制的实现原理版本表的变化是非常复杂的。尤文G斯博客的博主强烈建议由于机制实现相关表的关系比较复杂禁止用户直接利用操作普通表的方法修改SDE库中版本表的相关数据因为一旦把相关的状态联系删除错误那么就意味着你可能要重新建库。 本人亲身体验过由于在SDE中直接操作历史归档相关表导致的SDE库混乱的痛苦所以建议大家遵循ESRI公司的规则没有对机制更深入的理解还是不要直接去操作相关表。转载于:https://www.cnblogs.com/giserxiaoliang/p/3493695.html
