「中沢家」 の TMD （TM Diagram） を、前回からひき続いて、推敲しました。
前回 (1月31日）、「R { メーカー、型式 } が R { 商品、図面 } に関与する」 という構成が妥当ではないのではないかという点が焙り出されました。この点に関して、今回、以下の resource 群の 「相性」 を検討しました。
（1） 取引先
（2） 図面
（3） 製番
（4） 客版
「製番」 は、事業過程・管理過程では、以下のように管理されていました。
（1） 「製番」 の性質 （アトリビュート） は記述されていない。
（2） 「製番」 は、「手配製番」 の意味である。
（3） 「手配製番」 は、内作・外注・調達のいずれにも付与される。
（3） 1つの 「製番」 は、複数の 「図面」 を束ねる。
（1つの 「製番」 は、1つ以上の 「図面」 に対して付与される。）
「図面」 は、事業過程・管理過程では、以下のように管理されていました。
（1） 1つの図面番号は、2つ以上の図面に対して付与されない。
（2） 「部品構成」 を記述する。
（3） どのように手配されたか （すなわち、「製番」） を確認できるようにしたい。
（4） 取引先ごとに「客版」 （バージョン） を管理したい。
以上の管理上の諸点を実現するために、当初作成された TMD では、「製番」 を resource として認知して、「製番」 と 「図面」 のあいだで対照表を作成して--「製番. 図面. 対照表」--、その対照表を起点にして、部品構成 （再帰表） を作成してありました--「 製番. 図面. 製番. 図面. 再帰表」。
以上の情報を前提にして、TMD を作成する際に、まず、考えなければならない点は、「手配」 と 「部品構成」 は、べつべつの事態 （現象） である、ということです。言い換えれば、「図面」 が、まず、存在して、次に、「図面」 （設計図） に指示されている物が、「手配」 される、ということです。したがって、そのように考えれば、「製番」 には、性質 （アトリビュート） が記述されていないので、「製番」 の性質として、「手配日」 を記録できるかどうかという点を ユーザ に確認しなければならない。[ 中沢さんによれば、「手配日」 を考えることはできる、とのことでした。]
「手配日」 を管理しているのであれば、「製番」 は、（resource ではなくて、） event です。
したがって、以下のように推敲しました。
┌─────────────────┐
│ 製 番 Ｅ│
├────────┬────────┤
│製番（手配） │ │
│ │ │
│ │ │
└────────┼────────┘
｜
×
↓
┌───────────┴───────────┐
｜ ｜
┌────────┴────────┐ ┌────────┴────────┐
│ 製番ＨＤＲ │ │ 製番ＤＴＬ │
├────────┬────────┤ ├────────┬────────┤
│製番 │手配日 │ │製番 │ │
│ │ ├┼───＜│図番（Ｒ） │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
└────────┴────────┘ └────────┴────────┘
┌─────────────────┐ ┌─────────────────┐
│ 図面 Ｒ│ │ 取引先 Ｒ│
├────────┬────────┤ ├────────┬────────┤
│図番 │ │ │取引先コード │ │
│ │ │＞─○─┼┤ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
└────────┴────────┘ │ └────────┴────────┘
│
│
┌───────────┴───────────┐
│ 図面. 取引先. 対照表 │
├───────────┬───────────┤
│取引先コード（Ｒ） │客版 │
│図番（Ｒ） │ │
│ │ │
└───────────┴───────────┘
以上が、「手配」 に関する構成です。
なお、部品構成は、「 製番. 図面. 製番. 図面. 再帰表」 として記述されていましたが、以下のように、推敲しました。
┌─────────────────┐ ┌─────────────────┐
│ 図 面 Ｒ│ │ 図面. 図面. 再帰表 │
├────────┬────────┤ ├────────┬────────┤
│図番 │ │ │図番（Ｒ） │ │
│ │ ├┼─○─＜│図番（Ｒ） │ │
│ │ │ │ │ │ │
│ │ ├──┘ │ │ │
│ │ │ │ │ │
└────────┴────────┘ └────────┴────────┘
次回も、resource を検討します。
なお、resource を検討する際、推敲の コツ として、以下の点に注意を払って下さい。
resource の性質が記述されていない （Ｔの字の右側が ブランク である）。
resource は、event に関与 （ingression、侵入） する個体ですから、resoruce は、管理対象として、単独で、そのもの-の性質を記録されていることが基本形です。
以上の検討の道筋は、tm-net に アップロード されている講義録を参照して下さい。