本記事は全6回に渡るデータベース入門記事のうち、第5回「テーブル設計・正規化」です。
そもそもテーブルとは、「共通の属性を持った集合」です。
そのため、「テーブル名は必ず複数形か集合名詞で表現できる」と言われています。
本記事では「どの属性を同じテーブルにまとめ、どの属性を異なるテーブルに分けるのか」というテーブル設計の方法について記載します。
その他のデータベースの入門記事ついては以下の記事をご確認ください。
- 【データベース入門1】データベースとは
- 【データベース入門2】SQL コマンドとは、SQL 文の一覧
- 【データベース入門3】トランザクションと ACID 特性とは
- 【データベース入門4】バックアップ・クラスター・レプリケーション
- 【データベース入門5】テーブル設計・正規化 ←今ここ
- 【データベース入門6】オプティマイザー・実行計画
テーブル設計の基本的な考え方
テーブル設計の基本的な考え方は次の3つです。
- 異なる属性を持った集合は、別のテーブルにする
- 共通の属性を持った集合は、1つのテーブルにする
- レコードの重複が発生するテーブル設計は避ける
異なる属性を持った集合は、別のテーブルにする

上記のテーブル「Foods」には異なる属性「動物名」と「植物名」が混在しています。
- 「豚肉」は「植物の部位」という属性を持ちません
- 「トマト」は「動物名」という属性を持ちません
そのため、このテーブルは2つに分けます。
共通の属性を持った集合は、1つのテーブルにする

上記のテーブル「Meats」と「Vegetables」では、「名前」と「値段」という共通の属性を持つため、1つのテーブルにまとめることができます。
レコードの重複が発生するテーブル設計は避ける

上記のテーブルでは同姓同名の会員ユーザー「新垣結衣」さんを区別することができません。そのため、会員に一意の値となる属性(例えば会員 ID)を与えます。
候補キー
候補キーとは、一意の値から成る属性 (カラム) のことです。
候補キーが決定すると、タプル (レコード) 内の他の属性の値も全て一意に決定します。
会員ID | 名前 | 性別 |
---|---|---|
1 | 新垣結衣 | 女性 |
2 | 新垣結衣 | 女性 |
3 | 阿部寛 | 男性 |
上記のテーブルでは「会員 ID」が候補キーです。この値が決定すると、ほかのカラムもすべて決定します。
- {会員 ID :1}→{名前:新垣結衣}、{性別:女性}
- {会員 ID :2}→{名前:新垣結衣}、{性別:女性}
- {会員 ID :3}→{名前:阿部寛}、{性別:男性}
なお、RDBMS では、テーブルの候補キーの数によって以下の名称がつけられています。
以下の例では、{名前}と{産地}が複合主キーとなります。
名前 | 産地 | 値段 |
---|---|---|
トマト | 熊本県 | 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兆 |
{品種:シャルドネ}→{生産国:フランス?アメリカ?} となり候補キーが一意でなくなります。
■ 結論
ようするに、最初に説明したように「異なる属性を持った集合は、別のテーブルにする」を実施しましょうということです。
最後に
データベース入門記事「テーブル設計・正規化」に関する説明は以上となります。
その他のデータベースの入門記事ついては以下の記事をどうぞ。
- 【データベース入門1】データベースとは
- 【データベース入門2】SQL コマンドとは、SQL 文の一覧
- 【データベース入門3】トランザクションと ACID 特性とは
- 【データベース入門4】バックアップ・クラスター・レプリケーション
- 【データベース入門5】テーブル設計・正規化 ←今ここ
- 【データベース入門6】オプティマイザー・実行計画