Entity は、TM では、以下のように定義されている。

　　Entity である ＝ _Df 認知番号を付与されている対象である。

　そして、「みなし entity」 は、認知番号を付与されていないけれど、entity としてみなす技術であるが、基本的に、「周延」 の観点から導入された概念である。したがって、「みなし entity」 のいちぶは、コッド 関係 モデル の 「推移従属性」 に対応する。たとえば、以下を考えてみる。

　　｛予約番号、予約日、申込者氏名、申込者住所、・・・｝.

　予約番号と申込者氏名は、関数従属性として 「１対１」 に対応するが （第二正規形）、いっぽうで、申込者氏名と申込者住所も 「１対１」 に対応する （第三正規形）。したがって、コッド 正規形では、以下の構造とするのが正しい。

　　｛予約番号、予約日、申込者氏名、・・・｝.
　　｛申込者氏名、申込者住所、・・・｝.

　しかし、TM では、以下の構造とする。

　　｛予約番号、予約日、・・・｝.
　　｛予約番号 (R)、申込者氏名、申込者住所、・・・｝.

　すなわち、申込者は、管理上、独立した対象として認知されているのではないのであって、「予約」 のなかで認知されていると考える。もし、予約のつど、申込者氏名を いちいち 記入して、データ の重複が起こるのであれば、重複を回避するために、そして、入力の省力化を考えて、申込者に対して、認知番号を付与するのかどうかという点を検討しなさいと ユーザ に迫るのが TM の目的である。

　ちなみに、申込者氏名を primary-key にすることは、そうそう単純な手続きでない点に注意されたい。たとえば、予約伝票のなかで、「佐藤正美」 と記入されることもあれば、「佐藤　正美」 と記入されることもあれば、「佐藤まさみ」 と記入されることもあって、それらを、同じ primary-key として扱うためには、なんらかの標準化──たとえば、「姓名は連続して記入する （「佐藤正美」）」 という規約を導入しなければならないし、コンピュータ のなかで、姓名を統一する プログラム を用意しなければならない。たとえば、もし、「佐藤　正美」 という データ があれば、データ を一桁ずつ確認して ブランク を詰めなければならないし、「佐藤まさみ」 であれば、申込者住所を検証して、同一人物かどうかを検証して、「佐藤正美」 として統一しなければならない。そして、たとえ、そういう手続きを導入したとしても、「事実 （伝票に記入されている事実）」 と データ 構造が対応しているかどうかという点は論点になる。「事実」 は、どこまでも、しかじかの 「予約」 のときに、しかじかの 「申込者」 であったという点であって、その逆ではない──しかじかの 「申込者」 が、しかじかの 「予約」 をしたということではない。

　
● みなし entity の 「event/resource」 化

---

　さて、「みなし entity の 『event/resource』 化」 を考える際、たしかに、概念的には、「申込者」 を resource として考えることはできる。そう考えることができるから、「予約」 event から独立して、概念的に、「申込者」 を 「みなし entity」 にしたのである。

　しかし、独立した resource として認知されていない──言い換えれば、event の中でしか認知されていない──「申込者」 を resource として扱って、「予約番号 (R)」 を、あたかも、resource の認知番号として代用して、TM の 関係文法を適用することに、いったい、どういう 「意味」 があるのか。

　「申込者」 を resource として考えて、「申込者」 を徹底的に分析することには、データ 解析上、極めて有効であるが、上述したように、「事実」 は、どこまでも、しかじかの 「予約」 のときに、しかじかの 「申込者」 であったという点であって、その逆ではない──しかじかの 「申込者」 が、しかじかの 「予約」 をしたということではない。もし、逆に、しかじかの 「申込者」 が、しかじかの 「予約」 をしたという管理をしたいのであれば、その考えかたのなかには、すでに、「申込者」 を常得意として管理する視点が入っていて、「得意先番号」 を導入するはずである。

　あるいは、「予約」 された商品を 「申込者」 に送る管理過程を考えてみればよい。

　　｛予約番号、商品番号 (R)、予約日、・・・｝.
　　｛予約番号 (R)、申込者氏名、申込者住所、・・・｝.
　　｛出荷番号、予約番号 (R)、出荷日、・・・｝.

　「出荷」 のなかに （TM の文法に従って） 転記された 「予約番号 (R)」 は、たとえ、「申込者」 を resource として考えて、resource の認知番号を代用しているとしても、「予約」 event が完了したことを意味しているのであって──言い換えれば、しかじかの商品が予約されて、その商品が引き渡されて売上が計上されることを意味しているのであって──、「『商品』 を 『申込者』──正確に言えば、申込者住所--に送る」 ことを管理している訳ではない。しかし、以下の構造になれば、「意味」 が違ってくる。

　　｛申込者番号、申込者氏名、申込者住所、・・・｝.
　　｛予約番号、申込者番号 (R)、商品番号 (R)、予約日、・・・｝.
　　｛出荷番号、予約番号 (R)、出荷日、・・・｝.

　この構造が意味しているのは、「今回の 『予約』 では、（すでに登録されている） 『申込者』 の中で、或る 『申込者』 から、しかじかの 『商品』 が予約されて、『出荷』 された」 ということである。

　「みなし entity」 を単純に 「event/resource」 化することが、事業を 「解析する」 際に、いかに危険であるかという点を考えてほしい。