データベースの正規化とは？
こんにちは。
最近はデータベースについて学んでいます。
というのも今まで概念的には何となく理解していたんですけど、やっぱり人にうまく説明できないところがありまして。。
特によく出てくる「正規化」。
改めて言葉で説明しろって言われると難しくないですか？
ぼくだけですかね？笑
ただそんなことも言ってられないので、きちんと勉強することにしました。
今日はそんなことについて書いていきますね。
論理設計とは
正規化の前にまずはデータベース設計方法について。
データベースの設計方法は2つあります。
それが論理設計と物理設計。
物理設計はその名前の通り、実際に使うデータベースの容量やサーバーのスペック容量などのいわゆる物理層の制約を考慮して設計する方法です。
それに対してもう一つの論理設計というのが、上記の物理層の制約にとらわれず設計していく方法になります。
そして今回の話の中心である「正規化」もこの論理設計の一部になります。
せっかく論理設計の話になったので、簡単に論理設計の流れも紹介しておきます。
1．エンティティの抽出
（どのようなデータを扱うか）
↓
2．エンティティの定義
（各データがどのような属性を持つか）
↓
3．正規化
↓
4．ER図の作成
（各データの関係性を図で整理）
となります。
正規化とは
では本題の正規化とは何かについて説明していきましょう。
正規化とはデータベースで保持するデータの冗長性を排除し、一貫性と効率性を保持するためのデータ形式です。
例えば正規化という概念を知らず、テーブルを作成していくと、1つの情報が複数のテーブルに存在してしまうことがあります。
そうすると無駄なデータ領域を使うだけでなく、データの更新処理をするときにもいろいろなところ更新しなければならないなどの無駄な労力も必要になります。
そういった「無駄」をできるだけなくすのが「正規化」という作業です。
関数従属性とは
正規化においてはこの「関数従属性」という概念の理解が必須です。
関数従属性とは「ある属性の値が決まることによって他の属性の値が一意に決まること」です。
例えば都道府県を管理している以下のような表があったとします。
そしてこの表が都道府県ごとに番号をふった都道府県No.と都道府県名という
属性をもっていたら、都道府県No.がわかれば都道府県名もわかるということになりますよね。
| 都道府県No | 都道府県名 |
| 1 | 北海道 |
| 2 | 青森県 |
| 3 | 秋田県 |
| 4 | 岩手県 |
| 5 | 宮城県 |
これが関数従属性です。
そして正規化はこの関数従属性がテーブル全体で満たすよう整理していく作業なんですね。
ここから実際の正規化の手順について説明していきます。
※正規化は第5正規化まであるのですが、実務で行われるのは第3正規化までになるので、以下第1～第3正規化で記載していきます。
第一正規化
第一正規化とは「一つのセルの中に一つの値しか含まない状態にすること」です。
このように一つのセルにある一つだけの値を、英語で単一のという意味を持った「スカラ」という言葉を使って「スカラ値」と呼んだりもします。
例えば以下の表1を表2に変える作業ですね。
表1
| ID | 親 | 子 |
| 1 | フグ田マスオ フグ田サザエ |
フグ田タラオ |
| 2 | 波野ノリスケ 波野タイ子 |
波野イクラ |
↓
表2
| ID | 親 | 子 |
| 1 | フグ田マスオ | フグ田タラオ |
| 2 | フグ田サザエ | フグ田タラオ |
| 3 | 波野ノリスケ | 波野イクラ |
| 4 | 波野タイ子 | 波野イクラ |
なぜこういった作業が必要かというと、1つのセルに複数の値が入っていると一意に値が特定できなくなるためです。
第二正規化
第二正規化とは「テーブル内の部分関数従属を解消し、完全関数従属のみにすること」です。
これは以下表1を表2、表3に分ける作業です。
表1（社員）
| 部署コード（主） | 部署名 | 社員コード（主） | 社員名 | 生年月日 |
| A1 | 経理 | 1 | 山田太郎 | 1979/1/1 |
| A1 | 経理 | 2 | 鈴木花子 | 1983/3/7 |
| A2 | 総務 | 3 | 佐藤一郎 | 1986/5/20 |
↓
表2（社員）
| 部署コード（主） | 社員コード（主） | 社員名 | 生年月日 |
| A1 | 1 | 山田太郎 | 1979/1/1 |
| A1 | 2 | 鈴木花子 | 1983/3/7 |
| A2 | 3 | 佐藤一郎 | 1986/5/20 |
表3（部署）
| 部署コード（主） | 部署名 |
| A1 | 経理 |
| A2 | 総務 |
表1で主キーは部署コードと社員コードになるわけですが、部署名は社員コードがわからなくても部署コードさえわかれば、特定できますよね。
こういった状態を「部分関数従属」と呼び、これを表3のように別表として切り出します。
そして表2のように全ての列に従属性がある「完全関数従属」の状態を作り出すのが第2正規化なんです。
第二正規化がなぜ必要かというと第二正規化を行っていない状態だと一部に不明な情報があるだけで情報が登録できず、不便だからです。
例えば表1の状態で部署の情報だけあらかじめわかっていても、社員情報がわからないと登録ができなくなりますよね。
第三正規化
第三正規化とは「推移的関数従属を解消すること」です。
これも表を使って説明していきますね。
表1（社員）
| 部署コード（主） | 社員コード（主） | 社員名 | グループコード | グループ名 |
| A1 | 1 | 山田太郎 | 0A | Aグループ |
| A1 | 2 | 鈴木花子 | 0B | Bグループ |
| A2 | 3 | 佐藤一郎 | 0B | Bグループ |
↓
表2（社員）
| 部署コード（主） | 社員コード（主） | 社員名 | グループコード |
| A1 | 1 | 山田太郎 | 0A |
| A1 | 2 | 鈴木花子 | 0B |
| A2 | 3 | 佐藤一郎 | 0B |
表3（グループ）
| グループコード | グループ名 |
| 0A | Aグループ |
| 0B | Bグループ |
表1では主キーではないですが、関数従属性しているところがありますよね。
そうです。
グループコードとグループ名です。
これは主キーが関係しておらず、非キーと非キーの関係になります。
こういった非キーの従属関係のことを「推移的関数従属」と呼び、第三正規化ではこの状態を解消していきます。
まとめ
正規化についてまとめてみました。
あらためて図解すると自分の頭の中もすっきりするので良いですね！
今後もこうやって勉強したことを残していこう！
可能な限り(笑)
ちなみにぼくは今回の学習はこの本を中心にやりました。
今までいろいろなところで断片的に理解していたことがこの本だと体系的にまとめてあって初心者の方にはとってもオススメです。
良かったら参考にしてみてください。
今日もここまで読んで頂き、ありがとうございました。
