スノーフレークスキーマ

出典: フリー百科事典『ウィキペディア（Wikipedia）』
スノーフレークスキーマはスタースキーマのバリエーションであり、ディメンションテーブルの正規化を特徴としている。

情報処理やコンピューティングの分野では、スノーフレークスキーマは、ER図が雪片の形状に似た形になるように、多次元データベースのテーブルを論理的に配置したものである。 スノーフレークスキーマは、複数のディメンションに接続された一元化されたファクトテーブルによって表される。 「スノーフレーク」は、スタースキーマのディメンションテーブルを正規化する方法である。 すべてのディメンションテーブルに沿って完全に正規化されると、結果の構造は、ファクトテーブルが中央にあるスノーフレークに似たものになる。 スノーフレークの背後にある原則は、カーディナリティの低い属性を削除し、個別のテーブルを形成することにより、ディメンションテーブルを正規化することである。

スノーフレークスキーマはスタースキーマに似ている。しかし、スノーフレークスキーマでは、ディメンションは複数の関連するテーブルに正規化されるが、スタースキーマのディメンションは非正規化の状態で、各ディメンションは単一のテーブルで表される。 複雑なスノーフレーク形状は、スノーフレークスキーマのディメンションが複雑で、複数のレベルの関係があり、子テーブルに複数の親テーブル（所謂「道路の分岐点」）がある場合に現れる[1]。

一般的な用途[編集]

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

データの正規化と保存[編集]

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

ストレージスペースの観点から、ディメンションテーブルは通常、ファクトテーブルと比較して小さい。これは、スタースキーマのスノーフレークスキーマに対しての潜在的なストレージスペースの利点を打ち消すことがよくある。 例：220か国の300店舗で100万件の販売トランザクションを行うと、スタースキーマに1,000,300レコードが生成される（ファクトテーブルに1,000,000レコード、ディメンションテーブルに300レコードがあり、各国はその国の各ショップに対して明示的にリストアップされる）。 国テーブルを参照する国キーを持つより正規化されたスノーフレークスキーマは、同じ1,000,000レコードのファクトテーブル、220レコードのある国テーブルへの参照を持つ300レコードのショップテーブルで構成される。 この場合、スタースキーマはさらに非正規化されるが、数またはレコードを（無視できる）係数〜0.9998（= [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

関連項目[編集]

脚注[編集]

[脚注の使い方]
  1. ^ Paulraj Ponniah. Data Warehousing Fundamentals for IT Professionals. Wiley, 2010, pp. 29–32. ISBN 0470462078.
  2. ^ Han, Jiawei (2012). Data Mining - Concepts and Techniques. Massachusettes, USA: Morgan Kauffmann Publishers. ISBN 9780123814791 
  3. ^ Wilkie, Michelle (2009). “Using SAS® OLAP Server for a ROLAP Scenario”. SAS Global Forum 2009. http://support.sas.com/resources/papers/proceedings09/103-2009.pdf 2013年2月27日閲覧。. 
  4. ^ Kimball, Ralph (1996). “6: The Big Dimensions”. The Data Warehouse Toolkit (1st ed.). Wiley. pp. 95–98. ISBN 0-471-15337-0. https://archive.org/details/datawarehousetoo00kimb_0/page/95. "Do not snowflake your dimensions, even if they are large" 

参考文献[編集]

外部リンク[編集]

「https://ja.wikipedia.org/w/index.php?title=スノーフレークスキーマ&oldid=92295654」から取得