ただし、意味論を導入する際、データ 構造を記述する エンジニア の個人的な価値観を排除したかったので、小生が導入した技術が 「推論 ルール」 であった。そして、命題論理の主選言標準形を推論 ルール の基本形とした。
　主選言標準形は、以下の形である。

　　　（ｐ∧ｑ）∨（ｐ∧¬ｑ）∨（¬ｐ∧ｑ）∨（¬ｐ∧¬ｑ）.

　関係の論理 （aRb）では、a および b は 「個体」 であり、R は関係である。つまり、a および b は entity である。
　Ｔ字形 ER手法では、entity を以下のように定義している。

　　「identifier （認知番号） が付与されていること」

　そのために、関係の論理 （aRb） を、事象のなかで使われている データ に適用する際、R （関係） が 個体 （entity） として成立することがある。たとえば、受注は、顧客と商品との間に成立する関係である--つまり、aRb において、a および b が顧客および商品であり、R が受注である。しかし、Ｔ字形 ER手法では、たとえば、受注は、受注伝票を使って記述されていれば--受注番号という認知番号が付与されているので--、定義により、entity として成立する。

　そこで、推論 ルール の基本形として、aRb において、a および b を 「entity」 として考え、R を対照表として記述することにした。たとえば、従業員と部門との間には、「従業員. 部門. 対照表」 が成立する、という ルール にした。すなわち、命題論理を前提にして、a および b を 「単文」 として考え、対照表を 「複文 （真理値表）」 （ｐ∧ｑ） として考えた。

[ 参考 ]
　Ｔ字形 ER手法の原型を思いついたとき、aRb において、a および b が、「event」 であれ 「resource」 であれ、すべての 2項関係では、対照表を生成することを考えていた。つまり、「resource」 と 「event」 を結んでも、対照表を生成することを考えていた。

　
　そして、「event」 は、本来、2つの 「resource」 の間に成立する関係であるが、Ｔ字形 ER手法では、定義により、entity として扱われるので、entity ではあるが、R （対照表） の性質を継承するとした。すなわち、対照表のなかで、認知番号を付与された モノ を 「event」 とする。「event」 は、時系列のなかで、並ぶという性質がある。

　以上の考えを 「公理」 として、以下の 3つの推論 ルール を定式化した。
　（1） 「resource」 と 「resource」 を結んだら、対照表を生成する。
　（2） 「resource」 と 「event」を結んだら、「resource」 の認知番号を 「event」 に複写 （re-used） する。
　（3） 「event」 と 「event」 を結んだら、先行 「event」 の認知番号を、後続 「event」 に複写する。

　以上の基本 ルール に加えて、以下の 3つの ルール を変形として加えた。
　（1） 「resource」 と 「event」 の間に多価関数が成立するなら、「HDR-DTL」 の形態とする。
　（2） 「event」 と 「event」 の間に多価関数が成立するなら、対応表 （mapping-list）を生成する。
　（3） aRb おいて、「a ＝ b」 は、「再帰 （recursive）」 として扱う。

　対照表 （真理値表） が主選言標準形であるという意味は、たとえば、従業員 （p） と部門 （q） の関係として、「従業員. 部門. 対照表」 （ｐ∧ｑ） が生成されるが、もし、配属されていない従業員がいれば、部門コードには null が起こる （ｐ∧¬ｑ）--ちなみに、従業員と部門のいずれかに null が起これば、対照表は サブセット として記述される。

　さらに、Ｔ字形 ER手法では、インプット として 「情報」 を対象としている--つまり、1つの 「情報」 として、画面や帳票や ファイル・レイアウト などを対象としている。1つの 「情報」 は 「複文」 である。1つの 「複文」 は、いくつかの 「単文」 から構成される。単文は 「entity」 として記述できる。したがって、1つの 「情報」 を単位として、「情報」 のなかに記述された認知番号を結べば、リレーションシップ が生成される。したがって、推論 ルール に従って記述すれば、だれが作成しても、同じ データ 構造になる--つまり、データ 構造を記述する エンジニア の価値観のために データ 構造が揺らぐことがない。言い換えれば、生成された データ 構造は、かならず、原点 （公理） として定立された entity から導出される。
　したがって、完全性が実現されている。

[ 注意 ]
　1つの 「情報」 のなかに記述されている認知番号を使って リレーションシップ を生成する やりかた は、リレーションシップ の網羅性を保証する訳ではない。最低限の リレーションシップ を記述しているだけであって、網羅性を保証するためには--ほんとうの完全性を実現するためには--、「リレーションシップの検証表」 を作成しなければならない。

　TM の最大特徴となっている 「対照表」 は、構文論上、主選言標準形を前提にした真理値表である。
　そして、意味論上、以下の 「哲学」 を導入していることは、前回、述べた。

　　「resource が event に関与 （ingression） する」

　そのために、（関係を示す） 「対照表」 には、以下の 2つの視点が導入されている。

　　（1） 構文論上、「resource」 の文法を適用する。
　　（2） 意味論上、「event」 を指示する。

　たとえば、以下の例を示す。

　　｛部コード、...｝.
　　｛課コード、...｝.
　　｛部コード (R)、課コード (R)｝.
　　｛従業員番号、...｝.
　　｛部コード (R)、課コード (R)、従業員番号 (R)｝.

　すなわち、｛部コード (R)、課コード (R)｝ の対照表と 「従業員」 の resource との関係は、「resource-対-resource」 の文法が適用される。そして、意味論上、｛部コード (R)、課コード (R)｝ の対照表は 「組織編成 （event）」 を指示し、｛部コード (R)、課コード (R)、従業員番号 (R)｝ は 「配属 （event）」 を指示する。以上が、「対照表」 の 「基本的な」 考えかたである。

　「『基本的な』 考えかた」 と言った理由は--したがって、ほかにも、考えかたがあるということだが--、「対照表」 には相反する性質が表裏一体となっているからである。すなわち、「対照表」 には、「event」 的な性質もあれば、「resource」 的な性質もある。以下を考えてみる。

　　（1） 「過程 （...ing）」 としての編成 （動作）
　　（2） 「結果 （...ed）」 としての編成 （状態）

　たとえば、｛部コード (R)、課コード (R)｝ の対照表 を 「過程 （動作）」 として考えれば、「組織編成」 の記述になるが、「結果 （状態）」 として考えれば、「組織」 そのものを指示する。
　したがって、「対照表」 は、性質として、「日付」 が明示的に （explicitly） に記述されているか、あるいは、文脈のなかで、「日付」 を仮想することができるとき、そして、そのときにかぎり、「『event』 を指示する」 というふうに解釈できる。

　逆に言えば、「resource」 の性質が記述されている対照表も成立する。その例を、「赤本 （「データベース 設計論--Ｔ字形 ER」） の最終 ページ で示した （下記の例）。

　　｛銀行 コード (R)、支店 コード (R)、口座番号 (R)、口座種別 コード、名義人｝.