2006年 9月16日 応用編-16 Entity の擬態 >> 目次に もどる
2011年 8月16日 補遺  


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

  (1) Tentative Modeling (文法 [ 生成規則 ] に従って作成する)
  (2) Sementic Proofreading (意味 [ 指示規則 ] に従って推敲する)

 「黒本」 で示した 「分納 コード」 は、まず、TM の文法に従って作成すれば、以下のように、独立した entity として認知される。


 ┌─────────────────┐
 │       分 納      E│
 ├────────┬────────┤
 │分納コード   │数量      │
 │        │        │
 └────────┴────────┘

 
 そして、「受注」 との関連を示せば、以下の構成となる。


 ┌─────────────────┐      ┌───────────────────┐
 │       受 注      E│      │        分 納       E│
 ├────────┬────────┤      ├─────────┬─────────┤
 │受注コード   │受注日     │      │分納コード    │数量       │
 │        │受注数     ├┼───○<│受注コード(R) │         │
 │        │        │      │         │         │
 │        │        │      │         │         │
 │        │        │      │          │         │
 └────────┴────────┘      └─────────┴─────────┘

 
 以上が、Tentative Modeling として、文法に従って作成した TMD である。
 なお、リレーションシップ の 「ゼロ の cardinality」 は、「分納しないこともあり得る」 事態を示している。

 次に、Semantic Proofreading として、意味論 [ 指示規則 ] に従って TMD を推敲する。
 そして、そのときに、DA (Data Analyst) は、「分納」 の性質として──「event」 として認知されているにもかかわらず──、「日付」 が記述されていないことを意識していなければならない。

 もし、「分納日」 があれば、「受注日」 と 「分納日」 の関連 (並び) は以下のようになるはずである。

  (1) 受注日 > 分納日 [ これは成立しない。]
  (2) 受注日 = 分納日
  (3) 受注日 < 分納日

 それら [ (1) および (2) ] を検証すれば、実は、この事例において、分納日が記述されていなかった理由は、受注日と分納日が同じ日付であって、「分納日は、そもそも、存在しない」 ことが確認できる。すなわち、「分納は、『受注の明細』 として作用する」 ことが確認できる。言い換えれば、受注の 「HDR-DTL 構造」 なのである。ただし、分納が起こらないこともあるので、変則的な 「HDR-DTL 構造」 になる。
 「変則的な」 という意味は、「DTL (すなわち、分納) が 1件しかない」 という事態もある、ということである。


             ┌─────────────────┐
             │       受 注      E│
             ├────────┬────────┤
             │受注番号    │        │
             │        │        │
             │        │        │
             └────────┼────────┘
                      |
                      ×
                      |
          ┌───────────┴───────────┐
          |                       |
 ┌────────┴────────┐     ┌────────┴────────┐
 │      受注HDR      │     │      受注DTL      │
 ├────────┬────────┤     ├────────┬────────┤
 │受注番号    │受注日     │     │受注番号    │受注数     │
 │        │        ├┼───<│分納コード   │        │
 │        │        │     │        │        │
 │        │        │     │         │        │
 └────────┴────────┘     └────────┴────────┘

 
 「黒本」 の例では、後続 「event」 の 「請求」 は、もし、受注が分納形態であれば、受注 DTL ごとに請求することになっている。ただ、もし、「請求」 が指示する事実として、請求書は つねに一枚であれば、受注が分納される際には、かならず、受注 HDR を作成しているはずである。


             ┌─────────────────┐
             │       受 注      E│
             ├────────┬────────┤
             │受注番号    │        │
             │        │        │
             │        │        │
             └────────┼────────┘
                      |
                      ×
                      |
          ┌───────────┴───────────┐
          |                       |
 ┌────────┴────────┐     ┌────────┴────────┐
 │      受注HDR      │     │      受注DTL      │
 ├────────┬────────┤     ├────────┬────────┤
 │受注番号    │受注日     │     │受注番号    │受注数     │
 │        │        ├┼───<│分納コード   │        │
 │        │        │     │        │        │
 │        │        │     │         │        │
 └────────┼────────┘     └────────┴────────┘
          ┼
          |
          |
          ┼
 ┌────────┼────────┐
 │       請 求      E│
 ├────────┬────────┤
 │請求番号    │請求日     │
 │受注番号(R) │請求金額    │
 │        │        │
 └────────┴────────┘


 



[ 補遺 ] (2011年 8月16日)

 取り立てて補足説明はいらないでしょう。







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