バージョニング用語

バージョニングのドキュメントに頻出する用語を、以下に説明します。

用語	説明
ADD テーブル	トラディショナル バージョン対応データセットの場合、ADD テーブルはデータセットに挿入または更新されたレコードをすべて格納します。このテーブルは差分テーブルの 1 つです。 ADD テーブルは、A テーブルとも呼ばれています。
ベース テーブル	ベース テーブルは、フィーチャクラスの核となるテーブルです。ベース テーブルには、すべての非空間属性が格納されます。SQL ジオメトリ タイプを使用している場合、空間属性も格納されます。 ベース テーブルという用語は、SDEBINARY ジオメトリ格納タイプによって使用される他の補助テーブル (差分テーブル、アーカイブ クラス、F テーブル、S テーブル) と、この核となるテーブルとを区別するために使用されます。 データベース管理システムのユーザー インターフェイスを介してフィーチャクラスを確認すると、対応するベース テーブルが存在することが確認できます。たとえば、prj_sites という名前のバージョン対応フィーチャクラスがジオデータベース内に存在している場合、データベース内に prj_sites という名前のテーブルが存在します。このテーブルがベース テーブルです。 ベース テーブルは、ビジネス テーブルとも呼ばれます。
ブランチ バージョニング	ブランチ バージョニングは、フィーチャ サービスを使用する場合に簡単にロング トランザクションを処理するために使用されるジオデータベース バージョニングのタイプです。
子バージョン	子バージョンとは、別バージョンから生成されたジオデータベース バージョンです。この別バージョンが親バージョンになります。子バージョンは最初に作成された時点で親バージョンと同じデータを含みます。子バージョンで行われた編集内容は通常、親バージョンにマージされます。
圧縮	圧縮処理はトラディショナル バージョニングを使用するデータセットに対してジオデータベースで実行されます。その主な目的は、参照されなくなったステートとそれに関連する差分テーブルの行を削除し、すべてのバージョンに共通する差分テーブル内のエントリをベース テーブルに移すことです。これにより、各バージョン クエリに応じてデータベースが検索するデータ量が削減され、クエリのパフォーマンスが向上するとともに、システムの応答時間が短縮されます。 頻繁に編集されるトラディショナル バージョンを使用するジオデータベースは、頻繁に (編集量に応じて、毎日または毎週) 圧縮する必要があります。圧縮操作の間隔が長くなるほど、圧縮操作が完了するまでの所要時間も長くなります。
DEFAULT バージョン	デフォルト バージョンは、ジオデータベースの元のバージョンです。他のジオデータベース バージョンはすべて、デフォルト バージョンから派生して作成されます。
DELETE テーブル	トラディショナル バージョン対応データセットの場合、DELETE テーブルはデータセットで行われたすべての削除を記録します。また、更新されたレコードの記録も格納されます。これは、更新で行われる処理は、以前に存在していたレコードをいったん削除して、変更されたレコードを追加し直す処理と同じであるためです。DELETE テーブルは差分テーブルの 1 つです。 DELETE テーブルは、D テーブルとも呼ばれています。
差分テーブル	トラディショナル バージョン対応データセットでは、ADD テーブルと DELETE テーブルは、データセットに加えられた変更内容 (差分) が格納されることから、差分テーブルと総称されています。
編集バージョン	編集バージョンは、現在更新中の子バージョンです。 リコンサイル処理中に、編集バージョンはターゲット バージョンと比較され、両者間の競合が検索されます。
ジオデータベース バージョン	ジオデータベース バージョンは、ジオデータベース全体のスナップショットを表します。編集セッションが長時間にわたって継続した場合でも、ジオデータベースに加えた編集内容を独立させることにより、ロック競合を防ぐことができます。 バージョンは既存のバージョンから作成されます。この結果、親バージョンと子バージョンの系統が生成されます。
ベース テーブル移行オプション	トラディショナル バージョニングの場合、これは、データをバージョン対応登録する際に使用可能なオプションです。ベース テーブル移行オプションを使用すると、ジオデータベースの DEFAULT バージョンに加えられた編集内容は、差分テーブルからベース テーブルに直ちに移行されます。 ベース テーブル移行オプションは、次の場合に役立ちます。 編集の実行時間が数分である。 データがネットワークやトポロジに属していない。 従来のバージョニングを使用するジオデータベースへのアクセスに、サードパーティのアプリケーションを使用している。
名前付きバージョン	ユーザーが作成したバージョンを指すため使用される語。ブランチ バージョニングでは、この語は、デフォルト バージョンから作成されたバージョンを意味します。
親バージョン	親バージョンとは、別バージョンの生成元となったジオデータベース バージョンです。この別バージョン (子バージョン) がまだ存在する間は、親バージョンを削除することができません。
ポスト	ポスト プロセスでは、変更内容を編集バージョンからターゲット バージョンにマージします。
リコンサイル	リコンサイル処理は、編集バージョンとターゲット バージョンを比較して、両者間の競合を検索します。競合が発生するのは、別のユーザーがターゲット バージョンに加えた編集内容と自分の編集内容とで不整合があった場合です。 競合を定義するルール (行に加えた変更、または列に加えた変更のどちらを競合とするか)、競合解決のデフォルト動作 (編集バージョンまたはターゲット バージョンのどちらの変更内容を優先するか) を設定することができます。 リコンサイルによって更新されるのは編集バージョンだけであるため、ArcGIS で競合がないかをチェックすることは可能ですが、変更内容はターゲット バージョンにマージされません。ポスト処理を通じてターゲット バージョンとマージするには事前に、リコンサイル処理中に検出された競合を確認し、解決する必要があります。
バージョン対応登録	フィーチャクラスをバージョン対応登録すると、データセットに加えられた編集の追跡に使用される追加テーブルが作成され、他のユーザーがデータセットにアクセスまたは編集することをブロックすることなく、データセットを編集することができます。 データセットをバージョン対応登録するときにジオデータベース接続プロパティでバージョニング タイプが [トラディショナル] に設定されている場合、そのデータセットをバージョン対応登録 (デフォルト オプション) またはベース テーブル移行オプションのバージョン対応登録することができます。 データセットをバージョン対応登録するときにジオデータベース接続プロパティでバージョニング タイプが [ブランチ] に設定されている場合、そのデータセットは自動的にブランチ バージョン対応登録されます。
ステート	トラディショナル バージョニングでは、ジオデータベースのステートは、バージョンに加えられた変更内容の記録です。バージョン内のフィーチャを編集するたびに、新しいステートが作成されます。
ステート系統またはステート ツリー	トラディショナル バージョニングでは、ステート系統またはステートツリーは、開始ステートで始まり現行ステートで終わる一連のステート群です。これはジオデータベースに加えられた一連の変更内容を表します。ツリー内または系統内の各ブランチによって、バージョンがどのように展開したかが記録されます。 トラディショナル バージョンを検索または表示すると、ArcGIS はバージョンの系統を検索して、その系統に属しているステート ID を取得し、ADD テーブルと DELETE テーブルから適切なレコードを取り出します。
ターゲット バージョン	ターゲット バージョンは、編集内容をリコンサイルする親バージョンです。
トラディショナル バージョニング	フィーチャ サービスでロング トランザクションを操作していないが、バージョンが提供するマルチユーザー編集、ロング トランザクション、ワークフローのメリットが必要な場合、トラディショナル バージョニング を使用できます。
バージョン管理者	特定のポータル ユーザーは、フィーチャ サービスのためのブランチ バージョンを操作する、より高い権限を持ちます。これらのユーザーは、バージョンの所有者やアクセス権限にかかわらず、フィーチャ サービス用のバージョンを表示、編集、および管理することができます。 詳細については、「バージョン管理者」をご参照ください。
バージョン ツリー	バージョン ツリーとは、関連のあるジオデータベース バージョン同士の組織図のことを言います。バージョン ツリーは家系図と同様、バージョン間の関連付け (親バージョンと子バージョンの対応関係) を示します。バージョン ツリーを使用すれば、特定の子バージョンの祖先を DEFAULT バージョンまでさかのぼって追跡できます。