Ｔ字形 ER手法の 「対照表」 は、かつて （そして、今も）、論議を醸し出している点です。「対照表」 は、「述語論理」 の観点からすれば、「データ 構造」 として扱ってはいけない（笑）。言い換えれば、「対照表」 は、アルゴリズム のなかで扱うか、あるいは、どれかの テーブル のなかの 「従属関数」 として扱う、と いうのが 「述語論理」 の考えかたです。

　僕は コッド 正規形を信奉しています。ただ、コッド 正規形は、数理 モデル として、無矛盾性と完全性を実現していますが、事業のなかで実地に使われている データ を対象にした際、「（データ の） 並び」 と 「null （データの値）」 扱うことができなかった。

　しかも、コッド 正規形では、セット （集合） が前提になっているのですが、「セット を形成する判断規準がない」 という悩ましい問題点があります。どのような性質 （述語） を使って セット を形成するか--性質と述語は、厳密に云えば違うのですが、ここでは、論点にしないで--という点は恣意的です。

　セット を生成するために使った性質が、「モノ」 そのものに帰属する性質なのかどうか、という点は、集合論では論点にされない。セット を形成する性質が、「モノ」 そのものに帰属するかどうか、という判断がないので、間一髪、「意味論」 が忍び込む余地ができてしまった、ということです。つまり、「意味論」 は、「モノ」 そのものを対象として、「モノ」 そのものに帰属する性質と、「モノ」 が外的な関係のなかで形成してきた性質を仕訳しようとします。言い換えれば、集合論では、「モノ」 は関数の パラメータ ですから、どういう関数 （性質） を使うか、という点は恣意的です。

　いっぽう、意味論 （存在論、実体論） では、「モノ」 そのものの性質 （本質） と、「モノ」 が外的な関係のなかで稼得した性質を仕訳しようとしますが、「モノ」 の定義ができない。
　集合論の短所を意味論が扱おうとしていますし、意味論の短所を集合論は回避している、という二律背反の関係なのです。これらが相互に補うようにするには、どうすればよいか、、、。

　ｆ (x) [ つまり、性質 ] を使って集合を形成して、ｆ (x, y) [ つまり、関係 ] を使って テーブル を形成しますが、ｆ (x, y） のなかで成立した アトリビュート [ つまり、domain のなかを走る値 ] が、「整合的」であるかどうか、という検証は、「functional dependency」 が成立するかどうか、という点に委ねられています。
　したがって、従業員番号を 「primary-key」 とすれば、従業員の テーブル のなかに、入社日が定義されていても、従業員番号と入社日は、関数的な依存関係が成立するので--「primary-key」 と アトリビュート の間に、「1-対-1」 の関係が成立するので--、入社日は従業員の テーブル のなかに定義されていても良い、ということになります。入社日が、従業員そのものに帰属する性質かどうか、という点は集合論では論点にならない。

　しかし、もし、入社日が従業員の テーブル （セット、直積集合） に帰属しないとすれば、「日常言語の使いかたのなかで」、従業員の集合が曖昧になります。コッド 正規形は 「モデル」 としては、無矛盾性と完全性を実現しているのですが、実際に、テーブル を設計するとき、SE によって、テーブル の生成が、若干、ズレ てしまう理由は、その点にあるようです。
　関数として扱えば、｛従業員番号、従業員名称、入社日｝ となりますが、たとえば、或る SE が、（従業員の 「純粋な」 セット を形成するつもりで） 以下のような テーブル を設計しても、「或る観点から判断すれば」 間違いとは言えない。
　｛従業員番号、従業員名称｝
　｛従業員番号 (R)、入社日｝

　「或る観点から判断すれば」 と言った理由は、従業員そのもの （第一性） と、従業員が、ほかの対象に対して 「なんらかの行為」 をした関係 （第二性） を仕訳すれば、以上の テーブル は正しい--つまり、「意味論」 を導入しているのですが。

　そのときに、｛従業員番号 (R)、入社日｝ は、数学的な集合 （セット） か、と問えば、そうではない（！）　しかし、「日常言語の使いかたのなかで」、1つの集合として考えることができる。つまり、｛従業員番号 (R)、入社日｝ は、数学的な集合 （セット） ではないけれど、意味論の観点からすれば、入社日は従業員の性質ではない。

　いままで、だれも、その点 （集合論が性質を扱うときに、性質が モノ そのものに帰属するのか、そうでないのか、という点） を、データ 設計のなかで論点にしてこなかった。なぜなら、集合論の観点からすれば、そういうことは論点にはならないから。
　コッド 正規形を改善しようとした際、僕を悩ました点が、まさに、この点 （意味論） だった。

　そのために、僕は、データ 設計の最初の段階で、「データ の認知」 ということを論点にしました。コッド 正規形では、「primary-key」 として扱えば、簡単に済んでしまう点を、僕は 「しつこいほどに」 こだわった（笑）。コッド の セット・アット・ア・タイム 法を説明するときには、直積集合の説明をしていれば、まったく、問題点がないのですが、いざ、具体的な データ を対象にしたら、とたんに、説明がむずかしくなる（笑）。つまり、具体的な 「集合」 （テーブル） を設計する段になったら、SE が、それぞれ、若干、違う テーブル を設計してしまう。
　そのために、僕が導入した考えが、「合意」 （言語の使用説） という点だった--もちろん、僕には、それを考えるほどの天才はないので、ウィトゲンシュタイン の考えを使ったのですが（笑）。

　（2003年11月 9日）