データベース設計の基礎

要点と定義

データベース設計では、業務で扱う対象、その属性、対象同士の関係を整理し、データモデルに表します。E-RモデルやUMLでは、実体・属性・関連とカーディナリティを使って構造を捉えます。弱実体は、関連先の実体がなければ存在できない実体です。例えば、注文に属する明細は、注文が存在しない状態では存在できないものとしてモデル化できます。

関係を表にする際は、1対1ならどちらかの表に相手のキーを外部キーとして置く方法があります。1対多なら多側に1側のキーを置き、多対多なら両側のキーを持つ表を設けます。1対1の対応を保つには、外部キーの一意性など、対応数を守る制約も考えます。

項目の定義と、時点ごとに増える記録は分けて考えます。例えば、設備の点検項目には項目名や最新の基準値を持たせ、点検記録には対象設備、項目、実施日時、測定結果を対応付けます。これにより、一つの項目について複数回の記録を保持できます。

関数従属X→Yは、Xの値が決まるとYの値も一意に決まる関係です。候補キーは、関係の全属性を決定でき、かつ真部分集合では全属性を決定できない属性集合です。属性閉包は、与えられた関数従属を繰り返し適用して決定できる属性を集めたものです。候補キーをすべて求める場合は、閉包が全属性になることと極小性を確認し、ほかの最小集合がないかも調べます。

候補キーを確かめるには、まず候補属性集合の閉包を計算し、全属性に届くかを確認します。例えば、関係の属性がP、Q、R、S、Tで、PQ→R、R→S、ST→Q、Q→Tが与えられたとします。PQからR、S、Tが得られ、全属性を決定できます。PまたはQを除いた集合では全属性に届かないため、PQは候補キーです。

正規化は、データの重複や更新時の矛盾を抑えるために表の構造を整える考え方です。第1正規形では繰返し項目を避け、属性値を原子的に扱います。第2正規形では、複合キーの一部だけで非キー属性が決まる部分関数従属をなくします。第2正規形を満たしていても、非キー属性を介して別の非キー属性が決まる推移的関数従属があれば、第3正規形の確認が必要です。

第2正規形の関係が第3正規形でもあるかを確認するときは、推移的な従属に加え、関数従属の決定項がスーパーキーか、決定される属性が主属性かという条件を見ます。第1正規形の原子性や、第2正規形の部分関数従属の条件だけでは、第3正規形かどうかは決まりません。

索引は列の値の性質と検索内容に合わせて選びます。ビットマップインデックスは、状態区分のように異なる値の種類が少ない列で候補になります。値ごとのビット列を使い、複数条件を組み合わせて検索できます。

適用条件と例

例えば、書籍の貸出と会員の関係を考えます。一人の会員が複数の書籍を借りられ、一冊の書籍も時期を変えて複数の会員に貸し出されるなら、貸出を独立した記録として表せます。貸出表に会員のキーと書籍のキーを外部キーとして持たせ、貸出日時などを記録します。対応数と、記録ごとに必要な属性を先に整理します。