データベース設計

要点と定義

データベース設計では、業務で必要な情報と情報同士の関係を整理し、目的に合う表と制約に落とし込みます。設計の段階を分けると、業務上の対象や関連を表す概念設計、表・列・キーを定める論理設計、保存方法や性能を考える物理設計に整理できます。

概念設計では、管理対象をエンティティ（実体）、その性質を属性、エンティティ間のつながりをリレーションシップ（関連）として表します。E-R図はデータの構造を表すもので、業務手順やデータの生成から消滅までの流れを表す図とは役割が異なります。また、関係データベースの表として実装することだけを前提とする表現でもありません。UMLなどでも、対象、属性、関連、多重度を表せます。たとえば「会員」と「注文」を置き、一人の会員が複数の注文を行える関連を表せば、業務データの構造を整理できます。 関連の多重度は、たとえば一対一、一対多、多対多で表します。UMLの図では、部門と社員の関連に加え、事業部が部門の一種であることや、管理関係の多重度を読み取ることで、「社員が事業部に所属し得る」ことと「すべての部門が事業部に管理されるとは限らない」ことを区別できます。

論理設計では、表（テーブル）を、同じ種類の情報を持つレコードの集まりとして設計します。列（属性）には一つの意味の値を持たせ、主キーでレコードを識別します。複数列の組合せを主キーにする場合もあります。別の表の主キーを参照する列が外部キーです。外部キーは、参照先に存在しない値が登録されることを防ぐなど、表同士の参照一貫性を保つために使います。物理的な配置を近づけたり、障害後に復旧したりする目的とは異なります。

関数従属 X→Y は、同じ X の値に対して Y の値が一つに定まる関係です。表の実データを確認するときは、同じ X に異なる Y がないかを調べます。たとえば、架空の配送記録で「配送先→地域コード」が各配送先で一つに決まるなら、その記録上では関数従属が成立します。一方、同じ配送日に複数の地域コードがあれば「配送日→地域コード」は成立しません。標本の行だけから判断する場合は、その行に示された値の範囲での成立を確認している点にも注意します。

正規化は、データの重複や更新時の矛盾を減らすために表を整理する手順です。第1正規形では列の値を繰返し項目にせず、各欄を一つの値として扱います。第2正規形では、複合主キーの一部だけで決まる属性を分け、キー全体に完全関数従属させます。第3正規形では、キー以外の属性を介して決まる属性を分け、推移関数従属による重複を抑えます。分割の際は、分割前に得られた情報を必要に応じて結合で再構成できるか、主キーや外部キーで関連が保てるかも考えます。

適用条件と例

表を設計するときは、どの情報を知りたいのか、その情報をどの行からどう識別するのかを先に確認します。遊園地の例なら、入園者表に入園時刻と退園時刻があれば、両者の差から滞在時間を求められます。しかし、それだけでは誰がどのアトラクションを利用したかは分かりません。その情報には、入園者番号、利用時刻、アトラクション番号を持つ利用記録が必要です。表に記録された項目と記録単位から、得られる情報を判断します。

お気に入り数を持つ表が「店舗番号」と「お気に入り数」で構成されるなら、店舗番号で対象行を特定します。店舗名や所在地が別表にあっても、それだけでお気に入り数の表の行を識別できるとは限りません。必要な検索キーは、目的の値を保持する表のキーと照らして決めます。