Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】Database Normalization

2025年10月04日に「Dev.to」が公開したITニュース「Database Normalization」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

データベースの正規化は、データの重複を減らし、整合性を高めるための構造化プロセスだ。記事では、学生・コース・講師データを使い、1NF、2NF、3NFのステップで不要な情報重複をなくす手順をSQLと共に解説。これにより、データ管理が効率化され、不整合を防ぐ。

出典: Database Normalization | Dev.to公開日:

ITニュース解説

データベース正規化とは、リレーショナルデータベースの構造を整理し、データの重複(冗長性)を減らし、データの正確性や一貫性(データ整合性)を高めるための重要なプロセスだ。システムエンジニアを目指す上で、この正規化は効率的で信頼性の高いデータベースシステムを設計・構築するために不可欠な概念となる。

このプロセスを理解するために、まず正規化されていないデータベースがどのような問題を引き起こすかを考えてみよう。例えば、学生のID、名前、受講コースのID、コース名、担当教員名、成績といった情報をすべて一つの大きな表にまとめて管理しているケースを想定する。このような構造には、以下のような「アノマリー(異常)」と呼ばれる問題が発生する可能性がある。

一つ目の問題は「挿入アノマリー」だ。これは、まだどの学生も受講していない新しいコースをデータベースに登録したい場合に発生する。もしコースの情報が学生の受講情報と密接に結びついて一つの行として扱われていると、コースの情報だけを独立して登録できず、何らかの学生情報がなければデータを追加できない、といった状況に陥る。

二つ目は「更新アノマリー」だ。もしあるコースの名前が変更になった場合、そのコースを受講している学生の数だけ、表の中の該当するコース名を更新する必要が出てくる。もし複数の行の中から一つでも更新し忘れると、データベース内で同じコースに異なる名前が混在することになり、データの不整合が発生してしまう。

三つ目は「削除アノマリー」だ。ある学生が退学し、その学生の情報をデータベースから削除することになったとする。もしその学生が受講していたコースに、他に受講者が一人もいなかった場合、学生の情報を削除すると同時に、そのコースに関する valuable(貴重な)詳細情報も一緒に失われてしまう可能性がある。これは、本来残しておくべきデータが意図せず削除されてしまうことを意味する。

これらのアノマリーを解消するために、データベースを段階的に正規化していく。最初のステップが「第一正規形(1NF)」だ。1NFのルールは「繰り返しグループを排除し、すべての属性がアトミック(それ以上分割できない最小単位)であること」だ。例えば、一人の学生が複数のコースを受講している場合、元の非正規形のテーブルでは一つの行の中に複数のコース情報が含まれている可能性がある。これを、各学生と各コースの組み合わせごとに個別の行として記述し直す。これにより、重複する情報が排除され、各行は「学生IDとコースID」の組み合わせによって一意に識別できるようになる。この学生IDとコースIDの組み合わせが、このテーブルの主キー(Primary Key)となる。主キーとは、テーブル内の各行を一意に識別するための項目、または項目の組み合わせを指す。

次に進むのが「第二正規形(2NF)」だ。1NFを満たした上で、2NFのルールは「部分関数従属を排除する」ことだ。部分関数従属とは、複合主キーを持つテーブルにおいて、非キー属性(主キーではない属性)が主キー全体ではなく、主キーの一部にのみ依存している状態を指す。例えば、1NFのテーブルで「学生IDとコースID」が複合主キーである場合、学生の名前は学生IDにのみ依存し、コース名や担当教員名はコースIDにのみ依存する。これらは複合主キーの「一部」にしか依存していないため、部分関数従属となる。2NFでは、このような部分関数従属を持つ属性を、その依存関係が正しい独立したテーブルに分離する。具体的には、「学生ID」と「学生名」を持つ「学生」テーブル、「コースID」「コース名」「担当教員名」を持つ「コース」テーブル、そして「学生ID」「コースID」「成績」を持つ「履修」テーブル、というようにテーブルを分割する。これにより、更新アノマリーのような問題が解消され、例えばコース名を変更する際に、「コース」テーブルの該当箇所を一度更新するだけで済むようになる。この分割されたテーブル間には、主キーと外部キー(Foreign Key)という関係が構築される。外部キーとは、他のテーブルの主キーを参照し、テーブル間の関連付けを行うためのキーだ。

最後に進むのが「第三正規形(3NF)」だ。2NFを満たした上で、3NFのルールは「推移的関数従属を排除する」ことだ。推移的関数従属とは、非キー属性が主キーではなく、他の非キー属性に依存している状態を指す。例えば、先の「コース」テーブルに「担当教員名」と「担当教員電話番号」が含まれている場合を考える。「担当教員電話番号」は「コースID」に直接依存するのではなく、「担当教員名」という別の非キー属性に依存している。つまり、「コースID」→「担当教員名」→「担当教員電話番号」という推移的な依存関係がある状態だ。3NFでは、このような推移的関数従属を持つ属性を、その依存関係が正しい独立したテーブルに分離する。この例では、「担当教員ID」「担当教員名」「担当教員電話番号」を持つ「担当教員」テーブルを新たに作成し、「コース」テーブルからは「担当教員名」と「担当教員電話番号」を削除し、代わりに「担当教員ID」を外部キーとして持たせる。これにより、担当教員の電話番号が変わっても、「担当教員」テーブルの一箇所を更新するだけで済み、データの管理がさらに容易になる。また、特定の教員がどのコースも担当していない場合でも、教員の情報だけを独立して保持できるようになるため、挿入アノマリーの解消にも繋がる。

このように、非正規形から1NF、2NF、3NFと段階的に正規化を進めることで、多くのメリットが得られる。最も大きな利点は、データの冗長性が大幅に削減されることだ。同じ情報が複数箇所に重複して存在することがなくなるため、データベースの容量を節約できるだけでなく、データ更新時の手間や不整合のリスクが大幅に軽減される。次に、データ整合性が向上する。データが一意に、かつ正確に保たれるようになり、アノマリーの発生を効果的に防げるため、データベース全体の信頼性が高まる。 さらに、複数のテーブルに分割されたデータは、必要に応じてSQLのJOIN(結合)操作を用いることで、元の大きなテーブルのように結合して情報を取得できる。例えば、学生の名前、受講しているコースの名前、そのコースの担当教員の名前を一覧で表示したい場合、学生、履修、コース、担当教員の各テーブルを、それぞれのキー(主キーと外部キー)を使って結合することで、必要な情報を効率的に取得できる。これにより、複雑な情報も柔軟に取得できるようになる。 正規化されたデータベースは、データの管理やメンテナンスがしやすくなり、アプリケーション開発においてもデータの扱いが明確になるため、システム全体の安定性と効率性を向上させるための強固な基盤となるのだ。

関連コンテンツ