● 事業の前提

---

　（1） ゼネコン のような施工を管理する システム である。
　（2） ある建物を複数の施工会社 （下請け） に発注する。
　（3） その施工会社は、更に下請けの施工会社（孫請け）に発注する。
　（4） 下請けと孫請けの関係は、専門領域などで、おおよそ決まっているが、
　　　　一定の ビジネス・ルール はない。したがって、再帰にはならない。

　コード 体系では、以下の番号がある。

　（1） 物件番号 （建物のこと）
　（2） 発注番号
　（3） 施行会社 コード

　

● データ 構造

---

　　┌───────┬─┐　　　　　┌───────┬─┐
　　│物件　　　　　│Ｒ│　　　　　│　　　発注    │Ｅ│
　　├────┬──┴─┤　　　　　├────┬──┴─┤
　　│物件番号│　　　　├＋───＜┤発注番号│日付　　│
　　│　　　　│　　　　│　　　　　│物件番号│　　　　│
　　│　　　　│　　　　│　　　　　│(R) 　　│　　　　│
　　└────┴────┘　　　　　└────┴────┘

　発注番号は物件番号といっしょになって意味のある番号となる。
　物件番号に対しての連番になっている。

　たとえば、物件番号が A001 であれば、発注番号は （01, 02, 03） となる。
　つまり、「物件番号 ＋ 発注番号」 が F-真 を示す。
　したがって、この事態に対して構造を与えようとしたときに、HDR-DTL を考えた。

　　　物件 [ R ]
　　　｛物件番号、・・・｝.

　　　施行会社 [ R ]
　　　｛施行会社 コード、・・・｝.

　　　発注 HDR [ E ]
　　　｛発注番号、物件番号 (R)、施行会社 コード (R)、・・・｝.

　　　発注 DTL [ E ]
　　　｛発注番号、明細番号、物件番号 (R)、施行会社 コード (R)、・・・｝.

　
　このような現象では、HDR も DTL も、それぞれ、物件と関係するのか。

　

● 考えかた （その１）──「物件」 を 「resource」 とする。

---

　この事象では、発注番号は、「区分コード （あるいは、種別 コード）」として使われているのではないでしょうか。すなわち、「事実上の発注」 は、「物件」 と 「施行会社」 の対照表 （event） であって、発注番号が区分 コード として使われているのではないでしょうか。

　　　物件 [ R ]
　　　｛物件番号、物件名称、・・・｝.

　　　施行会社 [ R ]
　　　｛施行会社 コード、会社名称、・・・｝.

　　　物件. 施行会社. 対照表 HDR
　　　｛物件番号 (R)、施行会社 コード (R)、発注番号、日付、・・・｝.

　　　物件. 施行会社. 対照表 DTL
　　　｛物件番号 (R)、施行会社 コード (R)、発注番号、・・・｝.

　
　こういう事象は、建設業では、典型的に観られる事象ですね。
　もし、HDR が JV （Joint Venture） であれば、以下のようになるでしょう。

　　　物件. 施行会社. 対照表 HDR
　　　｛物件番号 (R)、施行会社 コード (R)、日付、・・・｝.

　　　物件. 施行会社. 対照表 DTL
　　　｛物件番号 (R)、施行会社 コード (R)、発注番号、施行種別 コード、・・・｝.

　　　物件. 施行会社. 対照表 DTL.DTL
　　　｛物件番号 (R)、施行会社 コード (R)、発注番号、・・・｝.

　★ ただし、DTL の発注番号が、JV の施行種別 コード を兼用するかもしれない。

　

● 考えかた （その２）──「物件」 を 「event」 とする。

---

　もう１つの考えかたは、「物件」 を 「event」 とする 考えかたです。
　「物件」 は 「resource」 なのですが、現実的には、「event」 にしかなっていないと考えることもできます。

　　　施行会社 [ R ]
　　　｛施行会社 コード、会社名称、・・・｝.

　　　物件 HDR [ E ]
　　　｛物件番号、施行会社 コード (R)、発注番号、日付、・・・｝.

　　　物件 DTL [ E ]
　　　｛物件番号、施行会社 コード (R)、発注番号、・・・｝.

　　　物件 [ VE ]
　　　｛物件番号 (R)、物件名称、・・・｝.

　★ ただし、物件 VE は、物件 HDR から派生する。

　
　これとは反対の事象ですが、たとえば、契約番号 （event） が、そのまま、建物を示すこともあります。
　というのは、契約あるいは発注して建てた物件は、一回切りの事象であるという考えかたが根底にあるようです。

　もし、施行後の保守も担当しているのであれば、物件を 「resource」 として管理するのが妥当です。ただ、たとえ、物件を 「event」 として記録しても、「VE」 が quasi-resource を示しています。もし、施行しないけれど保守のみを担当しているのであれば、物件を 「resource」 として管理するでしょうね。