2006年11月16日 応用編-20 「みなし エンティティ」 の リレーションシップ >> 目次に もどる
2011年 10月16日 補遺  


 いま、「黒本」 を読み返してみて、以下の 2点が論点になると思う。

 (1) 「みなし エンティティ」 は、派生元以外に リレーションシップ と関与しない。
 (2) 「みなし エンティティ」 にも、resource と event を導入して、関係文法を適用するか思案中である。

 「みなし エンティティ」 (以下、VE と略称) は、或る個体の性質なかに、ほかの個体の性質が混入しているときに生成される。そして、個体とは、TM (T字形 ER手法) では、以下のように定義されている。

   個体 (entity) である = Df 認知番号を付与されている対象である。

 そして、個体は、event と resource という 2つの クラス に細分される。

   event である = Df 性質として 「日付」 が帰属する。

   resource である = Df event 以外の entity である。

 
 たとえば、以下を考えてみる。

 {従業員番号、従業員名称、... 入社日}.

 TM の定義では、「入社日」 は 「入社」 という event に帰属する性質とされ、「従業員」 の resource には帰属しないとされる。ただ、「入社」 に対して認知番号が付与されていないので、「入社」 は、「従業員」 に対する VE として記述される。

 {従業員番号、従業員名称、...}.
 {従業員番号 (R)、入社日}.

 さて、企業 (会社 コード を認知番号とする entity、法的実体) では、資本金は帰属する性質なのかどうかという点を考えてみる。「常識的に考えれば」、法的実体である企業は資本金がなければ成立しないので、資本金は企業に帰属する性質であると判断できる。しかし、資本金をはじめとする 「財務情報 (与信判断)」 を企業の VE として扱うこともできる。あるいは、資本金は、発起人と株主とのあいだ (関係) のなかで成立する投下資金として考えることもできる。

 個体 「そのもの-の」 性質かどうか、あるいは、個体が ほかの個体 「に-対して」 作用したときの性質かどうか を判断することは、ことさように 難しい。そのために、性質 (個体に帰属する性質および VE として扱う性質) を生成するための 「一般手続き (文法)」 を私 (佐藤正美) は示すことができなかった。個体 「そのもの-の」 性質かどうかは、とりあえず、語-言語の使いかたを参考して判断するしかなかった。たとえば、「入社日」 は、形態素 (語構成) として、「入社. 日」 というふうに考えて、「入社」 に帰属する性質とする、と。そして、いっぽうで、個体が正規形になっているかどうかは、「S-P (主語-述語)」 を単位にして、1つの主語 (認知番号) に対して、述語 (性質) が 「1-対-1」 の関数従属性を実現している連言式になっていなければならない、と。

 言い換えれば、1つの認知番号に対して、性質 (述語) が 「1-対-1」 の関数従属性を示しても、その個体 「そのもの-の」 性質として帰属しないなら──「語-構成」 上、その個体とちがう定義域を走る値として判断されるなら──、VE として扱う。
 したがって、TM では、個体は、認知番号を起点にして、命題論理の 「S-P」 形式として生成されるが、VE は、どちからと言えば、述語論理と集合論を前提にして生成される。そして、集合論では、集合を作るために使われた述語 (性質) が、個体 「そのもの-の」 性質かどうかは検討対象とされない。

 VE の妥当性は、意味論上、指示規則のなかで判断するしかない。すなわち、{従業員番号 (R)、入社日} は、(合意して指示できる認知番号を付与されていないけれど、) 「入社」 という event を 「言及する」 というふうに判断できる。VE が、event あるいは resource を言及するのであれば、VE に対して、関係文法を適用しても良いのではないかとも思われる。しかし、そう単純にはいかない。1つの resource のなかに、ほかの resource が混入している現象として、以下を考えてみる。

 {地域 コード、地域名称、...}.
 {取引先 コード、取引先名称、...}.
 {地域 コード (R)、取引先 コード (R)}.

 取引先には、出荷先と納入先という 2つの 「意味」 が使われているとする--たとえば、取引先 コード の値のなかで、S が使われていれば出荷先で、D が使われていれば納入先とする。
 そして、取引先の 「意味」 を判断して、出荷先が多数であって、納入先は少数の例外であるとする。こういう現象に対して、「ひょっとしたら」、VE を使うかもしれない--「ひょっとしたら」 と綴ったように、VE を使ってはいけないのだが (理由は後述する)。

 {地域 コード、地域名称、...}.
 {取引先 コード、取引先名称、...}. [ 出荷先を示す ]
 {取引先 コード (R)、取引先名称、...}. [ 納入先を示す ]
 {地域 コード (R)、取引先 コード (R)}.

 さて、VE (納入先) にも、resource の文法を適用すれば、以下の構成となる。

 {地域 コード、地域名称、...}.
 {取引先 コード、取引先名称、...}. [ 出荷先を示す ]
 {取引先 コード (R)、取引先名称、...}. [ 納入先を示す ]
 {地域 コード (R)、取引先 コード (R)}. [ 出荷先が担当している地域を示す ]
 {地域 コード (R)、取引先 コード (R)}. [ 納入先が担当している地域を示す ]

 再度、以下を考えてみる。

 {地域 コード、地域名称、...}.
 {取引先 コード、取引先名称、...}.
 {地域 コード (R)、取引先 コード (R)}.

 そして、取引先と対照表に対して、それぞれ、VE (納入先) を作る。

 {地域 コード、地域名称、...}.
 {取引先 コード、取引先名称、...}. [ 出荷先を示す ]
 {取引先 コード (R)、取引先名称、...}. [ 納入先を示す ]
 {地域 コード (R)、取引先 コード (R)}. [ 出荷先が担当している地域を示す ]
 {地域 コード (R)、取引先 コード (R)}. [ 納入先が担当している地域を示す ]

 この構成は、取引先の VE (納入先) に対して、resource の文法を適用した構成と同じになる。
 すなわち、VE は、あくまで、構成に対して、意味論上、「事後認知」 にすぎない。

 ほかにも、以下を考えてみる。

 {地域 コード、地域名称、...}.
 {取引先 コード、取引先名称、...}. [ 出荷先を示す ]
 {取引先 コード (R)、取引先名称、...}. [ 納入先を示す ]
 {地域 コード (R)、取引先 コード (R)}. [ 出荷先が担当している地域を示す ]
 {地域 コード (R)、取引先 コード (R)}. [ 納入先が担当している地域を示す ]
 {請求書番号、取引先 コード (R)、請求日、...}. [ 納入先に送る ]
 {支払伝票番号、取引先 コード (R)、支払日、...}. [ 請求先から送られる ]

 請求書番号に関与した取引先 コード (R) は、取引先 の VE (納入先) であるとする。たとえ、そうだとしても、取引先 の resource が請求書に関与すれば、(請求書を送る宛先としての) 取引先の 「意味」 は 「納入先」 として 「解釈」 されるはずである。したがって、以下の構成でよい。

 {地域 コード、地域名称、...}.
 {取引先 コード、取引先名称、...}.
 {地域 コード (R)、取引先 コード (R)}.
 {請求書番号、取引先 コード (R)、請求日、...}.
 {支払伝票番号、取引先 コード (R)、支払日、...}.

 TM は、まず、意味論上、指示規則を使って、個体が認知される。次に、認知された個体を起点にして、構文論上、関係文法を使って、構成を作る。ただ、意味論 (指示規則) を前提にして個体を定義しているので──event の性質として、「日付」 が帰属するという定義を導入しているので──、resource 的性質と event 的性質が混入している状態は、定義に反する。たとえば、その典型的な事態として、{従業員番号、従業員名称、... 入社日...} を示すことができる。定義に反しないように、entity を整えるために導入された手段が VE であって、VE は個体を認知するための手段として導入された訳ではない。したがって、「個体を認知するために導入された訳ではない」 VE に対して関係文法を適用することは妥当ではない。

 ちなみに、認知番号に付与される値を判断して--たとえば、取引先 コード の値のなかで、S が使われていれば出荷先で、D が使われていれば納入先とするように--、VE を作ることは、TM の文法にはない。この点に関しては、以下の 2つの エッセー を参照されたい。

 (1) 101 ページ (形式的 サブセット 化と実質的 サブセット 化)

 (2) 325 ページ (バリデーション・ルール の対照表)

 



[ 補遺 ] (2011年10月16日)

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







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