「DB設計の正規化ってどんな取り組み？」「メリットやデメリットがあれば教えて欲しい」などと考えていませんか。詳細がわからず、困っている方は多いでしょう。DB設計の正規化は、データを整合的に扱うため行われる取り組みです。矛盾を防げる、データを管理しやすくなるなどのメリットがあります。ここでは、DB設計における正規化の概要を解説するとともに正規化のメリット、デメリット、正規化の手順を紹介しています。理解を深めたい方は参考にしてください。
目次
データベースの正規化とは
簡単に説明すると、データの重複をできる限りなくして、データを整合的に扱えるように設計することです。具体的には、データを分割したり整理したりします。正規化の主な目的は矛盾を防ぐことです。矛盾の例として以下のものがあげられます。
| 部活名 | 顧問名 | 生徒名 |
| 野球部 | 岩井 | 田中 |
| 野球部 | 岩井 | 佐々木 |
| サッカー部 | 大島 | 伊東 |
人事異動で、野球部の顧問が「岩井」から「山本」に代わったとします。顧問名に更新漏れがあると矛盾が生じてしまいます。
| 部活名 | 顧問名 | 生徒名 |
| 野球部 | 山本 | 田中 |
| 野球部 | 岩井（※） | 佐々木 |
| サッカー部 | 大島 | 伊東 |
野球部に所属している「田中」の顧問は「山本」、「佐々木」の顧問は「岩井」です。データが重複する上記のテーブルは、矛盾が発生しやすいといえるでしょう。設計により、このようなトラブルを防ぐことが正規化と考えられます。
【関連記事】：DBの正規化とは？メリット・デメリットを解説
データベースの正規化のメリット
データベースの正規化には、さまざまなメリットがあります。主なメリットとして以下の3点があげられます。
メリット①データの整合性をとれる
正規化によりデータの整合性をとりやすくなります。ここでいう整合性は、データの矛盾を防ぐことといえるでしょう。たとえば、以下のデータがあったとします。
| 生徒ID | 生徒名 | 部活ID | 部活名 | 顧問名 |
| 1 | 田中 | 101 | 野球部 | 岩井 |
| 2 | 佐々木 | 101 | 野球部 | 岩井 |
| 3 | 伊藤 | 102 | サッカー部 | 大島 |
前述のとおり、正規化を行っていないと矛盾が生じやすくなります。たとえば、野球部の顧問が「岩井」から「山本」に代わると、野球部に所属するすべての生徒の行を変更しなければなりません。抜けや漏れが発生すると矛盾が生じてしまいます。上記のテーブルを、以下のように分割すると更新の手間を省けます。
| 生徒ID | 生徒名 | 部活ID |
| 1 | 田中 | 101 |
| 2 | 佐々木 | 101 |
| 3 | 伊藤 | 102 |
| 部活ID | 部活名 | 顧問名 |
| 101 | 野球部 | 岩井 |
| 102 | サッカー部 | 大島 |
また、抜けや漏れも発生しにくくなる、つまりデータの整合性を取りやすくなります。
メリット➁データが管理しやすい
正規化を行うことで、データを管理しやすくなります。たとえば、以下のデータがあったとします。
| ID | 名称 | 分類 |
| 1 | トマト | 野菜 |
上記では「オレンジ」と入力するところを、誤って「トマト」と入力しました。「名称」を「オレンジ」に変更するだけでよいと考えてしまいがちですが、この場合は「分類」の変更も必要です。「分類」を「果物」に変更すれば、データの整合性をとれます。簡単に修正できますが、テーブルが複雑になるとどうでしょうか。抜けや漏れが発生して、データに矛盾が生じる恐れがあります。したがって、上記のテーブルは、データの管理に適していません。正規化で、テーブルの分割などをすると、データを管理しやすくなります。
メリット③データを柔軟に変更できる
データを変更しやすくなる点も正規化のメリットです。先ほどのテーブルをもとに解説します。
生徒ID 生徒名 部活ID 部活名 顧問名
1 田中 101 野球部 岩井
2 佐々木 101 野球部 岩井
3 伊藤 102 サッカー部 大島
上記のテーブルだと、部活名や顧問名が変更になった場合に、該当するすべての生徒の行でこれらの名称を変更しなければなりません。手間がかかるうえ、ミスも発生しやすくなります。次のようにテーブルを分割すると、変更する箇所が1行だけになります。
| 生徒ID | 生徒名 | 部活ID | 部活名 | 顧問名 |
| 1 | 田中 | 101 | 野球部 | 岩井 |
| 2 | 佐々木 | 101 | 野球部 | 岩井 |
| 3 | 伊藤 | 102 | サッカー部 | 大島 |
| 部活ID | 部活名 | 顧問名 |
| 101 | 野球部 | 岩井 |
| 102 | サッカー部 | 大島 |
例えば、野球部の顧問が「岩井」から「山本」に代わった場合は「顧問名」変更するだけで済みます。「生徒ID」「1」や「2」の行を変更する必要はありません。正規化を行うと、データを柔軟に変更できるようになります。
データベースの正規化のデメリット
データベースの正規化には、注意したいデメリットもあります。代表的なデメリットとしてあげられるのがパフォーマンスの低下です。テーブルを分割すると、結合操作が必要になります。この影響でパフォーマンスが低下してしまうことがあります。正規化は、データの整合性を優先する取り組みと考えられるでしょう。
この問題に対処するため、正規化を意図的に行わないことを検討できます。ただし、正規化を行っていないテーブルは、更新作業を行いにくいうえ、矛盾も生じやすくなります。大きなデメリットがあるため、積極的に勧められるわけではありません。一般的には、明確な理由がない限り正規化を行うほうがよいと考えられています。
【関連記事】：データベースの種類は？役割やメリット・課題について詳しく解説
正規化の手順
正規化の段階には第一～第五正規形などがあります。ちなみに、正規化を行っていないものを非正規形といいます。ここでは、第一～第三正規形について解説します。
第一正規形
簡単に説明すると、テーブル内の1つのセル（ここでは行と列が重なる1つのマス）に1つの値を設定している状態（繰り返しがない状態）です。たとえば、以下のテーブルがあったとします。
| 注文ID | ユーザーID | 顧客名 | 住所 | 商品ID | 商品名 | 注文数 |
| 101 | 1001 | 田中 | 東京都千代田区 | 10
52 15 |
Tシャツ
ソックス バッグ |
1
2 1 |
1つのセルに複数の値を含むため、上記のテーブルは非正規形といえます。第一正規形にしたい場合は、主キー（注文ID・商品ID）を設定して、繰り返しているデータを、別のテーブルに分けるとよいでしょう。
注文テーブル
| 注文ID | ユーザーID | 顧客名 | 住所 |
| 101 | 1001 | 田中 | 東京都千代田区 |
明細テーブル
| 注文ID | 商品ID | 商品名 | 注文数 |
| 101 | 10 | Tシャツ | 1 |
| 101 | 52 | ソックス | 2 |
| 101 | 15 | バッグ | 1 |
1つのセルに1つの値を設定している上記のテーブルは第一正規形といえます。
第二正規形
簡単に説明すると、部分関数従属をなくした状態です。部分関数従属は、複数の主キーが存在するテーブルで、いずれかの主キーだけで決まる項目がある状態といえるでしょう。以下のテーブルにおける主キーは注文IDと商品IDです。
注文テーブル
| 注文ID | ユーザーID | 顧客名 | 住所 |
| 101 | 1001 | 田中 | 東京都千代田区 |
明細テーブル
| 注文ID | 商品ID | 商品名 | 注文数 |
| 101 | 10 | Tシャツ | 1 |
| 101 | 52 | ソックス | 2 |
| 101 | 15 | バッグ | 1 |
商品IDが決まると商品名も決まります(＝部分関数従属)。したがって、この状態を解消する必要があります。
注文テーブル
| 注文ID | ユーザーID | 顧客名 | 住所 |
| 101 | 1001 | 田中 | 東京都千代田区 |
明細テーブル
| 注文ID | 商品ID | 数量 |
| 101 | 10 | 1 |
| 101 | 52 | 2 |
| 101 | 15 | 1 |
商品テーブル
| 商品ID | 商品名 |
| 10 | Tシャツ |
| 52 | ソックス |
| 15 | バッグ |
除期の分割により部分関数従属はなくなりました。
第三正規形
簡単に説明すると、推移関数従属がない状態です。推移関数従属は、主キー以外の項目でテーブル内の一部の項目が決まる状態です。つまり、主キーAによりBが決まり、BによりCが決まる状態といえるでしょう。以下の注文テーブルでは、ユーザーIDにより顧客名と住所が決まります。
注文テーブル
| 注文ID | ユーザーID | 顧客名 | 住所 |
| 101 | 1001 | 田中 | 東京都千代田区 |
したがって、ユーザーIDを主キーに設定してテーブルを分割すると第三正規形にできます。
顧客テーブル
| ユーザーID | 顧客名 | 住所 |
| 1001 | 田中 | 東京都千代田区 |
注文テーブル
| 注文ID | ユーザーID |
| 101 | 1001 |
注文明細テーブル
| 注文ID | 商品ID | 数量 |
| 101 | 10 | 1 |
| 101 | 52 | 2 |
| 101 | 15 | 1 |
商品テーブル
| 商品ID | 商品名 |
| 10 | Tシャツ |
| 52 | ソックス |
| 15 | バッグ |
以上のテーブルは、第三正規形と考えられます。
正規化はDB設計に欠かせない取り組み
ここでは、DB設計における正規化について解説しました。正規化は、設計でデータの重複をできる限りなくすことです。データの整合性をとれる、データを管理しやすくなる、データを変更しやすくなるなどのメリットがあります。DB設計に欠かせない取り組みといえるでしょう。正規化には第一～第五正規形などがあります。順を追って進めていくことが大切です。この記事を参考に、正規化に取り組んでみてはいかがでしょうか。
