テーブル設計の流れ
テーブル設計の流れの概要にめちゃくちゃわかりやすくテーブル設計の手順が書かれていたので記載。これをベースに作業を進める。
- メインとなるテーブル名を出す
- 「誰が・何が」を考えてテーブル名を出す
- 「誰を・何を」を考えてテーブル名を出す
- 各テーブルのカラムを出す
- 残ってる、表現できていない情報があれば、テーブルになるか、カラムに追加するかを考える
- 関連を入れる
- 制約とデフォルト値とINDEXを考える
ハンバーガーショップのレシート
ハンバーガーショップのレシートのテーブル設計を行う。題材は次のもの。
メインとなるテーブル名を出す（イベント系エンティティを洗い出す）
この紙の目的を考えると、『顧客が食べたいものを注文するもの』なので、メインとなるイベントは『注文』となる
「誰が・何が」、「誰を・何を」を考えてテーブル名を出す（リソース系エンティティを洗い出す）
『顧客』が『商品』を注文するので、リソース系エンティティを追加。
各テーブルのカラムを出す
レシートから見た目通りにカラムを設定していく。
表現できていない情報を、テーブルにするか、カラムに追加するかを考える
下記の項目がまだ表現できていない。
- セットの部分
- 預かり金
- 預かり方法
セット部分は、あるセットに対して複数の商品が割りつくと思うので、『セットメニュー』と『セット構成』エンティティを用意。預かり金はとりあえず『入金』エンティティを作ってそこに突っ込んでみる。
関連を入れる
関連を入れていく。具体的なデータ（マク○ナルドのメニューを想像しながら🤤）を考えながら関係や多重度を考えていく。外部参照キーも入れていく。
注文エンティティと注文リストエンティティを結びつければ良さそうなんだけど、注文リストエンティティへの関連がおかしい。『単価』属性がセット構成エンティティと商品エンティティに重複しているのが良くないと思うので、セットメニューをどうにかして商品に突っ込みたいが、、、、、、
ここでギブアップしました😅というわけで回答を見てみる。
参考：解答例
イベント（出来事系）系の抽出のポイントは、動詞と〇〇日と言っても成り立つかという点。そういう意味で、注文・入金はいずれも条件を満たすため、イベント系エンティティと言える。
ただ、入金については、レシート上の事実としては、『お金を預かる』という内容なので、より正確には下記のようなエンティティが適当。
分析のためには、それぞれで考える方がわかりやすいため、まずは注文エンティティから。
理解に苦しだ、複数商品を１度にまとめて注文するようなものは、『まとめ部分と個別内訳部分』に分けて考えるとよくて、見出し明細形式やマスターディテール形式と呼ばれるらしい。
次は、リソースを抜き出す（誰が、何を）。今回の例だと、『誰が』という部分は意味持たないと思っていたけど、そういう場合は抽出不要らしい。データベースは事実を記録するので、意味を持たない部分は記録不要みたいな感じか🤔よって、『何を』を考えると、商品エンティティが出てくる。
商品エンティティもセットメニューのようなものがあるので、見出し明細形式として考えられそうだが、セット商品と単品商品を同時に頼むこともあるので、セット商品も単品商品として捉えて次のようなエンティティにする。
また、セット商品も単品商品の組み合わせなので、複数の商品の組み合わせに対して単品としてエンティティを構成しないといけない。つまり、セットメニューに付与された商品ID（複数商品用）と、そのセットを構成する商品ID（単品用）を一緒に扱わなければならないので、商品ID属性を2つ持つ必要がある。
次にレシートを見ると、『POS#』と『EatIn』の文言があり、今まで出てきたエンティティの属性には、はまらないので、それぞれエンティティ化する。
だいたいエンティティと大枠ができたら、属性を追加していく。まずは、わかりやすい注文テーブルから。
次に商品テーブル。商品テーブルには当該商品がセットかどうかを見分ける区分を追加しておく。
残ったやつには、当該テーブルを示す要素を追加する。
次に、『お金を預かる』部分を考える。注文エンティティに入れてしまうというパターンもあるようだが、参考書では入れずに別のイベントとして捉えている。
最後に、それぞれの関係と多重度を考えて、結びつけていく。
自分もセット構成までたどり着けたのはよかったが、自己参照（再帰）の部分を理解していなかったのでなかなか難しいと感じました。😅
