【正規化の要点をギュッと凝縮】第1正規化から第3正規化まで

3392 ワード
DB設計 SQL 正規化 DB SQL テキストリンク

はじめに

DBの設計を意識したポートフォリオ作成がしたかったため、最低限必要な第1正規化から第3正規化を理解するためにインターネットの記事を見ながら自分なりに要点をまとめてみました。
参考にした記事は本文の一番最後に記載しております。

正規化はなぜ必要?

・正規化とはDBの矛盾を設計レベルで防ぐこと

⇒正規化を正しく行うことで矛盾のないDBを設計することができるようになる！

・正規化は非正規形から第6正規形まであるが、基本的には第3正規形までできてればOK

・不整合が起こるのを防ぐことで、メンテナンスの効率UPにつながる

例）社員テーブル更新時の矛盾

営業部の部長が「佐藤」から「中山」に変更になった際に、社員の鈴木の行の部長名が変更できてない

覚えておきたい用語

候補キー（≒ 主キーやユニークキー）

テーブル上で任意のレコードを特定するためのカラムのこと。

例えば、社員番号などは主キーに値する。

非キー

主キー（PRIMARY KEYやUNIQUE）以外のカラムのこと。

関数従属

あるレコードにおいてXの値が決まれば、Yの値も特定できる関係のことを関数従属という。

⇒候補キー（主キー）が決まれば、他の値も定まる

例）社員番号

社員番号が決まれば、付随する「名前」、「部署」、「役職」を特定することができる。

この場合、「名前」、「部署」、「役職」は「社員番号」に関数従属していると言える。

部分関数従属

複合主キーの一部の項目だけで列の値が特定できる関係のことを部分関係従属という。（詳細は第2正規化で！）

上記は1つの候補キー（主キー）によって特定できる関係、部分関数従属は複数の候補キーによってそれぞれ特定できる関係というイメージ。

推移的関数従属

主キー以外の列に関数従属している列のことを推移的関数従属という。

第1正規形から第3正規形まで

第1正規形

テーブル形式（表形式）で表現できる形であれば第1正規化の条件はクリア！

ただ注意点としては、テーブルの横の長さは統一すること。

第2正規形

部分従属しているものを切り離し、従属関係を分離させる方法を第2正規化という。

例）受注管理テーブル（第1正規形）を第2正規化する

第3正規形

第2正規化で分離したテーブルを更に分離するこを第3正規化という。

上記の図のテーブルはこれテーブルはこれ以上分離することはできないが、更に細かく分離することで表に追加情報を付け加えやすくなることに加え、より管理効率を上げることができる。

最後に

最後までご覧頂きありがとうございます。
まだまだ知識不足なので、認識が異なる部分ございましたら教えていただけると嬉しいです。

参考

https://qiita.com/mochichoco/items/2904384b2856db2bf46c

https://medium-company.com/正規化/

https://breezegroup.co.jp/202005/database-normalization/

https://oss-db.jp/dojo/dojo_info_04