Analysis Services を使用していますが、ディメンションを設計するときに、自然階層をどこまで構築すればよいのかよくわかりません。
つまり、すべての本物の属性関係を追加したということです。したがって、ほとんどの階層はいずれにしても自然ですが、最も一般的に要求される階層は、中間レベルがゆっくりと変化する属性である 3 つ以上のレベルです。
シナリオはジョブを追跡することです。ジョブには多くの属性があり、それらはすべて静的ですが、債務者属性（つまり、請求書の支払い者）はジョブの過程で変化する可能性があります。したがって、階層は次のようになります。
- Manager -> Debtor -> Job Name
- Director -> Debtor -> Job Name
- Office -> Debtor -> Job Name
- Office -> Manager -> Debtor -> Job Name
したがって、ディメンション内には、ジョブの静的属性で始まり、債務者（徐々に変化します）が続き、ジョブ名（ディメンション キー）が最下部にある階層が多数あります。
したがって、これらの階層を「自然化」するために現在行っていることは、階層内に表示される各債務者に対して、その上位の属性の組み合わせである「偽の」属性を作成することです。たとえば、上記の最初の例では、債務者レベルの属性には、マネージャと債務者 ID のキーがあります。最後の例では、マネージャ レベルのキーにはマネージャとオフィスがあり、債務者レベルの属性にはオフィス、マネージャ、債務者のキーがあります。次に、これらの属性をすべて非表示にして、階層内でのみ使用されるようにします。
そのため、ディメンションははるかに複雑になりますが、クエリのパフォーマンスが向上するというメリットがあります。多くの場合、これは顕著な改善です。複雑さとは別に、現在「債務者」のバージョンが複数あり、属性のキーが債務者の ID ではないため、常に問題が発生します。そのため、ドリルスルーとレポートのアクションに影響し、特定のレベルの動作を変更する場合、特定の種類の計算が困難になります。
私たちが使用するクライアントは、Reporting Services、Excel、および Office Web コンポーネントです。
SQL 2005 の初期バージョンでは、不自然な階層を含む複雑なクエリを実行すると、サーバーが完全に混乱する可能性があると聞いています。これが、不自然な階層を回避するために多大な努力を払ってきたもう 1 つの理由です。
また、Visual Studio では感嘆符のデザイン警告が非常に目立つため、不自然な階層を持つことは非常に悪いことのように思われます。
他のデザイナーはこのような状況でどのような対応をするのでしょうか? 不自然な階層構造を避けるために、どの程度の努力をしますか?
ベストアンサー1
SSAS キューブ上のゆっくり変化するディメンションで階層を作成する方法は、実際のキーをバックグラウンドで隠し、属性をキーであるかのように表示する疑似階層を合成することです。
Office Manager DebtorKey Debtor JobKey Job Name From To
Scunthorpe Bloggs 101 Scarper&Co 2001 Fixit 2010-01-01 2010-01-31
Scunthorpe Bloggs 102 Bodgett 2002 Fixit 2010-02-01 9000-01-01
この階層は、元のゆっくりと変化するディメンション上に構築され、属性関係を実行するために使用されます。階層内のレベルには適切な属性関係が必要です。IIRC では、これらはキューブが「Autoexists」最適化 (ファクト テーブルにアクセスする前にディメンションからのみ空でない状態を解決する) を実行するために必要です。そのため、これらの関係が設定されていないとキューブが遅くなります。
キューブを構築する前に、SQL でディメンションに階層を適用する必要がある場合があります。更新をロードする場合は、キーを静的にしておく必要がありますが、完全な更新を行う時間がある場合は、これは必要ないかもしれません。