【データベース入門5】テーブル設計・正規化

本記事は全6回に渡るデータベース入門記事のうち、第5回「テーブル設計・正規化」です。

そもそもテーブルとは、「共通の属性を持った集合」です。

そのため、「テーブル名は必ず複数形か集合名詞で表現できる」と言われています。

本記事では「どの属性を同じテーブルにまとめ、どの属性を異なるテーブルに分けるのか」というテーブル設計の方法について記載します。

その他のデータベースの入門記事ついては以下の記事をご確認ください。

一番初めに読む本

経験者向けの入門本

MySQL を触る方におすすめ

スポンサーリンク

テーブル設計の基本的な考え方

テーブル設計の基本的な考え方は次の3つです。

  • 異なる属性を持った集合は、別のテーブルにする
  • 共通の属性を持った集合は、1つのテーブルにする
  • レコードの重複が発生するテーブル設計は避ける

異なる属性を持った集合は、別のテーブルにする

上記のテーブル「Foods」には異なる属性「動物名」と「植物名」が混在しています。

  • 「豚肉」は「植物の部位」という属性を持ちません
  • 「トマト」は「動物名」という属性を持ちません

そのため、このテーブルは2つに分けます。

共通の属性を持った集合は、1つのテーブルにする

上記のテーブル「Meats」と「Vegetables」では、「名前」と「値段」という共通の属性を持つため、1つのテーブルにまとめることができます。

レコードの重複が発生するテーブル設計は避ける

上記のテーブルでは同姓同名の会員ユーザー「新垣結衣」さんを区別することができません。そのため、会員に一意の値となる属性(例えば会員 ID)を与えます。

候補キー

候補キーとは、一意の値から成る属性 (カラム) のことです。
候補キーが決定すると、タプル (レコード) 内の他の属性の値も全て一意に決定します。

会員ID名前性別
新垣結衣女性
新垣結衣女性
阿部寛男性

上記のテーブルでは「会員 ID」が候補キーです。この値が決定すると、ほかのカラムもすべて決定します。

  • {会員 ID :1}→{名前:新垣結衣}、{性別:女性}
  • {会員 ID :2}→{名前:新垣結衣}、{性別:女性}
  • {会員 ID :3}→{名前:阿部寛}、{性別:男性}

なお、RDBMS では、テーブルの候補キーの数によって以下の名称がつけられています。

  • テーブルに候補キーが1つの場合、その属性(カラム)を主キー (Primary Key)と言います
  • テーブルに候補キーが複数の場合、その属性(カラム)を複合主キーと言います

以下の例では、{名前}と{産地}が複合主キーとなります。

名前産地値段
トマト熊本県100
トマト茨城県200
ゴボウ茨城県150
  • ☓ :{名前}→{値段} 「トマト」だけでは「値段」はわかりません
  • ☓ :{産地}→{値段} 「茨城県」だけでは「値段」はわかりません
  • ○ :{名前, 産地}→{値段} 2つの主キー「名前」・「産地」で「値段」が確定します

非キー

候補キー以外を「非キー」と言い、この値が決定しても、レコード内の他の属性の値は一意に決定しません。

  • {名前:新垣結衣}→{会員 ID :?} 

名前からは会員 ID が1なのか、2なのか一意に決定しない

スポンサーリンク

関係の正規化

上述した「テーブル設計の基本的な考え方」を元に、天才肌の人なら直感で美しいテーブルを作れます。

では、我々凡人はどうすればいいのでしょうか。

大丈夫です。我々凡人でも、一定のルールに沿ってテーブルを変換すると上述したテーブルを作成できます。この一定のルールを正規化と言います。

正規化には3つのルールがあります。

  • 第一正規形 (1 Normal Form)
  • 第二正規形 (2 Normal Form)
  • 第三正規形 (3 Normal Form)

第一正規形 (1 Normal Form)

第一正規形(1NF)は、「1つの要素には、1つの値しか含めない」というルールです。

これにより、候補キーが作れない」という自体を避けられます。

なお、「候補キー」自体は、次の第二正規形で決定します。

第二正規形 (2 Normal Form)

第二正規形(2NF)は、「テーブルに必ず候補キーが含まれる」というルールです。

つまり、「{候補キー}→{非キー}」(特定の属性の値を決めると、レコード内の他の属性が全て一意に決定するような属性(カラム)が存在する)というルールです。

上記の例では、{ポケモン} を候補キーにした場合、{登場人物} 属性が一意に定まりません。{ポケモン:ピカチュウ}→{登場人物:?} になってしまいます。

そのため、最初に説明した「異なる属性を持った集合は、別のテーブルにする」を実施します。

第三正規形 (3 Normal Form)

第三正規形(3NF)は、「{非キー属性}により、他の要素の値が一意に決定しないようにする」というルールです。

つまり、「{候補キー}→{非キー}→{非キー}を禁止」というルールです。

上記の例では、{品種} が候補キーで、非キーの値がうまく一意に決定しています。(現時点では)

しかし、実際に {GDP} を一意に決定するのは、非キーの {生産国} です。

第二正規形テーブルが問題となる状況は、以下のレコードを追加する場合です。

■ 問題1:{品種} に何の値を入れるの問題

品種生産国GDP
アメリカ20.94兆

■問題2:候補キーが一意じゃなくなる場合

品種生産国GDP
シャルドネアメリカ20.94兆
追加するレコード
品種生産国GDP
シャルドネフランス2.603兆
紅玉日本5.065兆
現在のレコード

{品種:シャルドネ}→{生産国:フランス?アメリカ?} となり候補キーが一意でなくなります。

■ 結論

ようするに、最初に説明したように「異なる属性を持った集合は、別のテーブルにする」を実施しましょうということです。

スポンサーリンク

最後に

データベース入門記事「テーブル設計・正規化」に関する説明は以上となります。

その他のデータベースの入門記事ついては以下の記事をどうぞ。

参考資料・おすすめの書籍

一番初めに読む本

経験者向けの入門本

MySQL を触る方におすすめ