SSAS と書き戻し操作を使用してカスタム BI アプリケーションを設計しています。基本的に、ユーザーは、営業担当者とテリトリーの現在の状態を分析し、"what if" シナリオでテリトリーの境界と割り当てを微調整し、そのシナリオが気に入った場合は変更をコミットします。各ユーザーは上司に見せるためのさまざまなシナリオを持つことができ、シナリオが承認されると、それが販売組織の新しい現在の状態になります。これを実現するために、ROLAP と HOLAP の組み合わせを多用します。
シナリオ機能の実装方法で上司と意見が食い違う。彼は SSAS がどのように機能するかについてエグゼクティブ レベルの要約を持っており、データベース アプリケーションを構築してきた彼の長年の経験を活用していますが、私は何週間も SSAS を試し、Kimball の聖書を読んでいますが、私はまだ多次元モデリングに比較的慣れていません。次のような私のアイデアを承認、拒否、または微調整するために何をしているのかを知っている人が必要です。
おおよそ次のようなタイプ 2 の SCD テーブルがいくつかあります。
Create Table SlowlyChangingDimension
(
SurrogateId Int Identity(1,1) Not Null,
NaturalId NVarChar(50) Not Null,
BeginDate DateTime Not Null,
EndDate DateTime Not Null,
IsCurrent Bit Not Null,
IsCommitted Bit Not Null,
-- Data columns
Constraint PK_SlowlyChangingDimension Primary Key Clustered (SurrogateId),
Constraint Ck_SlowlyChangingDimension_DateRange Check (EndDate > BeginDate)
)
BeginDate、EndDate、および IsCurrent 列を適切に使用して履歴データを維持しています。新しいデータが入ってくると、オブジェクトの現在のバージョンを終了し、新しい現在のバージョンを作成します。
シナリオを処理するために、SCD 内のオブジェクトの特定のバージョンにタグを付けるために使用するシナリオ テーブルを追加します。新しいシナリオが作成されたら、SCD 内の各オブジェクトのコミットされたバージョンにシナリオのタグを付けます。コミットされたバージョンはこのように複数のシナリオに存在できるため、M2M リンクはブリッジ テーブルによって容易になります。
シナリオが作成され、その初期状態がコミットされた状態と同じになったので、ユーザーは変更を開始できます。変更は、IsCommitted = False の追加の現在の行として SCD テーブルに格納されます。変更が行われると、シナリオ ブリッジ テーブルが更新され、オブジェクトのコミットされたバージョンへのリンクが削除され、オブジェクトの新しい代替バージョンにリンクされるようになります。シナリオがコミットされると、コミットされた古いバージョンが終了し、現在の代替バージョンがコミットされ、シナリオとそのシナリオの SCD テーブル内の行へのすべてのリンクが削除されます。
私には、これは合理的に聞こえます。しかし、私の上司は、シナリオ データが別のテーブルに格納され、別のキューブを通じて表示されるように、新しいシナリオが作成されるときに実行時に追加のスキーマ要素を作成したいと考えています。実行時にスキーマを変更することはアンチパターンであると確信しているため、これは私を間違った方法でこすります。