注文・明細・商品の関係

概念データモデルは、業務で管理したい事実と、その事実の間の制約を表します。文章中の名詞をすべて独立したエンティティにするのではなく、何を1件として識別し、どの属性を、いつの状態として記録するかを決めます。ER図と関係スキーマを往復して、業務ルールを実装できる形へ落とし込みます。

対象・出来事・識別子を分ける

顧客、商品、倉庫などは管理対象、注文や入出荷は業務上の出来事として扱うことが多いですが、名称だけで分類しません。「入荷予定」と「入荷実績」を区別する必要があれば別の事実としてモデル化します。イベントの属性が必ず不変とは限らず、訂正や状態遷移を保存するかも要件で決まります。

識別子は、同名の顧客や同じ日に発生した注文を区別できなければなりません。氏名や日付だけで一意になると仮定せず、問題文の識別規則を確認します。注文番号が全社で一意なのか、店舗内だけで一意なのかによって、キーと外部キーの構成が変わります。

業務条件	一方から見た関係	逆方向
注文には必ず1顧客を指定する。顧客は注文前に登録できる	注文→顧客：1	顧客→注文：0以上
確定注文には1件以上の明細がある	確定注文→明細：1以上	明細→注文：1
明細は1商品を指定し、商品は注文前に登録できる	明細→商品：1	商品→明細：0以上

「1対多」の最大数だけでは、未注文顧客や明細のない注文を許すか決まりません。注文の作成途中なら明細0件を許し、確定時に1件以上を検査する設計もあります。図がどの業務状態を表すのかを先に定めます。

外部キーは参照先の存在を検査し、NOT NULLと組み合わせると子から親への必須参照を表せます。一方、「すべての親に子が1件以上ある」という制約は、外部キーを付けただけでは保証されません。状態変更時の検査など、別の仕組みが必要です。

注文・明細・商品の関係

矢印は参照関係を簡略化したものです。正確な最小・最大の個数は上の表で確認します。

学生の氏名は学生、講義の単位数は講義、学生が講義を履修した結果の評点は履修に属します。多対多は、両者の識別子を持つ連関エンティティで表すと、関連の属性と一意性を明示できます。多対多の関係そのものが第1正規形に違反するわけではありません。1行に複数の講義コードを詰め込むような表現が問題になります。

学生と講義の組をキーにできるのは、その組の履修が1回だけの場合です。再履修を許すなら年度や開講回なども識別に必要です。代理キーを採用しても、業務上の重複を防ぐUNIQUE制約は別に検討します。

個人会員と法人会員に共通する会員番号・連絡先を親に置き、固有の属性を子に置くモデルでは、すべての会員がどちらかに必ず属するか、両方に属せるかを確認します。完全性と排他性は別の制約です。単に親子の表へ分けただけで、これらすべてが保証されるとは限りません。

子を識別するために親のキーが必要な関係と、単に親を参照する関係も区別します。図記法の線種やキーの下線は問題に示された凡例に従います。特定の記法の意味を別の記法へ持ち込まないようにします。

条件：社員は複数の案件に参加でき、同じ案件に役割を変えて再参加できる。参加開始日でその参加を区別する。

問い：参加に必要な候補キーを挙げよう。

解答例：社員番号・案件番号・参加開始日。

根拠：社員と案件だけでは再参加を区別できない。参加終了日や役割は、その参加に属する属性となる。

条件：商品は注文前に登録可能で、注文明細は必ず1商品を参照する。

問い：商品から明細への最小多重度が0となる理由を説明しよう。（35字以内）

解答例：注文されていない商品も登録できるため。（19字）

根拠：明細から商品への必須参照とは別に判定する。

例の数値や業務条件を変えて同じ結論になるか確認してください。用語の定義だけでなく、問題文のどの条件から、どの制約・SQL・対策を選んだのかを自分の言葉で説明できれば、次の過去問に進みます。