2

VoIP サービス用の「通話録音システム」に関する次元モデルを作成しています。私の質問を示すために、ほんの少しの例を示します。

1 つの呼び出しを表すファクトがあるとします。そして、クライアントと呼ばれるディメンションと、プロバイダーと呼ばれる別のディメンションがあります。(もちろん、日付などの他の次元があるふりをします...)

(Dimension)Client ---> (Fact)Call <--- (Dimension)Provider

これにより、クライアントが行った通話の数、プロバイダーを介して送信された通話の数、およびその他の質問を確認できます。

また、1 つのクライアントがプロバイダーに関連付けられており、1 つのプロバイダーが多数のクライアントを持つことができるとします。

では、ここで質問です。次のようなクエリを作成するにはどうすればよいですか: 各プロバイダーにはどのようなクライアントがありますか?

両方の次元の間にあるクエリのようです。クライアントがサービスを使用したことがない場合、そのクライアントは呼び出しファクト テーブルに含まれず、この「プロバイダーごとのクライアント」クエリに表示されないため、その事実を含めることはできません。

これを行う 1 つの方法は、クライアント ディメンションのビューであるロールプレイング ディメンションを作成し、それをプロバイダ ディメンションに直接追加して、このようなクエリを実行することではないかと考えていました。次のようになります。

(Dimension)Client ---> (Fact)Call <--- (Dimension)Provider <--- (Dimension)View Client

もちろん、このアプローチでは、ユーザーはこの View Client ディメンションをファクト テーブルで使用しないように十分に注意する必要があります。これは、ファクト行が重複するためです。

では、これは有名なファクトレス ファクト テーブルを使用する必要がある状況の 1 つですか?

これを行う正しい方法は何ですか?

ありがとう!

4

1 に答える 1

1

ロールプレイング ディメンションは、同じファクト テーブルで複数回使用されるディメンションを「リサイクル」する場合に使用する必要があります (呼び出し日、サービス日など)。

それはあなたが探しているもののようには聞こえません。代わりに、関係が本当に 1 対多である場合は、この関係が事実とは何の関係もないことを認識して、プロバイダー ID をクライアント ディメンションに直接追加します (ビューなどは必要ありません)。

基本的に、この種のクエリに関して言えば、「プロバイダー」はクライアントから降ろされた単なる属性と考えてください。

ただし、クライアントとプロバイダーの間に多対多の関係がないことを確認したい場合があります (クライアントは複数のプロバイダーを使用でき、プロバイダーは複数のクライアントを持つことができます)。多対多の関係、ファクト テーブルとして次元的にモデル化されます。ファクト テーブルは、履歴の有無にかかわらず、現時点のスナップショットである可能性があります。Client必要な列は 2 つだけProviderです。クライアントとプロバイダーの関係を一定期間記録しておきたい場合は、日付スタンプを追加するだけです。

ファクトレス ファクトは、1 対多の関係をモデル化するためにも機能することに注意してください (モデルがバックエンドで変更された場合、ETL は既に完了しています..)

于 2012-06-18T13:06:17.040 に答える