SSIS ETLを構築して、さまざまなデータソース(MySQLから1つ、SQL Serverから2つ)を単一のSQLServerリレーショナルデータベースおよび正規化データベースに統合しました。これを[NDS]と呼びます。
SSIS ETLはタイプ2の更新を処理するため、[NDS]は代理キーを生成し、SCDテーブルには[_EffectiveFrom]タイムスタンプとnull許容の[_EffectiveTo]列が含まれ、すべてをリンクする自然キーと美しい外部キーには制約があります。一緒にデータ。
さて、それからSSASディメンションデータベースを構築したかったのですが、スノーフレークスキーマを設定していることに気付くまでそれほど時間はかかりませんでした。
そこで、新しい[DDS](リレーショナル)データベースを追加して、DSVにフィードするactualディメンションとファクトテーブルを作成することを考えています。 SSASデータベース.
この[DDS]データベースは、ファクトとディメンションを「フラット化」するために、人間が可能な限り非正規化されます([OrderHeaders] + [OrderDetails]を[Orders]ファクトテーブルに、[CustomerStores] + [Customers] +など) [SalesReps]をいくつかの[Customers]ディメンションテーブルに)-これを行うと、SSASでディメンション階層を構築しやすくなるだけでなく、実際のスタースキーマを簡単に作成できるようになります。
ただし、いくつか質問があります。
私はBigMess™の準備をしていますか、それとも正しい方向に進んでいますか?
ご覧のとおり、Kimball Dimensional Modelingの利点の1つは、データウェアハウスの設計が基本的にSSASの設計であるということです。常に例外がありますが、通常はDSVでテーブルを選択し、すぐに階層設計、キューブ関係などに移動できます。
NDSを段階的に廃止することに注意してDDSに移行することをお勧めします。 SCDタイプIIで言及した単純な理由から、すべてのデータ、ETLを複製する理由はありません。およびコードベース。両方を維持すると、多くのメンテナンスとリスクを伴う非常に複雑なソリューションにつながります。これは、回避する必要のある主要なBigMess™です。
理由は次のとおりです。
少量のデータがあり、増加の大きな期待がなく、データウェアハウスに切り替える能力がない場合にのみ、私が提案する代替設計。この提案には、最終的にはDWに入る多くの設計作業が含まれているため、NDSを維持してDDSを作成するのと似ています。
ビューとして明示されたクエリまたはDSVにハードコードされたクエリを使用してキューブを作成できます。
あなたは多くのハードルを克服し、NDSで優れた機能ソリューションを作成したようです。残念ながら、それが行わないのは、次元モデリングが提供する2つの重要なことです。単純なクエリパターンと多次元分析への簡単な変換です。ありがたいことに、ETL設計の多くは、別のテーブル構造をロードするためのテンプレートまたは開始点として役立つ可能性があります。