関係の正規化

関係の正規化とは

関係の正規化は、リレーショナルデータベースにおいて、データの一貫性を保ち、効率的なデータアクセスを可能にするための重要な設計手法です。具体的には、関係（テーブル）を正規形と呼ばれる形式に準拠させることで、データの冗長性や不整合を減らすことを目指します。

正規形には様々な種類がありますが、いずれも、データの重複を避け、更新時の矛盾を防ぐことを目的としています。しかし、完全に正規化されたデータベースは、検索パフォーマンスが低下する場合があるため、現実的には、データの一貫性とパフォーマンスのバランスを考慮した設計が求められます。

正規形の定義の解釈

あるテーブルが正規形であるためには、単に現在のデータが定義に適合するだけでなく、将来的にデータの増減があっても定義から外れないように、列（属性）が設計されている必要があります。重要なのは、テーブルには、各列に対応する現実の事象を表すデータのみが入るという制約を前提としている点です。例えば、気温のテーブルには、あり得ない気温のデータや、関係のないデータ（政治家の情報など）が入ることは想定されません。正規化とは、特定の要件に基づいた、妥当なデータベース設計を導くための方法です。

したがって、テーブルの形式的な定義だけでは、それが正規形かどうかを判断することはできません。各列の意味やシステム要件を理解することが不可欠です。ただし、列の名前が自己説明的である場合は、その意味を明示的に定義しないこともあります。

著名な正規形

数多くの正規形が定義されていますが、特に重要なのは、第一正規形から第五正規形、およびボイス・コッド正規形です。これらの正規形は、データの一貫性を保証するための段階的な基準を示しており、後の正規形は、前の正規形の条件をすべて満たしています。例えば、第三正規形は必ず第二正規形です。これらの正規化は、実務でも広く用いられますが、通常は第三正規形までで十分と考えることが多いです。

第一正規形（1NF）

テーブル内のすべての値がスカラ値（それ以上分割できない値）であるとき、そのテーブルは第一正規形であるといいます。スカラ値とは、単一の数値や単語など、それ以上分解できない値のことです。テーブルや配列、カンマで区切られた文字列などはスカラ値ではありません。第一正規形を満たさないテーブルは、リレーショナル演算の対象とすることができません。

第一正規形の定義は、リレーショナル演算が単一の値として定義された以上のデータ分割を扱えないため、分解が必要なデータは、最初からスカラ値として格納する必要があることを意味します。ある値がスカラ値かどうかは、その値をさらに分解して操作する必要があるかどうかで判断します。複数のスカラ値を組み合わせたデータ（繰り返しグループ）を格納する場合は、それらを分割して別々のテーブルに格納し、主キーと外部キーで関連付けることで第一正規形にします。

第二正規形（2NF）

テーブルが第一正規形であり、かつ、すべての非キー属性が、すべての候補キーに対して完全従属するとき、そのテーブルは第二正規形であるといいます。つまり、候補キーの一部に関数従属する非キー属性があってはなりません。

関数従属：属性Aが属性Bに関数従属するとは、Bの値が決まると、常にAの値が一つに定まることを意味します。これをB → Aと表します。Bを決定項、Aを従属項といいます。

部分従属：複数の属性からなる決定項の一部にのみ関数従属することをいいます。
完全従属：複数の属性からなる決定項全体にのみ関数従属することをいいます。

非キー属性：候補キーでない属性、および候補キーの一部でもない属性をいいます。

第二正規形でないテーブルは、非キー属性がその他の属性と独立して挿入・削除・更新できないため、更新異常が発生する可能性があります。第二正規形は、この問題を一部解決しますが、推移的な関数従属性（後述）は残ります。

例：{会社コード, 代表者氏名, 従業員番号, 従業員氏名} という従業員台帳テーブルで、{会社コード, 従業員番号} が候補キーである場合、会社コード → 代表者氏名 という部分従属があるため、このテーブルは第二正規形ではありません。

第三正規形（3NF）

テーブルが第二正規形であり、かつ、非キー属性があるならば、それら全てが候補キーに非推移的に関数従属するとき、そのテーブルは第三正規形であるといいます。

推移的な関数従属：候補キーA → B、かつB → Cである場合、CはAに推移的に関数従属するといいます。推移的に従属する属性に従属する非キー属性も同様です。

第三正規形の目的と利点は、第二正規形と同様ですが、第二正規形が候補キーの一部に対する従属を問題にするのに対し、第三正規形は他の非キー属性に対する従属を問題にします。

例：{会員番号, 氏名, 所属店コード, 所属店名} という顧客会員台帳テーブルで、会員番号 → 所属店コード、かつ、所属店コード → 所属店名である場合、所属店名は会員番号に推移的に従属するため、このテーブルは第三正規形ではありません。

第二正規形のテーブルは、常に無損失に第三正規形に変形できます。ただし、分解方法によっては、更新異常を防ぐために、両テーブル間のデータ関連を監視しなければならない場合があります。

ボイス・コッド正規形（BCNF）

テーブルに存在するすべての自明でない関数従属性の決定項が候補キーであるとき、そのテーブルはボイス・コッド正規形であるといいます。すなわち、すべての属性が候補キーに完全従属します。ボイス・コッド正規形は、ほとんどの場合第三正規形と同等ですが、複数の属性からなる候補キーが複数存在する場合に差異が生じることがあります。第三正規形は非キー属性を従属項とする関数従属性のみを問題にするのに対し、ボイス・コッド正規形は、候補キーを構成する属性間に候補キーを決定項としない関数従属性が存在することを許容しません。

第四正規形（4NF）

テーブルがボイス・コッド正規形であり、候補キーではない属性への多値従属性をもった属性が存在しないとき、そのテーブルは第四正規形であるといいます。

多値従属性：属性Aに対する属性Bの値の集合が、Aの値のみに依存し、他の属性の値には依存しない場合、BはAに多値従属するといいます。これをA Bと表します。

例：{コース, 参考図書, 講師} という講義コーステーブルで、コース 参考図書、かつ、コース 講師の場合、このテーブルは第四正規形ではありません。

第五正規形（5NF）

テーブルが第四正規形であり、結合従属性の決定項が候補キーのみである場合、そのテーブルは第五正規形であるといいます。

結合従属性：テーブルRが、属性A, B, ..., Z上の射影の結合と等しいとき、Rは結合従属性 * (A, B, ..., Z) を満たすといいます。

例：{精神科医, 保険会社, 病気} という医療情報テーブルで、精神科医と保険会社と病気の間に特定のルールがある場合、このテーブルは第五正規形ではありません。

ドメイン・キー正規形

ドメイン・キー正規形では、すべての制約はドメイン（値の範囲）とキー制約の結果として生じるものでなければなりません。

まとめ

関係の正規化は、データベース設計において非常に重要な概念です。データの冗長性を排除し、更新時の矛盾を防ぐことで、データベースの信頼性と効率性を向上させることができます。各正規形の定義と意味を理解し、システムの要件に合わせて最適な正規化レベルを選択することが大切です。

もう一度検索