前回との接続——DBMSの中身を開ける
L-01では、アプリはDBMSを通してしかデータに触れない、という構造を確認しました。ただし、そのDBMSの内側でデータがどんな形に整理されているかは、まだ開けていません。今回はその中身を開けます。参照スタックのPostgreSQLが採用しているのが、これから学ぶリレーショナルデータベースという方式です。この方式の考え方がわかると、AIに保存の設計を頼むときに、良い設計と危うい設計を自分で見分けられるようになります。
このスライドのポイント
- L-01: アプリはDBMSを通してしかデータに触れない
- ただしDBMSの内側でデータがどんな形に整理されているかは未確認
- 今回はその中身を開ける
- 参照スタックのPostgreSQLが採用しているのが「リレーショナル」という方式
リレーショナルデータベースとは
リレーショナルデータベースとは、データを複数の表に分けて保存し、その表どうしをキーで関係づけて情報を表す方式のデータベースです。表の正確な中身は次回のL-03で、キーの正体はL-04で扱います。今は、情報を1枚にまとめず、いくつかの表に分けて関係で結ぶ、という骨格だけをつかんでください。PostgreSQLは、この方式を採用したDBMSです。そして、この方式の核心はひとつです。同じ情報を2箇所に書かない。1箇所だけに置いて、他からはそれを参照する。これが最初から最後まで貫く原則です。
このスライドのポイント
- リレーショナルデータベース＝データを複数の表に分けて保存し、表どうしをキーで関係づけて表す方式のデータベース
- 「表」の正確な中身は次回L-03、「キー」の正体はL-04で扱う
- PostgreSQLはこの方式を採用したDBMS
- 核心: 同じ情報を2箇所に書かない（1箇所に置いて、他からは参照する）
なぜ必要か——1枚の巨大な表の落とし穴
この考え方を知らないと、Excelの1枚のシートに全部書き込む発想のまま、DBの設計をAIに指示してしまいます。たとえば経費が1万件あるとして、1枚の表にそのつど社員名まで書き込むと、同じ社員の名前が何千回も繰り返し現れます。その社員が結婚して名字が変わったら、その名前が書かれた全ての行を直さなければなりません。1件の変更のために、何千行もの修正が必要になる。これは事故のもとです。同じ情報が散らばっているほど、変更に弱く、食い違いも生まれやすくなります。
このスライドのポイント
- 知らないと: Excelの1枚のシートに全部書く発想のままDB設計をAIに指示してしまう
- 例: 経費1万件の表に、そのつど社員名まで書き込む→同じ名前が何千回も繰り返し現れる
- その社員が改名すると、名前が書かれた全行を修正する必要がある
- 同じ情報が散らばるほど、変更に弱く、食い違いも生まれやすい
構造——1枚にまとめる vs 分けて結ぶ
では、どう分ければよいのか。悪い例は、1枚の巨大な表に社員名も経費も全部詰め込んだ形です。ここでは社員名が何度も繰り返し現れます。良い例は、社員を管理する表と、経費を管理する表の2つに分ける形です。社員の名前は社員の表に一度だけ書きます。経費の表は、それが誰の経費かを名前ではなく番号で指し示します。図では、経費の表から社員の表へ矢印が伸びます。この矢印が、次回以降くわしく学ぶ関係の正体です。
このスライドのポイント
- 悪い例: 1枚の巨大な表に社員名も経費も全部詰め込む→社員名が繰り返し出現
- 良い例: 社員の表と経費の表の2つに分ける
- 社員名は社員の表に一度だけ書く／経費の表は「誰か」を番号で参照
- 経費の表から社員の表へ矢印（＝次回以降くわしく学ぶ「関係」）
処理の流れ——名前は1回だけ書く
もう少し具体的に見ます。経費の一覧画面に、申請した社員の名前を表示したいとします。このとき、名前は社員の表に1回だけ書いておきます。経費の表には、名前ではなく社員の番号だけを持たせます。表示のときに、その番号をたどって名前を取り出します。こうしておけば、社員が改名しても、直すのは社員の表のたった1行だけです。経費が何万件あっても、経費の表には一切手を触れずに済みます。1箇所を直せば全体に反映される。これが、分けて参照することの実利です。
このスライドのポイント
- 例: 経費一覧画面に、申請した社員の名前を表示したい
- 名前は社員の表に1回だけ書く／経費の表には社員の番号だけを持たせる
- 表示のとき、その番号をたどって名前を取り出す
- 改名しても直すのは社員の表の1行だけ。経費が何万件あっても経費の表は無修正
技術サンプルカード——分割前後の対比
スライドのサンプルを見てください。種別は構成図です。目的は、1枚にまとめた設計と、表を分けた設計の違いを見比べることです。分ける前は、経費の1行ごとに社員名が繰り返し入っています。分けた後は、社員の表に名前が1回、経費の表には社員を指す番号だけが入ります。読み方のこつは、同じ値が何度も繰り返し現れていたら、それは別の表に出すべきという合図だと考えることです。AIには、このデータ設計で同じ情報が複数の場所に書かれる箇所はありませんか、と聞いてみてください。
混同しやすい概念——表計算のシート vs リレーショナルの表
ここで、混同しやすい点を整理します。表計算ソフトのシートと、リレーショナルの表は、見た目はどちらも縦横のマス目でよく似ています。しかし設計の思想は正反対です。表計算のシートは、人間が一目で全体を見渡せるように、1枚にできるだけ情報を集めます。リレーショナルの表は逆で、情報をあえて複数の表に分け、必要なときに関係でつなぎ直します。見た目が似ているせいで、シートの感覚のままDBを設計すると危うい。ここは意識して切り替えてください。
バイブコーディングでの確認点
AIにDBの設計を作らせたら、繰り返し保存されている値はないか、を必ず確認してください。同じ社員名や同じ部署名が何度も出てくる設計だったら、表を分けられないかを相談する合図です。これは、E-09で予告したデータ構造の相談の、いよいよ本番にあたります。設計の段階でこの一手間をかけておくと、あとから直す苦労を大きく減らせます。質問例としては、この設計で繰り返し保存される値はどれですか、それは別の表に分けたほうがよいですか、と聞くとよいでしょう。
このスライドのポイント
- AIにDB設計を作らせたら「繰り返し保存されている値はないか」を必ず確認
- 同じ社員名・同じ部署名が何度も出てくる設計は、表を分けられないかを相談する合図
- これはE-09で予告した「データ構造の相談」の本番
- 設計段階のこの一手間が、あとから直す苦労を大きく減らす
まとめと一問一答
最後に一問一答です。同じ情報を2箇所に書かないための手段は何でしょうか。（間）答えは、表を分けて、キーで参照することです。30秒でまとめます。リレーショナルデータベースは、データを複数の表に分け、表どうしを関係でつないで表す方式です。核心は、同じ情報を1箇所だけに置き、他からは参照すること。次回のL-03では、その表そのものを解剖して、テーブル・行・列・型という部品を見ていきます。関連資料は、AI Builder Libraryの「業務アプリDB設計パターン50」と「DB設計プロンプト50」です。
このスライドのポイント
- 一問一答:「同じ情報を2箇所に書かないための手段は？」→ 表を分けてキーで参照する
- 30秒まとめ: リレーショナルデータベース＝データを複数の表に分け、関係でつないで表す方式。核心は「1箇所に置いて参照する」
- 次回L-03: 表そのものを解剖する（テーブル・行・列・型）
- 関連資料: 「業務アプリDB設計パターン50」「DB設計プロンプト50」
