リレーショナルOLTPデータベースからOLAPキューブに到達するための最良のアプローチは何ですか？

Question

かなり標準的なOLTP正規化データベースがあり、データのさまざまな次元で複雑なクエリ、平均、標準偏差を行う必要があることに気付きました。

だから私はSSASとOLAPキューブの作成に目を向けました。

ただし、キューブを作成するには、データソース構造を「スター」または「スノーフレーク」構成にする必要があると思います（現時点ではそうは思わない）。

SSISを使用して、プライマリOLTP DBで何らかのファクトとディメンションを持つ適切な「スター」構成の別のリレーショナルDBに何らかのETLプロセスを実行し、このDBをデータソースとして使用する通常の手順OLAPキューブ？

ありがとう

Answer 1

はい、それが基本的な考え方です。高度に正規化されたOLTPデータベースを取得し、データをスライスおよびダイシングしてレポートを表示するために、データベースをキューブに非正規化します。論理設計手法は、次元モデリングと呼ばれます。 次元モデリングに関する膨大な情報があります。 /www.kimballgroup.com/html/articles.html "rel =" noreferrer "> Kimballグループ。 Ralph Kimballのこのテーマに関する書籍も優れています。 BIツール自体の詳細については、仮想ラボをご覧ください。 SSIS、分析サービスなど。

Answer 2

答えは「はい、しかし」です。

SSASのディメンションには、一連のフィールドを使用してスライスをフィルター処理できる属性間の関係があります。これらの関係は階層的である場合があります（複数レベルの深さ-1つの属性は親と子を持つことができます。属性のように機能するが、ガイド付きドリルダウンを持つドリルダウンパス（SSASでは階層と呼ばれます）を確立することもできます。

これを行うには、厳密に階層的な関係にあるデータベースでキーを使用できるようにする必要があります（つまり、子が複数の親を持つことができるファジーな関係を持つことはできません）。これはすべてではありませんが、現時点では現実に十分に近いことに注意してください。

これらの階層は、システムによってフラットなデータ構造から構築するか、基盤となるデータソースビューでマークアップされた関係を持つスノーフレークを介して表示できます（DSVはキューブメタデータの一部であり、ある方法でデータをマッサージするために使用できますデータベースビューに似ています）。

スノーフレークは3NFのようなスキーマです（厳密には3NFである必要はありません-実際にはその一部をフラット化できます）。1：Mの関係しかありません。 SSASは、親子（再帰的自己結合を伴う親子関係）やM：M次元（M：M関係-まさにそのように聞こえる）など、いくつかの他の次元構造をサポートできます。このタイプの寸法はより厄介ですが、役に立つかもしれません。

ソースデータにキーがあり、スノーフレークと同等のデータセマンティクスを持つことができる場合、ソースシステム上の一連のデータベースビューを使用してキューブを作成し、十分なスノーフレークのように基礎データを表示できる場合がありますキューブディメンションに使用する形式（実際にこれを数回行いました）。合成キーを多用するスキーマは、これに適しています。

ベンダーまたは他の関係者がソースデータベースにビューを追加できない場合、代わりにデータソースビューを使用できる場合があります。 DSVには、データベースクエリから入力される「名前付きクエリ」と呼ばれる仮想テーブルを含めることができます。

ファクトテーブルはディメンションに結合します。 SSAS2005 +では、ディメンション内の異なる粒度で異なるファクトテーブルを結合できます。通常、データウェアハウスでこれを使用することはあまりありませんが、この機能は、ソースデータを過度にマッサージすることなく使用する場合に役立ちます。

これが機能しない場合は、ETLプロセスを記述してスターまたはスノーフレークスキーマを作成する必要があります。

いくつかの条件：

1. キューブは、基礎となるデータにクエリを発行するだけのリアルタイムモードで実行できます。これには、ソースデータに対して非効率的なクエリが作成されるリスクがあります。そのため、自分が何をしているのかを本当に確信していない限り、お勧めしません。

2. （i）の適切な場合、おそらくキューブをアプリケーションの画面のデータソースとして使用することはできません。ユーザーが画面上で見たいものの平均を計算する必要がある場合は、おそらく画面の後ろのストアドプロシージャで計算する必要があります。

3. これを行う場合は、レプリケートされたデータベースをセットアップし、そこからキューブを作成します。このデータベースを定期的に更新して、ETLプロセスが内部的に一貫したデータセットから実行できるようにします。ライブデータベースから実行する場合、対応するプロセスが実行された後に作成されたレコードに依存して、後でデータが入力されるリスクがあります。
   
   ディメンションロードを実行する状況があります。そして、新しいデータがシステムに入力されます。ファクトテーブルのロードを実行すると、ロードされていないディメンションデータに依存するデータが含まれるようになります。これにより、キューブが破損し、ロードプロセスが失敗します。複製されたデータベースをバッチ更新してETLを実行するか、キューブのロードをオフにすると、この問題が軽減されます。
   
   optiがない場合