top of page

データベースの正規化

  • 執筆者の写真: のろ
    のろ
  • 2 日前
  • 読了時間: 3分


はじめに

ITとは「情報技術」のことを指します。

IT関連のあらゆるテクノロジーは、情報つまりは”データ”を、より効果的に扱うための手段だと言えます。


それだけに、データはシステムの中心にある最も重要な存在だといっても過言ではありません。そして、そのデータを管理し、活用するための土台となるのがデータベース(DB)です。


この記事は、データベースについて学んだことを、自分なりに整理した備忘録です。同じように勉強している方の参考にもなれば嬉しいです。




正規化とは

データベースに保存するデータの冗長性を排除し、一貫性を保つデータ構造に整理する作業を「正規化」と言います。

簡単に言えば「データを役割ごとに分け、重複や矛盾が起きないようにするための考え方」です。


正規化は、データベース設計の段階で非常に重要な工程であり、正規化されていないデータ構造は運用上さまざまな問題を引き起こす可能性があります。


なお、正規化にはいくつかの段階があり、実務上は第3正規形まで理解しておけば十分とされています。




関数従属性

まず、正規化を語るうえで非常に重要な概念である「関数従属性」について説明します。

関数従属性とは、「Xが定まればYも一つに定まる性質」のことです。


関数従属性

データベース設計では、各カラムの値が主キー(PK)によって一意に決定される状態にすることが望ましいとされています。




第1正規形~第3正規形

それでは、実際に各正規形について説明します。

Excelのような表形式のデータをイメージしながら、関数従属性を理解していれば、どの正規形もそれほど難しくありません。


  • 第1正規形

    1つのセルに複数の値が入らないようにする


  • 第2正規形

    主キーが複合キーの場合、主キーの一部にのみ従属するカラムを分離する


  • 第3正規形

    主キー以外のカラムに従属するカラムを分離する

    すべてのカラムが主キーのみに従属する状態にする



データは段階的に第1正規形→第2正規形→ 第3正規形へと整理されていきます。




正規化の欠点

正規化は、あくまでデータベース設計における理論的な考え方であり、実務では意図的に正規化を行わない場合もあります


正規化していくとデータ構造は複雑になり、テーブルが複数に分かれます。

その結果、データを取得する際に複数のテーブルを結合する必要が生じ、SQLのパフォーマンスが低下する可能性があります。


このような場合は、非正規化によって対応することもあります。

ただし、前述の通りデータの冗長性が高くなるため、どちらの設計が適切か状況に応じた判断が必要です。




さいごに

今回は『達人に学ぶDB設計徹底指南書』を参考に、データベースの正規化をざっくりまとめました。

次回は、論理設計の最終的なアウトプットとなる「ER図」について解説します。




参考サイト

bottom of page