SQL GROUP BY — COUNT DISTINCT・FILTER・ROLLUPの応用

QUESTION 6

ユニーク数 — COUNT(DISTINCT) でグループ内の重複を除いて数える

COUNT(DISTINCT)ユニーク数重複を除く集計ユニーク集計

前提知識 ▼

同じ人が何度もアクセスする——そんなデータで「延べ件数」と「実人数」は別物です。グループ内の重複を除いた個数を数えるには COUNT(DISTINCT 列) を使います。COUNT(*)（行数）と COUNT(列)（NULL以外の数）との違いが鍵です。

-- 3種類の COUNT を比べる
COUNT(*)                  -- 行数（NULLも含めて全行）
COUNT(user_id)           -- user_id が NULL でない行数
COUNT(DISTINCT user_id)  -- user_id の異なる値の数（重複を1つに畳む）

DISTINCT は「異なる値の数」：COUNT(DISTINCT user_id) は、グループ内で重複を除いた user_id の種類数を返します。延べアクセス(COUNT(*))が同じでも、同一ユーザーの再訪が多ければ実人数(COUNT(DISTINCT user_id))は小さくなります。NULL は数えません。

問題 ▼

page_views テーブルから、日別の延べ閲覧数とユニーク訪問者数を求めてください。出力列は view_date, total_views, unique_users。view_date の昇順で返してください。

使用テーブル

► page_views（7行）

view_id	view_date	user_id
1	2024-05-01	U1
2	2024-05-01	U1
3	2024-05-01	U2
4	2024-05-02	U2
5	2024-05-02	U3
6	2024-05-02	U3
7	2024-05-02	U1

期待出力 ▼

view_date	total_views	unique_users
2024-05-01	3	2
2024-05-02	4	3

模範解答コード ▼

SELECT
  view_date,
  COUNT(*)                AS total_views,  -- その日の行数＝延べ閲覧数
  COUNT(DISTINCT user_id) AS unique_users  -- 重複を除いた user_id の数＝実訪問者数
FROM     page_views
GROUP BY view_date              -- 日付ごとにグループ化
ORDER BY view_date;             -- 日付の昇順（時系列）

/*
  実行順序（SQLの論理的な評価順）:
  1. FROM page_views     → 行を読込
  2. GROUP BY view_date  → 日付でグループ化
  3. 集計                  → COUNT・DISTINCTユーザー数
  4. ORDER BY view_date  → 日付順に整列
  */

解説（テーブル変化・ポイント） ▼

SELECT
  view_date,
  COUNT(*) AS total_views,
  COUNT(DISTINCT user_id) AS unique_users
FROM     page_views
GROUP BY view_date
ORDER BY view_date;

LEGEND ▼

データ取得・読込対象

① FROM page_views（7行） ▼

FROM page_viewspage_views の7行を読み込みます。user_id を見ると 5/1 は U1 が2回、5/2 は U3 が2回現れます。この重複の扱いが延べ数とユニーク数を分けます。

1 / 5

view_id	view_date	user_id
1	2024-05-01	U1
2	2024-05-01	U1
3	2024-05-01	U2
4	2024-05-02	U2
5	2024-05-02	U3
6	2024-05-02	U3
7	2024-05-02	U1

7行読込（再訪を含む）

学習ポイント

3つの COUNT を使い分ける：COUNT(*)は行数、COUNT(列)はその列が NULL でない行数、COUNT(DISTINCT 列)は重複を除いた値の種類数。「延べ」か「実数」か、要件に応じて選びます。本問の延べ閲覧数と実訪問者数の差は、まさにこの違いです。

DISTINCT は NULL を数えない：COUNT 系はもともと NULL を無視しますが、COUNT(DISTINCT 列)でもNULL は種類に含めません。「値が入っている異なるものの数」と覚えると安全です。

延べ ÷ 実数で「再訪度」も見える：同じグループで COUNT(*) と COUNT(DISTINCT user_id) を並べると、1人あたり何回かが分かります。KPI でいう「セッション数 vs ユニークユーザー数」の関係そのものです。

アンチパターン

実人数のつもりで COUNT(*) を使う：「ユニーク訪問者数」が欲しいのに COUNT(*) を使うと、再訪が二重・三重に数えられ水増しになります。実数なら必ず COUNT(DISTINCT user_id)。

複数列の DISTINCT を方言で書く：「user_id と page の組のユニーク数」は、PostgreSQL では COUNT(DISTINCT (user_id, page)) と行コンストラクタで書きます。COUNT(DISTINCT user_id, page) という構文は MySQL 方言で、PostgreSQL では動きません。

実務コラム：DAU/MAU とユニーク集計

日次アクティブユーザー(DAU)、月次(MAU)、ユニーク購入者数、取扱ブランド数——「種類の数」を測る指標は COUNT(DISTINCT …) が土台です。期間でまとめたいときは基礎編の DATE_TRUNC と組み合わせ、GROUP BY DATE_TRUNC('month', ts) に COUNT(DISTINCT user_id) を足せば月次ユニークが取れます。なお DISTINCT 集計は大規模データでは重くなりがちで、近似で良ければ HyperLogLog 系の近似カウント（APPROX_COUNT_DISTINCT 等）を使う製品もあります。

QUESTION 7

条件付き集計 — FILTER でステータス別に横持ち集計（ピボット）する

FILTER句条件付き集計ピボット/横持ちクロス集計

前提知識 ▼

「状態ごとの件数を1行に並べたい」——縦に積まれた status を横方向の列に展開するのがピボット（横持ち）です。条件付き集計を使えば、テーブルを1回スキャンするだけで複数の指標を同時に取れます。PostgreSQL では集計関数の FILTER (WHERE …) がエレガントです。

-- FILTER は「その集計だけに効く WHERE」
COUNT(*) FILTER (WHERE status = 'paid')      -- paid の行だけ数える
SUM(amount) FILTER (WHERE status = 'paid') -- paid の金額だけ合計
-- 移植性重視なら CASE で同等に書ける
SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END)

WHERE と FILTER の決定的な違い：WHERE はグループ全体の行を絞り込むため、すべての集計に同じ条件がかかります。一方 FILTER はその集計関数1つだけに条件を効かせます。だから「総数」と「paid だけの数」を同じ行に並べて出せるのです。条件に当たる行が無ければ COUNT は0、SUM は NULL になります。

問題 ▼

orders テーブルから、カテゴリ別に、総件数・ステータス別件数・paid の合計金額を1行にまとめてください。出力列は category, total_orders, paid_orders, pending_orders, cancelled_orders, paid_amount。total_orders の降順、同数なら category の昇順で返してください。

使用テーブル

► orders（8行）

order_id	category	status	amount
1	Books	paid	1200
2	Books	paid	800
3	Books	paid	600
4	Books	pending	500
5	Books	cancelled	300
6	Toys	paid	2000
7	Toys	cancelled	1500
8	Toys	pending	700

期待出力 ▼

category	total_orders	paid_orders	pending_orders	cancelled_orders	paid_amount
Books	5	3	1	1	2600
Toys	3	1	1	1	2000

模範解答コード ▼

SELECT
  category,
  COUNT(*)                                        AS total_orders,      -- カテゴリ内の総件数
  COUNT(*) FILTER (WHERE status = 'paid')      AS paid_orders,       -- paid だけ数える
  COUNT(*) FILTER (WHERE status = 'pending')   AS pending_orders,    -- pending だけ数える
  COUNT(*) FILTER (WHERE status = 'cancelled') AS cancelled_orders,  -- cancelled だけ数える
  COALESCE(SUM(amount) FILTER (WHERE status = 'paid'), 0) AS paid_amount  -- paid の金額だけ合計（無ければ0）
FROM     orders
GROUP BY category                                    -- カテゴリ単位でグループ化
ORDER BY total_orders DESC, category;             -- 総件数の多い順、同数はカテゴリ名の昇順

/*
  実行順序（SQLの論理的な評価順）:
  1. FROM orders                           → 行を読込
  2. GROUP BY category                     → カテゴリでグループ化
  3. 集計（FILTER で条件別）                       → 状態別件数・金額
  4. ORDER BY total_orders DESC, category  → 件数の多い順で並べ替え
  */

解説（テーブル変化・ポイント） ▼

SELECT
  category,
  COUNT(*) AS total_orders,
  COUNT(*) FILTER (WHERE status = 'paid') AS paid_orders,
  COUNT(*) FILTER (WHERE status = 'pending') AS pending_orders,
  COUNT(*) FILTER (WHERE status = 'cancelled') AS cancelled_orders,
  COALESCE(SUM(amount) FILTER (WHERE status = 'paid'), 0) AS paid_amount
FROM     orders
GROUP BY category
ORDER BY total_orders DESC, category;

LEGEND ▼

データ取得・読込対象

① FROM orders（8行） ▼

FROM ordersorders の8行を読み込みます。status が paid/pending/cancelled と縦に並んでいます。これをカテゴリ別に、横方向の集計列へ展開します。

1 / 5

order_id	category	status	amount
1	Books	paid	1200
2	Books	paid	800
3	Books	paid	600
4	Books	pending	500
5	Books	cancelled	300
6	Toys	paid	2000
7	Toys	cancelled	1500
8	Toys	pending	700

8行読込（status は縦持ち）

学習ポイント

条件付き集計＝1スキャンで多指標：1回のグループ化で、総数と状態別の数を同時に得られます。テーブルを何度も読み直したり、複数クエリを UNION したりせずに済む、レポートの王道テクニックです。

FILTER は「その集計だけの WHERE」：COUNT(*) FILTER (WHERE status='paid') の条件はその1つの COUNT にだけ効きます。グループ全体を絞る WHERE と違い、総数と部分集計を同じ行に共存させられます。これが横持ち（ピボット）の核心です。

CASE 版との互換：FILTER が使えない環境では SUM(CASE WHEN status='paid' THEN 1 ELSE 0 END) や COUNT(CASE WHEN status='paid' THEN 1 END) で同じ結果になります。意味は「条件に合う行だけ 1（または値）として畳み込む」。

アンチパターン

条件を WHERE に書いてしまう：WHERE status='paid' をクエリ全体に付けると、pending/cancelled の行が消え、total も paid だけの数になります。「総数」と「状態別」を1行で出したいなら、絞り込みは WHERE ではなく各集計の FILTER（または CASE）へ。

COUNT(CASE …) に ELSE 0 を付ける：COUNT(CASE WHEN status='paid' THEN 1 ELSE 0 END) は、0 も「値あり」として全行が数えられてしまいます。COUNT は NULL を無視するので、非該当はELSE を書かず NULL のままにするのが正解（または SUM(CASE … THEN 1 ELSE 0 END) を使う）。

実務コラム：クロス集計表はこれ一本

「月×ステータスの件数表」「店舗×商品カテゴリの売上表」——ダッシュボードで頻出のクロス集計は、行方向を GROUP BY、列方向を FILTER（条件付き集計）で表現するのが定石です。列の種類が固定なら本問のように手で並べ、可変なら crosstab()（tablefunc 拡張）やアプリ側のピボットに渡します。コンバージョン率のような比率は、COUNT(*) FILTER (WHERE converted) * 1.0 / COUNT(*) のように「分子だけ FILTER」で一発です。

QUESTION 8

小計と総計 — ROLLUP で小計・総計行を一度に出す

GROUP BY ROLLUPGROUPING()小計/総計集計の階層化

前提知識 ▼

明細の集計に加えて「地域ごとの小計」と「全体の総計」も同じ表に出したい——そんなときは GROUP BY ROLLUP(…) です。通常のグループ化に、上位のまとめ行（小計・総計）を自動で付け足してくれます。まとめ行かどうかは GROUPING() で見分けます。

-- ROLLUP(a, b) は次の3通りの集計を一度に生成する
GROUP BY ROLLUP(region, product)
--   (region, product) … 明細
--   (region)          … region 小計（product を畳む）
--   ()                … 総計（すべて畳む）

GROUPING(product)  -- その行で product が畳まれていれば 1、明細なら 0

「畳まれた列」は NULL になる：ROLLUP が生成する小計・総計行では、畳んだ列の値が NULL になります。ただし元データの NULL と区別がつかないため、GROUPING(列)=1（＝その列はまとめられた）で判定し、CASE で '(All)' などのラベルに置き換えるのが定番です。

問題 ▼

sales テーブルから、地域×商品の売上に、地域ごとの小計と全体の総計を加えた表を作ってください。出力列は region, product, total_amount。小計・総計の行では畳んだ列を (All) と表示し、各ブロックの末尾（明細→小計、最後に総計）に並ぶようにしてください。

使用テーブル

► sales（4行）

region	product	amount
East	Apple	100
East	Banana	150
West	Apple	200
West	Banana	250

期待出力 ▼

region	product	total_amount
East	Apple	100
East	Banana	150
East	(All)	250
West	Apple	200
West	Banana	250
West	(All)	450
(All)	(All)	700

模範解答コード ▼

SELECT
  CASE WHEN GROUPING(region)  = 1 THEN '(All)' ELSE region  END AS region,   -- 畳まれた region は (All) と表示
  CASE WHEN GROUPING(product) = 1 THEN '(All)' ELSE product END AS product,  -- 畳まれた product は (All) と表示
  SUM(amount) AS total_amount                                              -- 明細・小計・総計いずれも合計
FROM     sales
GROUP BY ROLLUP(region, product)        -- 明細＋region小計＋総計をまとめて生成
ORDER BY GROUPING(region), region,        -- 総計(region畳み=1)を最後に
         GROUPING(product), product;     -- 各region内で小計(product畳み=1)を末尾に

/*
  実行順序（SQLの論理的な評価順）:
  1. FROM sales                        → 行を読込
  2. GROUP BY ROLLUP(region, product)  → 明細・小計・総計を生成
  3. SUM(amount)                       → 各単位で合計
  4. SELECT                            → GROUPING() を CASE で '(All)' に置換
  5. ORDER BY GROUPING(region), region, GROUPING(product), product            → 明細→小計→総計に整列
  */

解説（テーブル変化・ポイント） ▼

SELECT
  CASE WHEN GROUPING(region) = 1 THEN '(All)' ELSE region END AS region,
  CASE WHEN GROUPING(product) = 1 THEN '(All)' ELSE product END AS product,
  SUM(amount) AS total_amount
FROM     sales
GROUP BY ROLLUP(region, product)
ORDER BY GROUPING(region), region,
         GROUPING(product), product;

LEGEND ▼

データ取得・読込対象

① FROM sales（4行） ▼

FROM salessales の4行を読み込みます。region(East/West)×product(Apple/Banana)の明細です。ここに小計と総計を付け足すのが目的です。

1 / 5

region	product	amount
East	Apple	100
East	Banana	150
West	Apple	200
West	Banana	250

4行読込（明細）

学習ポイント

ROLLUP は集計単位を階層生成：ROLLUP(region, product) は (region,product) → (region) → () の3階層を一度に集計します。明細・小計・総計を別クエリで作って UNION したりする必要がなく、1文で完結します。左から順に畳まれる階層の向きがポイントです。

GROUPING() でまとめ行を判定：小計・総計行は畳んだ列が NULL になります。元データの NULL と紛れるため、GROUPING(列)=1 で「この列はまとめられた」と判定し、ラベル付けや並べ替えに使います。本物の NULL と小計の NULL を区別できる手段です。

GROUPING を ORDER BY に使うと整列が決まる：ORDER BY GROUPING(region), region, GROUPING(product), product とすると、各ブロック内で明細→小計、全体の最後に総計という自然な並びになります。まとめ行が先頭に来てしまう事故を防げます。

アンチパターン

小計の NULL を WHERE で消してしまう：WHERE product IS NOT NULL を付けると、product を畳んだ小計・総計まで丸ごと除外されます。まとめ行を残したいなら、判定は product IS NULL ではなく GROUPING(product) で行います。

ROLLUP の順序を取り違える：ROLLUP(region, product) が出すのはregion 小計であって product 小計ではありません。product ごとの小計が欲しいなら ROLLUP(product, region) にするか、両方なら CUBE(region, product) や GROUPING SETS を使います。

実務コラム：レポートの「合計行」はDB側で

月次レポートの小計・総計、ピボットテーブルの集計行——これらは ROLLUP / CUBE / GROUPING SETS でDB側に寄せると、アプリの集計ループが消えて速く・正確になります。任意の組み合わせの小計が欲しいときは GROUPING SETS((region),(product),()) のように欲しい単位だけを列挙でき、無駄な集計を省けます。BIツールの「小計表示」も、裏側はたいていこの仲間です。

QUESTION 9

二段階集計 — 派生テーブルで「平均の平均」を正しく出す

サブクエリ/CTE二段階集計粒度の変換集計の集計

前提知識 ▼

「顧客あたりの平均購入額」を出すつもりが、いつのまにか「注文あたりの平均」になっていた——集計の粒度を誤る典型です。ある集計の結果をさらに集計するには、サブクエリ（派生テーブル）や CTE で段階を分けます。1つの GROUP BY だけでは表現できません。

-- ① まず顧客ごとに合計（粒度＝顧客）
WITH customer_totals AS (
  SELECT customer_id, SUM(amount) AS customer_total
  FROM orders GROUP BY customer_id
)
-- ② その結果(1行=1顧客)を、さらに平均する
SELECT AVG(customer_total) FROM customer_totals;

粒度が変わると意味が変わる：生の orders に対する AVG(amount) は注文あたりの平均です。一度 GROUP BY customer_id で顧客の合計に畳んでから AVG すると、顧客あたりの平均になります。両者は別の数値。「何あたりの平均か」を常に意識しましょう。

問題 ▼

orders テーブルから、地域ごとに「顧客数」と「顧客1人あたりの平均購入額」を求めてください（まず顧客ごとの合計を出し、その合計を地域で平均します）。出力列は region, customer_count, avg_customer_spend（平均は四捨五入して整数）。avg_customer_spend の降順、同数なら region の昇順で返してください。

使用テーブル

► orders（6行）

order_id	region	customer_id	amount
1	East	C1	1000
2	East	C1	2000
3	East	C2	3000
4	West	C3	500
5	West	C3	500
6	West	C4	2000

期待出力 ▼

region	customer_count	avg_customer_spend
East	2	3000
West	2	1500

模範解答コード ▼

WITH customer_totals AS (        -- 第1段階: 顧客ごとの合計（粒度＝顧客）
  SELECT
    region,
    customer_id,
    SUM(amount) AS customer_total
  FROM     orders
  GROUP BY region, customer_id        -- 地域×顧客で束ねる（1行＝1顧客）
)
SELECT                                -- 第2段階: 顧客合計を地域で集計
  region,
  COUNT(*)                   AS customer_count,     -- 行数＝その地域の顧客数
  ROUND(AVG(customer_total)) AS avg_customer_spend  -- 顧客合計の平均＝顧客あたり平均
FROM     customer_totals
GROUP BY region                        -- 地域でグループ化
ORDER BY avg_customer_spend DESC, region;  -- 平均の高い順、同額は地域名の昇順

/*
  実行順序（SQLの論理的な評価順）:
  1. CTE customer_totals               → 顧客ごとに売上を集計
  2. 外側 FROM customer_totals           → 集計結果を参照
  3. GROUP BY region                   → 地域でグループ化
  4. COUNT(*) / ROUND(AVG(...))        → 顧客数と平均を集計
  5. ORDER BY avg_customer_spend DESC, region  → 平均の多い順で並べ替え
  */

解説（テーブル変化・ポイント） ▼

WITH customer_totals AS (
  SELECT region, customer_id,
    SUM(amount) AS customer_total
  FROM orders
  GROUP BY region, customer_id
)
SELECT
  region,
  COUNT(*) AS customer_count,
  ROUND(AVG(customer_total)) AS avg_customer_spend
FROM     customer_totals
GROUP BY region
ORDER BY avg_customer_spend DESC, region;

LEGEND ▼

データ取得・読込対象

① FROM orders（6行） ▼

FROM ordersorders の6行を読み込みます。C1 と C3 は複数注文を持っています。まず顧客ごとに合計し、その合計を地域で平均する二段階で進めます。

1 / 5

order_id	region	customer_id	amount
1	East	C1	1000
2	East	C1	2000
3	East	C2	3000
4	West	C3	500
5	West	C3	500
6	West	C4	2000

6行読込（注文単位）

学習ポイント

集計の結果をさらに集計＝二段階：「合計の平均」「平均の最大」のような集計の集計は、1つの GROUP BY では書けません。サブクエリ/CTE で段階を分け、第1段階の出力を第2段階の入力テーブルとして扱います。

段階ごとに「1行が何を表すか（粒度）」が変わる：第1段階の出力は1行＝1顧客。だから外側の COUNT(*) は顧客数、AVG(customer_total) は顧客あたり平均になります。粒度を言語化すると、集計の意味を取り違えません。

「平均の平均 ≠ 全体平均」：顧客あたり平均（3000/1500）と注文あたり平均（2000/1000）は一致しません。注文数が顧客ごとに偏るほどズレます。どの単位で平均すべきかは問いの定義で決まります。

アンチパターン

1段階で AVG(amount) と書く：顧客あたり平均のつもりで生の AVG(amount) を使うと、実際は注文あたり平均。注文が多い顧客ほど結果を引っ張ります。まず顧客合計に畳んでから平均しましょう。

集計関数を直接ネストする：AVG(SUM(amount)) のように集計をそのまま入れ子にはできません（構文エラー）。段階を分けるならサブクエリ/CTE、同じ問い合わせ内で重ねたいならウィンドウ関数（次の Q10）を使います。

実務コラム：「○○あたり」を正しく出す

顧客あたり売上(ARPU)、セッションあたり滞在時間、店舗あたり客数——実務の指標の多くは「いったん単位ごとに集計してから、その平均/中央値/分布を見る」二段階です。CTE で段階に名前を付けると、長いクエリも「何を出してから何を出すか」が読み取りやすくなります。小計・総計と組み合わせ、第1段階で顧客合計→第2段階で ROLLUP、のように段階×階層を重ねるのも実務では定番です。

QUESTION 10

構成比 — ウィンドウ集約で各グループの全体シェアを出す

ウィンドウ関数SUM() OVER ()構成比/シェア集計の上の集計

前提知識 ▼

グループ別の合計に「全体の何%か」を併記したい——ウィンドウ関数 SUM(…) OVER () を使うと、GROUP BY の結果行を保ったまま、全体の集計値を各行にブロードキャストできます。サブクエリや結合なしで構成比が1文で出せます。

-- 各グループ合計を、全グループの総計で割る
SUM(amount)                       -- ① GROUP BY 後：このグループの合計
SUM(SUM(amount)) OVER ()           -- ② ①をグループ横断で合計＝総計（全行に同じ値）
100.0 * SUM(amount) / SUM(SUM(amount)) OVER ()  -- ③ 構成比(%)

SUM(SUM(x)) OVER () の二重集計：内側の SUM(amount) は GROUP BY 後の各グループ合計。それを外側のウィンドウ SUM(…) OVER () がグループをまたいで合計し、総計を全行へ配ります。ウィンドウ関数は集計の後段で動くため、集計結果の上にもう一段の集計を重ねられるのです。OVER () は「全行が1つの窓」を意味します。

問題 ▼

sales テーブルから、カテゴリ別の売上合計と、それが全体に占める構成比(%)を求めてください。出力列は category, category_total, pct_of_total（構成比は小数第1位に四捨五入）。category_total の降順、同額なら category の昇順で返してください。

使用テーブル

► sales（5行）

sale_id	category	amount
1	Electronics	4000
2	Electronics	2000
3	Clothing	1500
4	Clothing	500
5	Food	2000

期待出力 ▼

category	category_total	pct_of_total
Electronics	6000	60.0
Clothing	2000	20.0
Food	2000	20.0

模範解答コード ▼

SELECT
  category,
  SUM(amount) AS category_total,                     -- このカテゴリの売上合計
  ROUND(
    100.0 * SUM(amount) / SUM(SUM(amount)) OVER (),  -- 各合計 ÷ 総計 × 100（100.0で整数割り算を回避）
    1
  ) AS pct_of_total                                  -- 構成比(%)を小数第1位に丸め
FROM     sales
GROUP BY category                                    -- カテゴリでグループ化（集計はここで確定）
ORDER BY category_total DESC, category;              -- 合計の大きい順、同額はカテゴリ名の昇順

/*
  実行順序（SQLの論理的な評価順）:
  1. FROM sales                    → 行を読込
  2. GROUP BY category             → カテゴリでグループ化
  3. SUM(amount)                   → カテゴリ合計を集計
  4. SUM(SUM(amount)) OVER ()      → 総計を全行に付与
  5. 100.0 * 合計 / 総計               → 構成比を算出
  6. ORDER BY category_total DESC, category  → 合計の多い順で並べ替え
  */

解説（テーブル変化・ポイント） ▼

SELECT
  category,
  SUM(amount) AS category_total,
  ROUND(
    100.0 * SUM(amount) / SUM(SUM(amount)) OVER (),
    1) AS pct_of_total
FROM     sales
GROUP BY category
ORDER BY category_total DESC, category;

LEGEND ▼

データ取得・読込対象

① FROM sales（5行） ▼

FROM salessales の5行を読み込みます。カテゴリは Electronics/Clothing/Food。まずカテゴリ別に合計し、その合計が全体に占める割合を出します。

1 / 6

sale_id	category	amount
1	Electronics	4000
2	Electronics	2000
3	Clothing	1500
4	Clothing	500
5	Food	2000

5行読込

学習ポイント

ウィンドウ関数は集計結果に値を“併記”する：SUM(...) OVER () は、GROUP BY の結果行を1行も減らさず、全体集計を各行へ付け足します。だから「グループ合計」と「全体総計」を同じ行に並べ、その場で割って構成比を出せます。

SUM(SUM(x)) OVER () は「集計の上の集計」：内側 SUM(amount) はグループ合計、外側のウィンドウ SUM(…) OVER () はそれを横断合計した総計。Q9 ではサブクエリで二段階にした「集計の集計」を、ウィンドウなら1つの SELECT 内で重ねられます。

OVER の中身で粒度を切り替え：OVER () は全体が分母。OVER (PARTITION BY region) にすれば地域内シェア、OVER (ORDER BY …) を足せば累積構成比（パレート図）になります。同じ発想で分母の範囲だけを差し替えられます。

アンチパターン

整数割り算で全部0になる：100 * SUM(amount) / SUM(SUM(amount)) OVER () は整数同士の割り算で小数が切り捨てられ、0 や丸まった値になりがちです。100.0 など数値型を混ぜて割り、ROUND(…, 1) で桁を整えます。

OVER を付け忘れて集約エラー：総計のつもりで SUM(amount) をもう一度書いても、それは同じグループ合計のまま。グループをまたぐ総計にはウィンドウ（OVER）かサブクエリが必要です。素の列を分母に書くと「GROUP BY に無い」エラーになります。

実務コラム：シェア・寄与度・パレート分析

売上構成比、トラフィックのチャネル別シェア、コスト寄与度——「全体に対する割合」はダッシュボードの定番で、SUM(...) OVER () が最短ルートです。累積で見たい ABC 分析（パレート）は SUM(SUM(amount)) OVER (ORDER BY SUM(amount) DESC) で累積構成比を出し、80%ラインを引きます。GROUP BY でグループを作り、ウィンドウでグループ同士を関係づける——この2段構えが、集計レポートの表現力を一気に広げます。