書かずにはじめる SQL

2021-01-27

3,568文字

SQL を書ける人が増えるとハッピーな人が増えると思っているので、「こんな順で SQL に馴染んでいけば良いのではないか」という個人的な考えを書いてみる。

想定読者と前提

このエントリは次のような人を読者として想定している。

事業上の数字に興味があって集計・分析をおこないたい（技術職以外の）人
集計や分析の手法自体にはそれほど関心がなく、出てくる結果に興味がある人

このエントリを読む上では2つ目が重要かもしれない。というのも、このエントリではトップダウンでの SQL の理解を勧めるとともにその方法を書いていく。集計や分析の手法そのものにも興味があって、ボトムアップに理解していく方が良いという人には別の方法の方が良いかもしれないと思っている。

また、環境面で次のような前提を置いている。

集計・分析をする対象のデータベースはすでに存在している
身近に SQL を書ける人がいる

特にデータベースがまだない場合、データベースの設計・作成やデータ蓄積から始める必要があるので難易度がグッと上がってしまう。そんな状況からでも集計・分析を始める人を応援したい気持ちはあるが、ここに書くにはあまりにも余白が足りないのでなんとかしてデータベースに詳しい人を捕まえて相談してほしい。

ざっくり順序

各項目の詳細はこれから書いていくが、全体像として、以下のような順序が良いんじゃないかと思っている。

とにかく動かしてみる
部分的に書き換えられるようになる
何を知る必要があるかを理解する
あとはとにかくサイクルを回す

とにかく動かしてみる

SQL を書けるようになるコツは初めから SQL を書こうとしないこと——と書くとさすがにレトリックが過ぎるが、初手から自分で SQL を書く必要はないと思っている。

身近にいる SQL を書ける人に「こんなデータが見たいんだけど〜」と伝えて SQL を書いてもらった上でそれを実行すれば良い。SQL の書き方に興味があるんじゃなく、出てくる結果に興味があるんだから。

第一歩としてあまりにも頼りなく見えるかもしれないが、これには以下のように結構な効果があると思っている。

集計・分析の結果が欲しいという直近の目的を達成できる
SQL を書けるようになるとできることの雰囲気がわかる
- 今後のモチベーションになる
動くサンプルが手に入る
自分が SQL に興味を持っていることが周囲に伝わる
- 協力的な人が見つかるかもしれない

部分的に書き換えられるようになる

SQL を書いてもらって動かしてみるというのをいくつかやっていくと、特定条件で絞り込みやグルーピングをおこなっている SQL など一部を書き換えてみたいものに出会うはずなので、次はそこを書き換えて実行してみる。書き換えは必ずしも100%自力でおこなう必要はなくて、適宜詳しい人に聞けば良い。

書き換えの例としては以下のような感じ。

ごく簡単な絞り込み条件の変更。日付を書き換えているだけだが、最初はこの程度からで良い。

-- Before
select
    sum(s.amount)
from
    sales s
where
    s.date = '2021-01-27'
;

-- After
select
    sum(s.amount)
from
    sales s
where
    s.date = '2021-01-28' -- 書き換えポイント
;

少し発展した書き換え。売上を日ごとの集計ではなく月ごとの集計にしている。

-- Before
select
    sum(s.amount)
from
    sales s
group by
    s.date
;

-- After
select
    sum(s.amount)
from
    sales s
group by
    extract(month from s.date) -- 書き換えポイント
;

このステップでは以下のようなものを得られる。

細かい修正なら他人に頼まなくても自分でできるので楽
SQL の書き方が実例ベースでなんとなくわかるようになる
- 絞り込みは where、グルーピングは group by など
- この時点では網羅的であったり必ずしも正確である必要はない

何を知る必要があるかを理解する

自分で SQL の書き換えができるようになってくると、ゼロから書くということも自分でやりたくなってくるはず。 SQL の文法など書き方の細かいところを覚えるのはこの段階になってからで良い。

また、SQL の書き方ばかり取り沙汰されがちな印象があるが、SQL の知識だけではデータ集計・分析はできない。自分に今足りてなくて知るべきなのは何かという点について自覚的でいると、前に進みやすいように思う。

業務知識

あまり言及されない気がするけど、とても重要な要素。たとえば、「粗利 = 売上 - 原価」など。

このエントリの想定読者は数字に興味がある人なので業務知識については持っていることが多いと思うが、もしかすると細部については改めて考えてみる必要が生じるかもしれない。粗利の例で言えば、消費税の扱い、端数処理、全体の値引きを各商品に按分して計算するかどうかなど。

データのありか

これも言及されることが少ないように感じているが、集計・分析対象のデータがどこにあるかという知識がないとデータを取り出すことができない。そして、自社のデータがどのように格納されているかというのは世の中で売られている本には絶対に書かれていない。

具体的には、集計・分析しようとしているデータベースにあるテーブルとカラムについて知る必要がある。社内にドキュメントがあるならそれを読むとか、手元で動いているサンプルを眺めるとかしても良いが、正直、知ってる人に聞くのが一番早いので身近な人を捕まえて「原価ってどこに入ってる？」などと聞くのが良いと思う。

データの取り出し方

ここが SQL の部分。ここは一般的な知識で、いろんなサイトや本があるのでそれを見ながら身につけていくと良いと思う。

ざっくり分けると SQL 全体の文法についての知識と個々の関数についての知識に分けられるかなと思う。

SQL 全体となると膨大なのでここで細部まで書くことはできないが、全体を通してポイントを書くとすると以下のような感じだろうか。

select 文以外はまるっとスルーで大丈夫
- insert, update, delete, create table とか全部一旦忘れて良い
join は躓きポイントだけど、join なしで実用的な SQL を書くことは難しいのでがんばって
- inner join, outer join の使い分けは実用上も頻出するので重要
- cross join はあまり出てこないので一旦スルーでも大丈夫
null の扱いはちょっとややこしいので注意して覚えて
サブクエリを使えるようになるとできることがグッと増える
関数の細部は覚える必要なし、ググりながら書ければ大丈夫

データの見方

最後に取り出したデータをどう見るか。

たとえば、個々のお客さんの売上を算出することができたとして、その数字を要約するときには平均値（算術平均）が良いのか、中央値が良いのか、あるいは分布を見る必要があるのかなどという話。つまり、基本的な統計の知識が必要になる。

集計・分析を始めた最初期には必要ないかもしれないが、出てきた数字を根拠にして何かしらの判断なり意思決定をすると「とりあえず平均で」とはならないはず。

あとはとにかくサイクルを回す

ある程度 SQL を書けるようになったら、あとは必要に応じて書くだけになる。その時々の欲しいデータによっては新しい関数を使う必要なども出てくると思うので、都度調べたり聞いたりしながら書いていく。

その際に重要なのは書いた SQL を誰かにレビューしてもらうこと。それっぽい SQL を書けたとしても出てきた結果が必ずしも正しいとは限らないし、より効率的な書き方があったりする。

また、一定以上複雑なものについては必ずしも自分で書く必要はないという割り切りも重要だと思っている。このエントリの想定読者はデータ分析のプロではないので、すべてを自分でやる必要はないし、得意な人がいるなら適切に頼れば良い。フレンズによってとくいなことちがうからね。

他の人に頼る際にも、データ分析の経験があることによって要件を明確に伝えられるなどの強みは活きてくると思う。

その他

SQL クライアント

SQL を実行するのにどのツールを使うかという話。

基本的には身近な人が使っているツールに揃えるのが良いと思う。それ以外だと、個人的には Bdash がオススメ。

個人的には DataGrip と Bdash を併用しているが、DataGrip は安くないし UI も初心者向きではないので初手としてはあまり勧めない。

ググるときの注意点

自分が書く SQL がどのデータベース向けなのかを意識する。

PostgreSQL と MySQL など、データベースが変わると書ける関数が違うので、検索するときには「PostgreSQL 中央値」などデータベース名も含めて検索すると良い。

Propose changes / Revisions