本 エッセー は ほぼ 5年前に綴られましたが、今となっては訂正しなければならない文があります。本 エッセー では、「Ｔ字形 ER手法では、クラス 概念を使わない」 としていますが、TM （Ｔ字形 ER手法の改良版） では、クラス 概念を使っています──TM で使っている スーパーセット は、クラス 概念そのものです。

　TM が クラス 概念を使うようになった理由は、「HDR-DTL」 構成に対応するためです。「HDR-DTL」 を、技術的には、合成関数 [ ふたつの関数を合成した関数 ] として説明することもできますが、争点になるのが、TM の定義 [ entity の定義 ] によって、合成関数が ひとつの entity になる、という点です──すなわち、本 エッセー のなかで述べたように、「『関係』 が、そのまま、モノ になる」 という点です。したがって、「関係」 を entity としてみとめるのであれば、クラス 概念を導入したほうが妥当 [ 簡便？ ] です。そして、いったん、クラス 概念を導入したならば、「概念的 スーパーセット」を──クラス 概念そのものですが、クラス としての 「性質」 を記述しないという点で、「概念的」 という形容詞を付していますが── entity に対して適用して、entity の構成を験証したほうが役立ちます。

　たとえば、「出荷先」 entity と 「請求先」 entity が存在すれば、それらの entity に対して、「取引先」 という クラス を構成して、次に、クラス を セット に翻訳して、「出荷先」 および 「請求先」 を サブセット に読み替えて、「構成」 の妥当性──すなわち、サブセット のあいだに 「切断 （排他的 OR 関係）」 が適用できるかどうか──を調べればいいでしょうね。もし、「出荷先」 entity と 「請求先」 entity のあいだに 「まじわり」 が生ずるのであれば、なんらかの対応をしなければならないでしょう。

　さて、「対応表」 は、本 エッセー で述べたように、「写像関数 （あるいは、写像集合）」 であって、entity ではない点に注意してください。TM では、entity は以下のように定義されています。

　　　Entity である ＝ _DF 個体指定子を付与されている管理対象である。