スノーフレークスキーマとスタースキーマ

データウェアハウスにデータベーススキーマを選択する場合、 スノーフレーク スキーマスタースキーマが一般的な選択肢になる傾向があります。 この比較では、さまざまなシナリオとその特性におけるスタースキーマとスノーフレークスキーマの適合性について説明します。

比較表

スノーフレークスキーマとスタースキーマの比較表
スノーフレークスキーマ スタースキーマ
メンテナンス/変更の容易さ冗長性がないため、スノーフレークスキーマの維持と変更が簡単です。冗長データがあるため、保守/変更が容易ではありません
使いやすさより複雑なクエリ、したがって理解しにくいクエリの複雑さを軽減し、わかりやすい
クエリパフォーマンス外部キーが多いため、クエリの実行時間が長くなります(遅い)外部キーの数が少ないため、クエリの実行時間が短くなります(高速)
データウェアハウスのタイプ複雑な関係を単純化するためにデータウェアハウスコアに使用するのに適しています(多:多)単純な関係(1:1または1:多く)のデータマートに適しています
参加する結合の数が多い少ない結合
寸法表スノーフレークスキーマには、各ディメンションに複数のディメンションテーブルがある場合があります。スタースキーマには、ディメンションごとに1つのディメンションテーブルのみが含まれます。
使用する場合ディメンションテーブルのサイズが比較的大きい場合、スペースを削減するため、雪片の方が適しています。ディメンションテーブルの行数が少ない場合、スタースキーマを選択できます。
正規化/非正規化ディメンションテーブルは正規化形式ですが、ファクトテーブルは非正規化形式ですディメンションテーブルとファクトテーブルはどちらも非正規化形式です
データ・モデルボトムアップアプローチトップダウンアプローチ

多くの店舗を持つ小売業者のデータベースを考えてみましょう。各店舗は、多くの製品カテゴリとブランドの多くの製品を販売しています。 このような小売業者のデータウェアハウスまたはデータマートは、店舗、日付(または月、四半期、年)、または製品カテゴリまたはブランドごとにグループ化された販売レポートを実行する機能をアナリストに提供する必要があります。

スタースキーマの例

このデータマートがスタースキーマを使用している場合、次のようになります。

スタースキーマの例

ファクトテーブルは販売トランザクションのレコードになりますが、日付、店舗、製品のディメンションテーブルがあります。 ディメンションテーブルはそれぞれ、ファクトテーブルの外部キーであるプライマリキーを介してファクトテーブルに接続されます。 たとえば、実際のトランザクション日付をファクトテーブルの行に格納する代わりに、date_idが格納されます。 このdate_idはDim_Dateテーブルの一意の行に対応し、その行にはレポートでのグループ化に必要な日付の他の属性も格納されます。 たとえば、曜日、月、年の四半期など。 レポート作成を容易にするため、データは非正規化されています。

以下は、内部結合を利用して、ブランド別および国別のテレビ販売数のレポートを取得する方法です。

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

同じシナリオでスノーフレークスキーマを使用することもできます。この場合、次のように構成されます。

スノーフレークスキーマの例(クリックして拡大)

主な違いは、スタースキーマと比較した場合、ディメンションテーブルのデータがより正規化されていることです。 たとえば、Dim_Dateテーブルの各行に月、四半期、曜日を保存する代わりに、これらは独自のディメンションテーブルにさらに分割されます。 同様に、Dim_Storeテーブルの場合、州と国は地理的属性であり、1つのステップが削除されます。Dim_Storeテーブルに保存される代わりに、別のDim_Geographyテーブルに保存されます。

同じレポート-国別およびブランド別のテレビ販売数-は、スタースキーマよりも少し複雑になりました。

データベースがスノーフレークスキーマを使用している場合、国およびブランド別に販売された製品の数を取得するSQLクエリ。

関連記事