2007年 1月 1日

応用編-25、応用編-26　Ｔ字形 ER図の レビュー 手順

>> 目次に もどる

2011年12月 1日 補遺

　TM （Ｔ字形 ER手法） は、以下の手順で作成される。

　（1） Tentative Modeling （構文論主体）
　（2） Semantic Proofread （意味論主体）

　すなわち、まず、TM の文法 （生成規則） に従って 「構造」 を作って、次に、意味論 （指示規則） の観点に立って、「構造」 を推敲する。

　語-言語 （word-language） を使って記述された情報に対して、TM の文法を適用して 「構造」 を作れば、だれが 「構造」 を作成しても、ほぼ、同じ 「構造」 になる。しかし、その 「構造」 が、構文論的に妥当であっても、かならずしも、現実の事業を 「正確に」 に記述している訳ではない。たとえば、その ズレ を典型的に示す事態として、電話番号を考えてみる。

　TM の文法に従えば、電話番号は、認知番号を付与されている対象 （entity） として判断され、たとえば、「顧客」 との関係を考えれば、以下のような 「構造」 になる。

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

　構文論上、この 「構造」 は、妥当であるが、意味論上、以下の 2点を検討しなければならない。

　（1） 「電話」 の性質として、どのような属性が考えられるのか。
　　　（たとえば、トーン・パルス だとか伝送速度などが考えられる。）

　（2） 「電話. 顧客. 対照表」 は、どのような event を言及するのか。
　　　（たとえば、「日付」 として、「通話時刻」 を考えることができる。）

　したがって、上述した 「構造」 は、通信事業を営む企業体向けである。
　もし、そういう企業体でないのなら、「構造」 は、意味論的に訂正されなければならない。

　とすれば、電話番号を独立した entity として認知しないで、以下のように、「顧客」 に帰属する性質として （意味論的に） 修正できる。

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

　この 「構造」　は、電話番号が 「顧客」 の性質として a must であることを示している。すなわち、すべての 「顧客」 は [ ∀x P (x) ] 、電話番号を かならず もっていなければならない。逆に言えば、電話番号をもっていないひとは、「顧客」 として定義されない。こういう 「構造」 は、たぶん、クレジット 系の企業体向けか 宅配を営む企業体向けである （一般の企業体向けではない）。

　もし、「顧客」 が電話をもっていれば、なんらかの事態が起こったときに、連絡がしやすいくらいの意味で、電話番号を記録しているのなら--すなわち、電話番号が 「顧客」 の性質として、a must ではないなら--、意味論的に以下の 「構造」 にするのが真であろう。

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

　さて、以下の 「構造」 を考えることもできる。すなわち、電話番号を 「顧客」 に帰属する性質として考えて、さらに、電話番号の値が null になる--電話をもっていないひともいる [ ∃x P (x) ]--事態を 「形式的 サブセット」 として記述している 「構造」 である。

　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　　　　│　　　　　　　顧　客　　　　　　Ｒ│
　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　　　　│顧客番号　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　└────────┼────────┘
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　×　null （電話番号）
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　┌───────────┴───────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　｜
　┌────────┴────────┐　　　　　┌────────┴────────┐
　│　　　　　顧客（電話所有者）　　　│　　　　　│　　　　顧客（電話非所有者）　　　│
　├────────┬────────┤　　　　　├────────┬────────┤
　│顧客番号　　　　│顧客名称　　　　│　　　　　│顧客番号　　　　│顧客名称　　　　│
　│　　　　　　　　│電話番号　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　　　　└────────┴────────┘

　電話番号に関して、サブセット 構造と ＶＥ 構造と対比して、意味のちがいを言えますか。
　サブセット は、１つの セット （entity） のなかで、いくつかの部分集合を示します。したがって、「顧客」 の性質として電話番号は a must なのだけれど、なんらかの理由で、電話番号の値を定立できないときに、サブセット 構造を使います。
　いっぽう、ＶＥ 構造は、或る entity に帰属しない性質を記述するので、電話番号は、「顧客」 の性質として a must として考えられていない。

　Semantic Proofread では、推敲の しかた として 「一般手続き （アルゴリズム）」 を示すことができない。前述したように、Tentative Modeling のなかで、文法どおりに作成された 「構造」 に対して、「意味」 を確認しながら、丁寧に推敲する しかた しかない。それは当然のことであって、もし、Semantic Proofread にも、なんらかの 「一般手続き」 が成立するのなら、「構造」 を自動的に作ることができるということになって、オートマトン が 「構造」 を作れば良いことになってしまう。

　「黒本」 （応用編-25、応用編-26） で述べられている レビュー 手順は、あくまで、基本的な レビュー 項目を列挙しているにすぎない。「構造」 は、「個体と関係」 で作られるので、実地の レビュー では、構文論に従って作成された 「構造」 に対して、逐一、以下の点について確認します。

　（1） 個体の認知
　（2） 個体の性質
　（3） 関係の認知
　（4） 関係の性質

　それらは、文法に従って作られた 「妥当な構造」 があれば、検討しやすい。

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

　取り立てて補遺はいらないでしょう。

<< もどる

HOME

すすむ >>

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