はじめに
データ基盤案件に入った当初、実装を始めるときはすぐにSQLエディタを開いていました。
設計書を読みながら、とりあえず必要そうなテーブルを並べ、JOINを書き、実行結果を見ながら修正する進め方です。
しかし、この方法では途中で何度も手が止まりました。
- 必要なカラムがどのテーブルにあるか分からない
- JOINする理由を説明できない
- 結合後に件数が増えた原因が分からない
- 同じ意味に見えるカラムが複数存在する
- 最終的な出力と画面仕様がつながらない
そこで、SQLを書く前に、自分用の簡単な図とメモを作るようにしました。
結果として、SQLを書いている時間よりも、迷っている時間が減りました。
設計書を読むだけでは、頭の中でつながらなかった
設計書には、テーブル名、カラム、結合条件、加工内容などが書かれています。
ただし、必要な情報が複数の資料やシートに分かれていることも多く、読むだけでは全体像をつかめませんでした。
そこで、設計書の内容をそのまま覚えようとするのではなく、自分が理解しやすい形に書き直すことにしました。
SQLを書く前に整理するのは、主に次の3つです。
- テーブル同士の関係
- 必要なカラムの取得元
- データが出力されるまでの流れ
1. テーブル同士の関係を書く
まず、使用するテーブルと結合キーだけを書きます。
正式なER図を作る必要はありません。
今日の売上
│
│ 商品コード
▼
商品一覧
│
│ 店舗名
▼
店舗一覧
この程度でも、次のことを考えやすくなります。
- なぜこのテーブルを結合するのか
- 結合キーは一意になっているか
- LEFT JOINである必要があるか
- JOINによって件数が増える可能性はないか
以前は設計書に書かれたJOINをそのまま実装していました。
図を書くようになってからは、JOINの意味を理解してからSQLに落とし込めるようになりました。
2. 必要なカラムの取得元を書く
次に、出力したいカラムがどこから来るのかを整理します。
| 出力カラム | 取得元 | 加工内容 |
|---|---|---|
| 売上日 | 売上実績 | そのまま |
| 商品名 | 商品一覧 | そのまま |
| 店舗名 | 店舗一覧 | そのまま |
| 商品区分 | 売上実績 | CASEで名称へ変換 |
| 商品金額 | 売上実績 | 店舗単位で集計 |
この表を作ると、SELECT句を書く前にカラムの流れを確認できます。
また、不要なテーブルをJOINしていないかも判断しやすくなります。
特に、同じような名称のカラムが複数のテーブルにある場合に有効でした。
3. 出力までの流れを書く
最後に、設計書からSQLまでの確認順を整理します。
設計書
↓
テーブル関係図
↓
カラムの取得元
↓
実データ
↓
画面・出力仕様
↓
SQL
実データを見るのは、設計書の理解が正しいか確認するためです。
たとえば、次のような点を確認します。
- 結合キーに重複がないか
- NULLが存在しないか
- コード値が想定どおりか
- 日付や文字列の形式が統一されているか
- 1行が何を表しているのか
画面や出力仕様では、最終的に必要な集計単位を確認します。
同じ元データでも、日単位で集計するのか、月単位で集計するのかによって、GROUP BYやJOINの考え方が変わるためです。
図を書く時間は、遠回りではなかった
最初は、図や表を作るよりも、すぐSQLを書いた方が早いと思っていました。
しかし、理解が不十分なまま実装を始めると、後から次のような手戻りが発生します。
- JOIN条件の修正
- 不要なテーブルの削除
- 集計単位の見直し
- カラムの取得元の変更
- 重複レコードの原因調査
SQLを書く前に図を作るようになってからは、最初の準備時間は増えました。
一方で、実装中に設計書を読み直す回数や、SQLを大きく作り直す回数は減りました。
SQLの入力速度が上がったのではありません。
SQLを書く前に迷う要素を減らしたことで、結果的に実装が速くなりました。
まとめ
現在は、SQLを書く前に次の3点を整理しています。
- テーブル同士をどのキーで結合するか
- 必要なカラムをどこから取得するか
- 元データが最終出力までどのように流れるか
完成度の高いER図を作る必要はありません。
自分がJOINとカラムの流れを説明できる程度の簡単な図で十分です。
SQLを速く書くために必要だったのは、すぐにSQLを書き始めることではありませんでした。
最初の30分でデータの流れを整理し、実装中に迷わない状態を作ることでした。