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