第3正規形 (ダイサンセイキケイ) とは | 意味や読み方など丁寧でわかりやすい用語解説

第3正規形 (ダイサンセイキケイ) の読み方

日本語表記

第三正規形 (ダイサンセイキケイ)

英語表記

Third Normal Form (サードノーマルフォーム)

第3正規形 (ダイサンセイキケイ) の意味や用語解説

データベース設計における正規化は、データの冗長性を排除し、一貫性を維持するために不可欠なプロセスである。正規化には複数の段階が存在し、その中でも第3正規形は、実用的なデータベース設計において重要な目標とされる水準の一つである。第3正規形は、第2正規形の条件を満たした上で、さらにデータの依存関係を整理し、より矛盾の生じにくい構造を目指すものである。その核心は、主キー以外の列（非キー属性）同士で発生する間接的な依存関係を解消することにある。この手続きを正しく理解し適用することで、データベースの保守性や拡張性は大幅に向上する。 第3正規形を詳細に理解するためには、まずその定義を正確に把握する必要がある。あるテーブルが第3正規形であるための条件は二つ存在する。第一に、そのテーブルが第2正規形であること。第二に、主キー以外のどの列も、主キー以外の他の列に対して関数従属していないことである。ここで言う「関数従属」とは、ある列の値が決まると、別の列の値が一意に定まる関係を指す。例えば、「社員ID」が決まれば「社員名」が一意に決まる場合、「社員名」は「社員ID」に関数従属していると言える。第3正規形が特に問題とするのは「推移的関数従属」と呼ばれる状態である。これは、主キーから非キー属性へ、さらにその非キー属性から別の非キー属性へと、関数従属が連鎖している状態を指す。具体的には、「A→B」かつ「B→C」という関係があるとき、主キーであるAから見ると、Bを介して間接的にCの値が決定されてしまう「A→B→C」という依存関係が推移的関数従属である。第3正規化は、このような依存の連鎖を断ち切り、各列が主キーにのみ直接依存する構造を作り出すことを目的とする。 具体的な例を用いて考えてみる。ここに「注文テーブル」があり、列として「注文番号（主キー）」「顧客ID」「担当者ID」「担当者名」「担当者所属部門コード」「担当者所属部門名」を持っていると仮定する。このテーブルは、主キーが単一の「注文番号」であるため、部分関数従属は存在せず、第2正規形の条件は満たしている。しかし、このテーブルには推移的関数従属が存在する。「注文番号」が決まれば、その注文を担当した「担当者ID」が決まる。そして、「担当者ID」が決まれば、その担当者の「担当者名」「担当者所属部門コード」が一意に定まる。さらに、「担当者所属部門コード」が決まれば、「担当者所属部門名」も一意に定まる。つまり、「注文番号」→「担当者ID」→「担当者名」や、「注文番号」→「担当者所属部門コード」→「担当者所属部門名」といった、主キーから非キー属性を経由して別の非キー属性へと至る依存の連鎖が発生している。 このような推移的関数従属が存在するテーブルは、データの更新、挿入、削除の際に問題を引き起こす可能性がある。例えば、ある担当者の所属部門が営業部から企画部に変更になった場合を考える。この担当者が関わった全ての注文レコードについて、「担当者所属部門名」を更新する必要が生じる。もし一つでも更新を忘れると、同じ担当者IDに対して異なる部門名が記録され、データの不整合が発生する。また、新たに総務部が設立されたが、まだ所属する担当者がいない場合、「部門コード」と「部門名」の情報を登録することができない。なぜなら、これらの情報は注文に紐づいており、注文が存在しない限りテーブルにレコードを追加できないからである。さらに、ある担当者が担当していた唯一の注文がキャンセルされ、そのレコードを削除した場合、その担当者に関する情報（名前や所属部門など）もデータベース上から完全に失われてしまうという問題も起こりうる。 これらの問題を解決するために、推移的関数従属を排除する第3正規化を行う。具体的には、依存関係の元となっている部分を別のテーブルとして切り出す。先の例では、「担当者」に関する情報と、「部門」に関する情報をそれぞれ独立したテーブルに分離する。まず、「担当者テーブル」を作成し、「担当者ID」を主キーとして「担当者名」と「担当者所属部門コード」を管理する。次に、「部門テーブル」を作成し、「部門コード」を主キーとして「部門名」を管理する。そして、元の「注文テーブル」は、「注文番号（主キー）」「顧客ID」「担当者ID」のみを持つようにスリム化する。この「担当者ID」は、「担当者テーブル」の主キーを参照する外部キーとなる。 このようにテーブルを分割することで、先述の問題は解消される。担当者の所属部門が変更された場合、「担当者テーブル」の該当する1レコードを更新するだけで済み、データの整合性が保たれる。新しい部門が設立された場合も、「部門テーブル」に新しいレコードを1行追加すればよい。注文の存在とは無関係に部門情報を管理できる。注文レコードを削除しても、「担当者テーブル」や「部門テーブル」の情報が失われることはない。各テーブルの情報は、それぞれの主キーにのみ直接的に関数従属するようになり、データの冗長性が排除され、一貫性が高く、メンテナンスしやすいデータベース構造が実現される。このように、第3正規形は、データベースの健全性を保つための論理的な設計指針として極めて重要である。