Accessのようなリレーショナルデータベースを設計する上で、「正規化」の理解は必要不可欠です。そこで、今回は、「正規化」の考え方について紹介します。
一件一様のレコード作成 第1正規化
正規化とは、データの重複を無くし、効率的にデータを取得することを可能にするために、データを分割、整理することです。データの追加、更新、削除といった操作の際にデータの不整合や消失が発生することを防ぐためにも大切な設計思想となります。
正規化には第１～５正規形等がありますが、ここでは一般的に用いられる第１～3正規化までを見ていきましょう。
例えば、次の例を見てみましょう。
例１： 非正規形のテーブル
| 担当者ID | 担当者 | 部署コード | 部署 | 購入品 | 数量 | 購入日 |
| 11AA | 鈴木 | Z0 | 営業 | えんぴつ | 10 | 2022/7/10 |
| ノート | 2 | 2022/7/10 | ||||
| 消しゴム | 5 | 2022/7/15 | ||||
| 12AB | 山下 | Z1 | 製造 | えんぴつ | 20 | 2022/7/1 |
| 13AC | 佐藤 | Z9 | 経理 | ノート | 5 | 2022/7/14 |
非正規形のテーブルの場合、1行の中に繰り返しの項目が存在しています。例では、担当者「鈴木」が購入したものは3種類ありますが、これらのデータにおいて担当者情報に係る行が一括（セル結合されている）で表示されています。
リレーショナルデータベースでは、レコード（行）単位でデータを扱うため、非正規形の状態ではテーブルにデータを保存することができません。そこで、レコード単位でデータを扱えるようにするために「例1」で示したテーブルを「例2」で示すように修正します。
例2： 第1正規形のテーブル
| 担当者ID | 担当者 | 部署コード | 部署 | 購入品 | 数量 | 購入日 |
| 11AA | 鈴木 | Z0 | 営業 | えんぴつ | 10 | 2022/7/10 |
| 11AA | 鈴木 | Z0 | 営業 | ノート | 2 | 2022/7/10 |
| 11AA | 鈴木 | Z0 | 営業 | 消しゴム | 5 | 2022/7/15 |
| 12AB | 山下 | Z1 | 製造 | えんぴつ | 20 | 2022/7/1 |
| 13AC | 佐藤 | Z9 | 経理 | ノート | 5 | 2022/7/14 |
このようにして、非正規形のテーブルから「繰り返し」を取り除くことを第1正規化と言います。
部分関数従属の整理 第2正規化
第1正規化で繰り返しの情報をなくすために、一件一様のデータ（セル結合を使わず、レコード単位でデータを整理すること）として表の見直しをしました。
しかし、例2を見てみると、テーブル内に担当者として同じ情報が登録されていることが分かります。このため、例えば「鈴木」の部署が「総務」に変わった場合、全てのデータを修正する必要があり、不整合発生の要因になりえます。そこで、例2のテーブルから担当者に係る情報を別テーブルに分割することを考えます。少し専門的に言うと、第2正規化とは第1正規形のテーブルから「部分関数従属」を除くこと、を指します。ここで、部分関数従属とは、ある一意の情報、すなわち、主キーが決まればそれ以外の情報が決まるデータのことを意味します。
したがって、例2の場合を見ると、「担当者ID」は主キーとなり、「担当者ID」が分かれば自ずと「担当者」、「部署コード」及び「部署」が分かることになります。
つまり、例2のテーブルは次のように分割することができます。
例3.1： 第2正規形のテーブル①
| 担当者ID | 購入品 | 数量 | 購入日 |
| 11AA | えんぴつ | 10 | 2022/7/10 |
| 11AA | ノート | 2 | 2022/7/10 |
| 11AA | 消しゴム | 5 | 2022/7/15 |
| 12AB | えんぴつ | 20 | 2022/7/1 |
| 13AC | ノート | 5 | 2022/7/14 |
このようにして「担当者」に係るデータは別のテーブルとして保持し、購入データについては担当者IDだけを用いてレコードを紐づけ（リレーション）することにより保守性、整合性を向上させることができます。
推移的関数従属の整理 第3正規化
第2正規化までのデータ処理で、テーブル設計としてはかなり整理されたものになりましたが、さらに第3正規化として、第２正規形の表から、主キー以外の列に関数従属している列（推移的関数従属と言います。）を分割します。例3.2の場合、下の表の「部署コード」と「部署」が推移的関数従属となっています。
そこで、これらを踏まえて例3のテーブルは最終的に次のように示すことができます。
例4.1： 第3正規形のテーブル①
| 担当者ID | 購入品 | 数量 | 購入日 |
| 11AA | えんぴつ | 10 | 2022/7/10 |
| 11AA | ノート | 2 | 2022/7/10 |
| 11AA | 消しゴム | 5 | 2022/7/15 |
| 12AB | えんぴつ | 20 | 2022/7/1 |
| 13AC | ノート | 5 | 2022/7/14 |
例4.2： 第3正規形のテーブル②
| 担当者ID | 担当者 | 部署コード |
| 11AA | 鈴木 | Z0 |
| 11AA | 鈴木 | Z0 |
| 11AA | 鈴木 | Z0 |
| 12AB | 山下 | Z1 |
| 13AC | 佐藤 | Z9 |
例4.3： 第3正規形のテーブル③
| 部署コード | 部署 |
| Z0 | 営業 |
| Z1 | 製造 |
| Z9 | 経理 |
このようにして、正規化を行うことでデータの冗長性を排除し、データを不整合なく管理することができるようになります。
ここでは、第3正規化までの方法を紹介しましたが、実際のデータベースを構築する際には必ずしも第3正規化までする必要はなく、取り扱う情報の量、頻度、作業効率等を考慮し、第1正規形、第2正規形のテーブル構造として設計することもあります。
条件に応じて柔軟にデータベースを設計できるようにすることが大切です。
まとめ
今回はリレーショナルデータベースを構築する上で必要不可欠な「正規化」について紹介をしました。
一度慣れてしまえば、その概念は非常にわかりやすく、また整然とデータベースを構築できるようになりますので、本記事を参考にテーブル設計に臨んでいただければと思います。
スポンサーリンク
コメント