多対多の関係とMS SQL Server Analysis Services
この投稿は、MS SQL Server Analysis Servicesを使用した多対多リレーションシップのOLAPキューブ処理などの単純な問題に当てたいと思います。
まず、私がこれにどのようにアプローチしたかについて少し。 当局は、既存のデータベースにある種の分析を展開するのがいいと言った。 小規模なGoogle検索を実施した結果、OLAPテクノロジーは完璧であることがわかりました。 また、MS SQL Serverは会社のサーバーに展開されているため、Analysis Servicesコンポーネントはさらに優れています。
喜んで手をこすりながら、SQL ServerにバンドルされているMicrosoftのチュートリアルを入手しました。 そして2日後、私はすべてができると確信しました。 しかし、それはここではありませんでした...既存のデータベースでは、テーブル間の関係のほとんどは多対多の関係であることが判明しましたが、最初は問題を引き起こしませんでした。 しかし実際には、追加の非常に意味のある手振りなしではできないことがわかります。 そうでない場合、キューブは単に誤った情報を提供します。
RuNetでは、このトピックに関する情報を見つけるのは簡単な作業ではありませんでした。 これは誰にとっても当然のことであるか、スキーは行きません。 しかし、私はまだこのトピックに関する非常にクールな大きな英語のマニュアルを見つけました。 実際、英語を完全に理解している、またはトピックを非常によく理解したい人は、これ以上読むのではなく、リンクをたどってください： http : //www.sqlbi.com/articles/many2many/
以前の私のように、英語の教科書を読む時間がない人は読んでください。 投稿はこのマニュアルの翻訳ではありません。むしろ、最初の例の特定の要約+言及されているマイクロソフトの教科書からのいくつかの基本事項です。
実際に問題は何ですか。 読者がこの投稿（ http://habrahabr.ru/post/67272/ ）に精通していれば、彼はOlapの標準スキームが「スター」スキームと「スノーフレーク」スキームであることを知っています。 しかし、多対多の関係に囲まれている場合はどうでしょうか？
最も簡単なオプションは、ビューを使用して多対多の関係から脱却することです。これは、リクエストの処理速度にプラスの影響を与えます。 出られない？ 正しくしましょう。
問題の声明。 オンラインストア。 MS SQL Serverは、悪名高いM2M接続を備えたデータベースであり、次のようになります。購入識別子のテーブル、カテゴリテーブル（食品、スポーツなど）、およびアカウントテーブルが添付されています。 タスクを複雑にしてみましょう：複数の人が一度に1つのアカウントを使用できるようにします（たとえば、夫と妻が家で購入する）。M2Mを介して、personテーブルがリンクされます。 そして、まったく砂糖ではないように：個人カテゴリテーブルをM2Mを介して個人テーブルにリンクさせます。 そして、私たちは次のことに興味を持っています。人々のどのカテゴリー、より頻繁に購入するのか、いつそれをするのか。
遠い例ですが、問題はまだ見えています：2つのM2M接続を介して将来のディメンションをファクトテーブルに接続する方法は？ それは簡単です、私たちはSSASにどこを見るべきかを伝えます。
ディメンション（タイプ、日付、カテゴリ、人、アカウント）を作成するための準備手順（ http://habrahabr.ru/post/67272/を参照）を完了した後、Salesメジャー（行数）にキューブを作成しようとします。 既定では、Visual Studioは3つのメジャー（タイプ、アカウント、日付）のみを提供します。これらのメジャーのみがメジャーに直接関連しているためです。 キューブを作成したら、残りの2つのメジャーを手で追加します。 さらに、M2M接続の処理を担当するキューブ内に、Bridge Accounts PersonsカテゴリとBridge Persons Categories（両方-テーブルがクリアな行の数）の2つの補助メジャーを作成します。
したがって、次の図が表示されます。
多くの灰色のボックスと、Visual Studioがすでに1つのM2Mリレーションシップを処理しているという事実を確認します。それは、Bridge Persons Categories補助メジャーとAccountsディメンションの間です。 それは良いことですが、十分ではありません。 キューブに今すぐ何かを配るように頼むと、何も得られません。 いいえ、Dates and Accountsディメンションは、PersonsとCategoriesを使用して、残念ながらすべてを実行します。
この誤解を修正するために、リクエストを処理するための情報を探す場所をSSASに示します。 これを行うには、「測定値の使用」タブの灰色のボックスに次のように入力します。灰色のボックスをクリックし、省略記号->接続の種類を選択します。「多対多」を選択します。
出来上がり！ すべてが機能します。 次の写真を見ることができます：
魔法とは何ですか？ 関係に関する情報を検索する場所と方法をSSASに示しました。 注意：たとえば、「ディメンションカテゴリとブリッジアカウント担当者の測定」を正しく入力する前に、交差点「カテゴリディメンションと販売の測定」を正しく入力することはできません。 オプションでは、Bridge Personsカテゴリのみがドロップアウトします。 Visual Studioは別の方法を知らないだけです。 しかし、支援手段は手段でもあります。 そして、それらのパスは、通常の（ターゲット）メジャーの場合と同じ方法で示される必要があります。 テーブルにデータが入力されると、Visual Studioは知識を獲得し、より多くのオプションを提供します。
次に、リレーションシップテーブルの記入方法に関するニーモニックルールを作成します。「ターゲットメジャーとターゲットディメンションの間で、ターゲットメジャーに最も近いメジャーテーブルを選択します。」 したがって、2番目の列のTypeおよびDateディメンションには、本格的な興味深い測定値があり、3番目には補助的なBridge Accounts Personがあることがわかりました。 カテゴリー測定についても同様です。
リンクテーブルに完全に記入することは常に価値がありますか？ いや 興味のない情報を処理する必要はありません。 M2M接続はキューブのパフォーマンスに悪影響を与えるため、可能であればそれらを削除することをお勧めします。
シムのためにすべて。 役立つ投稿があればいいのですが。 少なくとも、以前はまったく同じようなものを探していたと言えますが、見つかりませんでした。 例からデータベースとキューブのソースコードを送信できます。