対照表と event の間には、順序対が成立することもあれば、成立しないこともある。
　というのは、対照表には、そもそも、以下の 2つがある。

　　（1） event の原形 [ DATE （取引日） が性質として帰属する ]
　　（2） validation-rule の真理値表 [ DATE （取引日） が性質として帰属しない ]

　対照表が （1） であれば、event との間には順序対が成立するが、（2） であれば、順序対は成立しない。

　例えば、以下の例を考える。

　　（1）顧客 entity がある。
　　　　（identifier は顧客番号とする。顧客は組立生産をしている製造会社とする。）
　　（2）商品 entity がある。
　　　　（identifier は商品番号とする。商品は、（顧客が組み立てる製品の） オプション 品とする。）
　　（3）「顧客. 製品. 対照表」 が成立している。
　　　　（商品は オプション 品なので、それぞれの顧客から受注される商品は顧客ごとにきまっている。）
　　（4） 受注 entity がある。
　　　　（identifier は受注番号とする。）

　以上の点を前提にして、顧客・商品・受注の間には、以下の関係が成立する。

　　　顧客　｛顧客番号、顧客名称,...｝[ R ]
　　　商品　｛商品番号、商品名称,...｝[ R ]
　　　顧客. 商品. 対照表　｛顧客番号 (R)、商品番号 (R)、...｝[ 対照表 ]
　　　受注　｛受注番号、顧客番号 (R)、商品番号 (R)、受注日、受注数、...｝[ E ]

　さて、ここで論点になるのは、「受注」 のなかに再利用された 「顧客番号 (R) と商品番号 (R)」 は、以下の 2つのいずれから得られるのか、という点である。

　　（1） それぞれの resource （顧客と商品） から、それぞれの identifier を入手する。
　　（2） 対照表から [ 顧客番号 (R) と商品番号 (R) を ] 一括して入手する。

　以上の 2つは、「実装形」 としたら、同じ形になるので、2つの違いに対して無頓着になる危険性が高いので注意されたい。

　この例で云えば、正解は （1） である。というのは、この例では、対照表が 「validation-rule」 として作用しているのであって--対照表の性質として、DATE （取引日） を想像することができないので--、対照表が event としては作用しない。

　逆に言えば、もし、（2） が成立するなら--対照表のなかに DATE （取引日） が帰属するのなら--、受注に対して先行関係にある event はなにか、という点を検証してもよい。

　以上をまとめれば、

　　（1） event として作用する対照表は、
　　　　後続の event に対して先行関係にあるので、対照表と event をむすぶのが正しい。

　　（2） validation-rule として作用する対照表は、
　　　　event として作用しないので、対照表と event をむすぶのは間違いである。