スタースキーマ

コンピューティングにおいて、スタースキーマまたはスターモデルは、データマート スキーマの最も単純なスタイルであり、データウェアハウスやディメンションデータマートの開発に最も広く使用されているアプローチです。^[1]スタースキーマは、任意の数のディメンションテーブルを参照する1つ以上のファクトテーブルで構成されます。スタースキーマは、スノーフレークスキーマの重要な特殊なケースであり、より単純なクエリを処理するのに効果的です。^[2]

スタースキーマは、物理モデル^[3]が星型に似ており、その中心にファクトテーブルがあり、その周囲に星の頂点を表すディメンションテーブルがあることからその名前が付けられています。

スター スキーマは、ビジネス プロセス データを、ビジネスに関する測定可能な定量的データを保持するファクトと、ファクト データに関連する説明的な属性であるディメンションに分割します。ファクト データの例には、販売価格、販売数量、時間、距離、速度、重量の測定値などがあります。関連するディメンション属性の例には、製品モデル、製品の色、製品サイズ、地理的な場所、販売員名などがあります。

多くのディメンションを持つスタースキーマは、センチピードスキーマと呼ばれることもあります。^[4]ディメンションの属性数が少ないと、メンテナンスは簡単になりますが、クエリでテーブル結合が多くなり、スタースキーマの使いやすさが低下します。

ファクト テーブルには、特定のイベントの測定値またはメトリックが記録されます。ファクト テーブルは通常、数値と、説明情報が保存されるディメンション データへの外部キーで構成されます。^{[4]ファクト テーブルは、均一な詳細度の低いレベル (「粒度」または「}粒度」 と呼ばれる) で設計されており、ファクトはイベントを非常に原子レベルで記録できます。これにより、時間の経過とともにファクト テーブルに大量のレコードが蓄積される可能性があります。ファクト テーブルは、次の 3 つのタイプのいずれかとして定義されます。

• トランザクションファクトテーブルは、特定のイベント（販売イベントなど）に関するファクトを記録します。
• スナップショットファクトテーブルは、特定の時点のファクトを記録します（例：月末のアカウントの詳細）
• スナップショット テーブルを蓄積すると、特定の時点での集計データが記録されます (例: 製品の今月累計売上など)

ファクト テーブルには通常、各行を一意に識別できるように代理キーが割り当てられます。このキーは単純な主キーです。

ディメンション テーブルには、ファクト テーブルに比べてレコード数が比較的少ないのが一般的ですが、各レコードにはファクト データを記述する属性が多数含まれる場合があります。ディメンションではさまざまな特性を定義できますが、ディメンション テーブルで定義される最も一般的な属性には次のものがあります。

• 時間ディメンションテーブルは、スタースキーマでイベントが記録される時間の粒度の最低レベルで時間を記述します。
• 地理ディメンションテーブルは、国、州、都市などの場所データを記述します。
• 製品ディメンションテーブルは製品を説明します
• 従業員ディメンションテーブルは、営業担当者などの従業員を記述します。
• 範囲ディメンションテーブルは、レポート作成を簡素化するために、時間、ドル価値、またはその他の測定可能な量の範囲を記述します。

ディメンション テーブルには通常、自然キーを形成するディメンション属性の組み合わせにマップされる、通常は単一列の整数データ型である 代理主キーが割り当てられます。

スター スキーマは非正規化されています。つまり、トランザクション リレーショナル データベースに適用される一般的な正規化ルールは、スター スキーマの設計と実装中に緩和されます。スター スキーマの非正規化の利点は次のとおりです。

• よりシンプルなクエリ - スター スキーマの結合ロジックは、高度に正規化されたトランザクション スキーマからデータを取得するために必要な結合ロジックよりも一般的にシンプルです。
• 簡素化されたビジネス レポート ロジック - 高度に標準化されたスキーマと比較すると、スター スキーマは、期間ごとのレポートや時点レポートなどの一般的なビジネス レポート ロジックを簡素化します。
• クエリ パフォーマンスの向上 - スター スキーマは、高度に正規化されたスキーマと比較すると、読み取り専用レポート アプリケーションのパフォーマンスを向上できます。
• 高速な集計 - スター スキーマに対するクエリが単純化されると、集計操作のパフォーマンスが向上します。
• キューブのフィード – スター スキーマは、すべてのOLAPシステムで独自のOLAP キューブを効率的に構築するために使用されます。実際、ほとんどの主要な OLAP システムは、独自のキューブ構造を構築せずにスター スキーマをソースとして直接使用できるROLAPモードの操作を提供します。

日付、店舗、製品別に分類された、店舗チェーンからの売上データベースを考えてみましょう。右側のスキーマのイメージは、スノーフレーク スキーマの記事で提供されているサンプル スキーマのスター スキーマ バージョンです。

Fact_Salesは ファクト テーブルであり、3 つのディメンション テーブルがありDim_DateますDim_Store。Dim_Product

各ディメンション テーブルには、その列に主キーがあり、テーブルの 3 列 (複合) 主キー ( 、、 ) の列(Idサンプル スキーマでは行として表示) の 1 つに関連付けられています。この例のファクト テーブルの非主キー列は、計算や分析に使用できるメジャーまたはメトリックを表します。ディメンション テーブルの非主キー列は、ディメンションの追加属性 (ディメンションのなど) を表します。 Fact_SalesDate_IdStore_IdProduct_IdUnits_SoldYearDim_Date

たとえば、次のクエリは、1997 年に各ブランドおよび国ごとに何台のテレビが販売されたかを回答します。

P.ブランド、S .国を国として選択し、SUM ( F .販売数)	
	  
	

Fact_Sales Fから、Dim_Date D ON ( F . Date_Id = D . Id )内部結合Dim_Store S ON ( F . Store_Id = S . Id )内部結合Dim_Product P ON ( F . Product_Id = P . Id )​  
          
         
       

D . Year = 1997かつP . Product_Category = 'tv'の場合        

P.ブランド、S .国別にグループ化 
	
	

• データ ウェアハウス
• 事実の星座
• オンライン分析処理
• 逆スタースキーマ
• スノーフレークスキーマ

• Stars: クエリ最適化スキーマのパターン言語