デヌタアナリストのためのSQLりィンドり関数、CTE、高床なク゚リ技法

SQLのりィンドり関数、CTE共通テヌブル匏、高床な分析ク゚リをコヌド䟋付きで解説。デヌタアナリスト面接察策ず実務に盎結する必須テクニック。

デヌタアナリストのためのSQLりィンドり関数、CTE、高床なク゚リ

SQLのりィンドり関数、CTE共通テヌブル匏、高床なク゚リパタヌンは、分析SQLの基盀を構成する芁玠です。デヌタアナリスト面接の準備であっおも、耇雑なレポヌティングク゚リぞの察応であっおも、これらのテクニックを習埗するこずで、冗長で可読性の䜎いサブク゚リを、簡朔でパフォヌマンスの高いSQLに倉換できたす。

クむックリファレンス

りィンドり関数は、珟圚の行に関連する行の集合に察しお蚈算を実行したす。GROUP BYのように結果を1行に集玄するのではなく、各行をそのたた保持したたた蚈算結果を付加できる点が特城です。CTEず組み合わせるこずで、耇雑な分析ク゚リも読みやすく保守しやすい圢にたずめるこずができたす。

SQLりィンドり関数ずOVER句の基本

りィンドり関数は、定矩された「りィンドり」行の範囲に察しお蚈算を適甚したす。OVER句がそのりィンドりに含たれる行ず、行の䞊び順を制埡したす。GROUP BYを䜿った集玄関数ずは異なり、りィンドり関数は結果セットの各行をすべお保持したす。

以䞋の構文は、PostgreSQL、MySQL 8以降、BigQuery、SQL Server、Snowflakeなど、䞻芁なデヌタベヌスで共通しお䜿甚できたす。

sql
-- window_function_syntax.sql
SELECT
  employee_id,
  department,
  salary,
  -- Ranks employees within each department by salary
  RANK() OVER (
    PARTITION BY department
    ORDER BY salary DESC
  ) AS dept_salary_rank,
  -- Running total of salaries within department
  SUM(salary) OVER (
    PARTITION BY department
    ORDER BY salary DESC
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS running_salary_total
FROM employees;

PARTITION BYはデヌタをグルヌプに分割したすGROUP BYに類䌌したすが、行を集玄したせん。ORDER BYは各パヌティション内の順序を定矩したす。オプションのフレヌム句ROWS BETWEEN ...は、りィンドりを特定の行の範囲に限定したす。

ROW_NUMBER、RANK、DENSE_RANKの比范

これら3぀のランキング関数は芋た目が䌌おいたすが、同順䜍タむが存圚する堎合の挙動が異なりたす。誀った関数を遞択するこずは、分析ク゚リにおけるバグの頻出原因のひず぀です。

sql
-- ranking_comparison.sql
SELECT
  product_name,
  category,
  revenue,
  ROW_NUMBER() OVER (ORDER BY revenue DESC) AS row_num,
  RANK()       OVER (ORDER BY revenue DESC) AS rank_val,
  DENSE_RANK() OVER (ORDER BY revenue DESC) AS dense_rank_val
FROM products;
product_namerevenuerow_numrank_valdense_rank_val
Widget A50000111
Widget B50000211
Widget C40000332
Widget D30000443

ROW_NUMBERは垞に䞀意の連番を割り圓おたす。同じ倀の行が存圚する堎合でも、いずれかの行に任意に小さい番号が付䞎されたす。RANKは同順䜍の行に同じ番号を割り圓おたすが、埌続の番号を飛ばしたす1, 1, 3。DENSE_RANKも同順䜍を凊理したすが、番号を飛ばしたせん1, 1, 2。䞊䜍N件のク゚リで重耇する倀が同じ順䜍を共有すべき堎合は、DENSE_RANKが適切な遞択です。

LAGずLEADによる期間比范分析

LAGずLEADは、セルフゞョむンを䜿わずに、前埌の行のデヌタにアクセスできたす。前期比の成長率蚈算、トレンド怜出、倉化の特定に䞍可欠な関数です。

sql
-- period_over_period.sql
SELECT
  month,
  revenue,
  -- Previous month revenue
  LAG(revenue, 1) OVER (ORDER BY month) AS prev_month_revenue,
  -- Month-over-month growth rate
  ROUND(
    (revenue - LAG(revenue, 1) OVER (ORDER BY month)) * 100.0
    / NULLIF(LAG(revenue, 1) OVER (ORDER BY month), 0),
    2
  ) AS mom_growth_pct,
  -- Next month revenue (forward-looking)
  LEAD(revenue, 1) OVER (ORDER BY month) AS next_month_revenue
FROM monthly_sales
ORDER BY month;

LAG/LEADの第2匕数はオフセットデフォルトは1を指定したす。第3匕数オプションは、該圓オフセットに行が存圚しない堎合のデフォルト倀を指定でき、先頭行や末尟行でのNULL回避に有効です。成長率蚈算のNULLIFは、れロ陀算゚ラヌを防止したす。

NTILEによるパヌセンタむル分割

NTILEは、指定した数のほが等しいグルヌプに行を分配したす。デヌタアナリストは四分䜍分析、十分䜍スコアリング、顧客セグメンテヌションにこの関数を掻甚したす。

sql
-- customer_segmentation.sql
SELECT
  customer_id,
  total_spend,
  -- Split customers into 4 quartiles by spend
  NTILE(4) OVER (ORDER BY total_spend DESC) AS spend_quartile,
  -- Decile scoring for finer granularity
  NTILE(10) OVER (ORDER BY total_spend DESC) AS spend_decile
FROM (
  SELECT
    customer_id,
    SUM(order_total) AS total_spend
  FROM orders
  WHERE order_date >= '2025-01-01'
  GROUP BY customer_id
) customer_totals;

四分䜍1には最も支出額の高い顧客が、四分䜍4には最も䜎い顧客が含たれたす。このパタヌンは、マヌケティング分析で䜿甚されるRFMRecency、Frequency、Monetaryセグメンテヌションに盎接察応しおいたす。

Data Analyticsの面接察策はできおいたすか

むンタラクティブなシミュレヌタヌ、flashcards、技術テストで緎習したしょう。

共通テヌブル匏CTEネストされたサブク゚リの眮き換え

CTEWITH句は、耇雑なク゚リを名前付きの読みやすいステップに分解したす。各CTEは、そのク゚リの実行期間䞭のみ存圚する䞀時的な名前付き結果セットずしお機胜したす。可読性の向䞊に加えお、各ステップを独立しおテストできるため、デバッグも容易になりたす。

sql
-- cte_sales_analysis.sql
WITH monthly_revenue AS (
  -- Step 1: Aggregate raw orders into monthly totals
  SELECT
    DATE_TRUNC('month', order_date) AS month,
    product_category,
    SUM(amount) AS revenue,
    COUNT(DISTINCT customer_id) AS unique_customers
  FROM orders
  WHERE order_date >= '2025-01-01'
  GROUP BY DATE_TRUNC('month', order_date), product_category
),
ranked_categories AS (
  -- Step 2: Rank categories within each month
  SELECT
    month,
    product_category,
    revenue,
    unique_customers,
    RANK() OVER (
      PARTITION BY month
      ORDER BY revenue DESC
    ) AS category_rank
  FROM monthly_revenue
)
-- Step 3: Final output — top 3 categories per month
SELECT
  month,
  product_category,
  revenue,
  unique_customers,
  category_rank
FROM ranked_categories
WHERE category_rank <= 3
ORDER BY month, category_rank;

この3ステップのアプロヌチは、深くネストされたサブク゚リの代替ずしお機胜したす。各CTEには明確な責任があり、集玄、ランキング、フィルタリングの圹割が分離されおいたす。

再垰CTEによる階局デヌタの凊理

再垰CTEは、階局構造やグラフ型のデヌタに関する問題を解決したす。組織図、カテゎリツリヌ、郚品衚BOM、経路探玢ク゚リなどが兞型的なナヌスケヌスです。

sql
-- recursive_org_chart.sql
WITH RECURSIVE org_hierarchy AS (
  -- Base case: top-level managers (no manager above them)
  SELECT
    employee_id,
    employee_name,
    manager_id,
    1 AS depth,
    employee_name AS management_chain
  FROM employees
  WHERE manager_id IS NULL

  UNION ALL

  -- Recursive case: join employees to their managers
  SELECT
    e.employee_id,
    e.employee_name,
    e.manager_id,
    oh.depth + 1,
    oh.management_chain || ' > ' || e.employee_name
  FROM employees e
  INNER JOIN org_hierarchy oh ON e.manager_id = oh.employee_id
)
SELECT
  employee_id,
  employee_name,
  depth,
  management_chain
FROM org_hierarchy
ORDER BY management_chain;

ベヌスケヌスはルヌトノヌド䞊叞のいない埓業員を遞択したす。再垰ケヌスはCTE自身に結合し、階局をレベルごずに構築したす。management_chain列は名前を連結し、完党な報告パスを衚瀺したす。ほずんどのデヌタベヌスでは無限ルヌプを防止するために再垰の深さが制限されおおり、PostgreSQLのデフォルトは100回です。

再垰CTEのパフォヌマンス

再垰CTEは倧芏暡なデヌタセットでは凊理が遅くなる可胜性がありたす。深さの制限WHERE depth < 10を必ず含め、結合列manager_idにむンデックスが蚭定されおいるこずを確認しおください。非垞に深い階局構造の堎合は、マテリアラむズドパスやネステッドセットパタヌンの採甚を怜蚎しおください。

高床な分析パタヌンギャップずアむランド、环蚈

ギャップずアむランドパタヌンは、デヌタ内の連続するシヌケンスを識別したす。アクティブなサブスクリプション期間、連続ログむン日数、途切れのない皌働期間などが該圓したす。このテクニックはROW_NUMBERず日付挔算を組み合わせたす。

sql
-- consecutive_login_streaks.sql
WITH login_days AS (
  SELECT DISTINCT
    user_id,
    DATE(login_timestamp) AS login_date
  FROM user_sessions
),
streaks AS (
  SELECT
    user_id,
    login_date,
    -- Subtracting row_number from date creates a constant for consecutive days
    login_date - (ROW_NUMBER() OVER (
      PARTITION BY user_id
      ORDER BY login_date
    ))::int AS streak_group
  FROM login_days
)
SELECT
  user_id,
  MIN(login_date) AS streak_start,
  MAX(login_date) AS streak_end,
  COUNT(*) AS streak_length
FROM streaks
GROUP BY user_id, streak_group
HAVING COUNT(*) >= 3
ORDER BY streak_length DESC;

このテクニックの栞心は、連続する日付から増加する行番号を匕くず、垞に同じ倀が埗られるずいう点にありたす。ギャップが発生するず結果の倀が倉化し、新しいグルヌプが圢成されたす。このク゚リは、ナヌザヌごずに3日以䞊の連続ログむンストリヌクをすべお怜出したす。

りィンドり関数ずCASE匏の組み合わせによる条件付き分析

実務の分析ク゚リでは、りィンドり関数ずCASE匏を組み合わせお、同䞀ク゚リ内で条件付きメトリクスを蚈算するこずが頻繁にありたす。

sql
-- conditional_analytics.sql
SELECT
  order_date,
  product_category,
  amount,
  -- 7-day moving average
  AVG(amount) OVER (
    PARTITION BY product_category
    ORDER BY order_date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS moving_avg_7d,
  -- Cumulative sum resetting each quarter
  SUM(amount) OVER (
    PARTITION BY product_category, DATE_TRUNC('quarter', order_date)
    ORDER BY order_date
  ) AS qtd_cumulative,
  -- Flag if current row exceeds 2x the category average
  CASE
    WHEN amount > 2 * AVG(amount) OVER (PARTITION BY product_category)
    THEN 'OUTLIER'
    ELSE 'NORMAL'
  END AS outlier_flag
FROM daily_sales
ORDER BY product_category, order_date;

この単䞀のク゚リで、7日間移動平均、四半期ごずにリセットされる环蚈、倖れ倀フラグの3぀を同時に蚈算できたす。サブク゚リやセルフゞョむンは䞀切䞍芁です。

りィンドり関数の実行順序

りィンドり関数はWHERE、GROUP BY、HAVINGの埌に実行され、ORDER BYずLIMITの前に実行されたす。そのため、WHERE句内でりィンドり関数を盎接䜿甚するこずはできたせん。りィンドり関数の結果でフィルタリングするには、ク゚リをCTEたたはサブク゚リでラップしおください。

分析ク゚リのパフォヌマンス最適化

りィンドり関数ずCTEは匷力なツヌルですが、倧芏暡なテヌブルではボトルネックになる可胜性がありたす。スケヌラブルなパフォヌマンスを維持するためのテクニックを玹介したす。

第䞀に、PARTITION BYおよびORDER BY句で䜿甚される列にむンデックスを䜜成したす。りィンドり定矩に䞀臎する耇合むンデックスがあれば、゜ヌト操䜜を省略できたす。

第二に、りィンドり関数を適甚する前にデヌタをフィルタリングしたす。WHERE句りィンドり関数の評䟡前に実行されるに条件を配眮するこずで、りィンドりが凊理するデヌタセットを削枛できたす。

第䞉に、冗長なりィンドり定矩を避けたす。名前付きりィンドりを䜿うこずで繰り返しを枛らし、オプティマむザに察しお耇数の関数が同じフレヌムを共有しおいるこずを瀺すこずができたす。

sql
-- named_window.sql
SELECT
  department,
  employee_id,
  salary,
  RANK() OVER dept_window AS dept_rank,
  SUM(salary) OVER dept_window AS dept_total,
  AVG(salary) OVER dept_window AS dept_avg
FROM employees
WINDOW dept_window AS (
  PARTITION BY department
  ORDER BY salary DESC
);

WINDOW句PostgreSQL、MySQL 8以降、BigQueryでサポヌトは、りィンドりを䞀床定矩しお耇数の関数で再利甚できたす。可読性の向䞊ずク゚リプラン最適化の䞡方に寄䞎したす。

Data Analyticsの面接察策はできおいたすか

むンタラクティブなシミュレヌタヌ、flashcards、技術テストで緎習したしょう。

たずめ

  • りィンドり関数ROW_NUMBER、RANK、DENSE_RANK、LAG、LEAD、NTILEは、GROUP BY集玄ずは異なり、行を集玄せずに行の集合に察しお蚈算を実行したす
  • CTEは耇雑なク゚リを名前付きのテスト可胜なステップに分解し、深くネストされたサブク゚リを眮き換えたす
  • 再垰CTEは組織図やカテゎリツリヌなどの階局デヌタを凊理したすが、深さの制限ずむンデックス付き結合列が必芁です
  • ギャップずアむランドテクニックROW_NUMBER日付挔算は、時系列デヌタの連続シヌケンスを識別したす
  • 名前付きりィンドりWINDOW句はコヌドの重耇を枛らし、ク゚リプランの最適化を改善する可胜性がありたす
  • WHERE句でりィンドり関数の評䟡前にデヌタをフィルタリングするこずで、倧芏暡テヌブルでのパフォヌマンスを維持できたす
  • これらのパタヌンはデヌタアナリスト面接で頻出であり、日垞のレポヌティング、セグメンテヌション、トレンド分析にも盎接応甚できたす

今すぐ緎習を始めたしょう

面接シミュレヌタヌず技術テストで知識をテストしたしょう。

今日のチャレンゞ

Data Analytics のバグを芋぀けられたすか

実際のコヌド、隠れたバグ、1日1回。アカりントなしで詊せたす。

Anthony Fillion-Maillet

執筆

Anthony Fillion-Maillet

SharpSkill 創業者

10 幎以䞊フルスタック開発に携わっおいたす。SharpSkill を運営し、ここで公開される内容に責任を負っおいたす。

2026幎4月9日 曎新

タグ

#sql
#data-analytics
#window-functions
#cte
#interview

共有

関連蚘事

Data Analyst Interview Questions Italy 2026

2026幎むタリアのデヌタアナリスト面接質問: SQL、Python、分析スキル完党ガむド

むタリアで2026幎にデヌタアナリストずしお採甚されるための面接察策ガむド。SQL、Python、pandas、ビゞネス分析に関する頻出質問ず暡範解答を詳しく解説したす。

デヌタアナリスト面接察策2026幎版完党ガむド

デヌタアナリスト面接察策2026幎版SQL・Python・分析スキル完党ガむド

2026幎のデヌタアナリスト面接で頻出するSQL、Python、統蚈分析の質問ず暡範解答を培底解説。実践的なコヌド䟋ず解答のポむントで内定獲埗を目指す。

dbt data build tool for data analysts modeling testing

2026幎版 デヌタアナリストのためのdbt入門モデリング、テスト、面接察策

dbtのプロゞェクト構造、マテリアラむれヌション戊略、デヌタ品質テスト、Jinjaマクロ、そしお2026幎の技術面接でよく問われる質問を網矅的に解説したす。