テーブルが契約を表わし、各行が既存契約の条項を示しているとします。契約期間中に契約条項が変更された場合、非テンポラル テーブルへの通常の更新では、新しい契約条項がテーブルに反映されることになります。ただし、役立つ可能性がある情報が失われます。変更する前は契約条項が異なっていたという事実です。Valid-timeテーブルでは、変更に特殊テンポラル構文を使用して、またこれらの変更による行の変更の特殊処理により、このような現実のモデルを作ることができます。
valid-timeテーブルへの変更は、system-timeテーブルへの変更よりもさらに柔軟です。データベースが自動でテンポラル帳簿処理を実行しますが、自動変更の性質は行の有効時間と、変更に指定した有効期間の関係により異なります。
valid-timeテーブルに対してUPDATEおよびDELETE変更を行なう場合は、オプションで変更を適用する期間を指定することができます。これは、変更の適用期間(PA)といいます。このコンテキストでは、行のvalid-time期間を、行の有効期間(PV)といいます。変更構文のPAは、SQLの追加修飾子として機能します。どの行が変更できるか、および変更により自動的に新規の行をテーブルに作成してデータベースが変更の時間で区切られた性質を反映することを許可するかどうかは、PAとPVの関係によって決定されます。
最も簡単なケースは、行のPV中のある特定の時点で有効となり、PVの残りの期間中に継続される変更です。契約条項の簡単な変更は、この一例です。これは、Teradata Databaseが変更の一時的な性質を保持する変更を扱う方法です。
- その行のコピーが自動的に作成され、新しい条項を示すように変更されます。新しい行のPVは条項の変更時点から開始され、新しい条項がいつ開始されたかを示します。行のPVはvalid-time列の元の終了境界を保持して元の契約終了日を保持します。これは、新しい条項が契約の残りの期間に有効となるためです。
- 変更前の契約条項を格納している元の行は、履歴行としてマークされます。古い行のvalid-timeの終了境界は、変更の時刻に設定されます。これは、その行にあった古い条項がその時点で無効になるためです。
valid-time次元を持つテーブルへの変更は、過去や将来の時間であっても、どの期間に対しても適用することができます。変更は、変更のPAと重なるPVを持つこれらの行にのみ、またPAとPVが一致する場合に限り影響します。
例えば、契約開始後に契約の変更が開始されて、契約の有効期限が切れる前に終了する場合など、変更のPAが行のPV内にある場合、変更の結果は3つの行となります。
- 最初の行には、元の情報と、変更が有効になるまで行の元のPVの開始からの時間をカバーするvalid-time期間が格納されます。
- 2つ目の行には、変更された情報と、変更文のPAと一致するvalid-time期間が格納されます。
- 3つ目の行には、元の行情報が保持されていますが、変更が有効でなくなったときに開始されるvalid-time期間が格納され、行の元のPVの終了時刻まで続きます。
このようにして、valid-timeテーブルでは変更のすべての履歴が自動的に保持されます。system-timeテーブルのクローズ行と異なり、valid-timeテーブルの履歴行は、すべてのSQL操作でアクセスできる状態のままとなります。実世界をモデル化しているため、valid-timeテーブルには将来のPVが含まれることがあります。これは、契約や保険などが将来の日付になるまで開始または終了されないことがあるためです。
PAを指定しない変更は、変更行の有効時間に影響することなく、非テンポラル テーブルで変更が行なうのと同様に動作します。それらは、行の有効時間に関係なく、問合わせ基準を満たすテーブルのすべての行に影響します。
ANSI valid-timeテーブルにおける行の変更の詳細については、ANSI Valid-Timeテーブルの行の変更を参照してください。