データ活用入門：BIツールの「キューブ」とは？リレーショナルデータベースとの関係からざっくり理解する

はじめに

BIツールに触れると、「キューブ」という言葉が出てきます。多次元分析、ディメンション、メジャー、OLAP。
リレーショナルデータベースを触ったことがあっても、データ分析の入り口では、こうした新しい言葉に次々と出会うことになります。

この記事は、キューブがどういうものか、そしてリレーショナルデータベース（RDB）とどういう関係にあるのかを整理したものです。 特定の製品の操作方法ではなく、どのBIツールにも共通する考え方の部分を扱います。

データベースの経験が少ない方でも読み進められるよう、Excelの集計表の話から始めています。 データ活用の用語を押さえるきっかけとして、少しでも参考になれば嬉しいです。

ざっくりまとめ

先に要点をまとめます。

• キューブは、売上のような数値を「商品×店舗×月」など複数の切り口の組み合わせで事前に集計して持っておくデータ構造。BIツールの多次元分析を支えてきた仕組み
• RDBとは競合ではなく分業の関係。RDBが元データの置き場、キューブはそこから作られる分析用の派生物
• RDBの側で多次元分析に向けた設計をする定番がスタースキーマ。集計済みデータをどこに持つかの違いがMOLAP／ROLAP／HOLAP
• 最近の分析基盤ではキューブそのものを構築する場面は減ったが、ディメンションやメジャーといった考え方は今もBIツールの土台になっている

キューブとは何か

■ クロス集計表を積み重ねる

Excelでよく作るクロス集計表（ピボットテーブル）で考えます。 行に商品、列に月を置いて、交わるマスに売上金額を集計する。 この表の軸は「商品」と「月」の2本です。

ここで「店舗ごとの違いも見たい」となると、Excelでは店舗の数だけ同じ表を作ることになります。 この「同じ形のクロス集計表を、店舗の数だけ積み重ねた束」を、まるごと1つのデータ構造として扱えるようにしたものが、キューブのイメージです。 軸が商品、月、店舗の3本になり、図に描くと立方体になるため、キューブ（cube：立方体）と呼ばれています。

（軸は3本とは限りません。4本以上でも同じ考え方で扱えます。この点は後半の「よくある誤解」で扱います。）

■ ディメンションとメジャー

キューブでは、この「軸」と「集計されるマスの数値」に名前が付いています。

• ディメンション：分析の切り口になる軸。商品、店舗、時間など
• メジャー：集計対象の数値。売上金額、販売数量など

BIツールの画面で「切り口をドラッグして、集計したい数値を選ぶ」という操作は、このディメンションとメジャーを選んでいます。

また、ディメンションには階層を持たせられます。 時間なら年、四半期、月、日。商品ならカテゴリ、商品名。 この階層が、次の操作で効いてきます。

■ キューブの代表的な操作

• ドリルダウン／ロールアップ — 年→四半期→月のように、階層に沿って粒度を細かくする／粗く戻す
• スライス — 1つのディメンションを特定の値で固定して、断面を切り出す（「2025年度」だけの商品×店舗の表）
• ダイス — 複数のディメンションを条件で絞って、小さなキューブを切り出す
• ピボット — 行と列の軸を入れ替えて、見る向きを変える

いずれも、ピボットテーブルで普段からやっている操作に対応します。 キューブは、この操作を大量のデータに対しても即座に返せるようにしたものです。 では、なぜ即座に返せるのか。キューブが生まれた背景から見ていきます。

なぜキューブが生まれたのか

■ RDBが得意な処理

リレーショナルデータベース（RDB）は、データを行と列の表で管理し、SQLで操作するデータベースです。 業務システムの裏側では、注文を1件登録する、在庫を1件更新する、といった処理が絶え間なく走っています。 このような、少量のデータを確実に読み書きする処理をOLTP（Online Transaction Processing：オンライントランザクション処理）と呼びます。 RDBは、この用途を中心に発展してきました。

■ 分析のクエリは性質が違う

一方、データ活用で投げたい問いは性質が違います。 「過去3年の売上を、商品カテゴリ別、地域別、月別に集計したい」。 SQLで書くと、例えば次のようになります。

SELECT p.category, s.region, c.year_month,
       SUM(f.sales_amount) AS total_sales
FROM sales f
JOIN products p ON f.product_id = p.product_id
JOIN stores   s ON f.store_id   = s.store_id
JOIN calendar c ON f.date_id    = c.date_id
GROUP BY p.category, s.region, c.year_month;

クエリ自体は普通のSQLです。 問題は読む量で、売上明細が数千万行あれば、集計のたびにそのほぼ全体を読み直すことになります。 切り口を変えるたびに、数十秒から数分を待つことになる。 しかも業務システムと同じデータベースに投げれば、注文登録などの本来の処理と資源を奪い合います。 このような、大量のデータをまとめて読んで集計する処理はOLAP（Online Analytical Processing：オンライン分析処理）と呼ばれ1、OLTPとは求められる性能の方向が異なります。

■ 答えを事前に用意しておく

そこで1990年代に広まったのが、「よく使う集計は、あらかじめ計算して別の場所に持っておく」 という考え方です。 商品カテゴリ×地域×月の全組み合わせについて、売上の合計を夜間バッチなどで先に計算しておく。 分析者がドリルダウンやスライスで切り口を変えても、返ってくるのは計算済みの値なので、待ち時間はほとんど発生しません。 この事前に集計された多次元のデータが、キューブの実体です。 キューブを格納して提供する専用のデータベースは、多次元データベースと呼ばれます。

（用語を整理しておくと、OLAPは「分析のための集計処理」という処理の性質を指す言葉で、キューブはOLAPを高速化するための代表的な実装です。両者はイコールではありません。）

キューブが何であるかと、生まれた理由を押さえました。 次に、このキューブとRDBのつながりを整理します。

リレーショナルデータベースとの関係

キューブとRDBの関係は、主に次の3つの面から整理できます。

■ 1：元データはRDBにある

キューブは、それ単体で成立するものではありません。 元になるのは、業務システムのRDBやデータウェアハウスに蓄積されたデータです。 そこから必要な列を取り出し、集計して、キューブを作ります。 この処理は夜間バッチなどで定期的に実行され、元データが更新されればキューブも作り直されます。

つまり、RDBが記録の置き場、キューブが分析のための派生物という役割分担です。

■ 2：RDBの表で多次元を表現する（スタースキーマ）

多次元の考え方は、専用のデータベースがなくてもRDBの表で表現できます。 その定番の設計がスタースキーマです。

• ファクトテーブル — メジャー（売上金額、数量）と、各ディメンションへの参照を持つ表。行数が多い
• ディメンションテーブル — 商品、店舗、日付といった切り口の情報を持つ表。行数は少ない

先ほどのSQLの例に出てきたテーブルが、ちょうどこの形です。 salesがファクトテーブル、products、stores、calendarがディメンションテーブルにあたります。

salesの中身は、例えばこのような明細の集まりです。

date_id	store_id	product_id	sales_amount	quantity
20250701	S001	P010	12,800	4
20250701	S002	P023	3,200	1
20250702	S001	P023	6,400	2

productsは、商品IDを商品名やカテゴリに読み替えるための表です。

product_id	product_name	category
P010	緑茶500ml	飲料
P023	チョコレート	菓子

ファクトテーブルを中心に、ディメンションテーブルが放射状につながる形を図に描くと星のように見えるため、スタースキーマと呼ばれます。

キューブの設計図を、RDBの語彙で書き直したものがスタースキーマだと言えます。

■ 3：集計済みデータをどこに置くか（MOLAP／ROLAP／HOLAP）

BI製品がキューブを実現する方式は、集計済みデータをどこに持つかで分かれます。

方式	集計済みデータの置き場	応答速度	データの鮮度
MOLAP（Multidimensional OLAP）	専用の多次元データベース	速い	バッチ更新の分だけ遅れる
ROLAP（Relational OLAP）	持たない。操作のたびにRDBへSQLを発行して集計する	RDBの性能に依存	常に最新
HOLAP（Hybrid OLAP）	集計値だけ多次元データベースに持ち、明細はRDBに残す	中間	中間

「キューブを構築する」と言うとき、狭い意味ではMOLAP方式を指しています。 主な製品には、Microsoft SQL Server Analysis Services（多次元モデル）やOracle Essbaseがあります。 一方でROLAPは、スタースキーマで設計したRDBそのものをキューブに見立てる方式で、独立した「キューブ」というデータは存在しません。

BIツールの画面から見ると、どの方式でも「ディメンションを選んでメジャーを集計する」という操作は同じです。 違うのは、その裏側で答えがどこから来るかだけです。

よくある誤解

■ 誤解1：「キューブは3次元まで」

図が立方体で描かれるため3次元の印象がありますが、ディメンションは4本以上でも扱えます。 その場合もキューブと呼ばれます（区別してハイパーキューブと呼ぶこともあります）。 3次元を超えると図には描けないため、説明用の絵が立方体になっているだけです。

■ 誤解2：「キューブがあればRDBは要らない」

両者は競合ではなく分業の関係です。 記録（1件ずつの確実な読み書き）はRDB、分析（大量の集計）はキューブと、担当する仕事が違います。 また、関係1で見たとおり、キューブの中身はRDB側のデータから作られます。 元データなしにキューブだけが存在することはありません。

■ 誤解3：「Excelのピボットテーブルと同じもの」

操作の考え方は同じですが、仕組みが違います。 ピボットテーブルは、手元のデータをその場で集計します。 データ量が増えると動作が重くなり、扱える行数にも上限があります。 キューブは、サーバー側で事前に集計した結果を返します。 元データが数億行あっても、画面の応答速度は保たれます。 「ピボットテーブルの操作感を、業務データの規模で成立させるための仕組み」と押さえておくと、両者の関係を説明しやすくなります。

■ 誤解4：「BIツールを使う＝キューブを使っている」

キューブは、BIツールを支える方式のひとつであって、必須の部品ではありません。 現在のBIツールには、キューブを介さずにデータベースへ直接クエリを発行するものが多くあります。 この事情を次の章で扱います。

今のBIツールとキューブ

ここまでキューブの仕組みを説明してきましたが、正直に書いておくと、新しく作る分析基盤で「キューブを構築する」工程は減っています。

背景にあるのは、データベース側の進化です。

• 列指向ストレージ — 分析専用のデータベース（クラウドのデータウェアハウスなど）は、データを列単位で格納する。集計に必要な列だけを読めばよいので、事前集計がなくても大量データのGROUP BYが実用的な速度で返る
• 計算資源の分離 — クラウドでは、分析用のデータベースを業務システムと分けて用意し、必要なときだけ計算資源を増やせる。「業務処理と資源を奪い合う」問題が起こりにくくなった

かつてキューブが解決していた「集計が遅い」「業務と資源を奪い合う」という問題の多くを、データウェアハウス自体が解決するようになりました。 現在のBIツール（Power BI、Tableauなど）は、データウェアハウスへ直接クエリを発行するか、ツール内蔵の列指向エンジンにデータを取り込む方式が中心で、どちらもキューブを別途構築する工程を必要としません。

キューブ側の維持の手間も、この流れを後押ししました。 例えばカテゴリ10種×店舗50×36ヶ月でも組み合わせは18,000マスあり、ディメンションや階層を足すたびに掛け算で増えていきます。 どの切り口を事前集計に含めるかの設計と、元データが変わるたびの再計算が運用の負荷になり、「切り口を後から自由に変えたい」というセルフサービスBIの流れとは相性がよくありませんでした。

一方で、キューブが持っていた考え方は今も残っています。

• ディメンションとメジャー — BIツールの画面はこの2分類のまま設計されている。フィールドをドラッグして集計する操作は、キューブ時代の語彙で動いている
• スタースキーマ — データウェアハウスのテーブル設計の定番であり続けている
• 事前集計 — マテリアライズドビューやBIツールの集計テーブル機能として、「よく使う集計を先に計算しておく」という発想は使われ続けている
• セマンティックレイヤー — 「売上とはどの数値をどう合計した値か」といった指標の定義を一元管理する層。キューブが担っていた役割の一部を引き継いでいる

また、MOLAP型の製品が現役の領域もあります。 財務や予算管理の分野では、集計値の整合性が重視されることに加えて、計画値をセルに書き戻す使い方（ライトバック）があるため、Essbaseのような多次元データベースが使われ続けています。

まとめ

キューブとRDBの関係を、用語の対応で整理します。

キューブ側の用語	RDB側の対応物
メジャー	ファクトテーブルの数値列（sales_amountなど）
ディメンション	ディメンションテーブル（products、storesなど）
ドリルダウン	GROUP BYに使う列を、階層に沿って細かい粒度に変えること
キューブ本体	スタースキーマのデータを事前集計して作る派生データ

キューブという部品そのものを構築する場面は、今後も減っていくかもしれません。 それでも、ディメンションとメジャーでデータを捉える見方は、BIツールを使う限り日常的に触れることになります。 データ活用に取り組む際の足がかりになれば幸いです。

参考

一次情報：

• パーティション ストレージ モードと処理（Microsoft Learn） — MOLAP／ROLAP／HOLAPの定義
• Star Schema OLAP Cube（Kimball Group） — スタースキーマとキューブの関係
• OLAP（オンライン分析処理）とは（IBM）

読み物：

• The Rise and Fall of the OLAP Cube（Holistics） — キューブが使われなくなっていった経緯
• OLAPキューブ（Wikipedia）

Footnotes

1. 「OLAP」という言葉は、リレーショナルモデルの提唱者であるE.F. Coddが1993年のホワイトペーパー「Providing OLAP to User-Analysts: An IT Mandate」で提唱したものです。RDBの生みの親が、分析用途には別のアプローチが必要だと論じたことになります。 ↩