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




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

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

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

　┌───────────────────────┐
　│　　　　　　　顧客. 電話. 対照表　　　　　　　│
　├───────────┬───────────┤
　│顧客番号（Ｒ）　　　　│　　　　　　　　　　　│
　│電話番号（Ｒ）　　　　│　　　　　　　　　　　│
　│　　　　　　　　　　　│　　　　　　　　　　　│
　└───────────┴───────────┘

[ 備考 ]

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




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

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

[ 備考 ]

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




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

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

　┌───────────────────────┐
　│　　　　　　　　　顧客. 電話　　　　　　　ＶＥ│
　├───────────┬───────────┤
　│顧客番号（Ｒ）　　　　│電話番号　　　　　　　│
　│　　　　　　　　　　　│　　　　　　　　　　　│
　└───────────┴───────────┘

[ 備考 ]

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



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

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

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

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


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

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

　┌───────────────────────┐
　│　　　　　　　顧客. 電話. 対照表　　　　　　　│
　├───────────┬───────────┤
　│顧客番号（Ｒ）　　　　│　　　　　　　　　　　│
　│電話番号（Ｒ）　　　　│　　　　　　　　　　　│
　│　　　　　　　　　　　│　　　　　　　　　　　│
　└───────────┴───────────┘
　TMD を文法どおりに作図したあとで、Semantic Proofreading を実施する。そのときに、「電話番号」 の意味を検証して、単独の entity が妥当なのか、「顧客」 entity の性質になるのか、それとも、「顧客」 entity の VE になるのかを調べればよい。

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




　 << もどる HOME すすむ >>
　 データ解析に関するＦＡＱ