データベースの正規化

正規化は RDB を使用するときの一般的な設計方法のこと。
正規化自体知ってはいたのだが、定義や手法をちゃんと調べたことがなかったので、
個人的に整理をしてみた。

正規化(Normalization)とは

データの重複をなくし、整合的にデータを取り扱えるようにデータベースを設計すること。
正規化の段階にはいくつかあり、一般業務では第３正規形まで準拠すれば良しとされる。
※第 3 正規形以上の正規形は「高次正規系」と呼ばれる

• 非正規形
• 第 1 正規形
• 第 2 正規形
• 第 3 正規形
• ※ボイス・コッド正規形（第 3.5 正規形）
• 第 4 正規形
• 第 5 正規形

なぜ正規化が必要なのか

なぜ正規化が必要なのかは以下のような理由がある。

1. データの一貫性を保持する

重複データを減らすことにより、データに一貫性を維持できる。
重複しているデータ同士が少し違う値を持っていると整合性が取れなくなる場合がある。

ex)
「山田太郎」と「山田 太郎」のどっちが正しいのか判断できない。
RDB ではスペースが入るだけで別のデータとして扱われてしまう。

2. データの冗長性を排除する

無駄な重複データを減らすことにより、
無駄なデータ領域を減らしたり、面倒な更新処理を短縮することができる。
サービスやデータ量が大きくなればなるほど恩恵は大きくなる。

3. データ柔軟性、拡張性の向上

テーブルが適切に分割されているため、データの拡張が容易になる。
将来の追加や変更などにも柔軟に対応することができる。

正規化することのデメリット

正規化することのデメリットもある。

1. データベース設計の複雑化

正規化のプロセス自体が複雑なので、設計自体に専門的な知識が必要になる。
そもそも開発者がデータベースへの知見を持っている必要がある。

2. クエリの複雑化

複数テーブルに分割されるため、関連テーブル同士を結合が前提となる。
これによりクエリが複雑化し、クエリの実行時間が増加する可能性がある。
大量のデータがある場合には、パフォーマンスの低下も引き起こしかねない。

正規化の手法

非正規形〜第三正規形までの正規化手法。

例で使用するテーブルは「達人に学ぶ DB 設計」に記載しているテーブルを参考にしてます。

非正規形

正規化が行われていない状態。
1 行の中に複数の折り返し項目が存在していると、非正規形となる。
正規化をするにはまず、「1 つのフィールドに 1 つの値」の原則を守る必要がある。

社員テーブル

第 1 正規形

「1 つのフィールドに 1 つの値」の原則が守られている状態。
「1 つのフィールドに 1 つの値」の値のことをスカラ（Scalar）値という。

社員テーブル

最低限スカラ値の状態ではないと、関数従属性がないとして RDB として認められない。
関数従属性とは、関数「Y = f(X)」のように、X が決まると Y が決まる状態のこと。

RDB でいうと、以下のように書くことができる。
{X} → {Y}

上記テーブルで言うと以下のような関数従属性になる。
{会社 ID, 社員 ID} → {社員名}

第 2 正規形

主キーの一部にある関数従属性を解消した状態。
≒ 部分関数従属を解消し、完全関数従属になっている状態。

・主キーの一部の関数従属性 → 部分関数従属
・部分関数従属を解消した状態 → 完全関数従属

社員テーブル

会社テーブル

第 1 正規形の社員テーブルで以下の従属性があったのだが、
{会社 ID, 社員 ID} → {社員名}

主キーの会社 ID にも関数従属性（部分関数従属）があった。
{会社 ID} → {会社名}

この部分関数従属を解消するため、
社員テーブルを分割して会社テーブルを作成した。

第 3 正規形

テーブル内に存在する段階的な関数従属性を解消した状態。
≒ 推移的関数従属解消した状態。

・テーブル内に存在する段階的な関数従属性　 → 　推移的関数従属

社員テーブル

会社テーブル

部署テーブル

第 2 正規形では部署 ID と部署名にも段階的な関数従属性（推移的関数従属）があった。
{会社 ID, 社員 ID} → {部署 ID} → {部署名}

この推移的関数従属を切り出して部署テーブルとするのが、第 3 正規形。

参考

https://www.shoeisha.co.jp/book/detail/9784798124704

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