6.2データウェアハウスと分析基盤

日々の受発注や在庫更新を処理するOLTP（オンライン・トランザクション処理）のデータベースは、更新の整合性と応答速度を優先して正規化された設計になっています。しかし「過去3年間の地域別・商品カテゴリ別の売上推移を集計する」といった分析クエリをOLTPのスキーマにそのまま投げると、複数表の結合が多重化し性能が悪化しがちです。データ基盤担当には、分析目的に応じてOLTPとは別のスキーマ・別の基盤（データウェアハウス）を設計し、どのタイミング・方式でデータを統合するかを判断する能力が求められます。この節ではその設計判断の型を学びます。

6.2.1スタースキーマとスノーフレークスキーマ

• ファクトテーブル＝分析対象となる数値の実績データ（売上金額・数量等）を格納する中心的な表。ディメンションテーブル＝分析の切り口（「いつ」「どこで」「誰が」「何を」にあたる時間・店舗・顧客・商品等の属性）を格納する表。ファクトテーブルは各ディメンションテーブルの主キーを外部キーとして持つ。
• スタースキーマ＝1つのファクトテーブルを中心に、複数のディメンションテーブルが直接放射状に接続する構造（星形）。ディメンションテーブルは非正規化されており（例：店舗表に地域名・都道府県名まで冗長に持つ）、結合数が少なく分析クエリの性能が高いが、冗長データの分だけ格納容量は増える。
• スノーフレークスキーマ＝ディメンションテーブルをさらに正規化し、階層構造（例：店舗表→地域表→都道府県表）に分割した構造（雪の結晶状）。格納容量は節約できるが、分析クエリで結合階層が増えスタースキーマより性能面で不利になりやすい。更新頻度が高いディメンションを持つ場合や格納容量を抑えたい場合に選ぶ。