プロダクトおよび技術を起点にして、システム・エンジニアの仕事を考えてみれば、以下の３つの仕事が成立するのではないでしょうか。

　（１） 歴史のなかで継承され進化してきた学問（知識）を前提にして、
　　　　新しい「モデル」を作る。

　（２） （だれかが、すでに、作った） 「モデル」を前提にして、
　　　　具体的な物（プロダクト）あるいは技術を作る。

　（３） （だれかが、すでに、作った） プロダクトあるいは技術を適用して、
　　　　或る目的を実現するためのシステムを作る。

　小生は、「モデル」という用語を、広い意味で使っていて、「アルゴリズム」と同義である、と理解してください。（１）は、さらに、「汎用的に使うことができるモデル」を作る基礎研究と、「或る目的を実現するために使われるモデル」を作る応用研究の２つがある、と考えていいかもしれない--もっとも、それらの境界線は、曖昧かもしれないけれど、、、。

　さて、小生自身は、（２） と （３） を仕事としているエンジニアです。企業のなかで働いているエンジニア（practitioners）は--研究職に従事しているエンジニアを除けば--、ほとんど、すべて、（２） あるいは （３） を仕事にしているでしょうね。
　コッド関係モデルは、（１） の成果として考えてよいでしょう。

　どうして、わざわざ、以上のことを言及したのか、と言えば、コッド関係モデルと（プロダクトとしての）ＲＤＢＭＳは、「相違する」という点を言いたいからです。ＲＤＢＭＳは、コッド関係モデルを基礎にして作られていて、コッド関係モデルの一部（セット・アット・ア・タイム法としてのモデル）を導入していますが、コッド関係モデルを、包括的に包摂している訳ではない。
　つまり、コッド関係モデルの具体的な形がＲＤＢＭＳである、と考えるのは謬見である。コッド氏は、２値（真および偽）しか扱えない--３値あるいは４値を前提にしていない--ＳＱＬに対して、非難なさった。

　ＲＤＢＭＳは、プロダクトとしての技術（mechanism と techniques）を搭載している。したがって、ＲＤＢＭＳを観て、コッド関係モデルを、逆に「推測」して、批評するということは、的外れになる。コッド氏のモデルは、彼が記した論文・書物のなかに示されている。１つのモデルを前提にして、２つの相違するプロダクトを作ることができる。或るモデルを、プロダクトとして、どのような「しくみ（machanism）」を使って具体化するか、という点は、プロダクトを作るエンジニアの力量が問われる。上述した（２）の仕事も、極めて、むずかしい仕事である--エンジニアなら、だれでもが できる、という訳ではない。そして、マーケットに対してセールスするプロダクトであるからには、どうしても、プロダクトを作るための費用を斟酌しなければならない。

　さて、上述した（３）を仕事にしているエンジニアが、コッド関係モデルのデータ正規形を、「ＲＤＢＭＳ向けのデータ構造を作る」技法として考えるのか、それとも、「関係モデル」--セット概念および第一階述語論理を前提にして、直積集合を使ったモデル--を、汎用的なモデルとして、考えるのか、という点は、論点になるでしょうね。
　そして、いずれの観点であれ、コッド関係モデルとＲＤＢＭＳは、それぞれ、独自の物である、という認識に立って主張されなければならないでしょうね。

　
　（2005年 5月 8日）