データウェアハウスに多対多の関係を実装する方法にはどのようなものがありますか？
データウェアハウスモデリングの主要なトポロジ（Star、Snowflake）は、1対多の関係を考慮して設計されています。これらのモデリングスキーマで多対多の関係に直面すると、クエリの可読性、パフォーマンス、および構造が大幅に低下します。
データウェアハウスのディメンション間またはファクトテーブルとディメンション間に多対多の関係を実装する方法は何ですか。また、必要な粒度とクエリパフォーマンスに関してどのような妥協点がありますか。
私の経験では、再帰的な階層はこれに取り組む最も実用的な方法です。次の利点があります。
- 無制限の深さ。
- コンパクト。
- 柔軟性。
- 速度。
対照的に、「-to-many」結合のレベルごとに追加のテーブルが必要です。これはハードコーディングされており、スキーマの更新に対して維持するのが困難です。
フィルター選択されたインデックスを使用することで、階層結合の大きなテーブルを専用テーブルよりも優れた速度で実行できます。その理由は、「テーブルをデータテーブルに結合する」と比較して、各結合は「親子」のみであるためです。後者には、処理および格納するインデックスがさらにあります。
私は長年この問題を解決しようと努めてきました。最近、これが私が思いついたものです。
データウェアハウスモデルのM：M関係のいくつかのシナリオ
ほとんどのOLAPサーバーとROLAPシステムには、現在M：Mデータ構造を処理する手段がありますが、注意が必要な警告がいくつかあります。Mを実装する場合は、 Mの関係では、レポートレイヤーとサポートするツールに注目する必要があります。
シナリオ1：ファクトテーブルへのM：Mディメンション
この例として、モーターポリシーの複数のドライバーが挙げられます。ドライバーを追加または削除すると、ポリシー調整トランザクションは、調整に伴って変化するドライバーのリストと関係を持つ場合があります。
オプション1-M：Mドライバー-ファクトブリッジテーブル指定されたポリシーのドライバーxトランザクション行があるため、これには非常に大量のデータが含まれます。 SSASはこのデータ構造を直接使用できますが、ROLAPツールを介してクエリを実行すると遅くなります。
M：Mリレーションシップがファクト行に固有のエンティティ（車のドライバーなど）に基づいている場合、ROLAPツールがM：Mリレーションシップをサポートしている場合（ビジネスでコンテキストを使用するなど）、これはROLAPツールにも適している可能性があります。オブジェクト）。
オプション2-ダミーの '組み合わせ'ディメンションテーブル共通コードのリストをファクトテーブルにマッピングする場合（つまり、リンクされたエンティティがファクト行に固有ではない場合）、次の方法を使用できます。データ量を減らします。このタイプのシナリオの例は、入院患者の訪問のICDコードです。それぞれの入院患者の訪問には、1つ以上のICD診断および/またはそれに対してリストされた手順があります。 ICDコードはグローバルです。
この場合、各ケースのコードの組み合わせの個別のリストを作成できます。個別の組み合わせごとに1行のディメンションテーブルを作成し、組み合わせとICDコード自体の参照テーブルの間にリンクテーブルを作成します。
ファクトテーブルには、「組み合わせ」ディメンションへのディメンションキーを含めることができ、ディメンション行には、実際のICDコードへの参照のリストがあります。ほとんどのROLAPツールはこのデータ構造を使用できます。ツールが実際のM：M関係でのみ機能する場合は、ファクトとコーディング参照テーブル間のM：M関係をエミュレートするビューを作成できます。これは、SSASで推奨されるアプローチです。
オプション1：の利点-適切にインデックスが作成され、M：Mテーブルを介して特定の関係を持つファクトテーブル行を選択することに基づくクエリは、かなり効率的です。
- やや単純な概念モデル
オプション2の利点：-データストレージがよりコンパクト
- 組み合わせを人間が読める形式で「組み合わせ」ディメンションのコードとして提示することにより、直線的な1：M関係をエミュレートできます。これは、M：M関係のサポートが不足しているdumberレポートツールでより役立つ場合があります。
シナリオ2：ディメンション間のM：M関係：
ユースケースを考えるのは難しいですが、ICDコードを使用して、ヘルスケアから何かを再び想定することができます。コスト分析システムでは、入院患者の訪問が次元になる可能性があり、訪問（またはNHSの場合はコンサルタントエピソード）とコーディングの間にM：Mの関係があります。
この場合、M：Mの関係を設定し、人間が読める形式でそれらをベースディメンションに体系化することができます。関係は、ストレートM：Mリンクテーブルを介して、または以前のようにブリッジング「組み合わせ」テーブルを介して行うことができます。このデータ構造は、Business Objectsまたはより高品質のROLAPツールを介して正しくクエリできます。
私の頭の上では、SSASがファクトテーブルまでの関係を考慮せずにこれを消費できることを確認できないので、コーディングとファクトテーブルのM：M関係のビューを提示する必要がありますこのデータでSSASを使用する行。
トランザクションシステムや現在のデータモデルなど、モデルでどのような多対多の関係を念頭に置いているかを正確に知りたいと思います。
通常、ディメンション間の多対多の関係は、ディメンションに関する事実です。顧客が多くの顧客にサービスを提供するいくつかの支店から注文するという事実、またはそのようなもの。それらのそれぞれは事実です。それは発効日またはそのようなものを持っていますが、関係は「事実なし」である可能性があります。関係自体は、顧客および支社以外の次元を持つ場合があります。したがって、これは、中心に（潜在的に事実がない）ファクトテーブルを持つ典型的なスタースキーマです。この星が倉庫内の他の次元の星とどのように関係しているのかは明らかに異なります。さまざまなスターを組み合わせるときはいつでも、ビジネスキーに基づいて行い、不注意なクロス結合を実行しないようにする必要があります。
通常、そのようなディメンションリレーションシップテーブルについては、より大きなファクトテーブルと同じ程度のレポートは作成しません。レポートを作成しても、必ずしもそれほど多くのデータとは限らないため、パフォーマンスに影響を与える傾向はありません。上記の場合、顧客/支店の利用状況を時系列で確認できますが、実際の注文数量に関するより良いデータが注文ファクトテーブルで利用できます。おそらく、顧客や支店などのディメンションも含まれます。これらは、ほとんどの人は多対多を考慮します（注文は顧客から支店への多対多の関係を定義すると見なすことができます）ので、データウェアハウス環境ではより一般的です。多対多モデルで数値集計を行うのは、要約情報をその関係レベル（顧客、支店、月、総売上高）にまとめた場合のみです。要約ファクトテーブルは、1つの多対多に似ています。数値データを持つようになった次元モデル。
ここに、キンボールとその他の関連記事を示します。これらは、提案された多対多の関係をモデル化するのに適用できます。多対多の関係は、問題ドメイン/論理モデルのみの概念であることに注意してください。正規化されたOLTPモデルでは、もちろん、それぞれ1対多のリンクテーブルで処理されます。正規化されていないキンボールデータウェアハウスモデルでは、いくつかの方法があります。これを行うには、1つは基本的にそのリンクテーブルをスターの中心にある事実として扱い、もう1つはフラグ列の配列として扱います。
結局のところ、どのモデルを選択するかは、正確にモデル化しているもの、どのように変化しているか、どのようにレポートしたいかによって異なります。これは、一般に、ディメンションモデリングとデータウェアハウジングが正規化モデルと大きく異なる点です。正規化されたモデルは、データの論理的および理論的な関係に集中します。データウェアハウジングは常に現実的なユースケースを監視し、非正規化してそれらを実行します。
ブリッジテーブルを使用した代替階層のモデリング：
http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf
多対多の関係のための3つのオプション（シェアの数値割り当てに関連付けられています-いくつかの興味深い前後のコメントを参照してください）
http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/
残念ながら、KimballのInformation Week/DBMS mag記事の多くには、良いリンクがありません...
これを解決する方法の1つは、ファクトテーブルに2列の外部キーを2列にして、多対多のリレーションシップを持つことです。