Standard または Advancedのライセンスで利用可能。
バージョニングにより、データにロックを適用したりデータを複製したりせずに、複数のユーザーがエンタープライズ ジオデータベースまたはワークグループ ジオデータベース内の同じデータを編集できます。
トポロジ、ネットワーク データセット、またはジオメトリック ネットワークに属しているフィーチャクラスを編集したり、パーセル ファブリックを編集したりするには、データをバージョン対応登録する必要があります。これは、ネットワーク、トポロジ、パーセル ファブリックのフィーチャを編集する際、ネットワークまたはトポロジのすべてのフィーチャがロックされないためです。つまり、他のユーザーがネットワーク、トポロジ、またはパーセル ファブリックの他の部分を編集できるため、競合が発生するおそれがあります。
バージョンを通じてエンタープライズ ジオデータベースまたはワークグループ ジオデータベースに常時アクセスします。接続する際に、接続先のバージョンを指定します。デフォルトでは、Default バージョンに接続します。
バージョンとは
バージョンは、ジオデータベースにおけるビューのようなもので、編集作業を区分けして管理します。バージョンにより、ユーザー本人も、同じバージョンに接続している本人以外のどのユーザーも、変更内容を確認することができます。下位バージョンに接続しているユーザーは、ユーザー本人が上位バージョンに対して変更内容のリコンサイルとポストを実行するまで変更内容を確認できません。
Default バージョン
Default バージョンはルート バージョンであり、したがって他のすべてのバージョンの上位バージョンです。
他のバージョンと異なり、Default バージョンは常に存在し、削除することはできません。ほとんどのワークフローでは、Default バージョンはジオデータベースのマスター バージョンであり、モデルとなるシステムの現在の状態を表します。他のバージョンからの変更をポスト (反映) することにより、Default バージョンを管理および更新します。また、他のバージョンと同様に、Default バージョンを直接編集することもできます。
他のバージョンの作成
バージョンを作成するには、既存のバージョンの子バージョンを作成します。したがって最初のバージョンは、Default バージョンの子バージョンとして作成されます。新しく作成したバージョンは、作成された時点では、Default バージョンとまったく同じジオデータベースの状態を表します。Default バージョンと新しいバージョンにそれぞれ独自の変更が加えられる過程で、各バージョン間に差が生じていきます。
ジオデータベースには多くのバージョンを作成することができます。ArcGIS for Desktop からアクセスした [バージョン マネージャー] ダイアログ ボックスを次に示します。この例には、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 以外のバージョンにマージした場合は、ベース テーブル移行オプションを指定しない場合と同様に、変更は差分テーブルに残ります。
権限とバージョン編集
バージョンの所有者 (作成したユーザー) は、バージョンにアクセスできるユーザーを設定することができます。アクセス権限には、次のオプションがあります。
- プライベート: バージョンの所有者だけが該当するバージョンでデータセットの表示と編集を実行できます。
- プロテクト: どのユーザーも該当するバージョンでデータセットを表示できますが、編集できるのは所有者だけです。
- パブリック: データセットに対する権限が付与されている限り、どのユーザーもそのデータセットの表示と編集を実行できます。
バージョンのアクセス権はバージョンの作成時に設定されますが、[バージョン マネージャー] ダイアログ ボックスで変更することもできます。詳細については、「バージョンの作成と権限の設定」および「バージョンのプロパティ」をご参照ください。
編集を加える場合は、ArcMap から特定バージョンのジオデータベースに接続し、バージョン対応登録されているデータをマップに追加します。
デフォルトでは、ArcMap のすべての編集セッションがバージョン対応です。そのため、マップにバージョン対応登録されたデータがあれば、編集セッションを開始してすぐに編集を始めることができます。編集セッションを開始するには、[エディター] ツールバーの [エディター] ドロップダウン リストで [編集の開始] をクリックします。
各バージョンへの編集は、そのバージョンにのみ適用されます。例外はスキーマの変更です。バージョンのスキーマを変更すると (たとえば、テーブルに新しいフィールドを追加するなど)、その変更は他のすべてのバージョンに適用されます。データセットのスキーマを変更できるのは、データ所有者のみです。
編集が終了したら、上位バージョンに対して変更内容のリコンサイルとポストを実行します。
変更内容のリコンサイルとポスト
リコンサイルとポストを実行すると、作業中のバージョンの上位にあるバージョン (親バージョンや Default バージョンなど) に変更内容が統合されます。リコンサイルでは、編集中のバージョンにおける変更内容が、マージ先となるバージョンと比較されます。
バージョンのデータを変更する際に、データにロックは適用されません。2 人の編集ユーザーが同じバージョンまたは異なるバージョンで同じデータを編集すると、競合 (コンフリクト) が発生することがあります。競合が発生するのは、2 つの編集プロセスで同じ行に対して異なる編集が行われた場合です。リコンサイル プロセスでは、各競合が表示され、行のどちらの編集内容を採用するかを選択することができます。
一般的に編集の量は編集対象の地理データ全体に対してごくわずかとなるので、編集の競合が頻発することは多くはありません。正しく設計されたワークフローでは、トランザクション中にフィーチャをロックまたはチェックしなくても良いことを考えれば、競合をリコンサイルするコストはごくわずかと考えることができます。
リコンサイルが完了したら、変更内容をポストすることができます。これにより、変更内容が他のバージョンに適用されます。他のバージョンへポスト済みのバージョンがそれ以上必要なければ、削除することができます。あるいは、そのバージョンをさらに編集し、再びリコンサイルしてポストすることもできます。
バージョン: 例
バージョンを使用する方法を示すため、都市の水道を例に考えてみます。水道局には、水道管、バルブ、ポンプなどの水道システムのコンポーネントの現在の状態を表すフィーチャのジオデータベースがあります。水道局では、水道システムの水道管を新たに拡張する必要があります。
水道局は、Default バージョンから「Extension project」という名前の新しいバージョンを作成します。このバージョンには、水道管を拡張するための設計が含まれています。ただし、水道管を拡張するのに 16 インチと 24 インチのどちらの送水管を使用するかについては確定していません。そこで、Extension project バージョンから、16 インチの設計と 24 インチの設計を調査するための新しいバージョンを作成します。
最終的に、24 インチの水道管であれば今後 12 年間に予想される水道需要をまかなえることと、初期工事費用の点でもこちらのほうが有利であることが判明します。24 インチの設計が承認されると、設計の正確さが確認された上で、Extension project バージョンにポストされます。
それから数か月後、新しい水道管の拡張工事が完成すると、 データベースのマスター バージョンを更新するために、Extension project バージョンは、変更内容の正確さが確認された上で、リコンサイルされて Default バージョンにポストされます。
