データウェアハウス-スキーマ

スキーマは、ファクトテーブルとディメンションテーブルが論理的に結合されているデータベースの論理記述として定義されます。データウェアハウスは、スター、スノーフレーク、およびファクトコンステレーションスキーマの形式で維持されます。

スタースキーマ

スタースキーマには、ファクトテーブルと複数のディメンションテーブルが含まれています。各ディメンションは1つのディメンションテーブルのみで表され、正規化されていません。ディメンションテーブルには、一連の属性が含まれています。

特徴

• スタースキーマには、1つのファクトテーブルと複数のディメンションテーブルしかありません。
• スタースキーマでは、各ディメンションは1つのディメンションテーブルで表されます。
• ディメンションテーブルは、スタースキーマでは正規化されていません。
• 各ディメンションテーブルは、ファクトテーブルのキーに結合されます。

次の図は、時間、アイテム、支店、場所の4つのディメンションに関する会社の売上データを示しています。

中央にファクトテーブルがあります。これには、4つの次元のそれぞれに対するキーが含まれています。ファクトテーブルには、属性、つまり販売されたドルと販売されたユニットも含まれています。

Note−各ディメンションには1つのディメンションテーブルのみがあり、各テーブルは一連の属性を保持します。たとえば、場所ディメンションテーブルには、属性セット{location_key、street、city、province_or_state、country}が含まれています。この制約により、データの冗長性が発生する可能性があります。

For example−「バンクーバー」と「ビクトリア」の両方の都市は、カナダのブリティッシュコロンビア州にあります。このような都市のエントリは、属性province_or_stateおよびcountryに沿ってデータの冗長性を引き起こす可能性があります。

雪片スキーマ

Snowflakeスキーマの一部のディメンションテーブルは正規化されています。次の図に示すように、正規化によってデータが追加のテーブルに分割されます。

スタースキーマとは異なり、スノーフレークスキーマのディメンションのテーブルは正規化されます。

For example−スタースキーマのアイテムディメンションテーブルは正規化され、アイテムテーブルとサプライヤテーブルの2つのディメンションテーブルに分割されます。これで、アイテムディメンションテーブルに、属性item_key、item_name、type、brand、およびsupplier-keyが含まれます。

サプライヤキーは、サプライヤディメンションテーブルにリンクされています。サプライヤディメンションテーブルには、属性supplier_keyおよびsupplier_typeが含まれています。

Note − Snowflakeスキーマの正規化により、冗長性が低下するため、保守が容易になり、ストレージスペースを節約できます。

ファクトコンステレーションスキーマ（ギャラクシースキーマ）

ファクトコンステレーションには複数のファクトテーブルがあります。ギャラクシースキーマとも呼ばれます。

次の図は、2つのファクトテーブル、つまり販売と出荷を示しています。

販売ファクトテーブルは、スタースキーマのテーブルと同じです。出荷ファクトテーブルには、item_key、time_key、shipper_key、from_location、to_locationの5つのディメンションがあります。出荷ファクトテーブルには、販売されたドルと販売された単位の2つのメジャーも含まれています。ファクトテーブル間でディメンションテーブルを共有することもできます。

For example −時間、アイテム、および場所のディメンションテーブルは、販売ファクトテーブルと出荷ファクトテーブルの間で共有されます。