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