たとえば、私たちの会社RetailIQの開発を選択しました。これは、薬局のネットワークの小売売上レシート、配達および在庫の詳細な分析のBIシステムです。 トピックのコンテキストを一般的に理解するために、すべてのデータは会計システム（1C、M-Pharmacyなど）からダウンロードされ、検証され、その後の多次元OLAPキューブの構築で特別なデータベースに追加されます。 ETLを使用したソース（会計システム）を使用して、ストレージにデータを転送し、それに基づいてキューブを構築します。これについては後で説明します。
データマッピング
表示されるデータの正確性とSSASキューブの処理時間はデータショーケースに依存するため、データショーケースの構築は最も重要なステップです。
このステップでは、表示する必要があるデータ（残高、売上など）およびセクション（製品、日付、従業員、支店など）を決定します。
データソースは、どのデータを取得できるかによって決まります（ファイル、Webサービス、その他のデータベース）。 整合性を維持するために、受信したデータでどのような変換を行う必要があるか。
データショーケースも準備されています。これは、異なるソースからのデータがマージされるリレーショナルデータベースです。 データショーケースを作成するには、スタースキームとスノーフレークの 2つのデータストレージスキームを使用できます。 この記事では、両方のスキームについて説明しています。 特定のケースでどのスキームを適用するかは、データに大きく依存します。 ただし、通常はスノーフレークスキームを使用します。これは、私たちの意見では、これによりデータ操作が簡単になるためです。
ヒント＃1キューブのソースはビューである必要があります
私たちの意見では、OLAPキューブのソースは、テーブルに直接バインドするのではなく、表現の形で行うのが最適です。 これにより、OLAPキューブ自体を変更せずにソースを変更できます。 また、SSASプロジェクトのDSVに変更を加えるのは問題があるため、データソースビュー自体でリクエストを行わないことをお勧めします。
ETLを作成する
ETLは、特定のビジネスルールに従ってデータを転送および変換するプロセスです。 このステップでは、いくつかの推奨事項があります。
ヒント＃2 Line NA
「データなし」（NA）要素がディメンションテーブルに追加されます。 これらは、ソースのファクトテーブルにバインドされていないデータへのバインドとして機能します。 たとえば、特定できない製品の売上がある場合、キーにNAを追加します。 ディメンションに他のテーブルへのバインドがある場合、それらのテーブルではNA要素を定義し、ディメンションのNA要素でこれらのレコードへのバインドを指定する必要もあります。
たとえば、CarTypeテーブルとCarMarkテーブルへのバインディングを持つCarテーブルがあるとします。 このようなことをします：
INSERT INTO CarType (ID, Name) VALUES (0, 'NA') INSERT INTO CarMark (ID, Name) VALUES (0, 'NA') INSERT INTO Car (ID, Name, CarTypeID, CarMarkID) VALUES(0, 'NA', 0, 0)
ヒント＃3サロゲートキー
ソースに主キーがある場合でも、代理キーを生成することをお勧めします。 ソースの主キーを「Native Key」という名前の測定テーブルの別のセルに書き込むことをお勧めします。 何が得られますか：
- NA要素を決定できます
- さまざまなソースからの主キーが一致する場合があります
- データベース内のプライマリキーの形式を自由に選択できます（たとえば、ソースでINTが使用されている場合でも、Guidを使用できます）。
ヒント＃4 ETLパッケージでNA値を設定する
ファクトのソースでセル値CarIDおよびEmployeeIDにNULLが含まれている場合、または測定値に含まれていないデータがある場合、次の変換を使用します。
両方のルックアップで、フィールド「一致するエントリのない行の処理方法を指定する」は「失敗を無視する」に設定されます。 したがって、不明なキーはNULLになります。 「ディメンションにNAを設定」要素では、NULLが各ディメンションのNA値に置き換えられます。
ヒント＃5 ETLの文書化
パッケージが完了したら、次の.xlsファイルを作成します。これは、ETLパッケージのドキュメントとして機能します。
この表から、データが「どこから」「どこに」流れるかを簡単に判断できます。
キューブを作成する
キューブは作業の終点です。 それを作成するために、いくつかのヒントも用意されています。
日付と時刻は異なる次元に分離する必要があります。
通常、SSASを使用して作成されたOLAPキューブは、多数のレコードを含むディメンションではうまく機能しません。 私たちの意見では、日付と時刻が同じ次元にある場合を避けることが最善です。 秒まで正確なDate-Timeディメンションを作成するとします。 10年にわたるこのディメンションのレコードは、10年* 365日* 24時間* 60分* 60秒= 315,360,000≈315百万レコードです。
キューブのタスクは運用ベースと比較して異なるため、分析データベースでは最大1秒の精度は通常必要ありませんが、キューブに時間を追加する必要がある場合は、別のディメンションでこれを行うことをお勧めします。
ヒント＃6同じ要素を持つ階層の作成
階層を構築するタスクがあるとします：フォームのテーブルからCar type-> Car make-> Car name：
| カリード | お名前 | カータイプ | カータイプ | カーマーク | カーマーク |
| 1 | メルセデスベンツF 800スタイル | 1 | スポーツ | 1 | メルセデス |
| 2 | スマート | 2 | マイクロカー | 1 | メルセデス |
この場合のCarIDはディメンションのキーになり、CarTypeIDとCarMarkIDはディメンションの属性です。 キューブを処理した後、次のものが得られると仮定します。
しかし、残念ながら、メルセデスグループはSportまたはMicrocarに属します（最初に処理される行によって異なります）。 この制限は、属性に複合キーを使用することで回避できます。 CarTypeID + '_' + CarMarkIDという形式のCarMark属性のキーを作成しましょう。 その結果、キューブの入り口で次の表のようなものが得られます。
| カリード | お名前 | カータイプ | カータイプ | カーマーク | カーマーク |
| 1 | メルセデスベンツF 800スタイル | 1 | スポーツ | 1_1 | メルセデス |
| 2 | メルセデスベンツF 800スタイル | 2 | マイクロカー | 1_2 | メルセデス |
その結果、必要な階層を取得します。
また、各ディメンション属性について、可能な限り、個々のソースから名前とキーを決定することをお勧めします。
OLAPキューブを構築するための最も簡単な推奨事項のみを提供しました。これにより、BIソリューションに柔軟性と拡張性を追加できます。 役立つヒントを見つけて、分析ソリューションを簡単に作成できるようにしてください。
ソース
キューブに関する基本情報は、記事habrahabr.ru/post/66356にあります。
データウェアハウスETLツールキット：データの抽出、クリーニング、適合、配信のための実用的なテクニック
Microsoft SQL Server 2008 Analysis Servicesによるエキスパートキューブ開発
www.sql.ru- :)
