【SQL 】データベースの正規化について
データの正規化は、必要なデータ項目を整理し、データが重複しないように表を分割することです。データの重複を排除することで、データベース操作に伴う重複更新や矛盾の発生を防ぐことができます。
またSQLを使ってデータを取り出す時に、正規化の知識があると何のデータがどこのテーブルに保存されているか感覚的にわかるようになります。
1. データベースの正規化のメリット
正規化を知っていると、初めてみるデータベースの構成が予想できます。
データを登録、更新、削除した時のトラブルが少なくなります。
2. データベースの正規化のデメリット
データの数が多くなり、データがどこにあるかわかりにくくなります。
3. データベースの正規化の正規化について
正規化には、第1正規形から第5正規形まであり、次のような手順で正規化を行います。
3-1. 非正規形
正規化されていない表になります。
下記のテーブルを見ると、複数の商品が紐づいています。
この場合、ひとつの仕入先に対して、複数の商品が繰り返し存在しているため、非正規形になります。
3-2. 第1正規形
第1正規形では、非正規型のデータから繰り返し項目を排除し、また、計算で求められる項目を削除します。
第1正規形の定義は1つのセルには1つの値しか含まれないことです。
下記のテーブルでは、非正規形に比べて、一つのカラムに一つの値のみが入る状態になります。
3-3. 第2正規形
第2正規形では、第1正規型のデータから部分主キーの一部の項目によって決まる項目を、別の表に分離します。
下記のテーブルでは、「注文ID」が決まれば、「注文日」「注文書」が一意に決まる。
「商品ID」が決まれば、「商品名」「単価」が一意に決まる。
このように、主キーの一部の項目によって、項目が一意に決まる関係を、部分関数従属といいます。
次の「注文テーブル」「商品」を分離します。
「注文テーブル」の主キーは「注文ID」「商品」の主キーは「商品ID」になります。
この状態では注文日と注文者は複合主キーの一部である注文IDのみに依存しています。
なので、注文IDと商品IDの関連付けだけを表す別のテーブルを分離します。
下記、主キーによって、項目が決まる関係を、完全関数従属といいます。
3-4. 第3正規形
第3正規形では、第2正規型のデータから主キー以外の項目によって決まる項目を、別の表に分離します。
下記のテーブルでは、「注文ID」が決まれば、「注文者」が一意に決まり、「注文者」が決まれば、「性別」、「住所」が一意に決まる。
このように、主キー以外の項目によって、項目が一意に決まる関係を、推移的関数従属といいます。
次の「注文者テーブル」に分離します。
下記、主キーは「注文者ID」になります。
3-5. ボイスコッド正規形
第3正規型のデータから非キーへの関数従属する主キーの関数を排除します。
第3.5正規化とも呼ばれます。
非キー列の担当講師に主キー列のコース名が関数従属するため、「受講者テーブル」と「担当講師テーブル」に分離します。
下記、ボイスコッド正規化を満たした状態になります。
3-6. 第4正規形
第4正規形は、表の列が全て主キーで、自明でない多値従属性を排除します。
多値従属とは、ある項目によってある項目群が定まることを指します。
第4正規形は、関数従属に関する正規化ではなく、多重従属性に関する正規化です。
例1
例2
複数の多重従属が存在すると、レコード更新時に不整合が発生しやすくなるため多重従属性を排除します。
下記、第4正規化を満たした状態になります。
3-7. 第5正規形
第4正規化を満たしているが元の表に復元できない場合、表現しきれないリレーションを表現します。
例えばルール変更で、「受講者」は「受講コース単元」を個別で受講できるようになった場合
下記では、「受講コース単元」は「受講者」ごとに異なるため、多重従属していない関係になります。
つまり、「受講者」と「受講コース単元」間に関連性が生まれます。
例1
例2
第4正規とは違い、全て関係しあっているため、下記に分解されます。
参照:
https://bbh.bz/2019/12/04/db-normalization-illustration/#i-6
https://www.messiahworks.com/archives/3399
4. まとめ
データベースの正規化についてまとめて見ましたが、理解するのが大変でした。
非正規形から第五正規形まで紹介しましたが、正規化は整理されたデータベースを扱うために行うといいと思います、DBの設計や作成などに役立つ知識なので、ぜひ学習してみるといいと思います。