「達人に学ぶDB設計徹底指南書」を読んだので、改めて第3章の正規化、第５章のパフォーマンスについてメモ。
正規化
DBで保持するデータの冗長性を排除し、一貫性と効率性を保持するためのデータ形式
第1正規形
1つのセルの中には1つの値しか含まない。リレーショナルデータベースのテーブルはすでに満たしている。
なぜ１つのセルに複数の値を入れてはダメなのか？
→ セルに複数の値を許せば、主キーが各列の値を一意に決定できないため
関数従属性 ✍️
X列の値を決めれば、Y列の値が１つに決まる。正規化とは、テーブルのすべての列が、関数従属性を満たすように整理していくこと。
第2正規形
テーブル内で部分関数従属を解消し、完全関数従属のみのテーブルを作る。
部分関数従属 ✍️
たとえば、主キーが{会社コード、社員ID}の時、「会社名」の列は主キーの一部である「会社コード」に依存する。
解決策
テーブルの分割を行う。部分関数従属の関係にあるキー列と従属列だけ独立のテーブルにすればいい。
なぜ行うのか
以下のように、社員の情報が不明の会社を登録することができる。また、{C0001,A商事}というレコードの他に、{C0001,A商社}のような間違ったデータが登録される危険があるが、このようなデータ誤登録の危険を格段に減らすことができる。
(p.96より引用)
→ 「会社」と「社員」という、それぞれに異なるレベルの実体を、きちんとテーブルとしても分離してやる
第3正規形
上のテーブルを見てみると、
{社員ID} → {部署コード} → {部署名}
という推移的関数従属がある。そのため、たとえば社員が一人もいない部署を登録できない。
→テーブルを分割することで関数従属の関係を独立させる。(ここでは部署テーブルを新しく独立させる)
ちなみに、正規形はいつでも非正規形に戻せる。 (4次、5次正規形はここでは割愛する)
ざっくりまとめ
正規化の利点 >>
データの冗長性が排除され、更新時の不整合を防止できる。
データの持つ意味が明確になり、開発者が理解しやすい。
正規化の欠点 >>
- テーブルの数が増えるため、SQL文で結合を多用することになり、パフォーマンスが悪化する。(このため、パフォーマンスを求めて非正規化を行うこともあるが、あくまで最後の手段とすべき)
