たしかに、サブセット と VE は、実装形が同じになることがある。
　たとえば、前回の例 （「請求」 の例、237 ページ） がそうである。

　VE として記述した例

　請求
　｛請求番号、請求日、請求金額、・・・｝ [ E ]

　請求申請
　｛請求番号 (R)、承認申請日、・・・｝ [ VE ]

　請求承認
　｛請求番号 (R)、請求承認日、・・・｝ [ VE ]

　入金予定
　｛請求番号 (R)、入金予定日、・・・｝ [ VE ]

　
　サブセット として記述した例

　　請求 [ E ]
　　　｜
　　　×
　　　│
　　　├　承認申請 { 請求番号, 承認申請日 }
　　　│
　　　├　請求承認 { 請求番号, 請求承認日 }
　　　│
　　　└　請求 { 請求番号, 請求日, 請求金額,・・・ }

　　入金予定
　　｛請求番号 (R)、入金予定日｝ [ VE ]

　
　「相違の サブセット」 では、それぞれの サブセット を実装すれば、VE を使った構造と同じ実装形になる。
　だが、「事業を解析する」 点から判断すれば、サブセット と VE は、それぞれ、違う目的の技術である。
　サブセット は 1つの entity だが、VE は 複数の （潜在的な） entity を示している。したがって、サブセット と VE では、記述されている構造が示す 「意味」 は、全然、違うのである。

　なお、Ｔ字形 ER手法は、「事業解析 ＝ データ 正規形 ＝ アルゴリズム の I/O 化」 を同時に実現することを目的にしている。データ 正規形だけを論点にするのなら、実装形が同じであれば、サブセット でも VE でも良いが、「データ 正規形 ＝ 事業解析」 という点を軽視してはいけない。

　サブセット と VE という 2つの相違する技術を使うということは、それぞれの使用目的が違うということである。上述の例では、VE （請求申請および申請承認） は （認知番号を付与されたら） 請求に対して独立した entity として対峙できる──請求に対して関係を結ぶことができる──ことを示しているが、いっぽう、サブセット は、1つの entity （請求） の状態遷移であることを示している。

　Ｔ字形 ER手法を ルール どおりに使ってください。