3.2. 退避対象¶
3.2.1. 退避対象期間¶
退避対象の期間のうちの終了日が退避基準日より前である期間は、アクティブテーブルからバックアップテーブルへ移動します。（期間A）退避基準日が期間の途中の日付であれば、その期間（期間B）をバックアップテーブルへコピーし、終了日を退避基準日に変更します。アクティブテーブルの期間Bの開始日を退避基準日に変更します。分割した期間（期間X）は、同じ期間コードを持たないよう、バックアップされる側である期間の期間コードを変更します。バックアップされる期間の期間コード変更は、あるエンティティにおいて期間コードで必ず一意になるようにするためです。アクティブテーブルとバックアップテーブルを1つのテーブルと仮定しても別の期間であると識別可能です。アクティブ側に残る期間の期間コードは変更しません。
【図：退避期間】
アクティブテーブル／バックアップテーブルを結合して参照した場合でも、期間が重複せず一意であるという制約を満たすようになっています。このため、1つの期間上にある日付で再退避を実行した場合も、期間コードが重複しないよう変更済みなので再退避が可能です。
【図：退避期間（2回目の退避）】
3.2.2. 退避先テーブル¶
退避されるデータは、アクティブテーブルと同じスキーマ上にあるバックアップ専用のテーブルに移動します。「退避テーブルと実行クラス 」に一覧がありますので参照してください。コラム
退避先のテーブルは以下の条件を満たしている必要があります。
- 退避先のテーブルは、退避元のテーブルとカラムが一致している必要があります。
- カラムの型、サイズ、カラムの順番を含めてすべて一致している必要があります。
3.2.3. バックアップテーブルのレコードを参照する場合の注意¶
退避されたデータはAPIで取得することはできません。SQLを実行する必要があります。退避されたレコードは、マスタ画面／APIから変更されることはありません。退避実行時点でのデータがそのまま保持され続けます。以下の操作すべては反映されません。
- アクティブのエンティティの非期間化情報が更新された
- アクティブテーブルのエンティティが削除された
- アクティブのエンティティに国際化情報が追加された
退避された後に作成されるエンティティは、いちばん始めの日付が1900年ではなく新しいシステム開始日(最後に退避したときの基準日)になります。退避先テーブルで、最初の退避で退避されたものは1900年から始まります。最初の退避実行後に作成されたエンティティ（2000年で退避された場合）は、2000年がエンティティの最初の開始日となります。次に2010年で退避した場合、退避テーブルには1900年開始のエンティティと2000年開始の（1900～2000がない）エンティティが混在することになります。また、最初のバックアップ後にアクティブ側で削除された場合、そのエンティティは2000年までのデータしか存在せず、2度目のバックアップ期間の2000～2010年のデータはなくなった状態になります。コラム
退避テーブルでは、「必ず連続した、特定の日付で1つの期間を持つ」という前提は成り立ちません。また、すべての期間において、同じロケールの国際化情報を持つとは限りません。前回退避が実行された日から、次に実行された日までの間のみで上記制約が成り立ちます。※ ただし、特定日において2期間が存在することはありません。