ER図の作成

• 日程: Day 7 / セッション 3
• 時間: [11:10-12:40]
• 形式: 実習
• ゴール: テーブル間のリレーション（1対多・多対多等）を明示したER図を時間内に作成できる
• 学習形式: ハンズオン実習（AIサポートあり）

テーブル定義書ができました。
しかし、定義書は1テーブルずつバラバラの紙です。

ここで考えてみてください。
「予約テーブルの member_id 列は会員テーブルを指している」——この関係、定義書のどこを見ればわかるでしょうか？
制約の欄を1枚ずつ読めばわかりますが、全体像は頭に入ってきません。

そこでER図（Entity Relationship Diagram）です。
テーブル（エンティティ）同士の関係（リレーション）を1枚の地図にします。
地下鉄の路線図のようなものです。駅（テーブル）の時刻表（定義書）を全部読むより、路線図を1枚見る方が乗り換え（結合）はすぐわかります。

テーブル間の関係は3パターンに整理できます。

• 1対1: 会員と会員詳細プロフィール。片方の1行に、もう片方の1行だけが対応
• 1対多: 会員と予約。1人の会員は多くの予約を持つが、1つの予約の持ち主は1人
• 多対多: 学生と授業。1人の学生は複数の授業を取り、1つの授業には複数の学生がいる

このうち多対多は、リレーショナルデータベースでは直接表現できません。
中間テーブル（連関エンティティ）を間に置いて、1対多を2つに分解します。
「学生」と「授業」の間に「履修」テーブルを置く、という具合です。

MermaidのerDiagram記法で書くと、こうなります。

記号の読み方:

• || は「ちょうど1」、o{ は「0以上の多」
• ||--o{ で「1対多（0件もあり）」
• 線の鳥の足のような側が「多」。だからこの記法は「鳥の足記法（Crow's Foot）」と呼ばれます

前セッションの注文票の例なら、こうなります。

注文明細が、注文と商品の多対多を解決する中間テーブルになっていることに注目してください。
正規化で自然に生まれたテーブルが、ER図では関係の要になります。

• リレーションを見つける手がかりは外部キー。「FKのある所に線あり」
• 多対多を見つけたら中間テーブルで1対多×2に分解する。これが今日一番の山場
• 「多」側の見積もりを口に出して確認する。「1人の会員は予約をいくつ持てる？」「1つの予約に会員は何人？」の2方向から問う
• ER図とテーブル定義書は必ず一致させる。図にあるのに定義書にないテーブル（またはその逆）は設計漏れ

ER図は1976年、台湾出身の計算機科学者ピーター・チェンが提案しました。
チェンの論文は、データベース分野で最も引用された論文の1つです。
彼は「漢字が物事を絵で表すように、データも図で表せるはずだ」と考えたと語っています。
ちなみに「鳥の足記法」の足マークは、本当にニワトリの足跡が由来。
世界中の設計書がニワトリの足跡だらけだと思うと、少し和みませんか。

実習前に疑問を解消しておきましょう。たとえば：

• 「1対1の関係って本当に必要？テーブルを1つにまとめてはだめ？」
• 「自チームの○○と△△は多対多だと思うけど、中間テーブルの名前はどうつけるのが普通？」
• 「MermaidのerDiagramで『0か1』はどう書くの？」

テーブル定義書をもとに、自チームの全テーブルを含むER図を作成してください。

1. テーブル定義書から全テーブルを書き出し、外部キーを手がかりに関係線を引く
2. 各関係について「1対1 / 1対多 / 多対多」を判定する。判定時は両方向から問う（AはBをいくつ持つ？BはAをいくつ持つ？）
3. 多対多が見つかったら中間テーブルを設計し、テーブル定義書にも追加する
4. MermaidのerDiagram（または使い慣れた作図ツール）でER図を清書する
5. ER図とテーブル定義書の整合性を相互チェックする

   • 図にあるテーブルはすべて定義書にあるか
   • 定義書の外部キーはすべて図の線になっているか
6. 完成したER図をAIに見せて「不自然な関係や欠けている関係はないか」をレビューしてもらう

• ER図（全テーブル・全リレーション・多重度を明示）
• 更新済みテーブル定義書（中間テーブルを追加した場合）

• どこから線を引くか迷ったら: 外部キー（FK）列を全テーブルから書き出すと、線の一覧がそのまま得られます
• 多重度に迷ったら: 具体的なデータを2〜3行書いて「この行はあちらの何行と結びつく？」と数えてみましょう
• 中間テーブルの名前: 「会員_イベント」のような連結名より、「参加」「申込」のような関係そのものの名前が読みやすいです
• MermaidのerDiagramでエラーが出たら: エラーメッセージとコードをそのままAIに貼り付けると直し方を教えてもらえます
• 関係線が交差して読みにくいときは: テーブルの配置を変える、中心になるテーブル（一番線が多いもの）を真ん中に置く
• 時間配分: 関係の洗い出し15分、多対多の解決10分、清書15分、整合性チェックとAIレビュー10分が目安

今回学んだことを一言でまとめると「ER図はテーブル同士の関係を1枚で見渡す地図であり、多対多は中間テーブルで解決する」です。

• リレーションは1対1・1対多・多対多の3パターン
• 多対多は中間テーブルで1対多×2に分解
• ER図とテーブル定義書の整合性チェックで設計漏れを潰す

これでDay 7の成果物（テーブル定義書・ER図）が揃いました。
次回（Day 8）は、このテーブルたちを「どの機能が読み書きするのか」をCRUD図で見える化し、機能設計に進みます。

以下の問いに答えられるか確認してみましょう：

• 1対多と多対多の例を、自チームのテーブルでそれぞれ挙げられますか？
• 多対多をそのまま実装できない理由と、解決方法を説明できますか？
• 自チームのER図で一番線が集まっているテーブルはどれですか？それはなぜですか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: Mermaid公式ドキュメントの「Entity Relationship Diagrams」のページ
• 発展課題: 自チームのER図を見ながら「会員Aの予約一覧を表示するにはどのテーブルをどの順にたどる？」をAIと一緒に考えてみましょう。SQLのJOINの予習になります

このセクションは、受講者が理解を深めることをサポートする参考情報です。