starスキーマとは？意味や仕組みは？（データベース：データウェアハウス：設計など）

データウェアハウスを設計するとき、分析しやすいテーブル構造としてよく使われるのがstarスキーマです。

名前は耳にしたことがあっても、どのテーブルを中央に置くのか、正規化されたデータベースと何が異なるのかまで理解するには、仕組みを順序立てて確認する必要があります。

本記事では、starスキーマの意味、構成要素、設計方法、メリットと注意点をわかりやすく整理します。

starスキーマの意味と全体像

それではまずstarスキーマの意味と全体像について解説していきます。

星形に見えるデータモデル

starスキーマとは、中央に配置したファクトテーブルを複数のディメンションテーブルが囲む、データウェアハウス向けのデータモデルです。

テーブル同士を図として表すと星のような形になるため、スター型スキーマとも呼ばれます。

中心に置かれるファクトテーブルには、売上金額、販売数量、閲覧回数、利用時間など、分析対象となる数値データが保存されます。

周囲のディメンションテーブルには、商品、顧客、店舗、日付、地域、担当者といった、数値を分類するための属性情報を持たせる構造です。

数値の事実を中央に集め、切り口となる属性を周辺に分けることが、starスキーマの基本的な考え方になります。

たとえば月別の商品別売上を確認したい場合、売上という事実はファクトテーブルから取得し、月や商品名はディメンションテーブルから取得します。

分析処理に適した設計思想

業務システムでは、注文登録や在庫更新を正確に処理するため、データを細かく分割した正規化設計が採用されることが少なくありません。

一方で、分析基盤では利用者が大量の履歴データを集計し、比較し、傾向を把握することが主な目的です。

starスキーマは、分析クエリをわかりやすくし、BIツールやSQLで扱いやすくするために考えられた構造といえるでしょう。

売上を日付、地域、商品カテゴリー、顧客層で分析するような場面では、テーブルの役割が明確なほど集計条件を組み立てやすくなります。

利用者がデータベースの複雑な内部構造を深く意識しなくても、必要な指標へ近づきやすい点が特徴です。

ファクトとディメンションの関係

ファクトテーブルとディメンションテーブルは、主キーと外部キーを通じて結び付きます。

ファクトテーブルには日付キー、商品キー、顧客キーなどが入り、それぞれのキーを使って周辺テーブルを参照します。

ただし、設計で最初に決めるべきなのはテーブル名ではなく、ファクトテーブルの一行が何を表すかという粒度です。

一行が一つの注文明細なのか、一日単位の商品別集計なのかによって、保存する数値や必要なキーは大きく変わります。

ファクトテーブルとディメンションテーブルの役割

続いてはファクトテーブルとディメンションテーブルの役割を確認していきます。

ファクトテーブルに保存する情報

ファクトテーブルは、業務上発生した出来事を分析用の数値として記録するテーブルです。

販売分析なら売上数量、単価、値引額、売上金額、原価、利益額などが代表的な項目になります。

Web分析であれば、ページビュー、セッション数、コンバージョン数、滞在時間などを扱うことになるでしょう。

ファクトテーブルは行数が多くなりやすく、数百万行から数億行規模へ成長することもあります。

そのため、列の型、パーティション、インデックス、データ取り込み方法まで含めて検討することが重要です。

ディメンションテーブルに保存する情報

ディメンションテーブルは、ファクトを説明し、集計の軸となる情報を管理するテーブルです。

商品ディメンションなら商品名、ブランド、カテゴリー、サイズ、色、発売日などを保存します。

顧客ディメンションなら会員区分、年代、居住地域、登録経路などが候補になります。

日付ディメンションには年月日だけでなく、曜日、祝日区分、会計年度、四半期、月初月末といった分析に便利な属性を持たせると効果的です。

日付を単なる日付型として扱うだけではなく、分析用の属性を備えたディメンションにすると、レポート作成の手間を減らせます。

売上分析における構成例

売上を対象にしたstarスキーマでは、一つの販売明細をファクトテーブルの一行にする設計が基本例です。

この場合、商品、顧客、店舗、日付、販売チャネルなどのディメンションが周囲に配置されます。

テーブル	主な役割	代表的な項目
売上ファクト	販売実績の保存	数量、売上金額、値引額、商品キー、日付キー
商品ディメンション	商品による分類	商品名、カテゴリー、ブランド、規格
顧客ディメンション	顧客属性による分類	会員区分、年代、地域、登録経路
日付ディメンション	時間軸による分類	年月、曜日、四半期、会計年度
店舗ディメンション	販売場所による分類	店舗名、都道府県、業態、エリア

starスキーマの仕組みとデータ集計

続いてはstarスキーマの仕組みとデータ集計を確認していきます。

キーによるテーブル結合

starスキーマでは、ファクトテーブルが各ディメンションテーブルへの外部キーを持ちます。

たとえば売上ファクトに商品キーがあり、商品ディメンションの主キーと結合することで、商品名やカテゴリーを取得できます。

SQLではファクトテーブルを起点にして必要なディメンションを結合し、条件指定と集計を行う流れが一般的です。

構造が単純なため、どのテーブルを結合すべきか判断しやすく、BIツールのセマンティックモデルにも載せやすい利点があります。

特に複数部門の利用者がセルフサービス分析を行う環境では、テーブルの用途が直感的に伝わる構成が品質と運用効率に影響します。

集計粒度と重複計上の注意点

集計結果を正しく保つには、ファクトの粒度とディメンションの対応関係を理解しなければなりません。

たとえば一つの注文に複数の商品明細がある場合、注文単位の送料を各明細行にそのまま入れると、商品別集計で送料が重複するおそれがあります。

このような場合は、明細ファクトと注文ファクトを分ける、配賦ルールを定めるなど、数値の意味に合わせた設計が必要です。

また、一対多となるディメンションを安易に結合すると、ファクトの行数が増えて合計値が膨らむ場合があります。

集計前後の件数と金額を確認し、想定外の重複がないか検証する姿勢が欠かせません。

BIツールでの利用イメージ

Power BI、Tableau、LookerなどのBIツールでは、ファクトとディメンションの関係を定義してダッシュボードを作成します。

利用者は売上金額を指標として選び、年月やカテゴリーを行列またはフィルターに設定することで、さまざまな角度から比較できます。

前年同月比、店舗別ランキング、顧客層別の購入傾向なども、共通ディメンションを整備しておけば再利用しやすくなります。

同じ日付ディメンションや商品ディメンションを複数のレポートで共有することにより、指標の解釈をそろえやすくなる点も大きな価値です。

データウェアハウスにおける設計手順

続いてはデータウェアハウスにおける設計手順を確認していきます。

業務プロセスの選定

starスキーマの設計は、最初から企業全体のすべてを一つの巨大モデルにまとめようとするより、対象となる業務プロセスを一つ選ぶところから始めます。

販売、出荷、在庫、請求、広告配信、問い合わせ対応など、分析したい業務上の出来事を定めます。

販売を選んだなら、どの時点を売上として記録するのかも明確にする必要があります。

受注時、出荷時、納品時、請求時では数字の意味が異なるため、業務部門と認識を合わせることが大切です。

粒度とディメンションの定義

次に、ファクトテーブルの一行が示す最小単位を決めます。

たとえば一行を一つの注文商品明細と定義すれば、注文日、商品、顧客、店舗、数量、金額を保持できます。

その後、利用者がどの切り口で見たいかを洗い出し、必要なディメンションと属性を設計します。

ここで重要なのは、現在の分析要求だけに閉じず、将来に想定される分類軸もほどよく考慮することです。

分析の質問を先に集めてからテーブルを設計すると、使われない列を増やしすぎず、必要な属性の漏れも防ぎやすくなります。

サロゲートキーと履歴管理

データウェアハウスでは、業務システムの自然キーとは別に、連番などのサロゲートキーをディメンションへ付与する設計がよく採用されます。

商品コードや顧客番号は業務上変更される可能性があり、過去データとの関係を安定して管理するには専用キーが役立ちます。

顧客の住所や会員ランク、商品のカテゴリーが変わった場合、過去の状態を残すか、最新の属性へ置き換えるかも決めなければなりません。

過去の状態を残す方式は緩やかに変化するディメンションとして知られ、履歴を用いた正確な分析に有効です。

starスキーマのメリットと注意点

続いてはstarスキーマのメリットと注意点を確認していきます。

クエリのわかりやすさ

starスキーマの大きなメリットは、分析SQLの構造を比較的単純に保ちやすいことです。

中心のファクトと周囲のディメンションという役割分担が明確で、利用者は必要な切り口を選んで結合できます。

正規化が進みすぎた構造では、商品名を取得するだけでも複数テーブルをたどる必要がある場合があります。

starスキーマでは属性をディメンションにまとめるため、分析者が扱う結合数を抑えられるケースが多いでしょう。

理解しやすさは、分析の速度だけでなく、レポート定義の誤りを減らす効果にもつながります。

性能とストレージのバランス

ディメンションに属性を集約する設計では、正規化された構造より同じ情報が繰り返し保存されることがあります。

そのため、ストレージ使用量の増加や、属性変更時の更新負荷を考慮する必要があります。

ただし、分析用途では読み取りや集計の効率を優先する場面が多く、多少の冗長性が実務上の利点になることもあります。

列指向データベースやクラウド型データウェアハウスを使う場合、圧縮や実行計画によって冗長性の影響が小さくなるケースもあります。

不適切な利用を避ける視点

starスキーマは万能ではなく、すべてのデータを一つの星形へ押し込むと管理しにくくなる場合があります。

異なる粒度の数値を同じファクトに混在させることや、意味の異なる指標を一つの金額列へ集約することは避けるべきです。

また、ディメンションが巨大化し、属性の関係が複雑になる場合は、スノーフレークスキーマや別のモデルを検討する余地もあります。

重要なのは形式に合わせることではなく、利用目的、データ量、更新頻度、利用者の分析方法に合う設計を選ぶことです。

データ品質の定義と更新ルールを文書化することも、長期運用では欠かせません。

まとめ

starスキーマは、中央のファクトテーブルと周囲のディメンションテーブルで構成する、データウェアハウス向けの代表的な設計手法です。

売上やアクセス数などの数値を中心に置き、商品、顧客、日付、地域といった切り口を周囲に配置することで、集計と分析を行いやすくなります。

設計の出発点は、分析したい業務プロセスとファクトの粒度を定めることです。

その上で必要なディメンション、キー、履歴管理、データ更新の方法を整理すれば、利用者にとってわかりやすい分析基盤へ近づきます。

starスキーマはデータを保存する形ではなく、意思決定に使える形へ整えるための考え方として捉えるとよいでしょう。