🛁

イラストで理解するデータベースの正規化

2023/06/11に公開

Database

tech

はじめに

データベースを設計するにあたり特に理解していなければいけないことの一つが正規化です。
業務でデータベースを設計されている方にとっては当たり前のことばかりかもしれませんが、非常に重要な概念のため、わかりやすく図を用いてまとめてみました。

想定する読者

データベース設計についてこれから学習される方

正規化とは

正規化とはデータベースの冗長性をなくし、一貫性を持ったデータ形式にすることです。
正規化を行うことで、データの不整合を防止することができます。

正規化の種類

正規化には複数のレベルがあり、ここでは第１正規形〜第５正規形までの解説を行います。

第１正規形

第１正規形はとても単純で「一つのセルの中には一つの値しか含まない」というものです。

なぜ第１正規形でなければならないかというと、非正規形の例では主キーから各列の値を一意に決定できないからです。
リレーショナルデータベースでは主キーが各列の値を一意に決定できなければならないという決まりがあり、この概念を関数従属性と呼びます。

第２正規形

第１正規形の例で出したテーブルの主キーは海賊団コードと団員コードです。
このとき海賊団名と海賊団コードは関数従属性があり、このように主キーの一部の列に対して従属する列があることを部分関数従属と呼びます。
この部分従属を排除して完全関数従属のみのテーブルを作ることが第２正規形にあたります。

部分関数従属を解消するために行うことはテーブルの分割です。
図の例では海賊団テーブルを新たに作り、海賊団名を移動させることで第２正規化を行いました。
では第２正規形ではないテーブルの場合はどのような不都合があるでしょうか？
それは所属する団員が決まっていない海賊団をテーブルに登録できないことです。
また海賊団を改名することになった際も、非正規形では複数のレコードを更新しなければなりませんが、第２正規形のテーブルの場合は海賊団テーブルの一行を更新するだけで済みます。

第３正規形

第３正規形の説明をするために、第２正規形のテーブルに海賊団での中の役割を表すカラムを追加します。

今は団長、戦闘員、航海士という役割しかありませんが、今後別の役割を持ったメンバーが加入する可能性があります。
しかし現在のテーブルには団員のいない役割はテーブルに登録することができません。
このように【海賊団コード】→【役割コード】→【役割】と言うように二段階の関数従属がある状態を推移的関数従属と呼びます。
第３正規化するためには第２正規形と同様に役割の部分を別テーブルに切り離します。

ボイス・コッド正規形

第３正規形と第４正規形の間にはボイス・コッド正規形（3.5 正規形と呼ばれることもある）が定義されています。
以下の図がボイス・コッド正規形を満たしていないテーブルと、正規化されたテーブルです。

左側のテーブルでは主キーである団員コード・海賊団コードからキャプテンへの関数従属性があります。
一方で各海賊団にキャプテンは一人なので、キャンテンから海賊団コードに対しても関数従属性があります。
このような非キーからキーへの関数従属性をなくした状態をボイス・コッド正規形と呼びます。

第４正規形

図の左側のテーブルは第３正規形のテーブルに武器カラムを追加したものです。
第４正規形
海賊団と団員のようなエンティティ同士の関連を表したものを関連エンティティと呼びます。
第３正規形のテーブルでは海賊団と団員の関連エンティティのみ表していましたが、図の例では武器のエンティティも含んでいます。
このテーブルでは団員コードが定まると複数の武器データが定まります。このようなキーと集合との対応を他植従属性と呼びます。
多値従属性が複数存在するテーブルを分割することで第４正規化を行うことができます。

第５正規形

第５正規形は第４正規形の発展版となります。

先ほどの例で海賊団と武器に関連があると想定します（無理矢理ですが、麦わら海賊団でなければ和道一文字が使えないというルール）。
そうすると最初のテーブルでは海賊団コードと武器の従属性がわからないため、海賊団コードと武器の関連エンティティを作る必要があります。
このように関連がある場合はそれに対応する関連エンティティを作る、ということが第５正規形のルールです。

正規化のメリット・デメリット

ここまで正規化の種類についてまとめてきましたが、正規化を行うことにはメリットだけではなくデメリットも存在します。
そのためパフォーマンス向上のために、あえて非正規化を行うようなこともあります。

メリット

データの冗長性が排除される
テーブルの持つ意味が明確になり、開発者が理解しやすい

デメリット

データを抽出する際にテーブルの結合が増え、SQL のパフォーマンスが悪化する

さいごに

最後まで記事を読んでいただきありがとうございます。
ここまで読んでいただいた方の中には、全部当たり前のことを言っているだけじゃないかと感じた方もいるかもしれません。
そのことについてミック氏の『達人に学ぶ DB 設計徹底指南書』の中では、正規化のメリットはその当然さにあり、常識を定式化することで誰もが利用可能なツールにすることができ道を外れた設計を防ぐことができるようになる、と述べられています。
当たり前のことだからこそ、原理原則として身につけておきたい知識です。