スタースキーマ(星型スキーマ)とは
スタースキーマは、
データウェアハウスにおける最も基本的なスキーマの一つで、その構造が星のように見えることから、このように呼ばれます。このスキーマは、データ分析を効率的に行うために設計されており、特に大規模なデータセットを扱う際にその効果を発揮します。
構造
スタースキーマは、中心となる「ファクト表」と、それを取り囲む複数の「ディメンション表」で構成されます。
ファクト表:
データウェアハウスの分析対象となる主要なデータを格納します。
売上データ、取引データなど、数値データや集計対象となるデータが含まれます。
複数のディメンションによって分類されるデータが集約されます。
通常、複合キーを持ち、関連するディメンション表への外部キーを含みます。
ディメンション表:
ファクト表のデータを分類・分析するための属性データを格納します。
時間、場所、製品、顧客などの情報を保持します。
各ディメンションの一意な値を持ち、ファクト表との結合に使用されます。
通常、
主キーを持ち、冗長なデータを含むことがあります。
特徴
単純さと理解のしやすさ
構造がシンプルであるため、設計や実装が容易です。
データモデルを理解しやすく、ビジネスユーザーにも扱いやすいです。
クエリの効率性
ファクト表とディメンション表の間の結合が比較的単純であるため、クエリの実行速度が速くなります。
データ分析に必要な情報を効率的に取得できます。
多次元分析に適している
ディメンションを軸とした多角的な分析を容易に行えます。
OLAP(オンライン分析処理)ツールとの連携がスムーズです。
リレーショナルデータベースとの親和性
標準的なリレーショナルデータベース(RDBMS)で実装できるため、既存のインフラを活用できます。
専用の多次元データベースと比較して、導入コストを抑えることが可能です。
正規化について
ディメンション表:
第二正規形(2NF)に留めることが多いです。
冗長なデータを含むことで、クエリのパフォーマンスを向上させることができます。
ファクト表:
第三正規形(3NF)を用いることが一般的です。
データの重複を避け、データの整合性を保つことを目的とします。
具体例
例えば、小売店の売上管理システムを考えます。この場合、以下の要素が考えられます。
ファクト表 (Fact_Sales):
売上データ(売上日、店舗ID、商品ID、販売数量など)を格納します。
複合キーとして、Date_Id, Store_Id, Product_Idを持ちます。
ディメンション表 (Dim_Date):
日付に関する情報(日付ID、年、月、日など)を格納します。
主キーとして、Date_Idを持ちます。
ディメンション表 (Dim_Store):
店舗に関する情報(店舗ID、店舗名、所在地など)を格納します。
主キーとして、Store_Idを持ちます。
ディメンション表 (Dim_Product):
商品に関する情報(商品ID、商品名、ブランド、カテゴリなど)を格納します。
主キーとして、Product_Idを持ちます。
この例では、ファクト表の各レコードは、対応するディメンション表のレコードと結合することで、詳細な分析が可能になります。例えば、「1997年のテレビの販売数」をブランドや国別に集計するなど、多角的な分析が可能です。
スノーフレークスキーマとの比較
スタースキーマは、スノーフレークスキーマの一種です。スノーフレークスキーマは、ディメンション表がさらに正規化され、複数のテーブルに分割される点が異なります。スタースキーマは、スノーフレークスキーマに比べて、クエリが単純になりやすく、パフォーマンスも高い傾向があります。しかし、ディメンション表が大きくなる可能性があり、データ更新の際に冗長性を考慮する必要もあります。
まとめ
スタースキーマは、
データウェアハウスの設計において重要な役割を果たします。そのシンプルな構造と高いクエリ効率から、多くのデータ分析プロジェクトで採用されています。このスキーマを理解し、適切に活用することで、データから価値を引き出すことが可能になります。
関連項目
スノーフレークスキーマ
ファクト星座スキーマ
外部リンク
Designing the Star Schema Database by Craig Utley
Star Schema for Retail Sales
Stars: A Pattern Language for Query Optimized Schema
Star schema optimizations