テーブル設計の流れ
テーブル設計の流れの概要にめちゃくちゃわかりやすくテーブル設計の手順が書かれていたので記載。これをベースに作業を進める。
- メインとなるテーブル名を出す
- 「誰が・何が」を考えてテーブル名を出す
- 「誰を・何を」を考えてテーブル名を出す
- 各テーブルのカラムを出す
- 残ってる、表現できていない情報があれば、テーブルになるか、カラムに追加するかを考える
- 関連を入れる
- 制約とデフォルト値とINDEXを考える
病院の受付伝票
病院の受付伝票のテーブル設計を行う。題材は次のもの。
メインとなるテーブル名を出す（イベント系エンティティを洗い出す）
この紙の目的を考えると、『患者が診察の受付するもの』なので、メインとなるイベントは『受付』となる
「誰が・何が」、「誰を・何を」を考えてテーブル名を出す（リソース系エンティティを洗い出す）
『患者』が『治療』の受付をするので、リソース系エンティティを追加。
各テーブルのカラムを出す
受付表から見た目通りにカラムを設定していく。
表現できていない情報を、テーブルにするか、カラムに追加するかを考える
下記の項目がまだ表現できていない。
- 受診科(診療科目)
- 受診内容
- 医師名
上記項目はそれぞれをエンティティとした方が、データのまとまりが綺麗と思ったので、それぞれエンティティ化する。
関連を入れる
関連を入れていく。具体的なデータ（自分のデータがどのように管理されるかを想像しながら）を考えながら関係や多重度を考えていく。外部参照キーも入れていく。
また、治療エンティティがなくてもデータとして成立しそうなので、削除する。
これまでの演習に比べて１つのエンティティ（受付）の属性がいっぱいになってしまった😅。とりあえず解答例を見てみる。
参考：解答例
受付表の受診科の横の番号は、何かよくわからなかったので表現していなかったけど、どうやら複数の診察をまとめて受付可能という意味だった。よって、１つの受付に複数の診察を割り付ける必要があるので、見出し明細形式で表現する。見出し明細形式でテーブルを作るときは、すぐに関連する属性IDを付与する。
そのほかの考えは、だいたい同じだったが、受付日時の横の数字は、「端末番号」ということだったので、受付エンティティに入れる必要がある。また、各受診の時刻はそれぞれ異なるはずなので、時刻を受付明細エンティティに移動する。最終的なER図は次のようなものになる。
今回は、割とイメージ通りの構成であったため、そこまで突っかかることは無くてよかった💪といっても、ER図作るのに結構時間かかってますが😅
とりあえず見たままを表現ということで上記までの検討しかしていなかったが、参考書ではさらに改良したER図が紹介されていた。内容としては、組み合わせに対する制約の管理というもので、今回の例だと、『医師が担当できる科目』や『各受診科で対応する受診内容』には制約がある。それをエンティティとして表現しておくと、入力支援などで使えるらしい。それに対応したER図が次のもの。
