データベース設計と正規化

要点と定義

データベース設計では、業務に必要なデータとその意味・関連を整理し、重複や矛盾が起きにくい構造にします。データ項目の標準化は、同じ意味の項目が異なる名前で登録されたり、同じ名前が異なる意味で使われたりするのを抑えるために行います。業務全体の要件からデータを整理するトップダウンと、既存の帳票やデータから共通項目を整理するボトムアップがあります。

過去の出題で扱った補足として、データ管理者（DA）は組織で使うデータの定義・標準や論理設計を担い、データベース管理者（DBA）は容量・性能・障害対応などデータベースの実装・運用を担うという役割分担が問われています。例えば、顧客属性の定義をそろえる仕事はDA、記憶容量や性能を管理する仕事はDBAに近いと考えます。役割は組織の体制で異なり得ますが、設問の判断ではデータの意味・論理構造か、運用資源・性能かを見分けます。

概念設計では、エンティティ、属性、関連と多重度を整理します。論理設計では、それらを表、列、主キー、外部キーなどに対応させます。主キーは行を識別し、外部キーは別の表の候補キーを参照します。参照制約は、参照先が存在しない値を登録して関係が壊れることを防ぐ制約です。例えば貸出表の会員番号を会員表の番号に結び付ければ、貸出記録がどの会員に属するかを表現できます。参照元の表と参照先の表を取り違えず、データモデルの関連に沿って設計します。

多対多の関連を関係データベースで表す場合、関連自体を記録する中間表を設け、両側の表を参照するキーを持たせる方法があります。例えば、受講者と講座の組合せごとに申込記録を持つとき、申込表が受講者番号と講座番号を参照します。両方の番号は申込を識別する複合キーの一部になり得ますが、同じ組合せの記録が一つに限られるかは業務上の条件で確認します。

正規化は、データの重複や更新時の不整合を抑えるために表を整理する考え方です。第一正規形は繰返し項目を持たず、属性値を一つずつ扱える形にします。第二正規形は第一正規形を満たし、複合主キーの一部だけで決まる非キー属性を分けます。第三正規形は第二正規形を満たし、非キー属性を介して決まる別の非キー属性を分けます。順に条件を満たす必要があり、第二正規形から第三正規形への変換では推移的な関数従属が判断の中心です。

適用条件と例

例えば、作業記録の表を「担当者番号・案件番号・作業時間・担当者名・部署番号・部署名」で構成し、担当者番号と案件番号の組を主キーとします。作業時間がその組全体で決まり、担当者名と部署番号は担当者番号で決まり、部署名は部署番号で決まるとします。担当者情報は複合キーの一部だけで決まるため、第二正規形にする際は担当者表へ分けます。さらに部署名は部署番号を介して担当者に結び付くため、第三正規形では部署表として分けます。この例の従属関係が成立することが前提で、実際のキーや分割は業務要件から確かめます。

正規化は更新の一貫性を高めますが、表の結合が増えると処理性能に影響することがあります。性能要件がある場合は、正規化による更新容易性と、非正規化などによる参照性能を評価して設計します。非正規化を選ぶ場合も、重複データをどう更新・整合させるかを検討します。

概念モデルから表に移す際は、関連の多重度と識別条件を確認します。多対多の関連なら中間表が必要になることが多く、親側の識別子を外部キーとして持たせます。参照制約は参照元の値が参照先に存在することを要求します。参照先の行を追加する操作と、参照元に未登録の識別子を持ち込む操作では影響が異なるため、どちらの表がどちらを参照しているかを追って判断します。