Desktop Help 10.0 - 「バージョニングの概要」をご参照ください。

このトピックは、ArcEditor および ArcInfo にのみ適用されます。

バージョニングにより、データにロックを適用したりデータを複製したりせずに、複数のユーザが ArcSDE ジオデータベースの同じデータを編集できます。

ユーザは常にバージョンを通じて ArcSDE ジオデータベースにアクセスします。マルチユーザジオデータベース（バージョン対応のジオデータベース）に接続する際には、接続先のバージョンを指定します。デフォルトでは、DEFAULT バージョンに接続します。

DEFAULT バージョン

ArcSDE ジオデータベースには、DEFAULT という名前の既定のバージョンが必ず存在します。このため、ジオデータベースにおいてバージョニングは常に有効です。バージョニングは ArcGIS が動作する仕組みの基礎を担っており、個別にインストールまたは設定する必要はありません。

他のバージョンとは異なり、DEFAULT バージョンは常に存在し、削除することはできません。ほとんどのワークフローでは、DEFAULT バージョンはデータベースのマスタバージョンであり、モデルとなるシステムの現在の状態を表します。他のバージョンからの変更をポスト（反映）することにより、DEFAULT バージョンを管理および更新します。また、他のバージョンと同様に、DEFAULT バージョンを直接編集することもできます。

DEFAULT バージョンはルートバージョンであり、したがって他のすべてのバージョンの上位バージョンです。

他のバージョンの作成

バージョンを作成するには、既存のバージョンの子バージョンを作成します。したがって一番最初のバージョンは、DEFAULT バージョンの子バージョンとして作成されます。新しく作成したバージョンは、作成された時点では、親バージョンとまったく同じジオデータベースの状態を表します。親バージョンと子バージョンにそれぞれ独自の変更が加えられる過程で、各バージョン間に差が生じていきます。

ジオデータベースには多くのバージョンを作成することができます。ArcGIS Desktop からアクセスする [バージョンマネージャ] ダイアログボックスを次に示します。この例では、DEFAULT バージョンと品質保証バージョン（QA）、そしてプロジェクトバージョンとして ProjectA および ProjectB が表示されています。

次の図は、各バージョンの関連付けを示しています。QA バージョンは DEFAULT バージョンの子であり、ProjectA バージョンと ProjectB バージョンは QA バージョンの子です。

バージョンを作成すると、ジオデータベース全体のコピーを作成したような錯覚にとらわれます。これは、各バージョンがジオデータベースのすべてのテーブルとフィーチャクラスで構成されるためです。あるバージョンでフィーチャクラスまたはテーブルを編集すると、親バージョンのフィーチャクラスやテーブルとは同じではなくなるため、ユーザはフィーチャクラスやテーブルを各バージョンに格納していると考えます。しかし、バージョンをいくつ作成した場合でも、テーブルやフィーチャクラスの複製がデータベースに作成されるわけではありません。ArcGIS は、各フィーチャクラスとテーブルをそれぞれ元の形式のままにして、変更内容を差分テーブルと呼ばれるテーブルに記録します。

ユーザはすべてのバージョンを同時に編集することができます。また、複数のユーザが同じバージョンを同時に編集することも可能です。

前述のバージョン例では、複数の編集ユーザが ProjectA バージョンと ProjectB バージョンを同時に編集できます。QA バージョンで品質管理を行うユーザ数は、おそらくそれより少なくなります。

バージョンとバージョン対応編集の仕組み

あるバージョンのデータに対してバージョン対応編集を実行するには、そのデータセットをバージョン対応登録する必要があります。

データセットをバージョン対応登録することと、バージョンを作成することは、同じではないことに注意してください。バージョンを作成すると、ジオデータベースのビューのようなものが作成されます。このビューでは、バージョン対応データを編集することができ、変更もすぐに反映されます。同じバージョンに接続しているユーザは、表示を更新すれば変更を見ることができます。ただし、下位のバージョンに接続しているユーザは、上位バージョンに対してリコンサイルを実行するまで上位バージョンの変更を確認できません。前述の例では、いったん 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 以外のバージョンにマージした場合は、ベーステーブル移行オプションを指定しない場合と同様に、変更は差分テーブルに残ります。

権限およびバージョン編集

バージョンの所有者（作成したユーザ）は、バージョンに権限を設定して、表示と編集を制限することができます。権限のオプションはプライベート（所有者のみがバージョンのデータセットを表示および編集できる）、プロテクト（どのユーザもバージョンのデータセットを表示できるが、編集できるのは所有者のみ）、およびパブリック（データセットに対する権限を割り当てられていれば、どのユーザもデータセットを表示および編集できる）です。

次に示す [バージョンマネージャ] ダイアログボックスを見るとわかるように、DEFAULT バージョンはプロテクト、他のバージョンはパブリックです。

ヒント:

バージョンの権限の詳細については、「バージョンの作成と権限の設定」をご参照ください。

ArcGIS で特定のバージョンのデータを編集するには、特定のバージョンに接続し、バージョン対応登録されているデータを ArcMap に追加します。

ヒント:

ArcMap で接続しているバージョンを切り替えることもできます。詳細については、「ArcMap でのバージョンの変更」をご参照ください。

デフォルトでは、ArcMap のすべての編集セッションがバージョン対応です。そのため、マップにバージョン対応データがあれば、編集セッションを開始してすぐに編集を始めることができます。編集セッションを開始するには、[エディタ] ツールバーの [エディタ] ドロップダウンリストで [編集の開始] をクリックします。

各バージョンへの編集は、そのバージョンにのみ適用されます。例外はスキーマの変更です。バージョンのスキーマを変更すると（たとえば、テーブルに新しいフィールドを追加するなど）、その変更は他のすべてのバージョンに適用されます。

編集の完了後は、上位バージョンに対してリコンサイルしてから変更内容をポストします。

変更のリコンサイルとポスト

リコンサイルおよびポストを実行すると、親バージョンや DEFAULT バージョンなど、作業しているバージョンの上位にあるバージョンに変更内容が統合されます。リコンサイルでは、編集中のバージョンにおける変更内容が、マージ先となるバージョンと比較されます。

バージョンのデータを変更する際に、データにロックは適用されません。2 人の編集ユーザが同じバージョンまたは異なるバージョンで同じデータを編集すると、競合（コンフリクト）が発生することがあります。競合が発生するのは、2 つの編集プロセスで同じ行に対して異なる編集が行われた場合です。リコンサイルプロセスでは、各競合が表示され、行のどちらの編集内容を採用するか選択することができます。

一般的に編集の量は編集対象の地理データ全体に対してごくわずかとなるので、編集の競合が頻発することは多くはありません。正しく設計されたワークフローでは、トランザクション中にフィーチャをロックまたはチェックしなくても良いことを考えれば、競合をリコンサイルするコストはごくわずかと考えることができます。

リコンサイルが完了したら、変更内容をポストすることができます。これにより、変更内容が他のバージョンに適用されます。他のバージョンへポスト済みのバージョンがそれ以上必要なければ、削除することができます。あるいは、そのバージョンをさらに編集し、再びリコンサイルしてポストすることもできます。

QA/Project の例で各バージョンに割り当てられた権限に基づいて、論理的なリコンサイルとポストのワークフローは、Project バージョンから QA バージョンに、そして DEFAULT バージョンに進みます。

バージョン:使用例

バージョンを使用する方法を示すため、都市の水道を例に考えてみます。水道局には、水道管、バルブ、ポンプなどの水道システムのコンポーネントの現在の状態を表すフィーチャのジオデータベースがあります。水道局では、水道システムの水道管を新たに拡張する必要があります。

水道局は、DEFAULT バージョンから「Extension project」という名前の新しいバージョンを作成します。このバージョンには、水道管を拡張するための設計が含まれています。ただし、水道管を拡張するのに 16 インチと 24 インチのどちらの送水管を使用するかについては確定していません。そこで、Extension project バージョンから、16 インチの設計と 24 インチの設計を調査するための新しいバージョンを作成します。

最終的に、24 インチの水道管であれば今後 12 年間に予想される水道需要をまかなえることと、初期工事費用の点でもこちらのほうが有利であることが判明します。24 インチの設計が承認されると、設計の正確さが確認された上で、Extension project バージョンにポストされます。

それから数か月後、新しい水道管の拡張工事が完成すると、データベースのマスタバージョンを更新するために、Extension project バージョンが、変更内容の正確さが確認された上で、DEFAULT バージョンにリコンサイルおよびポストされます。

「バージョニングの概要」をご参照ください。