6.1 【設問】受発注（1/3）

受注エンティティの属性を抽出し、必要に応じて正規化してください。

このような明細形式の注文書は、注文番号を一意に管理する番号として、伝票単位に情報が管理されています。
注文番号ごとにすべての情報を同じように管理しようとすると、客先情報や、注文番号などの「見出し項目＝ヘッダ情報」に対して、明細の商品情報が注文した商品の数分繰り返し対応している形になります。

管理すべき情報の頻度別に、伝票ごとに1回だけ出現する「ヘッダ情報」と具体的な「明細情報」に分けて管理することによって、重複を排除し、更新時の矛盾が起きないようにします（第1正規化。受注ヘッダと受注明細に分割します）。

1. 詳細設計では、正規化された冗長性のないデータベースを設計します。
マスタ系のエンティティは今回ほとんど概略設計で抽出されていますが、受注エンティティの部分に着目して、第1正規化の作業を行います。
注文伝票の中で1回しか出てこない情報を「受注」で管理し、繰り返し出てくる情報を「受注明細」で管理します。
関連する、互いのオカレンスは、生成・更新・削除のライフサイクルが同一であり、依存関係にあるということができます

• 一意識別子の決定、外部キーの決定、属性の決定方法やリレーションの分析の詳細など、正規化の詳細手順については、「1.5 正規化の手順」や「2.3 概念設計の手順」などを参照してください

2. 受注エンティティから「社員」「部門」の両方にリレーションが引いてありますが、これは冗長ではありません
受注を受けた「社員」が所属する「部門」を管理したいわけではなく、この受注を受けた部門を管理したいという要件から、直接「受注」と「部門」の間にリレーションが引いてあります

3. 「受注」から「社員」へ2本のリレーションが引いてありますが、これは受注を受けた社員と、受注時の値引きを承認する社員という意味の異なる2つのリレーションです

4. 「消費税率」は、他のアプリケーションからも共通で参照されるべき、独立したエンティティとして抽出します

• 注文伝票から読み取れる、業務で使用されるすべての項目を属性として抽出し、エンティティの属性と一意識別子、属性、外部キーなどを表記します

5. 商品の在庫引当は、1つの「倉庫」からすべて引き当てられるとは限りません
同じ商品を複数の倉庫から引き当てた場合、受注明細行の一意識別子は、「受注注文番号」「商品コード」「倉庫コード」の3つの属性の組み合わせになります

ここまで詳細に属性を検討してくると、業務の詳細な部分や、さまざまなケースにどう対応しているのか、対応できるようにするためには、どのような項目を管理すべきか、といった疑問がわいてきます。
業務を理解し、あらゆる角度から検討した結果、場合に応じた解決策を事前に提案できるようになると、モデリングに付加価値を提供することができるようになります。

また、必要に応じて、アプリケーション的な観点から、開発チームとすり合わせるべき具体的な項目を列挙し、必要に応じて開発チームや開発依頼元に問い合わせをします。

• 1. 金額の桁数はそれぞれ何桁まで管理するのか
• 2. 値引きは金額で管理するのか、パーセントで管理するのか
• 3. 日付は時分秒まで管理するのか

たとえば、倉庫に十分在庫がある場合はこれだけでよいでしょうが、もしいくつかの商品の在庫が足らなくて、仕入れしなければならない場合、受注時に顧客に言われた希望納期に納品できるかはわかりません。
もし、納期に間に合わない場合、顧客の了解を得て商品ごとに納期の異なる出荷処理を行うことになります。
次の問題でこれに対応できるモデルを考えてみましょう。

< 前へ　｜　6.1 【設問】受発注（1/3）　｜ 次へ >