データベースの正規化とは

データベースの正規化は、データを特定のテーブル構造に整理するデータベース設計プロセスです。これは、データの整合性を向上させ、データの異常を防止し、データの冗長性を最小限に抑え、照会のパフォーマンスを強化するのに役立ちます。

正規化では、データベース管理システム（DBMS）内のテーブルが、正規形と呼ばれる、テーブル内での属性の整理方法を規定する一連のルールを満たすように最適化されます。これらのルールは主に、行を一意に識別するために使用されるキーを含む属性（列）間の関係に基づいています。

中核を成すデータベースの正規化（データの正規化とも呼ばれる）によって、企業や組織は、大量の複雑で相互に関連した動的なデータをより効率的に整理、照会、維持できます。企業は現在、前例のない規模でデータを生成して保管していますが、データベースの正規化の必要性は目新しいことではありません。それはクラウド・ストレージやデータウェアハウスの発明よりも前から存在しています。

1960年代以来、企業は大規模なデータセットの管理に奮闘してきました。1970年代に、リレーショナル・データベースを紹介した画期的な論文で知られるIBMの数学者Edgar F. Coddは、データベースの正規化によって、属性（列）とそれによって発生する可能性のある問題との間の「望ましくない」依存関係を回避できると提唱しました。

つまり、データベース構造内でデータ・レコードが相互に関連付けられている場合、大規模で複雑なテーブル内の単一の値やいくつかの行を変更しただけでも、データの不整合やデータの損失などの意図しない結果が生じる可能性があります。データベースの正規化は、このようなリスクを最小限に抑えるように設計されています。

データベースの正規化には、次のようなメリットがあります。

データ構造の正規化によって、次の3種類の異常を防ぐことができます。

挿入異常：挿入異常は、テーブルの1つ以上の列で必要な値がMissing Valuesであるため、データ・レコードをテーブルに挿入できない場合に発生します。

削除異常：削除異常は、あるレコードを削除することで、そのレコードに含まれる重要なデータを意図せず削除してしまう場合に発生します。

更新異常：更新異常は、データのインスタンスがデータベース内のある場所では更新されるものの、そのデータ値が保管されている別の場所では更新されず、データの一貫性が失われる場合に発生します。

リレーショナル・データベースで、キーとは、テーブル内のデータ行を識別するために使用される1列または複数列の順序付きの集合です。リレーショナル・モデルのキーは、関連するテーブル間の関連付けも確立します。これらの機能により、SQL Databaseの照会を正確かつ効率的に実行できます。データベースの正規化ルールで主に使用されるキーには、次のようなものがあります。

• 主キー
• 複合キー
• 候補キー
• 外部キー
• スーパーキー

主キーは、各行または各レコードの一意の識別子として機能する値を持つ、データベース・テーブル内の列（複数の場合もある）です。例えば、学生ID列を、学生情報のテーブルの主キーにすることができます。主キーの特徴としては、null値が除外され、重複する値がなく、単一の列または複数の列のいずれかで構成できます。

2つ以上の列で構成されるキーは、複合キーと呼ばれます。主キーが複合キーである場合は、複合主キーと呼ばれることもあります。

候補キーとは、主キーの特性を持っているものの、主キー・ステータスが割り当てられていない列または列のグループのことです。

あるテーブルの外部キーは、別のテーブルの特定の主キーを参照することで、両テーブル間の関係を定義します。正規化中に大きなテーブルが小さなテーブルに分割されると、外部キーと主キーによって新しいテーブルの間に関連付けが確立されます。

スーパー・キーは複合主キーと似ていますが、レコードを一意に識別するために必要なものよりも多くの列で構成されます。

いくつかのデータベースの正規化制約は、主キーと、主キーでも候補キーでもない列との間の関係（依存関係とも呼ばれる）に基づいています。後者は、非キー属性または非プライム属性として知られています。

ある属性（決定要因）が別の属性の値を決定するデータベース内の属性間の関係は、機能依存関係と呼ばれます。属性間の機能的な依存関係の種類には、部分依存関係、推移的依存関係、複数値依存関係、結合依存関係などがあります。これらの関係は、関連する正規化ルールのセット、または正規形のコンテキストの中で説明されると最もよく理解できます。

データ・モデルで正規化を実行するには、正規化（正規形とも呼ばれる）の1つまたは複数のレベルに適合するようにテーブルを設計する必要があります。一般的な形式は、次のとおりです。

• 第1正規形
• 第2正規形
• 第3正規形とBoyce-Codd正規形
• 第4正規形
• 第5正規形

第1正規形（最も基本的なデータベースの正規化基準）では、データベース・テーブルのスキーマに主キーが含まれ、列間の繰り返しが除外されている必要があります。より具体的には、第1正規形のテーブルには、値の配列を持つフィールド（例えば、3つの異なる名前を持つ1つのセル）を含めるべきではなく、同じ型のデータを保管する異なる列である繰り返しグループを含めるべきでもありません。

第1正規形をよりよく理解するために、次の列のセットを例として使用します¹。

列は親のグループのテーブルで構成され、名前、誕生日、結婚記念日、Eメール・アドレス、子供の名前が含まれています。

このテーブルは、同じ種類の情報（子供の名前）を保管する3つの個別の列が含まれているため、第1正規形に違反しています。特にこの場合、テーブル構造が挿入エラーの原因となる可能性があります。例えば、現実の世界では、多くの親にとって子供は3人未満です。

例示用のテーブルでは、そのような親レコードはテーブルに追加できません。さらに、このテーブルから子供の名前を照会する場合、各行の3つの異なる列からデータを検索する必要があり、非効率です。

テーブル内のデータの第1正規形を実現するには、元のテーブルを2つに分割する必要があります。一方のテーブルには元のテーブルのほとんどの属性を含め、もう一方のテーブルは子を中心としたものにします。

テーブル1

テーブル2

rec_num         child_name

この例では、新しいテーブルは「rec_num」列によってリンクされたままになります。「rec_num」列は、テーブル1の主キーであり、テーブル2の「rec_num」列（外部キーとして機能する）によって参照されます。

第1正規形を満たすと冗長なデータは減らない可能性がありますが（親に複数の子がある場合、「rec_num」の値はテーブル2の複数の行に表示されます）、繰り返しグループをなくすことで照会をよりシンプルにできます。

第2正規形では、テーブル内の主キーに部分的に依存する非キー属性はありません。つまり、主キーが複合キーである場合、非キー属性はその複合キーのすべての列に依存する必要があります。

例えば、特定の倉庫に保管されている特定の部品の数量の記録を含むインベントリー・テーブルについて考えてみましょう。次の図は、インベントリー・エンティティーの属性を示しています²。

この例では、「part」列と「warehouse」列が複合主キーを形成しています。ただし、属性「warehouse_address」は「warehouse」の値のみに依存するため、このテーブルは第2正規形に違反しています。

このテーブルではデータの冗長性が生じがちであり、同じ倉庫の部品のレコードがテーブルに表示されるたびに、warehouse_addressの値がリストされます。これにより、ある行で所在地が更新され、他の行では更新されなかった場合、更新エラーが発生するリスクが高まります。1つの倉庫が部品の保管を停止した場合にも、削除エラーが発生する可能性があります。それらの部品の記録が削除されると、倉庫の所在地も削除されます。

第2正規形を満たし、エラーの可能性を低減するために、データを2つの新しいテーブル間で分散できます。

テーブル1

テーブル2

warehouse                                warehouse_address

第3正規形のテーブルは、第1正規形と第2正規形の両方を満たすと同時に、非キー属性が主キーではなく他の非キー属性に依存する状況を回避します。非キー属性が他の非キー属性に依存している場合、これは推移的依存関係と呼ばれ、第3正規形の違反となります。

以下の従業員情報のテーブルについて考えてみましょう³。

このテーブルでは、主キーは「emp_num」列です。ただし、「dept_name」列は、非キー属性である「dept_num」列に依存します。したがって、テーブルは第3正規形を満たしておらず、更新異常などのエラーのリスクが高くなります。「製造システム」などの部門名が変更された場合、現在のテーブル・スキーマの下で複数行を更新することが必要になります。

データを正規化されたデータベースで第3正規形に編成すると、そのようなエラーを防ぐことができます。この場合、このプロセスでは、データをEMPLOYEE、DEPARTMENT、EMPLOYEE_DEPARTMENT ⁴の3つの別々のテーブルに構造化する必要があります。

EMPLOYEEテーブル

DEPARTMENTテーブル

EMPLOYEE_DEPARTMENTテーブル

Boyce-Codd正規形（BCNF）は、第3正規形のより厳密または強力なバージョンと見なされています。BCNFではスーパー・キーを使用する必要があります。

テーブルは、複数値の依存関係がない場合、第4正規形です。複数の列の値が互いに独立しており、主キーにのみ依存する場合には、複数値の依存関係が発生します。

チュートリアルでよく引用される例は、スキルと言語の両方をリストした従業員テーブルを中心とするものです。従業員は複数のスキルを持ち、複数の言語を話すことができます。そこには2つの関係があり、1つは従業員とスキルの関係、もう1つは従業員と言語の関係です。

テーブルは、両方の関係を表す場合、第4正規形ではありません。データを第4正規形に変換するには、データを2つのテーブル（従業員のスキル用と言語用）に構造化する必要があります。

一般的に最高レベルの正規化と見なされている第5正規形は、結合依存関係を中心とした基準です。結合依存関係では、テーブルを小さなテーブルに分割した後にも、データを失ったり誤って新しいデータ行を作成したりすることなく、分割後の新しいテーブルを再度まとめて、元のテーブルを再構成できます。これは、ばらばらにしても元の形に戻すことができる、完成したジグソー・パズルになぞらえることができます。

第5正規形では、テーブルをより小さなテーブルに分割してよいのは、結合依存関係が実現できる場合のみです。分割された小さなテーブルから元のテーブルを再構成しようとすると、意図せずわずかに異なるテーブルが作成されてしまう場合は、元のテーブルを分解すべきではありません。ジグソー・パズルの例えで言えば、その状況は、パズルを再び組み立てたときに、ピースが欠けていたり余分なピースが紛れ込んだりしているようなものです。

データベースの正規化には多くのメリットがある一方で、トレードオフもあります。例えば、正規化を行う前であれば、特定のデータを探しているユーザーは1つのテーブルを照会するだけで済んだかもしれません。しかし正規化によってデータベースが複数のテーブルを含むようになると、ユーザーは複数のテーブルを照会する必要が生じ、時間がかかりコストの高いプロセスとなる可能性があります。

さらに、正規化によって個々のテーブルがよりシンプルになっても、データベース全体の複雑さが増す可能性があるため、適切に実装するには、データベースの設計者と管理者にかなりの専門知識が必要となります。