複数のファクトテーブルを持つデータウェアハウスの設計
私はデータウェアハウジングに不慣れです。まず、データウェアハウスツールキットのコピーがメールボックス（カタツムリメール：P）に送られるよりも正確にしたいと思います。しかし、私はすでにネットで見つけたものでこれらすべてのものを研究しています。
しかし、私がネット上で見つけられないのは、DWに複数の事実があるように思われる場合の対処方法です。私の場合（保険）、定期的ではない払い戻しがあります。 1人のクライアントは3か月間何も持たず、同じ月に10人持つことができます。一方、私には「サブスクリプション料金」があります（正しい英語の用語が何であるかはわかりませんが、ポイントはわかります）。これは毎月または3か月ごとに発生します。それは私には明らかに2つの明確な事実のように思えます。
これらの2つは、クライアントや「保険商品」など、いくつかの側面によって疎結合されています。これらの2つの異なるウェアハウスは、2つの異なるレポートを作成してから、DWの外部でレポートを接続する必要がありますか？または、単一の降下DWに適合するようにこれを設計する方法はありますか。それとも、これら2つの事実を1つにまとめる必要がありますか？その場合、払い戻しの粒度が失われる可能性があります。
私が読んだいくつかのブログは、DWには常に1つのファクトテーブルがあると述べています。 Sを使用してファクトテーブルを設計する手順について言及している人もいますが、それらの間にリンクがあるのか、同じDWプロジェクトの別個のコンポーネントであるのかについて明確な指示はありません。
DWデザインのその正確な部分に関するいくつかの参照を知っている人はいますか？
あなたの質問を逆に取ります。
データウェアハウスには、複数のファクトテーブルを含めることができます。ただし、ファクトテーブル間の結合を最小限に抑える必要があります。異なるファクトテーブルにファクト情報を複製してもかまいません。
あなたが言及したオブジェクトのうち：
払い戻しは事実です。タイムスタンプは、払い戻しファクトの次元です。
サブスクリプション料金は事実です。タイムスタンプは、サブスクリプション料金の事実の次元です。
払い戻しは複数回発生する可能性があります。各顧客には1つのサブスクリプション料金があると思います。したがって、これまでのところ、顧客と顧客の払い戻しという2つのファクトテーブルがあるようです。
（例として）最大で3回の払い戻ししかできないことがわかっている場合は、顧客払い戻しファクトテーブルを削除し、顧客テーブルに3つの払い戻し列を配置します。
あなたは保険についても言及します。顧客は複数のポリシーを持つことができます。したがって、3番目のファクトテーブルがあります。
データウェアハウスは通常、 スタースキーマ を使用して設計されます。スタースキーマは基本的に、1つ以上のディメンションテーブルに接続された1つのファクトテーブルです。すでに3つのファクトテーブルを定義しているため、データウェアハウスにはおそらく複数のスターがあります。
古い投稿に回答していることに気づきましたが、どちらの回答にも満足していません。どちらも質問に答えなかったと思います。
スキーマには1つ以上のファクトを含めることができますが、これらのファクトは主要な関係によってリンクされていません。正規化/トランザクションデータベースにクエリを実行する場合のように、単一のクエリでファクトテーブルを結合しないことをお勧めします。多対多の結合などの性質により、試行すると結果が不正確になります。
あなたが探している答えは、あなたが「ドリルアクロス」する必要があるということです。これは基本的に、各ファクトテーブル（スキーマ）を個別にクエリし、結果をマージすることを意味します。これは、SQlを使用して、またはできればデータウェアハウスを参照している可能性のあるレポート/分析ツールを介して発生する可能性があります。これを行う方法についての回答を複製する代わりに、私はすべての人に2つの非常に優れた記事を紹介します。
そして
ファクトテーブルはいくつでも持つことができます。あなたの例では、次のようなものがあります。
dimProductは、いくつかの製品をリストしています-サブスクリプションはそれらの1つです。 dimTransactionTypeは、可能なトランザクション（購入、返金、定期購読料...）を一覧表示します。
ここで、単純化されたサブスクリプションレポートに関心があるとすると、次のようにfactSubscriptionを追加できます。
