2005年 3月 1日 VE のあいだに成立する関係 >> 目次 (テーマ ごと)
  ● QUESTION   VE のあいだにも、関係は成立するのではないか。
  ▼ ANSWER   成立する。ただし、VE のあいだでは、あくまで、「VE の VE」 として扱う。
2010年 3月16日 補遺  



[ データ 構造 ]

  証券{証券番号、証券契約日、・・・申込者氏名、申込者住所、・・・代理店名称、・・・}.

 
[ 事業の前提 ]

 (1) 申込者に対して、コード (申込者番号) を付与していない。
 (2) 証券は、本店が管理しているが、申込者を管轄しているのは代理店である。

 本店では、代理店に対して、代理店番号を付与しているが、ここでは、証券を資料として、T字形 ER図を作成するので、代理店番号を入手できていない、とする。
 また、証券番号の値は、すべての代理店を適用区域として、「一意」 である、とする。

 
[ 考えかた ]

1. VE の切り出し

 まず、証券を資料にして、命題論理方式を使って作図すれば、以下のような構造になる。

 __________________
  証券番号    |  証券契約日
            |    :
            |  申込者氏名
            |  申込者住所
            |    :
            |  代理店名称
            |    :

 
  証券契約 [ E ]
  {証券番号、証券契約日、・・・}.
   |   |
   |  証券. 申込者 [ VE ]
   |  {証券番号 (R)、申込者氏名、申込者住所、・・・}.
   |
  証券. 代理店 [ VE ]
  {証券番号 (R)、代理店名称・・・}.

 
 申込者と代理店は、それぞれ、(「event」 のなかに混入している 「resource」 として、) 「証券契約」 entity に対して、「みなし」 entity となる。ただし、「みなし」 entity のあいだでは、相関関係が考慮されていない。

 
2. VE のあいだの関係

 次に、リレーションシップ の検証表を使って、関係を検証する。

  証券 申込者 代理店
証券      
申込者 ○    
代理店 ○ ○  


 (注意)
  以下の点は、実際には事業過程のなかで成立しているが、いまは、考慮外とする。
  (1) すでに契約した証券を、新たな契約に切り替える。(証券の再帰)
  (2) 代理店のあいだでは、振り替えがある (代理店の再帰)

 さて、リレーションシップ の検証表を作成して、それぞれの entity (「みなし」 entity も対象として) のあいだに成立する関係を確認したら、代理店が申込者を管轄している事実がわかった、とする。
 とすれば、以下の構造として修正しなければならない。

  証券契約 [ E ]
  {証券番号、証券契約日、・・・}.
   |
  証券. 代理店 [ VE ]
  {証券番号 (R)、代理店名称・・・}.
   |
  証券. 申込者 [ VE ]
  {証券番号 (R)、申込者氏名、申込者住所、・・・}.

 
 もし、代理店番号を使うとすれば、以下の構造になる。

  証券契約 [ E ]
  {証券番号、代理店番号 (R)、証券契約日、・・・}.
   |   |
   |  証券. 申込者 [ VE ]
   |  {証券番号 (R)、代理店番号 (R)、申込者氏名、申込者住所、・・・}.
   |
  代理店 [ R ]
  {代理店番号、代理店名称・・・}.

 
 証券契約のなかの代理店番号(R)は、「証券. 申込者」 のほうに移される点に注意されたい。
 関数従属性から判断すれば (あるいは、「TM の体系」では)、以下の構造が良い。

  証券契約 [ E ]
  {証券番号、代理店番号 (R)、証券契約日、申込者氏名、申込者住所、・・・}.
   |
  代理店 [ R ]
  {代理店番号、代理店名称・・・}.

 
 では、どうして、わざわざ、VE を生成するのか、といえば、申込者という 「resource」 的性質に対して、注意を促すことが目的である。たとえば、申込者の誕生日を記録して、誕生日には、花を贈るとか、あるいは、年齢に相応する商品を提示するとか、さらには、申込者の家族構成を記録して、今後、ほかの商品 (たとえば、子息のために、学資保険とか) を提示できるようにするとか、申込者を「resource」 として捉えて、管理過程のなかで、管理対象とするのかどうか、という点を検討をする。つまり、申込者に対して、「resource」 としての コード 化を検討することを目的としている。

 「みなし」 entity は、「TM の体系」 のなかには入っていない。「TM の体系」とは切り離して、意味論を検討するために、「TM’の体系」 のなかで、扱われる。もし、申込者に対して、意味論的な検討が終われば──そして、「resource」 としての コード 化をしないのであれば──、実装形として、以下のように、VE を、もとの entity にもどしても良い。

  証券契約 [ E ]
  {証券番号、代理店番号 (R)、証券契約日、・・・}.
   |   ↑
   |  証券. 申込者 [ VE ]
   |  {証券番号 (R)、代理店番号 (R)、申込者氏名、申込者住所、・・・}.
   |
  代理店 [ R ]
  {代理店番号、代理店名称・・・}.

 
 ちなみに、申込者番号が付与されたとすれば、以下の構造になる。

  証券契約 [ E ]
  {証券番号、代理店番号 (R)、申込者番号 (R)、証券契約日、・・・}.
   |   |
   |  申込者 [ R ]
   |  {申込者番号、申込者氏名、申込者住所、・・・}.
   |   |
   |   ├ 代理店. 申込者. 対照表
   |   | {代理店番号 (R)、申込者番号 (R)}.
   |   |
  代理店 [ R ]
  {代理店番号、代理店名称・・・}.

 
 なお、この対照表は、「event」 ではなくて、「validation-rule」 を示す。

 



[ 補遺 ] (2010年 3月16日)

 本文で述べているように、VE (「みなし」 entity) は、TM の体系には入れていません。
 TM の体系は、以下のとおり。

  (1) 個体の認知 (個体指定子)
  (2) 並び (全順序と半順序、「event と resource」)
  (3) 関係の文法
  (4) 切断 (周延、セット と サブセット)
  (5) 多値 (多価関数、OR 関係と AND 関係)

 以上が TM の体系です。
 TM は、「event と resource」 という 「意味論的」 概念を導入していますが、それらは、関係において 「項の並び」 を意識しているので、構文論的性質が強い。言い換えれば、TM は、関数と集合を前提にした文法です。

 ただ、TM で構成した グラフ は、かならずしも、「完全性」──現実的事態と一致して 「真」 とされる状態──を実現している訳ではない点に注意してください。たとえば、TM を適用して構成した 「従業員」 entity では、以下の状態になっているでしょう。

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

 すなわち、「入社日」──「入社」 という事態を記述する項──が 「resource」 のなかに混ざった状態になっています。この 「入社日」 を 「resource」 から排除する文法は TM のなかにない。しかし、TM は、個体を 「event と resource」 に切断しているので、「event」 の性質が 「resource」 のなかに混ざっている状態は、「妥当な」 構造ではない。

 その状態を 「意味論的に」──現実的事態と対比して──修正するのが TM’ (「みなし」 概念) です [ 正確に言えば、「TM + 『みなし』 概念」 の体系が TM’ です ]。言い換えれば、構文論 (文法) の適用ではなくて、意味論の調整です。TM’ の 「みなし」 概念には、以下の 2つが用意されています。

  (1) みなし entity (Virtual Entity、VE)
  (2) みなし スーパーセット (class、クラス 概念)

 いずれの 「みなし」 概念も、TM の文法で構成された グラフ に対して適用するので、文法がない──「みなし」 概念には、TM で使われているような 「個体の認知」 「関係の文法」 がない。したがって、VE どうしのあいだでは、「event と resource」 に対して用意されている文法を適用しない [ 適用できない ]。VE どうしのあいだでは、本 エッセー で述べたように、「VE の VE」 を構成するのみです。





  << もどる HOME すすむ >>
  ▼ データ解析に関するFAQ