前回の記事では、スタースキーマモデルについて説明しました。スノーフレークスキーマは、データウェアハウスモデリングにおける重要性の点でスタースキーマの次にあります。これはスタースキーマから開発されたものであり、以前のスキーマに比べていくつかの利点があります。しかし、これらの利点にはコストがかかります。この記事では、スノーフレークスキーマをいつどのように使用するかについて説明します。
スノーフレークスキーマ
スノーフレークスキーマの名前は、ディメンションテーブルが分岐してスノーフレークのように見えるという事実に由来しています。上記のモデルを見ると、いくつかのディメンションテーブルに囲まれたファクトテーブルであり、そのうちのいくつかは前述の分岐を行っていることがわかります。スタースキーマとは異なり、スノーフレークスキーマのディメンションテーブルには独自のカテゴリを設定できます。
スノーフレークスキーマの背後にある支配的な考え方は、ディメンションテーブルが完全に正規化されているということです。各ディメンションテーブルは、1つ以上のルックアップテーブルで記述できます。各ルックアップテーブルは、1つ以上の追加のルックアップテーブルで記述できます。これは、モデルが完全に正規化されるまで繰り返されます。スタースキーマディメンションテーブルを正規化するプロセスは、スノーフレークと呼ばれます。
この記事では、正規化について多くのことを耳にします。正規化とは何ですか？基本的に、冗長性を最小限に抑え、データの整合性を保護する方法でデータベースを編成します。正規化と非正規化の詳細については、この投稿を確認してください。
スノーフレークスキーマの例：販売モデル
以前は、スタースキーマを使用して架空の営業部門をモデル化しました。これは、営業活動と結果を追跡するために使用されるデータマートに似ています。モデルには5つのディメンションがあります： product 、時間 、ストア 、販売 タイプと従業員 。 fact_sales 表、価格 および数量 ディメンションテーブルの値に基づいて保存およびグループ化されます。復習については、以下のスタースキーマ販売モデルをご覧ください。
スノーフレークスキーマとして編成された同じモデルを次に示します。
dim_employee およびdim_sales_type ディメンションテーブルはすでに正規化されているため、スタースキーマモデルとまったく同じです。
一方、残りのディメンションテーブルには正規化ルールを適用しました。
dim_product スタースキーマのディメンションテーブルは、スノーフレークモデルで2つのテーブルに分割されます。 dim_product_type dim_product テーブル。これを使用して、いくつかのデータ整合性の問題を回避しました。
ETLプロセスの一部として、すべての製品名とそれに関連するタイプがすでに挿入されていると想定するのは論理的ですが、さらに製品名とタイプを追加する必要があると仮定します。スタースキーマでは、誤って間違った製品タイプをテーブルに入力する可能性があります。スノーフレークスキーマの場合：
- 新しい製品タイプ名が見つかった場合は、新しい製品タイプを追加してから、そのタイプを新しく追加されたレコードに関連付けることができます。ただし、これにより、スタースキーマの場合と同様に、ユーザーが間違った情報を入力する可能性があります。
- 追加したい商品名が既に存在するかどうかを確認できます。もしそうなら、そのIDを取得できます。そうでない場合は、新しい製品と関連するタイプを追加するかどうかを尋ねる警告が表示されます。
dim_store スタースキーマのディメンションテーブルは、スノーフレークスキーマの5つのテーブルで表されます。これらは、dim_store テーブル。このテーブルを正規化すると、データの整合性のリスクが回避されるだけでなく、ディスク領域も節約されます。
dim_time ディメンションは5つのテーブルで表されます。 dim_weekについて考えることができます 、dim_month 、dim_year およびdim_weekday dim_time テーブル。
dim_week 、dim_month 、dim_year およびdim_weekday テーブルは、時間ディメンションを説明するために使用される4つの異なる階層です。必要に応じて、四半期やその他の関連テーブルなどのディメンションを追加できます。この例では、dim_month 12か月を含む辞書です。この次元だけでは、その月がどの年に属しているかを知る方法はありません。これがdim_year テーブル。
スノーフレークスキーマの例：供給注文モデル
私たちが議論した他のデータマートは、供給注文用でした。アイデアは、次の4つのディメンションのすべての供給注文データを保存および集約することです。 product 、時間 、サプライヤー および従業員 。もう一度、関連するスタースキーマを見てみましょう：
これをスノーフレークスキーマに変換すると、次のモデルが得られます。
dim_product 、dim_time およびdim_supplier ディメンションテーブル。
スノーフレークスキーマの長所と短所
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_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
スターフレークスキーマ
スターフレークスキーマは、スノーフレークとスタースキーマを組み合わせたものです。これは、一部のディメンションテーブルが非正規化されたスノーフレークスキーマと見なすことができます。正しく使用すると、スターフレークスキーマは両方の世界で最高のアプローチを提供できます。明らかに、モデルのスノーフレーク部分はディスクスペースを節約し、スター部分はパフォーマンスを向上させるはずです。
上記のモデルは基本的に、非正規化されたdim_time テーブル。このスキーマは必要なクエリ結合の数を減らすため、パフォーマンスが向上する可能性があります。一方、ほとんどのテーブル属性と外部キー属性はintを共有しているため、ディスク容量が大幅に失われることはありません。 タイプ。
ギャラクシースキーマ
データウェアハウジングでは、ギャラクシースキーマは、2つ以上のファクトテーブルが1つ以上のディメンションテーブルを共有する場合です。このスキーマを使用する理由の1つは、ディスクスペースを節約することです。以下にサンプルの銀河スキーマを作成しました：
ここには、fact_sales およびfact_supply_order 、3つのディメンションテーブルを直接共有します：dim_product 、dim_employee およびdim_time 。 dim_store およびdim_supplier 同じルックアップテーブルdim_city 。
この方法でスペースを節約しますが、2つのデータマート（この場合は販売注文と供給注文）を1つの銀河スキーマに結合する前にいくつかの点に注意する必要があります。
- それらを結合する背後にあるロジックはありますか？ 例 両方のデータマートを同じ部門で使用しますか？
- 正確に同じ寸法と造粒が必要だと確信していますか？ 両方のデータマートの場合？
スノーフレークスキーマは、データモデリングでよく使用されます。ディスクスペースがパフォーマンスよりも重要である状況では、これは正しい選択かもしれません。省スペースとパフォーマンスのバランスが必要な場合は、スターフレークスキーマを使用できます。それでも、特定の問題に適切に適合するかどうかは、多くのパラメーターによって異なります。これは、ITの分野のひとつであり、さまざまな要素を「試して」、最良のソリューションを考え出すことができます。