Relational DataBaseにおける正規化について｜ブログ

はじめに Relational DataBaseの設計工程には正規化と呼ばれる手順があります。 今回は正規化がどういうものなのかと手順について説明していきます。 正規化について 正規化とは？ 正規化とは、データベースの設計手法の一つで、データの重複や不整合を防ぎ、データの整合性を保つためのプロセスです。 正規化を行うことで、データの更新や削除時に発生する問題を防ぐことができます。 正規化された表のことを正規形と呼びます。 正規化のメリット データの冗長性を削減 同じデータが複数箇所に保存されるのを防ぎます。 データの整合性を向上 更新や削除時に発生する矛盾を回避します。 データ操作の効率化 テーブル間の関係性が明確になるため、検索や更新が容易になります 正規化のデメリット パフォーマンスの低下 正規化によりデータが複数のテーブルに分割されるため、データを取得する際にテーブル結合が必要になり、クエリの実行速度が遅くなることがあります。 業務における正規化 上記メリット、デメリットを考慮して、DBの設計時に適切に正規化を行っていく必要があります。 業務では第三正規形まで考えることが多いため、今回は第三正規形までを取り上げます。 第一正規形について 第一正規形の定義 「一つのセルの中には一つの値しか含まない」 一つのセルに一つだけの値が含まれているとき、この値のことを「スカラ値(scallar value)」と呼びます。 英単語でscallar とは「単一の」の意味です。 第一正規形の例 非正規化データ 非正規化例 上記の表では「商品名」、「価格」のセルに二つの値が入っています。 これを第一正規形にしてみましょう。 第一正規形 Relational DataBaseになじみのある方なら、よく見慣れた形になったかと思います。 Relational DataBaseでは、いずれもすべて第一正規形を満たす形になっています。 第二正規形について 第二正規形の定義 第一正規形を満たした上で、部分関数従属を排除します。 関数従属・・・主キーが決まると、列の値が一意に定まる関係のこと。 部分関数従属・・・複合キーの一部に依存するカラムが存在すること。 複合キー・・・複数の属性（列）を組み合わせて一意にレコード（行）を識別するキーのこと。 第二正規形の例 先ほどの第一正規形の例 ここでの複合キーは「注文ID」と「商品名」です。 部分関数従属しているカラム 「顧客名」と「注文日」は「注文ID」に依存していますが、「商品名」には依存していません。 部分関数従属しているカラム 「顧客名」と「注文日」は「注文ID」に依存していますが、「商品名」には依存していません。 部分関数従属を解消するために、テーブルを分割します。 第二正規形の例 第二正規形まで完了しました。続いて第三正規形も進めましょう。 第三正規形について 第三正規形の定義 推移的関数従属を排除する 推移的関数従属・・・ある属性が主キーに直接依存せず、他の非キー属性を介して依存すること。 第三正規形の例 先ほどの第二正規形の例 注文詳細テーブルにおいて、主キー（Primary Key）の役割を果たすのは、「注文ID」と「商品名」の組み合わせの複合キーになります。 推移的関数従属しているカラム 「価格」は「商品名」に依存していますが、「商品名」は「注文ID」に依存しています。 ｛注文ID｝→｛商品名｝→｛価格｝ 「価格」は「注文ID」に直接依存せず、「商品名」を介して依存しています。 これが推移的関数従属している状態です。 推移的関数従属を解消するために、テーブルを分割します。 第三正規形の例 商品テーブルに分割し、商品テーブルの主キーの「商品ID」が、注文詳細テーブルでは「商品ID」として外部キーになります。 まとめ 今回の例の最終的なテーブル構成 ※今回は正規化の手順説明を簡易にわかりやすくするために、顧客情報を「顧客名」のみで想定しています。 実際に顧客情報は、「住所」や「メールアドレス」、「電話番号」など、様々な情報を持っていることが多いので、顧客情報のみを格納した「顧客」テーブルを別に切り出すことが多いと思います。 ※注文詳細テーブルについても、実際のデータベース設計では、操作性や管理のしやすさを考慮して、一意の識別子（注文詳細ID）を追加することが一般的ですが、今回は正規化の手順説明のため考慮していません。 データベース設計の際に、適切にテーブルを正規化することによって正規化のメリットを享受していきましょう。