「モデル」 を作るという作業をしていると、強烈な不安に襲われることが、多々、起こるようです（──ただし、これは僕の体験なので、すべての人に当てはまるかどうか、という点に関して確信はないのですが）。「不安」 というのは、たとえれば、広大な海のなかに飛び込んで、どこに向かって泳いでいけば良いのか、皆目、わからないまま、ただただ、手足をバタバタ振り回して溺れないようにしている、というような感覚に似ています。
　そして、たとえ、なんらかの 「モデル」 を作ったとしても、根底から間違っていたのではないか、という恐怖感が、ときどき、襲ってくる。

　たとえば、Ｔ字形 ER手法は、コッド 正規形の 2つの弱点 （「関係の並び」 と 「属性値の null」） を回避することを目的として作られたのですが、Ｔ字形 ER手法の最終形は、数理 モデルのなかに意味論を導入しなければならなくなった。セット・アット・ア・タイム 法 （コッド 正規形） が使った数学的手法 （直積集合） は、属性値集合を前提にして tuple を生成する関係 （関数） でした。
　たとえば、従業員番号の domain （属性値集合） と従業員名称の domain （属性値集合） から、それぞれ、1つずつ メンバー （値） を選んで、｛従業員番号, 従業員名称｝ という tuple を生成します。tuple を生成する関数が 「関係」 です──関係とは関数のことです。

　コッド 博士は、当初の モデル を拡張する論文を提示しています。その論文では、直積集合の domain として、属性値集合のほかに、主体集合を入れることを提示しています。
　属性値集合を f (x) とすれば、主体は、属性の集まりですから、F (f) です。とすれば、セット・アット・ア・タイム 法の値が走る domain が拡張されているのですが──階が 1つ高くなっているのですが──、これを関係 データベース として考えればよいのか、べつの形態の データベース 設計論として考えればよいのか、、、。

　提示された 1つの 「モデル」 のまわりには、膨大な知識が関連していて、それらの知識を 「芋蔓式に」 追跡していけば、おそらく、追跡することばかりに労力を費やして、自らは、なにもできないまま──さらに、一歩を進めることができないまま──終わることになる。だから、闇夜のなかの海に投げ出された感覚が起こるのでしょう。
　そういう連鎖を、どこかの区域で断ち切って、対象を限定しなければならない。

　たとえ、対象を限定しても、「意味」 そのもの （定義） を記述して、構造を考えようとすれば、悪しき抽象論に陥るか、無限後退に陥ることになるでしょう。たとえば、「鳥は飛ぶ」 という命題を考えるとき、「鳥」 とはなにか、とか 「飛ぶ」 とはなにか、ということを考え始めたら、収拾がつかなくなるし、しかも、例外が出てくる （たとえば、海鳥の ペンギン）。このような 「『らっきょう』 の皮むき」 事態を回避するには、──意味は性質を記述しているのだから、──性質の存在を前提にして集合を考えて、それらの 「述語 （あるいは、性質）」 を集めたら、「個体」 の存在を判断できるというふうに考えることもできます。

　たとえば、「『論理 データベース 論考』 の著者は、日本人である」 という複合的な固有名辞を考えるとき、以下の式で記述することができます。

　　　　∃x (F (x)∧G (x)).

　注意してほしい点は、固有名辞を述語に吸収しているという点です。
　すなわち、

　（1）F (x) であるような対象 x が存在する。
　　　（ここでは、「論理 データベース 論考」 を執筆した人物のこと）

　（2）G (x) であるような対象 x が存在する。
　　　（ここでは、日本人の メンバー であるということ）

　数学が対象としているのは、形式的な構造であって、物の定義ではない──数学では、物は無定義語です。すなわち、値を一意に定めるような アルゴリズム があって、「物が存在するとは、関数の変項になりえること」 であるというのが数学の考えかたのようです。

　僕は数学が苦手ですし──高校生のとき、数学の点数が （100点満点の） 12点だったこともあるのですが （苦笑）──数学を専門にしていない我々 シロート は、数学の プロ が精確な式を操作するのと同じ程度に数学を使うことは、まず、ないでしょうが、記述された式を読むことができるようにはしておきたい。
　数学自体は、そうとうに高度化しているそうですが、最近では、数学が、我々のそばにいる。たとえば、コッド 正規形にしても、オブジェクト 主導にしても、エージェント にしても、数学を知らなければ理解できない領域です。数学は広範ですが、我々 シロート は、「論理と集合」 の考えかたを学習して、論理式を読めるようにすればいいでしょう。

　そして、いったん、「構造」 を構成する手続きが提示されたら、手続きに従って、値を操作して具体的な 「構造」 を生成できる、というのが 「理想」 でしょうね。
　「理想」 というふうに、わざわざ、「　」を付与して注意を促した理由は、現実には、それが、なかなか、むずかしい、ということです。

　なぜなら、論理式を作るときに回避した 「言葉の 『定義』」 が、亡霊のように現れるから。たとえば、従業員を考えてみましょう。

　従業員 ⊃ ｛入社日 (x) ∧ 従業員番号 (x) ∧ ...｝.

　数学的な構造のなかでは、上述の式は正しいのですが、たとえば、以下のような 「存在論」 を考えてみましょう。

　　（1） 状態──モノ そのものの性質 （第一性）
　　（2） 作用──事態のはじめと事態の終わりの間に生じる作用 （第二性）

　もし、そういう 「存在論」 を前提にすれば、入社日は、入社という作用に帰属する性質である、というふうに判断することもできる。こういう観点が入ってくると、「構造」 を生成する作業が、次第に、込み入ってきますね。ただ、その観点も 「モノの見かた （世界観）」 の 1つなので、無視する訳にはいかない。つまり、対象となる世界を、どのような前提で観ているか、という点が論点になるのです。

　哲学のなかには、数々の派があるそうですが──僕は、哲学も シロート なので、哲学のことも多く知らないけれど──、おそらく、「派」 というのは、「モノ の見かた」 が違うことが理由なのでしょうね。

　数学の世界と哲学の世界の間で翻弄されはじめると──しかも、エンジニア の僕は、いずれの世界の専門家でもないので──、もう、闇夜の海のなかに投げら入れられ、溺れないように懸命に泳いでいる、という感覚が起こる。しかも、「モデル」 を作るときに使った数学的な手法や哲学的な考えかたを間違って理解しているかもしれない、という強迫観念がつきまとう。

　そういう不安感・恐怖感を回避するためには 1つしか救済法がない。
　それは、「作られた 『モデル』 のなかには、破綻がない （無矛盾性と完全性を実現している）」 という点を検証することしかない。そして、モデルの 「目的」 と 「前提」 を提示すれば良い。僕が、データベース の色々な設計法を、ほかの人たちから教えてもらうときに、かならず、確認する点は、「目的」 と 「前提」 です。そして、「モデル」 が公理系 （アウトプット が、いくつかの前提から、すべて、導出されること） であるかどうか、という点を、かならず、確認します。そういう態度は、「数学的である」 というのではなくて──なぜなら、僕は数学の シロート ですから──、僕が強烈に感じた不安感・恐怖感を回避するためです。

　ちなみに、Ｔ字形 ER手法は、或る目的のために、或る前提に立って、ルール どおりに作成すれば、或る構造が記述できる、という技術 （technique と mechanism） です。それ以上でも、それ以下でもない。

　
　（2003年11月28日）

　
　（参考）　本文のいちぶを書き換えました。（2008年 8月12日）