データ ウェアハウス モデルのスノーフレーク スキーマ

スノーフレーク スキーマとは何ですか?

A スノーフレークスキーマ データウェアハウスは、多次元データベース内のテーブルの論理的な配置であり、 エンティティ関係（ER）図 雪の結晶の形に似ている。 次元モデル 中心となるファクトテーブルがディメンションテーブルにリンクし、それらのディメンションテーブルがさらに関連するサブディメンションテーブルに分割される構造になっている。

スノーフレークスキーマは、スタースキーマの拡張版です。スタースキーマでは各ディメンションを単一のフラットテーブルに保持しますが、スノーフレークスキーマではこれらのディメンションを正規化し、繰り返し出現するデータグループを複数のルックアップテーブルに分割します。この正規化によって冗長性が排除され、スキーマ名の由来となった分岐型の階層構造が構築されます。

スノーフレークスキーマの例

以下のスノーフレークスキーマの例では、売上ファクトテーブルが中央に配置され、その周囲に製品、日付、店舗などのディメンションが配置されています。すべての属性を1つのディメンションテーブルに格納するのではなく、地理情報が正規化され、国は独立したテーブルに移動されています。

ここでは、店舗ディメンションは都市テーブルを参照し、都市テーブルは州テーブルを参照し、州テーブルは国テーブルを参照しています。各値は一度だけ格納され、外部キーによってリンクされているため、国名が何百万行にもわたって繰り返されることはありません。このような階層的な正規化こそが、スノーフレークスキーマとフラットなスタースキーマを区別する特徴です。

スノーフレークスキーマの特徴

スノーフレーク図式には、いくつかの特徴的な性質があります。

• 正規化されたディメンションテーブルは重複する値の保存を避けるため、ディスク容量の使用量が少なくて済みます。
• スキーマに新しい次元を追加することは、比較的少ない労力で可能です。
• データの取得には多数のテーブルの結合が必要となるため、クエリのパフォーマンスが低下する可能性があります。
• 管理すべきルックアップテーブルの数が増えるため、より多くのメンテナンス作業が必要になります。

スノーフレークスキーマの設計方法

スノーフレークスキーマの設計は、他のディメンションモデルと同様に開始し、正規化ステップを追加します。目的は、分析対象のビジネスプロセスを特定し、まずスタースキーマとしてモデル化し、次に深い階層を含むディメンションを正規化することです。以下の手順に従って作業を進めてください。

1. ビジネスプロセスと粒度を特定する。 ファクトテーブルの1行が何を表すか（例えば、1件の販売取引など）を決定し、報告する必要のある数値指標、つまりファクトを定義します。
2. 中心となる事実表を作成する。 数値メジャーと、各ディメンションを指す外部キーを加算します。これらの外部キーを組み合わせると、通常は複合主キーが形成されます。
3. ディメンションテーブルを定義します。 製品、顧客、日付、店舗など、記述的なディメンションごとにテーブルを1つ作成し、それぞれに代理主キーを割り当てます。
4. 階層構造を正規化する。 繰り返し属性を持つディメンションはすべて、サブディメンションテーブルに分割します。たとえば、カテゴリを製品ディメンションから分離したり、都市、州、国を店舗ディメンションから分離したりします。
5. 外部キーを使用してテーブルを接続します。 各サブディメンションを親テーブルにリンクさせることで、枝分かれした構造が雪の結晶のような明確な一対多の階層を形成するようにします。
6. クエリを使用して検証およびテストを行います。 代表的なレポートクエリを実行して、結合が正しい結果を返し、全体的なパフォーマンスが許容範囲内であることを確認してください。

この設計ではデータを第三正規形に正規化するため、アナリストが各ブランチをどのようにナビゲートすればよいかを理解できるよう、結合パスを明確に文書化してください。構造が定義されたら、スキーマの利点と欠点を比較検討する価値があります。

Snowflakeスキーマの利点

スノーフレークスキーマには、以下のような多くの利点があります。

• その主な利点は、より小さな正規化されたルックアップテーブルを結合することで、ディメンションデータの重複を回避できるため、ディスクストレージ容量を削減できることです。
• これにより、コンポーネント間および次元レベル間の関係において、より高い拡張性が実現されます。
• これにより冗長性が排除され、データの整合性が向上し、モデルの保守が容易になります。
• 記述属性は一箇所のみで更新されるため、データの不整合が発生するリスクが低減されます。

Snowflakeスキーマの欠点

この設計には、考慮すべきトレードオフも伴う。

• 正規化された構造では、関連する多数のテーブルを管理するために必要なメンテナンス作業が増加する。
• 複数の結合を含む複雑なクエリは、記述も理解も難しい場合があります。
• テーブルの数が増えると結合回数も増え、クエリの実行時間が長くなります。
• ビジネスユーザーは、分岐モデルの方が単純なスター型スキーマよりも操作が難しいと感じることが多い。

スノーフレークスキーマとスタースキーマの比較

スノーフレーク図式と スタースキーマ データウェアハウスにおける最も一般的な多次元スキーマは、スター型とスノーフレーク型の2種類であり、両者の主な違いは正規化にあります。スター型スキーマは、クエリ速度を最大化するために、各ディメンションを単一のフラットな非正規化テーブルに保持します。一方、スノーフレーク型スキーマは、ストレージ容量を節約し、データの整合性を保護するために、これらのディメンションを複数の関連テーブルに正規化します。そのため、この2つのスキーマは、それぞれ異なる優先順位に適しています。

側面	スタースキーマ	スノーフレークスキーマ
ディメンションテーブル	非正規化、次元ごとに1つのテーブル	サブディメンションテーブルに正規化
Storage	冗長性のため、より多くのスペースを消費します。	省スペース、無駄なし
クエリのパフォーマンス	より速く、より少ない結合	速度が遅くなり、結合回数が増える
クエリの複雑さ	書きやすい	より複雑
に最適	迅速なレポート作成とBI	大規模で階層的な次元

要するに、クエリ速度とレポート作成の簡便性が最優先される場合はスター型スキーマを、ストレージ効率、明確な階層構造、データ冗長性の低減が優先される場合はスノーフレーク型スキーマを選択してください。実際のデータウェアハウスの多くは、各ディメンションの規模と深さに応じて、両方のパターンを組み合わせて使用​​しています。

Snowflakeスキーマを使用するタイミング

スノーフレークスキーマは必ずしも最適な選択肢とは限らないため、ワークロードとレポート作成のニーズに合わせて設計を調整することが重要です。スノーフレークスキーマは、以下のような状況で最も効果を発揮する傾向があります。

• ディメンションは非常に大きく、多くの繰り返し属性が含まれているため、非正規化するとストレージ容量が無駄になります。
• ディメンションには、地域から国、州、都市といった、明確に定義された深い階層構造があり、それぞれが別のテーブルに自然にマッピングされます。
• このプロジェクトにおいては、クエリの速度そのものよりも、データの整合性と一貫性の方が重要である。
• ストレージコストは深刻な問題であり、巨大なディメンションテーブル全体でディスク容量を節約できることは非常に大きい。
• モデルフィード OLAP 正規化された階層構造を効率的にナビゲートできるツール。

逆に、ビジネスアナリスト向けの迅速かつシンプルなレポート作成が優先される場合は、スター型スキーマまたはハイブリッドスタークラスター設計の方が通常は適しています。 データウェアハウスのアーキテクチャ 速度とストレージ容量のバランスを取るために、両方のアプローチを意図的に組み合わせる。

ギャラクシースキーマとは何ですか?

A ギャラクシースキーマ 2つ以上のファクトテーブルがディメンションテーブルを共有する構造です。ファクトコンステレーションスキーマとも呼ばれ、星の集合体として捉えることができるため、ギャラクシースキーマとも呼ばれます。

上記の例に示すように、ファクトテーブルは2つあります。

1. 歳入
2. 製品

ギャラクシースキーマでは、ファクトテーブル間で共有される次元は、適合次元と呼ばれます。

ギャラクシースキーマの特徴

銀河の図式には、以下の特徴があります。

• 次元は、階層構造のさまざまなレベルに基づいて、明確な次元に分けられます。
• 例えば、地理に地域、国、州、都市という4つの階層レベルがあるとすれば、銀河系の図式には4つの次元が存在するはずだ。
• 単一のスター型スキーマを複数のスター型スキーマに分割することで、このタイプのスキーマを構築することが可能です。
• このスキーマにおける寸法は大きく、階層構造のレベルに応じて構築する必要があります。
• このスキーマは、ファクトテーブルを集約して、より優れた分析と理解を支援するのに役立ちます。

スターとは Cluster スキーマ?

スノーフレーク型スキーマは完全に展開された階層構造を持つため、複雑さが増し、追加の結合が必要になる場合があります。一方、スター型スキーマは完全に折りたたまれた階層構造を持つため、冗長性が生じる可能性があります。多くの場合、これら2つの設計のバランスを取ったものが最適な解決策であり、スター型スキーマと呼ばれます。 Cluster スキーマ。

重複ping ディメンションは階層構造における分岐点として現れます。分岐は、あるエンティティが2つの異なるディメンション階層において親エンティティとして機能する場合に発生します。これらの分岐エンティティは、1対多の関係を持つ分類として識別されるため、設計によって作成される余分なテーブルの数が制限されます。

よくあるご質問