2002年 2月23日 形式的 サブセット 化と実質的 サブセット 化 >> 目次 (作成日順)
  ● QUESTION   データ の値によって データ の扱いが違うなら、サブセット にしたほうがいいのか。
  ▼ ANSWER   だめ。 サブセット を形成するための コード あるいは null がなければならない。
2007年 3月16日 補遺  



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

  (1) 形式的 サブセット 化
  (2) 実質的 サブセット 化

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

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

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

 品目 {品目コード、品目名称、備考}.

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

  品目 [ R ]
   |
   × null (備考)
   │
   ├{品目番号、品目名称} [ 原状態 ]
   │
   └{品目番号、品目名称、備考} [ 製品(加工完了) ]

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

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

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

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

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

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

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

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

 



[ 補遺 ] (2007年 3月16日)

 いま [ 注釈 ] を読み返してみたら、ややこしい言いかたをしていますね (苦笑)。

 TM (T字形 ER手法) では、サブセット は、以下の事態のいずれかのとき、そして、そのときにかぎり、サブセット を作ります。

 (1) 区分 コード が示されている。(実質的 サブセット)
 (2) null が起こる。 (形式的 サブセット)

 そして、いずれの事態でも、サブセット を作る際には、かならず、サブセット を作った理由 (区分 コード あるいは null) を宣言しなければならない。

 さて、本文のなかで、「形式的 サブセット」 に関して、以下の 2点を述べています。

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

 管理情報 (統計) を作成するには、以下の 3つの観点があります。

 (1) stock (一時点での状態)
 (2) flow (推移)
 (3) rate (対比、比率)

 「『状態の推移』 を記述する」 という意味は、本文の例 (「品目」の例) でいえば、(加工の完了した) 「製品」 が 「最終の品目」 とされていて、「原材料」 は、「製品」 になるまでの過度的状態 (あるいは、一過性の状態) であるという意味です。「品目」 として管理されるのは、あくまで、(加工の完了した) 「製品」 です。そして、「原材料」 は、「製品」 に対して、原形 (以前の状態) として管理されているにすぎない。したがって、管理の視点として、「原材料」 が 「製品」 になったかどうかという点 (「flow」 の管理) が重視されています。

 もし、「品目区分 コード」 を用意して、「品目」 を 「原材料」 と 「製品」 とに分割すれば、「原材料」 と 「製品」 とを、1つの集合のなかで、それぞれ、メンバー (部分集合) として扱うのですから、それらの対比 (「stock」 の管理および 「rate」 の管理) が重視されることになります。この例でいえば、「品目」 として記録されている対象は、「原材料」 と 「製品」 ですから、勿論、状態の推移を管理することも大切なのですが、いっぽうで、(構造の分割・細分を示す 「区分 コード」 を使ったからには、) ほかの管理の視点が盛り込まれている、ということです。




  << もどる HOME すすむ >>
  データ解析に関するFAQ