以下の データ 構造を前提にする。

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

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

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

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

　
● VE は entity の純度を高めるために導入された。

　承認申請日および請求承認日は、時系列のなかで、null となるのであれば、状態遷移を示している。
　請求承認日が 「任意の入力項目」 であるとは判断しがたい。

　さて、VE は、以下の事態を回避することを目的として使う。

　（1） １つの resource のなかに、event が混入している。
　（2） １つの resource のなかに、他の resource が混入している。
　（3） １つの event のなかに、resource が混入している。
　（4） １つの event のなかに、他の event が混入している。

　それぞれの具体的な例については、拙著 「Ｔ字形 ER による データベース 設計技法」 を参照されたい。
　上述した事態は、いずれも、１つの entity のなかに、ほかの entity が 「混入（contaminated）」 していることを示している。つまり、VE は、entity の純度を高めるために、混入した他の entity　（ただし、認知番号が付与されていない状態） を排除するために使う。

　上述した例では、「入金予定」 が、あきらかに、VE として扱われる。

　VE は null を回避するために使う テクニック ではない。ただし、null の起こる アトリビュート が 「フラグ （flag）」 のような性質であれば、entity の純度を高めるために、VE を使うことがある。たとえば、「区分 コード」 とはいっても、「有る・無し」 を示すにすぎない 「flag」 であれば、VE を使う。

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

　請求. 領収書添付
　｛請求番号 (R)、領収書添付区分コード｝[ VE ]

　[ 領収書添付区分 コード の値は、 「 1 （はい）」 か 「0 （いいえ）」 のいずれかである。]

　
● 状態遷移を示す null は、区分 コード と同じである。

　時系列のなかで null が生じるというのは、状態遷移を示している。
　したがって、状態遷移に対しては、本来、ステータス・コード が付与されていても良い。
　サブセット には実質的 サブセット と形式的 サブセット がある （101 ページを参照されたい）。

　形式的 サブセット は null を扱うために使う。

　したがって、上述の例は、以下のように訂正されなければならない。

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

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