2002年12月16日 一見 「entity」、実は 「サブセット」。 >> 目次 (テーマ ごと)
  ● QUESTION   認知番号が entity を形成しないことはあるか。
  ▼ ANSWER   ある。 サブセットになることがある。
2008年 1月 1日 補遺  



 一見 「entity」、実は 「サブセット」 という実例がある。

 以下の例を考えてみる。

 (1) 受注 {受注番号、受注日、数量}
 (2) 分納 {分納 コード、数量}
 (3) 出荷 {出荷番号、出荷日、数量}

 そして、以下の 2つの関係が成立する。

 (1) 「受注」 と 「分納」 は 「1-対-複数」 の対応関係にある。
 (2) 「分納」 と 「出荷」 は 「1-対-1」 の対応関係にある。

 さて、「認知番号」 を判断規準にすれば、以下の 3つの 「entity」 が成立する。

 (1) 受注
 (2) 分納
 (3) 出荷

 そして、相関関係は以下が成立する。

  受注 {受注番号、受注日、数量}[ E ]
   |
   |1-対-N
   |
  分納 {分納 コード、受注番号 (R)、数量}[ E ]
   |
   |1-対-1
   |
  出荷 {出荷番号、分納 コード (R)、出荷日、数量}[ E ]

 さて、実は、この時点で、「常識の罠」 に陥ってしまっている(!)
 すなわち、「分納」 entity のなかには、「DATE」 がないにもかかわらず──あるいは、「DATE」 を仮想できるかどうかという点を検証もしないで──、「分納」 という行為は 「event」 であるというふうに勝手に判断してしまっている。

 「分納」 という行為は、1つの 「出荷」 が複数に分割されたならば 「分納」 になるのであって、「分納」 と 「出荷」 は べつべつの行為ではない。

 実際、以下のように値を代入してみれば (「分納」 が単独で成立できないことを) 理解できる。

 (1) 受注番号の値 (001、002、・・・)
 (2) 分納 コード の値 (01、02、・・・)
 (3) 出荷番号の値 (0001、0002、・・・)

 とすれば、「分納」 entity と 「出荷」 entity は以下の値をとる。

 (1) 分納 [ 受注番号 (R) + 分納 コード ] (001-01、001-02、002-01、・・・)
 (2) 出荷 [ 出荷番号 + 分納 コード (R) ] (0001-01、・・・)

 さて、「出荷 0001-01」 のなかの 「分納 コード (R) 01」 は、「分納 001-01」 と対応するのか、それとも、「分納 002-01」 と対応するのか。

 この例では、「分納 コード」 は 「受注番号」 の枝番である。
 つまり、分納 コード は、(一見、認知番号のように思われるが、実は、) 「受注」 の サブセット を形成する区分 コード である (つまり、受注番号の桁数が違う相違の サブセット になる)。
 以下のように サブセット 化するのが正しい。

        受注
        |
        × null (分納 コード)
        │
        ├{受注番号、受注日、数量、・・・}
        |
        └{受注番号 + 分納 コード、受注日、数量、・・・}

        出荷
        |
        × null (分納 コード)
        │
        ├{出荷番号、受注番号 (R)、出荷日、数量、・・・}
        |
        └{出荷番号、受注番号 (R) + 分納 コード (R)、出荷日、数量、・・・}

 「受注」 と 「出荷」 の対応関係は、「サブセット 間の対応関係」 (173 ページ) のなかで記述したように、「受注」 の サブセット と「出荷」の サブセット が、それぞれ、対応することになる。

 



[ 補遺 ] (2008年 1月 1日)

 本 エッセー の例は、実例です。「受注」 は、以下の 2つの形態のいずれかである、という現象です。

 (1) ひとつの 「受注」 は、ひとつの 「出荷」 に対応する。
 (2) ひとつの 「受注」 は、いくつかの 「出荷」 として分納される。

 「(1) または (2)」 という排他的現象なので、いわゆる 「HDR-DTL (one-header-many-details)」 形態ではない。そして、この 2つの形態を管理するために──しかも、当初、(1) の形態のみであったのが、なんらかの理由で、(2) の形態が起こったので──、「分納 コード」 を後付で導入したのではないか、と想像できます。

 この実例で使われていた 「受注伝票」 が、実際、どういう記入形式であったかを、いまとなっては確認できないので──私は、データ 構成しか思い出せないので──、本 エッセー で述べた以上の考察ができない点を制限事項として付しておきます。したがって、実際に使われている 「情報 (伝票)」 を対象にして検討できないので、本 エッセー では、単に、「認知番号と思われる コード が、認知番号ではない」 という現象が起こることだけを示しました。




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