2004年 2月 1日 1つの HDR と複数の DTL >> 目次 (作成日順)
  ● QUESTION   1つの HDR のなかの複数の DTL は成立するか。
  ▼ ANSWER   成立することもある。
2009年 2月16日 補遺  



● 前提 [ データ および事業 ]

 以下の データ を前提にする。

 ライン
 {ライン 番号、ライン 名称、・・・}[ R ]

 品目
 {品目番号、品目名称、・・・}[ R ]

 作業者
 {作業者 コード、作業者名称、・・・}[ R ]

 作業 オーダー
 {作業 オーダー 番号、ライン 番号 (R)、作業日、・・・}[ E ]

 
 以下の事業を前提にする。

 (1) 1つの ライン では、複数の作業者が作業する。
 (2) 1つの ライン では、複数の品目が扱われる。

 
 さて、以上を前提にすれば、作業者と品目との間では、以下の点が検討されなければならない。

 (1) 作業者と品目との間には、対応関係が成立している。
    とすれば、以下のいずれの関係が成立する。

    - 1人の作業者が扱う品目は 1つである。 [ 1:1 ]
    - 1人の作業者が複数の品目を扱う。 [ 1:M ]
    - 複数の作業者が 1つの品目を扱う。 [ M:1 ]
    - 複数の作業者が複数の品目を扱う。 [ M:M ]
    (ただし、作業者と品目には、直接の関係はなくて、ライン 上で、対応が成立する。)

 (2) 作業者と品目との間には、対応関係は成立していない。
    「だれが、どの品目を作業する」という管理はしない。

 
● データ 構造

 1つの HDR に対して複数の DTL が成立するのは、上述の前提 (作業者と品目の関係) の (2) である。
 まず、作業 オーダー と作業者が 「HDR-DTL」 になる。

 作業 オーダー
 {作業 オーダー 番号、ライン 番号 (R)、作業日、・・・} [ HDR ]

 作業 オーダー 明細 (1)
 {作業 オーダー 番号、作業者 コード (R)、・・・} [ DTL ]

 1つの オーダー のなかで複数の品目が扱われるのであれば、「多義」 ではない──複数の品目のなかから、1つだけが成立する、という現象ではない。すなわち、1つの作業 オーダー 明細のなかで、1つの品目が扱われる、ということである。とすれば、以下のように、「HDR-DTL」 となる。

 作業 オーダー
 {作業 オーダー 番号、ライン 番号 (R)、作業日、・・・} [ HDR ]

 作業 オーダー 明細 (2)
 {作業 オーダー 番号、品目番号 (R)、・・・} [ DTL ]

 さて、このとき、作業者の割り当てと、品目の割り当てが、べつべつに指図されているとすれば──たとえば、作業員に対する作業票と、資材の移動票が、べつべつに指図されて、ライン 上では (差立表では) 、だれが作業したかという点と、どの品目が費消されたかという点を、それぞれ、「ライン を単位として」 管理する生産形態だとすれば──したがって、「だれが、どの品目を作業する」 という管理をしていないとすれば (作業者と品目との間に的確な対応関係がないとすれば)──、上述した 2つの作業 オーダー 明細は、それぞれ、独立して成立する。
 したがって、以下のように、2つの DTL が成立する。

 作業 オーダー
 {作業 オーダー 番号、ライン 番号 (R)、作業日、・・・} [ HDR ]

 作業 オーダー 明細 (1)
 {作業 オーダー 番号、作業者 コード (R)、・・・} [ DTL ]

 作業 オーダー 明細 (2)
 {作業 オーダー 番号、品目番号 (R)、・・・} [ DTL ]

 
 ちなみに、作業者と品目との間に関係が成立していれば、以下の データ 構造が基本形になる。

 作業 オーダー
 {作業 オーダー 番号、ライン 番号 (R)、作業日、・・・} [ HDR ]

 作業 オーダー 明細
 {作業 オーダー 番号、作業者 コード (R)、品目番号 (R)、・・・} [ DTL ]

 
[ 参考 ]
 もし、作業 オーダー 明細が、時系列のあとのほうに出てくる 「event」 (例えば、「検収」 とか) に対して、明細単位で、対応するのであれば、作業 オーダー 明細のなかの 「作業 オーダー 番号」 に対して、(たとえば、リリース の順を記述した) 「枝番」 が付与されているはずである。

 



[ 補遺 ] (2009年 2月16日)

 本 エッセー を綴った 2004年の時点では、私は、いまだ、「HDR-DTL」 を 「合成関数」 として説明していないようですね。「HDR-DTL」 は多値関数であって、多値関数には、以下の 2つの関数が存在します。

 (1) OR 関係 (以下、MOR と略)
 (2) AND 関係 (以下、MAND と略)

 MOR は、たとえば、商品単価として正単価と割引単価の ふたつ (あるいは、2つ以上) が存在していて、それらの単価が共時的に成立するのではなくて、どちらかいっぽう (あるいは、多数のなかで 1つのみ) が排他的に成立する事態を云います。すなわち、ひとつの関数のなかで一つの変数の値が、一見、多値になっているけれど、実際には、値は一つしか充足されない事態です。この多値関数を本 エッセー では 「多義」 というふうに記述しています。

 いっぽう、MAND は、複数・多数の値が共時的に成立する関数です。たとえば、ひとつの受注で複数の商品が注文されるというふうに。MAND は、「合成関数」 です。たとえば、前述した 「受注」 の例で言えば、「G : 取引先 → 受注」 という写像 (関数) と 「F : 商品 → 受注」 という写像 (関数) との合成関数 「GF」 です。

 データ 構造上、MOR と MAND は、いずれも 「繰返項目 (repeating group)」 のように見えるのですが、それらの性質は全然違います。「HDR-DTL」 は、「受注」 をはじめとして 「event」 のなかで生じることが多いのですが、必ずしも、「event」 に限った現象ではないことに注意していてください (129ページ 「resource の HDR-DTL」 を参照されたい)。

 さて、「HDR-DTL」 が MAND であることを納得できれば、汎用形として活用できるでしょう。本 エッセー では、1つの HDR が複数の DTL を有する例を示しましたが、ほかの例として、「HDR-DTL」 の DTL が HDR として作用して、さらに DTL を構成するような現象が起こることもあります (289ページ 「DTL の DTL」 を参照されたい)。





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