● 提示されたテーマは ...
今回は、前回に続いて、「本番システム」 （S さん作成） のデータ構図を検討しました。
今回も、「本番システム」 の情報を対象とするので、このホームページのような 「公」 の場--だれでもが、目にすることができる場--では、作図されたデータ構造に対する 「読みかた」 を、すべて、記載しません。
さらに、今回は、S さんが、（前回の検討を踏まえて、） 丁寧に分析してきたので、（前回と比べて、見違えるほどに、） 的確な構造を作っていました。
（１） 「Event」 に関しては、
ほとんど、添削しなくてよい状態にまで、的確に記述されていました。
（２） 「Resource （および、対照表）」 に関しては、
「価格設定」 の構成に対して、いくつか、添削が入りました。
（２） に関しては、事業の 「からくり」 が、一目でわかる構造になっていて、ここでは公表しないので、会員の皆さんは、「レビュー （質疑） のやりとり」 と 「どのように添削したのか」 という過程を、tm-net にて、確認してください。
S さんは、今回のレビューのなかで、作成 （構文論的な tentative-modeling） と 推敲 （意味論的な proofreading） の やりかた を習得しました。それらの技術を 「鈍らない」 ようにするために、「日々の練習」 を続けてください。「情報 （画面、レポートなど）」 を、まいにち、１つずつで良いから、材料にして、--運動選手が、まいにち、基礎訓練をするように、-- 技術の 「素振り」 を続けてください。そうすれば、「情報 （あるいは、データ）」 を観て、事業の からくり を的確に読み取る技術は、きっと、a second nature になるでしょう。
ほかの人が作成したＴ字形ＥＲ図を推敲するときには、かならず、まず、以下の点を確認してください。
ＴＭの文法どおりに記述していなければ、推敲しない。
もし、ＴＭの文法を破って記述されているなら、まず、文法に従って記述するように、作成し直してください。というのは、もし、文法を破って記述されたら、「事業を読む」 ことができなくなってしまうから。
さて、今回は、S さんが、見事に的確な構造を作ってきたので、標準形として （ＦＡＱとして）、検討すべき点がない。事業の観点から言えば、以下の２点を論点にしたいのですが、きわめて、「classified」 情報になるので、今回、ここでは意見を述べないことにします。
（１） 「発注 --> 契約 --> 入金」 の構造
（２） 「価格設定」 の構造
S さんが再作成したＴ字形ＥＲ図を、推敲する前に、一目したら、（良い 「でき」 なので、） 推敲が、ほとんど、入らないことを推測できたので、推敲に入る前に、「余談」 として、以下の２点を語りました。
（１） 「集合オブジェクト」 と 「組オブジェクト」
（２） ISO/IRDS の 「からくり」
● 「集合オブジェクト」 と 「組オブジェクト」 ...
会員には、事前に、ぼくのホームページのエッセー（来る７月１日に掲載する「ベーシックス」） を回覧しましたが、ＴＭ を、オブジェクト指向の観点から、どのように理解すればよいか、という点を語りました。
コッド関係モデルの正規形は、原子的値の定義域である。そして、正規形を、コッド氏が示した３ＮＦをはじめとして、Boyce-Codd 正規形、（ファギン氏が示した） 第４正規形--多値従属性--および（ウルマン氏が示した） 第５正規形--多値結合正規形--の考えかたを、簡単なまとめでしたが、示しました。
それらの正規形の観点からすれば、ＴＭの対照表は、「非正規形」となる。
しかし、いっぽうで、コッド関係モデルを前提にした正規形では、「集合を組とするオブジェクト」を記述することができない。たとえば、「再帰（自己言及型）」を示しました。「再帰」（複合定義域） として、（部品番号（Ｒ）、部品番号（Ｒ）、数量）の構造は、属性値を記述するにしても、（部品番号（Ｒ）、部品番号（Ｒ））の自己言及を、正規形として認める訳にはいかない。これは、あきらかに、「部品構成表」を「モノ」（Ｆ-真）として考えて、それを２項関係として記述した構成です。すなわち、「集合を組とするオブジェクト」を考えています。
さて、「集合を組とするオブジェクト」 を、丁寧に定義するならば、以下のように再帰的に定義できます
（１） Ｓ１、Ｓ２、...、Ｓｎをオブジェクト （あるいは、セットのメンバー） とする。
（２） オブジェクトの並びを論点にすれば、
（Ｓ１、Ｓ２、...、Ｓｎ）は、「組オブジェクト」である。
（３） オブジェクトの並びを論点にしないなら、
｛Ｓ１、Ｓ２、...、Ｓｎ｝は、「集合オブジェクト」である。
さて、以下の対照表を考えてみます。
従業員
｛従業員番号、従業員名称、...｝.
部門
｛部門コード、部門名称、...｝.
部門. 従業員. 対照表
｛部門コード（Ｒ）、従業員番号（Ｒ）｝.
この対照表は、「集合オブジェクト」（「配属」という「Ｆ-真」）です。
以下の対応表を考えてみます。
受注
｛受注番号、受注日、...｝.
請求
｛請求番号、請求日、...｝.
受注. 請求. 対応表
｛受注番号（Ｒ）、請求番号（Ｒ）｝. <-- 正確には、（受注番号（Ｒ）、請求番号（Ｒ））.
対応表は、「組オブジェクト」です （onto-mapping のリストです）。
再帰表も、「組オブジェクト」です （部品表を、２項関係として記述した構成表です）。
ＴＭ（および、ＴＭ’）では、（entity 以外のテーブルとして、）「...表」というふうに記述されているデータ定義域は、「集合オブジェクト」か「組オブジェクト」である。だから、ＴＭでは、単純定義域としての entity と、ＴＭの文法に従って導出される複合定義域を切り離して、複合定義域には、「...表」という言いかたを使っている点に注意されたい。
● ISO/IRDS の構造 ...
ISO/IRDS の考えかたが、どのようになっているのか、という点を、（DOA+コンソーシアム bun01 でおこなわれた、堀内氏・岡部氏・大林氏 のフ゜レセ゛ンテーションを聴いて、） ぼくが まとめた note を、メールにて、ＴＭの会員に回覧しました。
ぼくの まとめた中身を、さらに、わかりやすいように、単純にすれば、以下のように考えてよいでしょう。
モデルは、以下のように、語彙と文法を前提にして構成される。
（１） 語彙
（１）-１ 論理学の語彙 （たとえば、AND、OR、IF、クラス概念など）
（１）-２ 観察述語 （事業のなかで使われている語彙）
（２） 文法 （たとえば、PM の公理系など）
ISO/IRDS は、（１）-２ を 「Ontology （Reference Ontology）」 として考えている。
そして、（２） を、「abstract syntax」 として考えている。
以上を前提にして、MMF （Meta Model Facility） が、メタ・モデルを生成する。
したがって、ISO/IRDS は、きわめて、妥当な構造となっています。
ただ、個人的に言えば、ぼくは、語彙を記述する際、Backus-Naur Form を使うことに対して、抵抗を覚えます。その理由を、ぼくの「論考」 173ページを読んだことのある TM会員は理解できるでしょう。