前回の続き——分けた表を、合わせる番
前回のL-06では、1つの表から必要な列と行を取り出すSELECTを学びました。ただ、実際の業務ではデータが複数の表に分かれています。L-02で見たとおり、同じ情報を繰り返さないために表を分けたからです。この講義は、その分けた表を「見るときに合わせる」JOINを扱います。設計の締めくくりに当たる回です。
このスライドのポイント
- L-06: 1つの表から必要な列・行を取り出すSELECTを学んだ
- 業務のデータは複数の表に分かれている（L-02の「同じ情報を繰り返さない」設計の結果）
- この講義の役割: 分けて保存した表を「見るときに合わせる」JOINを扱う
- リレーショナル設計の締めくくりに当たる回
JOINの定義——キーの対応で1つの結果にする
JOINとは、2つ以上の表を、キーの対応で結合して1つの結果にする操作です。どの列とどの列を対応させるかは、ONという句で指定します。L-02では情報を複数の表に分けました。L-04では、その表同士を主キーと外部キーで参照づけました。JOINは、その分けて参照づけた表を、取り出すときに合わせる手段です。これでリレーショナルデータベースの「分ける・参照する・合わせる」の3点セットが完成します。
このスライドのポイント
- JOIN＝2つ以上の表を、キーの対応で結合して1つの結果にする操作
- どの列とどの列を対応させるかはON句で指定する
- L-02で分けた表を、L-04の主キー・外部キーで参照づけ、取り出すときに合わせる手段がJOIN
- これで「分ける→参照する→合わせる」の3点セットが完成する
なぜ必要か——普通の一覧画面が読めるように
JOINを知らないと、「経費の一覧に申請者の名前を出す」という、ごく普通の画面のSQLが読めません。expensesの表には申請者の番号しか入っていないからです。名前はusersの表に1回だけ書いてあります。分けて保存した設計の意味は、こうして取り出すときに初めて完結します。JOINが読めないと、その腹落ちが得られないままになります。
このスライドのポイント
- JOINを知らないと「経費一覧に申請者名を出す」ごく普通の画面のSQLが読めない
- expensesの表には申請者の番号（user_id）しか入っていない
- 名前はusersの表に1回だけ書いてある
- 分けて保存した設計の意味は、取り出すときに初めて完結する
構造——参照の矢印が結合の線になる
構造を図で見てみましょう。expensesの表には、誰の経費かを指すuser_idという外部キーがあります。usersの表には、行を一意に識別する主キーのidがあります。JOINは、このuser_idとidが一致する行同士を線で結び、1枚の結果の表にまとめます。L-04で引いた参照の矢印が、そのまま結合の線になる、と考えるとつかみやすいです。
このスライドのポイント
- expensesの外部キー user_id と、usersの主キー id を対応させる
- 一致する行同士を結び、1枚の結果表にまとめる
- L-04で引いた参照の矢印が、そのまま結合の線になる
- 保存は2つの表のまま、結果だけが1つになる
処理の流れ——1本のSQLで画面の形に戻る
具体例は、申請者名付きの経費一覧画面です。この画面は、たった1本のSQLで作れます。expensesから日付と金額を取り、usersから名前を取り、user_idとidが一致する行を合わせる。L-02で分割した設計と、L-04で結んだキーが、ここで画面の形に戻ってきます。保存のときに分けたものを、表示のときに1つに合わせる。この流れが実感できるはずです。
このスライドのポイント
- 申請者名付きの経費一覧画面は、たった1本のSQLで作れる
- expensesから日付と金額を取り、usersから名前を取り、キーが一致する行を合わせる
- L-02の分割とL-04のキーが、ここで画面の形に戻る
- 保存のときに分けたものを、表示のときに1つに合わせる流れ
技術サンプル——JOINを1文で読む
サンプルを読んでみましょう。1行目のSELECTで、経費の日付と金額、そして利用者の名前を選んでいます。eとuは表につけた短い呼び名です。3行目のON、e.user_id と u.id を等しくする部分が結合の条件で、これはL-04で見たキーの対応そのものです。4行目のWHEREで1万円以上に絞り込んでいます。読み取り専用の文なので、L-06のSELECTと同じく、実行してもデータは変わりません。
混同しやすい概念——保存の形と表示の形
混同しやすいのは、「保存の形」と「表示の形」の違いです。データは、同じ情報を繰り返さないために複数の表へ分けて保存します。一方、画面に見せるときは、人が見やすいように1枚へ合わせます。保存の形と表示の形は別物で、その間を繋ぐのがJOINです。分けたまま保存しても、見るときに困らない。この安心が、リレーショナル設計の狙いでした。
バイブコーディングでの確認点——行数が増えていないか
バイブコーディングでの確認点です。一覧を表示するSQLをAIに作らせたら、「結合で行数が増えていないか」を確認してください。L-05で見た多対多の関係を跨いで結合すると、意図せず同じ行が重複し、件数や合計がおかしくなることがあります。AIへの質問例は、「このJOINはどのキーで結合していますか。結合で行数が増える可能性はありますか」です。件数が合わないときの定番の原因なので、覚えておいてください。
このスライドのポイント
- 一覧を表示するSQLをAIに作らせたら「結合で行数が増えていないか」を確認する
- L-05の多対多の関係を跨いで結合すると、同じ行が重複し件数・合計がおかしくなる
- 件数がおかしい集計の定番原因
- AIへの質問例: 「このJOINはどのキーで結合していますか。結合で行数が増える可能性はありますか」
まとめと一問一答
最後に一問一答です。分けて保存した表を、合わせて見る操作を何と呼ぶでしょうか。（間）答えはJOINです。30秒まとめです。JOINは、キーの対応をONで指定して複数の表を1つの結果に結合する操作でした。L-02の分割とL-04の参照が、ここで画面の形に合わさり、リレーショナル設計が一巡します。次回は、データを変える3つの文、INSERTとUPDATEとDELETEへ進みます。関連資料は「DBワード50」と「エラー解決プロンプト50」です。
このスライドのポイント
- 一問一答: 分けて保存した表を合わせて見る操作は？ → JOIN
- 30秒まとめ: JOINはキーの対応をONで指定し複数の表を1つの結果に結合する。L-02の分割とL-04の参照が画面の形に合わさり、リレーショナル設計が一巡する
- 次回: データを変える3つの文（INSERT・UPDATE・DELETE）へ
- 関連資料: 「DBワード50」「エラー解決プロンプト50」
