バージョン対応登録されたデータセットの履歴管理を有効にすると、そのデータセットの DEFAULT バージョンのデータを使用してアーカイブ クラスが作成されます。アーカイブ クラスは、gdb_from_date および gdb_to_date 属性を使用して、変更履歴が記録された時間を管理します。バージョン非対応のデータに対して履歴管理を有効にすると、クラスのベース テーブルに gdb_from_date および gdb_to_date フィールドが作成されます。
時間の表現
変更履歴が記録されたときの時間を ArcGIS がどのように記録するかを理解しておくことが重要です。履歴は、有効時間、トランザクション時間、または UTC (協定世界時) のいずれかで記録できます。有効時間は、現実の世界で変更が発生した瞬間であり、通常は変更を適用したユーザーによって記録されます。トランザクション時間は、イベントがデータベースに記録された時間です。トランザクション時間はシステムによって自動的に生成されます。UTC は、インターネット上で時計と時間を統制するために使用される一次標準です。
バージョン対応のデータの履歴管理の場合、ArcGIS は、DEFAULT バージョンに変更が保存された、またはポストされたときに、(現在のサーバー時間に基づく) トランザクション時間を使用して、データへの変更を記録します。トランザクション時間と現実の世界でイベントが発生した時間が同じであることはまれです。現実の世界で発生したイベントがデータベースに記録されるまでの間に、時間が経過するからです。たとえば、2006 年 5 月 14 日に土地区画が譲渡され、その変更が 2006 年 6 月 5 日にデータベースに記録された場合、 アーカイブ クラスではこの変更は 2006 年 6 月 5 日のトランザクション時間で発生した変更として記録されます。
編集が発生した場合、ArcGIS はトランザクションをアーカイブ クラスに記録します。有効時間とトランザクション時間の差は重要ではないように思えますが、履歴情報に対してクエリ操作を実行する場合にはその差を意識する必要があります。運用システムでは、バックログからの過去の事象に基づいてデータを編集したり更新することは決してめずらしくありませんが、このような編集によって有効時間とトランザクション時間の時差が生じることになります。
また、有効時間とトランザクション時間の差は、多くのユーザーや部署がデータベースを編集するマルチユーザー環境で履歴を記録する場合にも問題となります。変更が実行され、データベースに記録される順番は、現実の世界でそれらの変更が発生した順番と同じであるとは限りません。
バージョン非対応のデータの履歴管理では、時間を表すのに UTC が使用されます。データの変更は、編集セッション中に編集内容が保存されたときに記録されます。
バージョン非対応のデータに対する履歴管理の有効化
履歴管理を有効にすると、gdb_from_date および gdb_to_date 属性がベース テーブルに追加されます。すべての行の gdb_from_date 属性に、履歴管理を有効にした日時がタイムスタンプとして設定されます。すべての行の gdb_to_date 属性には、タイムスタンプとして 9999 年 12 月 31 日が設定されます。gdb_to_date 属性が 9999 年 12 月 31 日に設定されている場合は常に、そのオブジェクトの現在の状態を表します。編集内容を保存するとき、ジオデータベースは変更履歴を次のように管理します。
- 新しいフィーチャが作成され、gdb_from_date 属性には変更記録時のタイム スタンプが設定され、gdb_to_date 属性は 9999 年 12 月 31 日に設定されます。
- 編集セッションでフィーチャが更新されると、ベース テーブルの対応する行が更新され、その行の gdb_to_date 属性が 9999 年 12 月 31 日から変更記録時のタイム スタンプに更新されます。加えて、更新された行に対応する新規の行が追加され、この新しい行の gdb_from_date 属性が変更記録時のタイム スタンプに、gdb_to_date 属性が 9999 年 12 月 31 日に設定されます。
- 編集セッションでフィーチャが削除されると、ベース テーブルの対応する行が更新され、gdb_to_date 属性が変更記録時のタイム スタンプに設定されます。
バージョン対応のデータに対する履歴管理の有効化
履歴管理を有効にすると、特定のクラスの DEFAULT バージョンを表すすべての行が、アーカイブ クラスに同じタイム スタンプでコピーされます。すべての行の gdb_from_date 属性に、履歴管理を有効にした日時がタイムスタンプとして設定されます。すべての行の gdb_to_date 属性には、タイムスタンプとして 9999 年 12 月 31 日が設定されます。gdb_to_date 属性が 9999 年 12 月 31 日に設定されている場合は常に、DEFAULT バージョンにおいてそのオブジェクトの現在の状態を表します。DEFAULT バージョンに編集内容が保存またはポストされると、ジオデータベースは自動的に変更内容をアーカイブ クラスに保存します。これは、次の結果を返します。
- DEFAULT バージョンで作成されたフィーチャは、アーカイブ クラスにも新規の行として挿入されます。この行の gdb_from_date 属性は変更が記録されたときのタイム スタンプに設定され、gdb_to_date 属性は 9999 年 12 月 31 日に設定されます。
- DEFAULT バージョンでフィーチャが更新されると、アーカイブ クラスの対応する行が更新され、その行の gdb_to_date 属性が 9999 年 12 月 31 日から変更記録時のタイム スタンプに更新されます。加えて、更新された行に対応する新規の行が追加され、この新しい行の gdb_from_date 属性が変更記録時のタイム スタンプに、gdb_to_date 属性が 9999 年 12 月 31 日に設定されます。
- DEFAULT バージョンでフィーチャが削除されると、アーカイブ クラスの対応する行が更新され、gdb_to_date 属性が変更記録時のタイム スタンプに設定されます。
アーカイブ テーブルの更新は、単一のデータベース トランザクションで実行されます。トランザクションの過程でエラーが発生した場合には、アーカイブ処理全体がロールバックされるため、保存またはポスト処理は完了しないことになります。エラーを修正してから、保存またはポスト処理を再度実行する必要があります。
アーカイブ処理のたびに、DEFAULT バージョンの履歴マーカーがアーカイブ処理実行時の値に更新されます。これにより、履歴バージョンにおいて DEFAULT 履歴マーカーを選択して参照するアーカイブ クラスの状態が、トランザクション バージョンにおける DEFAULT バージョンの状態と常に等しくなります。
アーカイブ クラスへのアクセスは読み取り専用に限定されるため、バージョン対応登録されたクラスの特定のバージョンへのアクセスよりもデータベース リソースを消費しません。
アプリケーションの開発などにおいて、アーカイブ処理の瞬間を捕捉するイベントを取得する必要がある場合は、SDK の Iversionevents2 インターフェイスの OnarchiveUpdated イベントをご参照ください。
履歴バージョンでのクエリは、アーカイブ クラスで実行されます。
トランザクション バージョンでのクエリは、引き続き、ベース テーブルと差分テーブルで実行されます。
フィーチャの追加
次の図は、パーセル ファブリックの土地区画番号が 116 のフィーチャと該当する行を示しています。バージョン対応のデータの場合、この行はアーカイブ クラスに表示されます。バージョン非対応のデータの場合、この行は土地区画のベース テーブル内にあります。gdb_from_date 属性はフィーチャの作成日時を示しています。このフィーチャは履歴管理を有効にしてから変更されていないので、gdb_to_date 属性は 9999 年 12 月 31 日を示しています。
土地区画番号 117 のフィーチャが挿入されると、行が挿入され、gdb_from_date 属性がこのポスト処理のタイム スタンプで更新されます。このフィーチャはまだ更新または削除されていないので、新しい行の gdb_to_date 属性は 9999 年 12 月 31 日を示しています。
フィーチャの更新
フィーチャを更新すると、gdb_to_date 属性が変更記録時のタイム スタンプに設定され、フィーチャの現在の状態を示す新しい行がアーカイブ クラスに挿入されます。この新しい行の gdb_from_date 属性は変更記録時のタイムスタンプに設定されますが、現在の状態のフィーチャはまだ変更または削除されていないので、gdb_to_date 属性は 9999 年 12 月 31 日に設定されます。
次の図は、2 つの土地区画 (116 および 117) と、更新処理を実行する前の該当する gdb_from_date 属性と gdb_to_date 属性を示しています。
土地区画 117 の土地区画境界が拡張されると、gdb_to_date 属性が変更記録時のタイム スタンプで更新され、新しい行が作成されます。この新しい行の gdb_from_date 属性は、アーカイブ処理の日時に設定されます。
たとえば、更新 (7/12/2005 5:34:22 PM) 前の状態を検索すると、更新前に存在していた土地区画 117 が表示されます。7/9/2005 2:23:43 PM よりも前の状態を検索した場合、土地区画 117 はまだ作成されていないため、表示されません。更新 (7/14/2005 3:45:23 AM)後の状態を検索すると、土地区画境界が拡張された現在の土地区画 117 が表示されます。
フィーチャの削除
フィーチャを削除すると、gdb_to_date 属性がアーカイブ時のタイム スタンプで更新されます。次の図は、2 つの土地区画 (116 および 117) と該当する gdb_from_date 属性と gdb_to_date 属性を示しています。
土地区画 117 が削除されたので、gdb_to_date 属性が変更記録時のタイム スタンプで更新されます。
バージョン対応のデータに対する履歴管理の技術的な注意事項
次のシナリオでは、アーカイブ クラスに時間的なギャップが生じる可能性があります。
編集ユーザーが DEFAULT バージョンを直接編集し、編集セッションでオブジェクトを 1 つ削除します。
次に、編集ユーザーが編集を保存すると、アーカイブ クラスの gdb_to_date 属性がオブジェクトを削除したときのタイム スタンプで更新されます。
同じオブジェクトが子バージョンで更新され、DEFAULT バージョンに対してリコンサイルされ、競合が検出されます。
競合解決の過程で、編集ユーザーが行を更新された状態で競合を置換することにした場合、バージョンをポストしたときに DEFAULT バージョンで削除された行が復元されます。アーカイブ処理の過程でアーカイブ クラスに新しい行が挿入され、gdb_from_date 属性に変更記録時のタイム スタンプが、gdb_to_date 属性に 9999 年 12 月 31 日が設定されます。
したがって、ユーザーがデータセットの変更履歴を調べたとき、gdb_to_date 属性と gdb_from_date 属性の間に時間的ギャップが発生し、オブジェクトが DEFAULT バージョンが存在しなかった期間が含まれることになります。