データベース 正規化 第5

わかりやすい(自称)です。

はじめに

この記事でわかること

  • 第一〜第五正規形+ボイスコット正規形のカンタンな説明

この記事ではわからないこと

  • 厳密な正規形の定義
  • 各正規形がなぜ必要なのか

そもそも正規形とは?

正規形とは、利用しやすいように整理したデータの形のことです。正規形にすると、データベースの管理・操作が行いやすくなります。

データベースにおける正規形は第一正規形から第五正規形までの5つ+ボイスコット正規形の計6つがあります。ボイスコット正規形は第一から第五正規形まで考えられたあとに発見されたもので、第三正規形と第四正規形の中間にあたります。

各正規形を見ていく

データベースでは第一正規形から第五正規形の順で正規化が行われます。そのため、数字が大きい正規形であれば、それより数字の小さい正規形でもあります。

第一正規形

何も考えずにデータベースにデータを入れた形が第一正規形です。「データベースに入れられる最低条件を充たしている」正規形です。

詳しい条件としては

  • データが繰り返されていない

ということです。以下の正規化前は東京都の部分が1つにまとめられて(データが繰り返されて)いるので第一正規形でありません。

正規化前

都道府県名前年齢
東京都 山田太郎 24
山田花子 30
山田次郎 45

正規化後

都道府県 名前 年齢
東京都 山田太郎 24
東京都 山田花子 30
東京都 山田次郎 45

これだけです。正規化前はExcelなどでは表現できますが、データベースに入れることは出来ません。

第二正規形

主キーが一つだけの形が第二正規形となります。主キーというのは、カンタンにいえばIDのことです。

たとえば、以下の例で「商品名、価格」の2つは注文IDと商品IDが決まれば決まります。しかし、よく考えてみると、商品IDだけでも決められます。つまり、商品名と価格は「注文IDと商品ID」と「商品ID」の2つの主キーを持ちます。

複数の主キーがある状態は第二正規形でありません。ここから、主キーが1つだけになるようにテーブルを分割して正規化します。

正規化前: 注文明細テーブル

注文ID 商品ID 商品名 価格 個数
1 100 うまい棒 10 1
2 100 うまい棒 10 2
3 200 ブラックサンダー 30 3

正規化後

注文ID 商品ID 個数
1 100 1
2 100 2
3 200 3
商品ID 商品名 価格
100 うまい棒 10
200 ブラックサンダー 30

商品名、価格に対する主キーが「商品ID」のみになりました。だいぶ読みやすく、変更に強くなってきました。

第三正規形

第三正規形はさらに、「推移的な関係」を分解します。

たとえば、「会員の住所データ」を市区町村と都道府県で管理しているとします。

このとき、「IDが決まれば市区町村が決まる」「市区町村が決まれば都道府県が決まる」という関係があります*1。ということは、ここから「市区町村と都道府県」というテーブルに分解ができます。

正規化前

顧客ID 都道府県 市区町村 名前
1 東京都 新宿区 マイク
2 大阪府 大阪市 太郎
3 京都府 京都市 ジョン

正規化後

「顧客IDと市区町村」「市区町村と都道府県」という従属関係をつかってテーブルを分解しました。

顧客ID 市区町村 名前
1 新宿区 マイク
2 大阪市 太郎
3 京都市 ジョン
都道府県 市区町村
東京都 新宿区
大阪府 大阪市
京都府 京都市

ボイスコット正規形

やる気が出たら書きます

第四正規形

これはグループに関する正規形とイメージするとわかりやすいです

正規化前

部活名 顧問 部員
野球部 教師A 野球部員A
野球部 教師A 野球部員B
野球部 教師B 野球部員A
野球部 教師B 野球部員B

たとえばある野球部のデータを考えます。この野球部には顧問が2人、部員が2人いるとします。このとき、「部活名」「顧問」「部員」のテーブルを作ると、いちいち顧問と部員の組み合わせが列挙されてしまい、明らかにムダがあります。顧問が10人、部員が20人いたら200行も必要になります!

正規化後

部活名 顧問
野球部 教師A
野球部 教師B
部活名 部員
野球部 野球部員A
野球部 野球部員B

「部活名と顧問」「部活名と部員」に分けました。

「野球部」が決まると顧問が複数人、「野球部」が決まると部員が複数人わかります。このように、1つが決まると他の列は複数が選択されるという関係を分解するのが第四正規形です。

第五正規形

第四正規形のさらに特殊なケースが第五正規形になります。ここまで来ると複雑きわまりなく、あまり必要もないので割愛します。

*1:実際には異なる県に同じ名前の市があったりしますが、細かいことは気にしないでください

目次

  • 1 データベースの正規化
  • 2 正規化の手順
    • 2.1 正規化前
    • 2.2 【第1正規形】繰り返しを整理
    • 2.3 【第2正規形】部分関数従属している列を整理
    • 2.4 【第3正規形】関数従属している列を整理

データベースの正規化

正規化(英:normalization)とは、データを取り扱いやすいようにデータベースを設計することであり、データの一貫性の維持と効率的なデータアクセスを可能にするための手法です。

正規化することにより、データの冗長性と不整合が起きる機会を減らすことができます。

※冗長:必要以上に物事が多く無駄なこと

スポンサーリンク

正規化の手順

正規化には、第1正規形~第5正規形、およびボイスコッド正規形などの種類がありますが、第1正規形~第3正規形までで、十分に正規化されたと考えることも多いです。

データベース 正規化 第5

正規化前

例えば、次のような注文があるとします。

鈴木一郎:A商品を1つとB商品を2つ注文

佐藤次郎:C商品を1つ注文

田中三郎:D商品を2つ、E商品を1つ、F商品を1つ

上記の注文をそのまま表に挿入すると次の通りです。各行の長さがバラバラで商品が繰り返されている状態です。

データベース 正規化 第5

【第1正規形】繰り返しを整理

データベースでは、レコード単位でデータを扱うため、正規化前のようなデータはデータベースに格納することすらできません。

まずは、繰り返し項目のそれぞれを別レコードとして独立させ、各レコードの長さを整えます。(正規化前は、各レコードの長さがバラバラで商品が繰り返されている状態)

データベース 正規化 第5

上記が「第1正規形」の表(テーブル)です。背景色がついている行(レコード)が、正規化前では繰り返し項目になっていた部分です。

繰り返し項目を別レコードとして独立させることで、すべてのデータをデータベースに格納することができました。

【第2正規形】部分関数従属している列を整理

第2正規形では、部分関数従属している列を整理します。

データベース 正規化 第5

データベース 正規化 第5

例えば、第1正規形で作られた表(テーブル)の主キーは「注文番号」と「商品ID」です。

「注文番号」と「商品ID」が決まれば、行(レコード)を一意に特定することができますが、実は「注文番号」が決まるだけで「注文日」「ユーザID」「購入ユーザ名」は特定することができます。このような関数が部分関数従属です。

そして、第1正規形の表(テーブル)から、部分関数従属している列(レコード)を切り出したものが「第2正規形」です。

次の表(テーブル)は部分関数従属のイメージ例です。

データベース 正規化 第5

オレンジ枠の部分は「注文番号」が決まれば特定できる項目、緑枠の部分は「商品ID」が決まれば特定できる項目です。

下記が「第2正規形」の表(テーブル)です。

データベース 正規化 第5

オレンジ枠で囲んだ部分を「注文テーブル」、緑枠で囲んだ部分を「商品テーブル」として切り出しています。そして残った部分を「注文詳細テーブル」として3つの表(テーブル)に分けています。

【第3正規形】関数従属している列を整理

第3正規形では、主キー以外の列に関数従属している列を整理します。関数従属とは「○○が決まれば特定できる項目」のことです。

第2正規形の「注文テーブル」は「注文番号」が主キーです。そのため「注文番号」が決まれば行(レコード)を一意に特定することができます。

しかし、よく見ると「注文番号」以外の列に関数従属している項目があります。それは「購入ユーザ名」です。「購入ユーザ名」は、「ユーザID」が決まれば特定できる項目です。

次の表(テーブル)は関数従属のイメージ例です。

データベース 正規化 第5

緑枠の部分は主キー以外である「ユーザID」が決まれば特定できる項目です。このように、第3正規形では、主キー以外の列に関数従属している列を整理します。

下記が「第3正規形」の表(テーブル)です。

データベース 正規化 第5

緑枠で囲んだ部分を「ユーザテーブル」として切り出しています。

データベース 正規化 第5

これで、正規化の第1正規形~第3正規形は完了です。

第4正規形の定義は?

第4正規形 多値従属性A→→Bが存在するとき、全ての属性がAに関数従属する場合、その関係を第4正規形と呼びます。 左下の表では、部活→→部員、部活→→備品の両方の関係が同時に一つの表に表現されており、A→→Bが存在するとはいえないため、第4正規形は満たしません。

データ正規化の目的は?

データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを、データベースの正規化と呼びます。 正規化を行っておくと、データの追加・更新・削除などに伴うデータの不整合や喪失が起きるのを防ぎ、メンテナンスの効率を高めることができます。

正規化のメリットは?

正規化によってデータの視認性が高まり、検索性も向上します。 必要なデータを必要なタイミングですぐに取り出せるほか、複数のシステムから利用しやすくなるのも、メリットといえるでしょう。 検索性が向上すると、誰でもデータベースの情報を活用できるようになり、業務効率が上がります。

正規化の段階は?

正規化段階には、第1正規化~第5正規化、およびボイス・コッド正規化やドメイン・キー正規化などがあります。