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

要点と定義

データベース設計では、対象業務に必要なデータとデータ間の関連を整理し、E-R図やUMLなどで表した概念モデルから、表とキーを設計します。関連の多重度は、表への変換方法を考える手掛かりです。

表では、主キーが行を識別し、外部キーが参照先の行を示します。1対1の関連は、一方の表に相手の主キーを外部キーとして置いて表せます。1対1を保つには、その外部キーに一意性が必要です。1対多では多側の表に1側のキーを置き、多対多では両側のキーを持つ対応表を設けます。

E-R図の多重度は、外部キーがどちらの表にあるかと、各行がいくつの相手に結び付くかを照らして読みます。例えば、医師の表が診療科コードを持つなら、各医師はそのコードで一つの診療科を参照し、一つの診療科には複数の医師が所属し得ます。診察の表が診療科コードと患者番号を持つ場合も、各診察記録が参照する診療科と患者を別々に確認します。

正規化は、データの重複や矛盾を抑えるために表を整理する考え方です。第1正規形から第3正規形までの条件を確認し、特に第2正規形では部分関数従属、第3正規形では推移関数従属などに着目します。候補キーや関数従属性を確認し、どの属性が何によって決まるかを整理します。

過去の出題で扱った補足として、関係Rの候補キーが複数ある場合、第3正規形を満たしてもボイス・コッド正規形を満たさないことがあります。出題例では、関数従属性の右辺が候補キーに含まれる素属性であることが第3正規形の判断に関わり、左辺がスーパーキーでないため、ボイス・コッド正規形の条件は満たしません。

表の分解では、結合して元の情報を復元できる情報無損失性と、分解後の表で元の関数従属性を確認できる関数従属性保存性を区別します。過去の出題で扱った補足として、第3正規形への分解はこの二つを満たすよう構成できますが、すべての正規化分解が常に両方を満たすわけではありません。

過去の出題で扱った補足として、関数従属性から属性集合の閉包を求めるときは、左辺の属性がすべてそろった従属性だけを適用し、その右辺を加えます。また、従属性の集合から冗長性を調べるときは、一つを取り除いても元の従属性を導けるかを確認します。

適用条件と例

会員と講座の双方に複数の相手があり得るなら、対応表に会員番号と講座番号を外部キーとして置きます。申込日など、関連ごとに決まる属性も対応表に置けば、どの組合せに関する情報かを表せます。

親子関係のモデルは、組織レベルの追加や親の数などの要件に合わせて選びます。自己参照の方式では、組織の親を最大一つとする階層を表せます。親子関係を別に記録する方式では、一つの子に複数の親を対応させることもできます。その方式で親子関係の循環を許さない要件がある場合は、循環を防ぐ制約が必要です。これらは過去の出題で扱った補足です。

属性集合の閉包の自作例として、初期集合を「商品番号」とします。「商品番号から商品名が決まる」「商品名から分類が決まる」という従属性なら、まず商品名を加え、続いて分類を加えます。「分類と倉庫番号から保管区画が決まる」という従属性は、倉庫番号が集合にないため、この時点では適用できません。このような閉包計算は、過去の出題で扱った補足です。