Ｔ字形 ER手法では、モノ の類として 「resource と event」 を導入して、それらを類別する判断規準として 「DATE」 を導入している。ただし、（純粋な記号操作を前提にしている） 「正規化 （normalization）」 概念では、（「resource」 とか 「event」 とかいう） 「意味論」 を モデル のなかに導入してはいけない （！）

　小生 （佐藤正美） が、ウィトゲンシュタイン 氏の 「真理関数 （主選言標準形）」 を使ってＴ字形 ER手法の 「原型」 を考えたときに、最大に苦しんだ点が、「モデル （真理関数）」 のなかに 「意味論」 を導入してしまった、という点です。さらに、小生が悩んだ点は、「event」 の定義として、「DATE」 を導入した、という点です。純粋な記号操作のなかでは、モデル の構造のなかに、「時間軸」 を混入してはいけない。「DATE」 は、あくまで、パラメータ の１つであって、構造を構成する判断基準であってはいけない。

　小生はＴ字形 ER手法を （「真理関数」 を使った） データ 設計法として使っていたけれど、データ 設計法としては、前述した危険性 （「意味論」 の混入） を犯していることを、重々、承知していました。つまり、純粋な モデル 理論として判断すれば、Ｔ字形 ER手法は、「論理学」 の ルール を破っている、ということです。

　ただ、直積集合を使った純粋な データ・モデル （セット・アット・ア・タイム 法） が、変数として実 データ を対象にしたとき、完全な 「順序対」 の導入ができなかったことや、null に対して 4値 ロジック を使った ややこしい演算体系になったことを鑑みれば、（法則的な モデル ではないにしても、なんらかの） 構造を構成するためには--しかも、ビジネス のなかで扱われている データ を対象とすれば--「順序対」 を保証する規準として、「並べられる」 データ と 「並べられない （並びが論点にはならない）」 データ を類別することは中核の論点になる。ビジネス （経営過程--少なくとも、正常営業循環 [ 購買過程-生産過程-販売過程] ） のなかでは、時系列が成立する。

　とすれば、ビジネス のなかで使われている実 データ を対象として、時系列 （時間軸） を導入するのであれば、Ｔ字形 ER手法を データ 設計法 （モデル 構成法--法則） として使うのではなくて、それぞれの事象の 「事実を記述する」 ための技術として使うというふうにしなければならない。

　とすれば、現実の世界 （実 データ） を対象とすれば、「resource」 と 「event」 という概念も 「DATE」 という概念も、対象を解析する概念として使うことができ、Ｔ字形 ER手法を 「データ 解析」 技術として使うことができる（！） つまり、Ｔ字形 ER手法は、（設計段階のなかで使われる） 「データ 構造を設計する法則」 （モデル 構成法） から離陸 （take-off） して、（経営と IT の接点である） 「事実を記述する」 ための 「データ 解析法」 へと飛翔できる。

　拙著 「論理 データベース 論考」 は、（ビジネス のなかで使われている データ を対象として） 「関係 R」 として関数を使うかどうか、という点を検証した書物です。小生が、「論理 データベース 論考」 を執筆していたとき、最大の難関だったのが、Ｔ字形 ER手法のなかに、「意味論」 を混入してしまったことだった--ちなみに、「意味論」 の混入は、Ｔ字形 ER手法を、当初、実地に使いながら、効率的・効果的に使えるように整えてきた （理論的な検証が後回しになってしまった） という点にあった。
　「論理 データベース 論考」 は、aRb を 「関数として扱わない」 という宣言をした--Ｔ字形 ER手法を 「事実を記述する」 ための技術として使う第一歩となった--書物です。小生がＴ字形 ER手法を 「データ 解析法」 法である、と言い出した時点は、「論理 データベース 論考」 を脱稿してからだった （笑）。

　「順序対」 という論点に対して、「DATE」 という意味論を導入したので--そして、いっぽうでは、主選言標準形を 「正規化」 法として使ったので--、Ｔ字形 ER手法は、実地に使えるように単純な ルール の体系として集成することができたのですが、初見では、「こんなのが技術なの ？」 と疑われてしまう傾向があるようです（笑）。「データ 構造を導出するための法則」 という意味では、Ｔ字形 ER手法は データ 設計法ではない。ただし、「事実を記述する」 技術という意味では、Ｔ字形 ER手法は、その目的を達成していることは、拙著「論理 データベース 論考」 のなかで証明しました。そして、解析した事実 （「データ 解析」） を、そのまま [ 若干の調整はしなければならないけれど ]、実装したのが 「データ 設計」 です。

　それぞれの ビジネス には、それぞれ、固有の （one and only） データ 構造が存在するのであって--しかも、それは、つねに、変転するのあって--、すべての事象に適合する モデル はない。ただし、或る構造のなかで扱われている任意の項目が、すべて、前提 （公理、仮定） から証明できる、という証明可能性の意味では、[ データ 構造を記述する ] モデル は存在しなければならない。

　「事実の記述」 というのは、（「データ 設計」 から観れば） どういうことなのかといえば、「データ 設計は、工学技術であって、一人の システム・エンジニア の価値観のために崩れるような モノ ではない。『わたしには、或る データ が見えて、あなたには、それが見えない』 というような、いきなり、だれも知らないような ファイル が飛び出るような不意打ちは、工学技術にはない。作図された データ 構造は、かならず、前提 （公理、仮定） から、すべて、証明されなければならない。それが 『完全性』 ということです。」