サブセット 化には、以下の 2つがある。

　　（1） 形式的 サブセット 化
　　（2） 実質的 サブセット 化

　形式的 サブセット 化は （データ のなかに） 「null」 が生じるので サブセット を生成することをいう。
　実質的 サブセット 化は「区分 コード」 を使って サブセット を生成することをいう。

　
　たとえば、品目番号が identifier として成立していて、品目番号の値によって、データ の扱いがちがうことがある。品目番号の値が、たとえば、100未満なら、アルゴリズム A を使い、100以上なら、アルゴリズム B を使うという （アルゴリズム のなかの） 「if-else」 の構造を前提にして データ 値が用意されていることがある。そういうときには、品目番号の値を使って サブセット を生成するかどうか、という点が論点になるが、そのような事象は、純然たる アルゴリズム の適用の論点であって、データ 構造の論点ではない。したがって、サブセット は生成しない。そういう事象は、アトリビュート・リスト のなかで記述する。

　データ の値によって、アトリビュート の構成が違ってくることがある。以下を例にする。

　品目 ｛品目コード、品目名称、備考｝.

　ただし、「備考」 には、品目が完成品なら、（ユーザ が依頼した） 加工具合が記述される、とする。
　とすれば、データ 構造は、以下のようになる。

　　品目 [ Ｒ ]
　　　｜
　　　× null （備考）
　　　│
　　　├｛品目番号、品目名称｝ [ 原状態 ]
　　　│
　　　└｛品目番号、品目名称、備考｝ [ 製品（加工完了） ]

　
　そういう事象では、データ （アトリビュート） のなかに null が生じるので、null を宣言した サブセット を生成することになる （形式的 サブセット 化）。ただ、ここで論点になるのは、そのような サブセット に対して、「区分 コード」 を用意するかどうか、という点である。
　形式的 サブセット 化に関して、以下のように考えればよい。

　（1） 「状態の推移」 を記述するのであれば、「区分 コード」 を用意しないほうがいい。
　（2） 「形態ごと」 に管理するのであれば、「区分 コード」 を用意したほうがいい。□

　
[ 注釈 ]
　「データ 解析に関する FAQ」 のなかで、１月31日に掲載した 「サブセット と VE （その 2）」 （ページ 一覧表のなかの 97ページ） では、以下のように記述されています。

　R＆D 区分 コード は （部品に対して）--サブセット として--「状態」 を記述する コード として作用できる点に特徴がある

　以上の記述が、本 ページ のなかの「『状態の推移』 を記述するのであれば、『区分 コード』 を用意しないほうがいい。」 という記述と矛盾するのではないか、という ご指摘をいただきました。この 2つのは矛盾するのではなくて、以下のような違いがあります。

　（1） 状態の推移を記述するために--状態の推移を管理するために--「区分 コード」 をすでに用意している
　　　（ 1月31日の掲載）
　（2） 形式的 サブセット 化 （null の扱い） のなかで状態の推移を扱っている
　　　（ 2月23日の掲載）

　（2） のときには、--状態の推移が当初から管理対象になっていなければ--状態の推移を管理する 「区分 コード」 を用意しないほうがよい、という意味です。

　曖昧な記述のために混乱を招いたことを お詫びします。