スノーフレークスキーマ

コンピューティングにおいて、スノーフレーク スキーマまたはスノーフレーク モデルは、多次元データベース内のテーブルの論理的な配置であり、エンティティ リレーションシップダイアグラムはスノーフレークの 形状に似ています。スノーフレーク スキーマは、複数のディメンションに接続された集中型のファクト テーブルによって表されます。「スノーフレーク」は、スター スキーマでディメンション テーブルを正規化する方法です。すべてのディメンション テーブルに沿って完全に正規化されると、結果の構造は中央にファクト テーブルがあるスノーフレークに似ています。スノーフレークの背後にある原則は、低カーディナリティ属性を削除して個別のテーブルを形成することでディメンション テーブルを正規化するというものです。^[1]

スノーフレーク スキーマはスター スキーマに似ています。ただし、スノーフレーク スキーマではディメンションが複数の関連テーブルに正規化されますが、スター スキーマのディメンションは非正規化され、各ディメンションが 1 つのテーブルで表されます。スノーフレーク スキーマのディメンションが複雑で、複数のレベルの関係があり、子テーブルに複数の親テーブルがある場合 (「分岐点」)、複雑なスノーフレーク形状が現れます。

スタースキーマとスノーフレークスキーマは、データ操作の効率よりもデータ取得の速度が重要視される多次元データウェアハウスやデータマートで最もよく見られる。そのため、これらのスキーマのテーブルはあまり正規化されておらず、第3正規形に満たないレベルの正規化で設計されることが多い。^[2]

正規化では、一般的に繰り返されるデータ グループを新しいテーブルに移動することで、冗長性 (重複) を回避するためにデータを分割します。したがって、正規化により、特定のクエリを実行するために結合する必要があるテーブルの数が増える傾向がありますが、データを保持するために必要なスペースと、データが変更された場合に更新する必要がある場所の数は削減されます。

スペース ストレージの観点から見ると、ディメンション テーブルはファクト テーブルに比べて通常は小さくなります。このため、スター スキーマと比較した場合のスノーフレーク スキーマの潜在的なストレージ スペースの利点が打ち消されることがよくあります。例: 220 か国の 300 店舗で 100 万件の販売取引が行われると、スター スキーマでは 1,000,300 件のレコードが生成されます (ファクト テーブルに 1,000,000 件のレコード、ディメンション テーブルに 300 件のレコードがあり、ディメンション テーブルには各国の店舗ごとに各国が明示的にリストされます)。国キーが国テーブルを参照する、より標準化されたスノーフレーク スキーマは、同じ 1,000,000 件のレコードのファクト テーブル、300 件のレコードの店舗テーブル、および 220 件のレコードを含む国テーブルへの参照で構成されます。この場合、スタースキーマはさらに非正規化されますが、レコード数は（無視できるほど）約0.02％（= [1,000,000+300]ではなく[1,000,000+300+220]）だけ減少します。

一部のデータベース開発者は、基盤となるスノーフレーク スキーマを作成し、その上にビューを構築してスター スキーマをシミュレートするために必要な結合の多くを実行することで妥協しています。これにより、ディメンションの正規化によって実現されるストレージの利点と、スター スキーマが提供するクエリの容易さが実現します。トレードオフとして、基盤となる結合をサーバーが自動的に実行するように要求すると、クエリの実行時にパフォーマンスが低下するだけでなく、特定のクエリを実行するために必要のないテーブルへの余分な結合が発生する可能性があります。^{[引用が必要]}

スノーフレーク スキーマは、スター スキーマ論理モデルと同じファミリーに属します。実際、スター スキーマはスノーフレーク スキーマの特殊なケースと見なされます。スノーフレーク スキーマには、次のような特定の状況でスター スキーマよりも優れた利点があります。

• 一部のOLAP多次元データベースモデリングツールはスノーフレークスキーマに最適化されています。^[3]
• 属性を正規化するとストレージが節約されますが、その代償としてソース クエリの結合がさらに複雑になります。

スノーフレーク スキーマの主な欠点は、スター スキーマと比較すると、属性の正規化のレベルが追加されるため、ソース クエリの結合が複雑になることです。

スノーフレークスキーマは、フラットな単一テーブルディメンションとは対照的に、厳しい批判を受けてきました。スノーフレークスキーマの目的は、正規化されたデータを効率的かつコンパクトに格納することだと考えられていますが、このディメンションで必要な結合を参照する際のパフォーマンスが低下するという大きな代償を伴います。^[4]この欠点は、最初に認識されてから数年の間に、参照ツール内でのクエリパフォーマンスが向上したため、軽減された可能性があります。

右側に示すサンプル スキーマは、スター スキーマの記事で提供されているスター スキーマ サンプルのスノーフレーク バージョンです。

次のサンプル クエリは、1997 年にブランド別および国別に販売されたテレビの総数を返すスター スキーマ サンプル コードに相当するスノーフレーク スキーマです。スノーフレーク スキーマ クエリでは、単純なクエリを実行するためにも、スター スキーマ バージョンよりも多くの結合が必要であることに注意してください。この例でスノーフレーク スキーマを使用する利点は、スノーフレーク スキーマによってディメンション自体から多くの重複値が削除されるため、ストレージ要件が低くなることです。

SELECT 
B.Brand , G.Country , SUM ( F.Units_Sold ) FROM Fact_Sales F INNER JOIN Dim_Date D ON F.Date_Id = D.Id INNER JOIN Dim_Store S ON F.Store_Id = S.Id INNER JOIN Dim_Geography G ON S.Geography_Id = G.Id INNER JOIN Dim_Product P ON F.Product_Id = P.Id INNER JOIN Dim_Brand B ON P.Brand_Id = B.Id INNER JOIN Dim_Product_Category C ON P.Product_Category_Id = C.Id WHERE D.Year = 1997 AND C.Product_Category = ' tv ' GROUP BY B.Brand , G.Country​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​	
	
	
  
                   
                  
              
                
                  
       

	   
	  
 
	
	

• スタースキーマ
• データ ウェアハウス
• オンライン分析処理(OLAP)

• Anahory, S.; D. Murray.現実世界におけるデータ ウェアハウス: 意思決定支援システム構築のための実践ガイド。Addison Wesley Professional。
• キンボール、ラルフ(1996)。データウェアハウスツールキット。ジョン ワイリー。ISBN 978-0-471-15337-5。

• 「なぜスノーフレーク スキーマは優れたデータ ウェアハウス設計なのか?」 ( Mark Leveneおよび George Loizou著)
• 逆スノーフレーク結合