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


25

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

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


質問をより明確に述べる必要があります。これがおそらく4日以降誰も答えていない理由です。私の答えに答えてあなたが述べることはあなたの元の質問と同じではありません。
IamIC

@IanC編集済み。良いですか?
ブライアンボールサンスタントン

完璧な:)
IamIC

回答:


17

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

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

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

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

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


1
「これらの多対多をモデル化する方法にはどのようなものがあり、そのパフォーマンスと粒度への影響は何ですか?」モデリングについて回答しました。投票する必要はありません。
IamIC

4
必要なデータをさらに提供する必要があります。再帰的な階層構造を通じて、あなたが述べた正確な問題を克服しました。しかし、データとその接続について何も知らなければ、答えることは非常に困難です。
IamIC

2
はい、彼らはこれをネイティブにモデル化しません。テーブルと結合をもう1つ追加して、多対多を達成するとどうなりますか?RDBMSでは、テーブルの構造に関係なく、多対多の2つの結合が行われます。近道はありません。唯一の可能な例外は、PostgreSQLまたはCaché/ Mの配列です。
IamIC

1
(実際、再帰的な階層構造は良い考えです。)問題を解決した1つの方法は、ディメンション内の可能な多対多リレーションシップのリストを事前計算し、それを通常のディメンションテーブルに参照してから、ファクトテーブルをそれに結合することでした集計ディメンションテーブル。「再帰的階層」の答えは、もう1つの有用な設計上の答えです。これらのさまざまなハッキングのパフォーマンスへの影響に関する研究があったのだろうか?
ブライアンボールサンスタントン

3
@Brianは、有用な回答に対する投票を忘れないでください。コミュニティの作成に役立ちます。あなたの質問に答えるために、私はこれらのハックに関する調査に出くわしませんでした。ただし、「より高速なのは、再帰CTEか手動のツリー構築か?」です。前に述べた解決策は理にかなっています。これをインデックス付きビューと組み合わせると、当然、事前に作成された正しい関係マップが常に確保されます。
IamIC

6

データウェアハウスモデルの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を使用する行。


5

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

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

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


いい答えだ。ここで検討しているケースは2つあります。ファクトとディメンション間のN:M、およびファクト、ディメンション、ディメンション間の1:N:M。
ブライアンボールサンスタントン

3
@Brian Ballsun-Stantonファクトとディメンション間でN:Mと言うとき、特定のファクトには、質問のタグのように、すべて適用されるいくつかの区別されないさまざまなカーディナリティの兄弟ディメンションがあることを意味しますか?そのため、1つの質問(事実)にsql-server、data-warehouseのタグを付け、もう1つの質問にdata-warehouse、sql-server、business-intelligenceのタグを付けます。タグ割り当てファクト(質問ファクトとは少し異なる粒度)の別のスターにそれを引きます。インデックス作成の可能性が大きくなり、ディメンションの変化をより明確にキャプチャできるようになります。
ケードルー

@Brian Ballsun-Stanton 1:N:Mに関しては、それは雪の結晶だと思うし、それを避ける傾向がある。ディメンション間の関係に他の星(またはブリッジ)を定義する場合は、問題ありません。次元データウェアハウスは正規化されておらず、とりわけ、実世界のエンティティの関係を具体的に表現したり、冗長性を排除したりするのではなく、特定の種類の操作をサポートするように設計された実用的な構造であることに注意してください。
ケードルー

1
@Brian Ballsun-スタントンてきたキンボールフォーラムを見て、彼が彼のツールキット帳に橋やアウトリガーを呼び出します。forum.kimballgroup.com/...
ケイドRouxの

@Cadeそれらについて説明する回答をお願いできますか?:)
ブライアンボールサン-スタントン

5

以下に、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雑誌記事の多くには、もはや良いリンクがありません...


「代替階層」記事へのリンクが壊れています。たぶん、あなたはこれに言及している:kimballgroup.com/html/designtipsPDF/DesignTips2004/...
ENDY Tjahjono

多対多の記事へのリンクをありがとう。私の 'Aha!'を手に入れました それからの瞬間。
エンディチャジョノ

2番目のリンクは無効です。同じ記事への新しいリンクがあります。ただし、やや文字化けしており、ある時点ですべてのグラフィックが失われます。blog.pythian.com/...
posfan12

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.