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

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

　ライン
　｛ライン 番号、ライン 名称、・・・｝［ 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」 （例えば、「検収」 とか） に対して、明細単位で、対応するのであれば、作業 オーダー 明細のなかの 「作業 オーダー 番号」 に対して、（たとえば、リリース の順を記述した） 「枝番」 が付与されているはずである。