こんにちは。株式会社iimonでバックエンドエンジニアを担当している玉山です。
今回はDB(データベース)の正規化についてです。
それでは早速見ていきましょう。
目次
正規化とは
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを、データベースの正規化と呼びます。正規化を行っておくと、データの追加・更新・削除などに伴うデータの不整合や喪失が起きるのを防ぎ、メンテナンスの効率を高めることができます。
正規化の段階には、第1～第5正規形およびボイスコッド正規形がありますが、ここでは、データベースを設計する際に一般的に用いられる第1～第3正規形までを説明していきます。
ref：https://oss-db.jp/dojo/dojo_info_04
非正規形
正規化がまったく行われておらず、1行の中に複数の繰り返し項目が存在するようなテーブルは非正規形と呼びます。
例えば以下のようなデータになります。
DBのテーブルは以下のような状態です。
物件テーブル
| 物件ID | 物件名 | 号室 | 物件都道府県 | 管理会社名 | 管理会社電話番号 | 管理会社都道府県 | 物件ID | 物件名 | 号室 | 物件都道府県 | 管理会社名 | 管理会社電話番号 | 管理会社都道府県 | 物件ID | 物件名 | 号室 | 物件都道府県 | 管理会社名 | 管理会社電話番号 | 管理会社都道府県 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | マンション島田 | 101 | 東京都 | 島田ステートメント | 03-111-1111 | 東京都 | 1 | マンション島田 | 201 | 東京都 | 島田ステートメント | 03-111-1111 | 東京都 | 3 | イイモンマンション | 101 | 神奈川県 | iimon不動産 | 042-111-1111 | 神奈川県 |
第1正規形
リレーショナルデータベースでは原則としてレコード単位で個々のデータを扱いますので、非正規形のデータはデータベースに格納することすらできません。まずは、繰り返し項目のそれぞれを別レコードとして独立させます。
物件テーブル
| 物件ID | 物件名 | 号室 | 物件都道府県 | 管理会社名 | 管理会社電話番号 | 管理会社都道府県 |
|---|---|---|---|---|---|---|
| 1 | マンション島田 | 101 | 東京都 | 島田ステートメント | 03-111-1111 | 東京都 |
| 2 | マンション島田 | 201 | 東京都 | 島田ステートメント | 03-111-1111 | 東京都 |
| 3 | イイモンマンション | 101 | 神奈川県 | iimon不動産 | 042-111-1111 | 神奈川県 |
第2正規形
第2正規形では、部分関数従属性を排除します。
部分関数従属性とは、候補キー(DBの概念では主キー)の一部に関数従属している状態を「部分関数従属している」と言います。
例えば、物件IDが決まれば管理会社名が決まる場合、管理会社名は物件IDに関数従属するといいます。
表記はこのようになります。
物件ID→管理会社名
それと物件IDは独立属性、管理会社名を従属属性と言います。
独立属性は複数でもOKで、例えば、あり得ないですが物件名と号室の組み合わせで管理会社名が違う場合、独立属性が物件名と号室になり、以下のような表記をします。
{物件名、号室}→管理会社名
ではなぜ第2正規形するのでしょうか。
それは第1正規形にすることでデータベースに格納できるようにはなりましたが、データ管理の観点からはまだまだ不十分です。
例えば、新たな管理会社が増えたとしても、実際に何らかの物件が増えるまでは、その情報を管理することができません。
また、管理会社の電話番号が変更になると、複数のレコードを更新しなければならないため、1件しか更新しなかった場合、不整合を生じる恐れがあります。これは、物件情報、管理会社情報といった独立した情報をすべて同一のレコードで扱っていることが理由です。だから、これらを別々のテーブルに分割することを考える必要があります。
第1正規形のテーブルを見てみると、レコードを一意に定める要素は{マンション名, 管理会社}（これを主キーと呼びます）であることが分かります。主キー以外の項目（非キー属性）について、主キーの一部の要素だけで決まる（部分関数従属と言います）ものがあれば別テーブルに分離させましょう。各項目の従属関係は次の図を参照してください。
物件テーブル
| 物件ID | 物件名 | 号室 | 物件都道府県 | 管理会社ID |
|---|---|---|---|---|
| 1 | マンション島田 | 101 | 東京都 | 1 |
| 2 | マンション島田 | 201 | 東京都 | 1 |
| 3 | イイモンマンション | 101 | 神奈川県 | 2 |
管理会社テーブル
| 管理会社ID | 管理会社 | 管理会社電話番号 | 管理会社都道府県 |
|---|---|---|---|
| 1 | 島田ステートメント | 03-111-1111 | 東京都 |
| 2 | iimon不動産 | 042-111-1111 | 神奈川県 |
第3正規形
第3正規形とは、全ての非候補キー(主キー以外のキー)が、候補キー(主キー)に対して推移的関数従属しない状態を指します。
つまり、非候補キーに対する関数従属を別表を分けます。
推移的関数従属とは、例えば、物件IDが決まれば物件名が分かる(物件ID→物件名)、物件名が分かれば物件都道府県が分かる(物件名→物件都道府県)というように間接的に繋がっている関係を物件都道府県は物件IDに対して推移的に関数従属していると言います。
管理会社テーブルにも同じことが言えます。
物件テーブル
| 物件ID | 物件名 | 号室 | 都道府県ID | 管理会社ID |
|---|---|---|---|---|
| 1 | マンション島田 | 101 | 1 | 1 |
| 2 | マンション島田 | 201 | 1 | 1 |
| 3 | イイモンマンション | 101 | 2 | 2 |
管理会社テーブル
| 管理会社ID | 管理会社 | 管理会社電話番号 | 都道府県ID |
|---|---|---|---|
| 1 | 島田ステートメント | 03-111-1111 | 1 |
| 2 | iimon不動産 | 042-111-1111 | 2 |
都道府県テーブル
| 都道府県ID | 都道府県 |
|---|---|
| 1 | 東京都 |
| 2 | 神奈川県 |
参考
https://oss-db.jp/dojo/dojo_info_04
