2002年 3月 3日 一般化と VE >> 目次 (作成日順)
  ● QUESTION   データ の一般化では、identifier がないことがある。どうすればよいか。
  ▼ ANSWER   対照表あるいは VE として扱うのが合理的である。
2007年 4月 1日 補遺  



 ここでいう 「テ゛ータ の一般化」 とは、以下の現象をいう。

  (1) 学校法人がある。学校法人には学部と大学院がある。
    (1)-1 学部生には学生番号が附番されている。
    (1)-2 大学院生には院生番号が附番されている。
    (1)-2 教職員には職員番号が附番されている。

  (2) 或る大学院生は、学部生でもあり、教員(講師)をしている。

 したがって、或る大学院生の テ゛ータ {名称、住所、電話番号、...} には、3つの重複 (redundancy) が起こっている。

 テ゛ータ の重複度が過半数に近いのなら、おそらく、学部生と院生と教職員とを統合する管理番号--例えば、在籍者番号とか--が用意されるのが合理的である。
 しかし、それほどの重複度でないのであれば、おそらく、統合的な管理番号を用意していないと思われるので、対照表あるいは VE として扱うことが合理的である。

 
 まず、注意しなければならない点は、3つの重複を回避するために、(エント゛ユーサ゛ の承認を得ていない) 「統合的な管理番号」 を使ってはいけない、という点である。なぜなら、その「統合的な管理番号」 は、だれも認知していないから。逆に言えば、エント゛ユーサ゛ の合意を得ることができるのなら、「統合的な管理番号」 を導入することは適切である。

 次に、厳密に言えば、住所は、学部生なり院生なり教職員のなかに帰属する テ゛ータ ではない。
 郵便番号を使って管理しているのであれば、(番地を除く) 住所は (郵便番号を identifier として)単独の entity として成立している。
 したがって、学部生と住所との関係は以下のようになる (院生と教職員も同じようになる)。

 {学生番号、名称}.
 {郵便番号、住所}.
 {学生番号 (R)、郵便番号 (R)、番地}.

 さて、ここで論点になるのが、「名称」 の重複度である。
 テ゛ータ は 「事実の写像である」 と思いたがる人々は、一人の人間に対する名称が 2つ以上も記録されることを嫌う。しかし、「事実」 というのは、「記録された事実」 であって、管理対象として認知されていることをいう。

 学部は独自の経営管理 システム を使っているし、大学院は独自の経営管理 システム を使っている。
 その 2つの システム の連結が 「弱い」 統合度であれば--逆に言えば、それぞれが、単独の経営管理 システム として稼働しているのであれば--、学部においては、学部生が院生 (や教員) であるという事実は、以下のように、VE を使って記述されることになる。

  [ entity と VE ]

  [ 学部側で ]
   {学生番号、名称}----{学生番号 (R)、院生番号 (R)}.

  [ 大学院側で ]
   {院生番号、名称}----{院生番号 (R)、学生番号 (R)}.

 その 2つの システム の連結が 「強い」 統合度であれば--極端に言えば、「一貫教育体制」 であれば--、当然ながら、「在籍者番号」 は考慮されて然るべき認知番号である。言い換えれば、学生番号や院生番号は 「進捗 コート゛」 に過ぎない。ただし、学部には学部としての管理項目があるし、大学院には大学院としての管理項目があるので、以下のように、対照表と VE を使って記述することになる。

  [ entity ]

   {在籍者番号、名称}.
   {学部 コート゛、名称}.
   {大学院 コート゛、名称}.

  [ 対照表と VE ]

   {在籍者番号 (R)、学部 コート゛ (R)、習得単位数、...}.
   {在籍者番号 (R)、学部 コート゛ (R)、学生番号(R)}.
   {在籍者番号 (R)、大学院 コート゛ (R)、習得単位数、...}.
   {在籍者番号 (R)、大学院 コート゛ (R)、院生番号 (R)}.

 当然ながら、以上の 2つの記述は、べつべつの 「事実」 を表示しているのであり、それらの テ゛ータ 構造を観れば、その組織の管理体制を知ることができる。以上の点が、テ゛ータ 設計 (「minimal cover」 を狙う やりかた) と テ゛ータ 解析の相違点である。

 もし、以上の 「名称」 の記録を 「重複」 というのなら、そして、その 「重複」 が嫌なら、一人の人間に対して、生涯唯一の認知番号--例えば、国民背番号--を導入すればよい。たとえ、国民背番号制度を導入したとしても、一人の人間に対して--あるいは、ひとつの名称に対して--、複数の管理番号 (あるいは、認知番号) は起こる。なぜなら、ひとつの事象に対して認知するやりかたは、管理主体が違えば違ってくるから。
 コンヒ゜ュータ の都合のために経営が実施されているのではない。



[ 補遺 ] (2007年 4月 1日)

 本 エッセー で述べた学校の例では、「一貫教育体制」 でなければ、「一般化」 の論点は起こらないでしょうね。「一般化」 が論点になる ほかの例として、以下を考えてみましょう。

 {支払先コード、支払先名称、...}.
 {出荷先コード、出荷先名称、...}.
 {納入先コード、納入先名称、...}.

 支払先・出荷先・納入先に対して、それぞれ、認知番号 (個体指示子) が付与されている、とします。そのときに論点になるのが、それらの セット (集合) のあいだで、「まじわり (AND 関係)」 が起こるのではないかという点です。すなわち、支払先・出荷先・納入先には、家族的類似性があって、クラス として、「取引先」 を考えることができるのではないか、という論点です。

 もし、それらの セット のあいだに 「まじわり」 が起こるのであれば、そして、その 「まじわり」 の比率が高いのであれば--たとえば、30% とか--、「取引先」 という上位 クラス を導入して、「一般化」 したほうが良いかもしれない。支払先・出荷先・納入先を区分するために、「取引先区分コード」 を導入するとします。「一般化」 すれば、以下の構成となるでしょう。

 ┌─────────────────┐     ┌─────────────────┐
 │    取引先区分コード    R│     │       取引先      R│
 ├────────┬────────┤     ├────────┬────────┤
 │取引先区分コード│        │     │取引先コード  │取引先名称   │
 │        │        │>─○─<│        │        │
 │        │        │  │  │        │        │
 │        │        │  │  │        │        │
 │        │        │  │  │         │        │
 └────────┴────────┘  │  └────────┴────────┘
                      │
                      │
         ┌────────────┴────────────┐
         │      取引先. 取引先区分. 対照表      │
         ├────────────┬────────────┤
         │取引先コード(R)   │            │
         │取引先区分コード(R) │            │
         │            │            │
         └────────────┴────────────┘



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