Day 3・書きかえる・設計する — INSERT/UPDATE/DELETEと表の設計

表の設計のはじめの一歩、そしてコースのまとめ

「1種類のデータ=1テーブル」で重複を避ける設計の初歩を学び、AI時代のSQLとの付き合い方でコースを締める。

表は「1種類のデータ = 1テーブル」で分ける

テーブル設計と聞くと難しそうですが、初歩の考え方はシンプルです。「1種類のデータは、1つの表にまとめる」。利用者の情報は users、注文の情報は orders、というように、種類ごとに表を分けます。そして、同じ情報を何度も書かない（重複させない）ようにします。

1つの表に全部詰め込む

注文の表に、注文のたびに利用者の氏名・住所も書く。同じ人が10回注文すれば、同じ住所が10回書かれ、引っ越しのとき10か所直すことになる。

種類ごとに表を分ける

利用者は users、注文は orders に分け、注文には user_id だけ持たせる。住所は users の1か所だけ。直すのも1か所で済む。

なぜ重複を避けるのかというと、重複したデータは「食い違い」の原因になるからです。同じ住所があちこちにコピーされていると、片方だけ直して片方が古いまま、ということが起きます。1か所にまとめておけば、そこを直せば全体が正しくなります。これが設計の一番大事な感覚です。

1種類のデータ = 1テーブル（利用者はusers、注文はorders）。
同じ情報を何度も書かない（重複を避ける）。
表と表は、主キー・外部キーでつなぐ。
設計の理由はいつも「後で直しやすく・食い違わないように」。

AIにはこう聞く

「こういうデータを管理したいのですが、どんなテーブルに分ければよいですか？重複を避ける観点で提案してください」と聞くと、設計のたたき台を出してくれます。出てきた案を、この章で学んだ「1種類=1テーブル」「重複を避ける」で読み解ければ十分です。

AI時代のSQLとの付き合い方 — このコースのまとめ

3日間おつかれさまでした。ここで大事なことをお伝えします。SQLは、全部を暗記して自分で書けるようになる必要はもうありません。文の骨組みはAIがどんどん書いてくれる時代です。では、あなたに求められるのは何でしょうか。

読める: AIが出したSQLを見て、「これは何を取り出す文か」がわかる。
意図を説明できる: 「この文は◯◯を集計したいから書いた」と日本語で言える。
危険に気づける: WHEREの無いDELETEなど、事故につながる操作を見て「これは危ない」と止められる。

なぜ「読める」だけで十分なのか

実務でトラブルになるのは、AIが書けないからではなく、人間が中身を確認せずに危険な文をそのまま実行してしまうときです。だから、書く力よりも「読んで・説明して・危険に気づく」力のほうが、今はずっと価値があります。あなたはもう、SELECTを読み、JOINのつなぎ目を理解し、DELETEの怖さを知っています。それで十分に戦えます。

最初は呪文のように見えた SQL が、今では「データと会話するための、やさしい言葉」に見えているはずです。わからない文に出会っても、もう大丈夫。AIに「この文は何をしていますか」と聞き、返ってきた説明を自分の言葉で確かめられます。ここまで来たあなたは、もうデータと対等に会話できます。よくがんばりました。ここがゴールであり、次のスタートです。

AIにはこう聞く

これから実務や学習でSQLに出会ったら、「この文を1行ずつ日本語で説明して、危険な点があれば教えてください」と聞くのを習慣にしましょう。読めて・説明できて・危険に気づける。この3つがあなたの武器です。

読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。

理解度チェック

答えられれば、面接で説明できる状態に一歩近づきます。

テーブル設計の初歩の考え方として、最も適切なものはどれですか？

AI時代に、SQL初心者が身につけると特に価値が高いのはどれですか？

このコースを終えた今、あなたは「SQLとどう付き合っていくか」を自分の言葉でまとめてください。

記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。