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

前の2つの記事では、スタースキーマとスノーフレークスキーマという2つの最も一般的なデータウェアハウスモデルについて検討しました。今日は、これら2つのスキーマの違いを調べ、どちらを使用するのがよいかを説明します。

スタースキーマとスノーフレークスキーマは、リレーショナルデータベースを使用してデータマートまたはデータウェアハウス全体を整理する方法です。どちらもディメンションテーブルを使用します ファクトテーブルに集約されたデータを説明する。

知識であれ、製品であれ、サービスであれ、誰もが何かを売っています。この情報を運用システムまたはレポートシステムのいずれかに保存することも必要です。したがって、ほぼすべての企業のデータウェアハウス内で、ある種の販売モデルを見つけることが期待できます。

スタースキーマとスノーフレークスキーマの両方の販売モデルをもう一度見てみましょう。

スタースキーマ

スタースキーマの最も明白な特徴は、ディメンションテーブルが正規化されていないことです。上記のモデルでは、ピンクのfact_sales テーブルには、運用データベースから作成された集約データが格納されます。水色のテーブルはディメンションテーブルです。これらの5つのディメンションをパラメーターとして使用してレポートを作成する必要があるため、これらのディメンションを使用することにしました。各ディメンション内の粒度も、レポートのニーズによって決まります。

このモデルから、このスキーマが「スタースキーマ」と呼ばれる理由を簡単に理解できます。スタースキーマのように見え、中央のファクトテーブルをディメンションテーブルで囲んでいます。

スノーフレークスキーマ

このスノーフレークスキーマは、スタースキーマとまったく同じデータを格納します。ファクトテーブルのディメンションは、スタースキーマの例と同じです。最も重要な違いは、スノーフレークスキーマのディメンションテーブルが正規化されていることです。興味深いことに、ディメンションテーブルを正規化するプロセスはスノーフレークと呼ばれます。

繰り返しになりますが、スノーフレークスキーマは視覚的にその名前を思い起こさせ、ディメンションテーブルのいくつかのレイヤーが不規則なスノーフレークのような形状を作成します。

最初の違い：正規化

前述のように、正規化はスタースキーマとスノーフレークスキーマの重要な違いです。これに関して、知っておくべきことがいくつかあります：

Snowflakeスキーマは、ディメンションテーブルを格納するために使用するスペースが少なくなります。これは、原則として、正規化されたデータベースが生成する冗長レコードがはるかに少ないためです。
非正規化されたデータモデルは、データの整合性の問題の可能性を高めます。これらの問題により、将来の変更やメンテナンスも複雑になります。
経験豊富なデータモデラーにとって、スノーフレークスキーマはスタースキーマよりも論理的に編成されているように見えます。（これは私の個人的な意見であり、難しい事実ではありません。:)）

これら2つのスキーマの2番目の大きな違いに移りましょう。

2番目の違い：クエリの複雑さ

最初の2つの記事では、2016年にベルリンの店舗で販売されたすべての電話タイプの製品の数量を取得するために販売モデルで使用できるクエリを示しました。

スタースキーマクエリは次のようになります：

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

スノーフレークスキーマから同じ結果を得るには、次のクエリを使用する必要があります：

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

明らかに、スノーフレークスキーマクエリはより複雑です。ディメンションテーブルは正規化されているため、製品タイプの名前と都市を取得するには、さらに深く掘り下げる必要があります。同じディメンション内の新しいレベルごとに別のJOINを追加する必要があります。

スタースキーマでは、ファクトテーブルと必要なディメンションテーブルのみを結合します。せいぜい、ディメンションテーブルごとに1つのJOINしかありません。また、ディメンションテーブルを使用していない場合は、それを気にする必要もありません。スノーフレークスキーマクエリでは、適切なディメンションレベルを取得するためにどれだけ深く行かなければならないかわからないため、クエリを作成するプロセスが複雑になります。

DMBSはリクエストの処理に時間がかかるため、2つのテーブルの結合には時間がかかります。 dim_store およびdim_city テーブルはモデル内で近接して配置されていますが、ディスク上で互いに近くに配置されていない可能性があります。データが同じテーブル内にある場合、データがディスク上で物理的に近くなる可能性が高くなります。

基本的に、スノーフレークスキーマデータマートに対して実行されたクエリは、実行速度が遅くなります。ただし、ほとんどの場合、これで問題が発生することはありません。1ミリ秒で結果が得られるか、1秒で結果が得られるかはそれほど重要ではありません。

スピードアップ

レポートを高速化するために、次のことができます。

レポートで必要なレベルまでデータを集約します。これにより、データが大幅に圧縮されます。ライブデータをレポートスキーマ構造（ETLプロセス）に適合するように変換する手順を作成する必要があります。
すべての中央ストレージ領域を構築します売上データだけでなく、会社の集計データ。
分析とレポートに必要なデータのみをユーザーに提供します。

スノーフレークとスタースキーマ：どちらを使用する必要がありますか？

理論とクエリの速度について見てきたので、問題の核心に取り掛かりましょう。特定のプロジェクトで使用するスキーマをどのようにして知ることができますか？

スノーフレークスキーマの使用を検討してください：

データウェアハウス内。 ウェアハウスは会社のデータセントラルであるため、この方法で多くのスペースを節約できます。
ディメンションテーブルに大量のストレージスペースが必要な場合。 ほとんどの場合、ファクトテーブルがほとんどのスペースを占めることになります。また、ディメンションテーブルよりもはるかに速く成長する可能性があります。ただし、それが当てはまらない特定の状況があります。たとえば、ディメンションテーブルには、冗長であるが必要な属性が多数含まれている可能性があります。この例では、 cityを使用しましたストアが配置されている都市を表す属性。人口、郵便番号、人口統計データなど、都市のより詳細な説明が必要な場合はどうなりますか？他のサブディメンションの説明-たとえば、 store 、地域、状態および国 –属性を増やすと、dim_store 冗長性の高い1つの大きなテーブルにテーブルをディメンション化します。
バックグラウンドでスノーフレークスキーマを必要とするツールを使用する場合。（幸いなことに、最新のツールのほとんどは、スキーマと銀河スキーマの両方をサポートしています。）

スタースキーマの使用を検討してください：

データマート内。 データマートは、中央のデータウェアハウスから取り出されたデータのサブセットです。これらは通常、さまざまな部門向けに作成されており、すべての履歴データが含まれているわけではありません。この設定では、ストレージスペースの節約は優先事項ではありません。

一方、スタースキーマは分析を簡素化します。これは、クエリの効率だけでなく、ビジネスユーザーの将来のアクションを簡素化することでもあります。彼らはデータベースを理解し、クエリの書き方を知っているかもしれませんが、それを回避できるのであれば、なぜ物事を複雑にし、より多くの結合を含めるのでしょうか？ビジネスユーザーは、ファクトテーブルをすべてのディメンションテーブルと結合するテンプレートクエリを持つことができます。次に、適切な選択とグループ化を追加するだけで済みます。（このアプローチは、Excelのピボットテーブルに近いものです。）
バックグラウンドでスタースキーマを必要とするツールを使用する場合。（繰り返しますが、これは通常問題ではありません。）

スタースキーマとスノーフレークスキーマはどちらも、データウェアハウスやデータマートを整理するために使用されるリレーショナルモデルです。それらがどれほど似ていても、2つの異なるアプローチを示し、それぞれに長所と短所があります。個人的には、データウェアハウスを実装するときはスノーフレークスキーマを使用し（ストレージスペースを節約するため）、データマートの場合はスタースキーマを使用します（ビジネスユーザーの生活を楽にするため）。