2001年 8月31日 「電話番号」 の扱い >> 目次 (テーマ ごと)
  ● QUESTION   電話番号は identifier か。
  ▼ ANSWER   電話番号は identifier になることもあれば、そうでないこともある。
2006年10月 1日 補遺  




1. 具体例 (その 1) (「電話番号」 が identifier である)

 ┌───────────────────────┐
 │          顧 客         R│
 ├───────────┬───────────┤
 │顧客番号       │顧客名称       │
 │           │           │
 └───────────┴───────────┘

 ┌───────────────────────┐
 │          電 話         R│
 ├───────────┬───────────┤
 │電話番号       │           │
 │           │           │
 └───────────┴───────────┘

 ┌───────────────────────┐
 │       顧客. 電話. 対照表       │
 ├───────────┬───────────┤
 │顧客番号(R)    │           │
 │電話番号(R)    │           │
 │           │           │
 └───────────┴───────────┘


[ 備考 ]

 「電話番号」 が identifier あれば、電話 は 「resource」 になるので、電話に帰属する「性質」を想像してみればよい。電話の性質としては、おそらく、トーン・ハ゜ルス とか、伝送速度が想像できる。また、「顧客. 電話. 対照表」 のなかには、「DATE」 を仮想することができるので、この対照表は 「event」 として機能する。とすれば、「DATE」 は、「 from」 と 「to」 の時刻を採取することができる。
 したがって、(電話番号を identifier として扱うのは) 「通信」 関係の経営組織体である。




2. 具体例 (その 2) (「電話番号」 が アトリヒ゛ュート である)

 ┌───────────────────────┐
 │          顧 客         R│
 ├───────────┬───────────┤
 │顧客番号       │顧客名称       │
 │           │電話番号       │
 │           │           │
 └───────────┴───────────┘

[ 備考 ]

 「電話番号」 が 「顧客」 entity の性質に帰属するのであれば、「顧客」 の テ゛ータ が成立するには、「電話」 が a must であることを表現している [ 電話番号には null 値がない、とことを示している ]。とすれば、たとえば、文房具店を想像するなら、電話をもっていない顧客には商品を販売しない、ということになる(?!)。一般 の営利企業が、そういう前提の ヒ゛シ゛ネス をしているとは想像できない。
 電話番号を アトリヒ゛ュート として扱うのは、(電話番号が a must になっている) クレシ゛ット (信販) 系の経営組織体であろう。




3. 具体例 (その 3) (「電話番号」 が VE である)

 ┌───────────────────────┐
 │          顧 客         R│
 ├───────────┬───────────┤
 │顧客番号       │顧客名称       │
 │           │           │
 └───────────┴───────────┘

 ┌───────────────────────┐
 │         顧客. 電話       VE│
 ├───────────┬───────────┤
 │顧客番号(R)    │電話番号       │
 │           │           │
 └───────────┴───────────┘



[ 備考 ]

 一般の営利企業は、電話を VE として扱うのが適切である 。
 ただし、「実装形」 は、VE の電話番号を、顧客のなかに戻して実装するかもしれない (厳密に言えば、実装形も、電話番号を VE として、顧客から切り離して実装するのが正しい)。



[ 補遺 ] (2006年10月 1日)

 TMD (TD Diagram、T字形 ER図) は、以下の 2段階を踏んで作成される。

 (1) Tentative Modeling (文法どおりに構造を作成する)
 (2) Semantic Proofreading (意味を確認しながら図を推敲する)

 Tentavie Modeling に従えば、「電話番号」 は、まず、以下のように構成される。


 ┌───────────────────────┐
 │          顧 客         R│
 ├───────────┬───────────┤
 │顧客番号       │顧客名称       │
 │           │           │
 └───────────┴───────────┘

 ┌───────────────────────┐
 │          電 話         R│
 ├───────────┬───────────┤
 │電話番号       │           │
 │           │           │
 └───────────┴───────────┘

 ┌───────────────────────┐
 │       顧客. 電話. 対照表       │
 ├───────────┬───────────┤
 │顧客番号(R)    │           │
 │電話番号(R)    │           │
 │           │           │
 └───────────┴───────────┘

 TMD を文法どおりに作図したあとで、Semantic Proofreading を実施する。そのときに、「電話番号」 の意味を検証して、単独の entity が妥当なのか、「顧客」 entity の性質になるのか、それとも、「顧客」 entity の VE になるのかを調べればよい。

 TMD を レビュー する際、「resource」 として記述されている entity の右側 (性質) が ブランク になっていれば、ことのほか、注意を払わなければならない。すなわち、「性質」 が記述されていなければ、「event」 とも 「resource」 とも判断できないはずなのだが、常識的な観点に立って、事物と事象を常識判断していれば、「resource」 が--「名称」 すら記述されていない状態で--いったい、どういう理由 (意味) で 「構造」 のなかに関与しているのかを丁寧に検討しなければならない。




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