4 年前に綴られた本文を今読み返してみて、論法が 「論点先取り」 に陥っていることに気付きました （苦笑）。
　というのは、本文のなかで 「エンティティ （entity） を、すでに知っている人が、テーブル （table） を合成できる」 と綴っていますが、システム を設計する段階で、テーブル のなかに、すでに、reference-key を指示しているので、デーブル 構成では、そもそも、テーブル 間の 「join の 道 （path）」 が確定されているので、entity を合成する道は あらかじめ示されています。

　そうだとすれば──設計段階において、「path」 が固定されるとすれば──、設計は エンドユーザ が実施すれば良いということになりますね （そして、私は、その やりかた を強く推奨します）。

　コッド 関係 モデル も TM （Ｔ字形 ER手法の改良版） も 「論理的意味論」 に属する モデル です。ふたつの モデル を説明する理論は、それぞれ、数学基礎論 （および、言語哲学） を知らないと理解できないのですが、それらの理論を前提にした 「設計の 『手続き』」 は、いずれの モデル も、とても単純な テクニック なので──そして、いずれの モデル の テクニック も、コンピュータ の知識がなければ使えないという テクニック ではないので──、エンドユーザ も使える テクニック です。とすれば、事業過程・管理過程を知っている──特に、データ のあいだに付帯した制約・束縛を知っている──エンドユーザ が設計すれば良いとふうに考えるのは当然でしょう。ただ、もし、エンドユーザ が、そうするための時間を割り振るのが困難であれば、かれらの代わりに システム・エンジニア が設計すれば良いということです。システム・エンジニア が設計するとしても、あくまで、「代行」 であって 「主役」 ではないという自覚がなければならないでしょうね──そういう自覚 （「事実」 を前提にした自覚） を持っていないと、システム・エンジニア が、事業過程・管理過程を知り尽くして設計できるなどと思い違いしてしまうので （あるいは、自惚れてしまうので）。

　本文のなかで、もうひとつ訂正しなければならない点は、「Ｔ字形 ER手法は、... 概念設計と論理設計を 1つの手法で同時に実現することを狙っているから」 としている点です。というのは、この点は、コッド 関係 モデル でも同じです。およそ、「論理的意味論」 であれば──言い換えれば、「モデル （modeling）」 であれば──、その接近法になるのが当然です。

　TM では、entity という語と object という語が使われています。
　Entity は、TM では、以下のように定義されています。

　　Entity である ＝ _Df 個体指定子が付与された対象である。

　そして、個体指定子 （entity-setter） として、コード 体系のなかで記述されている管理番号 [ ××番号、×× コード ] を使います──たとえば、商品番号とか従業員番号とか受注番号とか契約書番号など。