一見 「entity」、実は 「サブセット」 という実例がある。

　以下の例を考えてみる。

　（1） 受注　｛受注番号、受注日、数量｝
　（2） 分納　｛分納 コード、数量｝
　（3） 出荷　｛出荷番号、出荷日、数量｝

　そして、以下の 2つの関係が成立する。

　（1） 「受注」 と 「分納」 は 「1-対-複数」 の対応関係にある。
　（2） 「分納」 と 「出荷」 は 「1-対-1」 の対応関係にある。

　さて、「認知番号」 を判断規準にすれば、以下の 3つの 「entity」 が成立する。

　（1） 受注
　（2） 分納
　（3） 出荷

　そして、相関関係は以下が成立する。

　　受注　｛受注番号、受注日、数量｝[ E ]
　　　｜
　　　｜1-対-N
　　　｜
　　分納　｛分納 コード、受注番号 (R)、数量｝[ E ]
　　　｜
　　　｜1-対-1
　　　｜
　　出荷　｛出荷番号、分納 コード (R)、出荷日、数量｝[ E ]

　さて、実は、この時点で、「常識の罠」 に陥ってしまっている（！）
　すなわち、「分納」 entity のなかには、「DATE」 がないにもかかわらず──あるいは、「DATE」 を仮想できるかどうかという点を検証もしないで──、「分納」 という行為は 「event」 であるというふうに勝手に判断してしまっている。

　「分納」 という行為は、1つの 「出荷」 が複数に分割されたならば 「分納」 になるのであって、「分納」 と 「出荷」 は べつべつの行為ではない。

　実際、以下のように値を代入してみれば （「分納」 が単独で成立できないことを） 理解できる。

　（1） 受注番号の値　（001、002、・・・）
　（2） 分納 コード の値　（01、02、・・・）
　（3） 出荷番号の値　（0001、0002、・・・）

　とすれば、「分納」 entity と 「出荷」 entity は以下の値をとる。

　（1） 分納 [ 受注番号 (R) ＋ 分納 コード ]　（001-01、001-02、002-01、・・・）
　（2） 出荷 [ 出荷番号 ＋ 分納 コード (R) ]　（0001-01、・・・）

　さて、「出荷 0001-01」 のなかの 「分納 コード (R) 01」 は、「分納 001-01」 と対応するのか、それとも、「分納 002-01」 と対応するのか。

　この例では、「分納 コード」 は 「受注番号」 の枝番である。
　つまり、分納 コード は、（一見、認知番号のように思われるが、実は、） 「受注」 の サブセット を形成する区分 コード である （つまり、受注番号の桁数が違う相違の サブセット になる）。
　以下のように サブセット 化するのが正しい。

　　　　　　　 受注
　　　　　　　　｜
　　　　　　　　×　null （分納 コード）
　　　　　　　　│
　　　　　　　　├｛受注番号、受注日、数量、・・・｝
　　　　　　　　｜
　　　　　　　　└｛受注番号 ＋ 分納 コード、受注日、数量、・・・｝

　　　　　　　 出荷
　　　　　　　　｜
　　　　　　　　×　null （分納 コード）
　　　　　　　　│
　　　　　　　　├｛出荷番号、受注番号 (R)、出荷日、数量、・・・｝
　　　　　　　　｜
　　　　　　　　└｛出荷番号、受注番号 (R) ＋ 分納 コード (R)、出荷日、数量、・・・｝

　「受注」 と 「出荷」 の対応関係は、「サブセット 間の対応関係」 （173 ページ） のなかで記述したように、「受注」 の サブセット と「出荷」の サブセット が、それぞれ、対応することになる。