2009年 7月 1日 「技術編-31　みなし entity」 を読む >> 目次にもどる
2018年 4月15日 補遺 　


　

　TM では、entity は、以下のように定義されています。

　　entity である ＝ Df 個体指定子を付与された対象である。

　「みなし entity」 とは、個体指定子を付与されていないにもかかわらず、ひとつの個体としてみなされた対象を云います。前回述べたように、「みなし概念」 は、TM の文法のなかには入れていない──すなわち、「同意された語彙 → L-真の構成 → F-真の験証」 という手続きのなかで、文法に従って構成される個体ではないということ。したがって、「みなし entity」 に対しては、TM の文法を適用しない。「みなし entity」 は、「F-真」 の験証のなかで構成される概念です。

　上述したように、「みなし entity」 を構成する文法がないので──言い換えれば、文法に従って構成された個体に対して 「F-真」 を験証するときに、その個体に帰属しないと判断される性質を その個体から除去して ほかの entity として構成する概念なので──、個体の 「F-真」 を どのように 「解釈」 するかによって、「みなし entity」 は構成されることもあれば構成されないこともあります [ つまり、個体を 「解釈」 するひとの判断に依存します ]。たとえば、以下の例を考えてみましょう。

　（1) 「会社」 entity

　　{ 会社 コード、会社名称、資本金、・・・ }.

　「会社」 entity において、「資本金」 は 「会社」 に帰属する性質かどうか という点が争点になります。「会社」 を設立するためには 「資本金」 は a must なので、「資本金」 は 「会社」 に対する本質述定の一つであるという 「解釈」 もできますし、いっぽうで、多くの会社と取引している場合には、それぞれの会社に対する 「与信」 を判断する項目の一つであるとも 「解釈」 できます。もし、「与信」 の項目であると 「解釈」 すれば、以下のように、「みなし entity」 を構成するでしょう。

　（2） 「会社」 entity と、その 「みなし entity」

　　{ 会社 コード、会社名称、・・・ }. [ 会社 entity ]

　　{ 会社 コード （R)、資本金 }. [ 会社. 与信 ]

　では、（1） と （2） のどちらが 「正しい解釈」 なのか は、文脈 [ 構成全体 ] のなかでしか判断できないでしょう──言い換えれば、「会社」 そのものを対象にして判断できないということ。ことさように、「みなし entity」 を構成するのは難しい。逆に言えば、TMD を観るときに、「みなし entity」 を確認すれば、事業を どのように 「解釈」 しているか がわかるということ。TM を構文論の テクニック だとすれば、それを意味論的に整えること [ 意味論的な添削 ] が 「みなし概念」 であると云ってもいいでしょう。 □

　



[ 補遺 ] （2018年 4月15日）

　「みなし entity」 は クラス 概念である。そして、クラス f (x) を構成するための一般手続きはない。

　TM は、コッド 関係 モデル を基底にしているので、セット （集合） を前提にしている。しかし、多値関数の AND 関係 （TM でいう MA） は、セット で説明すれば合成関数であるが、クラス で説明すれば ファンクター （関数の クラス） である。そして、ファンクター として MA を説明したほうが簡単である [ セット と クラス は、実務的には──範囲が限定された領域では──同じと考えていいので、TM では多値関数を説明するときに セット を クラス に読み替えている ]。

　自由に構成できる クラス を TM では entity を構成する集まりとして使わない。言い換えれば、TM は次に示すように 「セット で作って、クラス で整える」 という体系になっている。

　（1） モノ の集まり （entity）
　（2）「関係」 と 「関数」
　（3）「関係」 文法
　（4） 集合 （セット）
　（5） 多値関数
　（6） クラス

　そして、T之字記法は、前回述べたように、左側が 「構造」 に関与して、右側は 「構造」 に関与することはない。右側は、次に示すように、あくまで、モノ の集まり （集合） を構成する条件を列挙している。

　┌─────────────────┐
　│　　　　　　　entity　　　　　　　│
　├────────┬────────┤
　│　並べる　　　　│　集める　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　└────────┴────────┘
　したがって、セット を構文論的に構成したあとで、意味論的に整えるために クラス を使う。すなわち、意味論的に──現実の事実と対比して──その セット を構成しないような条件を クラス を使って べつの集まりにする。そして、作った クラス の左側 （個体指定子） は、元の セット の個体指定子を継承する [ セット を意味論的に整えるために作った クラス は、派生元以外の セット とは関係をもたない ]。

　「みなし entity」 を導入した理由は、「resource のなかに混入している 『日付』 （event を構成する条件） を排除する」 ためです──たとえば、｛ 従業員番号、従業員名称、・・・、入社日、・・・｝ の 「入社日」 、「入社日」 は 「入社」 という event を構成するための条件であって、従業員を構成する条件ではない （「入社」 のあとで、「従業員」 となる）。構文論的には、従業員番号と入社日は、関数従属性において、1 対 1 なので、従業員 entity のなかに入社日があってもいいが、意味論的には── event （出来事） と resource （出来事に関与する モノ） という二つの概念を TM は前提にしているので、resource のなかに日付が存するのは矛盾になる。そのために クラス を使って、resource のなかの 「日付」 を排除する。

　では、TM が どうして event と resource という概念を導入したのか といえば、「関係」 と 「関数」 との対応性を判断して、全順序と半順序という 「並び」 を導入して、事業の構造を把握するためです──つまり、事業を プログラミング するために、事業構造を無矛盾な形式的構造に変換するためです。






　 << もどる HOME すすむ >>
　 目次にもどる