有効時間は実世界をモデル化し、行内のすべての情報で表現される事実が有効または真実である期間を示します。valid-time期間は、次に示すように、valid-time列に格納されます。valid-time列には、保険証書や契約が有効である期間、従業員の雇用期間など、時間を認識した手法での追跡や操作が重要になる情報を格納します。valid-time期間は、行の有効期間(PV)ともいいます。
valid-time列は、列定義にAS VALIDTIMEを指定して定義します。データ型は、要素型がDATE またはTIMESTAMP(n) (任意でWITH TIME ZONEを含む)のPERIODデータ型になります。新しい行をテーブルに挿入するときには、valid-time列の値を指定します。
変更または削除した行のvalid-time列は、その行の変更または削除に指定した期間と元のPVとの関係に応じて、Teradata Databaseが自動的に保守します。
たとえば、valid-timeテーブル内の行が2年間有効な契約条項を表現しているとします。その条項(行)を、契約期間中に変更する必要がある場合には、次に示すような保守が実行されます。
- その行のコピーが自動的に作成され、新しい条項を示すように変更されます。その行のPVは条項の変更時点から開始され、新しい条項がいつ開始されたかを示します。その行のPVは変更前のvalid-time列の終了境界値を維持するので、元の契約の終了期日がそのまま維持されます。
- 変更前の契約条項を格納している元の行は、履歴行としてマークされます。PVは変更時点で終了するように設定されます。これは、この時点で古い条項が無効になるためです。
このような変更では、その変更が行なわれた時点から行の情報が変更され、変更された情報は行のPVの残りの期間が終了するまで有効になります。
valid-time列を含むテーブルに対する変更は、過去の期間や将来の期間のように、現在の時刻と重ならない期間を指定した場合にも適用できます。この変更は、指定した期間と重なるPVを持つ行にのみ影響します。また、その変更が適用可能な期間のみ影響します。このテーブルに対する別の種類の変更では、行のPVの全期間に影響させることもできます。これは、非テンポラル テーブルに加えた変更と同様になります。
たとえば、前述の契約条項が2年間の契約期間中の6週間だけ変更されるとします。この変更によってテーブルには自動的に3つの行が生成されます。
- その行のコピーが自動的に作成され、新しい条項を示すように変更されます。その行のPVには、新しい条項が有効になる6週間が反映されます。
- 変更前の契約条項を格納している元の行は、履歴行としてマークされます。PVは、新しい条項が始まる時点で終了するように設定されます。
- 新しい行が挿入され、6 週間の条項の変更が終了した後、契約が元の条項に戻るときの条件を反映します。この新しい行のPVは、新しい条項の期限が満了した時点に開始され、変更前の行の元の終了期日に終了します。
このようにして、valid-timeテーブルでは変更のすべての履歴も自動的に保持されます。ただし、transaction-timeとは異なり、valid-timeを含むテーブルの履歴行は、テンポラルSQL問合わせやDMLでアクセスできる状態が保たれます。実世界をモデル化しているため、valid-timeテーブルには将来のPVが含まれることがあります。これは、契約や保険などが将来の日付になるまで開始または終了されないことがあるためです。
valid-time列は、行内の情報に期限が定められていて、時間を認識した手法で行の情報を保守、追跡および操作する必要のある場合に追加してください。有効時間列は、行の変更頻度が比較的少ない場合に最適です。POS (販売時点情報管理)テーブルなど、非常に頻繁に変更される属性を表現するには、valid-timeテーブルよりもイベント テーブルの方が適しています。イベント テーブルにはテンポラル セマンティクスを適用しません。