前回の続き——キーの「つなぎ方」には型がある
前回のL-04では、行を識別する主キーと、別の表を指す外部キーを学びました。キーは表と表をつなぐ道具でしたが、そのつなぎ方には型があります。この講義では、現実の関係を一対一・一対多・多対多の3パターンに分類し、それぞれをどんな表の形で表すかを決められるようになることを目指します。ここはデータ設計の骨組みを決める、重要な回です。
このスライドのポイント
- L-04で学んだこと: 行を識別する主キーと、別の表を指す外部キー
- キーは表と表をつなぐ道具。ただし、つなぎ方には型がある
- この講義の役割: 関係を3パターンに分類し、それぞれの表の形を決める
3つのパターンの定義
3つのパターンを順に見ます。一対多は、片方の1行に、もう片方の複数行が対応する関係です。1つの部署に社員が複数いる、が典型で、最もよく現れます。このとき外部キーは「多」の側、つまり社員の表に置きます。一対一は、1行に対して1行が対応する関係で、社員と社員詳細のような組み合わせです。多対多は、互いに複数が対応する関係で、社員と資格のように、1人が複数の資格を持ち、1つの資格を複数人が持ちます。多対多は表同士を直接つなげず、両方の外部キーを持つ中間テーブルを間に挟んで表現します。
このスライドのポイント
- 一対多: 片方の1行に、他方の複数行が対応（部署1つに社員が複数）。最頻出。外部キーは「多」の側に置く
- 一対一: 1行に1行が対応（社員と社員詳細）
- 多対多: 互いに複数が対応（社員と資格）
- 多対多は直接は表現できず、両方の外部キーを持つ中間テーブルを挟む
なぜ必要か——見分けられないと壊れた設計を見抜けない
この分類を持たないと、AIへ設計を頼むときに危険な形を見抜けません。たとえば「1つの経費に複数のタグを付けたい」という多対多の関係を頼むと、AIはtags列に「交通費,出張,7月」のようなカンマ区切りの文字列を詰め込む設計を返すことがあります。一見動きそうですが、これは壊れた設計です。特定のタグで検索することも、タグごとに集計することもできなくなります。関係の型を先に見分けられれば、この落とし穴を避けられます。
このスライドのポイント
- 分類を持たないと、AIが返す危険な設計を見抜けない
- 例: 「1つの経費に複数のタグを付けたい」（多対多）を頼む
- AIはtags列に「交通費,出張,7月」のようなカンマ区切り文字列を返すことがある
- これは壊れた設計。タグでの検索も、タグごとの集計もできなくなる
構造——両方向から個数を問って見分ける
3つのパターンを図で並べて見分けます。判別のコツは、関係を両方向から問うことです。「Aから見てBは何個か」「Bから見てAは何個か」を両方たずね、片方だけ複数なら一対多、両方とも複数なら多対多、どちらも1つなら一対一です。一対多では外部キーを多の側に1本置くだけで表せます。多対多だけは表を直接つなげないため、両方の外部キーを持つ中間テーブルという専用の表を1枚追加します。
このスライドのポイント
- 判別法: 関係を両方向から問う
- 「Aから見てBは何個か」「Bから見てAは何個か」
- 片方だけ複数=一対多／両方とも複数=多対多／どちらも1つ=一対一
- 一対多は外部キー1本／多対多だけは中間テーブルという専用の表を追加
処理の流れ——経費とタグは多対多
経費とタグの例で流れを追います。経費1件には複数のタグが付き、1つのタグは複数の経費に付きます。両方向とも複数なので、これは多対多です。そこで、経費の表とタグの表とは別に、expense_tagsという中間テーブルを用意し、そこにexpense_idとtag_idの組を1行ずつ保存します。こうすれば、あるタグが付いた経費も、ある経費に付いたタグも、どちらも正しく取り出せます。カンマ区切りの文字列では、この検索も集計も成り立ちません。
このスライドのポイント
- 経費1件に複数タグ、タグ1つは複数経費に付く=両方向とも複数=多対多
- 経費の表・タグの表とは別に、expense_tags中間テーブルを用意
- expense_idとtag_idの組を1行ずつ保存する
- カンマ区切り文字列では、検索も集計も成り立たない
技術サンプルカード——3パターンの構成図
サンプルは、3つのパターンをテーブルの形で示した構成図です。目的は、関係の言葉がそのまま表の構造に翻訳されることを確かめることです。一対多は部署と社員、一対一は社員と社員詳細、多対多は経費とタグを中間テーブルで結んだ形で並べています。読み方の要点は、「1つに複数」「互いに複数」という関係の言葉が、外部キーを置く場所や中間テーブルの有無を決めている点です。AIには「経費とタグの関係は3パターンのどれですか。この設計はそれを正しく表現していますか」と確認してみてください。
混同しやすい概念——カンマ区切り文字列 vs 中間テーブル
混同しやすいのは、多対多を1列のカンマ区切りで持つ設計と、中間テーブルで持つ設計です。前者はtags列に「出張,交通費」と文字列で詰め込む形で、AIも頻繁に出す代表的なアンチパターンです。後者は中間テーブルに組を1行ずつ保存する正しい形です。見た目は前者のほうが単純ですが、検索・集計・タグの付け外しのすべてが後者でしか安全に行えません。カンマ区切り文字列を見たら、多対多の見落としを疑ってください。
このスライドのポイント
- カンマ区切りで持つ設計（壊れた設計）: tags列に「出張,交通費」と文字列で詰め込む。AIも頻繁に出す代表的なアンチパターン
- 中間テーブルで持つ設計（正しい設計）: 組を1行ずつ保存する
- 見た目は前者が単純だが、検索・集計・タグの付け外しは後者でしか安全に行えない
- カンマ区切り文字列を見たら、多対多の見落としを疑う
バイブコーディングでの確認点
バイブコーディングでは、設計をAIに渡す前に、関係の個数を業務の言葉で確かめておきます。「AとBの関係は、Aから見て何個で、Bから見て何個ですか」を自分に問い、答えを言葉にしてからAIへ渡します。これはA-08で決めた保存データの設計を、より精密にする作業です。個数がはっきりすれば、AIの設計案が一対多なのに一対一になっていないか、多対多なのにカンマ区切りになっていないかを、その場で判定できます。
このスライドのポイント
- 設計をAIに渡す前に、関係の個数を業務の言葉で確かめる
- 問い: 「AとBの関係は、Aから見て何個で、Bから見て何個ですか」
- これはA-08で決めた保存データの設計を、より精密にする作業
- 個数がはっきりすれば、AIの設計案が型どおりかその場で判定できる
まとめと次回
最後に一問一答です。多対多の関係を表すために必要な表は何でしょうか。（間）答えは、中間テーブルです。両方の外部キーを持ち、組を1行ずつ保存する専用の表でした。30秒のまとめです。関係は、両方向から個数を問えば一対一・一対多・多対多に分類でき、多対多だけは中間テーブルが必要になります。カンマ区切り文字列は、多対多の壊れた設計のサインです。次回は、保存したデータを取り出すSQLへ進みます。関連資料は「業務アプリDB設計パターン50」「業務整理質問集100」です。
このスライドのポイント
- 一問一答:「多対多の関係を表すために必要な表は？」→ 中間テーブル（両方の外部キーを持つ）
- 30秒まとめ: 両方向から個数を問えば3パターンに分類できる。多対多だけは中間テーブルが必要
- カンマ区切り文字列は、多対多の壊れた設計のサイン
- 次回: 保存したデータを取り出すSQLへ
- 関連資料: 「業務アプリDB設計パターン50」「業務整理質問集100」
