（1） Event （出来事、行為、取引など）

　　（2） Event 以外の モノ。

　TM では、この類別 （範疇） の根拠として、関係 R を関数 f とみなして、関係の性質 （関係の対称性、関係の非対称性） を関数の項の並び （全順序、半順序） と対応して、「関係の非対称性」 をもつ モノ を全順序で並べられるとみなして Event とし、「関係の対称性」 をもつ モノ を半順序で並べられるとみなして Event の補集合 （Rerource） としています。全順序 （値の大小関係で並べられる） となる項には 「日付 （取引日）」 が特性となっています──すなわち、「日付」 が モノ の成立要件となる、ということ。その特性が成立要件ではない モノ は、Event の補集合です。

　TM の前身であるＴ字形ER法では、モノ の集まりを Entity と呼んで、Entity を Event と Resource の二つに分けていました──その分類は、外見上、TM と ほぼ同じです。しかし、その分類の根柢となる考えかたは、180度 違います。TM は 「関数」 を根柢に置いています、したがって 先ず Entity という語を使わないで 「項」 という語を使っています （実地の モデル 作成では、「項」 という言いかたをしないで、モノ と言っています）、そして （関係 R を関数 f とみなしているので） 分類の規準として全順序・半順序を使っていて、モノ を Event と その補集合としています （すなわち、Event の並びを 「運動 （あるいは、関係） の原因-結果 （言い替えれば、先行-後続）」 として捉えた関係主義に立っています。いっぽう、Ｔ字形ER法は実体主義的でした、そのために Ｔ字形ER法では、Resource を重視していました。しかし、TM では、Resource という語を なるべく使わないで 「Event の補集合」 としています。ただ、「関係」 文法を説明するときに、概念の正確さをたもつために、いちいち 「Event と、Event の補集合」 といえば かえって うっとうしいので、「Event と Resource」 というふうに単純に云っているだけです。Resource （Event の補集合） は、文法上では あくまで 「Event に関与する モノ」 としか扱っていない。

　「Event と、その補集合」 という分類は、事業分析・データ 設計では実地に使う モデル 技術として TM の最大の強みであると同時に純正な モデル 理論としては最大の弱点でもあります。というのは、R (Event, Resource) において、Event のなかに Event の補集合 （Resource） の個体指定子を挿入する （出来事に モノ [ 行為者 ] が関与する） ということを数学的には証明できないからです （自明のことであるとしか言いようがない）。全順序と半順序の並立は、悩ましい問題です。E.F. コッド 氏は、「関係」　(Relation） を直積集合 [ n-組、tuple ] として記述したのですが、実際の データ （名称、住所など） は全順序だけで並べることができないので、Relation の代わりに Relationship という日常語を使ってもいいと言ったのですが、同じ問題が （コッド の正規形よりも意味論的に階を一つ上げた） TM でも生じています。そして、TM は 個体指定子の 「関係」 文法 （二項関数を使った文法） なので、その問題は もっと顕著に現れています。私は、若い頃 （40歳代の頃） には、この問題を追究してみようと思ったのですが、哲学を そうとうに学習しなければならないので 私の力量では及ばないと判断して追究するのをやめました。そして、ウィトゲンシュタイン 氏の 「論理哲学論考」 の最初に宣言されている次の記述を R (Event, Resource) の説明として流用しました──