Entity を 「認知」 する際、小生が配慮した点は、「合意」 ということであった。
　1人の システム・エンジニア の価値観が データ 構造を形成する訳ではない。データ は、事業に関与する全員が使い、「意味」 を伝達している。そのために、データ 集合を生成する判断規準として、小生が使った前提は 「コード体系」 であった。

　従来のやりかたなら、データ 集合を生成したら、関係 （構造） を生成するという手順になるのだが、（20年ほど前に、コッド 正規形を日本に普及する仕事をしていて） 小生の頭のなかで、吹っ切れていなかった点が、「データ の並び」ということであった。この点に関しては、コッド 博士も、彼の論文のなかで、「関係 R のなかで、アトリビュート の並びは、全順序ではない （半順序になる）」 というふうに認めていらした。属性値集合 [ ｆ (x) ] の代わりに主体集合 [ F (ｆ）] を想像しても、関係 R の間に成立する並びは半順序である。

　[ 参考 ]
　全順序というのは、すべての データ が並べられることをいい、半順序とは、並べられる データ もあれば、そうでない データ もある、ということ。

　事業のなかで使われる データ のなかには、「並び」 が論点になる データ もあれば、そうでない データ もある。
　たとえば、出荷と請求では、（出荷、請求） という並びと （請求、出荷） という並びでは、「意味」 が違ってくる。（出荷、請求） は 「代金回収 （後払い）」 を意味し、（請求、出荷） は 「入金確認後、出荷 （前払い）」 を意味する。しかし、たとえば、従業員と部門では、（従業員、部門） という並びも、（部門、従業員） という並びも--並びを変えても--、意味は同じである （「配属」 という同じ意味である）。

　そのために、Ｔ字形 ER手法では、「データ構造」 を生成する際、「並び」 という点を論点にした。事業のなかで使われている データ を、「並び」 を判断規準にして、以下の 2種類に類別しなければならない。
　（1） 「並び」が論点になる データ （「並び」 が代わると、「意味」 が変わる データ）
　（2） 「並び」が論点にならない データ （「並び」 が変わっても、「意味」 が変わらない データ）

　Ｔ字形 ER手法では、「並び」 が論点になる データ を 「event」 として、それ以外の データ （つまり、「並び」 が論点にならない データ） を 「resource」 としている。つまり、entity は、以下の２つの種類に類別される。
　（1） event
　（2） resource

　さて、以上の点に気づいたまでは良かったのだが、この考えかた （entity は 2つの サブセット から構成される） が、それ以後、小生を苦しめることになった。まず、最初に、小生が苦しんだ点は、「event」と「resource」を類別する判断規準である。

　モノ は定義できない--あるいは、数理 モデル では、モノ は パラメータ として扱われる。
　モノ を類別するなら、まず、モノ が定義されていなければならない。幸い、Ｔ字形 ER手法は、モノ （entity） とは、コード 体系を前提にして、「認知番号を付与されていること」 としている。そのために、モノ を類別するなら、モノ の性質を判断規準にすれば良い。つまり、「event」 の性質と 「resource」 の性質を比較して、どちらかにしかない性質を判断規準にすれば良い。ところが、この性質を探すために、小生は 1年を費やすことになってしまった。今から振り返れば、無駄な探究をしていた、と笑い話として済ますことができるが、当時、「並び」 が論点になる データ と、そうでないデータ を類別するという着想を得て、有頂天になってしまい、証明を冷静に詰めるということができなくなっていたようです（苦笑）。なぜなら、小生は、「resource」 を、まず、「定義」 する作業に取り組んだから （苦笑）。
　起点を間違ったために、次第に、泥沼に陥って、ついには、1年間を棒にふることになってしまった。つまり、「resource （事物）」 は、モノ （entity） の サブセット だとしていながら、モノ （事物） を定義しようとして、まさに、「Ｗ ＝ ｛Ｗ｝」 の罠に陥ってしまったから。

　1年間の空虚な試みに疲れて、再度、起点にもどったとき、極めて単純なやりかたを、やっと、気づいた。
　極めて単純なやりかた というのは、（Ｔ字形 ER手法の定義によれば） entity は 2つの サブセット しかないのだから、「resource」 が定義しにくいのなら、もういっぽうの 「event」 を定義して、「resource」 は、「event」 以外というふうにすれば良いということです。

　このとき、小生が、かって、専攻していた財務会計が役立った。財務会計では、「流動」 と 「固定」 を類別する基準として、「正常営業循環基準」 が使われている。つまり、事業過程 （購買過程・生産過程・販売過程） のなかで認知 （測定・計上） される モノ を 「流動」 とする。
　「event （事象）」 は、事業過程のなかで起こった行為を記述する データ である。そして、行為であれば、それが起こった 「日付」--あるいは、終了した 「日付」--が記録される。「resource （事物）」 そのものには 「日付」 はない。なぜなら、「resource」 は、「event」 を実施する主体であるか、あるいは、「event」 のなかでやりとりされる対象だから。

　そこで、「event」 に帰属する性質のなかから 「日付」 を選んで、entity を類別する判断規準としている。
　つまり、性質として、「日付」 が帰属する モノ を 「event」 として、「resource」 は （排中律を使って） 「event以外のモノ」 としている。

　当初、Ｔ字形 ER手法は、コッド 正規形の弱点を回避することを目的として、「event」 概念と 「resource」 概念を導入したのだが、次第に、コッド 正規形から離れることになった。そして、「event」 概念と 「resource」 概念は、後々、小生を苦しめることになったし、逆に、Ｔ字形 ER手法が、データ 正規形を生成しながら、事業を解析できるという特徴を稼得することにもなった。小生を苦しめた点は、「性質として 『日付』 が帰属する」 という判断規準を導入したがために、「意味論」 のなかに足を踏み入れてしまった、という点です。なぜなら、小生は 「意味論」 を毛嫌いしていて、（コッド 正規形を信奉していたから） データ 構造は、だれでもが合意できる数理 モデル でなければならない、と思っていたから。

　[ 注意 ]
　コッド 正規形を小生は信奉していましたが、セット・アット・ア・タイム 法を実装技術として信頼していた訳ではない--少々、矛盾するような言いかたですが（笑）。ただ、セット・アット・ア・タイム 法が 「驚異的な」 パフォーマンス を実現できるような技術として、小生は 「INDEX-only」 を提示したのです。

　「Event」 の定義として、性質 「日付」 を使ったがために--entity を類別するために、「意味論」 を導入したがために--、Ｔ字形 ER手法は、体系のなかで矛盾を起こさないように、「みなし entity」 という補足的な技術を導入しなければならなくなった （後述）。 □