# スター・スノーフレークスキーマ ## 定義 スター・スキーマ(star schema)とスノーフレーク・スキーマ(snowflake schema)は、データウェアハウス(通常はリレーショナル)におけるテーブル構造の広く使われる規約であり、ビジネスアナリストのニーズに最適化されている。中心には*ファクトテーブル*(fact table、例: `fact_sales`)があり、各行は特定時点に起きたイベント(例: 顧客の商品購入)を表す。ファクトテーブルの一部の列は価格・原価のような属性値そのものを持ち、他の列は*ディメンションテーブル*(dimension table)への外部キー参照である。各行がイベントを表すため、ディメンションはそのイベントの*誰が・何を・どこで・いつ・どのように・なぜ*(who/what/where/when/how/why)を表現する。テーブル関係を可視化するとファクトテーブルを中心にディメンションテーブルが放射状に取り巻く星形になることが名前の由来である。ETLプロセスがオペレーショナルなシステムのデータをこの形式へ変換する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Stars and Snowflakes: Schemas for Analytics") ## スノーフレークとone big table(OBT) スノーフレーク・スキーマはスター・スキーマの変種で、ディメンションをさらにサブディメンションへ分割する(例: `dim_product`のブランド・カテゴリを別テーブルへ正規化する)。スノーフレークはスターより正規化されているが、スターの方がアナリストにとって扱いやすいため好まれる傾向がある。逆方向の極端な設計が*one big table*(OBT)で、ディメンションテーブルを廃してディメンション情報をファクトテーブルの非正規化列へすべて畳み込む(ファクトとディメンションの結合を事前計算しておく)。OBTはストレージを多く消費する代わりにクエリを高速化できる場合がある。ファクトテーブル・ディメンションテーブルともに実運用では非常にワイド(ファクトテーブルは100列超、時には数百列)になりうる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Stars and Snowflakes: Schemas for Analytics") ## 分析文脈での非正規化の位置づけ スター/スノーフレーク/OBTはいずれも多対一関係(多くの売上が1つの商品・1つの店舗に対応する)を中心とする。原理的には他の関係型も存在しうるが、クエリを単純化するために非正規化されることが多い——たとえば1回の取引で複数商品を購入した場合、その多対多的な性質は明示的に表現されず、ファクトテーブルには商品ごとに別の行が作られ、それらが同じ顧客ID・店舗ID・タイムスタンプを共有する形で表現される。分析文脈でのこうした非正規化は、データが基本的に変化しない履歴ログである(誤りの訂正を除く)ため、OLTPシステムで問題になるデータ一貫性・書き込みオーバーヘッドの懸念があまり生じない。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Stars and Snowflakes: Schemas for Analytics") ## 横断的知見 - (この節は今後、複数ソースの突き合わせで得られた知見を蓄積する。現時点では単一ソースからの知見のみ。関連する[[列指向OLAPデータベース]]は本ページと隣接するが、後者はストレージエンジン(カラム型格納・プルーニング)、本ページはスキーマ設計(ファクト/ディメンション)というレイヤーの違いがあり、両者を橋渡しする実データの突き合わせは今後の課題。) ## 未解決の問い - OBTとスノーフレークのどちらを選ぶかの実務的な判断基準(クエリパターン・ストレージコスト・アナリストのスキルセット)は、本章の記述以上にどこまで体系化されているか。 - スター・スキーマのファクトテーブルと[[イベントソーシングとCQRS]]のイベントログは類似構造を持つとされるが、両者を同一のデータ基盤(例: 列指向OLAPデータベース上のイベントログ)で統一的に扱う実装例はあるか。 - 列指向ストレージ([[列指向OLAPデータベース]])の普及は、スター・スキーマの「結合コストを下げるための正規化度合いの調整」という設計判断そのものをどこまで陳腐化させたか(列指向エンジンは広いファクトテーブルへの結合を高速に処理できるため)。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] - 概念: [[列指向OLAPデータベース]] / [[イベントソーシングとCQRS]] / [[導出データ]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]]("Stars and Snowflakes: Schemas for Analytics")