DWH層の(物理)データモデルとしてはInmon, Kimball, Data Vaultの方式が有名
高度に正規化されたデータモデリングとは違い、Star Schema では fact テーブルを dimension テーブルに囲まれている状態。(その形がstar likeなのでStar Schemaと聞いたことがある。) その結果、ほかの出データモデルとは違い join の回数が少なくてよく、これによりクエリのパフォーマンスを向上させることができる。別のメリットとしては、異論はあるかもしれない(arguably)が、ビジネスユーザーにとって理解しやすく使いやすいことがあげられる。(data vaultはビジネスユーザーはクエリ出来るのか？)
cf. https://www.thoughtspot.com/data-trends/data-modeling/dimensional-data-modeling
Star Schema は特定のビジネスレポートと対応するようのものではない。とはいえ、下流のデータマートやBIツールに直接つなげるようにレポートをモデリングできる。Star Schemaにおいてはビジネスロジックにおける性質や fact をきちんと捉え、かつビジネス上重要な問いかけに対して答えられるように柔軟である必要がある。
Star Schemaにおいては原則単一のfactテーブルを持つ。とはいえ異なるfactテーブルに対応する複数のStar Schemaを作りたくなることがあるかもしれない。その場合はdimensionテーブルが再利用可能である可能性があるので、できるだけdimensionテーブルを減らすように努めないといけない。Star Schemaをまたいで利用可能なものを適合ディメンジョンと呼ぶ。（conformedだが、共通と訳されていることもある）
適合ディメンジョンではStar Schemaをまたいで複数のfactテーブルをjoinさせることが可能になる。Kimball方式ではデータは冗長でも構わないが、ビジネス定義やデータの整合性がドリフトしないよう（ドリフトの訳が難しい、変化するとか？、実務ベースから想像するなら部署によって定義が違うとか、いつの間にか用語の意味が変わっていたとか？）に注意する必要がある。
このKimball方式のモデリングはバッチデータのみに有効でストリーミングデータには有効ではない（なぜ？）Kimball方式のモデリングはとても人気のあるモデル方式である（確かにData Vault運用していますはほとんど聞かない…）
Star Schemaのまとめ
pros