テーブル設計の流れ
テーブル設計の流れの概要にめちゃくちゃわかりやすくテーブル設計の手順が書かれていたので記載。これをベースに作業を進める。
- メインとなるテーブル名を出す
- 「誰が・何が」を考えてテーブル名を出す
- 「誰を・何を」を考えてテーブル名を出す
- 各テーブルのカラムを出す
- 残ってる、表現できていない情報があれば、テーブルになるか、カラムに追加するかを考える
- 関連を入れる
- 制約とデフォルト値とINDEXを考える
病院の領収書
病院の領収書のテーブル設計を行う。題材は次のもの。
メインとなるテーブル名を出す（イベント系エンティティを洗い出す）
この紙の目的を考えると、『病院が請求するもの』なので、メインとなるイベントは『請求』となる
「誰が・何が」、「誰を・何を」を考えてテーブル名を出す（リソース系エンティティを洗い出す）
『病院』が『費用』の請求をする。ただ、病院をデータとして記録する必要はないので、『費用』のみをリソース系エンティティに追加。また、費用は複数の請求内容から構成されているので、見出し明細形式にする。
各テーブルのカラムを出す
領収書から見た目通りにカラムを設定していく。
表現できていない情報を、テーブルにするか、カラムに追加するかを考える
下記の項目がまだ表現できていない。
- 請求者の情報（患者の情報）
- 保険区分、保険負担
- 請求内容
上記項目はそれぞれをエンティティとした方が、データのまとまりが綺麗と思ったので、それぞれエンティティ化する。また、請求内容は、ある程度分類科される気がしたので、請求分類エンティティも追加した。
関連を入れる
関連を入れていく。具体的なデータ（自分のデータがどのように管理されるかを想像しながら）を考えながら関係や多重度を考えていく。外部参照キーも入れていく。
また、費用エンティティがなくてもデータとして成立しそうなので削除する。
解答例を見てみる。
参考：解答例
今回の解答からの得たポイントは次の３つ。
見たままに属性を追加しきる
属性の追加忘れが結構あった😅その辺は見たままに全部追加という部分をもう少しきちっとやる必要があると思った。
データの扱いやすさを考慮した属性にする
請求期間については、解答例の方は開始日と終了日で分けて管理するようにしていた。データとして持つなら解答例のような形の方が扱いやすい（期間としてまとめてしまうと、データ処理するときに一度開始と終了に分割する処理が必要になる）と感じたので、今後はそういった属性追加をしていきたい。
事実とデータが一致するようなエンティティに適切な属性を持たせる
自分の考えだと、保険と金額を請求内容エンティティに入れていたが、解答例だと請求明細に入っていた。理由を少し考えてみた🤔請求内容エンティティに入れた場合、領収書発行後に請求内容の点数や金額を編集すると、発行した領収書のデータと、データベース内のデータに差異が出てしまうからだと思った。よって、あるエンティティ内で事実として動かない部分は、１つのエンティティ内に属性を持たせることが大事なんだと学んだ。
