浅間上昇AI Academy

SPECIAL CONTENTS ／ BASICS

AI時代のデータベース入門
基礎編：表の設計と、SQLのきほん

AIがコードを書く時代でも、「どんな表に、何を、どうつないで持つか」を決めるのは人の仕事です。業務アプリの品質を左右する、表の設計とSQLの基本を押さえます。

01 主キーと外部キー

1件を見分ける「番号」と、表どうしをつなぐ「参照」

主キーは、その表の中で1件を必ず見分けられる番号です。名前は同姓同名がありえるので、キーにしません。外部キーは、別の表の主キーを指す列で、表どうしをつなぎます。

講師（架空のデータ）
🔑 講師番号氏名雇用区分
10高原 先生アルバイト
11浅間 先生正社員
コマ毎週の授業枠（架空）
🔑 コマ番号曜日開始🔗 講師番号🔗 生徒番号
501月17:00101
502水19:00113

🔑 主キー🔗 外部キー（別の表を指す）

「コマ501の講師は誰？」は、講師番号10を講師の表で引けば分かります。講師の名前を直しても、コマの表は直さなくて済みます。

02 つながり方

1対多と、多対多

表どうしのつながり方は、ほとんどがこの2つです。

生徒1多欠席
1対多：1人の生徒に、欠席が何件もある。欠席の表に「生徒番号」を持たせる。
生徒多参加（中間の表）多イベント
多対多：1人が複数のイベントに参加し、1つのイベントに複数人が参加する。「参加」という中間の表でつなぐ。

03 正規化

同じ情報を、2回書かない

Excelでありがちなのが、1行に何でも書いてしまう形です。保護者の電話番号が変わると、何行も直す必要があり、直し漏れが起きます。

よくあるExcelの形同じ保護者情報が何度も出てくる
日付生徒保護者保護者電話内容
5/1浅間 一郎浅間 父090-0000-0001欠席
5/8浅間 一郎浅間 父090-0000-0001振替
5/15浅間 一郎浅間 父090-0000-0001欠席
生徒
🔑 生徒番号氏名保護者電話
1浅間 一郎090-0000-0001
出来事
日付🔗 生徒番号内容
5/11欠席
5/81振替
5/151欠席

電話番号が変わっても、直すのは1か所だけ

これを「正規化」と呼びます。浅間上昇AIのアプリ開発でも「同じ情報を、2回入力しない」を大切な設計原則にしています。

04 SQL

データベースに話しかける言葉、SQL

SQLは1970年代に生まれ、1986年に標準規格になりました。基本の書き方は40年近くほとんど変わっていません。

  • SELECT

    意味
    取り出す
    例
    中学2年の生徒を一覧する

  • INSERT

    意味
    追加する
    例
    新しい欠席を登録する

  • UPDATE

    意味
    直す
    例
    振替の状態を「確定」にする

  • DELETE

    意味
    消す
    例
    誤って登録した行を消す（業務では慎重に）

  • JOIN

    意味
    表をつなぐ
    例
    コマと講師をつないで、講師名つきの時間割にする
例：月曜のコマを、講師名つきで取り出す
SELECT コマ.開始, 講師.氏名
FROM コマ
JOIN 講師 ON 講師.講師番号 = コマ.講師番号
WHERE コマ.曜日 = '月'
ORDER BY コマ.開始;

40年の間に増えた、業務で役立つ機能

  • WITH（共通表式）

    できること
    長い集計を、名前を付けた途中の表で段階的に書ける

  • ウィンドウ関数

    できること
    行をまとめずに、累計・順位・前月比を出せる（借入残高の推移など）

  • JSON

    できること
    形の決まっていない情報も、表の中に保存・検索できる

  • UPSERT

    できること
    「なければ追加、あれば更新」を1回で書ける（Excelの再取込など）

データベースごとの方言（AccessとPostgreSQL）

  • あいまい検索の記号

    Access
    * と ?
    PostgreSQL
    % と _

  • 日付の書き方

    Access
    #2026/10/03#
    PostgreSQL
    '2026-10-03'

  • 条件で値を変える

    Access
    IIf(条件, A, B)
    PostgreSQL
    CASE WHEN 条件 THEN A ELSE B END

  • 上位○件

    Access
    SELECT TOP 10 …
    PostgreSQL
    SELECT … LIMIT 10

  • 文字をつなげる

    Access
    &
    PostgreSQL
    ||

05 トランザクション

「全部成功」か「全部なかったことに」

業務の1つの操作は、裏では複数の表への書き込みになります。途中で止まると、データが食い違ってしまいます。

  1. 欠席を登録

    欠席の表に1行

  2. 振替先を確保

    振替予定の表に1行

  3. 欠席の状態を更新

    「振替予約済み」へ

3つまとめて1つの「取引」にする

2つ目で失敗したら、1つ目もなかったことにします。「欠席は登録されたのに振替がない」という中途半端な状態を作りません。

06 制約

間違ったデータを、そもそも入れさせない

  • NOT NULL（必須）

    守ること
    空欄を許さない
    業務の例
    欠席には必ず日付がある

  • UNIQUE（重複禁止）

    守ること
    同じ値を2つ持たせない
    業務の例
    同じログインIDは1人だけ

  • CHECK（範囲）

    守ること
    あり得ない値を拒む
    業務の例
    金額はマイナスにならない／終了日は開始日より後

  • 外部キー

    守ること
    存在しない相手を指させない
    業務の例
    いない生徒の欠席は登録できない
画面のチェックは「入れる前の案内」、データベースの制約は「最後の砦」です。両方あると、AIが書いたプログラムに見落としがあっても、壊れたデータが残りにくくなります。

07 ステータス

業務の「いまどこ？」を、状態として持つ

業務は1回の入力で終わらず、段階を進みます。今どの段階かを1つの列で持つと、一覧や抜け漏れのチェックが簡単になります。

  1. 未対応
  2. 依頼あり
  3. 確定
  4. 実施済み

例：欠席の振替。ほかに「振替なし」で閉じる道もある。決められた順番でしか進めないようにすると、飛ばしや逆戻りを防げる。

あわせて決めておきたいこと

  • 金額

    おすすめ
    整数の「円」で持つ。小数にすると、合計で1円ずれることがある

  • 日時

    おすすめ
    いつ作ったか・いつ直したかを全部の表に残す

  • 削除

    おすすめ
    業務データは消さずに「無効」にする（論理削除）。過去の記録との矛盾を防ぐ

  • 確定後

    おすすめ
    締めた月の内容は書き換えず、訂正は記録を追加する

08 マイグレーション

表の形を変えるときは、段階を踏む

列を足す、表を作るといった「表の形の変更」をマイグレーションと呼びます。本番では取り消しが難しいので、環境を分けて進めます。

  1. 開発

    ダミーデータで試す

  2. 確認（Staging）

    本番のコピーで人が確かめる

  3. 本番（Production）

    承認されたものだけ

Neonなら、本番のコピー（ブランチ）をすぐに作れるので、確認用の環境を用意しやすくなります。

09 AI時代のレビュー

AIが書いたSQLを、人が確かめる観点

今はSQLの多くをAIが書きます。だからこそ、読んで確かめる力の価値が上がっています。

  • 集計の条件は、業務の意味と合っているか
  • 他の会社・他の人のデータまで取り出していないか
  • 消す・直す命令に、対象を絞る条件が付いているか
  • 複数の書き込みが、1つの取引にまとまっているか
  • 金額が整数のまま計算されているか
  • 本番で表の形を変える内容が含まれていないか

← 前の編

入門編：データベースって、そもそも何？

次の編 →

発展編：塾の基幹システムで学ぶ、業務アプリの設計

自社のデータを、
どう持つべきか一緒に整理します。

Excelのままでよいのか、既存のサービスで十分か、小さな専用アプリにするべきか。業務の聞き取りから一緒に考えます。ご相談は無料です。

30分の個別相談・適合診断AI時代の業務アプリ開発を見る