基本コンセプト
情報システムは、ビジネスプロセスの実行を支援するもの（業務システム, Operational system）と、ビジネスプロセスの分析を支援するもの（分析システム, Analytic System）の 2 つに大別される。
これらのシステムは、それぞれ異なる目的と要件を持っているため、設計アプローチも異なる。
ディメンショナルデザイン
特に分析システムの設計において、ディメンショナルデザインの原則が重要な役割を果たしている。ディメンショナルモデリングは、分析システムの特有の要件に直接対応するために発展してきた手法であり、ビジネスプロセスの評価方法と各測定値のコンテキストの記述を明確に表現することを目的としている。
Ralph Kimball の著作「The Data Warehouse Toolkit, 1996」を通じて広く知られるようになったディメンショナルモデリングの原則と手法は、データウェアハウスとビジネスインテリジェンスの分野で広く採用され、現在に至るまで重要な役割を果たしている。
分析システムとのやり取りは、ビジネスプロセスに関するデータを取得するクエリ（DQL）によってのみ行われ、情報の作成（DDL）や変更（DML）は行われない。
ディメンショナルデザインは、個々のトランザクションだけでなく、大量のトランザクションにアクセスする可能性のあるクエリに対して最適化されている。同時並行的で高性能な更新をサポートすることに負担をかけることはない。また、業務システムが情報を変更したり削除したりしても、履歴データ（historic data）を維持することができる。
スタースキーマ
ディメンショナルデザインでは、ビジネスプロセスの評価に使用される数値データを「ファクト」と呼び、それらの測定値に関連する情報を「ディメンション」と呼ぶ。例えば、販売データを分析する際、「売上金額」はファクトに当たり、「商品名」や「販売日」、「店舗名」などはディメンションに当たる。
このようなデータをリレーショナルデータベースで表現する際、ディメンショナルデザインでは、関連するディメンションをディメンションテーブルの列としてグループ化し、ファクトをファクトテーブルの列として格納する。ファクトテーブルを中心に置き、ディメンションテーブルを周りに配置すると、まるで星やアスタリスクのような形に見えることから、この設計は「スタースキーマ」と呼ばれてる。
スタースキーマを採用することで、データの構造が分かりやすくなり、分析のためのクエリを効率的に実行できるようになる。また、ユーザーにとってもデータの関係性が理解しやすくなるため、ビジネス上の意思決定に役立てやすくなる。
キーと履歴データ
スタースキーマにおいて、各ディメンションテーブルにはサロゲートキー（SK）が割り当てられる。このキーは、データウェアハウスまたデータマート専用に作成された一意の識別子であり、ス タースキーマを構築する過程で割り当て管理される。サロゲートキーにはビジネス上の意味はなく、通常は整数値やハッシュ値が使用されている。
一方、ディメンションテーブルには、業務システムで何かを一意に識別するためのキー列も含まれている。これらのキー列は、ナチュラルキー（NK）と呼ばれる。
後述するが、ファクトテーブルにもサロゲートキーまたはナチュラルキーが含まれることもある。
また、サロゲートキーとナチュラルキーを分離することで、元の業務システムが変更を追跡できない場合でも、データウェアハウスで変更を追跡することができる。例えば、顧客情報が変更された場合、業務システムでは同じ顧客 ID のデータが上書きされるかもしれないが、スタースキーマでは同じ顧客 ID でも異なるサロゲートキーを割り当てることで、複数のバージョンを保存することができる。
ディメンションテーブル
ディメンションテーブルは、スタースキーマにおいてファクトに関連する情報を提供する役割を持っている。ディメンションは、ファクトに対するコンテキストを表現し、クエリやレポートにおいて集計のレベルを指定したり、フィルタリングを行ったりするために使用される。
通常、ディメンションテーブルは第 3 正規形ではないが、これはディメンショナルモデルが ER モデルとは異なる目的で使用されるからである。ただし、場合によってはディメンション内で追加の正規化を行うこともあり、この場合「スノーフレークスキーマ」と呼ばれる。
ディメンションのグループ化は、設計の際に慎重に検討する必要がある。例えば、ある情報を既存のディメンションの一部として扱うべきか、別のディメンションとして扱うべきかなどの判断が求められる。
ファクトテーブル
スタースキーマの中心にあるのがファクトテーブルである。ファクトテーブルは、ファクトを表現するだけでなく、関連する各ディメンションテーブルを参照するためのサロゲートキーも含んでいる。例えば、注文に関するスタースキーマでは、注文数量、売上、利益などのファクトと、ユーザー、商品、日付、注文状況などを参照するサロゲートキーが含まれている。
ファクトテーブルの各行は、特定の詳細レベルでファクトを保存する。この詳細レベルは、ファクトテーブルの「粒度」と呼ばれ、粒度が細かいほど多角的に分析することができるので、可能な限り最小粒度で格納することが求められる。ただし、粒度が細かすぎるとデータ量が膨大になり、パフォーマンスに影響を与える可能性があるため、適切な粒度を選択することが重要である。
また、ビジネス要件によっては、ファクトテーブルにもディメンジョンが含まれることがある。ファクトテーブルのディメンションは「Degenerate Dimension（退化ディメンション？）」と呼ばれ、対応するディメンショ ンテーブルを持たない非キー属性で、ファクトテーブルの一意識別子やパーティション分割、セマンティックレイヤーのキーとして利用される。
Degenerate Dimension は、ファクトテーブルのサロゲートキーを生成するために使用されることもある。例えば、注文番号や注文明細番号などの一意識別子を使用して、ファクトテーブルの各行に対応するサロゲートキーを作成できる。これにより、ファクトテーブルのユニークテストやセマンティックレイヤーのメトリクスの定義をしやすくなる。