「モデ 家」 の アトリビュート・リスト （「契約」 に関する アトリビュート） を検討しました。
● 「ツォルン の補題」
（1） 任意の半順序集合は、極大な部分順序集合をもつ。
（2） 「全順序」 と 「半順序」 のあいだに、いかなる 「関数 （写像）」 を考えることができるか。
→ 板書写真 （1）
● 請求書発送日
TMD の 全体図 レビュー は一挙に （一度で） 終了することができないので、部分的に おこなわざるを得ない。そこで、2回目以後 （途中から はじめる場合に）、その日の起点 （レビュー 対象） となる 「箱」 を確認して レビュー を はじめます。そのときに、「かならず」、その 「箱」 と他の 「箱」 とのあいだに存在する 「関係」 を最初に確認すること。すなわち、
「箱」 ではない、「線」 を観よ （！）
この ことば の意味は、R (a, b) という構成式そのものを示していて、「文脈」 のなかで意味を考えなさい、ということ。
さて、きょうは、「請求書発送日」 から レビュー を はじめました。「請求書発送日」 は、以下の状態で存在しています。
（1） 「契約」 に対する VE 「印税前払請求」 に帰属する性質である。
（2） 「請求書」 および 「発送日」 という ふたつの概念で構成されている。
そこで、（1） の文脈のなかで、「請求書発送日」 は、「契約年月日」 のなかで束縛変数になっている点に注意すること。すなわち、
{ 契約年月日 {... 請求書発送日 }}.
したがって、「全順序」 のなかで、「＜ （小さい）、＝ （同じ）、＞ （大きい）」 を問うこと。
次に、（2） として、請求書との関係を確認しなければならない。請求書には、「計上日」 が存在しています。したがって、「発送日」 と 「計上日」 との関係を確認しなければならない。なお、以下の文のなかで、T は 「存在する」、F は 「存在しない」 ことを示します。
{ 請求書発送日、計上日 } ＝ { (T, T), (T, F), (F, T), (F, F) }.
「発送日」 と 「計上日」 は、（ユーザ [ モデ さん ] に確認したら、） 「排他的」 であるとのこと。すなわち、「請求書」 として計上される対象のなかに、印税前払費用は算入されないし、その逆も真。そこで、以下の点を確認しなければならない。
(T, T) が生じない、言い換えれば、(T, F) あるいは (F, T) のいずれであるか
とするには、どのような判断 [ アルゴリズム ] が適用されるのか。
→ 板書写真 （2）
● アドバンスト 料 (D)、今回請求額
アドバンスト 料は、前回 レビュー した アトリビュート です。VE 「契約. 印税前払費用」 のなかに、アドバンスト 料の導出項目が存在しています。まず、この点 [ アドバンスト 料 (D) ] の意味を確認します。この導出項目は、アドバンスト 料の 「複写」 である、とのこと。そして、アドバンスト 料 (D) は、「今回請求額」 に対して 「制約・束縛」 として作用しています。すなわち、「今回請求額」 の合計 （sum） は、アドバンスト 料と同じになる、とのこと。
さて、ここで争点になるのは、「アドバンスト 料」 と 「アドバンスト 料 (D)」 が、「つねに同じである」 ということを確約できるかどうかという点です。すなわち、以下の現象が絶対に生じないことを ユーザ に対して、つねに確約しなければならない。
アドバンスト 料 （100）、アドバンスト 料 (D) （98）、今回請求額 （25, 30, 45）
アドバンスト 料 (D) は、アドバンスト 料の単純な複写だから プログラム 上で間違うはずがないと想像できるのですが、こういう 「余計な」 確約──実際に存在しない制約・束縛──を請け合うのは避けるべきです。したがって、アトリビュート・リスト を作成したら、アドバンスト 料 (D) は排除してください。
なお、「表」 形式において、導出項目を 「実装したほうがいい」 例を示しました──「縦列」 で実装するか、「横列」 で実装するか、それぞれの例を示しました。
→ 板書写真 （3）