データウェアハウスシステムで スタースキーマ を使用すると、いくつかの利点が得られます。ほとんどの場合、それらを最上層に使用するのが適切です。また、オペレーショナルデータストア（ODS）-「現在の状態」を保持し、データ構造などの操作を容易にする正規化された構造を持つこともできます。ただし、これが望ましくない合理的な状況があります。 ODSレイヤーを使用して、または使用せずにシステムを構築する機会があり、それぞれのケースでアーキテクチャを選択する特定の理由がありました。
データウェアハウスアーキテクチャの細かさを調べたり、KimballとInmonのフレーム戦争を開始したりすることなく、スタースキーマの主な利点は次のとおりです。
ほとんどのデータベース管理システムには、高速オプティマイザに Bitmap Index 構造または Index Intersection を使用する「スター変換」を行う機能があります。つまり、選択が解決されるまで、ファクトテーブル（通常はインデックスよりもはるかに大きい）にヒットすることなく、スタースキーマからの選択を行うことができます。
パーティショニング ファクトテーブルのみをパーティション化する必要があるため、スタースキーマは比較的単純です（いくつかの聖書的に大きな次元がない限り）。 パーティション削除 は、クエリオプティマイザーがクエリ結果におそらく参加できないパティションを無視できることを意味し、I/Oを節約します。
緩やかに変化する次元 は、スノーフレークよりもスタースキーマに実装する方がはるかに簡単です。
スキーマは理解しやすく、 snowflake またはE-Rスキーマよりも結合が少ない傾向があります。あなたの報告チームはあなたを愛しています
スタースキーマは、 ビジネスオブジェクト または レポートビルダー などのアドホッククエリツールを使用すると、はるかに使いやすく、（さらに重要なことですが）パフォーマンスが向上します。開発者は、これらのツールによって生成されるSQLをほとんど制御できないため、クエリオプティマイザーにできる限りの支援を与える必要があります。スタースキーマを使用すると、クエリオプティマイザーがそれを誤る可能性が比較的少なくなります。
通常、特別な理由がない限り、レポートレイヤーはスタースキーマを使用します。複数のソースシステムがある場合は、正規化されたスキーマまたはスノーフレークスキーマで Operational Data Store を実装して、データを蓄積することができます。 ODSは通常、履歴を作成しないため、これは簡単です。履歴状態はスタースキーマで追跡され、正規化された構造よりもはるかに簡単です。正規化または雪片化されたオペレーショナルデータストアは「現在の」状態を反映し、データに固有の履歴ビューを超えて保持しません。
ODSロードプロセスは、データのスクラブと適合に関係しています。これは、正規化された構造を使用する方が簡単です。 ODSでクリーンなデータを取得したら、ディメンションおよびファクトのロードは、一般的なメカニズムまたは比較的単純なメカニズムを使用して、比較的単純に履歴（経時変化）を追跡できます。これは、スタースキーマを使用する方がはるかに簡単です。たとえば、多くのETLツールは、緩やかに変化するディメンションのための組み込み機能を提供し、汎用メカニズムの実装は比較的簡単です。
このようにシステムを階層化すると、責任が分離されます。ビジネスとデータのクレンジングロジックはODSで処理され、スタースキーマのロードは履歴状態を処理します。
データウェアハウスアーキテクチャのwhereについて、データウェアハウスのリテラチャーで継続的な議論があります スタースキーマ デザインを適用する必要があります。
要するに Kimball はデータウェアハウスでStar-Schemaデザインのみを使用することを非常に強く推奨しますが、 Inmon は最初に normalized 3NF =設計し、後でデータマートでStar-Schema設計を使用します。
ここに加えて、 Snowflake schema design は別のアプローチであると言うこともできます。
4番目の設計は、 Data Vault Modeling アプローチです。
スタースキーマは、大量のデータへの高速アクセスを可能にするために使用されます。サブジェクト領域に対して行われる可能性のあるクエリを満足させるために必要な結合の量を減らすことにより、高いパフォーマンスが実現します。これは、ディメンションテーブルでデータの冗長性を許可することによって行われます。
スタースキーマはウェアハウスの最上層のパターンであることを覚えておく必要があります。また、すべてのモデルには、ウェアハウススタックの最下部にステージングスキーマが含まれ、一部のモデルには、すべてのソースシステムが3NFモデルスキーマにマージされる永続化変換マージ済みステージング領域も含まれます。さまざまなサブジェクト領域がこの上にあります。
最上位のスタースキーマに代わるものには、スノーフレークスキーマであるバリエーションがあります。何らかの調査にも耐える新しい方法は、Dan Linstedtによって提案された Data Vault Modelling です。
スタースキーマに関することは、ほとんどの人がデータウェアハウスでやりたいことの種類の自然なモデルであるということです。たとえば、さまざまなレベルの粒度（たとえば、月、日、または年）のレポートを簡単に作成できます。また、典型的なビジネスデータをスタースキーマに挿入することも効率的です。これもデータウェアハウスの一般的で重要な機能です。
もちろん、必要な任意の種類のデータベースを使用できますが、ビジネスドメインを十分に理解していない限り、スタースキーマを使用した場合ほど効率的にレポートが実行されない可能性があります。
スタースキーマは、データウェアハウスの最後の層に自然に適合します。別の質問があります。私の知る限り、ビル・インモンとラルフ・キンボールの2つの大きなキャンプがあります。あなたがスターと一緒に行くことに決めた場合/これらの2人の男の理論を見たいと思うかもしれません。
また、スタースキーマのセットアップを好むレポートツールもあります。特定のレポートツールに縛られている場合、それはレポートマートが倉庫でどのように見えるかを駆動する可能性があります。
スタースキーマは、通常のデータウェアハウジングのニーズに適合するリレーショナルデータベースの論理データモデルです。リレーショナル環境が提供されている場合、スターまたはスノーフレークスキーマは、多くのDW設計方法論に組み込まれた優れた設計パターンになります。
ただし、リレーショナルデータベースエンジン以外にもあり、効率的なデータウェアハウジングに使用できます。多次元ストレージエンジンは、OLAPタスク（TM1など）に対して非常に高速です。この場合、スタースキーマデザインを適用できません。特別な論理モデルを必要とする他の例には、XMLデータベースまたは列指向データベースが含まれます） （例：実験的な C-store） ）。
なしでも可能です。ただし、あなたは自分自身の人生を難しくします-あなたの組織はDWの上に存在する標準ツールを使用したいと思うでしょう、そしてそれらのツールはスタースキーマを期待します穴。
データベースレベルの最適化の多くは、スタースキーマがあることを前提としています。最適化と再構築に多くの時間を費やして、DBが非常に優れたレイアウトで「正しいこと」を行えるようにします。
長所が短所を上回ることを確認してください。
（以前に行ったことがあるように聞こえますか？）
-D
解決する必要がある3つの問題があります。
1）テーブル内およびテーブル間を結合したり、抽出時にデータをクリーニングしたり、派生物を作成したりすることにより、過度の圧力をかけずに運用ソースシステムからデータを取得する方法.
2）異なるソースからのデータをマージする方法-一部のレガシー、一部のファイルは、異なる部門から、ビジネスをモデル化し、ソースシステムの構造を反映しない、統合された正確で効率的に保存された全体にシステムの変更/交換は比較的迅速に行われますが、ビジネスの基本モデルはゆっくりと変更されます。
3）可能な限り迅速かつ正確に、ビジネスの特定の人/部門の特定の分析およびレポート要件を満たすようにデータを構成する方法。
これら3つの非常に異なる問題の解決策は、それらを解決するために異なるアーキテクチャ層を必要とします
ステージング層ソースの構造を複製しますが、ソースから変更されたデータのみが毎晩ロードされます。ステージングレイヤーから次のレイヤーにデータが取得されると、データはドロップされます。クエリは、単純なdata_timeフィルターを使用した単一テーブルのクエリです。ソースへの影響はほとんどありません。
エンタープライズ層これは、ビジネス指向の第3正規形データベースです。データはステージングレイヤーからエンタープライズレイヤーに抽出され（その後ドロップされ）、そこでデータがクリーニング、統合、および正規化されます。
プレゼンテーション（スタースキーマ）レイヤーここでは、特定の要件を満たすためにディメンションをモデル化します。結合の数を減らすために、データは意図的に非正規化されます。エンタープライズレイヤーのいくつかのテーブルを占める可能性のある階層は、単一のディメンションテーブルにまとめられ、複数のトランザクションテーブルは単一のファクトテーブルにマージされます。
あなたは常にこれらの3つの問題に直面しています。エンタープライズ層を廃止することを選択した場合、2番目の問題を解決する必要がありますが、スタースキーマ層で行う必要があり、私の見解では、これはそれを行うのに間違った場所です。