「モデ 家の TMD」 の 「event」 の構成を検討しました。
まず、「event」 の読みかたを説明しました。
それに関連して、TM の関係文法のなかで、「resource-対-resource」 の説明法を変えるかもしれないことを伝えました。
● TM の関係文法「resource-対-resource」
（1） 現時点では、「resource-対-resource」 の説明法は、「ZF の公理系」 の 「対の公理」
を使っています。
すなわち、ふたつの集合 （セット） [ たとえば、a および b ] を前提にして、和集合 { a, b }
の存在をみとめて、その和集合が f (x) という特徴があれば── TM では、「日付」 が
仮想できれば──、「event」 として認知する、としています。
（二項関係が三項態を作る、としています。）
（2） もうひとつの考えかたとして、R { s1, s2 } という二項述語を F { s1, s2, t (e) } というふう
に三項述語として考えても良いのではないかと思っています。今後、三項述語としての
扱いを検討してみます。
「event」 の読みかた および 「関係文法 R { s1, s2 }」 について、板書を参照してください。
● モデ 家の 「event」 構成
（1） まず、「event」 として同意されて認知されている entity を列挙します。
（2） 「event」 として認知されていないけれど、「日付」──現実的事態として記録された
「日付」──が、ほかにも存在するかどうかを確認します。「event」 として認知されて
いない 「日付」 を リスト します。
（3） 「event」 のあいだに存在している関係を記述します。
（3）-1 「納品」 と 「請求」 のあいだには、直接の関係がない点に注意して下さい。
（3）-2 「契約」 → 「受注」 → 「納品」 のあいだには、「1-対-1」 の関係があり、
「契約」 → 「請求」 のあいだには、「複数-対-1」 の関係になっている点に
注意していて下さい。
（3）-3 以上の関係を鑑みれば、「受注」 と 「請求」 とのあいだの整合性を実現する
ことが最大の配慮点になることを気づいて下さい。
（4） 「event」 あいだの写像関係 （対応関係） を記述します。
（5） 「event」 に対して、「resource」 の関与のしかたを確認します。
（5）-1 「契約」 には、以下の 3つの 「resource」 が関与している。
● 「取引先 コード」
● 「取引先種別 コード」 が関与している。
（どのような種別 コード をもつ取引先が関与するのかを確認する。）
● 「書名 コード」
（5）-2 「契約」 に関与している 「resource」 間には、なんらかの制約・束縛はあるか。
（「取引先. 取引先種別」 と 「書名」 には、なんらかの制約・束縛はあるか。）
（5）-3 「契約」 と 「resource」との写像関係を確認する。
● 「契約」 と 「取引先 コード」 は、「1-対-複数」 に対応する。
● 「契約」 と 「書名 コード」 は、「1-対-複数」 に対応する。
● 「取引先 コード」 と 「書名 コード」 は、「1-対-複数」 に対応する。
これらの関係が 「HDR-DTL」 構成になることを直ぐに気づいて下さい。
なお、「書名 コード」 は、前回までの分析では、「書籍」 「用品」 および 「雑誌」 という 3つの 「resource」 に分割・細分されましたが、今回の検討のなかで、「書籍」 「用品」 および 「雑誌」 は、ひとつの 「resource」（「書名」） として扱うほうが良いことが明らかになりました。
したがって、{ 書名 コード、商品区分 コード、・・・ } という構成に戻します。
以上の諸点は、板書を参照してください。
（6） 以上の検討点を TMD で構成しました。
TMD は、板書を参照してください。
ただし、「契約番号」 と 「取引先 コード」 のあいだには、「1-対-複数」 の対応関係が存在しているので、「取引先 コード」 は MAND として記述しなければならない。
TMD は、板書を参照してください。
この時点で、「契約番号」 と 「取引先 コード」 との 「1-対-複数」 関係は、実は、「1-対-1」 関係であることが確認されました。というのは、たとえ、「取引先」 が ふたつ存在しても、どちらかが 「サブ契約」 となるということを エンドユーザ （モデさん） が気づきました。「サブ 契約」 が、新しい契約番号として記録されるのか、それとも、同じ契約番号を使うのか──したがって、いずれの場合であれ、「再帰」 を考慮しなければならないのか──、という点を検討しようとした時点で、時間切れになりました。
● まとめ
（1） 上述した説明から判断できるように、「構成 （形式的構成）」 を検討するには、
entity そのものよりも 「（entity のあいだの） 関係」 を注視して下さい。
（2） 「構成」 では、つねに、「F-真」 を配慮して下さい。
文 p が 「真」 であるのは、時刻 t において、事態 q に対応するとき、そして、
そのときに限る。
「経済的実態を コンピュータ のなかに そのまま記述する」 という意味は、「F-真」 を実現した構成を作るということです。文法規則のない、そして、真・偽を問えないような、システム・エンジニア の憶測で作った構造を 「モデル」 とは言わない。