はじめに
本記事は「JOINしたら売上が増えた？テーブルの粒度・主キー・1対多を理解する」の続編です。
SQLで合計を出せても、その数字の意味が正しいとは限りません。
たとえば「売上」には、少なくとも次の考え方があります。
- 注文された時点の金額
- 発送が完了した商品の金額
- キャンセルや返品を差し引いた金額
どれも売上と呼べますが、答えている問いが違います。
この記事では、数字を速く出す仕組みであるサマリーテーブルと、数字を正しく読む仕組みであるデータ定義書を、ひとつの例でつなげます。
1. 明細を毎回集計すると遅い
売上明細では、通常は1回の購入や1商品ごとに1行が記録されます。
ダッシュボードを開くたびに大量の明細を読み、日付と商品で分けて合計すると、同じ計算を何度も繰り返すことになります。
売上明細
↓ 日付・商品ごとに合計
日別商品別の売上
そこで、よく使う集計結果を先に保存しておきます。
2. 集計結果を先に保存する
次のテーブルは、1行が「1日 × 1商品」の売上を表しています。
| 日付 | 商品 | 売上 |
|---|---|---|
| 9月1日 | 商品A | 120,000円 |
| 9月1日 | 商品B | 85,000円 |
| 9月2日 | 商品A | 98,000円 |
このような集計済みのテーブルを、サマリーテーブルと呼びます。明細から毎回計算しなくてよいため、レポートを速く表示できます。
ただし、集計したことで情報は少なくなります。
- 購入1件ごとの詳細は分からない
- 「1日 × 1商品」より細かく分析できない
- 更新後でなければ最新の売上は含まれない
速くなった代わりに、「この1行は何を表すのか」「どこまで新しいのか」を確認する必要が生まれます。
3. テーブル名だけでは意味が分からない
次の名前を見ただけで、違いを説明できるでしょうか。
sales_daily
sales_summary
mart_sales
名前だけでは、売上が税込みか税抜きか、返品を除くのか、いつまでのデータなのか分かりません。
SQLは指定された列を正確に計算します。しかし、どのテーブルと定義を選ぶべきかまでは決めてくれません。
そこで、テーブルの取扱説明書としてデータ定義書を用意します。
4. データ定義書には理由を書き添える
| 項目 | 記載例 | なぜ必要か |
|---|---|---|
| 用途 | 日別・商品別の売上分析 | 目的に合うテーブルか判断するため |
| 1行の意味 | 1日 × 1商品 | 二重集計やJOINによる重複を防ぐため |
| 売上の定義 | 税抜き・キャンセルと返品を除く | 同じ「売上」の解釈をそろえるため |
| 元データ | 注文明細・商品マスタ | 数字の作られ方を追えるようにするため |
| 更新 | 毎朝6時・前日分まで | 最新データが含まれるか判断するため |
| 管理者 | データ基盤チーム | 不明点や異常を確認できるようにするため |
重要なのは項目を埋めることではなく、その説明によって、どんな間違いを防げるかです。
こうした「データについて説明するデータ」をメタデータと呼びます。データ定義書は、メタデータを人が読める形にまとめたものの一つです。
5. 実際に使う前の確認
たとえば、9月8日の午前10時に「今日の売上」を聞かれたとします。
データ定義書に「毎朝6時更新・前日分まで」とあれば、そのテーブルから分かるのは9月7日までです。SQLが正しくても、9月8日の売上として提示すれば回答は誤りになります。
初めて使うテーブルでは、SQLを書く前に次の順で確認します。
- 何のためのテーブルか
- 1行は何を表すか
- 指標はどう定義されているか
- いつまでのデータが入っているか
- 分からないとき誰に確認するか
この5点が分かれば、テーブル名から推測して集計する危険を大きく減らせます。
まとめ
- サマリーテーブルは、よく使う単位で先に集計したテーブル
- 集計すると速くなる一方、詳細や最新性に制約が生まれる
- データ定義書は、1行の意味・指標の定義・更新時刻などを説明する
- 各項目は、数字の取り違えを防ぐために存在する
- SQLを書く前に定義を確認すると、速さと正しさを両立しやすい
次回は、「毎朝6時更新」の裏側を扱います。まとめて処理するバッチ処理と、到着に合わせて処理するストリーミング処理の違いを整理します。