2005年 5月 1日 基準編-3 identifier と entity >> 目次にもどる
2010年 4月 1日 補遺  

 

 Identifier を、entity を認知するための符丁としている点では、「黒本」 の考えかたは、いまも、継承されている。
 しかし、「黒本」 と、いまの やりかた では、若干、違いがある。その違いは、identifier の訳語として、「認知番号」 という語を使っている点である。

 Identifier と entity に関して、小生は、訳語を悩んだ。「論考」 (2000年出版) でも、identifier と entity に関して、的確な訳語を思い浮かばなかったので、原語のまま、「identifier」 とか 「entity」 というふうに綴っている。Identifier の訳語として、「識別子」 を使うつもりは、毛頭、なかった。小生が論点にしたかったのは、「認知のしかた」 であって、identifier を、認知された個体に対する符丁として考えるのではなくて、認知行為のほうに視点を向けたかった。
 Identifier に対して、「認知番号」 という訳語を、定訳として、使うようになったのは、2002年か2003年だった、と記憶している。

 「認知」 行為を重視した理由は、(T字形 ER手法が、当初、ウィトゲンシュタイン 氏の前期作 「論理哲学論考」──写像理論を提示した書物──を底本にして作られたけれど、 彼の後期作 「哲学探究」──「言語 ゲーム」 を提示した書物──を底本にするように、転回したかったので、) ゲーム に関与している人たちのあいだで成立している 「同意」 という行為を重視したかったから──この点に関しては、次回、「identifier と コード 体系」 のなかで、詳細に述べるので、これ以上に語ることを止める)。

 Entity も、非常に、むずかしい概念である。
 Entity は、ふつうの使いかたであれば、「現実的事実のなかで存在する対象」 というふうに考えられるかもしれない。ただ、「現実世界」 というのは、或る モーメント のなかで生起した すべて のことなので、「対象」 は、認識主体の判断が作用して、「認知」 された物である。すなわち、entity は、実物 (「...の時点で、...の所にある」 存在、あるいは、或る quantity ) のままでは、科学の対象にならないので、われわれは、現実世界のなかで感知される実物を、なんらかの構成のなかで、「対象」 として記述する。この 「対象」 を、データベース 設計の領域では、entity と云う。
 Entity の訳語として、「認知された対象」 とか 「個体」 を使っても良いのだが、それらの語は、どうも、「作用 (事象)」 を個体として ふくめない ニュアンス があるので──「作用 (事象)」 も entity なのだから──、小生は、それらの語を使わないで、わざわざ、カタカナ 表示として、「モノ」 という語を使っている。

 1つの 「構造」 は、「モノ と関係」 を使って記述される──「モノ」 には、「作用 (事象)」 も ふくまれていて、「作用 (事象)」 が 「関係」 ということではない点に注意されたい。「関係」 は、モノ どうしが関与するしかたであると思ったほうが理解しやすい。「関係」 を記述する やりかた として、以下の 2つの概念が使われている。

  (1) relation
  (2) relationship

 Relation は 「関係」 と訳されて、relationship は 「関連」 と訳されることが多い。Relation は、数学的には、「関数」 である。したがって、「モノ」 の並びが前提になる。いっぽう、「関連」 は、「モノ」 の並びを前提にはしていない。

 Relation を 「関数」 として考えれば、entity は、relation のなかで、変項として扱われる。言い換えれば、数学では、「モノ」 は、変項として認知される存在のことをいう。したがって、変項たる entity は、無定義語として扱われる。
 この やりかた の強みは、「構造」 を、生成規則 (構文論) に従って、矛盾を ふくまない公理系──言い換えれば、破綻しない・繰り返し使うことができる 「構造」──として作って、変項と (もし、変項が、現実的事実を対象にしているのならば、) 現実的事実との指示関係 (意味論) を、あとになって、検証すれば良い、という点にある (「F-真」 概念)。また、もう 1つの強みとして、変項が、現実的事実を指示しないとしても、「証明」 という手段を使って、「構造」 の無矛盾性を検証することができる、という点にある (「L-真」 概念)。この やりかた が、「モデル」 を作る やりかた である。

 コッド 関係 モデル は、以上の やりかた を使って作られている。そして、コッド 関係 モデル は、「完全性 (relational completeness)」 を証明されている。そして、小生が、「黒本」 を執筆する理由になったのが──正確に言えば、T字形 ER手法を作る理由になったのが──、実は、この「relation」 に対する戸惑──コッド 関係 モデル を、実地の システム 作りのなかに適用しにくいと感じていた戸惑い──である。小生は、「関係」 を 「関数」 として扱わないことを選んだ。「関数」 を使わないのであれば、「関数」 のなかで 変項 (無定義語) とされる entity を 「定義」 しなければならない。そのときに、ふたたび、identifier が論点になった。 □

 



[ 補遺 ] (2010年 4月 1日)

 Identifier は、拙著 「赤本」 以後──「赤本」 をふくめて──、「個体指定子」 という訳語 (言いかた) に収斂してきました。「個体指定子」 という語を使う前には、本文で述べたように、「認知番号」 という語を使っていました。「認知番号」 を 「個体指定子」 に変えた理由は、個体を管理するときに付与する コード が、かならずしも、「番号」 に限らないからです──たとえば、「商品略称」 は、個体を指示する コード として使われる場合があります { 商品略称、商品名称、・・・}。

 ただ、「認知番号」 のほうが、「個体指定子」 に比べて、語呂がいいので、いまでも、TM を セミナー で語るときに、ときどき、「認知番号」 を使っています。

 「個体指定子」 を論じるときに、つねに争点になるのが、「(値の) 一意性」 と 「(個体指定子の) 複合構成」 ですが、これらの点については、「赤本」 のなかで、それぞれ、独立した節を立てて論じたので、本 「補遺」 で述べるのは止めます。

 なお、「関係 (relation)」 と 「関連 (relationship)」 については、拙著 「赤本」まで──「赤本」 をふくめて──「関連」 のほうを使っていましたが、拙著 「いざない」 では、(「関連」 の使用を止めて、) 「関係」 を使うようになりました。

 当初、「関係 (relation)」 を使うことに対して抵抗があった理由は、「関係」 が、数学上、「関数」 として使われていて──直積集合の部分集合として使われていて──、それを データ 設計に対して厳正に適用することが強引すぎると私は思っていたからです [ ちなみに、コッド 関係 モデル は、「関数」 を使っています ]。Entity のなかには、「並び」 が構成上において重大な性質である モノ──TM で云う 「event」──と、「並び」 が構成上において争点にならない モノ──TM で云う 「resource」──がある、と私は判断していたので、ひとつの 「関数」 を、一律、entity に対して適用することを私は良しとしなかった。

 ただ、「いざない」 では、「関数」──特に、帰納的関数── を 再度 検討して、「ツォルン の補題」 を前提にして、「event」 に対して 「全順序」──ここでいう 「全順序」 とは、それぞれの項が線型順序 (「≦」) で並べられること──を適用して、「resource」 に対して 「半順序」──ここでいう 「半順序」 とは、線型順序にはならないけれど、なんらかの並べかたがあること──を適用して、構成上、「関数」 を併用すればいいというふうに私の考えを変えました。そのために、「いざない」 において──そして、「いざない」 を出版したあとで開催している セミナー において──私は、「関連 (リレーションシップ)」 を使うのを止めて、「関係 (リレーション)」 を使うようにしています。つまり、TM は、T字形 ER手法に比べて、用語上、以下の変更があった、ということ。

    identifier → 個体指定子

    関連 → 関係

 勿論、これらの用語変更は、単に用語を変えたのではなくて、考えかたが変化した、ということを注意していてください。





  << もどる HOME すすむ >>
  「T字形ER データベース設計技法」を読む