「関係の文法」 は、「resource が event に関与 （侵入、ingression） する」 という考えかたで組まれています。そして、ほかの関係 （「event」 どうしの関係、「resource」 どうしの関係、1つの 集合上の関係） も考慮して、1つの体系として まとめした。

　「関係の文法」 は、数学上の 「解析」 手順を守るように作られています。すなわち、（2007年 1月23日付、「反 コンピュータ 的断章」 のなかで述べたように、） 証明しなければならない対象 A が存在しているとき、A が成り立つためには、B₁ が成り立たなければならないことと示し、さらに、B₁ が成り立つためには、B₂ が成り立たなければならないことを示すというふうに、以下のように、順次、対象を導出する手順です。

　　　　　A → B₁ → B₂ → ... → B_n.

　そして、TM （Ｔ字形 ER手法） では、「既知の ことがら」 B_n として--すなわち、最小単位たる 「打ち止め」 として-- entity を考えています。

　この 「解析」 手順が、数学の公理系みたいな印象を与えているのかもしれないですが--たしかに、「関係の文法」 は、文法に従った導出手順を示しているので、1つの 「系」 と言えるかもしれないのですが--、「関係の文法」 が示している手順は、あくまで、「event」 の性質と 「resource」 の性質に従って、複文を いくつかの単文に分割・細分する手順であって、数学の公理系ではない。TM の 「関係の文法」 は、あくまで、作図の 「一般手続き」 を示したにすぎない。
　実地の作図では、「解析」 の逆になって、B_n → ... → B₁ → A というふうに組み立てます。B_n が entity で、A が 「情報 （画面、帳票など）」 です。

　システム が、個体と関係を使って作られる有機体であるならば、システムは、個体・関係の 「網羅性と無矛盾性」 を請け合っていなければならなはずです。そして、無矛盾性を請け合うのであれば、導出手順が示されていなければならないし、導出手順のなかに矛盾がないことを検証されていなければならないでしょう。

　数学的な モデル であれば、形式的体系 T （たとえば、「述語論理」） の加算 モデル が存在することを示せば良いのですが、われわれ システム・エンジニア が システム 化の対象にしている経営過程では、そういう 数学的 モデル は存在しない。でも、われわれが作る システム のなかで矛盾が起こってはならない--というのは、データ 演算のなかで矛盾が起これば、情報が適切に作成されていることを請け合うことができないから。無矛盾性に関して、われわれ システム・エンジニア が実現しなければならない点は、データ・モデル すなわち ｛データ、データ 演算、制約｝ の組のなかに矛盾が起こらないで、正しい データ が正しい前提で正しく演算されていることを検証する点にある。そのためには、データ が正しく導出されている手順を示さなければならない。TM では、それを示す手続きが、「関係の文法」 です--ただし、TM では、このほかにも、データ の正しさを検証するための手続きがあります （たとえば、「データ の周延」 や 「データ の多値」）。

　経営過程のなかで、「情報の『意味』」 が いかにして成立して、いかにして伝達されているかという点を解析するために、「関係の文法」 を私は作りました。

　
　（2007年 2月 8日）