図3●正規化の流れ
表の一つのマス目にはいるデータを1個にすることと，平坦な表形式にすること。これが第1のステップである。次に，あるフィールドの値が決まるとユニークに決まるデータがあれば，それを抜き出して別のテーブルに分ける。こうすることによって，重複して存在する無駄なデータを取り除ける。しかも情報が1カ所に集中するので，データの保守も楽になる。
図4●第4正規形
主キーに対して多値を取る情報が複数存在する場合，これらのデータも分けたほうが管理しやすくなる。情報の無駄もなくなる。これが第4正規形である。ただし元の状態でも，主キーに対してユニークな情報なので，第3正規形の条件は満たしている。第4正規形を含め高次の正規化は，必ずしも必要ではない。
図5●多値フィールドの例
構造上複数の値を一つのフィールドに格納できるよう拡張したデータベース管理システムもある。ただし固定個数の枠を取るのであれば却って無駄が増えるし，この値を串刺しに検索できるかどうかが実装に依存するなど，実際に使う際には注意が必要だ。

正規化にはいくつかの段階がある

　データ設計で重要な位置を占めるのがデータの正規化である（図3[拡大表示]）。これはリレーショナル・モデル固有の手続きである。リレーショナル・モデルの理論的基盤である関係演算や集合演算（詳細は後述）を使ってデータを操作する場合に，適切にデータを管理できるようにするのが基本である。そしてここで重要なことは，同じデータを重複して存在させないこと。同じデータが複数別の場所に存在していると，片方だけ更新して別の個所を更新し忘れる危険性がある。結果としてデータに矛盾が発生し，データそのものが信頼できないものになってしまう。正規化はこの危険性を取り除く作業でもあるのだ。

　正規化の作業は，(1)まずデータを表形式にする，(2)一つのフィールドの値で別のフィールドの値が決まる場合，それを別のテーブルに分ける，(3)多値を取るフィールドが複数あったら，それを別テーブルに分ける，と段階的に進んでいく。

　元々のデータは，リレーショナルなデータ構造（つまり表形式）になっているとは限らない。むしろ伝票や記事情報などを見ればわかるように，結構複雑な形状をしていることが多い（図3-a[拡大表示] ）。これを表に格納できる形態に展開したものが，「第1正規形」である（図3-b[拡大表示]）。例えば販売管理のデータの場合，「売り上げ」という行為に対してどの取引先が，いつ何をどれくらい注文したのかといった情報が必要になる。一つの会社が複数の注文を実施するし，一つの注文で複数の商品を発注することもある。これをシンプルな表形式に展開したものが第1正規形である。ここで取引番号を表すフィールドを追加している。これ自体は正規化と関係ないが，同じ日に同じ取引先に対して同じ商品を販売しても識別できるようにするためである。このフィールドがレコードを一意に識別するための「主キー（プライマリキー）」になる。

　だがこのままでは非常に不便である。例えば取引先名など同じデータが繰り返し登場する。非常に無駄である。また取引先に関連する情報が引っ越しなどで変更になった場合，その情報がテーブルのなかに埋もれ込んでしまう。さらに，売り上げが発生していない商品は，データベースに登録できない。

　一方でこういった情報は，取引先が決まればほぼ一意に決まる情報でもある。このようにある条件が整うと自動的にその値が決まるデータを，「従属」関係にあるという。この従属関係の洗い出しが正規化の第2のステップである（図3-c[拡大表示]）。例えば商品の品目が決まれば，その名称や価格，関連情報などは一意に決まる。これは別のテーブルで管理した方が得策である。そして，その別のテーブルと関連づける情報が「外部キー」である。このような形にしたものを「第3正規形」と呼ぶ。理論的に表現すれば，一つのテーブルの情報がすべて，主キーに従属する関係になっているものが第3正規形である。名前からもわかるように，第1正規形と第3正規形の間には「第2正規形」も定義されている。しかし現実には，第1正規形から余分な従属関係を取り除くと，自動的に第3正規形になることが多く，あえてこの段階を考慮する必要はない。

　第3正規形までいけば，おおむね正規化は完了である。ただこれでは済まない場合がある。複数の値を取りうるフィールドが2個以上存在する場合である。例えば書籍データベースを考えてみる。一つの書籍に対して，複数の筆者や複数のキーワードを付けることになる。この場合主キーは書名で，筆者やキーワードはそれぞれ書名にのみ従属する。したがって図4-a[拡大表示]の形も第3正規形なのである。しかしこの形は，見るからによくない。同じ情報が複数のレコードに存在してしまっている。そこでこれら複数の値を取るフィールドを別のテーブルに分ける（図4-b[拡大表示]）。これが第4正規形である。

　なおこのような複数の値を取るデータがある場合，多値フィールドという考え方で対応できるRDBMSもある。多値フィールドとは文字通り，一つのフィールドが複数の値を取ることができるものだ（図5[拡大表示]）。リレーショナル・モデルにおけるテーブルには反するが，これを「拡張リレーショナル型」と呼ぶこともある。うまく利用できれば非常に便利なのだが，例えば個数が限定されていたりすると却って使い勝手が悪くなることもある。また多値フィールド機能に頼って後述する関係演算がおろそかになっているものもあった。

「ふーん。何となく，分かったような分からないような…」
「まあ言葉は難しいけど，結局は同じデータを別の場所に置かないということだね」
「でも，こんなに分けちゃったら，どうやって望みのデータを取り出すんですか」
「クエリーを書くっていうのは分かっているよね。そこで何をしているかというと，関係演算とか集合演算とかをしているんだ」
「ああ，またややこしい言葉が…」

（北郷　達郎、八木　玲子）