2.1概念設計とE-R図

データベース設計者が最初に取り組むのは、業務の対象（顧客・注文・商品など）を漏れなく捉え、それらの間にどんな関係があるかを整理する概念設計です。ここでのモデル化の精度が甘いと、後工程の正規化やSQL実装がいくら正しくても、業務要件を表現できないスキーマができあがってしまいます。この節では、E-R図による概念設計の基本と、関係データベースでは直接表現できない多対多の関連をどう関係スキーマへ落とし込むかという設計判断を学びます。

2.1.1実体・関連・属性

• 実体（エンティティ）＝業務上区別して管理したい対象（顧客・商品・注文など）。実体は関係データベースでは1つの表に対応することが多い。実体が持つ性質は属性（顧客の氏名・住所など）として表現し、実体を一意に識別する属性の組が候補キーの元になる。
• 関連（リレーションシップ）＝実体同士のつながり（「顧客が注文を出す」「注文が商品を含む」など）。関連自体も属性を持つことがある（例：「注文が商品を含む」関連が持つ「数量」は、顧客にも商品にも属さず関連そのものの性質である）。

2.1.2カーディナリティ（多重度）

• カーディナリティ＝関連に参加する実体のインスタンス数の対応関係。1対1（1人の社員が1台の社用PCを使う）・1対多（1人の顧客が複数の注文を出す）・多対多（1件の注文が複数の商品を含み、1つの商品が複数の注文に含まれる）の3種で表現する。
• カーディナリティの判定を誤ると、後で関係スキーマに外部キーを置く場所やテーブル分割の方針そのものを間違える。「実際に1件のインスタンスが相手側を何件まで持ちうるか」を業務ヒアリングで確認してから確定させるのが実務の鉄則。

2.1.3多対多の関連の解消

• 関係データベースの1つの表は、外部キーという形で1対多までしか直接表現できない。多対多の関連は、両実体の主キーを外部キーとして持つ「連関実体（中間表）」を新設して1対多×2に分解することで解消する。
• 連関実体には、関連そのものが持つ属性（「注文明細」なら数量・単価等）を格納できる。連関実体の主キーは両外部キーの組（複合主キー）にするのが基本形だが、業務上その組合せ自体が繰り返される場合（同一注文で同一商品を複数回・条件を変えて発注する等）は、独自のサロゲートキーを追加する設計判断もありうる。

あるECサイトのデータベース設計者が、「注文」と「商品」の関係をE-R図に落とし込んでいます。ヒアリングの結果、1件の注文には複数の商品が含まれ、1つの商品は複数の注文に登場しうることが分かったため、これは多対多のカーディナリティだと判断しました。ここで設計者が誤って「注文」表に商品IDを複数列（商品ID1・商品ID2・商品ID3…）として追加する設計を提案したとします。この設計は、注文に含まれる商品数の上限をあらかじめ決め打ちしなければならず、上限を超えた注文が来た時点で列を追加するスキーマ変更が必要になる、更新時異常の温床です。正しい解消法は、「注文明細」という連関実体を新設し、注文IDと商品IDの両方を外部キーとして持たせ、さらにこの関連自体が持つ属性である「数量」「販売時単価」をこの注文明細表に格納することです。注文明細表の主キーは基本的に（注文ID, 商品ID）の複合主キーになりますが、もし「同一注文で同一商品を、異なる納期指定で複数回発注できる」という業務要件が判明した場合は、(注文ID, 商品ID)だけでは行を一意に識別できなくなるため、注文明細IDという独自のサロゲートキーを追加する設計に切り替える必要があります。このように、カーディナリティの判定と連関実体の主キー設計は、業務ルールの細部（同一組合せの繰り返しを許すか）まで踏み込んで初めて確定できる判断です。

2.1.4この節のまとめ

• 実体＝表・属性＝列・関連＝表間の対応関係として業務を捉えるのがE-R図
• カーディナリティ（1対1/1対多/多対多）は業務ヒアリングで確定させ、後工程の外部キー設計を左右する
• 多対多の関連は連関実体（中間表）を新設し1対多×2に分解して解消する。中間表の主キー設計は業務ルール次第