SQLは、答えだけではわからない。
SQLを実行すれば、答えは返ってきます。
売上はいくらだったのか。
どの施策の成果が高かったのか。
何人の顧客が継続しているのか。
どこで利用者が離脱しているのか。
しかし、表示された数字だけを見ても、その数字が正しい理由までは分かりません。
どのデータが集計に含まれたのか。
どの条件によって除外されたのか。
テーブルの結合によって重複していないか。
計算の単位は、確認したい指標と一致しているか。
SQLは答えを返してくれます。
その答えがどのように作られたのかを理解するには、結果だけでなく、そこへ至る途中を見る必要があります。
いまや、データは一部の専門職だけが扱うものではありません。
企業活動のIT化とデータ化が進み、エンジニアやデータアナリストだけでなく、マーケター、企画、営業、業務改善を担う人も、日常的にデータを根拠とした判断を求められるようになりました。
その多くを、見えないところで支えているのがSQLです。
SQL Quiz Bookは、SQLの処理過程を、クエリとテーブルの変化の対応から理解するための問題集です。
SQLの難しい点とは？
SQLで得られた結果は、さまざまな意思決定に使われます。
経営指標を確認する。
施策の成果を評価する。
顧客の行動を分析する。
次に取るべき行動を決める。
最終的に表示されるのは、表やグラフ、あるいは一つの数値かもしれません。
しかし、その数字がどのように作られたのかは、完成した結果を見るだけでは分かりません。
SQLは、処理の細かな手順ではなく、欲しい結果を宣言するための言語です。
これはSQLの大きな強みです。
利用者は、データをどの順番で読み、どの方法で処理するかを、すべて手続きとして記述する必要がありません。必要な結果をクエリとして表現すれば、具体的な実行方法の多くはデータベースが判断します。
一方で、この性質は処理の途中を見えにくくします。
SQLを書く順番と、データが論理的に処理される順番も一致しません。
そのためSQLを理解するには、書かれたクエリを眺めるだけではなく、
「今、何行あるのか」
「どの列が存在しているのか」
「どの行とどの行が対応したのか」
「この条件によって、何が残り、何が消えたのか」
を追跡する必要があります。
SQLの難しさは、構文の多さだけにあるのではありません。
最終的な数字へ至るまでに、データがどのように形を変えたのかが見えにくいことにあります。
一人の顧客は、どこへ消えたのか
簡単な例を考えてみます。
usersには、AliceとBobの2人が登録されています。
ordersには、Aliceの支払い済み注文だけが登録されています。
すべてのユーザーと、その支払い済み注文を取得するつもりで、次のSQLを書いたとします。
SELECT
users.name,
orders.id
FROM users
LEFT JOIN orders
ON users.id = orders.user_id
WHERE orders.status = 'paid';
このクエリを実行すると、Aliceは表示されますが、Bobは表示されません。
LEFT JOINを使ったのだから、注文のないBobも残るはずだと考えたくなります。
実際、LEFT JOINの直後までは残っています。
その時点のテーブルは、概念的には次の状態です。
| name | order_id | status |
|---|---|---|
| Alice | 101 | paid |
| Bob | NULL | NULL |
ところが、その後にWHERE句が評価されます。
Bobの行では、orders.status = 'paid'の評価結果はTRUEではありません。NULLを含む比較はUNKNOWNとなるため、WHERE句を通過できず、Bobの行は取り除かれます。
最終結果だけを見れば、Bobがいないことは分かります。
エラーを直すだけなら、条件をON句へ移動すればよいと覚えることもできます。
しかし、実務で重要なのは修正方法だけではありません。
LEFT JOINによってBobの行がNULLで補完されたこと。
その行がWHERE句へ渡されたこと。
NULLとの比較がTRUEにならなかったこと。
その結果として、Bobの行が除外されたこと。
この一連の変化を理解していれば、条件やデータが変わっても、同じ原理から判断できます。
そして、この違いは単なるSQLの知識問題ではありません。
「すべての顧客」を対象にしたつもりの分析から、購入実績のない顧客が除外されれば、継続率、転換率、顧客構成などの指標も変わります。
一つの条件が、最終的なビジネス判断にまで影響します。
SQLの正解は、最終的なテーブルとして現れます。
SQLの理解は、そこへ至る変化の中にあります。
入力と出力の間にあるもの
一般的なSQL教材では、次のものが示されます。
入力となるテーブル。
完成したクエリ。
実行後の結果。
これはSQLを学ぶために必要な情報です。
しかし、入力から出力へ至る途中で、行や列がどのように変化したのかは見えないことがあります。
どのデータが読み込まれたのか。
どの行とどの行が結び付いたのか。
どの条件によって、何が除外されたのか。
複数の行が、どの単位へまとめられたのか。
元のデータから、どのように新しい指標が計算されたのか。
SQLの処理は、入力テーブルから結果テーブルへの一度のジャンプではありません。
論理的には、小さなテーブル変化の連続です。
もちろん、実際のデータベースが、学習用に示した中間テーブルをそのまま物理的に生成するわけではありません。
データベースはクエリを最適化し、処理順序を変更し、不要な計算を省略します。
それでも、SQLが意味する処理を理解するためには、各句に対応するテーブルの変化を追うことが、強力な思考モデルになります。
多くの教材に欠けているのは、正しい答えではありません。
答えに至るまでの状態変化です。
SQLを実行すること
ブラウザ上でSQLを書き、その場で実行できる学習サービスは数多く存在します。
クエリを書き、実行し、エラーを読み、修正する。
これはSQLを身につけるうえで非常に有効です。実際に手を動かす反復練習を、読むだけの教材で置き換えることはできません。
しかし、実行結果だけでは分からないこともあります。
正解したとしても、なぜ正解したのかは保証されません。
不正解だったとしても、どの段階で想定とずれたのかは分かりません。
とりあえずJOINを追加する。
とりあえずDISTINCTで重複を消す。
とりあえずサブクエリで囲む。
試行錯誤を続ければ、期待する結果へ到達できるかもしれません。
しかし、データの量や偏り、NULLの有無、テーブル間の関係が変わったとき、そのSQLが同じように正しく動くとは限りません。
構文を覚えることは必要です。
実際にSQLを書くことも必要です。
個別のテーマを深く掘り下げることも必要です。
SQL Quiz Bookは、それらを置き換えようとしているわけではありません。
不足している一つの段階を補おうとしています。
実行する前に、何が起こるかを予測する。
実行した後に、なぜそうなったのかを説明する。
そのために、SQLの「途中」を読める形にします。
SQL Quiz Book
SQL Quiz Bookの設計は単純です。
すべての問題で、SQLによるテーブルの変化を段階的に可視化します。
各問題は、前提知識、問題文、使用テーブル、期待出力、模範解答、解説という順番で進みます。
最初に入力テーブルと期待出力を見比べ、必要な処理を考えます。
模範解答を開くと、クエリの各段階に対応するテーブルの変化を確認できます。
FROMで、どのデータを読み込んだのか。
JOINで、どの行とどの行が対応したのか。
WHEREで、何が残り、何が除外されたのか。
GROUP BYで、どの行が同じグループへまとめられたのか。
SELECTで、どの列が最終結果として取り出されたのか。
目指したのは、模範解答を見て「なるほど」と感じるだけの解説ではありません。
自分の予想と実際の変化が、どこで食い違ったのかを特定できる解説です。
実行環境を必須にしない
SQL Quiz Bookは、読むことを中心に設計しています。
データベースを準備しなくても、問題とテーブルを読み、クエリによってデータが変化する過程を追えます。
SQLを専門とするエンジニアだけでなく、分析結果を利用するビジネス職にとっても、学習を始めやすい形を目指しました。
すべての人が、データベースの専門家になる必要はありません。
しかし、データに基づいて判断するのであれば、その数字がどのような条件と処理によって作られたのかを理解する力は重要になります。
これは、実行環境が不要だから優れているという意味ではありません。
インタラクティブな演習、実際に手を動かす反復練習、個別テーマの深掘りには、すでに多くの優れた教材や実行環境があります。
SQL Quiz Bookだけで、SQL学習のすべてを完結させることは目指していません。
読むことで処理の構造を理解する。
実行環境で試し、自分の手で確かめる。
必要に応じて専門的な教材で深く学ぶ。
それぞれは競合するものではなく、異なる学習段階を担っています。
SQL Quiz Bookは、SQLの処理を理解し、実践へ進むための土台を作る補完的な教材です。
SQLは、さまざまな仕事の中にある
実務のSQLは、JOINだけ、GROUP BYだけという形では現れません。
マーケターが、広告接触から購入までの転換率を調べる。
企画担当者が、商品別の売上と継続率を比較する。
営業担当者が、顧客の利用状況から支援すべき対象を探す。
業務改善担当者が、処理時間やエラーの増加を検知する。
データアナリストが、複数のデータを組み合わせて意思決定の材料を作る。
エンジニアが、それらを正確かつ継続的に提供できる仕組みを構築する。
扱うテーマは違っても、その背後ではデータの抽出、結合、集約、変換が行われています。
現代のビジネスでは、システムと業務、技術と意思決定を完全に切り離すことが難しくなっています。
すべてのビジネス職が複雑なSQLを自在に書く必要はありません。
一方で、データから得られた結果を使う人が、その処理の基本的な意味を理解できれば、エンジニアやアナリストとの会話も、指標の検証も、意思決定も変わります。
SQL Quiz Bookでは、JOINやGROUP BYなどの基本構文だけでなく、バッチ処理、行動分析、KPI分析、異常検知、イベントモデリング、統計分析、パフォーマンス最適化などを扱っています。
現在公開しているのは、19テーマ、98セット、490問です。
しかし、この490問を完成形とは考えていません。
どのテーマが分かりにくかったのか。
実務でどのようなSQLに困っているのか。
次にどの分野を学びたいのか。
ユーザーの皆様から寄せられる反応や要望をもとに、テーマ、セット、問題をこれからも継続的に追加していきます。迅速な対応、高品質に。
それぞれのテーマは、基礎と応用に分かれています。
最初から決められた順番ですべてを進める必要はありません。JOIN、NULL、ウィンドウ関数、KPI分析など、自分の業務や課題に関係するテーマを選び、現在の理解度に合ったレベルから学べます。
すでに知っている分野を飛ばし、必要なテーマへ直接進む。
基礎を確認してから、同じテーマの応用へ進む。
実務で分からない言葉に出会ったとき、そのテーマだけを読み直す。
個別テーマを学習単位とすることで、学ぶ範囲を広げすぎず、必要な知識を効率よく補える構成にしています。
問題文、SQL関数名、技術キーワードから検索し、必要な問題へ直接戻ることもできます。学習の進捗を記録し、理解が曖昧だった問題へ復習マークを付けることもできます。
問題を一度解いて終わるのではなく、必要な知識を必要なときに読み直せる問題集を目指しました。
LLMがSQLを書く時代
LLMは、すでに多くのSQLを生成できます。
テーブル定義と目的を伝えれば、SQLに不慣れな人でも、データを抽出するためのクエリを短時間で得られるようになりました。
これは、データを扱える人の範囲を大きく広げる変化です。
これから、人間がSQLを一から書く機会の一部は減っていくでしょう。
しかし、人間がSQLを書くことと、人間がSQLを理解することは同じではありません。
生成されたSQLは、本当に意図した対象を抽出しているのか。
顧客や売上を重複して数えていないか。
一部のデータが条件によって除外されていないか。
集計の単位は、確認したいビジネス指標と一致しているか。
結果が変化したとき、その理由を説明できるか。
SQLは、構文として正しくても、業務上は間違っていることがあります。
LLMが生成したという事実は、その結果に対する説明責任を引き受けてはくれません。
むしろSQLが簡単に生成されるほど、これまでSQLを書かなかった人も、生成されたクエリやその結果に関わるようになります。
エンジニアやアナリストだけでなく、その数字を使って施策や事業を判断する人にも、処理を理解する力が必要になります。
これから重要になるのは、構文を暗記し、SQLを一から速く書く力だけではありません。
SQLを読み、データの変化を予測し、結果を検証し、その理由を説明する力です。
技術や操作方法が変化しても、データがどのように抽出され、結合され、集約され、変換されたかを理解する力は、基礎として残ります。
少なくともしばらくの間、その結果に責任を持つのは人間や組織です。
SQL Quiz Bookが育てたいのも、この理解する力です。
まず、途中を見てください
SQL Quiz Bookでは、全98セット・490問を公開しています。
そのうち67セット・335問は、模範解答、解説、テーブル変化の図解まで無料で読むことができます。
有料セットについても、問題、前提知識、使用テーブル、期待出力までは公開しています。どのような教材なのか分からないまま、先に購入する必要はありません。
すべての解説を読む場合は、月額10ドルのProプランと、20ドルの買い切りプランから選べます。読める内容は同じです。
しかし、最初にプランを選ぶ必要はありません。
まずは、一つ問題を開いてみてください。
入力テーブルを見る。
期待出力を見る。
必要なSQLを考える。
そして、クエリに対応するテーブルの変化を一段ずつ追う。
今まで見えなかった途中が見えれば、SQLの読み方だけでなく、データから得られた結果の見方も変わります。
正しいSQLを覚えることから、
データがなぜその結果になったのかを説明できることへ。
SQL Quiz Bookは、テーブルの変化を通してSQLの「途中」を理解するための問題集です。
SQL Quiz Book を開く ↗
sqlquizbook.com