わかりやすい(自称)です。 正規形とは、利用しやすいように整理したデータの形のことです。正規形にすると、データベースの管理・操作が行いやすくなります。 データベースにおける正規形は第一正規形から第五正規形までの5つ+ボイスコット正規形の計6つがあります。ボイスコット正規形は第一から第五正規形まで考えられたあとに発見されたもので、第三正規形と第四正規形の中間にあたります。
データベースでは第一正規形から第五正規形の順で正規化が行われます。そのため、数字が大きい正規形であれば、それより数字の小さい正規形でもあります。 何も考えずにデータベースにデータを入れた形が第一正規形です。「データベースに入れられる最低条件を充たしている」正規形です。 詳しい条件としては ということです。以下の正規化前は東京都の部分が1つにまとめられて(データが繰り返されて)いるので第一正規形でありません。 これだけです。正規化前はExcelなどでは表現できますが、データベースに入れることは出来ません。 主キーが一つだけの形が第二正規形となります。主キーというのは、カンタンにいえばIDのことです。 たとえば、以下の例で「商品名、価格」の2つは注文IDと商品IDが決まれば決まります。しかし、よく考えてみると、商品IDだけでも決められます。つまり、商品名と価格は「注文IDと商品ID」と「商品ID」の2つの主キーを持ちます。 複数の主キーがある状態は第二正規形でありません。ここから、主キーが1つだけになるようにテーブルを分割して正規化します。 商品名、価格に対する主キーが「商品ID」のみになりました。だいぶ読みやすく、変更に強くなってきました。 第三正規形はさらに、「推移的な関係」を分解します。 たとえば、「会員の住所データ」を市区町村と都道府県で管理しているとします。 このとき、「IDが決まれば市区町村が決まる」「市区町村が決まれば都道府県が決まる」という関係があります*1。ということは、ここから「市区町村と都道府県」というテーブルに分解ができます。 「顧客IDと市区町村」「市区町村と都道府県」という従属関係をつかってテーブルを分解しました。 やる気が出たら書きます これはグループに関する正規形とイメージするとわかりやすいです たとえばある野球部のデータを考えます。この野球部には顧問が2人、部員が2人いるとします。このとき、「部活名」「顧問」「部員」のテーブルを作ると、いちいち顧問と部員の組み合わせが列挙されてしまい、明らかにムダがあります。顧問が10人、部員が20人いたら200行も必要になります!はじめに
この記事でわかること
この記事ではわからないこと
そもそも正規形とは?
各正規形を見ていく
第一正規形
正規化前
都道府県名前年齢 東京都
山田太郎
24
山田花子
30
山田次郎
45
正規化後
都道府県 名前 年齢 東京都
山田太郎
24
東京都
山田花子
30
東京都
山田次郎
45
第二正規形
正規化前: 注文明細テーブル
注文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 都道府県 市区町村 名前 1
東京都
新宿区
マイク
2
大阪府
大阪市
太郎
3
京都府
京都市
ジョン
正規化後
顧客ID 市区町村 名前 1
新宿区
マイク
2
大阪市
太郎
3
京都市
ジョン
都道府県 市区町村 東京都
新宿区
大阪府
大阪市
京都府
京都市
ボイスコット正規形
第四正規形
正規化前
部活名 顧問 部員 野球部
教師A
野球部員A
野球部
教師A
野球部員B
野球部
教師B
野球部員A
野球部
教師B
野球部員B
正規化後
野球部 | 教師A |
野球部 | 教師B |
野球部 | 野球部員A |
野球部 | 野球部員B |
「部活名と顧問」「部活名と部員」に分けました。
「野球部」が決まると顧問が複数人、「野球部」が決まると部員が複数人わかります。このように、1つが決まると他の列は複数が選択されるという関係を分解するのが第四正規形です。
第五正規形
第四正規形のさらに特殊なケースが第五正規形になります。ここまで来ると複雑きわまりなく、あまり必要もないので割愛します。
*1:実際には異なる県に同じ名前の市があったりしますが、細かいことは気にしないでください
目次
- 1 データベースの正規化
- 2 正規化の手順
- 2.1 正規化前
- 2.2 【第1正規形】繰り返しを整理
- 2.3 【第2正規形】部分関数従属している列を整理
- 2.4 【第3正規形】関数従属している列を整理
データベースの正規化
正規化(英:normalization)とは、データを取り扱いやすいようにデータベースを設計することであり、データの一貫性の維持と効率的なデータアクセスを可能にするための手法です。
正規化することにより、データの冗長性と不整合が起きる機会を減らすことができます。
※冗長:必要以上に物事が多く無駄なこと
スポンサーリンク
正規化の手順
正規化には、第1正規形~第5正規形、およびボイスコッド正規形などの種類がありますが、第1正規形~第3正規形までで、十分に正規化されたと考えることも多いです。
正規化前
例えば、次のような注文があるとします。
鈴木一郎:A商品を1つとB商品を2つ注文
佐藤次郎:C商品を1つ注文
田中三郎:D商品を2つ、E商品を1つ、F商品を1つ
上記の注文をそのまま表に挿入すると次の通りです。各行の長さがバラバラで商品が繰り返されている状態です。
【第1正規形】繰り返しを整理
データベースでは、レコード単位でデータを扱うため、正規化前のようなデータはデータベースに格納することすらできません。
まずは、繰り返し項目のそれぞれを別レコードとして独立させ、各レコードの長さを整えます。(正規化前は、各レコードの長さがバラバラで商品が繰り返されている状態)
上記が「第1正規形」の表(テーブル)です。背景色がついている行(レコード)が、正規化前では繰り返し項目になっていた部分です。
繰り返し項目を別レコードとして独立させることで、すべてのデータをデータベースに格納することができました。
【第2正規形】部分関数従属している列を整理
第2正規形では、部分関数従属している列を整理します。
例えば、第1正規形で作られた表(テーブル)の主キーは「注文番号」と「商品ID」です。
「注文番号」と「商品ID」が決まれば、行(レコード)を一意に特定することができますが、実は「注文番号」が決まるだけで「注文日」「ユーザID」「購入ユーザ名」は特定することができます。このような関数が部分関数従属です。
そして、第1正規形の表(テーブル)から、部分関数従属している列(レコード)を切り出したものが「第2正規形」です。
次の表(テーブル)は部分関数従属のイメージ例です。
オレンジ枠の部分は「注文番号」が決まれば特定できる項目、緑枠の部分は「商品ID」が決まれば特定できる項目です。
下記が「第2正規形」の表(テーブル)です。
オレンジ枠で囲んだ部分を「注文テーブル」、緑枠で囲んだ部分を「商品テーブル」として切り出しています。そして残った部分を「注文詳細テーブル」として3つの表(テーブル)に分けています。
【第3正規形】関数従属している列を整理
第3正規形では、主キー以外の列に関数従属している列を整理します。関数従属とは「○○が決まれば特定できる項目」のことです。
第2正規形の「注文テーブル」は「注文番号」が主キーです。そのため「注文番号」が決まれば行(レコード)を一意に特定することができます。
しかし、よく見ると「注文番号」以外の列に関数従属している項目があります。それは「購入ユーザ名」です。「購入ユーザ名」は、「ユーザID」が決まれば特定できる項目です。
次の表(テーブル)は関数従属のイメージ例です。
緑枠の部分は主キー以外である「ユーザID」が決まれば特定できる項目です。このように、第3正規形では、主キー以外の列に関数従属している列を整理します。
下記が「第3正規形」の表(テーブル)です。
緑枠で囲んだ部分を「ユーザテーブル」として切り出しています。
これで、正規化の第1正規形~第3正規形は完了です。