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

　従業員
　{ 従業員番号、従業員名称、入社日、... }.

　
●　VE の目的

　VE は、entity の精度を高めるために導入されている。
　当初、VE を導入した理由は、Ｔ字形 ER手法のなかで矛盾が起こらないようにするためであった。
　Ｔ字形 ER手法では、entity は、以下の 2つの サブセット から構成される。
　　（1） event
　　（2） resource

　Event は、時系列のなかで 「並び」 が論点になる entity であり、性質として、「日付 （DATE）」 が帰属する。そして、排中律を使って、resource は、event 以外の entity （補集合） とされている。

　さて、性質として、「日付 （DATE）」 が帰属する entity を event として定義するなら、従業員 entity のなかに、「入社日」 が記述されることは矛盾になる──なぜなら、「入社日」 は、「入社」 という event に帰属する性質であって、従業員に帰属する性質ではないから。そのために、従業員 entity のなかに、入社日を定義することは、Ｔ字形 ER手法の前提に反する。したがって、入社日を従業員 entity から切り離して、擬似的な event を生成する手段が VE である。

　ただし、入社日を性質として記述する「入社」 entity はない──Ｔ字形 ER手法では、entity は認知番号を付与されていることが前提になっているが、入社番号も入社 コード も、「合意」 された認知番号として コード 体系のなかにはないので、次善策として、従業員 entity のなかに、入社日を収めている。
　とすれば、入社日を切り離して、擬似的な event を生成するなら、以下のように、従業員番号を継承するしかない。

　従業員
　{ 従業員番号、従業員名称、... }.

　従業員. 入社
　{ 従業員番号 (R)、入社日 }.

　「従業員. 入社」 のなかの 「従業員番号 (R)」 は、ほかの entity （あるいは、対照表） のなかに複写されることはないし、「従業員. 入社」 が、ほかの entity （あるいは、対照表） から、（R） を複写されることもない。

[ 参考 ]
　「従業員. 入社」 を 「従業員」 から切り離して実装して、「従業員. 入社」 テーブル に対して、CREATE INDEX （従業員番号、入社日） を生成して、従業員番号 (R) を直接に使うことは、なんら、問題を生じない。（R） の ルール と、indexing はべつの論点である。

　
●　VE の性質

　VE に対して、entity の種類と同じように、event 系の VE と resource 系の VE の 2つの サブセット から構成されるという ルール を導入できないことはない。しかし、「関係の論理 （aRb）」 のなかで、個体 （a および b） として認知されているのは、以下の 3つである。

　　（1） resource
　　（2） event
　　（3） event として作用する対照表

　「関係の論理」 の R は、Ｔ字形 ER手法では、すべからく、対照表である。その対照表に対して、認知番号を付与された モノ が event になる。対照表は、2つ以上の （R） から構成される擬似 event であって、1つの （R） が対照表を構成することはあり得ない。すなわち、対照表は、3項態 （2つの項から構成されて、新たな事態を形成する態） であって、新たな事態として作用し、ほかの entity （あるいは、対照表） と リレーションシップ を結ぶことができる──ただし、validation-rule を記述する対照表は単なる 2項態であって、ほかの entity と直接に リレーションシップ を結ぶことは、まず、ない。

　しかし、1つの （R） から構成されている モノ は、それ自体として認知されている モノ ではない。もし、それを管理対象として認知したいなら、独立した認知番号を付与しなければならない。
　Ｔ字形 ER手法が、entity の定義として、（コード 体系のなかで 「合意」 された） 認知番号を前提した理由は、entity の生成が一人の SE の価値観のために揺らがないようにするためである。したがって、1つの （R） から構成される entity などは起こり得ない。VE は、entity の精度を高めるための補助定理であって、entity を生成するための手段ではない。

　さらに、VE を 「的確に」 生成できるのは、DA の段位でいえば、2段以上の実力がなければならない。言い換えれば、2段以下の実力では、VE を的確に生成できない。
　認知番号を使って entity を生成するかぎり、entity は、だれが生成しても同じになるが、VE の使用を認めたとたんに、「構造」 が揺らぐ危険性に晒される。しかも、VE が乱用される危険性もある （拙著「論考」、240ページ参照）。

　VE の生成が恣意的になりやすいので、VE に対して、「関係の論理 （aRb）」 を導入することはしなかった。
　関数と違うやりかたを使って、データ の半順序・全順序を扱うために、entity の定義のなかに、「意味論」 を導入したのだが── event の定義として、「日付 （DATE）」 が性質として帰属する、という判断規準を導入したのだが──、1つの公理系として矛盾を回避するために──resource のなかに収められている 「日付 （DATE）」 を排除するために──、VE を導入したが、VE は、Ｔ字形 ER手法の前提を なし崩しにする危うさを秘めている。