2006年 9月16日

応用編-16　Entity の擬態

>> 目次に もどる

2011年 8月16日 補遺

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

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

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

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

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

　┌─────────────────┐　　　　　　┌───────────────────┐
　│　　　　　　　受　注　　　　　　Ｅ│　　　　　　│　　　　　　　　分　納　　　　　　　Ｅ│
　├────────┬────────┤　　　　　　├─────────┬─────────┤
　│受注コード　　　│受注日　　　　　│　　　　　　│分納コード　　　　│数量　　　　　　　│
　│　　　　　　　　│受注数　　　　　├┼───○＜│受注コード（Ｒ）　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　　│　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　　│　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　　│　　  　　　　　　│　　　　　　　　　│
　└────────┴────────┘　　　　　　└─────────┴─────────┘

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

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

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

　　（1） 受注日 ＞ 分納日　[ これは成立しない。]
　　（2） 受注日 ＝ 分納日
　　（3） 受注日 ＜ 分納日

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

　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　　　　│　　　　　　　受　注　　　　　　Ｅ│
　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　　　　│受注番号　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　└────────┼────────┘
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　×
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　┌───────────┴───────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　｜
　┌────────┴────────┐　　　　　┌────────┴────────┐
　│　　　　　　受注ＨＤＲ　　　　　　│　　　　　│　　　　　　受注ＤＴＬ　　　　　　│
　├────────┬────────┤　　　　　├────────┬────────┤
　│受注番号　　　　│受注日　　　　　│　　　　　│受注番号　　　　│受注数　　　　　│
　│　　　　　　　　│　　　　　　　　├┼───＜│分納コード　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　　　　└────────┴────────┘

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

　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　　　　│　　　　　　　受　注　　　　　　Ｅ│
　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　　　　│受注番号　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　└────────┼────────┘
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　×
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　┌───────────┴───────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　｜
　┌────────┴────────┐　　　　　┌────────┴────────┐
　│　　　　　　受注ＨＤＲ　　　　　　│　　　　　│　　　　　　受注ＤＴＬ　　　　　　│
　├────────┬────────┤　　　　　├────────┬────────┤
　│受注番号　　　　│受注日　　　　　│　　　　　│受注番号　　　　│受注数　　　　　│
　│　　　　　　　　│　　　　　　　　├┼───＜│分納コード　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┼────────┘　　　　　└────────┴────────┘
　　　　　　　　　　┼
　　　　　　　　　　｜
　　　　　　　　　　｜
　　　　　　　　　　┼
　┌────────┼────────┐
　│　　　　　　　請　求　　　　　　Ｅ│
　├────────┬────────┤
　│請求番号　　　　│請求日　　　　　│
　│受注番号（Ｒ）　│請求金額　　　　│
　│　　　　　　　　│　　　　　　　　│
　└────────┴────────┘

[ 補遺 ] （2011年 8月16日）

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

<< もどる

HOME

すすむ >>

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