Standard または Advancedのライセンスで利用可能。
従来のバージョニングにより、データにロックを適用したりデータを複製したりせずに、複数のユーザーがエンタープライズ ジオデータベースまたはワークグループ ジオデータベース内の同じデータを編集できます。従来のバージョニングでは、これを可能にするために、差分テーブルと呼ばれる補助テーブル内に編集内容を保存します。
トポロジ、ネットワーク データセット、またはジオメトリック ネットワークに属しているフィーチャクラスを編集したり、パーセル ファブリックを編集したりするには、データをバージョン対応登録する必要があります。これは、ネットワーク、トポロジ、またはパーセル ファブリックのフィーチャを編集する際、すべてのフィーチャがロックされないためです。つまり、他のユーザーがネットワーク、トポロジ、またはパーセル ファブリックの他の部分を編集できるため、競合が発生するおそれがあります。
バージョンを通じてエンタープライズ ジオデータベースまたはワークグループ ジオデータベースに常時アクセスします。ArcGIS からジオデータベースに初めて接続すると、Default バージョンに接続します。別のバージョンに接続して、その情報をデータベース接続ファイル (*.sde) に保存するには、ジオデータベース プロパティのバージョンを指定します。
バージョンとは
バージョンは、ジオデータベースにおけるビューのようなもので、編集作業を区分けして管理します。複数のユーザーが同じバージョンに接続すると、そのユーザーには、そのバージョンで実行された編集が表示されます。下位バージョンに接続しているクライアントは、ユーザー本人が共通の上位バージョンに対して変更内容のリコンサイルとポストを実行するまで変更内容を確認できません。
Default バージョン
Default バージョンはルート バージョンであり、したがって他のすべてのバージョンの上位バージョンです。
他のバージョンと異なり、Default バージョンは常に存在し、削除することはできません。ほとんどのワークフロー戦略では、Default バージョンは、モデル化されているシステムの現在の状態を表しているため、レコードの信頼できるシステムとしてユーザーが公開または使用するバージョンとなります。他のバージョンからの変更をポスト (反映) することにより、Default バージョンを管理および更新します。また、他のバージョンと同様に、DEFAULT バージョンを直接編集することもできます。
他のジオデータベース バージョンの作成
ジオデータベースの従来のバージョンを作成するには、既存の従来のバージョンの子バージョンを作成します。最初に作成するバージョンは、Default バージョンの子バージョンです。この子バージョンは、作成された時点では、Default バージョンとまったく同じジオデータベースの状態を表します。Default バージョンと子バージョンにそれぞれ独自の変更が加えられる過程で、各バージョン間に差が生じていきます。
ジオデータベースには多くの従来のバージョンを作成することができます。次の図は、ArcMap の [バージョン マネージャー] ダイアログ ボックスを示しています。この例には、DEFAULT バージョンとその他の 4 つのバージョン、およびこれらの関係を示す、ダイアログ ボックスのツリー ビューが表示されています。Cases バージョンと Base バージョンは DEFAULT バージョンの子バージョンであり、Case1 バージョンと Case2 バージョンは Cases バージョンの子バージョンです。
バージョンを作成すると、ジオデータベース全体のコピーを作成したような印象を受けますが、実際は違います。従来のバージョンをいくつ作成しても、テーブルとフィーチャクラスは 1 回しかデータベースに保存されません。ArcGIS は、各フィーチャクラスとテーブルをそれぞれ元の形式のままにして、変更内容を差分テーブルと呼ばれるテーブルに記録します。
バージョンは、複数のユーザーが同時に編集することができます。
従来のバージョンとバージョン対応編集の仕組み
従来のバージョンのデータに対してバージョン対応編集を実行するには、そのデータセットを従来のバージョン対応登録する必要があります。
データセット (フィーチャクラス、フィーチャ データセット、またはテーブル) を従来のバージョン対応ワークフローで使用するために登録すると、2 つの差分テーブルが作成されます。1 つは挿入内容と更新内容を記録する A (ADD) テーブル、もう 1 つは削除内容を記録する D (DELETE) テーブルです。データセットでレコードを更新または削除するたびに、これらのテーブルのどちらかまたは両方に行が追加されます。したがって、従来のバージョン対応登録されたデータセットには、元のテーブル (ベース テーブルまたはビジネス テーブルと呼ばれます) だけでなく、差分テーブル内の変更内容も含まれます。ジオデータベースは、差分テーブルに適用される編集が行われた時点でユーザーが接続していたジオデータベース バージョンを追跡します。あるジオデータベース バージョンでデータセットを検索または表示すると、ベース テーブルと差分テーブルから関連する行が組み立てられて、データのそのバージョン固有の状態が表示されます。
特定のフィーチャクラスまたはテーブルに加えられた編集内容はすべて、編集前のバージョンに関係なく、同じ差分テーブルに記録されます。つまり、どのバージョンも 3 つのテーブルの行の一部だけを参照していることになります。それでは、ArcGIS は差分テーブル内のどの行がどのバージョンに属しているかをどのようにして把握するのでしょうか。
ADD テーブルと DELETE テーブルの行はそれぞれ、ステート ID と呼ばれる整数の識別子でマークされます。ステート ID は、行がテーブルに追加された状況を参照します。バージョンを編集するたびに、新しいステート (状態) が作成され、差分テーブルのどちらかまたは両方に新しい行が追加されます。ステートについては、バージョンがどのように発展したかが各ブランチ (枝) に記録された、ツリー構造の一部と考えることができます。ベース テーブルがバージョンの現在の状態になるまでの一連の変更を記録するステート群を、系統と呼びます。バージョンを検索または表示すると、ArcGIS がバージョンの系統を検索して系統に属するステート ID を取得し、ADD テーブルと DELETE テーブルから適切なレコードを取得します。
ジオデータベースが編集されるに従って、差分テーブルのサイズとステート (状態) の数は増えていきます。テーブルのサイズとステートの数が増えるにつれ、バージョンの表示や検索のたびに ArcGIS が処理しなければならないデータは増えていきます。データベースのパフォーマンスを維持するために、ジオデータベース管理者は [圧縮] コマンドを定期的に実行して、使用されていないデータを削除する必要があります。
ベース テーブル移行オプション
データを従来のバージョン対応登録する際にベース テーブル移行オプションを指定すると、変更内容が差分テーブルに記録されます。ただし、Default バージョンを編集して、編集内容を保存した場合、その編集内容は即座に差分テーブルからベース テーブルに移行し、差分テーブルから削除されます。このことは、Default バージョンを編集した場合にしか当てはまりません。下位バージョンに加えられた編集内容は、即座にベース テーブルに移行しません。
ベース テーブル移行オプションは、次の場合に役立ちます。
- 編集の実行時間が数分である。
- データがネットワークやトポロジに属していない。
- 従来のバージョニングを使用するジオデータベースへのアクセスに、サードパーティのアプリケーションを使用している。
ほとんどのサードパーティのアプリケーションは、ベース テーブルのみを検索します。すなわち、差分テーブルにアクセスできません。従来のバージョニングを使用するときにベース テーブル移行オプションを選択しないと、これらのアプリケーションは、Default バージョンにリコンサイルおよびポストされていないその他のバージョンで実行された編集内容を取り込みません。Default 以外のバージョンを編集する場合、変更内容は同じ差分テーブルに記録されることに注意してください。これらの他のバージョンに編集内容を保存すると、変更は差分テーブルに残ります。ただし、リコンサイルおよびポスト プロセスを使用して、変更を Default バージョンにマージすると、変更は差分テーブルからベース テーブルへ移行されます。変更を Default 以外のバージョンにマージした場合は、ベース テーブル移行オプションを指定しない場合と同様に、変更は差分テーブルに残ります。
権限とバージョン編集
ジオデータベース バージョンの所有者 (作成者) またはジオデータベース管理者は、バージョンに対するアクセス権限を付与できます。アクセス権限には、次のオプションがあります。
- [プライベート] - バージョンの所有者またはジオデータベース管理者だけが該当するバージョンでデータセットの表示と編集を実行できます。
- [プロテクト] - どのユーザーも該当するバージョンでデータを表示できますが、編集できるのはバージョンの所有者とジオデータベース管理者だけです。
- [パブリック] - テーブルとフィーチャクラスに対する編集権限が付与されている限り、どのユーザーもそのデータの表示と編集を実行できます。
バージョンのアクセス権はバージョンの作成時に設定されますが、バージョンの所有者またはジオデータベース 管理者は、後で [バージョン マネージャー] ダイアログ ボックスを使用して権限を変更することができます。詳細については、「バージョンの作成と権限の設定」および「バージョンのプロパティ」をご参照ください。
テーブルまたはフィーチャクラスがバージョン対応登録され、バージョンが作成される (必要な場合) と、他のユーザーも含めユーザーはデータを編集できるようになります。ArcMap で編集するには、編集するジオデータベース バージョンに接続し、バージョン対応テーブルまたはフィーチャクラスをマップに追加します。
デフォルトでは、ArcMap のすべての編集セッションがバージョン対応です。そのため、マップにバージョン対応登録されたデータがあれば、編集セッションを開始してすぐに編集を始めることができます。
編集内容は、編集時に接続しているバージョンにのみ適用されます。編集が終了したら、上位バージョンに対して変更内容のリコンサイルとポストを実行します。
変更内容のリコンサイルとポスト
リコンサイルとポストを実行すると、作業中のバージョンの上位にあるバージョン (親バージョンや Default バージョンなど) に変更内容が統合されます。リコンサイルでは、編集中のバージョンにおける変更内容が、マージ先となるバージョンと比較されます。
バージョンのデータを変更する際に、データにロックは適用されません。このため、複数のユーザーが同じデータを操作すると、それが同じバージョンであっても異なるバージョンであっても、競合が発生する可能性があります。競合が発生するのは、2 つの編集プロセスで同じ行に対して異なる編集が行われた場合です。リコンサイル プロセスでは、各競合が表示され、行のどちらの編集内容を採用するかを選択することができます。
一般的に編集の量は編集対象の地理データ全体に対してごくわずかとなるので、編集の競合が頻発することは多くはありません。正しく設計されたワークフローでは、編集トランザクション中にフィーチャをロックまたはチェックしなくても良いことを考えれば、競合をリコンサイルするコストはごくわずかと考えることができます。
リコンサイルし、競合が解決したら、変更内容をポストすることができます。これにより、変更内容が上位バージョンに適用されます。(子バージョンから) ポスト済みのバージョンがそれ以上必要なければ、削除することができます。あるいは、そのバージョンをさらに編集し、再びリコンサイルしてポストすることもできます。
バージョン: 例
従来のバージョンを使用する方法を示すため、都市の水道を例に考えてみます。水道局には、水道管、バルブ、ポンプなどの水道システムのコンポーネントの現在の状態を表すフィーチャのジオデータベースがあります。水道局では、水道システムの水道管を新たに拡張する必要があります。
ユーザーは、Default バージョンから新しいバージョンを作成し、その新しいバージョンに Extension_project という名前を付けます。この新しいバージョンには、新しい拡張の設計に対して行われた編集が含まれます。ただし、水道管を拡張するのに 16 インチと 24 インチのどちらの送水管を使用するかについては確定していません。そこで、Extension_project バージョンから、16 インチの設計と 24 インチの設計を調査するための新しいバージョンを作成します。
最終的に、24 インチの水道管であれば今後 12 年間に予想される水道需要をまかなえることと、初期工事費用の点でもこちらのほうが有利であることが判明します。24 インチの設計が承認されると、設計の正確さが確認された上で、リコンサイルされて、Extension_project バージョンにポストされます。
新しい水道管拡張の建設は、2、3 か月後に完了します。ジオデータベースの公開済みバージョンを更新するために、Extension_project バージョンは、変更内容の正確さが確認された上で、リコンサイルされて Default バージョンにポストされます。
