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公司的規則，沒有對機制更深刻的理解仍是不要直接去操做相關表。