2006年11月 1日

応用編-19　「みなし エンティティ」

>> 目次に もどる

2011年 10月 1日 補遺

　「みなし entity」 の技術は、「黒本」 以後も （「赤本」 に至るまで） 変わっていない。「みなし entity」 は、意味論上、導入された技術である。すなわち、1つの entity のなかに、ほかの entity の性質が混入していると判断されるなら、その性質を除去する--ほかの テーブル として生成する--技術である。以下を考えてみる。

　　｛従業員番号、従業員名称、...入社日、...｝.

　この データセット では、たとえば、コッド 関係 モデル の 「関数従属性」 を前提にすれば、入社日は、従業員番号 （primary-key） に対して、「1 対 1」 の関数従属性が認められるので、構文論上、妥当な構造である。そして、この構造を観れば、或る従業員は、或る日に入社したという 「意味」 を理解することもできる。

　セットを生成するために使った性質が、「モノ」 そのものに帰属する性質なのかどうか、という点は、集合論では論点にされない。関係主義の観点から言えば、「モノ」 は、「関係」 のなかで パラメータ （変項） として存在する個体である。したがって、数学的な構造のなかでは、上述の式は正しいが、たとえば、以下のような実体主義的な 「存在論」 を考えてみる。

　　（1） 状態--モノ そのものの性質 （第一性）
　　（2） 作用--事態のはじめと事態の終わりの間に生じる作用 （第二性）

　もし、そういう 「存在論」 を前提にすれば、入社日は、入社という作用に帰属する性質であって、従業員に帰属する性質ではないというふうに判断することもできる。もっと正確に言えば、或る個人が企業と雇用契約をむすんで、その企業に入社したというふうに判断することもできる。したがって、入社日は、個人と企業との関係 （入社） が起こった日として、入社に帰属する性質として記述できる。

　TM （Ｔ字形 ER法） は、entity を以下のように定義している。

　　　entity である ＝ _Df 認知番号が付与されている個体である。

　それを前提にすれば、従業員番号を認知番号にして、「従業員」 を認知できる。しかし、「入社日」 が帰属するはずの入社という事態を認知するための 「入社番号 （あるいは、入社 コード）」 は、たぶん、コード 体系のなかに定義されていない。したがって、「入社」 を認知することはできない。したがって、TM では、構文論上、コッド 関係 モデル と同じになる。
　ただ、意味論上、入社日が （前述したように、） 従業員に帰属する性質かどうか という点は debatable である。そのために、TM に対して、「意味論を強く適用した」 技術として、以下の 2点を追補した。

　　（1） みなし スーパーセット （概念的 スーパーセット）
　　（2） みなし entity

　TM に対して、この 2点を追補した体系を TM’ という。この 2点を増補した理由は、TM を （データ 設計法を超えて、） 企画・設計・製造が 1つの マスター・プラン を共有する concurrent engineering としたかったからである。すなわち、TM を 「現実の世界 （経営過程）」 を分析法として使い、かつ、データ 設計法としても使って、分析と設計のあいだに存在している 「溝」 を埋めたかったからである。

　TM では、entity は認知番号が付与されている個体として定義されているので、「入社日」 が帰属する 「入社」 を--もし、コード 体系上、入社番号 （あるいは、入社 コード） が定義されていないのなら--認知することができない。しかし、入社日は、「現実の世界 （経営過程）」 を記述する 「実体主義的な 『存在論』」 では、従業員に帰属する性質ではない。そのために、TM’ では、「みなし entity」 として、（「従業員番号」 を 「みなし認知番号」 として継承して、） 以下のような構造を作る。

　　｛従業員番号、従業員名称、...｝.　（「従業員」 を指示する）
　　｛従業員番号 (R)、入社日｝.　（「入社」 を指示する）

　「従業員番号 (R)」 は、個体指示子だから、TM では、従業員を指示する語であるが、TM’ では、「入社番号」 の代用として使われる。すなわち、TM’ では、「従業員番号 (R)」 は、「入社」 entity を生成するための認知番号の代用として使われ、｛従業員番号 (R)、入社日｝ は、（構文論上、entity ではないが、） 意味論上、entity と 「みなす」 。そのために、認知番号を付与されていない 「みなし entity」 とされる。

　「みなし entity」 は、実装上、派生元の entity にもどしても良いし--前述した 「従業員」 の データセット でいえば、｛従業員番号、従業員名称、...入社日｝ としても良いし--、べつべつにしたままでも良い--｛従業員番号、従業員名称、...｝ と ｛従業員番号 (R)、入社日｝ という 2つの データセット としても良い。ただし、製造段階で、「INDEX-only」 を使うのなら、べつべつに実装するほうが、それぞれの データセット に対して index-key を、多数、使えるので、パフォーマンス上、有利である。

[ 補遺 ] （2011年10月 1日）

　取り立てて補足説明は要らないでしょう。

　一つ補足する （あるいは、訂正する） ならば、文中、「TM （Ｔ字形 ER法）」 と綴られているのは便宜上そう綴っているのであって、TM と 「Ｔ字形 ER法」 は べつべつの技術体系です── TM は モデル 論に遵った技術体系ですが、「Ｔ字形 ER法」 は一つの技術体系ですが モデル 論の上で調 （ととの） えられた体系ではないことを注意書きしておきます。正確に綴れば、「TM （『Ｔ字形 ER法』 の改良版）」 とすべきでした、申し訳ない。

<< もどる

HOME

すすむ >>

「Ｔ字形ＥＲ データベース設計技法」を読む