TM （および、TM'） は、「データ 設計、事業解析および （プログラム の） ソース・コード I/O 化を同時に実現する」 ことを目的としているが、計算構造としては、以下の概念・アルゴリズム を前提にして作られている。

　（1） セット 概念
　（2） 第一階の述語論理

　すなわち、計算構造としては、コッド 関係 モデル と同じ前提に立っている。
　したがって、計算構造として、「集合の集合 （関数の関数）」 を導入していない。

　TMD （TM Diagram） を実装形として整える際、「抽象 データ 型」 の オブジェクト を作ることはできる。すなわち、TMD の entity および アトリビュート に対して、アトリビュート・リスト に記載されている 「前提 （baseline）」 や 「計算式 （導出規則）」 を カプセル 化することはできる。さらに、(R) を──TM では、参照 キー として考えないで、導出規則 （TM の関係文法） のなかで導入された 「Re-used」 の意味で使っているが──参照 キー として実装することもできる。そして、いくつかの entity を join して、「現実世界の事物」 を構成する際、「現実世界の事物」 を写像する 単位 （複数の entity を join した単位） を 1つの オブジェクト として考えることもできる。
　たとえば、以下を考えてみる。

　　｛著作番号、著作名称、・・・｝.
　　｛著作番号 (R)、出版日｝.
　　｛著者番号、著者名称、・・・｝.

　以上の entity および VE に対して、以下のように、「著作」 という概念的 スーパーセット を作ることができる。

　　　 [ 著作 ]
　　　　　↑
　　　　　× （概念的 スーパーセット）
　　　　　｜
　　　　　├｛著作番号、著作名称、・・・｝.
　　　　　├｛著作番号 (R)、出版日｝.
　　　　　└｛著者番号、著者名称、・・・｝.

　そして、「著作」 を 1つの単位として データ 演算の対象にすることができる。すなわち、リレーション のなかで、事実的対象を構成する リレーション を オブジェクト （抽象 データ 型） として扱うこともできる。ただし、「著作」 は、数学的な クラス 概念ではない。合成関数である──数学的に言えば、具象 カテゴリー と ファンクター である。すなわち、ファンクター は、関数の クラス であって、実 データ ではない。

　TM では、「著作」 は、以下のように、対照表として記述される。

　　｛著作番号、著作名称、・・・｝.
　　｛著者番号、著者名称、・・・｝.
　　｛著作番号 (R)、著者番号 (R)、出版日｝.

　すなわち、関数の クラス は、対照表として、かつ、「event」 （この例では、「出版」 という event） として構成される。TM では、この対照表は 「event」 であって、「著作」 という 「resource」 として認知しない。

　｛著作番号 (R)、著者番号 (R)｝ を 集合 オブジェクト として考えて、かつ、1つの個体 （持続する現実的な事物） として考えることもできる。ただし、TM は、「合意・同意された認知番号を付与された対象」 を entity として定義している。したがって、entity （セット 概念） を演算して得られた構成は、「関係」 の記述であって、「個体」 の記述とはしない。言い換えれば、なにを 「個体」 として認知しているかという点は、それらの データ を使う人たちの判断次第である。たとえば、以下を考えてみる。

　　｛著作番号、著作名称、著者名称、・・・｝.
　　｛著作番号 (R)、出版日｝.

　この構造は、「著者」 を単独の entity として認知していない。この構造では、対照表 ｛著作番号 (R)、著者番号 (R)、出版日｝ は生成されない。「著者番号」 を導入するかどうかは、事業のなかで、どのような管理をするのかという判断次第であって、管理のしかたが相違すれば──したがって、個体の認知のしかたが相違すれば--、当然ながら、データ 構造は相違する。たとえば、出版社が「装丁」 を管理するのであれば、「材質番号」 を導入して、それぞれの著作が、どのような材質を使っているのかを管理するかもしれない。しかし、書物を販売する書店では、それぞれの書物に対して、「材質」 を管理することはしないかもしれない。「書物」 という物体を データ 構造として、どのように構成するかという点が、データ 設計として論点になるのではない。言い換えれば、「個体 （entity）」 は、つねに、「合意・同意された」 認知を前提にして記録され、それらの 「個体 （entity）」 を使って構成された物 （対照表、対応表、再帰表） は、どこまでも、「関係」 を記述しているのであって、対照表を 「event あるいは resource」 として類別する 「意味」 はない。「集合の集合 （クラス、あるいは対照表）」 は、集合の集合であるかぎり、個体として認知されていない。そういう 「集合の集合」 に対して、擬似番号 （phantom/pseudo） を付与するのは、演算の効率化のためであって、事実を対象とした記述ではない。

　逆に言えば、対照表 ｛著作番号 (R)、著者番号 (R)｝ が集合 オブジェクト として、1つの resource を構成しているのであれば、それに対して 1つの認知番号を付与しているはずである。たとえば、出版社であれば、「著作番号」 と 「著者番号」 を使って書物を管理するが、対照表 ｛著作番号 (R)、著者番号 (R)｝ は最終構成物であって、対照表を起点にして、なんらかの事業を進める訳ではない。いっぽう、書店では、対照表 ｛著作番号 (R)、著者番号 (R)｝ として構成された書物が事業の起点になる。書物は、編集・出版・セールス のなかで、一連の事業として、出版社や書店などで「共通して」 使われる個体なので、「共有できるように」 ISBN を付与されている。ただし、ISBN は、出版社では、最終成果物たる対照表 ｛著作番号 (R)、著者番号 (R)｝ の備考であって、VE として扱われるかもしれない。

　対照表を 「event とするか、resource とするか」 の判断 （あるいは、「解釈」） は、ユーザ に委ねられた判断であって、システム・エンジニア に委任されているのではない。たとえば、再帰表｛部品番号 (R)、部品番号 (R)｝ に対して──すなわち、部品構成に対して──もし、部品構成表を 1つの個体として認知するのであれば、部品構成表番号が付与されるはずである。

　なお、1つの認知番号が、対照表のように、複合構成になっているという現象については、253 ページ、449 ページ および 457 ページ を参照されたい。