（1） 周延しない サブセット
　（2） 混合的な名辞

　
　この 2つは、以下の 2点と対応している。

　（1） 外的性質 （あるいは、外的特徴）
　（2） 内的性質 （あるいは、内的特徴）

　
　外的性質とは、抽象的集合の・集合としての性質であり、内的性質とは、自然的性質のことをいう。^（注意）
　外的性質の観点から、周延しない サブセット として、サブセット の間に成立する 「論理積 （連言）」 を排除している。
　そして、内的性質の観点から、主語 （entity） に帰属しない性質を論点にしている。

　内的性質を判断する規準として、「entity 名称. 性質」 という単語構成を使う。つまり、形態素を検討する。
　たとえば、「受注日」 とか 「請求日」 は、「受注. 日」 や 「請求. 日」 という単語構成であり、それぞれ、受注 entity と 請求 entity に帰属する性質である--ただし、受注番号と請求番号が、コード 体系のなかで、記述されていることを前提にしている。同様にして、従業員名称と部門名称は、「従業員. 名称」 と 「部門. 名称」 という単語構成であり、それぞれ、従業員 entity と部門 entity に帰属する。

　さて、ここで論点になるのは、「性質として帰属すべき entity のない」 状態である。
　たとえば、以下を例にする。

　｛受注番号、受注日、受注数、直送先名称｝

　直送先名称は、単語構成 （形態素） から判断すれば、直送先に帰属する性質である。しかし、直送先 コード が、コード 体系にないとすれば、直送先は、 entity として、認知されていない。直送先 entity が認知されていないが、受注という出来事に関与する対象として、直送先を感知できるので、直送先名称を受注 entity のなかに置いている、という状態である。逆に言えば、受注という出来事を、認知番号を付与して、entity （対象） として認知すれば、直送先名称は、受注 entity の性質として、帰属しない性質となる。したがって、entity の観点からすれば、直送先名称を、受注 entity から外さなければならない。しかし、直送先名称が帰属するはずの直送先 entity は認知されていない。
　直送先名称を、受注 entity から外したとき、直送先が、受注という出来事に関与している事実を記述するために、以下のように、「受注番号」 を複写する。

　｛受注番号、受注日、受注数｝
　｛受注番号 (R)、直送先名称｝

　（Ｒ）を認知番号の代用としている状態が、VE （Virtual Entity） である。
　VE は、entity の定義を整合的にするために導入された概念である。

　Ｔ字形 ER手法では、entity は、「認知番号を付与された」 対象とされ、以下の 2つの サブセット に仕訳される。

　（1） event
　（2） resource

　event は、内的性質として、「日付」 が帰属する出来事と定義される。resource は、entity のなかで、event に対する補集合である--したがって、resource には、「日付」 は帰属しない。しかし、外的性質として、以下の状態を認識できる。

　｛従業員番号、従業員名称、入社日｝

　入社日は、単語構成 （「entity 名称. 性質」） から判断すれば、「入社. 日」 であるので、従業員には帰属しない内的性質である。従業員日はないので、従業員は resource である。resource のなかに、（たとえ、帰属すべき entity が違うとしても、） 「日付 （入社日）」 が混入している状態は、event の定義から判断して、整合的ではない。この非整合的な状態を回避するために導入した概念が、VE である。つまり、entity （event） の定義と対比して、矛盾を起こさない措置として--resource のなかに、「日付」 を遺さない措置として--、VE を導入した。

　VE を導入した理由は、以上であるが、VE は、データ 解析の観点から言えば、「event のなかに、resource が混入している状態」 を認識する、という点において、大きな実りを生むことになった。なぜなら、データ 解析とは、resource 解析のことだから。

　VE そのものの説明は、「論考」 よりも 「黒本」 のほうが体系立っている。「論考」 では、以下の 2つの現象しか示していない。

　（1） 或る resource のなかに、ほかの resource 的性質が混入している。
　（2） 或る event のなかに、resource 的性質が混入している。

　「論考」 では、VE を、一々、説明するつもりはなかった。というのは、VE は、「黒本」 で詳細に説明済みだったから。「論考」 で、VE を取り扱った理由は、「周延していない サブセット」 といっしょに記述してあるように、そして、節の標題が示すように、「コード 体系 （の乱れ）」 という観点に立って、区分 コード と認知番号に対して注意を促すためであった。

　VE のなかで (R) として示された認知番号は、当然ながら、reference-key ではない。意味論上、VE のなかに (R) として示された認知番号の多くは、「代示」 である--すべて [ ∀ (x) ] ではない点に注意されたい。たとえば、｛受注番号 (R)、直送先名称｝ では、受注番号 (R) は、直送先番号の代示である。「黒本」 では、(R) を reference-key としていたが、「論考」 では、その間違いを訂正して、(R) は、「Re-used」 としている。

　「黒本」 でも 「論考」 でも、「データ 分析とは、resource 解析である」 ということを強調してきたがために、そして、VE では、たしかに、event のなかに混入している resource 的性質を切り出して解析することは、データ分析上、非常に役立つ措置なのだが、VE が 「ほかの entity を定立する」 ための手段のように重視されるのは、度が過ぎている。たとえば、｛従業員番号 (R)、性別｝ では、従業員番号 (R) は、なんらかの認知番号の代示にはなっていない。もし、従業員番号 (R) が、個人を示す個体指示子の代示だとすれば、従業員名称は、当然ながら、VE のなかに記述されなければならないし、おそらく、従業員の データ として記録されている項目 （アトリビュート） のほとんどが VE となる。

　VE は、あくまで、しかじかの entity に帰属しない性質を除去するための措置であって、「認知番号を付与されていない個体 （の集合） を定立する」 ための手段ではない。VE を作った そもそもの理由は、resource のなかに event 的性質が混入することを回避するためである。たとえば、従業員 entity として、｛従業員番号、従業員名称、入社日、...｝ では、「入社日」 という 「日付」 が resource のなかに混入したままであれば、TM （Ｔ字形 ER手法） の entity 定義と矛盾する。というのは、TM では、「日付」 が帰属する entity が event とされているから。定義に矛盾しないように、resource から event 的性質を除去するために導入されたのが VE であった。言い換えれば、entity の純度を高めるために導入されたのが VE であった。したがって、しかじかの entity から除去された性質が、ほかの entity として定立できるかどうか は、べつの論点である [ 前述した 「性別」 の例を考えられたい ]。

　ただ、event のなかに混入している resource 的性質を切り出して検討することが、「データ 構造」 の潜在的問題点 （事業過程に対する有効性） に対して ソリューション を考える際に極めて役立つので、目的と手段が逆転してしまい、VE を 「ほかの entity を定立する」 手段のような印象を与えてしまったのかもしれない。