はじめに
RDB（リレーショナルデータベース）の設計について、基本的な事項をまとめます。
- エンティティ
- リレーション
- 正規化
目的を明らかにする
DB設計に限った話ではありませんが、まずは目的や要件を明らかにすることが大切です。
ここが狂っていると全ての設計に狂いが生じてしまいます。
例えば
大学で使用するDB。生徒、教員、履修講義を一覧したい。
エンティティを定義する
目的がわかると、エンティティも自ずと明らかになってきます。
慣れないうちは、名詞から考えると良いでしょう。例えば先の例から名詞だけを抜き出すと、そのままエンティティとして使用できます。
- 大学
- 生徒
- 教員
- 履修講義
例外を考慮する
「普通はこうだろう」「大丈夫だろう」という考えはDB設計に禁物です。
DBは長期スパンで使用されるので、サービスの拡大や継続などによって破綻がないように考えをめぐらせる必要があります。
1900年台の人にとって、2000年は遠い未来に感じられたかもしれませんが、実際に2000年問題となって現れました。
リレーション
RDBはその名の通り、テーブル同士の関係性（リレーション）を大きな特徴としています。
One to One
一対一の関係。
- 夫には妻がいる
例
[夫] -- [妻]
One to Many
一対多の関係。
- 教員は、複数の講義を受け持つ。
- 講義には１人の担当教員がいる。
例
[教員] -= [履修講義]
Many to Many
多対多の関係。
- ある生徒は複数の講義を履修する
- ある講義を多数の生徒が履修している
[生徒] == [履修講義]
多対多の関係性は中間テーブルを用意して一対多の関係に直します。
例
[生徒] =- [生徒：履修講義] -= [履修講義]
正規化
正規化は複数のプロセスに分けることができます。一般的に以下の３つは網羅すべきと考えられています。
- 第1正規化
- 第2正規化
- 第3正規化
第1正規化
繰り返しやダブりが取り除かれたものを第1正規形とします。
IDなどのプライマリキー（PK）や、値の組み合わせを用いて、データが一意であるよう保証します。
第2正規化
テーブルを分割し、テーブル同士のリレーションを定義します。
こうすることで、更新する箇所を局所的に抑えることができます。
分割の基準
例えば「生徒番号」がわかれば「名前」「学年」「成績」など関連するデータが決定されるなら、その部分だけ別テーブルに切り出せる事になる。
こういうのを部分関数従属性があるといいます。
第2正規化とは部分関数従属性を取り除くことです。
第3正規化
第2正規化された状態のテーブルに、そのテーブルと直接関係のない項目が残っている場合があります。
例えば、「生徒」テーブル、「教員」テーブルの項目として「郵便番号」「住所1」「住所2」と項目がある場合、「住所」テーブルに切り出すことができるでしょう。
このようにプライマリキーに直接従属しない部分もテーブルを分けられる場合があります。
※ただし、これを適用しすぎると返って管理が大変になることもあるため、ちょうどいいバランスで第3正規化を行う必要があります。
まとめ
以下の基本的な事項についてまとめました。
- エンティティ
- リレーション
- 正規化