対照表 （combination-table, truth-table, quasi-event） は、Ｔ字形 ER手法を公表した際、多くの人たち--とりわけ、ワーニエ・メソッド を使っている人たちや コッド 正規形を使っている人たち--の間で、論点になったし、いまでも、論点になっている技法である。

　ワーニエ・メソッド であれ、コッド 正規形であれ、ファイル （あるいは テーブル） 構造のなかで、2項間に 「複数：複数」 の関係が起こるときには、「1-対-1」 の対応関係として転換するために、「中間 ファイル」 として、対照表に似た ファイル を作っていたので、対照表を、その中間 ファイル と同じようにみなしてしまうようである。

　対照表は、あくまで、論理演算 （推論） のなかで、技術的に生成される ファイル であって、対照表そのものを単独に作ることは、絶対にない。

　Ｔ字形 ER手法は、コッド 正規形の以下の 2つの前提 （制約条件） に対して、正反対の判断をして作った公理形である。
　　（1） 関数従属性^{（注 1）}
　　（2） 包摂従属性^{（注 2）}

　関数従属性のなかで、コッド 氏は、タプル と同じ次数の空集合 （null） を認めているが、Ｔ字形 ER手法は、[ 少なくとも^{（注 3）} 、] 関係 スキーマ のなかで、null を認めない前提に立っている。そして、包摂従属性を正確に記述しようとすれば、テーブル の系列が論点になるので、Ｔ字形 ER手法は、テーブル を 2つの種類 （系列が論点になる event と、系列が論点にならない resource） に切り離した。

　Ｔ字形 ER手法は、「モノ と関係」 を記述するために、「情報 （言語形態）」 を対象にしているので、関係の論理として、関数 [ R (a, b) ] を使わないで、命題論理 （モノ の認知として「S-P」 形式を使うこと） と推論 ルール （aRb を記述するための 4つの推論 ルール） を使って公理形を作った。

　
●　対照表は、推論 ルール のなかで導出される技術的な テーブル であるが、「event の原型」 である。

　Ｔ字形 ER手法では、モノ （entity） は、event であれ、resource であれ、「単独 （one and only） の認知番号」 を付与されていることが定義である。したがって、entity そのものが認知されるには、複合概念 （2つ以上の認知番号を付与されること） は、絶対にない。系列を構成する event は、「内的性質として、DATE が帰属する事態」 として定義されている。つまり、event は時系列を構成する。 いっぽう、resource は、（内的性質として、DATE が帰属しない） 「持続する現実の事物」 あるいは 「反復する抽象的な事物」 である。

　関係の論理 （aRb） では、a および b は モノ とされ、R が関係を記述している。Ｔ字形 ER手法は、R を関数として扱わないので、推論 ルール を提示した。a および b が個体であるとすれば、R は、個体が関与する 「出来事 （occasion）」 として考えることができる。たとえば、受注 （関係 R）には、得意先 （個体 a） と商品（個体 b） が関与する。いっぽう、受注 （関係 R） は、事業のなかで、受注番号を付与されていれば--受注日が性質として帰属しているので--、モノ （event） として認知され、個体 （a および b） と同じ扱いになる。ただし、出来事としての性質を継承しているので、関係の記述は、受注 event のなかに記述される。したがって、推論 ルール では、受注 event のなかに、得意先 コード と商品 コード が複写される。

　resource のなかに、ほかの entity の認知番号が複写されることは、絶対にない。というのは、resource のなかに、ほかの entity の認知番号を複写すれば、resource は複合概念になって、単独の entity ではなくなるから。
　そのために、resource と resource が 「直接に」 関連を結ぶことがあれば、対照表を生成する。たとえば、従業員と部門のあいだに関連があれば、「従業員. 部門. 対照表」 を生成する。言い換えれば、対照表は、個体 （a および b） に対して、関係 R の記述である。関係 R は、生起する出来事 （occasion）であり、event として記述することができる。つまり、対照表は、「event の原型」 である--ただし、認知番号を付与されていない。したがって、対照表は、性質として、DATE （事業過程のなかで成立する取引日） を仮想する （あるいは、付与する） ことができる。たとえば、以下の対照表は、「配属」という event の原型である。

　　　従業員. 部門. 対照表 ｛従業員番号 (R)、部門コード (R)、[ DATE （たとえば、配属日）]、...｝.

　もし、この対照表に対して、配属番号とか辞令番号を付与すれば、対照表は、以下のような「配属」 event になる。

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

　Ｔ字形 ER手法の 4つの推論 ルール では、resource と event を結べば、resource の認知番号が event のなかに複写される--上述した、受注の考えかたを思い出してほしい。推論 ルール に従えば、従業員 （resource） と配属 （event） を結べば、配属のなかに、従業員番号が複写されるし、部門 （resource） と配属 （event） を結べば、部門 コード が配属のなかに複写される。これらの ルール は、上述した対照表の (R) 構成と同じである。

　以上のように、対照表は、命題論理を使って entity を認知して、（関数を使わないで） 推論ルールを使って 「関係の論理」 を記述する際、技術的に生まれる テーブル であって、Ｔ字形 ER手法の前提から導出される整合的な テーブル である。
　対照表には、以下の 2つがある。

　（1） event の原型 （「DATE」 が帰属する）
　（2） 真理値表 （「DATE」 が帰属しない）

　真理値表として作用する対照表は、理論的に生成しなければならない テーブル ではない。なぜなら、entity の間に成立する 「構成 （バリデーション・ルール）」 を示す テーブル であって、それ自体 （真理値表） は、entity として認知されないから。真理値表として作用する対照表については、すでに、ほかの ページ で詳細に記述したので割愛する--以下のページを参照されたい。
　　65ページ、77ページ、141ページ、145ページ、149ページ。

　
（注 1） 関数従属性
　1つの タプル のなかで、或る属性値に対して、他の属性値が一意になること。

（注 2） 包摂従属性
　或る テーブル の キー は、他の テーブル のなかにも存在しなければならないこと。
　「参照整合」 ともいう。

（注 3） 少なくとも
　outer join では、null が起こることがあるが、ここで論点にしている null は、atomic な属性値のことをいう。

　市販されている 「データベース 設計法」 に関する書物のなかで、最近、「対照表」 という （小生が作った） 独特の用語を流用している--「パクっている」?--書物が いくつか あるようです。そして、それらの書物のなかで、「対照表」 は、「2つの テーブル が 『複数-対-複数』 の関係にあるならば作成する」 と記述されているそうです。そういう説明は、「対照表」 の性質を正しく理解していない。もし、そういう説明で済むのであれば、（「対照表」 という用語ではなくて、） 「対応表 （mapping-list）」 という用語を使うべきでしょう。すなわち、「対照表」 という用語を パクった人たちは、「対照表」 の性質を理解しないままに、「対照表」 という用語を使っているということです--しかも、参考文献を示さないまま （怒）。

　「対照表」 と 「対応表」 は、それぞれ、性質がちがうので、私は、2つの用語法 （「対照表」 と 「対応表」） を作りました。「対照表」 は、本 エッセー のなかでも述べていますが、「意味論的に、事実的な 『F-真』 概念」を構成します。そして、「対応表」 には、そういう性質はない。したがって、「対照表」 は、関係の対応性が 「1-対-1」 でも 「1-対-複数」 でも 「複数-対-複数」 でも構成されます。
　「対照表」 は、以下の 2つの性質のいずれか を帯びています。

　（1） 事実的な 「F-真」 概念
　（2） 制約 （resource のあいだに生じる制約）

　したがって、「対照表」 は、単なる 「上への関数 （onto-mapping）」 ではない。
　もし、「対照表」 という用語を使うのであれば、正しく理解して使っていただきたいし、もし、「複数-対-複数」 の関係を除去するためにのみ使うのであれば、「対照表」 という用語を使わないでいただきたい。