こちらの本を読んでまとめ
正規化について
正規化とは
あるルールに従った形に整理すること
正規形とは
正規化には何段階かレベルがあり、それらを正規形と呼ぶ
第1正規形
1テーブルに1つのカラムに1つの値が入った状態
- スカラ値という状態
第2正規形
1テーブル内で主キー以外で主キーのような役割になっているカラムのグループを別テーブルへ切り出した状態
- 完全関数従属という状態
第3正規形
1テーブル内で主キーと1対多の関係になる実用値が入るカラムを切り出した状態
- 推移的関数従属という状態
DB設計時
基本的には第3正規化までを行えば良い
実践メモ
ここからはあくまで個人的観測(他の書籍から得た知見も含む)
基本ステップ
- 業務概念を洗い出す
- 1つの概念に相当するデータ項目を洗い出す
- データ属性を定義する
ポイント
- ある程度システムの全体像があって、必要なデータがイメージできるなら第1正規化から順を踏んで行う必要はない
- 第2、第3正規化を検討しながら繰り返す
- 概念として洗い出すのとテーブルやカラムとして洗い出すのを分ける考え方もあるが、一緒に考える
- 設計を追加・改善する前提なため
- ドキュメントの管理コストを減らすため
- 設計は業務知識習熟度に依存し、経過によってより良い設計ができるため
業務概念を洗い出す
洗い出す際は大きく2つに大別して考える
- マスタ系
- 実在する具体情報系
- トランザクション系
- 活動による記録情報系
概念はひとまずテーブル名として考える
項目はひとまずカラム名として考える
1つの概念に相当するデータ項目を洗い出す
データが活用される画面や業務をイメージしながら、そこで使われるデータが概念に含まれるか検討しつつ洗い出す
-
最初に洗い出した概念の中になさそうな場合は新しい概念を作成する
- 非依存型のテーブル
-
最初に洗い出した概念の中に項目を洗い出していった後、更に細かい項目が出てきたら別概念として切り出す
- 依存型のテーブル
- 関数従属の関係
- リレーションシップを引く
-
最初に洗い出した概念がある性質に特化した概念として、システム上重要度が高い場合は汎化型の概念として作成する
- オブジェクト指向のサブクラスのようなイメージ
データ属性を定義する
フレームワークやDB(サービス)によってよしなにできたり制約があったりするので、前提としてアーキテクチャの選定を行っておく
それに法って決める
雑感
データの設計ができるとシステム地盤ができて開発時に浮遊感がなくなる気がするので、初期にしっかり行う