【ITニュース解説】NORMALIZATION

データベースの正規化とは、データを効率的かつ矛盾なく管理するための設計手法である。システムエンジニアにとって、データベース設計の基礎であり、データの品質を保つ上で非常に重要となる。

まず、正規化されていないデータベースにはどのような問題があるのかを見ていこう。提供された「Base table」は、学生ID、学生名、コースID、コース名、講師名、講師電話番号といった情報が一つの大きなテーブルにまとめられている。

このようなテーブルでは、いくつかの問題が発生する可能性がある。これらは「異常（Anomalies）」と呼ばれ、大きく分けて三つある。一つ目は「挿入異常」だ。これは、例えば新しい講師の情報を登録したい場合、その講師が担当する学生やコースがまだ決まっていないと登録できない、といった問題である。講師情報だけを独立して追加することができないため、データの入力に制約が生じてしまう。

二つ目は「更新異常」だ。もし「Dr. Kumar」という講師の電話番号が変更になった場合、このテーブルでは「S01 Arjun」が「C101 DBMS」を履修している行と、「S02 Priya」が「C101 DBMS」を履修している行、それぞれの「InstructorPhone」を更新しなければならない。もし、一つでも更新し忘れると、同じ講師に対して異なる電話番号が記録されることになり、データに矛盾が生じる。データが複数箇所に重複して存在するため、更新作業が複雑になり、エラーのリスクが高まるのだ。

三つ目は「削除異常」だ。これは、例えばあるコースの最後の学生が退学し、その学生の情報をテーブルから削除した場合、そのコースの情報や、そのコースを担当していた講師の情報まで一緒に消えてしまう、といった問題である。特定の学生情報と、コースや講師の独立した情報が密接に結合されているため、特定のデータを削除した際に、意図せず他の重要なデータまで失われてしまう危険性がある。

これらの異常を解消し、データの整合性を保ち、効率的な運用を実現するために「正規化」を行う。正規化には段階があり、それぞれ「正規形」と呼ばれるルールに従ってテーブルを分割・再構成していく。

最初のステップは「第1正規形（1NF）」への変換である。第1正規形のルールは、テーブル内のすべての属性（列）が単一の値（アトミックな値）を持ち、繰り返しグループが存在しないことだ。今回の「Base table」は、すでに各セルに単一の値が格納されているため、このルールは満たされている。しかし、第1正規形では、各行を一意に識別するための「主キー」を明確に定義することが重要となる。ここでは「StudentID」と「CourseID」の組み合わせを主キーとすることで、特定の学生が特定のコースを履修しているという情報を一意に識別できるようにする。この段階ではテーブルの構造は大きく変わらないが、後の正規化のための基礎を固める。

次に「第2正規形（2NF）」への変換を行う。第2正規形のルールは、第1正規形であることに加え、「部分関数従属性」を排除することである。部分関数従属性とは、主キーが複数の列（複合主キー）で構成されている場合に、主キーの一部にのみ従属する属性が存在する状態を指す。今回の例では、「StudentID + CourseID」が主キーだが、「StudentName」は「StudentID」にのみ従属しており、「CourseName」「Instructor」「InstructorPhone」は「CourseID」にのみ従属している。

この部分関数従属性を排除するため、テーブルを分割する。具体的には、学生の情報（StudentID, StudentName）を格納する「Students」テーブル、コースと講師の情報（CourseID, CourseName, Instructor, InstructorPhone）を格納する「Courses」テーブル、そしてどの学生がどのコースを履修しているかを示す「Enrollments」テーブル（StudentID, CourseID）の三つに分割する。これにより、例えばDr. Kumarの電話番号は「Courses」テーブルに一度だけ記録され、更新の際に一箇所のみの変更で済むようになる。また、学生情報とコース情報が独立するため、挿入異常や削除異常のリスクも軽減される。

最後のステップは「第3正規形（3NF）」への変換だ。第3正規形のルールは、第2正規形であることに加え、「推移的関数従属性」を排除することである。推移的関数従属性とは、主キーではないある属性が、主キーではない別の属性に従属している状態を指す。第2正規形までで作成した「Courses」テーブルでは、「InstructorPhone」が「Instructor」に従属している。つまり、「Instructor」が決まれば「InstructorPhone」も決まるという関係があり、これは主キーである「CourseID」を介さずに、非キー属性（Instructor）から別の非キー属性（InstructorPhone）への依存関係がある状態だ。

この推移的関数従属性を排除するため、「Courses」テーブルをさらに分割する。講師の情報（InstructorID, InstructorName, InstructorPhone）を格納する独立した「Instructors」テーブルを作成し、「Courses」テーブルには「InstructorID」だけを持たせて「Instructors」テーブルを参照させる形にする。これにより、Dr. Kumarの電話番号が変更されても、「Instructors」テーブルの一箇所を更新するだけで済むようになる。また、特定の講師がどのコースも担当していない状態でも、その講師の情報を独立して登録・管理できるようになる。

最終的に、正規化によって「Students」「Instructors」「Courses」「Enrollments」の四つのテーブルが作成される。これらのテーブルはそれぞれ独立した情報を持ち、互いに「外部キー」という仕組みで関連付けられる。例えば、「Courses」テーブルの「InstructorID」は、「Instructors」テーブルの「InstructorID」を参照する「外部キー」として機能し、データ間の関係性を維持する。

正規化されたテーブルにデータを挿入する際は、それぞれのテーブルに適切な情報を入れる。学生はStudentsテーブルに、講師はInstructorsテーブルに、コースはCoursesテーブルに、そして学生の履修情報はEnrollmentsテーブルに格納される。このようにデータが構造化されることで、データの重複が大幅に削減され、データの整合性が保たれやすくなる。

正規化されたデータベースから必要な情報を取得する際は、「JOIN」という操作を用いる。例えば、学生名、履修コース名、担当講師名の一覧を取得したい場合は、Enrollmentsテーブルを起点にStudentsテーブル、Coursesテーブル、Instructorsテーブルをそれぞれの共通するID（主キーと外部キー）を使って結合することで、複数のテーブルに散らばった情報を一つにまとめることができる。

正規化は、初期設計段階での手間はかかるものの、長期的に見ればデータベースの運用コストを削減し、データの信頼性を高める上で不可欠なプロセスである。データの重複が減ることでストレージ効率が向上し、更新や削除の際の異常発生リスクを最小限に抑え、データの一貫性を保証しやすくなる。システムエンジニアとして、この正規化の概念と実践は、堅牢なシステムを構築するための重要なスキルとなるのだ。