大量のデータを操作する際は，データの形を扱いやすく整えることが必要だ。特にRDBにおいては，データの属性間の関係が絡み合っていると，内容を正しく保てないことがある。今回はデータの形を整える基礎理論である正規化について，RDBの場合を中心にその考え方や手順を解説しよう。
リレーショナル・データベース（RDB）の特徴は，表（テーブル）をデータ構造としていることだ。いかに使いやすく実用的な表を作れるかが，RDB設計のカギとなる。
表の作成は，データ項目を「ユーザーが知りたいことは何か」という観点で洗い出すことから始まる。例えば，社員名簿のRDBでは，「社員番号」，「氏名」，「部署」，「役職」，「内線番号」といった項目を洗い出す。そして，個々の項目のデータ型（文字列，整数，浮動小数点数など）を決定していく。
では，データ項目とデータ型が決まったら，それらを横に並べて1つの表にすれば表は完成するのだろうか。RDBの設計はそれほど単純でない。データに対して追加，更新，削除といった操作を加えても，データが矛盾なく内容を正しく保つためには，「正規化」という作業を行わなければならない。
「キー」の役割を知る
正規化の具体的な説明に入る前に，「キー」について確認しておこう。キーは，行を一意に判別したり，表同士を結びつける役割を担う。正規化を理解するうえでは欠かせないものだ。キーは通常，表の中の特定の属性，もしくは属性の組み合わせを指す。ここで言う「属性」とは，集合論における「列」の呼び名である。
キーには，3つの種類がある。まず，ある表において，行を一意に識別できる属性（または属性の組み合わせ）を「候補キー（candidate key）」と言う。
候補キーは，1つだけとは限らない。候補キーが複数ある場合は，設計者の判断で表を代表するキーを1つ定める。そのキーが「主キー（primary key）」である。
また複数の表同士を結びつけるための属性がキーになることもあり，これを「外部キー（foreign key）」と呼ぶ。外部キーは他の表の主キーになると考えればよい。
「表」に潜む様々な問題
前述したように，正規化が必要な理由は，RDBの内容を操作（追加，更新，削除）しても，データを矛盾なく正しく保つためである。では，十分に表を正規化していないと，どんな問題が生じるのか。
図1は，正規化が十分に行われていない表だ。この表に操作を加えると，いくつかの問題が発生する恐れがある。
例えば，データを「更新」する際の問題だ。営業部の内線番号が「100」から「111」に変わり，データの更新作業が必要になったとしよう。表には内線番号が「100」の行が2つある。うっかりして片方の更新を忘れると，「100」という存在しないデータが残ってしまう恐れがある。
データを「削除」する際にも問題が発生する。例えば，経理部の「日経花子」が退職したとする。それに伴い日経花子の行を削除すると，表の中から「経理部」という部署に関する情報が消えてしまうのだ。
もちろん，部署に関するデータ（部署名，内線番号）を別の表としてもう1つ用意する方法もある。しかし，同じ情報が複数存在すると，変更があった場合にすべての表の内容を更新しなければならないほか，更新の際に間違った内容が入力される可能性もある。このため部署に関する情報は1つの表に集め，別の表からはそれを参照するようにした方が，メンテナンス性・整合性を確保するうえで最適なのは自明だろう。
