アプリケーションによっては、時間経過に伴って情報が変化するデータベースの設計や構築が必要になる場合があります。これはテンポラル テーブル サポートなしでも実現できますが、複雑なものになります。
次に示すように定義されたPolicyテーブル(ここでは保険契約のPolicyテーブル)を使用する、保険会社のアプリケーションについて考えてみます。
CREATE TABLE Policy( Policy_ID INTEGER, Customer_ID INTEGER, Policy_Type CHAR(2), Policy_Details CHAR(40) ) UNIQUE PRIMARY INDEX(Policy_ID);
このアプリケーションでは、Policyテーブルの行が有効になる時期を記録する必要があるとします。テンポラル テーブル サポートがない場合には、アプリケーションでの対処法として、PolicyテーブルにStart_DateというDATE型の列を追加する方法が考えられます。このアプリケーションでは、Policyテーブルの行が有効でなくなった時期も特定する必要があるとします。これを実現できるのは、End_Dateという別のDATE型の列です。
このテーブルの新しい定義は、次のようになります。
CREATE TABLE Policy( Policy_ID INTEGER, Customer_ID INTEGER, Policy_Type CHAR(2), Policy_Details CHAR(40) Start_Date DATE, End_Date DATE ) UNIQUE PRIMARY INDEX(Policy_ID);
この時点で、面倒な問題がいくつか表面化します。例えば、ある顧客が保険契約の有効期間中にその保険契約を変更すると、新しい保険契約の条件を格納する新しい行の作成が必要になります。その保険契約の条件は、保険契約が変更された時点から保険契約が終了するまで有効になります。ただし、変更前の保険契約の条件も、履歴を残すために重要になります。元の行は保険契約の開始時点で有効だった条件を表わしますが、保険契約の条件がいつ変更されたかを反映するためにEND_DATEを更新する必要があります。
さらに、この種の変更によって複数の行が同じPolicy_IDの値を保持することになり、このテーブルのプライマリ インデックスに変更が必要になります。こうなると、このテーブルにどのような変更を加えるにしても、Start_Date列とEnd_Date列の変更について考慮しなければならなくなります。問合わせは、さらに複雑なものになるでしょう。
テーブル内にDATE型の列が存在していても、それだけでテーブルがテンポラル テーブルになることも、データベースがテンポラル データベースになることもありません。テンポラル データベースでは、企業が管理する情報の時間依存性を記録する必要があります。
Vantageでは、従来のテーブルにDATE型の列を追加するような方法とは異なる、時間依存のテーブルの効率的な作成、問合わせ、変更をビルトインでサポートします。