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

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

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

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

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

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

一番初めに読む本

経験者向けの入門本

MySQL を触る方におすすめ

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

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

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

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

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

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

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

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

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

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

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

候補キー

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

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

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

{会員 ID ：１}→{名前：新垣結衣}、{性別：女性}
{会員 ID ：２}→{名前：新垣結衣}、{性別：女性}
{会員 ID ：３}→{名前：阿部寛}、{性別：男性}

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

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

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

名前	産地	値段
トマト	熊本県	100
トマト	茨城県	200
ゴボウ	茨城県	150

☓ ：{名前}→{値段}　「トマト」だけでは「値段」はわかりません
☓ ：{産地}→{値段}　「茨城県」だけでは「値段」はわかりません
○ ：{名前, 産地}→{値段}　２つの主キー「名前」・「産地」で「値段」が確定します

非キー

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

{名前：新垣結衣}→{会員 ID ：？}

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

関係の正規化

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

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

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

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

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

第一正規形 (1 Normal Form)

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

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

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

第二正規形 (2 Normal Form)

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

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

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

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

第三正規形 (3 Normal Form)

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

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

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

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

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

■ 問題１：{品種} に何の値を入れるの問題

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

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

品種	生産国	GDP
シャルドネ	アメリカ	20.94兆

追加するレコード

品種	生産国	GDP
シャルドネ	フランス	2.603兆
紅玉	日本	5.065兆

現在のレコード

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

■ 結論

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

最後に

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

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

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

一番初めに読む本

経験者向けの入門本

MySQL を触る方におすすめ