社員Aさんの個人的な情報と、Aさんが何か（仕事、ボウリング、健康診断など）をした結果生じる情報とを切り分けることで、それらを実務に即して関連付けることができます。正規化によって情報群を一旦切り分け、切り分けた情報同士をリレーションによって関連付ける――ということです。
- 役割によって切り分ける -
データベースでは、上記の情報は以下のようなテーブルに切り分けられます。
社員：社員ID、氏名、現住所、連絡先、所属、役職
報酬：基本給、通勤手当、住居手当、役職手当
当月営業成績：当月の営業実績
累計営業実績：４月、５月、６月…
健康診断結果：検査年月日、身長、体重、右視力、左視力…
年休管理：前年度残、消化年月日、事由、残日数
ボウリング大会結果：開催日、１ゲーム目、２ゲーム目、３ゲーム目、総合点、順位
「社員」は社員の基本的な情報を記録するマスターテーブルで、その他は何らかの業務（ボウリング大会も社内のリクリエーション行事という『業務の一環』と見なせます）を遂行した結果生じたデータを記録するテーブルです。
もちろん各情報の内容は暫定的なものですから、実際に運用する場合は各項目についてもっと厳密に検討しなければなりません。
ただ、こうして１人の社員の基礎的な情報と、仕事や休暇、リクリエーション行事など日々生活を行うたびに変化する情報とを切り分けることで、それぞれの情報の管理（参照、書き換え）を効率的に行うことができ、それ以外の（ある目的にとっては必要のない）情報を不要にアクセスする無駄も省けます。
テーブルの正規化とは、具体的に言えばこのようなことなのです。
- IDによってレコードを特定する -
先に掲げた「当月営業成績」や「健康診断結果」は、営業実績や身長、体重などの項目で構成されています。これらがフィールド（列）となり、具体的な値が記録されるとレコード（行）になります。
実際のテーブルではこれらのフィールドに加えて「その行が誰のデータを記録したものなのか」を示すために、「社員ID」フィールドが追加されます。これによって、特定の社員と営業成績を記録した１件のフィールド、あるいは特定の社員とその身長、体重などの健康診断結果が結びつけられ、意味のある情報となります（身長を示す168という値が、社員Aさんのデータであることが明確にならなければ、それは意味のある情報とはなりません）。
このような状態のとき、テーブル「当月営業成績」や「健康診断結果」は社員の基本情報を記録したテーブル「社員」を参照していることになります。例えば、健康診断結果の「身長：168(cm)」という値が誰のものであるかは、同じレコードの「社員ID」の値からテーブル「社員」を参照することで明らかになります。これがテーブルの関連付けです。この場合、テーブル「健康診断結果」とテーブル「社員」がフィールド「社員ID」で関連付けられていることになります。
- フィールドによってテーブルを関連付ける -
関連付けられるのはテーブルであって、フィールドではありません。テーブルの構成要素であるフィールドの持つ「意味」（社員を特定する「社員ID」、商品を特定する「商品ID」など）に基づいて、テーブル同士が関連付けられる――ということです。
その場合、関連付けられるテーブルのフィールド名は同じであることが一般的ですが、それは決まりではありません。例えば「健康診断結果」の「社員番号」と「社員」の「社員ID」とを結び付けても構いません（但し、多くのRDBMSでは、異なるテーブルに同じフィールドがあり、一方がキーフィールドであれば、自動的に参照関係を設定します）。
２つのテーブルがこのような関係の場合、一方がもう一方を参照する形になります。例では、テーブル「健康診断結果」がテーブル「社員」を参照していることになるので、「健康診断結果」を参照側テーブル、「社員」を被参照側テーブルと呼びます。
「健康診断結果」は「社員」に記録された全社員のレコードから、「社員ID」をたどることによって唯一のレコードを示すことができます。このとき「社員ID」はレコードを特定するためのキー（鍵）となり、被参照側であるテーブル「社員」の「社員ID」は「キーフィールド」となります。
 |
|
|
