事実的対象を、モデルとして、「（科学的に） 記述する」ことと、モデルが示している構造を「解釈する」ことは、それぞれ、べつの行為である。言い換えれば、モデル技法 （modeling） を使って、事業過程を的確に記述できても、事業過程の「意味」を適切に解釈できる、という訳ではない。

　たとえば、拙著「論理データベース論考」のなかで示した「受注入力画面」を対象にして--177ページを参照されたい--、小生の愚息 （中学１年生） が、（ＴＭの規則に従って、） データ構造を、５分ほどで作った。この練習問題 （受注入力画面） は、ＴＭの規則を、単純に説明するために--したがって、データ構造を作りやすいように--、事業過程で使われている用語 （単語） を、わかりやすいように選んであるので、中学生でも、規約さえ知っていれば、データ構造を作ることができる。愚息が、ＴＭの規約に従って、すぐに、データ構造を作ることができた、としても、かれが、事業を知っていることにはならない。
　ＴＭの規則は、構文論 （文法） として整えてあるので、もし、事実的対象に対して付与された述語 （観察述語） が、機械的に判断できるように語-構成を整えてあれば、中学生でも、文法に従えば--語の「意味」を知らなくても--、データ構造を作ることができる。そうだからと言って、かれが DA （Data Analyst） である、ということにはならない。

　ＴＭの「対照表」は、Ｔ字形ＥＲ手法を公表したときに、論争を起こしたし、いまでも、論争をよんでいるそうである。すなわち、（対照表は、）「データの冗長」ではないか、と。そして、そういう構成にすることには、「意味がない」、と。
　たとえば、以下を考えてみる。

　　従業員
　　　｛従業員番号、従業員名称、...｝.

　　部門
　　　｛部門コード、部門名称、...｝.

　　部門. 従業員. 対照表
　　　｛部門コード（Ｒ）、従業員番号（Ｒ）｝.

　
　対照表は、そもそも、「関係の論理 （ａＲｂ）」に対して、関係Ｒ を「関数」として適用しない、ということを前提にしている。そうした理由は、関数従属性および包摂従属性を前提にして作られる以下の構造のなかで、（部門コードの値として、） null が生じるから。

　　　｛従業員番号、従業員名称、...部門コード（Ｒ）｝.

　
　たとえば、部門に配属されていない従業員を考えてみればよい。Null は、（意味論的に、） 「Ｆ-真」を示さない--「unknown」 と 「undefined」 という多義になる。たとえ、ダミー・コードを使って、null を回避しても、ダミー・コードは、「Ｆ-真」を示さない。
　ウェッブの或るサイトでは、「Ｔ字形ＥＲ手法は、null にこだわりすぎる」という非難が記載されているそうだが、そう言う人は、はたして、数学・論理学 （あるいは、プログラムのアルゴリズムのなかで、２値を使うこと） を、エンジニアとして、まじめに考えているのだろうか。Null の論理否定 （NOT） は、null になる、というのが、３値論理である。とすれば、null を、（いくつか） ふくんだテーブルに対して、NOT をふくむ構文を適用すれば、どのような結果になるのか、という点を、そう言う人は、考えたことがないのだろうか。そう言う人は、エンジニアとして、無責任なことを言っている、と小生は思う。

　さて、話を本筋 （対照表） に戻して、｛部門コード（Ｒ）、従業員番号（Ｒ）｝に対して、もし、「日付」を仮想すれば、ＴＭの規約に従って、その対照表は、「配属」という「event」を「指示する （意味する）」。つまり、（日付を付与できる） 対照表は、「Ｌ-真」であると同時に、「Ｆ-真」でもある。したがって、対照表に対して非難されている「意味がない」というのは、的外れである。そういう非難をしている人は、｛従業員番号、従業員名称、...部門コード（Ｒ）｝として記述された部門コードそのものが、（関数従属性・包摂従属性を前提にした） 「構造」のなかで、制約条件として、「配属」という意味を記述している、というコッド関係モデルの構造を、適切に理解しているのだろうか。

　
　（2005年 6月 1日）