テーブル設計の流れ
テーブル設計の流れの概要にめちゃくちゃわかりやすくテーブル設計の手順が書かれていたので記載。これをベースに作業を進める。
- メインとなるテーブル名を出す
- 「誰が・何が」を考えてテーブル名を出す
- 「誰を・何を」を考えてテーブル名を出す
- 各テーブルのカラムを出す
- 残ってる、表現できていない情報があれば、テーブルになるか、カラムに追加するかを考える
- 関連を入れる
- 制約とデフォルト値とINDEXを考える
図書館の予約申込書
上記をベースにご注文用紙のテーブル設計を行う。題材は次のもの。
メインとなるテーブル名を出す（イベント系エンティティを洗い出す）
この紙の目的を考えると、『図書館利用者が借りる本を予約するもの』なので、メインとなるイベントは『予約』となる。
「誰が・何が」、「誰を・何を」を考えてテーブル名を出す（リソース系エンティティを洗い出す）
「誰が・何が」、「誰を・何を」を考えてテーブル名を出す。『利用者』が『書籍』を予約するので、リソース系エンティティを追加。
各テーブルのカラムを出す
予約申込書から見た目通りにカラムを設定していく。
表現できていない情報を、テーブルにするか、カラムに追加するかを考える
下記の項目がまだ表現できていない。
- 申込日
- 連絡の仕方
- 通知可否
- 受け取り場所
- 何で知ったか
申込日、通知可否、受け取り場所は、いずれも『ある予約についてそれぞれ決めるもの』だと思うので、予約エンティティの属性で良さそうと思ったので追加してみる。
残りの項目は次のもの。
- 連絡の仕方
- 何で知ったか
「何で知ったか」は明らかにどこにも属さなそうなので新規エンティティにする。そして、「連絡の仕方」の電話番号は利用者に対して複数持てそうなので利用者エンティティには入れないほうがいい気がする。加えて「連絡の仕方」の連絡方法はある程度手段（チェックボックスの項目）が決まっていそうなので、それぞれエンティティ化した方がいいかと思うので、次のようにする。
関連を入れる
関連を入れていく。具体的なデータ（自分がこの申込書を使って申し込むこと）を考えながら関係や多重度を考えていく。外部参照キーも入れていく。
制約とデフォルト値とINDEXを考える
最後にカラムごとに下記を設定するかどうかを考える。
- 一意性制約
- 非NULL制約
- 外部キー制約（参照整合性制約）
- 検索INDEX、複合検索INDEXをつけるかどうか
- デフォルト値
参考書：解答例
参考書の答えは、下記だった。だいたい似たような感じだったけど、『出版社』の部分はなるほどなと思った。出版社エンティティとして分けてしまったほうが疎になる気がしました😅
さらに、シンプルな例が下記として紹介されていた。
こちらでは「出版社情報はメモ程度でいい」なら、書籍に組み込んでしまってもいいということで書籍エンティティに含まれていた。同じ発想であったため、とりあえずここまでの認識はそれっぽい感じになっていると感じました😅
