ここまでのモデルは、受注に対する条件を「受注備考」を使用して管理していこうというモデルとなっています。
しかし、取引に関する条件は様々な条件が存在するはずです。
例えば「キャンセル可能日数」といった取消に関する条件や、「当月売上翌月入金」「3ヶ月支払手形」「現金・振込み」「半分現金・半分手形」といった売上や入金に関する条件等などです。
それらの情報を「受注備考」で管理しようとすれば、テキストで必要な情報を登録していくしかありません。
また、取引条件のみではなく得意先への注意事項やイレギュラー処理の情報等取引条件とはまったく異なった情報が登録される可能性もあります。
その場合、ある取引条件に該当する受注を見たいといった場合、備考に記述されている内容から判断して処理をする必要が出てきます。
そこで、受注に対する取引条件を別途エンティティとして独立させ管理するようにし、当該エンティティにて取引条件を管理します。
取引条件は上記のように1つの受注に対して複数存在することが考えられますし、逆にある取引条件というのは複数の受注に対して指定されることが考えられます。
従って、受注と取引条件はN対Mの関係になりますので、中間(関連)エンティティを追加し、以下のように定義します。
取引条件以外の補足情報を定義するために、「受注備考」は残しておきます。
※コメント投稿者のブログIDはブログ作成者のみに通知されます