SQL を使用したバージョン対応データの編集の概要
SQL クライアントからバージョン対応データを編集するには、ベース（ビジネス）テーブル自体ではなく、データのバージョン対応ビューを編集する必要があります。バージョン対応登録されたテーブルは変更内容を記録するために、ADD テーブルと DELETE テーブル（まとめて差分テーブルと呼びます）という 2 つの関連テーブルを使用します。テーブルのバージョン対応ビューを編集するとき、編集データは ADD テーブルと DELTE テーブルに書き込まれます。ベース テーブルを直接編集すると、この書き込み処理が行われないため、レコードが孤立したりデータが損失したりする可能性があります。
バージョン対応ビューに対して SQL データ操作ステートメントを実行する場合、それぞれの種類のステートメントについて、データベースで次の処理が発生します。*
- 挿入: 基のベース テーブルの ADD テーブルに行が追加され、新しい行の object ID 値が自動的に生成されます。
- 更新: 更新は、実際には、元の行を削除して、新しい情報を持つ新しい行を追加します。そのため、UPDATE ステートメントを実行すると、基のベース テーブルの ADD テーブルと DELETE テーブルの両方に行が追加されます。
- 削除: 基のベース テーブルの差分テーブルに行が追加されます。
* 状態 0 を指している DEFAULT バージョンを編集している場合、すべての編集データはただちにベース テーブルに移動します。
SQL による編集の場合、内部でバージョンのリコンサイルは実行されないので注意してください。そのため、編集を終了したら、ArcGIS for Desktop または Python スクリプトを使用して、編集データを親バージョンとリコンサイルする必要があります。
編集モデル
新しい名前付きジオデータベース バージョンを作成してそのバージョンを編集したり、DEFAULT バージョンを直接編集したりできます。どちらを行うかは、サイトの要件に依存します。優れたパフォーマンスとスケーラビリティを実現するには、名前付きバージョンまたは DEFAULT バージョンのどちらを編集するか、適切なモデルを選択することが重要となります。
名前付きバージョンの編集
サイトが次に当てはまる場合、名前付きバージョンを作成し、SQL を使用してバージョン対応ビューで編集します。
- 複数の編集者が同じデータを変更しなくてはならない場合。
- 明確に定義された品質管理プロセスが必要な場合。
- 他のユーザが変更内容をすぐに利用できなくても構わない場合。変更内容をリコンサイルおよびポストするまでは、個別に作業できる場合。
- Oracle または SQL Server データベースで、編集するバージョン対応フィーチャクラスが SDEBINARY または OGCWKB ジオメトリ格納を使用している場合。
- 編集するバージョン対応のフィーチャクラスまたはテーブルが、編集データをベースに移動するオプションを選択した状態でバージョン対応登録されている場合。
バージョン対応ビューで編集するとき、編集データは ADD テーブルおよび DELETE テーブルに記録されます。編集データは、名前付きバージョンが参照する現在の状態に書き込まれます。
以下に名前付きバージョンのデータを編集する場合の手順を示します。記載どおりの順序で行ってください。
- バージョン対応テーブルまたはフィーチャクラスのバージョン対応ビューが存在しない場合は作成します。
- 編集作業用のジオデータベース バージョンを作成します。
- set_current_version プロシージャを使用して、新しいバージョンにアクセスすることを指定します。指定すると、編集セッションが名前付きバージョンが指している状態に設定され、このバージョンがロックされます。
- edit_version プロシージャまたはデータベースに適した関数を実行して、編集セッションを開始します。
- SQL を使用してバージョン対応ビューに対して編集を実行します。
- データベースの編集をコミットまたはロール バックします。
- edit_version プロシージャまたはデータベースに適した関数を実行して、編集セッションを終了します。
- ArcGIS で編集内容をリコンサイルしてポストします。
- ArcGIS を使用して親バージョンにすべての変更をポストしたら、バージョン対応ビューでの編集用に作成したバージョンは削除できます。
DEFAULT バージョンの編集
サイトが次の 1 つ以上に当てはまる場合、SQL を使用してバージョン対応ビューで DEFAULT バージョンを編集できます。
- 編集データがショート トランザクションの場合。
- バージョン対応ビューで行われた編集データを他のユーザがただちに利用できるようにする必要がサイトにある場合。
- フィーチャクラスの編集時に、フィーチャクラスが SDEBINARY または OGCWKB ジオメトリ格納ではなく、SQL 空間タイプを使用する場合。
- 編集するテーブルまたはフィーチャクラスが、編集データをベースに移動するオプションを選択した状態でバージョン対応登録されていない場合。
DEFAULT バージョンを編集するときは、名前付きバージョンと同様に、編集データは差分テーブルに記録されます。ただし、DEFAULT バージョンを編集する場合は、DEFAULT バージョンを参照しているすべてのユーザが編集データを確認することができます。
挿入、更新、削除の各処理は、DEFAULT バージョンが参照している現在の状態に書き込まれます。DEFAULT が状態 0 を参照している場合、各編集データはバージョン対応テーブルまたはフィーチャクラスのベース テーブルに直接適用されます。別のユーザが DEFAULT バージョンを編集している場合は、バージョンが新しい状態を参照するように更新されます。これが DEFAULT バージョンに複数の編集を加えたトランザクションの途中で発生した場合、最後にコミットした DEFAULT バージョンの状態に編集データが書き込まれます。
編集データがコミットされたら、以下はただちにデータにアクセスできるようになります。
- バージョン対応テーブルおよび DEFAULT バージョンを操作しているユーザまたはアプリケーション
- DEFAULT バージョンの現在の状態を含むステート系統を持つ子バージョンを操作しているユーザまたはアプリケーション
詳細:バージョン対応ビューを使用して DEFAULT バージョン内で変更されている行が、DEFAULT バージョンの現在の状態に依存する状態の別のバージョンで変更された場合、バージョン対応ビューは新しいジオデータベースの状態を作成し、新しい状態を参照するように DEFAULT バージョンを更新してから、編集を実行します。これは、編集中の行（DEFAULT バージョンの状態に依存する状態でも変更されています）が、圧縮操作や下位状態のバージョンが DEFAULT バージョンでリコンサイルされるときに上書きされないようにするために必要です。
バージョン対応ビューで DEFAULT ジオデータベース バージョンのデータを編集する場合は、バージョンを設定したり、編集セッションを開始したりしないでください。実行手順は次のとおりです。
- バージョン対応テーブルまたはフィーチャクラスのバージョン対応ビューが存在しない場合は作成します。
注意:バージョン対応ビューが ArcGIS 10.1 より前に作成された場合、再作成する必要があります。古いバージョン対応ビューを DEFAULT バージョンで編集することはできません。
- SQL を使用してバージョン対応ビューに対して編集を実行します。自動的に、DEFAULT バージョンの現在の状態を編集することになります。
- データベースの編集をコミットまたはロール バックします。トランザクションが開いているとき、差分テーブルには排他ロックがかかっているため、各編集の後にコミットまたはロール バックすることをお勧めします。ロックは、トランザクションが終了するまで解除されません。