AdventureworksDW 環境の財務報告設計と構造が似ているディメンション モデルを作成しました。このモデルでは、各アカウントの値がファクト テーブルの単一の値列として保持され、ディメンションによってデータに意味的な意味が与えられます。
このモデルには 1000 を超える列があるため、追加の列を追加または削除するのに適しています。このデザインに関する非常に優れたブログは次のとおりです。
このモデルは次元モデルのクエリにはうまく機能し、次元分析のためにこのモデルをサポートする例もありますが、このモデルは、より広いテーブルを好むように思われるキューブ開発やデータ マイニングの標準ではないことが懸念されます。
質問: この設計は Entity-Attribute-Value (EAV) に分類されますか?
複数のファクト テーブルを使用した設計の方がよいでしょうか。非常に多くのワイド ファクト テーブル (最大 10) で、それぞれ最大 200 ～ 300 列ですが、行は少なくなります。
はるかに広いテーブルでは、パフォーマンスの問題がさらに発生する可能性がありますか?
特定のデザインがEAVモデルと見なされているのは正しいです。
このような設計を使用すると、新しいアカウント、階層などを簡単に追加できます。モデルを更新する必要はありません。
メジャーアプローチごとに1列はお勧めしません。ほとんどのアカウントは、ほとんどの行で null になります。また、このような設計では、メジャーの 1 つだけを取得する必要がある場合でも、すべてのメジャーを読み取る必要があります。
キューブではアカウント ディメンションを多用しています。残念ながら、共有メンバーのようなものは、Essbase のように SSAS で処理するのは簡単ではありません。
親子である Account ディメンションを作成する必要があります。また、通常どおり、ファクト テーブルにこの Account ディメンションのキーが必要です。アカウント ディメンションを使用すると、タイム バランス機能が適切にサポートされます。SSAS のタイム バランス機能を使用すると、カスタム MDX コードよりも高速になるはずです。
現在、単項演算子と親子関係を数式に変換しています。基本的には通常の式があり、階層内の親も式として機能します。最後に、階層をフラット化します。そのため、アカウント ディメンションでドリルダウンすることはできません。アカウント ディメンションを計算エンジンとしてのみ使用しています。適切な階層を持つことも可能ですが、カスタム ロールアップ メンバーと単項演算子を同時に混在させないことにしました。
共有メンバーと、カスタム ロールアップ メンバーとして実装されたすべての式。