複数の OLTP ソースから収集したデータに基づいて、ローカル OLAP キューブを構築しています。私はこれをプログラムで行っており、SSAS や MDX ベースのツールなどのツールにはアクセスできないことに注意してください。
私の要件は、OLTP システム ユーザーの運用要件とは多少異なります。「理論的には」、利用可能な最も原子的な粒度を保持することが望ましいことはわかっていますが、キューブに最低レベルのデータを含める理由はわかりません。
たとえば (単純化しています)、「価格」のようなメジャー フィールドがあります。さらに、各販売ファクトには、次のような値を持つバージョン属性があります。
- リスト（オリジナル/イニシャル）
- 最初の見積もり
- 調整済み見積もり
- 売却
これらは価格設定の内部開発を説明しており、私が作成するレポートにとって重要です.
ただし、レポートの目的で、特定のトランザクションを参照するときは常に、すべてのバージョンの値を知りたいと考えています。したがって、キューブ内の Price by Version などのメジャーをピボットすることを検討しています (バージョンはデータ モデル内の独自のエンティティのままです)。その結果、次のようなメジャーが得られます。
- 価格表
- 見積価格初期値
- 見積価格調整済み
- 販売価格
特定の時点で有効なバージョンは 1 つだけであるため、複数のバージョンを集約する必要はありません。
既知の利点
これはローカル キューブ ファイルになるため、このアプローチにより、価格を異なるバージョン間で比較するために必要ないくつかの計算されたメジャーの作成が簡素化されるようです (MDX でこれを行っていた場合、集計のさまざまなレベルで計算されたメジャーを作成することは問題になりません)。 )
また、レコード数が 3 ～ 6 分の 1 に減少するため、ローカル キューブのパフォーマンスが大幅に向上します。
既知の欠点
データ モデルはビジネス プロセスと一致しますが、キューブはデータを最も原子的なレベルで格納しません。アナリストは、メジャーの選択によってバージョンを区別する必要があり、バージョンでフィルター処理することはできませんでした。使用可能なすべてのバージョンを常に取得していました。
このアプローチにより、小節の数が大幅に増加します。たとえば、追跡する価格は 1 つだけではなく、トランザクションごとに追跡する複数の価格コンポーネントとその他の測定値があります。したがって、トランザクションごとに 12 の真のメジャーを追跡すると、このアプローチを採用すると、最終的に 50 ～ 60 のメジャーになる可能性があります。
非常に大きなファクト テーブルの場合、パフォーマンス上の理由から、ファクト テーブルから可能なすべてのフィールドをディメンションに分割することが望ましいことは理解していますが、ローカル キューブを使用する場合にこれが当てはまるかどうかはわかりません。ローカル キューブの制限を考慮して、特定のキューブ ファイルに入れるレコードは 50,000 未満にします。
私が見逃しているこのアプローチの他の欠点はありますか?