DB設計(テーブル設計)はなぜ重要なのか?
データ設計(特に論理設計)がシステムの品質を最も大きく左右する。
・ソフトウェアは「データの流通機構」であるから。
・どのようなプログラムが必要になるかは、どのようなデータをどういうフォーマットで設計するかに左右されるから。
インフラは担当しないアプリケーションエンジニアは、論理設計(ER図)ができるようになる必要がある。
論理設計の4ステップ
1.エンティティの抽出
データを管理する概念をリストアップする。
図書館システムの場合、書籍、司書、会員、貸し出し、予約などがエンティティとして挙げられる。
「貸し出し」「予約」のように、物理的実体を伴う必要はない。
2.エンティティの定義
各エンティティが持つデータをリストアップして決めていく。
書籍エンティティの場合、「書籍名」「出版日」「著者」「ISBN」など、データ管理したい項目をエンティティごとに書き足していく。
3.正規化(重要)
正規化とはテーブルを適切に分割していくことに過ぎない。正規化を意識しなくてもできている人も多い。
正規化はCRUDが整合的に行えるように、エンティティのフォーマットを整理することが重要な目的。第三正規化までできていれば良い。
第一正規化
1つのカラムには1つの値しか含まないようにすること。
一般には全カラムがスカラ値のみ持ちうる状態を第一正規形と言う。スカラ値とは、それ以上分割できない値のこと。
カラムが配列、カンマ区切りの文字列などを想定する場合は、同じテーブル内の別カラムに出し分ける or 別テーブルに持てるようにすること。
NG例:第一正規化されていない
予約ID | 図書ID |
001 | T001 |
002 | T002 T003 |
003 | T004,T005 |
OK例1:第一正規形(△)
予約ID | 図書ID1 | 図書ID2 |
001 | T001 | null |
002 | T002 | T003 |
003 | T004 | T005 |
スカラ値のみ持つようにするという観点では、第一正規形の条件を満たしている。しかし、繰り返し項目は同一レコードのないに持つ(横持ち)ではなく、別レコードにする(縦持ち)ことが望ましいため△。
OK例2:第一正規形
予約ID | 図書ID |
001 | T001 |
002 | T002 |
002 | T003 |
003 | T004 |
003 | T005 |
第二正規化
ID項目に対する属性項目のうち、属性項目を子テーブルに切り出すこと。
理路的には部分関数従属を取り除いて、完全関数従属となるようにすること。
関数従属とは、Xが決まれば Yが決まるという関係である。図書ID(X)が決まれば、図書名(Y)が決まるため、図書名は図書IDに関数従属していると言う。
一般的には、主キー項目と主キーではない項目(非キー項目)の間に関数従属性が生じる。
NG例:第二正規化されていない
予約ID | 図書ID | 図書名 |
001 | T001 | ひらがな本 |
002 | T002 | ドラゴンボール |
002 | T003 | DB設計の本 |
003 | T004 | UI設計の本 |
003 | T005 | テスト自動化 |
OK例:第二正規形
予約ID | 図書ID |
001 | T001 |
002 | T002 |
002 | T003 |
003 | T004 |
003 | T005 |
図書ID | 図書名 |
T001 | ひらがな本 |
T002 | ドラゴンボール |
T003 | DB設計の本 |
T004 | UI設計の本 |
T005 | テスト自動化 |
第三正規化
主キー以外のカラムに従属しているカラムを子テーブルに切り出すこと。
(第二正規化の過程でもう切り出してしまっているかもしれません。)
理路的には推移的部分従属を取り除くことである。
第二正規化と第三正規化の違いは?
第二正規化は主キーに関する属性項目を別テーブルに切り出すこと。
第三正規化は第二正規化によってできた各テーブルにおいて、さらに切り出せる項目を切り出すことである。
正規化のポイント
- 正規化後は、結合(JOIN)することで必ず正規化前に戻すことができる。このことを無損失分解という。正規化の逆は結合である。
4.ER図の作成
ER図を作成する。ER図は業務フロー図よりも大事。
参考書籍
この記事を書くにあたって、次の本で勉強しました。
達人に学ぶDB設計 徹底指南書 おススメ度★★★★★