「DATE （取引日）」 を使えばよい。
　「event」 系の対照表は、「性質 （アトリビュート）」として、「DATE」 を帰属することができる。
　「性質」 として 「DATE」 を仮想することができる対照表は、「疑似 event （quasi-event）」 である。
　しかし、「validation-rule」 系の対照表は、「DATE （取引日）」 を仮想することができない。

　
▼ 具体例 [ 拙著 「論理 データベース 論考」 191ページ 参照。]

　
　以下の 2つの「resource」を使う。

　（1） 顧客 ｛顧客番号、名称,...｝.
　（2） 製品 ｛製品コード、名称,...｝.

　以上の 2つの 「resource」 を組とした--ただし、unordered な--以下の対照表を生成することができる。
　｛顧客番号 (R)、製品コード (R)｝.

　この対照表の 「性質 （アトリビュート）」 として 「DATE （取引日 ）」 を仮想すれば、「受注」 という 「event」 が成立する。
　　｛顧客番号 (R)、製品コード (R)、DATE （受注日）｝.

　したがって、この対照表は 「event」 系の対照表である

　次に、以下の 3つの 「entity」 （2つの 「resource」 と 1つの 「event」） を考えてみる。

　（1） 顧客 ｛顧客番号、名称,...｝.
　（2） 製品 ｛製品コード、名称,...｝.
　（3） 受注 ｛受注番号、 顧客番号 (R)、製品コード (R)、受注日、受注数｝

　「顧客」 と 「製品」 を組とした--ただし、unordered な--以下の対照表を生成することができる。
　｛顧客番号 (R)、製品コード (R)｝.

　この対照表の 「性質 （アトリビュート）」 として 「DATE （取引日）」 を仮想すれば、「受注」 という 「event」 が成立する。しかし、「受注」 は既に成立している。とすれば、この対照表の性質として 「DATE」 を仮想することができない。たとえば、顧客ごとに受注される製品が制約されているのなら、「顧客」 と 「製品」 の間には、コンビネーション （構成） が成立する。とすれば、その （対応関係の） 構成から外れた製品の受注があれば、accept してはいけない。この対応関係の validation は、アルゴリズム のなかで扱うこととされてきた。しかし、この対応関係を対照表の形として--つまり、データ 構造として--記述しておけば、アルゴリズム を記述しなくてもよい （対応関係の検証は、一回の I/O で済む）。

　ちなみに、アルゴリズム を記述するとしても、アルゴリズム のなかで、この対応関係の internal-table を用意しなければならない。とすれば、この対応関係を データ 構造として用意しておけば、プログラム の ステップ 数は少なくなるし 、プログラム の生産性は高くなる。

　この対照表は、（データ に帰属する ルール を記述した） 「真理値表」 として機能している。すなわち、3つの entity （顧客、製品、受注） という実 データ を コントロール する 「メタ・データ」 である。したがって、「メタ・データ」 は （述語論理の観点からすれば、） 「関数」 として扱うこととされている。いっぽう、データ指向 （Data-Oriented） の観点からすれば、データ に帰属する対応関係 （データ に帰属する ルール）は、そもそも、DD （Data Dictionary） が扱うべきなのであるが、現時点では、そういう対応関係の ルール を記述できる精巧な DD は マーケ ット にはない。

　とすれば、データ 間の対応関係を記述する 「メタ・データ」 は、実 データ といっしょに 「実装する」 ほうがよい。「event」 系の対照表は、（命題論理の観点からすれば） 「実装しなければならない」 （a must の） table であるが、「validation-rule」　系の対照表は、「実装してもいいし、実装しなくてもよい」 （実装しなければ、アルゴリズム のなかで扱うことになる）。ただ、実装したほうが、アルゴリズム の負荷が軽減される、ということである。