芥川龍之介 作「侏儒の言葉」のなかで、百足と蝶の喧嘩として、以下の文が記述されています。

　　　　百足　　ちつとは足でも歩いて見ろ。
　　　　蝶　　　ふん、ちつとは羽根でも飛んで見ろ。

　
　前提が同じでなければ、対比ができないことを、この寓話は示しています。

　さて、前回、僕は、「モデルと自然言語」について綴りましたが、いわゆる「基幹系システム」を対象にして、以下の２つの前提を置いています。

　　（１） 事業のなかで使われる文章情報を対象とする。
　　（２） データベース・プロダクトとして、 RDB を使う。

　もし、この２つの前提を外せば、ほかの考えかたを前提にした公理系・技術が成立します。
　たとえば、「人工知能 （ＡＩ）」を枠組みにして、認知・推論・知識・学習という観点から、データを扱うこともできます。あるいは、「認知科学」の枠組みのなかで、パターン認識・記憶・イメージ・推論と知識・言語・学習・感情・信念などを対象として扱うこともできます。あるいは、「自然言語理解」のなかで、形態・構文・意味・文脈などを対象として考えることもできます。

　どういう目的のために、どういう公理を前提にして、どのような体系 （あるいは、体系まで至らないけれど、いくつかの やりかた） を組んでいるか、という点を確認しなければ、２つの体系 （あるいは、やりかた） を対比するとき、（それぞれの体系が整合的であれば、） 対比は、「水掛け論 （talk past）」として終わってしまいます。
　ＡＩ の領域に対して、関係モデル （relational model） やＴ字形 ER手法は、充足的なモデルではない。関係モデルもＴ字形 ER手法も、データベース設計論のモデルです--ただし、Ｔ字形 ER手法をモデルと呼ぶことには、僕は抵抗があるのですが、、、というのは、構文論として、Ｔ字形 ER手法は、スキーマに対する手法であって、代数演算を提示していないから [ 代数演算は、コッド博士が提示なさったリレーショナル代数演算を前提にしているから ]。

　形式主義的公理主義が、自然の現象 （事態） に対して、すべからく適用できるかどうか、という点について、僕は、意見を提示するほどの数学的な知識はないのですが、少なくとも、モデル （あるいは、理論） は、いくつかの命題を前提にして、それらの命題のみを用いて作られるという前提に立てば、モデル （公理系） を検討するなら、目的と選ばれた公理を確認するのは当然でしょうね。モデルも１つの言語ゲームです。
　言い換えれば、問題を定式化するには、以下の２つを、つねに考慮しなければならない、ということです。

　　（１） 目的関数 （公理系）
　　（２） 制約条件

　以上のような考え方ができる、というのは、論理的に考えることができるエンジニアの態度だと思うのですが、SQL のプログラムや Java のプログラムを作成できれば、関係モデルやオブジェクト主導を知っていると勘違いしている人たちが多いし、目的や公理を提示しないで、単なる作図技法をモデルと勘違いしている人たちも多いようです。

　公理 （前提） と目的 （制約条件） を提示しなければ、モデル (公理系) の対比は、シロートの喧嘩のような「水掛け論」になるのは当然でしょうね。

　「科学的である」ということが、対象の構成とか法則を探ることであり、エンジニアリングということが、（対象に対する） 機械仕掛けの構造を設計・作成する技術である、とすれば、モデル （公理系） を検討するなら、目的 （制約条件） を確認することは、エンジニアの態度として、当然のことでしょう。

　かって、小生の「論理データベース論考」に対して、「詐欺である」という言い掛かりの読者カードが送られてきたことがあります。そして、「SQL などという醜悪な言語しか扱っていない」という非難が綴られていました。
　SQL が「醜悪」かどうか、という判断は、僕にはできないのですが、「はしがき」のなかでは、「関係 （多項述語論理）」を「関数」として扱わないで、「名辞 （概念） と関係は同じレベルにある」ことを前提にして、データ構造に関する推論ルールを考えたことを綴っていますし--スキーマとして、関係モデルとは違う公理を前提にすることを記述していますし--、「目次」のなかには、「リレーショナル・データベースの基本構造」という章立てが明示されていて、データベースとして、（関係モデルを前提にした） リレーショナル・データベースを検討の対象にしていることを明示していますので、（SQL 以外の言語を対象にしなかったことに対して） 僕は「詐欺」呼ばわりされることをしていないはずですが、、、。
　もし、「目次」のなかで、「リレーショナル・データベースの基本構造」という章立てを記述しながら、SQL を対象としなかったり、あるいは、ほかの言語を扱っていれば「詐欺」になるでしょうが、僕は、「はしがき」と「目次」のなかで、目的・前提と制約条件を明示しています。

　なお、Ｔ字形 ER手法を使って作図したスキーマが、SQL 以外の言語に対して--あるいは、手続き型言語と表操作言語のほかの言語に対して--、有効かどうか、という点を、僕は検証していないので、なんとも、コメントができない （ただし、セット・アット・ア・タイム法とレコード・アット・ア・タイム法を前提にしている言語に対しては、Ｔ字形 ER手法のスキーマを使うことができるはずです）。Ｔ字形 ER手法は、関係モデルが前提にした公理 （関数従属性と包含従属性） に関して、「べつの定義を使えば--関数従属性に対して「null値」を認めないで、包含従属性に対して「並び （順序系列）」を考慮すれば--、べつの公理系を作ることができる」ことを示しただけです。

　リレーショナル代数演算 （セット・アット・ア・タイム法） を前提にした SQL が「醜悪」かどうか、という点は僕には判断できないけれど、少なくとも、関係代数は、第１階述語論理を使った「関係完備 （relational complete）」が証明されているので、１つの公理系として、整合的です。整合的な公理系は「美しい」、と僕は思うのですが、SQL は、関係代数のほかの操作句 （group-by、average、countなど） も用意しているので、件の人は、それらを「醜悪」と言ったのかなあ、、、それとも、モデルの目的・前提・制約条件を考えることができなかったのかな（笑）。

　「反コンピュータ的断章 （2004年１月７日付）」のなかで、「コンピュータ ソフトウェア事典を読む」ことを、お薦めしました。コンピュータ ソフトウェア事典を読めば、自らが専門にしている技術など、広大なコンピュータ・ソフトウェアの領域のなかでは、微々たる対象にすぎないことを理解できるでしょう。そうすれば、自らの技術が「最高」などと思う自惚れもなくなるでしょう。そして、自らは「一介のエンジニア」にすぎない、と思うのが正しい。ただし、技術 （人工的な言語ゲーム） の適用目的・前提・制約条件を考慮して、技術体系を、１つの言語ゲームとして、「科学的に考える」ことができるエンジニアである、と。

　
　（2004年2月29日）