たとえば、以下の品目 entity を例とする。

　　｛品目番号、品目名称｝[ Ｒ ]

　前提：
　（1） 品目番号は 4桁である。
　（2） 品目番号の 3桁目の値が 「9」 なら、社内消費用の品目である。
　（3） その以外の品目は、通常受注用の品目とする。

　おそらく、以下のような サブセット を生成したとする。

　　　　　　　品目
　　　　　　　　｜
　　　　　　　　＝
　　　　　　　　│
　　　　　　　　├｛社内消費｜品目番号, 品目名称｝
　　　　　　　　│
　　　　　　　　└｛通常受注｜品目番号, 品目名称｝

　一見、「わかりやすい」 構造であるが──「論理和」 を充足しているので、ひょっとしたら、「クラス」 の観点からは、こういう構造を生成するかもしれないが──、Ｔ字形 ER手法では、絶対に認められない構造である。

　なぜなら、Ｔ字形 ER手法では、かならず、サブセット を生成する判断規準を記述しなければならない。
　つまり、コード 体系のなかで実地に使われている コード （「XX 区分 コード」 あるいは 「XX 種別 コード」） を記述するか、もしくは、null が起こるので形式的 サブセット を生成したことを記述しなければならない。

　この例では、モノ の認知番号 （identifier） は 「品目番号」 である。
　この例では、「品目番号」 は、さらに、「分析 （解体）」 される状態にない。

　とすれば、モノ の認知番号のなかで、コード に対して意味が附与してあっても、コード は形式的には全体として 1つの コード であって、コード の値を判断するのは アルゴリズム である。
　したがって、品目番号の 3桁目が 「9」 なら、社内消費として使われる品目であるという点は、「アトリビュート・リスト」 の 「前提欄」 のなかで記述される。

　構造は値には関与しない （！）
　そして、構造を生成するための判断規準は、Ｔ字形 ER手法では、「コード 体系」 なのである。
　サブセット を生成するためには、判断規準として 「コード」 （あるいは、null） を記述しなければならない。
　もし、そのような コード （あるいは、null） が記述できないなら、サブセット を生成してはいけない。

　Ｔ字形 ER手法の目的の 1つは、（DOA が 「データ の独自性」 を主張する割には、データ と アルゴリズム の境界線が曖昧にされてきていたので） 「データ と アルゴリズム の境界線を明晰に判断して、データ 構造を明晰に記述する」 という点にある。コード 体系のなかに実存しない コード を恣意的に使うことを禁止して、サブセット を生成する判断規準を用意した点を再考してほしい。