Panda Noir

JavaScript の限界を究めるブログでした。最近はいろんな分野を幅広めに書いてます。

データベースの正規化について超絶わかりやすくまとめてみた

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

はじめに

この記事でわかること

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

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

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

そもそも正規形とは?

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

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

各正規形を見ていく

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

第一正規形

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

詳しい条件としては

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

ということです。

正規化前

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

正規化後

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

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

第二正規形

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

たとえば、以下の例では注文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が決まれば市区町村が決まる」「市区町村が決まれば都道府県が決まる」という関係があります(実際には市の名前がかぶっていたりしますが細かいことは気にしないでください)。ということは、ここから「市区町村と都道府県」というテーブルに分解ができます。

正規化前

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

正規化後

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

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

ボイスコット正規形

やる気が出たら書きます

第四正規形

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

正規化前

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

たとえば「部活の顧問と部員」というテーブルがあるとします。いちいち顧問と部員の組み合わせが列挙されてしまっていて、明らかにムダがあります。

顧問が10人、部員が20人いたら200行も必要になってしまいます!

正規化後

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

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

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

第五正規形

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