DB2 に格納されたジオデータベースのバージョン対応テーブル
エンタープライズ ジオデータベースは、大量の地理データを同時に作成および更新している多数のユーザをサポートする必要があります。したがって、ジオデータベースは、データのコピーを複数作成することなく、マルチユーザによる同時編集をサポートする編集環境を提供する必要があります。またこの編集環境では、一般的に数日にわたる編集セッション、データベースに対する変更を元に戻すまたはやり直す操作、マスタ データベースに影響を与えずにデータ モデルと代替アプリケーション設計案をテストおよび開発する機能、データとデータベースの時間による変化を監視する機能もサポートする必要があります。
これらの要件を満たすために、ArcSDE ジオデータベースはバージョニングを使用できます。まず、フィーチャ データセット、スタンドアロン フィーチャクラス、およびテーブルをバージョン対応登録します。続いて、編集を行うジオデータベースのバージョンを作成します。これらのバージョンは仮想的なもので、ジオデータベースの物理的なコピーは作成されません。バージョンは、バージョン対応の各データセットに関連付けられた差分テーブルと、バージョンのステートを管理するいくつかのシステム テーブルによって表されます。
バージョンの詳細については、「バージョニングの概要」をご参照ください。
ArcGIS Desktop のバージョン対応テーブル
[カタログ] ウィンドウでは、バージョン対応のデータセットはバージョン非対応のデータセットと同じように表示されます。フィーチャクラスまたはテーブルがバージョン対応かどうかは、[プロパティ] ダイアログ ボックスを開くことで確認できます。[一般] タブに、フィーチャクラスまたはテーブルがバージョン対応登録されているかどうかが示されています。
複数のジオデータベースのバージョンを作成できます。[カタログ] ウィンドウで、各バージョンに対して個別に空間データベース接続を作成することもできます。DEFAULT バージョンにあるバージョン対応データセットをプレビューする際に、同じフィーチャクラスを DEFAULT 以外のバージョンからプレビューした場合と表示が異なっていたり、含まれるレコードの数が違う場合があります（DEFAULT 以外のバージョンに空間データベース接続を作成する方法については、「特定のジオデータベース バージョンへの接続」をご参照ください）。
同様に、あるバージョンのバージョン対応フィーチャクラスを ArcMap で表示した後、別のバージョンの同じフィーチャクラスを表示すると、表示が異なる場合があります。これは、表示されるテーブルまたはフィーチャクラスに含まれる行の数が、バージョンごとに異なる場合があるためです。
ヒント: マップに表示されているデータのバージョンを確認するには、ArcMap のコンテンツ ウィンドウで [リソース別にリスト] ボタンをクリックします。
ジオデータベースのバージョンを（この例では、wo2557 に）切り替えると、消火栓フィーチャクラスには給水栓と給水管が 1 つ追加されています。これは、wo2557 をデータ ソースのジオデータベース バージョンとして編集に使用し、消火栓フィーチャクラスに給水栓が 1 つ、および給水管フィーチャクラスに給水管が 1 つ追加されたことを意味します。
この場合、各バージョンは独立したデータのコピーであるように見えますが、ジオデータベースは新しいコピーを作成したり元のデータを変更する代わりに、バージョン対応テーブルまたはフィーチャクラスを元のまま残し、データに対する変更をすべて別のジオデータベース システム テーブルに保存します。バージョンの変更を記録するジオデータベース テーブルは、差分テーブルと呼ばれます。バージョン対応登録されたテーブルまたはフィーチャクラスごとに、2 つの新しい差分テーブル（ADD テーブルと DELETE テーブル）が作成されます。
IBM DB2 データベースのバージョン対応テーブル
内部的に、多数のデータベース テーブル（データセット テーブル、差分テーブル、システム テーブル）によってバージョニングが管理され、各バージョンが追跡されます。
差分テーブル
フィーチャ データセット、スタンドアロン フィーチャクラス、またはテーブルをバージョン対応登録すると、データベースに差分テーブル（ADD テーブルと DELETE テーブル）が作成されます。差分テーブルには、データベースの各ステートでバージョン対応テーブルまたはフィーチャクラスに対して実行された挿入、更新、削除がすべて記録されます。
メモ: データセットをバージョン対応登録できるのは、データセットの所有者だけです。
a<registration_id>
a<registration_id> テーブル（ADD テーブル）は、バージョン対応のビジネス テーブルで挿入または更新されたレコード（フィーチャ）に関する情報を維持し、特定のデータベース ステートで追加または変更されたレコードを特定するために検索されます。ADD テーブルの名前に含まれている <registration_ID> は、TABLE_REGISTRY テーブルの REGISTRATION_ID フィールドの値です。この値はバージョン対応テーブルに対応します。消火栓の例では、TABLE_REGISTRY テーブルの消火栓フィーチャクラスの REGISTRATION_ID は 161 です。したがって、消火栓フィーチャクラスの ADD テーブルは a161 です。
ADD テーブルには、編集しているバージョン対応登録されたビジネス テーブルと同じすべてのフィールドに加えて、STATE_ID が含まれます。
|
フィールド名 |
フィールド タイプ |
説明 |
NULL？ |
|---|---|---|---|
|
<バージョン対応のビジネス テーブルにあるすべてのフィールド> |
<バージョン対応のビジネス テーブルのフィールドに対応するすべてのタイプ> |
新しいフィーチャのすべての属性 |
|
|
SDE_STATE_ID |
BIGINT |
新しいフィーチャが追加または更新されたステートの識別子 |
NOT NULL |
たとえば、バージョン対応の編集セッション中に消火栓フィーチャクラスに給水栓を追加すると、新しい給水栓のレコードが ADD テーブルに追加されます。
d<registration_id>
d<registration_id> テーブル（DELETE テーブル）は、バージョン対応のテーブルで削除または更新されたすべての行に関する情報を維持し、特定のステートで削除または変更された行を識別するために検索されます。行を削除する場合、レコードは物理的に削除されません。レコードには削除済みのフラグが設定され、以降のデータベース クエリで返されなくなります。
|
フィールド名 |
フィールド タイプ |
説明 |
NULL？ |
|---|---|---|---|
|
SDE_STATE_ID |
BIGINT |
フィーチャが削除される系統のステートの識別子 |
NOT NULL |
|
SDE_DELETES_ROW_ID |
INTEGER |
削除または更新されたフィーチャの一意の識別子 |
NOT NULL |
|
DELETED_AT |
BIGINT |
フィーチャが削除されているステート |
NOT NULL |
各データベース バージョンを正しく表すために、差分テーブルと VERSIONS および STATE_LINEAGES システム テーブルを検索して、どのような変更がどのデータベース ステートで行われたかが識別されます。続いて、バージョンはデータの元の状態とすべての変更を考慮したデータをシームレスに表示します。
システム テーブル
デルタ テーブルに加え、システム テーブルによりバージョン対応のテーブルと編集を管理します。これらには、STATES、STATE_LINEAGES、VERSIONS、MVTABLES_MODIFIED テーブルがあります。
一般的に、バージョン対応のデータベースには DEFAULT バージョンに加えて多数のバージョンが存在します。これらの追加バージョンは、作業指示、設計の代替案、ディスコネクト編集のセッション、履歴のスナップショットなどを表しています。VERSIONS テーブルには、一意の名前と ID で識別される各バージョンとともに、これらのバージョンの説明のリストが含まれます（ID は ArcSDE によって自動的に生成されます）。また、各バージョンには、所有者、説明、親バージョン、関連するデータベース ステート、およびユーザのアクセス レベルに関する情報があります。
VERSIONS テーブルが作成されるときに、DEFAULT バージョンの詳細が自動的にこのテーブルに記録されます。ArcSDE 管理者は DEFAULT バージョンの所有者に設定され、また対応するデータベース ステートの初期 ID が 0 に設定されます。次に、VERSIONS テーブルの DEFAULT エントリの例を示します。
|
名前 |
Owner |
Version_ID |
Status |
State_ID |
説明 |
Parent_name |
Parent_owner |
Parent_version_ID |
Creation_time |
|---|---|---|---|---|---|---|---|---|---|
|
DEFAULT |
SDE |
1 |
1 |
0 |
Instance default version |
NULL |
NULL |
NULL |
2009-02-12 08:40:26 |
データに対する編集を管理するために、バージョン対応ジオデータベースはデータベース ステートのコレクション（データベースに対する変更の単位）を維持します。ステートは、変更ごとのデータベースの不連続なスナップショットを表します。すべての編集操作は、新しいデータベース ステートを作成します（編集操作は、フィーチャおよび行に対して行われるタスク（追加、削除、変更）または一連のタスクです）。すべてのジオデータベースのバージョンは、これらのデータベース ステートのいずれかを参照し、時間とともに一連のステートを参照していきます。
すべてのジオデータベース ステートは同じスキーマを持ち、編集された各テーブルまたはフィーチャクラスを表す行の数だけが異なります。同じフィーチャが同じバージョンまたは別のバージョンで編集されるときに発生する競合を識別するために、バージョンのリコンサイル中にバージョンのステートの系統が比較され、差異または競合が検出されます。
ステートに関するすべての情報は、STATES テーブルで管理されます。各バージョンが参照するデータベース ステートを識別するために、VERSIONS および STATE_LINEAGES に対してクエリが実行されます。
ステートはツリー構造で管理され、ステートの系統によって親子関係を持ちます。各バージョンのステートの系統に関する情報は、STATE_LINEAGES テーブルで管理されます。このテーブルには、ステートの親子関係をたどるための複数のエントリのインデックスが格納され、すべてのバージョンのクエリで使用されます。
バージョンの正しいビューを返すために、ステート系統が検索され、そのバージョンに対して行われた各変更を記録したすべてのステートが識別されます。このステートのリストから、バージョンを正しく表したテーブル行を決定できます。ジオデータベースが編集され、時間とともにバージョンが変化するにつれ、ステート ツリーはより複雑になります。
STATES テーブルとともに、MVTABLES_MODIFIED テーブルは、データベースの各ステートで変更されたすべてのテーブルのリストを保持します。
あるステートでフィーチャクラスまたはテーブルが変更されると、常に MVTABLES_MODIFIED テーブルに新しいエントリが作成されます。2 つのバージョンをリコンサイルするとき、プロセスの最初のステップは、これらの 2 つのバージョンが参照するステート（現在の編集バージョンのステートと、ターゲット バージョンのステート）を識別することです。これらのステートから、これら 2 つのバージョンのステート系統をたどって追跡することで、共通の上位ステートが特定されます。続いて、MVTABLES_MODIFIED テーブルにクエリを実行して、共通の上位ステートとターゲット バージョンのステートの間で変更されたすべてのテーブルを識別します。変更されたテーブルのリストから、両方のステートの系統に共通なテーブルの 2 つ目のリストが生成されます。この 2 つ目のリストにある共通のテーブルのすべてに対して、バージョンの差分を検索する多数のクエリが実行されます（INSERT、UPDATE、DELETE、UPDATE_UPDATE、および UPDATE_DELETE）。
バージョン対応のフィーチャクラスに関連するテーブルは、次の図のようになります。
破線はテーブル間の暗黙的なリレーションシップを示しています。
ADD テーブルと DELETE テーブルの名前に含まれる数字は、TABLE_REGISTRY テーブルにあるビジネス テーブルの REGISTRATION_ID です。
XML ドキュメントでのバージョン対応テーブル
XML ドキュメントのエントリは、フィーチャクラスまたはテーブルをバージョン対応にするかどうかを指定します。エントリは versioned タグで囲みます。バージョン対応のフィーチャクラスまたはテーブルの場合、値は true です。
ヒント: versioned タグはフィーチャ データセットで設定されますが、必ずしもフィーチャ データセット内にあるフィーチャクラスのバージョン値を反映しません。フィーチャ データセット内のフィーチャクラスがバージョン対応登録されているかどうかを確認するには、個々のフィーチャクラスに対してクエリを実行します。
<Versioned>true</Versioned>