（1） モノ の性質 f (x). （セット [ 集合 ] あるいはクラス）

　　（2） モノとモノとの関係 R (a, b)

　　（3） モノからモノをつくる関数 f (x, y)

　実務的には、R (a, b) は f (x, y) と同じであると考えてよいので、モデル （形式的構造） をつくるには次の二つの関数を使えばよいということです──

　　（1） f (x)

　　（2） f (x, y)

　f (x) は モノ を集める関数で、f (x, y) は モノ と モノ を並べる （関係を構成する） 関数です。
　前回 （3.4）、f (x, y) を使って、Event と Event の補集合を前提にして、「構造」 を構成する 「関係文法」 を四つ示しました。「関係文法」 は関数 f (x, y) を使っているので、モノ のそれぞれ二つの集まりのあいだの「構造」 をつくる技術は一般手続きとして定立されています。「構造」 をつくるうえで実務的に難しい点は、寧ろ どの モノ と どの モノ が関係があって、逆に どの モノ と どの モノ が関係がないか ということを 100% （すなわち、それら関係を一つの取りこぼしもなく） 捕捉できるかという点です。それらの関係のなかで一つでも漏れがあれば、F-真の 「構造」 にはならない （「完全性」を欠如します）。「『関係』 の網羅性」 を検証する手続きは、後述します （5.10 で説明します）。

　「関係」 が網羅されていれば、「構造」 は パーフェクト になります。すなわち、事業の文脈が完全に定立されます。言い替えれば、モノ の座標が定まります。したがって、文脈のなかで モノ の 「意味」 （meaning） が定まります。逆に言えば、モノ の 「意味」 というのは、文脈が定まらない限り わからない。

　全体の 「構造」 が定まれば、その 「構造」 のなかに置かれた モノ の 「意味」 を確認することができる。モノ は個体指定子を使って認知されます──実務では、個体指定子として××番号とか××コードを使っています。この個体指定子が、「情報」 （原帳票など） では 一つの管理対象 （モノ の集まり） を現していて、モデル （形式的構造） では 「集合」 f (x) を現しています。一つの管理対象 （モノ の集まり） が 形式上 正しい集合 f (x) になっていればいいのですが、正しい集合 f (x) になっていない場合が多い。つまり、我々が直感的につくった モノ の集まりが 「集合」 f (x) になっていないことが多い。実務では、一つの管理対象について、さらに細かく管理するために 「××区分 コード」 を使っています。この 「区分 コード」 は、形式上 分割・細分を現していて、一つの集合 f (x) について部分集合の存在を示しています。すなわち、「区分 コード」 が定義されていれば、一つの集合は いくつかの部分集合に切断されることを示しています。

　一つの集合 f (x) のなかの部分集合のあいだには、交わりはない──部分集合どうしは排他的 OR 関係です （AND 関係は生じない）。言い替えれば、部分集合の類別の仕方は一通りしかない （この点については、6.5 「セット と サブセット」 の証明を参照してください、本書 159ページ）。