Cognos-data-warehouse-schemas
データウェアハウス-スキーマ
スキーマは、ファクトテーブルとディメンションテーブルが論理的に結合されているデータベースの論理記述として定義されます。 データウェアハウスは、スター、スノーフレーク、およびファクトコンステレーションスキーマの形式で維持されます。
スタースキーマ
スタースキーマには、ファクトテーブルと複数のディメンションテーブルが含まれます。 各ディメンションは1次元のテーブルのみで表され、正規化されません。 ディメンションテーブルには、一連の属性が含まれています。
特徴
- スタースキーマでは、ファクトテーブルは1つだけで、ディメンションテーブルは複数あります。
- スタースキーマでは、各ディメンションは1次元のテーブルで表されます。
- ディメンションテーブルは、スタースキーマでは正規化されません。
- 各ディメンションテーブルは、ファクトテーブルのキーに結合されます。
次の図は、4つのディメンション（時間、アイテム、支店、場所）に関する会社の販売データを示しています。
中央にファクトテーブルがあります。 これには、4つの各次元へのキーが含まれています。 ファクトテーブルには、属性（販売ドルと販売単位）も含まれています。
注-各ディメンションには1次元のテーブルのみがあり、各テーブルには属性のセットが保持されます。 たとえば、ロケーションディメンションテーブルには、属性セット\ {location_key、street、city、Province_or_state、country}が含まれています。 この制約により、データの冗長性が生じる場合があります。
たとえば-「バンクーバー」と「ビクトリア」はどちらもカナダのブリティッシュコロンビア州にあります。 そのような都市のエントリは、provision_or_stateおよびcountry属性に沿ってデータの冗長性を引き起こす可能性があります。
雪片のスキーマ
Snowflakeスキーマの一部のディメンションテーブルは正規化されています。 次の図に示すように、正規化はデータを追加のテーブルに分割します。
スタースキーマとは異なり、スノーフレークスキーマのディメンションのテーブルは正規化されます。
例-スタースキーマのアイテムディメンションテーブルは正規化され、アイテムとサプライヤテーブルの2つのディメンションテーブルに分割されます。 これで、アイテムディメンションテーブルには、item_key、item_name、type、brand、supplier-keyの属性が含まれます。
サプライヤキーは、サプライヤディメンションテーブルにリンクされています。 サプライヤディメンションテーブルには、属性supplier_keyおよびsupplier_typeが含まれています。
注-Snowflakeスキーマの正規化により、冗長性が低下するため、保守が容易になり、ストレージスペースを節約できます。
ファクトコンステレーションスキーマ（Galaxy Schema）
ファクトコンステレーションには複数のファクトテーブルがあります。 Galaxy Schemaとしても知られています。
次の図は、2つのファクトテーブル、つまりSalesとShippingを示しています-
売上ファクトテーブルは、スタースキーマのテーブルと同じです。 出荷ファクトテーブルには、item_key、time_key、shipper_key、from_location、to_locationの5つのディメンションがあります。 出荷ファクトテーブルには、2つのメジャー、つまり販売ドルと販売単位も含まれています。 ファクトテーブル間でディメンションテーブルを共有することもできます。
例-時間、アイテム、および場所のディメンションテーブルは、販売ファクトテーブルと出荷ファクトテーブルで共有されます。
