【データベース】RDBの正規化を理解する〜第2正規形〜

はじめに

前回の続きで今回は第2正規化について学んだことをまとめたいと思います！

前回の記事はこちら

第2正規化とは？

• 部分関数従属を解消し、完全関数従属だけの状態にすること。
• 異なるレベルの実体（エンティティ）を分離する作業でもある。

完全関数従属

主キーを構成するすべての列に従属性がある状態。

部分関数従属

主キーを構成する一部の列に対して従属する列がある状態。

第2正規化の方法

部分関数従属のある従属列を切り出し、別テーブルに分割する。

例（第2正規化前〜部分関数従属の状態〜）

クラステーブル

クラスID	クラス名	教師ID	教師名	生徒ID	生徒名
1	1年A組	T001	佐藤先生	1	山田太郎
1	1年A組	T001	佐藤先生	2	鈴木花子
1	1年A組	T001	佐藤先生	3	田中次郎
2	1年B組	T002	高橋先生	4	佐々木一郎
2	1年B組	T002	高橋先生	5	伊藤美咲
3	2年A組	T003	中村先生	6	木村健太
3	2年A組	T003	中村先生	7	渡辺陽子
3	2年A組	T003	中村先生	8	山口幸子
3	2年A組	T003	中村先生	9	加藤大輔

部分関数従属の状態とは？

このテーブルの主キーは「クラスID」「教師ID」「生徒ID」になります。ただし、この例だと主キーを構成する一部の列に対して従属する列がある状態、つまり部分関数従属の状態になっています。

具体的に言うと：

• クラスID → クラス名
• 教師ID → 教師名
• 生徒ID → 生徒名

上記3つの列は、対応する主キーが決まれば、その値が一意に決まる従属性があります。ただし、クラスIDが決まっても、生徒名は一意に決まりません。同様に、教師IDが決まっても、生徒名は一意に決まりません。これは、同じクラスや担当教師には複数の生徒が存在する可能性があるからです。これが部分関数従属の状態になります。

問題点

このような状態だと以下のような問題が発生します。

1. データの冗長性: 同じクラス名や担任教師名が繰り返し記載されるため、データが冗長になる。
2. 更新異常: 担任教師の名前やクラス名を変更する場合、すべての関連する行を更新する必要があり、データの不整合が発生する恐れがある。
3. 挿入異常: 新しいクラスや教師を追加する場合、関連する生徒情報が存在しないと挿入できなくなる。
4. 削除異常: 生徒のデータを削除するとき、クラスや教師の情報も誤って削除される可能性がある。

解決方法

この状態を解消するには、部分関数従属のある従属列を切り出し、別テーブルに分割を行います。具体的には以下のように分割を行います。

• 部分関数従属のある生徒ID、生徒名を生徒テーブルとして切り出す。
• 部分関数従属のある教師ID、教師名を教師テーブルとして切り出す。
• クラステーブルにはクラスの情報だけを持たせるようにする（異なる実体のエンティティの分離）。
• 生徒テーブル、教師テーブルにクラスIDを追加し、クラステーブルと紐付ける（外部キー制約）。

例（第2正規化後〜完全関数従属の状態〜）

クラステーブル

クラスID	クラス名
1	1年A組
2	1年B組
3	2年A組

教師テーブル

教師ID	教師名	クラスID
T001	佐藤先生	1
T002	高橋先生	2
T003	中村先生	3

生徒テーブル

生徒ID	生徒名	クラスID
1	山田太郎	1
2	鈴木花子	1
3	田中次郎	1
4	佐々木一郎	2
5	伊藤美咲	2
6	木村健太	3
7	渡辺陽子	3
8	山口幸子	3
9	加藤大輔	3

第2正規化によって改善された点

1. データの冗長性の削減: 同じクラス名や担任教師名が複数回記載されることがなくなり、データがシンプルになった。
2. 更新異常の防止: 教師やクラスの名前を変更する際に、複数の行を更新する必要がなくなり、一貫性が保たれるようになった。
3. 挿入異常の解消: 新しいクラスや教師を追加する際に、生徒情報が存在しなくても挿入できるようになった。
4. 削除異常の防止: 生徒を削除しても、クラスや教師の情報が誤って削除されることがなくなり、データの安全性が向上した。

まとめ

今回は第2正規化についてまとめてみました。
何となく感覚で行なっていましたが、DB設計で留意すべき点などメリット、デメリット含め、考えることでとても学びになったように思います。
また、間違った解釈等あれば教えていただけると幸いです。

次の記事はこちら

参考書籍