変更要約: 初版
3.2データベース設計と正規化（関係モデル・E-R図・正規化(1〜3NF)・主キー/外部キー/参照制約）
データを実体（エンティティ）と関連（リレーションシップ）で捉えるE-R図（実体関連図）、業務要件をデータモデルへ落とし込むデータモデリング、重複と更新異常を排除する正規化（第1正規形・第2正規形・第3正規形と各段階の関数従属の判定）、行を一意に識別する主キー、他表を参照する外部キーと参照制約（参照整合性）を、応用情報技術者としてE-R図からの導出手順を含めて深く学びます。
データベース設計は応用情報技術者試験のテクノロジ系で最も安定して出題される分野の一つです。基本情報技術者では正規化の結果（どの表に分割されるか）を問う設問が中心でしたが、応用情報ではなぜその分割が必要かを関数従属の観点から説明できるか、業務要件をE-R図として正しくモデル化できるかまで踏み込んで問われます。「部分関数従属」「推移的関数従属」という用語の違いを、単なる暗記ではなく具体例で判定できることが得点の鍵です。
3.2.1E-R図とデータモデリング
- E-R図（実体関連図）＝業務に登場する対象をエンティティ（実体）、対象間の関わりをリレーションシップ（関連）として図示するモデリング手法。エンティティは属性（列）を持ち、リレーションシップには多重度（カーディナリティ）＝1対1・1対多・多対多がある。
- 多対多の関連は関係データベースの表では直接表現できないため、両者の主キーを持つ連関エンティティ（中間表）を新たに設け、多対多を「1対多」×2に分解する。例：「学生」と「講座」は多対多だが、「履修」という連関エンティティ（学生ID・講座ID・成績）を挟むことで正しく表現できる。
- データモデリング＝業務要件を整理し、エンティティ・属性・関連を抽出してE-R図に落とし込む工程。業務で使われる名称のゆれ（「顧客」と「取引先」が実は同じ対象を指す等）を統一し、重複したエンティティを作らないことが設計品質を左右する。
3.2.2正規化と関数従属の判定
- 関数従属＝ある列（決定項）の値が決まれば別の列（従属項）の値が一意に定まる関係（例：「商品ID→商品名」）。第1正規形（1NF）＝繰り返し項目を排除し各セルを単一値にする。第2正規形（2NF）＝1NFに加え、複合主キーの一部だけに従属する列（部分関数従属）を分離する。
- 第3正規形（3NF）＝2NFに加え、主キー以外の列に従属する列（推移的関数従属）を分離する。判定手順は「
①主キー全体に従属しない列はないか（部分従属→2NF違反）→
②主キーではない列に従属する列はないか（推移的従属→3NF違反）」の2段階で機械的に確認できる。 - 主キー（PRIMARY KEY）＝行を一意に識別する列（重複・NULL禁止）。外部キー（FOREIGN KEY）＝他表の主キーを参照する列。参照制約（参照整合性）＝外部キーの値が参照先に実在する値のみを許可する制約で、違反する更新・削除（親を先に削除する等）はDBMSが拒否するか、カスケード（連動）で子も併せて処理する設定が選べる。
「多対多は連関エンティティで1対多×2に分解」「部分関数従属=複合主キーの一部への従属(2NF違反)」「推移的関数従属=非キー列への従属(3NF違反)」「外部キーは参照整合性を保証し、違反する削除は拒否かカスケード」が最頻出です。具体的な表の列を示し「この列はどの正規形に違反しているか」を関数従属の観点から判定させる設問が中心になります。
受発注システムのE-R図を設計する場面を考えましょう。「顧客」エンティティと「商品」エンティティは、1件の注文で複数商品を扱い、同じ商品が複数の顧客に注文されるため多対多の関係にあります。関係データベースの表では多対多を直接表現できないため、両者の主キー（顧客ID・商品ID）に加えて数量・単価を持つ「注文明細」という連関エンティティを新設し、「顧客―注文明細」「商品―注文明細」という2つの1対多に分解します。次に、この「注文明細」表に（注文ID, 商品ID）という複合主キーを設定し、列として数量・単価に加えて誤って「商品名」まで持たせてしまったとします。商品名は複合主キーの一部である商品IDだけに従属し、注文IDには依存しないため、これは部分関数従属にあたり第2正規形違反です。商品名を切り出した「商品」表（商品ID・商品名・単価）に分離し、注文明細表には商品IDのみを外部キーとして残すことで解消します。さらに「注文」表に注文ID・顧客ID・顧客名をまとめて持たせていた場合、顧客名は主キー（注文ID）ではなく非キー列の顧客IDに従属する推移的関数従属であり第3正規形違反です。「顧客」表（顧客ID・顧客名）に分離し、注文表には顧客IDを外部キーとして残します。ここで、ある顧客を「顧客」表から削除しようとしたとき、その顧客の注文が「注文」表に残っている場合、参照制約によりDBMSは削除を拒否するか、注文側も連動して削除するカスケード削除を設定しておく必要があります。カスケード削除を安易に有効化すると、過去の注文履歴が顧客削除と同時に失われるという業務上の問題を招くため、削除ではなく論理削除（フラグで無効化）を採用する設計判断も実務ではよく行われます。
| 正規形 | 排除する対象 | 判定の着眼点 |
|---|---|---|
| 第1正規形(1NF) | 繰り返し項目（1セル複数値） | 各セルが単一値か |
| 第2正規形(2NF) | 部分関数従属 | 複合主キーの一部だけに従属する列がないか |
| 第3正規形(3NF) | 推移的関数従属 | 非キー列に従属する列がないか |
ひっかけ： 「複合主キーを持つ表は必ず2NF違反」は誤りです。複合主キーの一部だけに従属する列がある場合にのみ2NF違反となり、キー全体に従属する列（例：数量が(注文ID,商品ID)の組み合わせに従属）は問題ありません。「外部キーがあれば必ず参照整合性が保たれる」も誤りで、参照制約を有効化していなければ存在しない値を登録できてしまいます。「多対多の関連はそのまま2つの表で表現できる」という誤解も禁物で、連関エンティティ（中間表）が必要です。
3.2.3この節のまとめ
- 多対多はそのまま表現できず、連関エンティティで1対多×2に分解。E-R図は業務名称の統一が設計品質を左右
- 部分関数従属(複合主キーの一部への従属)=2NF違反・推移的関数従属(非キー列への従属)=3NF違反を機械的に判定
- 外部キー＋参照制約=参照整合性。削除時は拒否かカスケードかを設計判断（履歴保全には論理削除も選択肢）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 「注文明細」表は(注文ID, 商品ID)を複合主キーとし、数量・単価に加えて「商品名」を列として持つ。商品名は商品IDのみに従属し注文IDには依存しない。この状態を説明するものはどれか。
Q2. 「学生」と「講座」は、1人の学生が複数講座を履修し、1つの講座に複数学生が登録できる関係にある。この多対多の関連を関係データベースで正しく表現する方法はどれか。
Q3. 「顧客」表からある顧客を削除しようとしたところ、その顧客の注文が「注文」表に外部キーとして残っている。参照制約が有効な場合、DBMSの標準的な挙動として適切なものはどれか。