履歴管理プロセス

バージョン対応登録されたデータセットの履歴管理を有効にすると、そのデータセットの DEFAULT バージョンのデータを使用してアーカイブ クラスが作成されます。アーカイブ クラスは、gdb_from_date および gdb_to_date 属性を使用して、変更履歴が記録された時間を管理します。

時間の表現

変更履歴が記録されたときの時間を ArcGIS がどのように記録するかを理解しておくことが重要です。一般的にシステムの変更履歴は有効時間またはトランザクション時間のどちらかで記録することができます。有効時間は、現実の世界で変更が発生した瞬間であり、通常は変更を適用したユーザによって記録されます。トランザクション時間は、イベントがデータベースに記録された時間です。トランザクション時間はシステムによって自動的に生成されます。

ArcGIS は、DEFAULT バージョンに変更が保存された、またはポストされたときに、(現在のサーバ時間に基づく)トランザクション時間を使用して、データへの変更を記録します。トランザクション時間と現実の世界でイベントが発生した時間が同じであることはまれです。現実の世界で発生したイベントがデータベースに記録されるまでの間に、時間が経過するからです。たとえば、2006 年 5 月 14 日に土地区画が譲渡され、その変更が 2006 年 6 月 5 日にデータベースに記録された場合、アーカイブ クラスではこの変更は 2006 年 6 月 5 日のトランザクション時間で発生した変更として記録されます。

編集が発生した場合、ArcGIS はトランザクションをアーカイブ クラスに記録します。有効時間とトランザクション時間の差は重要ではないように思えますが、履歴情報に対してクエリ操作を実行する場合にはその差を意識する必要があります。プロダクション システムでは、バックログからの過去の事象に基づいてデータを編集したり更新することは決してめずらしくありませんが、このような編集によって有効時間とトランザクション時間の時差が生じることになります。

また、有効時間とトランザクション時間の差は、多くのユーザや部署がデータベースを編集するマルチユーザ環境で履歴を記録する場合にも問題となります。変更が実行され、データベースに記録される順番は、現実の世界でそれらの変更が発生した順番と同じであるとは限りません。

履歴管理の有効化

履歴管理を有効にすると、特定のクラスの DEFAULT バージョンを表すすべての行が、アーカイブ クラスに同じタイムスタンプでコピーされます。すべての行の gdb_from_date 属性に、履歴管理を有効にした日時がタイムスタンプとして設定されます。すべての行の gdb_to_date 属性には、タイムスタンプとして 9999 年 12 月 31 日が設定されます。gdb_to_date 属性が 9999 年 12 月 31 日に設定されている場合は常に、DEFAULT バージョンにおいてそのオブジェクトの現在の状態を表します。DEFAULT バージョンに編集内容が保存またはポストされると、ジオデータベースは自動的に変更内容をアーカイブ クラスに保存します。これは次を意味します。

アーカイブ テーブルの更新は、単一のデータベース トランザクションで実行されます。トランザクションの過程でエラーが発生した場合には、アーカイブ処理全体がロールバックされるため、保存またはポスト処理は完了しないことになります。エラーを修正してから、保存またはポスト処理を再度実行する必要があります。

アーカイブ処理のたびに、DEFAULTバージョンの履歴マーカーがアーカイブ処理実行時の値に更新されます。これにより、履歴バージョンにおいて DEFAULT 履歴マーカーを選択して参照するアーカイブ クラスの状態が、トランザクション バージョンにおける DEFAULT バージョンの状態と常に等しくなります。

アーカイブ クラスへのアクセスは読み取り専用に限定されるため、バージョン対応登録されたクラスの特定のバージョンへのアクセスよりもデータベース リソースを消費しません。

アプリケーションの開発などにおいて、アーカイブ処理の瞬間を捕捉するイベントを取得する必要がある場合は、SDK の Iversionevents2 インタフェースの OnarchiveUpdated イベントを参照してください。

履歴バージョンでのクエリは、アーカイブ クラスで実行されます。

アーカイブ テーブル
アーカイブ テーブル

トランザクション バージョンでのクエリは、引き続き、ベース テーブルと差分テーブルで実行されます。

ベース テーブル、ADD テーブル、DELETE テーブル
ベース テーブル、ADD テーブル、DELETE テーブル

フィーチャの追加

次の図は、地籍データベースの土地区画番号が 116 のフィーチャと、アーカイブ クラスの該当する行を示しています。gdb_from_date 属性はフィーチャの作成日時を示しています。このフィーチャは履歴管理を有効にしてから変更されていないので、gdb_to_date 属性は 9999 年 12 月 31 日を示しています。

フィーチャの追加

土地区画番号 117 のフィーチャが挿入され、編集内容が DEFAULT バージョンにポストされると、アーカイブ クラスに行が挿入され、gdb_from_date 属性がこのポスト処理のタイムスタンプに設定されます。このフィーチャはまだ更新または削除されていないので、新しい行の gdb_to_date 属性は 9999 年 12 月 31 日を示しています。

フィーチャ 2 の追加

フィーチャの更新

フィーチャを更新すると、gdb_to_date 属性が変更記録時のタイムスタンプに設定され、フィーチャの現在の状態を示す新しい行がアーカイブ クラスに挿入されます。この新しい行の gdb_from_date 属性は変更記録時のタイムスタンプに設定されますが、現在の状態のフィーチャはまだ変更または削除されていないので、gdb_to_date 属性は 9999 年 12 月 31 日に設定されます。

次の図は、2 つの土地区画(116 および 117)と、更新処理を実行する前の、アーカイブ クラスの該当する gdb_from_date 属性と gdb_to_date 属性を示しています。

フィーチャの更新

土地区画 117 の土地区画境界が拡張され、これらの編集内容が DEFAULT バージョンにポストされると、gdb_to_date 属性がアーカイブ時のタイムスタンプで更新され、新しい行が作成されます。この新しい行の gdb_from_date 属性は、アーカイブ処理の日時に設定されます。

フィーチャ 2 の更新

たとえば、更新(7/14/2005 5:34:22 PM)前の状態を検索すると、更新前に存在していた土地区画 117 が表示されます。7/9/2005 2:33:43 PM よりも前の状態を検索した場合、土地区画 117 はまだ作成されていないため、表示されません。更新(7/14/2005 3:45:23 AM)後の状態を検索すると、土地区画境界が拡張された現在の土地区画 117 が表示されます。

アーカイブ クラスの検索の詳細

フィーチャの削除

フィーチャを削除すると、gdb_to_date 属性がアーカイブ時のタイムスタンプで更新されます。次の図は、2 つの土地区画(116 および 117)と、アーカイブ クラスの該当する gdb_from_date 属性と gdb_to_date 属性を示しています。

フィーチャの削除

土地区画 117 を削除し、これらの編集内容を DEFAULT バージョンにポストすると、gdb_to_date 属性が変更記録時のタイムスタンプで更新されます。

フィーチャ 2 の削除

履歴管理の技術的な注意事項

次のシナリオでは、アーカイブ クラスに時間的なギャップが生じる可能性があります。

編集ユーザが DEFAULT バージョンを直接編集し、編集セッションでオブジェクトを 1 つ削除します。

次に、編集ユーザが編集を保存すると、アーカイブ クラスの gdb_to_date 属性がオブジェクトを削除したときのタイムスタンプで更新されます。

同じオブジェクトが子バージョンで更新され、DEFAULT バージョンに対してリコンサイルされ、競合が検出されます。

競合解決の過程で、編集ユーザが行を更新された状態で競合を置換することにした場合、バージョンをポストしたときに DEFAULT バージョンで削除された行が復元されます。アーカイブ処理の過程でアーカイブ クラスに新しい行が挿入され、gdb_from_date 属性に変更記録時のタイムスタンプが、gdb_to_date 属性に 9999 年 12 月 31 日が設定されます。

したがって、ユーザがデータセットの変更履歴を調べたとき、gdb_to_date 属性と gdb_from_date 属性の間に時間的ギャップが発生し、オブジェクトが DEFAULT バージョンが存在しなかった期間が含まれることになります。

関連項目


3/6/2012