寫本文的最初意向是當前正在進行的項目中有實現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公司的規則，沒有對機制更深入的理解還是不要直接去操作相關表。