スター スキーマは、ディメンション テーブルとファクト テーブルで構成されます。
ファクト テーブルには、各ディメンションの外部キーが含まれており、それに加えて「メジャー」が含まれています。この測定値は正確には何を構成していますか?
保存されているのは集計関数の答えですか?
スター スキーマは、ディメンション テーブルとファクト テーブルで構成されます。
ファクト テーブルには、各ディメンションの外部キーが含まれており、それに加えて「メジャー」が含まれています。この測定値は正確には何を構成していますか?
保存されているのは集計関数の答えですか?
基本的にはい。
単純なグリッドがある場合
Salary Januari Februari March April May June
Q1 Q2
Me 1100 1100 1100 1100 1500 1500
Collegue1 2000 2000 2000 0 0 0
時間は、2つのレベルを持つ階層的な次元です(表示)。表示されている他のディメンションは「EmployeeID」です。他のディメンション(図には示されていません)は、PointOfView(予算/実績など)にある可能性があります。
金額(1100など)はメジャーであり、ファクト(ファクトの非識別部分)を構成します。ディメンションは、さまざまなレベルで各メジャーの統合関数を定義します(例:Amount(Q1)== SUM(Amount(January ... March)))。統合の動作はメジャーによって異なることに注意してください(たとえば、所得税の%は合計されませんが、何らかの方法で統合されます。OLAPキューブの設計の技術はどの程度正確ですか)。
(雑学:MDXを使用して、前の四半期と比較した金額の偏差、四半期全体の平均給与などを照会する測定値を計算できます。ここでも、統合式には考慮が必要です) 。
この時点で、統合ルールの設計はルールが計算される順序に依存することがわかります(「給与偏差%」の式が最初に評価されてから統合される場合は、平均化する必要があります。ただし、生のSALARYメジャーは、最初にQ1、Q2レベルに統合(合計)され、次に、導出されたメジャーは、最低レベルのように計算できます。
これで、キューブの保存方法を決定するときに、物事がより楽しくなります。基本的に2つの方法があります。
ほとんどのOLAPエンジンがハイブリッド方式(HOLAP)に収束していることは誰もが驚くことではありません。ハイブリッド方式(HOLAP)では、頻繁にアクセスされる統合レベルの重要な部分が事前に計算されて保存され、その他の部分はその場で計算されます。
基になるデータを標準のRDBMS(ROLAP)に保存するものもあれば、保存しないもの(OLAP)もあります。高性能に重点を置いたエンジンは、すべてのデータを事前に計算されたキューブに保持する傾向があります(非常にまばらな次元の場合は「多くの小さなサブキューブ」にのみ頼ります)。
まあ、とにかく、これは少し暴言でした。データウェアハウジングとOLAPを実行するときにかつて学んだことをとりとめのないものにするのが好きでした
隣接するツリー モデルの場合は、タイトル フィールドまたはデータを含むその他のフィールドになります。
事実と測定は同義語です。事実はデータです: 販売、生産、配送など。ディメンションは事実 (時間、場所、部門) に関連付けられた情報です。
メジャーは 2 種類のうちの 1 つです。
対策。測定。単位付きの数字。ドル、重量、体積、サイズなど。測定。
集計します。データの合計 (場合によっては平均)。ウェアハウス内のデータである可能性があります。パフォーマンス上の理由から事前に計算された集計です。または、詳細すぎて取得できない (または不要な) データである可能性もあります。音量が大きすぎるとか。
ファクト テーブルで最も重要なことは、キー以外の測定値が単位付きの実際の測定値であることです。