(0.ゼロからやる場合)
なにはともあれ、まずは項目集めから。
項目が集まらなければ何もしようがないので、とにかく要求／要望を持っている人から
そのシステムを作るにあたり必要となる項目を聞き出す。※実はここが一番難しいけど。
1. 項目が集まってきたらテーブルを作成する。
マスタ系とトランザクション系で大きく分類し、関連する項目をまとめテーブルにする。
例） 社員、品目 など固定的に参照されるものはマスタ系
お知らせ、記事 など常にデータが入れ替わっていくものはトランザクション系
※この段階というより、要件定義フェーズでこの意識で聞けるとスムーズかも。
2. 主キーを決めて、参照関係を決める。
作るシステムの性格やデータベースにもよるが、
id列が主キーになるパターンが増えてきている。よく企業システムなどで利用される複数の項目でキーを表す複合主キーのアプローチは、少し下火になってきているような気がする。（個人的には）
参照関係の決め方は大体下記パターン。
１：１ 例）国：首都
１：多 例）会社：社員
多：多 例）工場：種類
さらに覚えておくといいのが、 一方が 0 の場合も成立しうるかどうか。
例）運転者：違反履歴
１：多ではあるが、違反歴がない人も当然いるので、厳密には 1: 0もしくは多となる。
この違いは、画面設計などにも影響してくるので、要注意。
3. 項目ごとの属性を決める
NotNull属性
⇒ 盲目的に全てにつけると面倒なコーディングになるので、
業務上はもちろん、画面上も必須入力であるべき項目に対してのみ付けたほうがよい。
Default値
⇒ insert時に特に指定しなかった場合に、自動で設定される値。地味に重宝する。
桁数を確認
⇒ データベースによって桁数の許容範囲等々は変わってくるのできちんと確認すること。
4. ER図にして推敲する。
ここからが本番!
むしろ、このフェーズでいかに悩み改良できるかが、システムの良し悪しをきめる！
色々あるが、個人的には下記のようなポイントに注目して行う。
・ ○○が１に対して、△△は複数であっているか？
ない場合もある？等の参照関係のシミュレーション。
・ 削除した場合に残された参照関係をもつデータはどうなるか？
そのデータがなくなった場合にシステムはどう動くことになるか？
・ データ階層は適切か
例）ECサイトならルートのデータは、 店舗 なのか 販売エリア＞店舗 なのかetc..
・ そうめったに変動しないのであれば、マスタに持たなくてもプログラムの定数でどうか？
・ 列持ちテーブルになっていないか？
特殊な理由がない限り、基本的には行持ちテーブルで行うこと。
・ 必須な項目／あると便利な項目／無くてもいい項目 この区別をしっかりと付ける。
・ 検索処理を考えた時に、結合が増えることでコストが高くなる。
その場合は、検索条件をあえて検索対象テーブルに保持するのも考え方の１つ（正規化を崩す）
5. （日をおいて）さらに推敲＆他の人にもみてもらう
実際に、いくつかデータパターンを作ってみると、いろんなケースに気づけるので、オススメ。
Excelでもなんでもいいので、レコードの動きを視覚化することが大切。
6. クイックモデリングチェック項目
- データが入ってないカラムが多い
- １つのカラムに複数以上の意味がある
- データが重複している
- 名前から意味が分かりづらい
- 他のカラムに依存して値が変わるカラムがある
- 型が適切ではない。例）整数で１０桁＝１０億？
- NOT NULL制約を使っているか
- 外部参照キーの設定があるか
- 導出項目をもっていないか（持っている場合は理由があるか）
- フラグがありすぎるときは、少しでも減らせないか検討する
おわり。
とにかくイマジネーション＆経験を重ねるのみ！！