database - スタースキーマ設計

Question

スタースキーマ設計はデータウェアハウスに不可欠ですか? それとも、別の設計パターンでデータウェアハウジングを行うことができますか?

score 96 · Accepted Answer

データウェアハウスシステムにスタースキーマを使用すると、いくつかの利点が得られます。ほとんどの場合、スタースキーマを最上位レイヤーに使用するのが適切です。オペレーショナルデータストア (ODS) を使用することもできます。これは、「現在の状態」を保持し、データのコンフォメーションなどの操作を容易にする正規化された構造です。ただし、これが望ましくない合理的な状況もあります。私は ODS レイヤーを使用するシステムと使用しないシステムを構築する機会があり、それぞれの場合にアーキテクチャを選択する特定の理由がありました。

データウェアハウスアーキテクチャの詳細や、Kimball 対 Inmon の炎上戦争を始めることなく、スタースキーマの主な利点は次のとおりです。

ほとんどのデータベース管理システムには、高速な述語解決のためにビットマップインデックス構造またはインデックスインターセクションを使用する「スター変換」を実行するクエリオプティマイザーの機能があります。これは、スタースキーマからの選択が、選択が解決されるまで (通常はインデックスよりもはるかに大きい) ファクトテーブルにヒットすることなく実行できることを意味します。
スタースキーマのパーティション分割は、ファクトテーブルのみをパーティション分割する必要があるため、比較的簡単です (聖書的に大きなディメンションがある場合を除きます)。パーティションの除去は、クエリオプティマイザがクエリ結果に関与できない可能性があるパーティションを無視できることを意味し、これにより I/O が節約されます。
ゆっくりと変化するディメンションは、スノーフレークよりもスタースキーマで実装する方がはるかに簡単です。
スキーマは理解しやすく、スノーフレークまたは ER スキーマよりも結合が少なくなる傾向があります。あなたの報告チームはこれであなたを気に入るはずです
スタースキーマははるかに使いやすく、(さらに重要なことに) Business ObjectsやReport Builderなどのアドホッククエリツールでうまく機能します。開発者は、これらのツールによって生成された SQL をほとんど制御できないため、クエリオプティマイザーをできる限り支援する必要があります。スタースキーマを使用すると、クエリオプティマイザーが誤動作する機会が比較的少なくなります。

特別な理由がない限り、通常、レポートレイヤーはスタースキーマを使用します。ソースシステムが複数ある場合は、正規化されたスキーマまたはスノーフレークスキーマを使用してオペレーショナルデータストアを実装し、データを蓄積することができます。通常、ODS は履歴を実行しないため、これは簡単です。履歴状態はスタースキーマで追跡され、正規化された構造よりもはるかに簡単に追跡できます。正規化された、またはスノーフレーク化されたオペレーショナルデータストアは、「現在の」状態を反映し、データに固有の履歴ビューを保持しません。

ODS ロードプロセスは、正規化された構造を使用する方が簡単なデータのスクラブと適合に関係しています。ODS にクリーンなデータがあれば、ディメンションとファクトの読み込みは、一般的なメカニズムまたは比較的単純なメカニズムを使用して履歴 (時間の経過に伴う変化) を比較的簡単に追跡できます。これは、スタースキーマを使用するとはるかに簡単に実行できます。多くの ETL ツール (たとえば) には、ディメンションをゆっくりと変更するための組み込み機能が用意されており、一般的なメカニズムの実装は比較的簡単です。

このようにシステムを階層化すると、責任が分離されます。ビジネスとデータのクレンジングロジックは ODS で処理され、スタースキーマロードは履歴状態を処理します。

score 9 · Accepted Answer

データウェアハウスアーキテクチャのどこにスタースキーマ設計を適用する必要があるかについて、データウェアハウジングの文献で進行中の議論があります。

要するに、 Kimballはデータウェアハウスでスタースキーマ設計のみを使用することを非常に強く主張していますが、Inmonは最初に正規化された 3NF設計を使用してエンタープライズデータウェアハウスを構築し、後でデータマートでスタースキーマ設計を使用したいと考えています。

ここに加えて、Snowflake スキーマ設計も別のアプローチであると言えます。

4 番目の設計は、Data Vault Modelingアプローチです。

score 8 · Accepted Answer

スタースキーマは、大量のデータへの高速アクセスを可能にするために使用されます。サブジェクト領域に対して行われる可能性のあるクエリを満足させるために必要な結合の量を減らすことにより、高いパフォーマンスが可能になります。これは、ディメンションテーブルでデータの冗長性を許可することによって行われます。

スタースキーマは、ウェアハウスの最上位レイヤーのパターンであることを覚えておく必要があります。すべてのモデルには、ウェアハウススタックの最下部にステージングスキーマも含まれ、一部のモデルには、すべてのソースシステムが3NFモデル化スキーマにマージされる永続的な変換されたマージステージング領域も含まれます。さまざまな主題分野がこの上にあります。

トップレベルのスタースキーマの代替には、スノーフレークスキーマであるバリエーションが含まれます。いくつかの調査にも役立つ可能性のある新しい方法は、DanLinstedtによって提案されたDataVaultModelingです。

score 7 · Accepted Answer

スタースキーマの特徴は、ほとんどの人がデータウェアハウスでやりたいことの自然なモデルであるということです。たとえば、さまざまなレベルの粒度 (月、日、年など) のレポートを簡単に作成できます。また、一般的なビジネスデータをスタースキーマに挿入することも効率的です。これは、データウェアハウスの一般的で重要な機能です。

必要なあらゆる種類のデータベースを使用できますが、ビジネスドメインを十分に理解していない限り、スタースキーマを使用した場合ほど効率的にレポートを実行できない可能性があります。

score 6 · Accepted Answer

スタースキーマは、データウェアハウスの最後のレイヤーに自然に適合します。どうやってそこにたどり着くかという別の質問があります。私の知る限り、ビル・インモンとラルフ・キンボールの2つの大きなキャンプがあります。スターと一緒に行くことにした場合は、これら2人の理論を確認することをお勧めします。

また、一部のレポートツールは、スタースキーマの設定を非常に気に入っています。特定のレポートツールにロックされている場合、それがウェアハウスでのレポートマートの外観を左右する可能性があります。

score 4 · Accepted Answer

スタースキーマは、通常のデータウェアハウジングのニーズに適合するリレーショナルデータベースの論理データモデルです。リレーショナル環境が与えられている場合、スタースキーマまたはスノーフレークスキーマは、多くの DW 設計方法論に組み込まれた優れた設計パターンになります。

ただし、リレーショナルデータベースエンジン以外にもあり、効率的なデータウェアハウジングに使用できます。多次元ストレージエンジンは、OLAP タスク (TM1 など) では非常に高速な場合があります。この場合、スタースキーマ設計を適用することはできません。特別な論理モデルを必要とするその他の例には、XML データベースや列指向のデータベース (実験的なC ストアなど) があります。

score 3 · Accepted Answer

なしで行うことは可能です。ただし、あなたは自分自身の生活を困難にします-あなたの組織はDWの上にある標準的なツールを使いたいと思うでしょう、そしてそれらのツールはスタースキーマを期待します-ラウンドに四角いペグを取り付けるのに多くの努力が費やされます穴。

データベースレベルの最適化の多くは、スタースキーマがあることを前提としています。DBがスターではないレイアウトで「正しいこと」を実行できるように、最適化と再構築に多くの時間を費やします。

長所が短所を上回っていることを確認してください。

（私が以前そこにいたように聞こえますか？）

-D

score 2 · Accepted Answer

私たちが解決しなければならない問題は 3 つあります。

1) オペレーションソースシステム内およびテーブル間でテーブルを結合し、抽出時にデータをクリーニングし、派生物を作成するなどして、過度のプレッシャーをかけずに運用ソースシステムからデータを取得する方法。

2) 異なるソースからのデータをマージする方法 - 一部のレガシー、一部のファイルベース、さまざまな部門からのデータを、ビジネスをモデル化し、ソースシステムの構造を反映しない、統合された、正確で効率的に保存された全体にマージする方法。システムは比較的迅速に変更/交換されますが、ビジネスの基本モデルはゆっくりと変化することを忘れないでください。

3) ビジネスの特定の人/部門の特定の分析およびレポート要件を満たすために、データをできるだけ迅速かつ正確に構造化する方法。

これら 3 つの非常に異なる問題を解決するには、それらを解決するために異なるアーキテクチャレイヤーが必要です。

ステージングレイヤーソースの構造を複製しますが、ソースから変更されたデータのみが毎晩ロードされます。データがステージングレイヤーから次のレイヤーに取得されると、データは削除されます。クエリは、単純な data_time フィルターを使用した単一テーブルクエリです。ソースへの影響はほとんどありません。

Enterprise Layer ビジネス指向の第 3 正規形データベースです。データはステージングレイヤーからエンタープライズレイヤーに抽出 (およびその後ドロップ) され、そこでクリーニング、統合、および正規化されます。

プレゼンテーション (スタースキーマ) レイヤーここでは、特定の要件を満たすために次元的にモデル化します。結合数を減らすために、データは意図的に非正規化されています。Enterprise Layer の複数のテーブルを占有する階層は、1 つのディメンションテーブルにまとめられ、複数のトランザクションテーブルは 1 つのファクトテーブルにマージされる場合があります。

あなたはいつもこの3つの問題に直面しています。エンタープライズレイヤーを廃止することを選択した場合でも、2 番目の問題を解決する必要がありますが、スタースキーマレイヤーで解決する必要があります。

database - スタースキーマ設計

8 に答える 8

Related

Reference