2007年 1月 1日 応用編-25、応用編-26 T字形 ER図の レビュー 手順 >> 目次に もどる
2011年12月 1日 補遺  


 TM (T字形 ER手法) は、以下の手順で作成される。

 (1) Tentative Modeling (構文論主体)
 (2) Semantic Proofread (意味論主体)

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

 

             ┌─────────────────┐
             │       顧 客      R│
             ├────────┬────────┤
             │顧客番号    │        │
             │        │        │
             │        │        │
             └────────┼────────┘
                      |
                      × null (電話番号)
                      |
          ┌───────────┴───────────┐
          |                       |
 ┌────────┴────────┐     ┌────────┴────────┐
 │     顧客(電話所有者)   │     │    顧客(電話非所有者)   │
 ├────────┬────────┤     ├────────┬────────┤
 │顧客番号    │顧客名称    │     │顧客番号    │顧客名称    │
 │        │電話番号    │     │        │        │
 │        │        │     │        │        │
 │        │        │     │        │        │
 │        │        │     │         │        │
 └────────┴────────┘     └────────┴────────┘

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

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

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

 (1) 個体の認知
 (2) 個体の性質
 (3) 関係の認知
 (4) 関係の性質

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



[ 補遺 ] (2011年12月 1日)

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







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