|
2005年 5月 1日 |
基準編-3 identifier と entity |
|
|
2010年 4月 1日 補遺 |
|
|
|
Identifier
と
entity
に関して、小生は、訳語を悩んだ。「論考」
（2000年出版）
でも、identifier
と
entity
に関して、的確な訳語を思い浮かばなかったので、原語のまま、「identifier」
とか 「entity」
というふうに綴っている。Identifier
の訳語として、「識別子」
を使うつもりは、毛頭、なかった。小生が論点にしたかったのは、「認知のしかた」
であって、identifier
を、認知された個体に対する符丁として考えるのではなくて、認知行為のほうに視点を向けたかった。 「認知」 行為を重視した理由は、（Ｔ字形 ER手法が、当初、ウィトゲンシュタイン 氏の前期作 「論理哲学論考」──写像理論を提示した書物──を底本にして作られたけれど、 彼の後期作 「哲学探究」──「言語 ゲーム」 を提示した書物──を底本にするように、転回したかったので、） ゲーム に関与している人たちのあいだで成立している 「同意」 という行為を重視したかったから──この点に関しては、次回、「identifier と コード 体系」 のなかで、詳細に述べるので、これ以上に語ることを止める）。 Entity
も、非常に、むずかしい概念である。 1つの 「構造」 は、「モノ と関係」 を使って記述される──「モノ」 には、「作用 （事象）」 も ふくまれていて、「作用 （事象）」 が 「関係」 ということではない点に注意されたい。「関係」 は、モノ どうしが関与するしかたであると思ったほうが理解しやすい。「関係」 を記述する やりかた として、以下の 2つの概念が使われている。 （1）
relation Relation は 「関係」 と訳されて、relationship は 「関連」 と訳されることが多い。Relation は、数学的には、「関数」 である。したがって、「モノ」 の並びが前提になる。いっぽう、「関連」 は、「モノ」 の並びを前提にはしていない。 Relation
を
「関数」 として考えれば、entity
は、relation
のなかで、変項として扱われる。言い換えれば、数学では、「モノ」
は、変項として認知される存在のことをいう。したがって、変項たる
entity
は、無定義語として扱われる。 コッド 関係 モデル は、以上の やりかた を使って作られている。そして、コッド 関係 モデル は、「完全性 （relational completeness）」 を証明されている。そして、小生が、「黒本」 を執筆する理由になったのが──正確に言えば、Ｔ字形 ER手法を作る理由になったのが──、実は、この「relation」 に対する戸惑──コッド 関係 モデル を、実地の システム 作りのなかに適用しにくいと感じていた戸惑い──である。小生は、「関係」 を 「関数」 として扱わないことを選んだ。「関数」 を使わないのであれば、「関数」 のなかで 変項 （無定義語） とされる entity を 「定義」 しなければならない。そのときに、ふたたび、identifier が論点になった。 □
|
|
[ 補遺 ] （2010年 4月 1日） Identifier は、拙著 「赤本」 以後──「赤本」 をふくめて──、「個体指定子」 という訳語 （言いかた） に収斂してきました。「個体指定子」 という語を使う前には、本文で述べたように、「認知番号」 という語を使っていました。「認知番号」 を 「個体指定子」 に変えた理由は、個体を管理するときに付与する コード が、かならずしも、「番号」 に限らないからです──たとえば、「商品略称」 は、個体を指示する コード として使われる場合があります { 商品略称、商品名称、・・・}。 ただ、「認知番号」 のほうが、「個体指定子」 に比べて、語呂がいいので、いまでも、TM を セミナー で語るときに、ときどき、「認知番号」 を使っています。 「個体指定子」 を論じるときに、つねに争点になるのが、「（値の） 一意性」 と 「（個体指定子の） 複合構成」 ですが、これらの点については、「赤本」 のなかで、それぞれ、独立した節を立てて論じたので、本 「補遺」 で述べるのは止めます。 なお、「関係 （relation）」 と 「関連 （relationship）」 については、拙著 「赤本」まで──「赤本」 をふくめて──「関連」 のほうを使っていましたが、拙著 「いざない」 では、（「関連」 の使用を止めて、） 「関係」 を使うようになりました。 当初、「関係 （relation）」 を使うことに対して抵抗があった理由は、「関係」 が、数学上、「関数」 として使われていて──直積集合の部分集合として使われていて──、それを データ 設計に対して厳正に適用することが強引すぎると私は思っていたからです [ ちなみに、コッド 関係 モデル は、「関数」 を使っています ]。Entity のなかには、「並び」 が構成上において重大な性質である モノ──TM で云う 「event」──と、「並び」 が構成上において争点にならない モノ──TM で云う 「resource」──がある、と私は判断していたので、ひとつの 「関数」 を、一律、entity に対して適用することを私は良しとしなかった。 ただ、「いざない」 では、「関数」──特に、帰納的関数── を 再度 検討して、「ツォルン の補題」 を前提にして、「event」 に対して 「全順序」──ここでいう 「全順序」 とは、それぞれの項が線型順序 （「≦」） で並べられること──を適用して、「resource」 に対して 「半順序」──ここでいう 「半順序」 とは、線型順序にはならないけれど、なんらかの並べかたがあること──を適用して、構成上、「関数」 を併用すればいいというふうに私の考えを変えました。そのために、「いざない」 において──そして、「いざない」 を出版したあとで開催している セミナー において──私は、「関連 （リレーションシップ）」 を使うのを止めて、「関係 （リレーション）」 を使うようにしています。つまり、TM は、Ｔ字形 ER手法に比べて、用語上、以下の変更があった、ということ。 identifier → 個体指定子 関連 → 関係 勿論、これらの用語変更は、単に用語を変えたのではなくて、考えかたが変化した、ということを注意していてください。 |
|
|
|||
|
|
|||