はじめに
データ戦略室ビジネスアナリティクスグループの須賀と申します。
2021年8月に中途入社をして、4か月が経とうとしています。
前職ではデータ関係の仕事をしていたわけではなく、「SQLって何？」という状態で転職をしました。
今ではある程度SQLを扱えるようになりましたが、ここまでの4か月は決して楽な道のりではありませんでした。
今回は、これからデータに関する業務を始めようとする人や未経験者を指導する立場の方に対して、自身の経験談を交えながら初心者がぶつかりやすい壁とその乗り越え方を紹介したいと思います。
しくじりその①：プライマリーキーの把握
データ抽出がうまくいかなかった理由の一つとして、そもそも使用している抽出元のテーブルのプライマリーキーは何なのか、どんなデータのテーブルなのかが不明瞭なままデータ抽出しようとしていたことが挙げられます。
たとえば、以下のテーブル
テーブルAは、従業員id×売上月の2つの情報の複合でプライマリーキーとなり、従業員の月ごとの売上を集計したテーブルになっています。
一方、テーブルBは従業員idがプライマリーキーとなっており、従業員の名前が格納されたテーブルになっています。
テーブルAに対して、「売上のテーブル」とだけ認識していると、正しいデータは抽出できませんし、以下でお話しするJOINのミスに繋がる可能性もあります。
しくじりその②：JOINを使ったテーブル結合
SQLを学ぶ中で、最初にして最大のしくじりポイントだと個人的に感じたのは「JOIN」の使い方でした。
最初にJOINについて学ぶ際に、ネット検索や参考書を頼りに「複数のテーブルからカラムを取得したいときは共通のカラムをキーにJOINすればOK！」という情報に行きつきました。
上記の例は、メンバーテーブルとオフィステーブルを用いて、メンバーの所属しているオフィスと部署を抽出したい場合です。
「部署idが両方のテーブルに共通のカラムだから、部署idでJOINをすれば両方のテーブルから必要な情報を得ることができる」と考えました。
抽出結果は以下の通りになります。
1メンバーあたり2行の結果が返ってきてしまいました。
同じ部署idでも、オフィスが複数ある場合があるため、1部署に対して2オフィスが抽出されてしまいました。
今回の抽出の場合には、チームテーブルにおけるプライマリキーであるチームidで結合をすることで、1メンバー当たり1オフィス1部署の抽出を行うことができました。
テーブルのプライマリーキーを正しく把握できていないと、JOINで他のテーブルを結合する際に、意図しているものとは別の結合になっていることがあります。
基になるテーブルのプライマリキーはなにで、結合するテーブルとはどういう関係になっているのかを理解していないと、正しいデータ抽出はできません。
結果のレコード数が今回のように少なかったり、JOINするテーブルが少なければ抽出時点で間違いにすぐ気が付くのですが、結果が数万行を超えたり、JOINするテーブルの数が増えたりするとどこのJOINで間違ったのか、そもそも間違った結果になっているのかすら気が付かないこともありました。
しくじりその③：SQLの実行順序
SQLを使い始めてしばらくの間、SQLが実行される順番を意識していませんでした。
チームに入りたての頃に任されていた簡単なデータ抽出であれば実行順について何も知らなくてもほしいデータが手に入るからです。
実行順が大事であることに気が付くのは、SELECT句内で新しいカラム名を定義する必要性が出てきたり、集計をするためにGROUP BY句を使用する必要性が出てきたタイミングです。
昔の僕はこんなクエリを作っていました。
まずはSELECT句でクラスごとの平均点のカラムを作って、WHERE句で80点以上のものに絞ればいいかな…と思ったのですが、「平均点カラムは見つかりません」のようなエラーがでて、クエリは動いてくれませんでした。
SELECT句で平均点カラムを作ったのにどうして見つからないのか、初心者の僕は混乱しましたが、そんな時、SQLには実行順があることを知りました。
SELECT句とWHERE句では、WHERE句のほうが処理順が先になるため、SELECT句で新しくカラムを作ってもWHERE句が処理されるタイミングではまだ新しいカラムは用意されていない状態だったというわけですね。
しくじりを乗り越えたきっかけ
ここからは、紹介した3つのしくじりをどう乗り越えたのかを紹介したいと思います。
きっかけとなったのは、データマートの設計図作成でした。
例えば、上記のようなデータマートがあったとします。
データマートの元となるテーブルは、「分類テーブル」「商品名テーブル」「価格テーブル」の3つです。
各データマートについて、このような形で設計図を作成していきます。
わかりやすい設計図を作るためには、各中間テーブルがどのような意味があって作られ、中でどのような処理が何のためにされているのかを理解する必要がありました。そのために、
- 基となるテーブルの構造
- テーブルのプライマリキーはなにか
- 結合するテーブル同士の関係
- それぞれの予約語の意味、目的
といった点を正確に理解する必要がありました。
これらの点を踏まえて設計図を作ることで感じたメリットは以下の3つです。
プライマリキーへの意識が高まった
もともとプライマリーキーに関してあまり意識せずにクエリを書いていましたが、設計図を作る中でテーブルがどのように結合されているのかを考えるうちに、それぞれのテーブルのプライマリーキーを正しく把握することがクエリを書くときに重要であることを学びました。
自分が使うデータの構造を理解できた
自分が普段データ抽出に使っているテーブルにはどのようなデータが存在し、他のテーブルとはどのような関係性になっているのかを理解できました。
データ抽出をする際に、そのデータを出すためにはどのテーブルを使う必要があり、それぞれをどのように結合してデータを抽出すればよいのかをスムーズに考えられるようになりました。
予約語の意味や使い方を知ることができた
クエリを読み解く中で、これまで見たことのないような予約語を目にすることが多く、その予約語で何ができるのか、何のためにその予約語を用いているのかを理解する必要がありました。
その結果、自分がデータ抽出をする際にできることの選択肢が増えました。
自分のほしいデータ抽出をするために、どのような処理が必要か、クエリで実現できることは何かをより幅広く考えられるようになりました。
最後に
これまでのしくじりは、「わからないことをわからないままにしていたこと」「わかった気になっていたこと」が原因だったと振り返ってみて自覚をしています。
当時の僕は「わからないものをわかるまで調べること」「それでもわからないときは人に聞くこと、聞ける環境があること」ということをより意識すべきだったと感じています。
なにか少しでもわからない、間違っている気がすると思うときにはそのままにせずに、しっかり理解できるまで勉強をしてからその先の勉強に進むべきでした。
とはいえ、いくら調べてもわからない、どう調べたらいいかわからない、わかっていない状況を認識できないといったことも起こりえます。
その時には、有識者に教えを求めること、アウトプットに対して細かくレビューをもらうことが非常に有効でした。
データ初心者に教える立場の人には、わからないことの調べ方の事前共有や、それでもわからないときに聞きやすい環境を用意することが大切なのだと思います。
「わからないをわからないままにしない」は、SQLに限らず、どんな仕事にも必要なことだと思います。自分も、今後の仕事でより大事にしていきたいです。
