OLAPとOLTPの違い

二つのワークロードは正反対

同じ「データベースを使う処理」でも、OLTP（Online Transaction Processing、取引系） と OLAP（Online Analytical Processing、分析系） はアクセスパターンが真逆です。ここを取り違えると、本番の取引DBに重い集計クエリを投げてサービスごと詰まらせる、という典型的な事故になります。

OLTPは、注文の確定・在庫の減算・残高の更新のような多数の短いトランザクションです。1件あたりが触るのは主キーで特定した少数の行で、読み書きが混在し、応答は数ミリ秒が期待されます。「今この1件を正しく更新する」が主役なので、点アクセス（point access）と整合性が最優先です。

OLAPは、「先月の地域別・商品カテゴリ別の売上」のような少数の巨大なクエリです。1本が数百万〜数十億行を走査（スキャン）して集約し、更新はほぼ行わず一括ロードで積む。応答は秒〜分でも許容され、代わりにスループット（一度に舐める量）が主役です。

この差は好みではなく物理です。点アクセスに最適な物理レイアウトと、全走査集約に最適なレイアウトは両立しないため、分析系は取引系から別基盤（データウェアハウス／レイクハウス）へ切り出すのが定石になります。DB内部のインデックス構造やトランザクション制御は取引系の関心で、ここでは扱いません（内部原理は/database/側の主題です）。本稿は分析基盤としての設計、すなわちデータのモデリングと物理配置に絞ります。

なぜ取引系スキーマを分析にそのまま使えないのか

OLTPのスキーマは正規化されています。同じ事実を一箇所だけに持ち、更新時の不整合（更新異常）を防ぐためです。顧客・注文・注文明細・商品・カテゴリ…と表が細かく分かれ、外部キーで結ばれる。1件の更新はごく一部の表に閉じるので、正規化は取引系にとって正しい選択です。

ところが分析クエリでは、この正規化が牙をむきます。「地域別・カテゴリ別の売上」を出すだけで、注文明細から商品、商品からカテゴリ、注文から顧客、顧客から地域…と多数の表を結合する羽目になる。結合の数と中間結果の膨張がクエリを重くし、しかも分析者は業務の正規化構造を暗記しないと問い合わせを書けません。

スタースキーマ：ファクトとディメンション

分析基盤の標準形がスタースキーマ（星型スキーマ） です。中心にファクト表（fact table）、その周囲にディメンション表（dimension table） を放射状に配置するのでこの名がつきます。

• ファクト表は、測定したい数値の事実（メジャー） を1行1イベントで持ちます。売上なら「いつ・どの店で・どの商品を・いくつ・いくらで売れたか」の金額や数量です。行数は膨大（億単位もざら）だが、列は「各ディメンションを指す外部キー＋数個のメジャー」と幅は狭い。
• ディメンション表は、事実を切る軸となる属性を持ちます。商品ディメンションなら商品名・カテゴリ・ブランド・仕入先、日付ディメンションなら年・四半期・月・曜日・祝日フラグ。行数は小さい（商品数、日数）が、列は多く記述的です。

              ┌─────────────┐
              │ dim_date    │   ← 年/四半期/月/曜日/祝日…
              └──────┬──────┘
┌─────────────┐   ┌──▼──────────────┐   ┌─────────────┐
│ dim_product ├──►│  fact_sales     │◄──┤ dim_store   │
│ 商品/分類   │   │  (数量, 金額,   │   │ 店舗/地域   │
└─────────────┘   │   各dimへのFK)  │   └─────────────┘
              ┌───┤                 ├───┐
     ┌────────▼─┐ └─────────────────┘ ┌─▼──────────┐
     │dim_customer│                    │dim_promo   │
     └────────────┘                    └────────────┘

分析クエリはいつも同じ形になります。ファクトを対象に、いくつかのディメンションを結合し、ディメンションの属性で絞り込み（WHERE）、別の属性でまとめて（GROUP BY）、メジャーを集約（SUM/COUNT/AVG）する。スタースキーマはこの定型を最短にします。

-- 「2026年Q1・地域別・カテゴリ別の売上合計」の骨格
SELECT   s.region, p.category, SUM(f.amount) AS sales
FROM     fact_sales f
JOIN     dim_store   s ON f.store_id   = s.store_id
JOIN     dim_product p ON f.product_id = p.product_id
JOIN     dim_date    d ON f.date_id    = d.date_id
WHERE    d.year = 2026 AND d.quarter = 1
GROUP BY s.region, p.category

結合はすべて巨大なファクト表 対 小さなディメンション表の形になり、結合の相手が小さいので実行計画が単純で速い。ディメンションを非正規化（カテゴリを別表に切り出さず商品ディメンションに畳み込む）しておけば結合数はさらに減ります。これがスノーフレークスキーマ（ディメンションをさらに正規化した形）よりスタースキーマが好まれる理由です。結合を1段でも減らすほうが、正規化の綺麗さより分析では価値が高い。

集約中心の設計とグレイン

スタースキーマ設計で最初に決めるべきはグレイン（grain、ファクト1行が表す粒度） です。「注文明細1行＝1グレイン」なのか「1日1店舗1商品の集計＝1グレイン」なのか。グレインを細かく取るほど後から自由に集計できるが行数は増える。粗く取れば軽いが、それより細かい問いには答えられません。分析基盤の設計は**「どの粒度まで事実を残すか」の意思決定**であり、集約の自由度とコストのトレードオフです。

よく効くのが事前集約（pre-aggregation） です。日次・月次のようによく使う粒度をあらかじめ集計してサマリー表（マテリアライズドビュー） に持てば、BIの応答が桁で速くなる。素朴なOLAPキューブは、ディメンションの組み合わせごとに合計を先に計算しておく発想の極端形です。ただし事前集約はストレージと再計算コストと引き換えで、元データが更新されたらサマリーも作り直しが要る。「どの集約を実体化し、どれを都度計算するか」は分析基盤の中心的なチューニングになります。

列指向がなぜ分析に効くのか

ここまでの設計（少数列を全行スキャンして集約する）は、物理的な行の並べ方と深く噛み合います。分析基盤が列指向（columnar）ストレージを採るのはこのためです。

• 行指向（row-oriented）：1行の全列を連続してディスクに置く。[行1の全列][行2の全列]…。1件の全項目をまとめて読み書きする点アクセス、つまりOLTPに向く。
• 列指向（column-oriented）：同じ列の値を全行ぶん連続して置く。[全行のamount][全行のqty][全行のdate_id]…。特定の列だけを舐める集約、つまりOLAPに向く。

分析クエリが SUM(amount) を求めるとき、行指向だと各行の全列をディスクから読み込んで amount 以外を捨てることになります。ファクト表が数十列あって使うのが2〜3列なら、大半のI/Oが無駄です。列指向なら必要な列のブロックだけを読むので、I/O量が「使う列の割合」まで落ちます。これが列プルーニング（column pruning）で、スキャン主体のワークロードに直接効きます。

逆に、なぜOLTPで列指向を使わないかも同じ理屈です。1行を挿入するのに全列のブロックへ書き分ける必要があり、1行更新も列ごとに分散した位置を触る。点書き込みの多い取引系では行指向が有利で、列指向は「一括ロード＋読み取り主体」を前提にして初めて勝てる。近年のHTAP（取引と分析の融合）は、書き込みは行指向で受け、バックグラウンドで列指向へ変換する二層構成でこの矛盾を回避しますが、根っこにあるのは本稿のOLTP／OLAP物理差そのものです。

まとめ

• OLTPは点アクセス・書き込み・低レイテンシ、OLAPはスキャン・集約・高スループットでアクセスパターンが正反対。物理レイアウトが両立しないため、分析系は取引系DBから別基盤に切り出すのが原則。
• 取引系は正規化で書き込み整合性を守るが、分析ではその構造が結合地獄を生む。分析基盤は非正規化して読み取りを最適化する。
• 標準形はスタースキーマ。数値の事実を持つ巨大なファクト表を、属性軸を持つ小さなディメンション表が囲み、分析クエリを「フィルタ→グループ化→集約」の定型に落とす。
• 設計の起点はグレインの決定で、集約の自由度とコストのトレードオフ。よく使う粒度は事前集約（サマリー表） で応答を稼ぐ。
• 「少数列を全行スキャン」する分析には列指向が本質的に合う。列プルーニングでI/Oを削り、同種の値の隣接で高圧縮とベクトル化が効く。集約中心の設計と列指向は相互に噛み合う。