データウェアハウスに多対多の関係を実装する方法は何ですか？

データウェアハウスモデリングの主要なトポロジ（スター、スノーフレーク）は、1対多の関係を念頭に置いて設計されています。これらのモデリングスキームで多対多の関係に直面すると、クエリの可読性、パフォーマンス、および構造が大幅に低下します。

ディメンション間、またはファクトテーブルとデータウェアハウスのディメンションの間に多対多の関係を実装する方法と、必要な粒度とクエリパフォーマンスに関してどのような妥協がありますか？

私の経験では、再帰階層はこれに取り組む最も実用的な方法です。次の利点があります。

1. 無制限の深さ。
2. コンパクト。
3. 柔軟性。
4. 速度。

対照的に、「-to-many」結合の各レベルに追加のテーブルが必要です。これはハードコーディングされており、スキーマの更新に対して維持するのは困難です。

フィルター選択されたインデックスを使用することにより、階層結合の大きなテーブルは専用テーブルよりも優れた速度で実行できます。その理由は、「テーブルをデータテーブルに結合する」と比較して、各結合が「親子」のみであるためです。後者には、処理および保存するインデックスが多くあります。

私は長年、この問題を解決しようとしてきました。最近、これが私が思いついたものです。

データウェアハウスモデルのM：M関係のいくつかのシナリオ

ほとんどのOLAPサーバーとROLAPシステムには、現在M：Mデータ構造を処理する手段がありますが、注意が必要な注意事項がいくつかあります。M：M関係を実装する場合は、レポートレイヤーとサポートするツールに注意する必要があります。

シナリオ1：ファクトテーブルへのM：Mディメンション

この例として、モーターポリシーの複数のドライバーがあります。ドライバーを追加または削除すると、ポリシー調整トランザクションは、調整によって変更されるドライバーのリストと関係を持つ場合があります。

オプション1-M：Mドライバー-ファクトブリッジテーブル これには、特定のポリシーのドライバーxトランザクション行があるため、非常に大量のデータが含まれます。SSASはこのデータ構造を直接使用できますが、ROLAPツールを使用したクエリは低速です。

M：M関係がファクト行に固有のエンティティ（車の運転手など）に基づいている場合、これはROLAPツールにも適している可能性があります。ROLAPツールがM：M関係をサポートしている場合（ビジネスでのコンテキストの使用など）オブジェクト）。

オプション2-ダミーの「組み合わせ」ディメンションテーブル 共通コードのリストをファクトテーブルにマッピングする場合（つまり、リンクされたエンティティがファクト行に固有ではない場合）、データボリュームを削減する別のアプローチをとることができます。このタイプのシナリオの例は、入院患者の訪問でのICDコードです。各入院患者の訪問には、1つ以上のICD診断および/または手順が記載されています。ICDコードはグローバルです。

この場合、各ケースのコードの組み合わせの個別のリストを作成できます。個別の組み合わせごとに1行のディメンションテーブルを作成し、組み合わせとICDコード自体の参照テーブルの間にリンクテーブルを作成します。

ファクトテーブルには「組み合わせ」ディメンションへのディメンションキーを含めることができ、ディメンション行には実際のICDコードへの参照のリストがあります。ほとんどのROLAPツールは、このデータ構造を使用できます。ツールが実際のM：M関係でのみ機能する場合、ファクトとコーディング参照テーブルの間のM：M関係をエミュレートするビューを作成できます。これは、SSASでの推奨アプローチです。

オプション1の利点： -M：Mテーブルを介して特定の関係を持つファクトテーブルの行を選択することに基づいた、適切にインデックス付けされたクエリは、かなり効率的です。

• ややシンプルな概念モデル

オプション2の利点： -データストレージがよりコンパクトに

• 「組み合わせ」ディメンションのコードとして人間が読み取れる形式で組み合わせを提示することにより、ストレートな1：M関係をエミュレートできます。これは、M：M関係のサポートが不足している暗いレポートツールでより役立つ場合があります。

シナリオ2：ディメンション間のM：M関係：

ユースケースを考えるのは難しいですが、ICDコードを使用して、ヘルスケアから何かを思い描くことができます。コスト分析システムでは、入院患者の訪問がディメンションになる場合があり、訪問（またはNHSスピークのコンサルタントエピソード）とコーディングとの間にM：Mの関係があります。

この場合、M：M関係を設定し、場合によってはベースディメンション上で人間が読める関係をコード化できます。関係は、ストレートM：Mリンクテーブルを介して、または以前のようにブリッジング「組み合わせ」テーブルを介して行うことができます。このデータ構造は、Business Objectsまたは高品質のROLAPツールを使用して正しく照会できます。

頭から離れて、SSASがファクトテーブルに直接関係を持たずにこれを消費できるのを見ることができないので、コーディングとファクトテーブル間のM：M関係のビューを提示する必要があります。このデータでSSASを使用する行。

トランザクションシステムまたは現在のデータモデルのように、モデルでどのような多対多の関係を念頭に置いているのかを正確に知りたいと思います。

通常、ディメンション間の多対多の関係は、ディメンションに関する事実です。顧客が多くの顧客にサービスを提供する複数の支店から注文するという事実、またはそのようなもの。それらはそれぞれ事実です。発効日などがありますが、関係は「事実なし」である可能性があります。関係自体は、顧客とブランチオフィス以外の次元を持つ場合があります。そのため、これは、（事実上ない可能性のある）ファクトテーブルを中央に持つ典型的なスタースキーマです。この星が倉庫内の他の次元の星とどのように関係するかは、明らかに異なります。異なるスターを組み合わせるときはいつでも、ビジネスキーでそれを行い、意図しないクロス結合を実行していないことを確認する必要があります。

通常、このようなディメンションリレーションシップテーブルについては、より大きなファクトテーブルと同じ程度にレポートすることはありません。レポートする場合、データ量は常に同じとは限らないため、パフォーマンスに影響する傾向はありません。上記の場合、顧客/支店の使用率を経時的に見ることができますが、実際の注文数量に関するより良いデータが注文ファクトテーブルで利用可能になり、おそらく顧客、支店などのディメンションも含まれますほとんどの人は多対多を検討します（ただし、注文は顧客から支店への多対多の関係を定義すると見なすことができます）ので、データウェアハウス環境ではより一般的です。その関係レベル（顧客、支店、月など）に要約情報をロールアップした場合にのみ、多対多モデルで数値集計を実行します。

以下に、Kimballからの関連記事と、提案された多対多の関係のモデル化に適用されるその他の記事を示します。多対多の関係は、問題のドメイン/論理モデルのみの概念であることに注意してください。正規化された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雑誌記事の多くには、もはや良いリンクがありません...

これを解決する1つの方法は、ファクトテーブルに、多対多のリレーションシップを持つ2次元からの外部キーの2列のみを持たせることです。