TM は、以下の 「前提」 を導入しています。

　（1） entity に対して、意味論を適用して、以下の 2種類に類別する。
　　　（1）-1 event （その性質として、日付が帰属する。）
　　　（1）-2 resource （event 以外の entity である。）

　（2） 対照表は、resource のあいだで 「関係」 として生成する。
　　　　aRb 上、a および b が resource であれば、R を対照表として記述する。

　（3） 対照表は、「関係」 を示す 「構成表」 である。

　
　entity は、「合意」 概念を導入して意味論的に 「event と resource」 に 類別しています。したがって、この前提に立つかぎり、「F-真」 および 「L-真」 という 「真」 概念を導入しなくても良いのですが、そういう 「真」 概念を 導入しなければならなかった理由は、対照表の性質を判断するためです。

　対照表は 「構成表」 です。「構成表」 は、以下の 2つの性質を示します。

　　（1） 「過程」 としての構成 （-ing）
　　（2） 「結果」 としての構成 （-ed）

　（1） は行為・現象を示して──生起する現実的な事物を示して── 「event 的」 な 性質を帯びています。したがって、性質として、「日付」 を付与することができます。 悩ましい点は、構成表の 「すべて」 が、この性質を帯びるという点です。いっぽうで、（2） は、個体 （resource） の複合概念を示すことがあります。その典型的な現象を、「赤本」 （「データベース 設計論--Ｔ字形ER」） の最終 ページ で示しました。それは、以下の例です。

　　｛銀行 コード (R)、支店 コード (R)、支店名称、・・・｝.

　「赤本」 以前では──「黒本」 （「Ｔ字形 ER データベース 設計技法」） および 「論考」 （「論理 データベース 論考」） では──構成表に対して 「意味論上の解釈」 しか示していなかった。当然ながら、構成表を、「構文論上」、どのように解釈 すれば良いのかという点を示さなければならない。対照表 （構成表） は、以下の ように考えれば理解しやすい。

　　（1） 構成表は、構文論上、「resource」 の文法を適用する。
　　（2） 構成表は、意味論上、「event」 を言及する。

　（2） では、「赤本」 の最終 ページ に示したように、「resource 的」 な構成表が出るのですが、「反 コンピュータ 的断章」 （2月16日） で綴りましたが、 「resource 的」 な構成表を、「resource」 として判断するかどうかという 点は、TM の 「前提」 （実 データ および それらの セット 概念、第一階の述語論理） を 超えてしまいます。

　TM を作ったときに、この点が 私を悩ました点です。
　構成表の 「すべて」 を 「過程（-ing）」 として考えれば、構成表の 「すべて」 を 「event 的」として解釈することもできるし、構成表を 「結果（-ed）」 として 考えれば、「resource 的」 として解釈することもできるので、「日付」 が 明示 されている （あるいは、文脈のなかで、付与できる） 対象のみを 「event」 として 認知するという点で止めています。あるいは、逆に、構成表が 「組 オブジェクト」 として resource を示す性質が明示されていたら、「resource 的」 として認知することが できます。

　構成表は個体を 「言及 （refer to）」 しても 「指示 （designate）」 している訳じゃない。「合意」 概念を前提にすれば、もし、構成表のなかに 性質が記述されるのであれば──たとえば、「日付」 とか──、「意味」 を 示しますが、構成表として、性質が記述されていないとき──すなわち、 Ｔ字形表記として、右側が ブランク であるとき──、「event」 とも 「resource」 とも 解釈できるのです。

　赤本の最終 ページ で、「組 オブジェクト」 として、｛銀行 コード (R)、支店 コード (R)、支店名称・・・｝ の 構成表を示した理由は、「関係」 が、「resource」 的性質を示すこともある点を示すためです。

　ちなみに、「対照表-対-event」 の 「複数-対-１」 関係では、興味深いことに、 それらのあいだに、なんらかの 「event」 が入って、「event」 どうしの 「複数-対-１」 に消去されるようです。たとえば、典型的な例として、以下を考えてみます。

　[ 入荷 ] （event）
　｛入荷番号、商品番号 (R)、入荷日、入荷数、・・・｝.

　[ 入荷. 入庫. 対応表 ]
　｛入荷番号 (R)、入庫番号 (R)｝.

　[ 入庫 ] （event）
　｛入庫番号、倉庫番号 (R)、商品番号 (R)、入庫日、入庫数、・・・｝.

　[ 在庫 ] （対照表）
　｛倉庫番号 (R)、商品番号 (R)、記録日、在庫数、・・・｝.

　複数の 「入荷」 を一括して、「在庫」 にします。観てのとおり、「入荷」 と対照表 は、対応表を作成しないで、「入庫」 があいだに入って、入荷と入庫のあいだで対応表が作成 されます。その逆として、以下を考えてみます。

　[ 在庫 ] （対照表）
　｛倉庫番号 (R)、商品番号 (R)、記録日、在庫数、・・・｝.

　[ 出庫 ] （event）
　｛出庫番号、倉庫番号 (R)、商品番号 (R)、出庫日、出庫数、・・・｝.

　[ 出庫. 出荷. 対応表 ]
　｛出庫番号 (R)、出荷番号 (R)｝.

　[ 出荷 ] （event）
　｛出荷番号、商品番号 (R)、出荷日、出荷数、・・・｝.

　
　ほかの例として、「配属」 を前提にした 「研修」 を考えてみます。

　[ 配属 ]
　｛部門 コード (R)、従業員番号 (R)、配属日、・・・｝.

　[ 研修 ]
　｛研修番号、部門 コード (R)、従業員番号 (R)、研修実施日、・・・｝.

　配属日の相違する──つまり、複数の配属ということですが──複数の従業員 に対して、1つの研修を実施したとします。このときも、構成表 （対照表） の (R) が 「event」 に複写されるのみで 対応表はでない。

　逆を考えてみます。
　すなわち、いくつかの研修を終えてから配属するとします。

　[ 研修 ]
　｛研修番号、従業員番号 (R)、研修実施日、・・・｝.

　[ 配属 ]
　｛部門 コード (R)、従業員番号 (R)、配属日、・・・｝.

　このときも、対応表はでない。
　どの研修と どの研修を終えたら配属されたかは、あくまで、「研修」 event のなかで示される。もし、どの研修と どの研修を終えないと配属されないと いう ルール があるのならば、「研修」 event の 「再帰」 として記述されます。

　以上の点が対照表の 「構成表」 としての特徴なのです。
　すなわち、構成表は認知番号をもたないので、構成表のなかの (R) の いちぶ──基本的に、全部──が、後続 event （あるいは、先行 event）の (R) として作用するということです。