テーブル設計の流れ
テーブル設計の流れの概要にめちゃくちゃわかりやすくテーブル設計の手順が書かれていたので記載。これをベースに作業を進める。
- メインとなるテーブル名を出す
- 「誰が・何が」を考えてテーブル名を出す
- 「誰を・何を」を考えてテーブル名を出す
- 各テーブルのカラムを出す
- 残ってる、表現できていない情報があれば、テーブルになるか、カラムに追加するかを考える
- 関連を入れる
- 制約とデフォルト値とINDEXを考える
お持ち帰りご注文用紙
上記をベースにご注文用紙のテーブル設計を行う。題材は次のもの。
メインとなるテーブル名を出す（イベント系エンティティを洗い出す）
この紙の目的を考えると、『お客さんが何か食べたいものを注文するもの』なので、メインとなるイベントは『注文(order)』となる。
「誰が・何が」、「誰を・何を」を考えてテーブル名を出す（リソース系エンティティを洗い出す）
「誰が・何が」、「誰を・何を」を考えてテーブル名を出す。『お客さん(costomer)』が『商品(items)』を注文するので、リソース系エンティティを追加。
各テーブルのカラムを出す
注文表から見た目通りにカラムを設定していく。
表現できていない情報を、テーブルにするか、カラムに追加するかを考える
税込価格や『New』を示す情報が抜けているので、とりあえず見た目通りに『商品』エンティティに追加。
関連を入れる
関連の付け方は中々イメージしにくく、難しい。こういう時は、実際のデータを入れて考えると良いみたい。
例えば、自分が出前をとることを想像すると、御用達の店なら何回も注文するので「顧客-注文は、1対多」になるし、好きなものは何回も注文するので「注文-商品は、多対1」になって、あるカテゴリには複数の商品が入るので「カテゴリ-商品は、1対多」になるみたいな感じ。
よって、それぞれ、参照関係を設定していくと、次のような感じになる。
また、多対多になってしまうような時は注意が必要。その場合は、中間テーブルを作ってあげる必要がある。理由は、両者のエンティティが共通キーを持たない場合、SQLで結合しようとしても結合キーを指定できず、良い感じに結合できない（リレーション関係から情報を復元できない）から。
上の例だと１回の注文で１種類しか頼まないようなケースになってしまっているので、１回に複数種類の注文をするような時には、『orderエンティティは、複数のitemエンティティを持てば良いじゃん』と考えて、下記のようにしてしまうと、多対多関係になってしまう。
なので、中間テーブル（注文まとめ）を用意してあげる。下の例では、ordersエンティティで複数のorderエンティティを持てるにようにすることで、１回の注文でまとめて頼めるみたいな感じにしたER図。
制約とデフォルト値とINDEXを考える
最後にカラムごとに下記を設定するかどうかを考える。
- 一意性制約： ある列の組について一意性をもとめる。主キーと違い、複数設定可。
- 非NULL制約: NULL禁止
- 外部キー制約（参照整合性制約）: 参照の親子関係。親に該当するデータがないとエラー。
- 検索INDEX、複合検索INDEXをつけるかどうか
- デフォルト値
