DB設計チェックリスト
一般
複数の目的に使われるテーブル
- 1つのテーブルが複数の意味を持つ
- Usersテーブルに会員、管理者、事業者などが混在しているなど
複数の目的に使われるカラム
- レコードの属性に合わせて値の意味が変わり、読み替えが必要になるカラムは存在しないか
- 会員だと入会日、スタッフだと入社日とするなど
導出項目が保存されていないか
- 計算によって導き出せる項目を保存していないか
- 例えば、年齢などは生年月日が分かっていれば導出可能
カラムの数は適切か
- カラム数が12を超えると分割を検討する
- エンティティの特性上、カラム数が膨らむことはよくあることなので機械的に分割してはいけない
- col1, col2, col3...のように連番が付いたカラムは別テーブルに移動する
レコード数が大きくなりすぎるテーブルはないか
- ユーザーの行動ログなど要件的にレコード数が膨大になるテーブルはないか
- パーティションを切る、RDBMS以外の別システムに切り出すなども検討する
有意コードはないか
- 桁数に特定の意味を持つコードを定義していないか
- 9から始まるidは管理者、1から始まるidはユーザーなど
- 既存システムで使われているなどやむを得ない場合を除き、有意コードを採用するべきではない
エンティティの粒度
- 登録されるデータは情報の意味を喪失しない粒度で最小か
- 凝集度は適切か？ 冗長なデータはないか
イベントエンティティ
- そのエンティティにタイムスタンプは必要か
- タイムスタンプを必要としないテーブルの場合、それはイベント・エンティティではない可能性が高い。
データのライフサイクル
- 異なるライフサイクルのデータがひとつのエンティティに同居していないか
- INSERT時に必ずNULLになる項目（別のタイミングでUPDATEされる項目）は、データのライフサイクルが異なるので別テーブルに追い出すことを検討する。
Null
- デフォルトでNullが登録されるカラムはないか
- デフォルト値がNULLになるカラムはそのエンティティの構成要件として必須ではない可能性が高い
フラグ
- 削除フラグは別の解法で置き換えられないか
- ステータスとして表現する余地はないか
- 本当に0/1で表現できる要件なのか、隠れた要件はないか
正規化
第一正規形
- 繰り返し属性は除去されているか
- 繰り返し項目は別テーブルへ追い出しておかなければならない。
第二正規形
- 第一正規形を満たしているか
- 満たしていないなら第一正規化する
- 関数従属性のある値は別テーブルに追い出されているか
- 関数従属性のある値があるなら別テーブルに追い出す
第三正規形
第四正規形
第五正規形
BC正規形
- JSON型、配列型フィールドを使っていないか
- 合理的な理由がない限り、素直に別テーブルに追い出すべきであり、みだりにJSON型・配列型のフィールドを使用してはならない。
参考資料