データベース設計の基礎

要点と定義

データベース設計では、業務で扱うものや事柄を分析し、どのデータを、どのような関係で管理するかを定めます。E-Rモデルのエンティティは管理対象となる実体や概念を表し、その特徴を属性で記述します。エンティティは物理的なものに限らず、注文などの概念も表せます。注文をエンティティとし、注文番号や注文日を属性にする、といった設計ができます。

エンティティ間の関連には、対応する個数の範囲（カーディナリティ）を定めます。例えば、一つの部署には従業員が0人以上所属でき、一人の従業員は1部署以上に所属する設計なら、従業員の複数部署への所属は許されますが、部署に所属しない従業員は許されません。関連の両端で、どちら側の個数を示すのかを確認します。

データ項目やコードは、意味をそろえ、必要な情報を読み取れるように設計します。表意コードはコードの記号から内容を推測しやすい方式です。コードの桁ごとに意味を持たせる方式や、単に連番を割り当てる方式とは役割が異なります。たとえば「赤い商品」を表す記号を含めれば内容を推測しやすくできますが、コードの意味を変えるときは既存データとの整合も考慮が必要です。

論理設計では、表の行を一意に識別する主キーと、別の表の行を指す外部キーを定めます。主キーは単一列の場合も、複数列の組合せの場合もあります。年度と受診者IDの組を主キーにすれば、同じ受診者の年度ごとの結果を別々の行として管理できます。外部キーは参照先のキーとの対応を表すため、参照先に存在しない値を登録できないようにするなど、表間の一貫性を保ちます。NULLは値がないことを表し、主キーにはNULLを使えません。

表の設計では、同じ事実を何度も記録して更新漏れや矛盾を生まないよう、データの意味と関数従属を確認します。関数従属「A→B」は、Aの値が決まればBの値も一意に決まることを表します。例えば注文コードから顧客コードが決まり、顧客コードから顧客住所が決まるなら、注文コードから顧客住所が推移的に決まります。

正規化は、データの重複や更新時の不整合を抑えるため、表を段階的に整理する考え方です。第1正規形では、各項目を繰返しのない値として扱います。第2正規形では、第1正規形を満たしたうえで、複合主キーの一部だけに従属する項目を分けます。第3正規形では、第2正規形を満たしたうえで、キー以外の項目を介した推移的な従属を分けます。完全関数従属はキー全体に依存すること、部分関数従属は複合キーの一部に依存することです。

適用条件と例

複数の表を設計するときは、管理対象の単位を見極めてキーを選びます。書籍情報をISBNごとに管理し、所蔵する個々の本を別に管理するなら、ISBNは書籍情報表のキー、書籍番号は所蔵個体のキーにできます。同じISBNの本を複数冊買った場合、書籍情報を重複登録せず、個体ごとに書籍表へ追加します。貸出表は書籍番号を外部キーとして参照します。

外部キーで参照されている行を削除するときは、参照関係を壊さない順序が必要です。例では、対象ISBNに対応する書籍番号を調べ、その番号を参照する貸出行を削除し、次に書籍行、最後に参照元の書籍情報行を削除します。先に書籍情報行を消すと、書籍表に参照先のないISBNが残ります。実際の削除可否や処理順は、設定した制約や削除規則にも依存します。

別の例として、申込者情報と検査農産物情報を申込データベースに置き、検査結果情報を別のデータベースに置く場合を考えます。検査農産物情報に申込者IDを持たせれば、どの申込者の農産物かをたどれます。検査結果情報に検査農産物IDを持たせれば、その農産物の検査結果を対応付けられます。各IDは、参照先表のキーと対応するように設計します。