| 2023年10月 1日 | 「3.2 モノ の集まりを作る」 を読む | >> 目次に もどる |
|
モノ として何を考えるか （見做すか）、モノ の 「定義」 を正面切って扱えば これは もう極めて難しい哲学的問題になります──機械などの構造 （仕組み） を考える エンジニア としては、こういう問題は 正直 扱いたくない。たとえば、「時計」 を考えた場合に、販売会社であれば、セールス する一つの単位 （プロダクト） として 「時計」 を モノ と見るだろうし、製造会社であれば、「時計」 を構成する個々の 「部品」 （文字盤、針、リューズ など） を モノ として、「時計」 は それらの モノ の構成品と見做すでしょう。「対象」 を観る視点によって モノ の捕捉単位は違ってきます。だから、モノ の 「定義」 は、「文脈」 によって揺れる （様々です）。すなわち、「構造」 を示す関数 （モノ を並べる関数） f (x1, x2,・・・, xn) では、モノ は無定義語であって、関係 （関数） のなかの変数として扱われ、変数のなかに 「真とされる値」 が充足されたら モノ が存在するという考えかた （関係主義） に立っています。 関数の入力には、変数として文字列を扱いますが、事業過程・管理過程を対象にすれば、それぞれの単語には すでに 「意味 （meaning）」 が付与されています。つまり、関数のなかで 本来 無定義語として扱われる変数には、「意味 （meaning）」 のある単語が使われるということです。コッド 正規形では、 f (x1, x2,・・・, xn) のなかの変数を それぞれ 「属性値集合」 として考えています──たとえば、x1 を 「従業員番号」 の集合として、x2 を 「従業員名称」 として、x3 を 「従業員住所」 として考える、ということ （そして、x1 が primary-key です）。すなわち、コッド 正規形では、 f (x1, x2,・・・, xn) の直積集合 [ tuple ] が、単純に言えば 関数 f が モノ を表しています。この表現形式は、TM でも同じです。 ただ、TM は、第 1章・第 2章でも述べたように、個体指定子 （コッド正規形の primary-key） についての 「文法」 を定めた技術体系です （primary-key の性質については、第 10章で詳しく述べています）。コッド の リレーショナル 理論は 完備性 （Relational Completeness） が証明されています、コッド の リレーショナル 理論を凌駕する データ 設計法を作ることは、私のような程度の凡人には ムリ です。そこで、私が考えたのは、tuple の構成文法ではなくて、事業過程・管理過程の 「（意味 meaning の） 構造」 を記述する文法を明示することでした。勿論、コッド 正規形でも、「（意味の）構造」は記述されています──コッド は、それを関数の constraints として表しています。その constraints を事業過程・管理過程の構造として ヨリ明らかにしたいというのが私の狙いでした。そのために、個体指定子 （primary-key） のあいだの 「関係」 を扱う文法を明示したという次第です。そのために、TM では、モノ というのは 個体指定子が付与された管理対象というふうに 「定義」 しています。TM は、個体指定子のあいだの 「『関係』 文法」 なのです。ただし、個体指定子のあいだの 「関係」 文法であるがゆえに、個体指定子を使って集められた 「属性値集合」 （および、それらの tuple） が正規の 「集合 （セット）」 になっているかどうかの検証の手続きが不可欠であることを覚えておいてください。 □ |
| << もどる | HOME | すすむ >> | |
| 目次にもどる | |||