素早く正規形を見抜く実践テクニック：データベースエンジニアへの道（3）（1/4 ページ）

本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア（データベース利用者）が、データ管理者（DA）やデータベース管理者（DBA）へステップアップするための第一歩として有効な基礎知識を紹介する。（編集局）

　今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。

　それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。

　ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。

正規化の位置付け

　正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿では正規化を中心に扱っていきますが、ここで注意してほしいのは、正規化はデータモデリングにおける主人公ではなく脇役のような存在だということです。前回で紹介したER図を描き上げる4つのステップでいうと「4th Step」の一部に当たります（図1）。よく見掛ける正規化の例では（この記事も例外ではありませんが）、正規化を使ってテーブルを切り出していますが、実務でこのようなことは行いません。ほとんどのテーブルは「3rd Step」までで抽出が終わっているはずです。正規化は、それら前工程の作業結果に矛盾がないか確認するというチェック機構として働きます。

図1　ER図を描き上げる4つのステップ（前回から流用）

　以降では、正規化の目的や必要性を確認した後、正規化の結果として得られる正規形を、具体例を交えながら順に見ていきます。

正規化の目的

　一言でいうと正規化とは、「1事実1カ所（1 fact in 1 place）を目指して、テーブルの整合性を保ったまま、テーブルの冗長性を排除して、データを効率的に管理できるようにすること」です。データベースはデータを保管するシステムですので、データを効率的に管理できることは非常に重要です。

　正規化では、冗長性を排除するためにテーブルの分解という方法を取ります。その方法には以下の6つがあり、第n正規化して得られるテーブルを第n正規形といいます。

• 非正規形（※正規形ではないが、第1正規化の対象を非正規形という）
• 第1正規形（1NF）
• 第2正規形（2NF）
• 第3正規形（3NF）
• ボイスコッド正規形（BCNF）
• 第4正規形（4NF）
• 第5正規形（5NF／PJNF）

　では、なぜ正規化しなくてはならないのでしょうか。正規化をしないで、テーブルに冗長性があると下記の3つの問題が発生します。

• 事前登録不能（登録）
• 重複更新（更新）
• 関係喪失（削除）

　これらの問題の具体例を、第2回で取り上げたオンラインショップの商品購入を例にして見ていきましょう。まずは表1の第1正規形の注文明細テーブルを見てください。

表1　オンラインショップの商品購入
（表をクリックすると拡大します）

事前登録不能（登録）

　新しい商品を注文の前に登録できません。このテーブルにデータを登録するにはキーである注文番号、商品IDが必要ですので、一度も注文されたことのない商品には注文番号が割り当てられていないため、登録ができません。つまり、注文と同時でなければ商品が登録できないということになります。

重複更新（更新）

　商品の名前や単価が変更されたとき、複数ある同一商品の情報をすべて更新しなくてはなりません。同じ商品の情報が注文ごとに繰り返し登録されているため、1つの商品情報を更新するためには複数行を残らず更新する必要があります。

関係喪失（削除）

　一度しか注文されたことのない商品を含む注文が削除されると、商品情報が失われてしまいます。注文を削除するという行為により、商品が削除されてしまうことがあります。

　これらの問題は、1つのテーブルに2つ以上の実体（ここでは注文明細と商品）が含まれていることが原因です。実体が異なるとデータのライフサイクルである登録、更新、削除のタイミングが異なるために、上記のような問題が起こります。そして、これらの問題を解決するために正規化が必要です。