「中沢家」 の TMD （TM Diagram） を、前回から ひき続いて、推敲しました。
前回、「社内版」 に関して、以下を考えて、3つ以上の代替案を考える宿題を出しました。
（1） 「個体」 --たとえば、「図面」-- の性質として考える。
（2） 「関係」 のなかで--すなわち、バージョン 管理として--考える。
（2）-1. 社内版を主として、客先版を従として考える。
（2）-2. 社内版を従として、客先版を主として考える。
今回、宿題に対して、4つの案が提示されました。それらの案を検討しました （それぞれの TMD は、ここでは、省略します）。
4つの案のなかで、3つは、「客先版」 と 「社内版」 を 図面に対する サブセット --すなわち、「図面」 の性質--としていました。
TM の文法は、数学の 「解析」 を前提にして作られています。「解析」 とは、数学的な論法の一つであって、証明しなければならない対象 A が存在しているとき、A が成り立つためには、B1 が成り立たなければならないことを示し、さらに、B1 が成り立つためには、B2 が成り立たなければならないことを示すというふうに、以下のように、順次、対象を導出する手順です。
A → B1 → B2 → ... → Bn.
そして、A を、終いには、「既知の ことがら」 Bn に帰着する やりかた を 「解析」 と云います。この 「既知の ことがら」 （管理対象としての個体） が、TM では、「entity」 です--つまり、「事実的な F-真」 を示す （現実の事実を指示する） 物であったり、多くの人たちが 「合意している」 管理対象です。
TMD の作成は、「解析」 の逆を辿ります。すなわち、「既知の ことがら （entity）」 を起点にして、「構造」 を、順次、組んでいきます。したがって、「なんらかの 『構造』 を作るためには、その前に、どのような モノ （entity とか対照表とか） が存在していなければならないか」 を つねに考えるようにして下さい。
「客先版」 は、「取引先の図面」 に対して付与される番号です。そして、「図面」 が 「取引先用の」 図面であるか、それとも、「自作用の」 の図面であるかを判断するためには、「取引先」 が、まず、認知されていて、「取引先」 が提示した図面であることが判断されなければならない。「取引先」 が提示したのかどうかという判断するためには、なんらかの 「手続き （あるいは、事態）」 が先立っていなければならない。その 「手続き （あるいは、事態）」 が 「受注」 である--ちなみに、「受注」 は、TMD には記述されていなかった。
┌───────────────────┐
│ 受 注 Ｅ│
├─────────┬─────────┤
│受注番号 │受注日 │
│取引先コード（Ｒ）│ │
│ │ │
└─────────┴─────────┘
しかも、「客先版」 には、かならず、「社内版」 が対応 （「1-対-1」 対応 ?） します。
図番 001
┌────┬────┬────┬────┐
│ │ 事態 -1│ 事態- 2│ 事態 -3│
├────┼────┼────┼────┤
│ 客先版 │ 001 │ 002 │ 002 │
├────┼────┼────┼────┤
│ 社内版 │ 001 │ 002 │ 003 │
└────┴────┴────┴────┘
事態-3 が起こるかどうかは、ユーザ に確認して下さい。
「客先版」 と 「社内版」 は、排他的ではないので--同一の個体に対して、かならず、2つが組になって対応するので--、ひとつの認知番号に対して、客先版と社内版の サブセット にはならない。前回、「客先版」 を 「取引先. 図面. 対照表」 のなかの性質としていましたが、「社内版」 との対応を考慮して、「図面」 の VE としました。
4つの案のなかで 1つの案は、「客先版」 を resource としていましたが、resource として認知する （管理する） 積極的な理由はない。というのは、「客先版」 は、単独の個体指示子 （認知番号） として作用しない--同一個体の状態が推移するので、状態の推移を時系列のなかで並べる コードです。
以上の諸点を鑑みて、とりあえず、以下の 「構造」 として整えました。
┌───────────────────┐ ┌───────────────────┐
│ 受 注 Ｅ│ │ 製造手配 Ｅ│
├─────────┬─────────┤ ├─────────┬─────────┤
│受注番号 │受注日 │ │製番 │製造手配日 │
│取引先コード（Ｒ）│ │ │ │ │
│ │ │ │ │ │
└─────────┴─────────┘ └─────────┴─────────┘
∨
｜ ┌─────────────┐
┼ │ 図面. 客先版 ＶＥ│
┌──────┴──────┐ ┌─────────────┐ ├──────┬──────┤
│ 取引先 Ｒ│ │ 図 面 Ｒ├┼───○＜│図番（Ｒ） │客先版 │
├──────┬──────┤ ├──────┬──────│ ｜ ｜ ｜
│取引先コード│取引先名称 │ │図番 │品名 │ └──────┴──────┘
│ │ ├┼─○─＜｜ │ │
│ │ │ │ │ │ │ ┌─────────────┐
│ │ │ │ │ │ │ │ 図面. 社内版 ＶＥ│
│ │ │ │ │ │ ├┼────＜├──────┬──────┤
└──────┴──────┘ │ └──────┴──────┘ │図番（Ｒ） │社内版 │
│ ｜ ｜更新日 ｜
│ └──────┴──────┘
┌─────────┴─────────┐
│ 取引先. 図面. 対照表 │
├─────────┬─────────┤
│取引先コード（Ｒ）│ │
│図番（Ｒ） │ │
│ │ │
└─────────┴─────────┘
さて、この状態では、「図面 （の アトリビュート）」 は、最新の状態しか記録されないでしょうね。「図面 （の アトリビュート）」 の更新された状態も、すべて、記録するのならば、｛図番＋社内版｝ が ひとつの個体指示子として作用するので、以下の 「構造」 となるでしょう。
┌───────────────────┐ ┌───────────────────┐
│ 受 注 Ｅ│ │ 製造手配 Ｅ│
├─────────┬─────────┤ ├─────────┬─────────┤
│受注番号 │受注日 │ │製番 │製造手配日 │
│取引先コード（Ｒ）│ │ │ │ │
│ │ │ │ │ │
└─────────┴─────────┘ └─────────┴─────────┘
∨
｜
┼
┌──────┴──────┐ ┌─────────────┐
│ 取引先 Ｒ│ │ 図 面 Ｒ│
├──────┬──────┤ ├──────┬──────┤ ┌─────────────┐
│取引先コード│取引先名称 │ │図番 │品名 │ │ 図面. 更新日 ＶＥ│
│ │ ├┼─○─＜｜社内版 │ ├┼────┼┼──────┬──────┤
│ │ │ │ │ │ │ │図番（Ｒ） │更新日 │
│ │ │ │ │ │ │ ｜社内版（Ｒ）｜ ｜
│ │ │ │ │ │ │ └──────┴──────┘
└──────┴──────┘ │ └──────┴──────┘
│
│
┌─────────┴─────────┐
│ 取引先. 図面. 対照表 │
├─────────┬─────────┤
│取引先コード（Ｒ）│客先版 │
│図番（Ｒ） │ │
│社内版（Ｒ） │ │
└─────────┴─────────┘
「取引先. 図面. 対照表」 のなかに、「社内版」 が関与するので、「客先版」 を対照表のなかに もどしました。
さて、この時点で、以下の 2点を検討しなければならないでしょうね。
（1） 「客先版」 には、「更新日 （通知日）」 を記録するのか。
（2） 「受注」 は、かならず、「手配」 に先行するのか。
（1） は、「社内版」 には、「更新日 （作成日をふくむ）」 が記録されているが、「客先版」 には、「日付」 を記録するのかという点が検討されなければならない。もし、「通知日」 が記録されるのであれば、上述した 「構造」 は修正しなければならない--「通知日」 が記録されるかどうかは、「中沢家」 が次回までに確認することにしました。
（2） に関して、「受注」 は、基本的に、「手配」 に先立つが、「手配」 が 「受注」 の先立つこともあるとのこと。（2） の構造を宿題としました。
以上の検討の道筋は、tm-net に アップロード されている講義録を参照して下さい。