sdi - Page: FAQ229

[ 補遺 ] （2008年 7月16日）

　本エッセーでは、具体例を示しているので、取り立てて、補遺はいらないでしょう。

　本エッセーのなかで使われている用語を、若干、訂正しておきます。「アトリビュート・リスト」のなかに、「前提（baseline）」欄があるのですが、「前提」という言いかたを、最近（2年ほど以前から）、「制約・束縛」という言いかたに変えています──ただ、「アトリビュート・リスト」では、いまでも、「前提」というふうに記載しています。

　本エッセーで述べた「階のちがう概念が、ひとつの個体指定子（entity-setter）のなかで同列に付値されている」という現象を、私は、ときどき、clients のいくつかのシステムで遭遇しました。クリプキ氏のことばを借用して、（正しいクラス演算に対して、そういう間違ったクラス演算を）「クワス」算というふうに私は諷しています。

　さて、セット、クラス、アトリビュート、述語は、数学上、それぞれ違う概念として定義されているのですが、いっぽうで、それらの概念を、ふだんの生活のなかで使うときに──ここで云う「ふだんの生活」というのは、システム設計（そして、特に、データベース設計）という意味ですが──、どれほどの違いがあるのでしょうか。それらの概念のなかで、どれかひとつを起点にして、ほかの概念を類似概念として使えば、それらの概念の違いは、使用上、さほど、難点にはならないのではないでしょうか。ちなみに、私は、セット概念を起点にしています。セット概念を起点にすれば、セットは、特殊な種類のクラスになるにすぎないでしょう。すなわち、もし、クラスのなかに、「階」を導入すれば、クラスは、クラスの元（メンバー）であるとき、セットである、という考えかたです。だから、私は、クラスを f (x) としてみなして、（セットがモノのあつまりであることに対して、）クラスを「概念」というふうに考えています。とすれば、セットはクラスであると思っても宜しい。そして、もし、クラスを f (x)　だとすれば、クラスと「性質」には、さほど、違いはなくなって、「叙述的・述語的な」集合を考えることも、自然なやりかたでしょう。すなわち、外延が同じもので、「分割（division）」を除去したものをクラスとみなすのが自然なやりかたでしょう。

　さて、クラスのなかに「階」を導入することを考えてみましょう──ラッセル氏が提示した「型（タイプ）」を考えてみます。「階（あるいは、「型」）」は、「集合論のパラドックス」を回避するために導入されました。「階（あるいは、型）」を使うというのは、変数に対して添字を使って、階層的な記法を使うやりかたです。すなわち、個体を x ₀ とか y₀ として、集合を x₁ とか y₁ と、さらに、レベル 3 （集合の集合）、レベル 4 （集合の集合の集合）というふうに無限に続けることができます。ただ、ひとつの範囲のなかのひとつの集合を定立するには、それらの構成員（元）に対して、階の添字はいらないでしょうし、まして、「文」を単位にして考えれば──たとえば、「佐藤正美は男である」という文を考えれば──、単称名辞（佐藤正美）に対して、性質（男である）の外延（集合）を考えることも意味はないでしょう。ただ、「階（あるいは、型）」の考えかたは、概念を構成するやりかたに合致するので、自然に感じられるでしょうね。

　ところが、この「階（あるいは、型）」を使ったときに、少々、やっかいな問題点が浮上します。TM のなかで、そういう現象が、多々、起こります──「対照表」がそうです。というのは、たとえば、集合の「論理和（論理積）」を考えてみてください。それぞれの集合（レベル 2）は、個体変数（レベル 1）を前提にして定立されているのですが、すべての集合の「論理和（あるいは、論理積）」は、レベル 3 で扱うことになります──あるいは、少なくとも、レベル 2 に属することを排除されるでしょう。このやりかたは、データベース設計では、「強すぎる」でしょうね。寧ろ、セット概念（の「対の公理」）を使ったほうがデータを構成しやすい。だから、私は、タイプ理論を使わなかった。

　さて、本エッセーで述べた「事業所、部、プロジェクト」に関して、たとえば、最初に、「事業所」という類を考えて、次に、その構成員として、それぞれ、「部」「プロジェクト」を考えるというやりかたが、ほんとうに effective かどうか──言い換えれば、クラス概念（タイプ概念）を起点にして考えるというやりかたが、ほんとうに effective かどうか──を検討していただきたい。ここには、或る混乱が起こっているように私には思われます。すなわち、この混乱は、「クラス（あるいは、タイプ）」を適用するときに、「分割・細分」をトップダウン的に導入してしまったので起こったように私には思われます。前述しましたが、「クラス」は、「性質」として考えて、ボトムアップ的に導入したほうが effective ではないでしょうか──特に、データがすでに存在しているような領域では、そうだと思います。そして、いったん、クラス（あるいは、タイプ）を使って「概念」を構成したら、次に、上位の階（類）から下位の階（種）が「網羅されているかどうか」を検討するほうが effective だと私は思います。

2003年 7月 1日	事業所コード（コードの混在）	>> 目次（テーマごと）
●　QUESTION	事業所コードのなかにプロジェクト・コードが混入しているが、どのように扱えばよいか。
▼　ANSWER	階の関係が崩れた例である。　概念的スーパーセットを使えばよい。
2008年 7月16日補遺

	<< もどる	HOME	すすむ >>
	データ解析に関するＦＡＱ