「達人に学ぶ DB設計指南書」を読みました その2
はじめに
「達人に学ぶ DB設計指南書」は、翔泳社より出版されている書籍です。
https://www.shoeisha.co.jp/book/detail/9784798124704
今回は、こちらの書籍のまとめや感想などをお伝えします。
その1はこちら。
https://yajima.sytes.net/posts/20230613
内容まとめ
第3章 論理設計と正規化 ～なぜテーブルは分割する必要があるのか？
テーブルとは、共通点を持ったレコードの集合である。
テーブルは必ず複数形で書ける。そうでなければ、設計が間違っている。
テーブルには主キー（primary key）がある。
設計上、主キーは必ず作らなければならない。
他テーブルとの関連を表す列として「外部キー（foreign key）」を設置できる。
外部キーを設定する = 参照整合性制約。
外部キーは、親子関係と似た関係。
他の制約として、以下の3つが挙げられる。
- NOT NULL制約
- NULLを許可しない
- 一位制約
- 一意性を求める
- CHECK制約
- 取りうる値の範囲を制限する
データの冗長性を排除し、一貫性と効率性を保持するための形式を正規形と呼ぶ。
正規形は1から5まで存在するが、通常は第3正規形まで理解すれば十分。
第1正規形
第1正規形は、一つのセルの中には一つの値しか含まないようにすること。
例えば、1つのセルに複数の値がカンマ区切りで入っているようなカラムは正規化されていない。
第2正規形
第2正規形は、部分関数中属性を排除すること。
例えば、ある列がある列の値に依存している場合は正規化できていない。
その場合は別テーブルに切り出すなどの対処が必要となる。
第3正規形
第3正規形は、推移的関数従属を排除すること。
例えば社員テーブルの「部署コード」を考えると、「誰も所属していない部署は作れない」という状況になっている。
| 社員ID | 部署コード | 部署名 | 社員名 |
|---|---|---|---|
| A001 | B0001 | 営業部 | テスト 太郎 |
こういった、テーブル内に存在する段階的な関数従属性を排除するのが第3正規化である。
第4正規形
第4正規形は、多値従属性を排除すること。
例えば、一つのテーブルに社員IDとチームコード、製品コードがある場合、「社員コードにチームコードと製品コードが依存している」状況である。
これをそれぞれ別テーブルに切り出すのが第4正規化と呼ばれる。
第5正規形
第5正規形は、関連がある場合はそれに対応する関連エンティティを作ること。
例えば、第4正規形の「社員 - チーム」「社員 - 製品」では、チームと製品の関係性は表現できない。
（もし特定のチームは特定の製品しか使えない決まりだったら？）
そこで第5正規形では、もう一つ「チーム - 製品」エンティティを作成する。
こうすることで、関連するエンティティを一対一の関係で表現することができる。